The current stage3 for i686 (2009-11-24) contains kernel sources within the tarball. Reproducible: Didn't try Steps to Reproduce: Downloaded the stage3 from distfiles.gentoo.org today; after untarring I found 385MB worth of 2.6.30 kernel sources in usr/src. Actual Results: You should be able to reproduce the same thing relatively easily, assuming the stage3 on each distfiles.gentoo.org server is the same Expected Results: I wouldn't think we'd want to distribute kernel sources within stage3 tarballs, but maybe my understanding of the role of stage3 tarballs and gentoo's have drifted apart. My apologies if this is a dup. I can never seem to find anything with the bugzilla search system.
The kernel sources were not intentionally added to the stage3. The stage3 tarball is just the packages contained in the system set and their dependencies. If the kernel sources are now being included, it's because some package in system started DEPENDing on it.
>=udev-146 uses linux-info.eclass, which pulls virtual/linux-sources Can we get this fixed, please? @zzam: We talked about this before but i don't remember it. There was a workaround for udev-141 to skip this issue.
Looking through the logs i found robbat2 and zmedico talking about it...cc'ing them.
Maybe just add emerge -C virtual/linux-sources as the last step in the stage building, since it's not a runtime dep.
That requires a modification to catalyst, which I'd rather not do. The other option is to do a second build for each spec in the catalyst-auto script so that it just uses binary packages, but the build takes long enough as it is.
agaffney: why isn't catalyst removing the non-RDEPEND packages anyway? But maybe we accelerate the 1-month notice I gave on the -dev list today.
There's never been a need for catalyst to do so. Normally, we just run it twice, and the second time through uses the binpkgs from the first. Is there an "easy" way to identify non-RDEPEND packages?
(In reply to comment #7) > "easy" way to identify non-RDEPEND packages? emerge --depclean --with-bdeps=n
(In reply to comment #2) > >=udev-146 uses linux-info.eclass, which pulls virtual/linux-sources > > Can we get this fixed, please? > > @zzam: We talked about this before but i don't remember it. There was a > workaround for udev-141 to skip this issue. > You can set I_KNOW_WHAT_I_AM_DOING to get linux-info.eclass to not depend on kernel-sources. See bug 283320
(In reply to comment #9) > (In reply to comment #2) > > >=udev-146 uses linux-info.eclass, which pulls virtual/linux-sources > > > > Can we get this fixed, please? > > > > @zzam: We talked about this before but i don't remember it. There was a > > workaround for udev-141 to skip this issue. > > > > You can set I_KNOW_WHAT_I_AM_DOING to get linux-info.eclass to not depend on > kernel-sources. > See bug 283320 > Yes, but why was that workaround removed? Setting that variable is a bit of a hack, and that means modifying the environment of all the build machines...
Can we get this fixed as a christmas present? :)
If you want a quick workaround, add sys-kernel/gentoo-sources-2.6.31-r6 to /etc/portage/profile/package.provided for the stage builds. I tried that locally and it seems to work.
Either way, we'd need to modify catalyst. I've added the 'emerge --depclean --with-bdeps=n' to the code. I'll try to get catalyst-2.0.6.906 out the door today with that fix (and a few other tiny things).
This is fixed with catalyst-2.0.7.907. The stage3-i686-20091229.tar.bz2 is now 121MB vs. 182MB for the previous week.
Meh...but that workaround sucks! Why do the buildboxes have to emerge a kernel source if they aren't going to use it? Thats waste of space during buildtime and slowness on embedded architectures. I still require an answer to comment #9.
This "workaround" just accomplishes the same thing that we did during normal release cycles when we ran the build a second time with binpkgs. It's just more efficient! :P
armin76: The logic made available by I_KNOW_WHAT_I_AM_DOING=1 is going to become default in 10 days, per my mail to -dev.
