![]() |
|
|
|||
|
emerging klibc gets wrong kernel sources?
Following the guide to get uvesafb working, I emerged klib. This
downloaded kernel 2.6.23 and the 2.6.24-rc7 patch. However, emerging gentoo-sources previously got 2.6.24-r4. So now there are two kernel trees. Shouldn't klibc compile against the gentoo-sources kernel? And space is showing signs of getting tight already. I only have a base-system, and yet it eats 3GB (from 10GB total). It looks like Gentoo will need outrageous amounts of space for a full KDE desktop. |
|
|||
|
Re: emerging klibc gets wrong kernel sources?
Nikos Chantziaras wrote:
> Following the guide to get uvesafb working, I emerged klib. This > downloaded kernel 2.6.23 and the 2.6.24-rc7 patch. However, emerging > gentoo-sources previously got 2.6.24-r4. So now there are two kernel > trees. Shouldn't klibc compile against the gentoo-sources kernel? No, there are some trouble with klibc that makes it can't be compiled against a normal kernel source or against the Linux headers, you need a specially patched kernel source to make this work, thats why you get the 2.6.24-rc7 kernel source (don't use this one to compile a normal kernel). > And space is showing signs of getting tight already. I only have a > base-system, and yet it eats 3GB (from 10GB total). It looks like > Gentoo will need outrageous amounts of space for a full KDE desktop. Each time you build something, you download the source and gentoo patches, you should clean out your /usr/portage/distfiles of all unneeded files. A full install of KDE will take something like 511M when compiled. -- //Aho |
|
|||
|
Re: emerging klibc gets wrong kernel sources?
J.O. Aho wrote:
>> And space is showing signs of getting tight already. I only have a >> base-system, and yet it eats 3GB (from 10GB total). It looks like >> Gentoo will need outrageous amounts of space for a full KDE desktop. > > Each time you build something, you download the source and gentoo > patches, you should clean out your /usr/portage/distfiles of all > unneeded files. A full install of KDE will take something like 511M when > compiled. I used `eclean --destructive distfiles` to clean, but it's not really deleting anything. Is it safe to simply `rm -rf /usr/portage/distfiles/*` as well as `rm -rf /var/tmp/portage/*`? Those two directory trees eat about 1GB right now. |
|
|||
|
Re: emerging klibc gets wrong kernel sources?
Nikos Chantziaras wrote:
> J.O. Aho wrote: >>> And space is showing signs of getting tight already. I only have a >>> base-system, and yet it eats 3GB (from 10GB total). It looks like >>> Gentoo will need outrageous amounts of space for a full KDE desktop. >> >> Each time you build something, you download the source and gentoo >> patches, you should clean out your /usr/portage/distfiles of all >> unneeded files. A full install of KDE will take something like 511M >> when compiled. > > I used `eclean --destructive distfiles` to clean, but it's not really > deleting anything. Is it safe to simply `rm -rf > /usr/portage/distfiles/*` as well as `rm -rf /var/tmp/portage/*`? Those > two directory trees eat about 1GB right now. It's safe to do so. -- //Aho |
|
|||
|
Re: emerging klibc gets wrong kernel sources?
Nikos Chantziaras <realnc@arcor.de> wrote:
> J.O. Aho wrote: >>> And space is showing signs of getting tight already. I only have a >>> base-system, and yet it eats 3GB (from 10GB total). It looks like >>> Gentoo will need outrageous amounts of space for a full KDE desktop. >> >> Each time you build something, you download the source and gentoo >> patches, you should clean out your /usr/portage/distfiles of all >> unneeded files. A full install of KDE will take something like 511M >> when compiled. > > I used `eclean --destructive distfiles` to clean, but it's not really > deleting anything. Is it safe to simply `rm -rf > /usr/portage/distfiles/*` as well as `rm -rf /var/tmp/portage/*`? Those > two directory trees eat about 1GB right now. Yes, it's safe. /var/tmp/portage/* will only contain *failed* compiles. /usr/portage/distfiles is nice to have for when rebuilding something, but if you don't mind having to redownload packages you recompile, it's safe to zap that too. Regards, -- *Art |
|
|||
|
Re: emerging klibc gets wrong kernel sources?
Nikos Chantziaras wrote:
> J.O. Aho wrote: >>> And space is showing signs of getting tight already. I only have a >>> base-system, and yet it eats 3GB (from 10GB total). It looks like >>> Gentoo will need outrageous amounts of space for a full KDE desktop. >> >> Each time you build something, you download the source and gentoo >> patches, you should clean out your /usr/portage/distfiles of all >> unneeded files. A full install of KDE will take something like 511M when >> compiled. > > I used `eclean --destructive distfiles` to clean, but it's not really > deleting anything. Is it safe to simply `rm -rf > /usr/portage/distfiles/*` as well as `rm -rf /var/tmp/portage/*`? Those > two directory trees eat about 1GB right now. While it's safe, I wouldn't clear out distfiles. /var/tmp/portage, however, is safe as long as you don't have a current emerge running ;-) The reason I keep distfiles (and mine is currently sitting at 3.3GB) is because I find I'm rebuilding packages intermittently. Keeping the source around speeds things up, even though I have a 10Mb internet connection. It's also much kinder to the mirrors in that I'm not re-downloading (much) each time I do a revdep-rebuild. That and I have all my gentoo boxes mounting from a single location, so it actually has the source to all builds on all machines. (Too bad eclean couldn't check ALL machines for needed sources... luckily, the other machines are almost solely subsets of my primary machine, so it's pretty close.) This means that I download each source tarball once, and compile it up to three times. (Yes, I could just reuse the binaries across the two P4's, though not the P3, and if I had more P4s, I'd probably do so.) More if I have to revdep-rebuild. |
|
|||
|
Re: emerging klibc gets wrong kernel sources?
Darin McBride wrote:
> Nikos Chantziaras wrote: > >> J.O. Aho wrote: >>>> And space is showing signs of getting tight already. I only have a >>>> base-system, and yet it eats 3GB (from 10GB total). It looks like >>>> Gentoo will need outrageous amounts of space for a full KDE desktop. >>> >>> Each time you build something, you download the source and gentoo >>> patches, you should clean out your /usr/portage/distfiles of all >>> unneeded files. A full install of KDE will take something like 511M when >>> compiled. >> >> I used `eclean --destructive distfiles` to clean, but it's not really >> deleting anything. Is it safe to simply `rm -rf >> /usr/portage/distfiles/*` as well as `rm -rf /var/tmp/portage/*`? Those >> two directory trees eat about 1GB right now. > > While it's safe, I wouldn't clear out distfiles. /var/tmp/portage, > however, is safe as long as you don't have a current emerge running ;-) If you (and/or the OP) have a sufficient amount of RAM in your system, you could then make */var/tmp/portage* a /tmpfs./ It's what I do, but then again, that system has 32 GB of RAM in it, so your mileage may vary. ;-) -- Aragorn (registered GNU/Linux user #223157) |
|
|||
|
Re: emerging klibc gets wrong kernel sources?
Aragorn wrote:
> Darin McBride wrote: >> Nikos Chantziaras wrote: >>> I used `eclean --destructive distfiles` to clean, but it's not really >>> deleting anything. Is it safe to simply `rm -rf >>> /usr/portage/distfiles/*` as well as `rm -rf /var/tmp/portage/*`? Those >>> two directory trees eat about 1GB right now. >> While it's safe, I wouldn't clear out distfiles. /var/tmp/portage, >> however, is safe as long as you don't have a current emerge running ;-) > If you (and/or the OP) have a sufficient amount of RAM in your system, you > could then make */var/tmp/portage* a /tmpfs./ It's what I do, but then > again, that system has 32 GB of RAM in it, so your mileage may vary. ;-) There are some packages that requires a lot of free RAM memory to compile, like OpenOffice (think that one may be one of the worst). -- //Aho |
![]() |
|
| Thread Tools | Search this Thread |
| Display Modes | |
|
|