[gentoo-dev] latest boost vs. eselected boost
Hello, a user submitted a bug[1] that cmake always select the latest boost. We the kde team as cmake maintainer found a solution to respect the (e)selected boost. The patched version is not in tree yet, because after my blog post[2] about this issue a discussion in the bug starts. Summary of the comments: 1) Ebuilds should always pick the latest boost version. 2) Boost should be compared to gcc, python, ruby etc So please state your opinion here, before the bug comments explode. In the case that eselect feature for boost will be last rited as in comment 16[1] announced, then you can forget this mail. [1] https://bugs.gentoo.org/show_bug.cgi?id=335108 [2] http://blogs.gentoo.org/johu/2012/01/13/cmake-picks-always-the-latest- boost/ Greetings -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID F3CFD2BD signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] latest boost vs. eselected boost
On 1/19/12 9:05 AM, Johannes Huber wrote: Summary of the comments: 1) Ebuilds should always pick the latest boost version. 2) Boost should be compared to gcc, python, ruby etc [1] https://bugs.gentoo.org/show_bug.cgi?id=335108 Right, Tiziano Müller's (dev-zero) comments are pretty clear that ebuilds should use latest boost. I'm fine with last-riting eselect-boost, and I'm also fine with eselect-boost applying to ebuilds too, like eselect-python. What I mostly care about is consistency and principle of least surprise. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: How help in arch testing work
On 19/01/2012 07:02, Mike Frysinger wrote: On Wednesday 18 January 2012 14:02:01 Markos Chandras wrote: On 01/18/2012 05:32 PM, Paweł Hajdan, Jr. wrote: On 1/18/12 4:48 PM, Donnie Berkholz wrote: On 10:05 Wed 18 Jan , Mike Frysinger wrote: On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote: 3) Check your rdepend, where is possible with scanelf[3] and if you declare it, please, as you said, exclude gcc/glibc and all package from @system portage generates a NEEDED file in the vdb Awesome, never seen that before! Same here. How about adding some warning to portage (maybe just in the developer profile) when files in NEEDED are provided by packages not in RDEPEND? Interesting idea. I agree this has to be only in dev profile for now would probably be easy to just whip up a tool that ran locally on all of the dev's installed packages ... -mike Although it does not make use of the newly-discovered NEEDED file, I wrote a tool a while back that checks scanelf output against RDEPEND: https://github.com/kensington/gentoo-tools/blob/master/missingdep.sh
[gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
While dealing with https://bugs.gentoo.org/show_bug.cgi?id=393471 I started discussing with developers working on libjpeg-turbo support in WebKit, and I learned that despite http://archives.gentoo.org/gentoo-dev/msg_e67bedf25dd178ec09a325a1220724e6.xml libjpeg-turbo is not necessarily binary compatible with libjpeg, and even with different versions of itself. Here's why. See http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299view=markup and search for as a shared library. I'll paste the relevant quote here anyway: While you can build the JPEG library as a shared library if the whim strikes you, we don't really recommend it. The trouble with shared libraries is that at some point you'll probably try to substitute a new version of the library without recompiling the calling applications. That generally doesn't work because the parameter struct declarations usually change with each new version. In other words, the library's API is *not* guaranteed binary compatible across versions; we only try to ensure source-code compatibility. The particular problem with www-client/chromium is caused by http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp which sort of hardcodes in the compiled binary whether it was compiled against libjpeg-turbo with swizzle support (whatever that is) or not. The real problem here is that with above no guarantee of binary compatibility such a solution may be considered legitimate, especially that for e.g. Google Chrome the bundled copy of libjpeg-turbo is always used. What do you guys think we should do with this on the Gentoo side? At this moment I've just reverted the mentioned change in www-client/chromium ebuild, but it's not feasible to keep a local patch too long (it needs rebasing too often). I was thinking about changing SONAMES, which would trigger rebuilds make things work, but then don't we rely on specific libjpeg SONAMES for binary-only software to work? Or does such binary-only software just use libjpeg-6b? Are there some other solutions we could apply on the Gentoo side? The main point here is that Chromium upstream considers http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp a legitimate change, and based on the referenced http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299view=markup disclaimer about no guarantee of binary compatibility, I think it makes sense. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On Wed, 18 Jan 2012 22:00:52 -0500 Mike Frysinger vap...@gentoo.org wrote: I see a violation of this rule at least on 2.13-r4, which leads to useless rebuilds on `emerge -avuND world` on every single gentoo install world-wide. i don't have too much compassion for -N. if people really care enough about it, they'd read the ChangeLog and see that it is meaningless. -mike I wonder why locale-gen stopped working after a meaningless rebuild. But that's probably my fault somehow. Bad moon phase or something. * (1/3) Generating pl_PL.UTF-8 ...locale alias file `/usr/share/locale/locale.alias' not found: No such file or directory [ !! ] -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On Thu, 19 Jan 2012 03:42:14 +0100 Michael Weber x...@gentoo.org wrote: Um, what happend to the policy to not f*** around with stable ebuilds? I don't think such a rule has any meaning considering that those ebuilds are mostly contained in an eclass. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
On 01/19/2012 11:19 AM, Paweł Hajdan, Jr. wrote: While dealing withhttps://bugs.gentoo.org/show_bug.cgi?id=393471 I started discussing with developers working on libjpeg-turbo support in WebKit, and I learned that despite http://archives.gentoo.org/gentoo-dev/msg_e67bedf25dd178ec09a325a1220724e6.xml libjpeg-turbo is not necessarily binary compatible with libjpeg, and even with different versions of itself. Here's why. See http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299view=markup and search for as a shared library. I'll paste the relevant quote here anyway: While you can build the JPEG library as a shared library if the whim strikes you, we don't really recommend it. The trouble with shared libraries is that at some point you'll probably try to substitute a new version of the library without recompiling the calling applications. That generally doesn't work because the parameter struct declarations usually change with each new version. In other words, the library's API is *not* guaranteed binary compatible across versions; we only try to ensure source-code compatibility. The particular problem with www-client/chromium is caused by http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp which sort of hardcodes in the compiled binary whether it was compiled against libjpeg-turbo with swizzle support (whatever that is) or not. The real problem here is that with above no guarantee of binary compatibility such a solution may be considered legitimate, especially that for e.g. Google Chrome the bundled copy of libjpeg-turbo is always used. What do you guys think we should do with this on the Gentoo side?At always use system libraries and i'm in process of dropping keywording from media-libs/jpeg wrt[1] since we have no need for source slot of it [1] http://bugs.gentoo.org/398909 both providers will be left in the virtual/jpeg, but only libjpeg-turbo will be keyworded (and thus supported), eliminating rest of the issues raised here - Samuli this moment I've just reverted the mentioned change in www-client/chromium ebuild, but it's not feasible to keep a local patch too long (it needs rebasing too often). I was thinking about changing SONAMES, which would trigger rebuilds make things work, but then don't we rely on specific libjpeg SONAMES for binary-only software to work? Or does such binary-only software just use libjpeg-6b? Are there some other solutions we could apply on the Gentoo side? The main point here is that Chromium upstream considers http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp a legitimate change, and based on the referenced http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299view=markup disclaimer about no guarantee of binary compatibility, I think it makes sense.
Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
On Thu, 19 Jan 2012 10:19:27 +0100 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: While dealing with https://bugs.gentoo.org/show_bug.cgi?id=393471 I started discussing with developers working on libjpeg-turbo support in WebKit, and I learned that despite http://archives.gentoo.org/gentoo-dev/msg_e67bedf25dd178ec09a325a1220724e6.xml libjpeg-turbo is not necessarily binary compatible with libjpeg, and even with different versions of itself. Here's why. See http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libjpeg.txt?revision=299view=markup and search for as a shared library. I'll paste the relevant quote here anyway: While you can build the JPEG library as a shared library if the whim strikes you, we don't really recommend it. The trouble with shared libraries is that at some point you'll probably try to substitute a new version of the library without recompiling the calling applications. That generally doesn't work because the parameter struct declarations usually change with each new version. In other words, the library's API is *not* guaranteed binary compatible across versions; we only try to ensure source-code compatibility. The particular problem with www-client/chromium is caused by http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp which sort of hardcodes in the compiled binary whether it was compiled against libjpeg-turbo with swizzle support (whatever that is) or not. The real problem here is that with above no guarantee of binary compatibility such a solution may be considered legitimate, especially that for e.g. Google Chrome the bundled copy of libjpeg-turbo is always used. What do you guys think we should do with this on the Gentoo side? At this moment I've just reverted the mentioned change in www-client/chromium ebuild, but it's not feasible to keep a local patch too long (it needs rebasing too often). I was thinking about changing SONAMES, which would trigger rebuilds make things work, but then don't we rely on specific libjpeg SONAMES for binary-only software to work? Or does such binary-only software just use libjpeg-6b? Hmm, does this mean the ABI differs on runtime compilation options? SONAME should be changed with new versions, not options. If upstream does allow things like that, that's bad. If chromium uses that, it's even worse. I'd go with the simplest solution which is either enabling the particular configure option unconditionally or disabling it. If possible -- synced with SONAME change. But it should be upstream SONAME change (considering they do change SONAMEs when releasing binary-incompatible versions); we don't really want to go the Debian way, keeping our own SONAME cycles. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] How help in arch testing work
On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger vap...@gentoo.org wrote: if it's part of the implicit system dep, they absolutely need to defend their actions. you want to change the policy, then start a thread on it. What policy? I don't see any written policy stating that you aren't allowed to include system packages in *DEPEND. There is a line in the devmanual stating that it is not necessary, nor advisable,... to list some kinds of system dependencies, full of caveats about the system set varying by profile and specific versions and such. It does not say that it is not permitted. So, I don't really see any policy to change. Anybody wanting to create such a policy is of course welcome to start a thread on it... :) Rich
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glib
On Thu, Jan 19, 2012 at 08:56:57AM -0500, Rich Freeman wrote: So, suppose I don't want to update those 200 kde packages, but I don't want to ignore the odd package that does come up in -N in the future? Do I just run a daily emerge -puDN world, look at the output, then manually remove the 200 kde packages, and then run a manually-constructed emerge -1 with a bunch of individual packages on it? If anyone missed that, there's --exclude now and it was a simple --exclude=kde-base/* to skip those packages and wait for a better moment (like some important upgrade). Piotr Szymaniak. -- Mezczyzna odlozyl gazete z powrotem na stojak i postapil krok w przod, robiac mine, ktora nadala mu wyglad swinskiego pecherza rozpietego na drucianym wieszaku do garniturow. -- Graham Masterton, The Burning signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On Thursday 19 January 2012 04:32:01 Michał Górny wrote: On Wed, 18 Jan 2012 22:00:52 -0500 Mike Frysinger wrote: I see a violation of this rule at least on 2.13-r4, which leads to useless rebuilds on `emerge -avuND world` on every single gentoo install world-wide. i don't have too much compassion for -N. if people really care enough about it, they'd read the ChangeLog and see that it is meaningless. I wonder why locale-gen stopped working after a meaningless rebuild. But that's probably my fault somehow. Bad moon phase or something. * (1/3) Generating pl_PL.UTF-8 ...locale alias file `/usr/share/locale/locale.alias' not found: No such file or directory [ !! ] pretty sure /usr/share/locale/locale.alias has always been unconditionally installed by glibc -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/01/12 10:41 PM, Mike Gilbert wrote: On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger vap...@gentoo.org wrote: - you're confusing the literal @system with implicit system deps I don't quite follow here. literal @system = the exact packages listed in the 'system' package list implicit deps = packages installed as part of the system due to dependency resolution (including via use flags or whatnot and/or default settings from the profile) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk8YSBMACgkQAJxUfCtlWe0LlAEAnSzthcxjk3BAFJSrYysjtiUl mfQw1TMZ4wxcLgxJtQAA/jjquypoUwjCCJhwEYSNPM5dRHu3jNhapVfN2+8H32AF =4LFJ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On Thursday 19 January 2012 04:32:46 Michał Górny wrote: On Thu, 19 Jan 2012 03:42:14 +0100 Michael Weber wrote: Um, what happend to the policy to not f*** around with stable ebuilds? I don't think such a rule has any meaning considering that those ebuilds are mostly contained in an eclass. pedantically speaking, i think you're thinking of gcc. glibc is mostly contained in eblits. practically speaking, it's mostly the same, although there's a bit more control over things with eblits. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: How help in arch testing work
On Wednesday 18 January 2012 21:23:47 Duncan wrote: If people want it, they can merge it, just like any other package. Really, the same applies to busybox, and arguably, even to module-init-tools (and the more recent replacement, kmod...), since that's not needed if people choose to build all their drivers into the kernel. not really. the # of people who build their kernel without module support is such a minority that they can suck it up and accept the additional dep, or simply use one of the many existing knobs in /etc/portage/ to disable it. busybox is there because we believe Gentoo should have a rescue shell installed for when the system/user eats things and needs recovery without resorting to a livecd. if you never make a mistake, then you're free to ignore it like anything else. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] latest boost vs. eselected boost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/01/12 03:27 AM, Paweł Hajdan, Jr. wrote: On 1/19/12 9:05 AM, Johannes Huber wrote: Summary of the comments: 1) Ebuilds should always pick the latest boost version. 2) Boost should be compared to gcc, python, ruby etc [1] https://bugs.gentoo.org/show_bug.cgi?id=335108 Right, Tiziano Müller's (dev-zero) comments are pretty clear that ebuilds should use latest boost. I'm fine with last-riting eselect-boost, and I'm also fine with eselect-boost applying to ebuilds too, like eselect-python. What I mostly care about is consistency and principle of least surprise. I thought there was a push to eventually de-slot boost? (in which case this issue just disappears) Anyways, if we ARE going to keep boost slotted, we should probably have a mechanism within ebuilds to select the boost version that will be used -- simiar to/same as python and ruby (or perhaps closer to autotools? unsure which paradigm best fits). Yes, I know how much of a potential mess this could be and how much of a PITA it's going to be to do.* I'm not sure if using eselect-boost for this would be a good idea, though; isn't eselect mainly just for the system? IE, when a user is using boost for their own stuffs? * Given that python and ruby already need to do this, maybe it would be a good idea to make an eclass and set of functions that generalize this capability, and then convert the python and ruby eclasses and ebuild to use (or at least inherit) the generalized eclass? Seems better than reinventing the wheel for every slotted build platform.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk8YSecACgkQAJxUfCtlWe0mpwD/TClHGn/93VFTiuP7S7ZUnF5k yDbm8jRbG2fL0vwiemgBAJ4uYSpFVuzAJgR/ZoDou94umBLarPdc2OxInnH/1QyY =pzBv -END PGP SIGNATURE-
Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
On Thursday 19 January 2012 04:35:43 Samuli Suominen wrote: On 01/19/2012 11:19 AM, Paweł Hajdan, Jr. wrote: While dealing withhttps://bugs.gentoo.org/show_bug.cgi?id=393471 I started discussing with developers working on libjpeg-turbo support in WebKit, and I learned that despite http://archives.gentoo.org/gentoo-dev/msg_e67bedf25dd178ec09a325a1220724 e6.xml libjpeg-turbo is not necessarily binary compatible with libjpeg, and even with different versions of itself. Here's why. See http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/libj peg.txt?revision=299view=markup and search for as a shared library. I'll paste the relevant quote here anyway: While you can build the JPEG library as a shared library if the whim strikes you, we don't really recommend it. The trouble with shared libraries is that at some point you'll probably try to substitute a new version of the library without recompiling the calling applications. That generally doesn't work because the parameter struct declarations usually change with each new version. In other words, the library's API is *not* guaranteed binary compatible across versions; we only try to ensure source-code compatibility. The particular problem with www-client/chromium is caused by http://trac.webkit.org/changeset/101286/trunk/Source/WebCore/platform/im age-decoders/jpeg/JPEGImageDecoder.cpp which sort of hardcodes in the compiled binary whether it was compiled against libjpeg-turbo with swizzle support (whatever that is) or not. The real problem here is that with above no guarantee of binary compatibility such a solution may be considered legitimate, especially that for e.g. Google Chrome the bundled copy of libjpeg-turbo is always used. What do you guys think we should do with this on the Gentoo side?At always use system libraries that doesn't help. the libjpeg turbo peeps themselves have said they don't guarantee compatibility across their own versions. and i'm in process of dropping keywording from media-libs/jpeg wrt[1] since we have no need for source slot of it err, no. libjpeg-turbo doesn't provide the older SONAME's like jpeg does. those SLOT's aren't going anywhere (SLOT!=0). history has shown that the canonical version stays around while the derivatives come and go. so until the seemingly braindead ABI policies of libjpeg-turbo can get sorted out, i don't think we can drop KEYWORDS on SLOT=0 jpeg. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
On Thursday 19 January 2012 09:04:08 Rich Freeman wrote: On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger vap...@gentoo.org wrote: if it's part of the implicit system dep, they absolutely need to defend their actions. you want to change the policy, then start a thread on it. What policy? I don't see any written policy stating that you aren't allowed to include system packages in *DEPEND. we've always avoided depending on implicit system packages. the devmanual was the first attempt and writing it down, but it doesn't change the history no matter how much you want otherwise. the exact package list has been refined over time to shrink things down, but it hasn't change the policy. There is a line in the devmanual stating that it is not necessary, nor advisable,... to list some kinds of system dependencies, full of caveats about the system set varying by profile and specific versions and such. It does not say that it is not permitted. considering all the packages listed have known conflicts for other profiles, it is an error for you to attempt to include it. and as already stated, doing it is just in my packages doesn't fly as crap spreads. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
On Wednesday 18 January 2012 22:41:26 Mike Gilbert wrote: On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger wrote: - you're confusing the literal @system with implicit system deps I don't quite follow here. By implicit system deps, are you referring to the common sense set of essential packages that you have floating around in that brain of yours? :) this policy predates me, and i'm not the only one supporting it (i've had almost no hand in the construction of any part of the devmanual for examle). i might have a pretty good idea of what things entail now, but that's purely a matter of me staring at the guts of the core system for so long. at this point, things can probably be enumerate a bit more clearly due to the slow culling of less important packages from @system. i'd have to noodle. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
On 1/19/12 6:02 PM, Samuli Suominen wrote: On 01/19/2012 06:56 PM, Mike Frysinger wrote: that doesn't help. the libjpeg turbo peeps themselves have said they don't guarantee compatibility across their own versions. it's forward compatible, which is all we should care about Just a note: that'd require me to DEPEND on a recent enough version of libjpeg-turbo in the www-client/chromium ebuild, which would mean either: a) changing the virtual/jpeg dependency to =libjpeg-turbo-... b) adding a versioned virtual/jpeg to require a recent enough libjpeg-turbo (but then what about libjpeg versions - it can easily become complicated) c) similar to a) but also adding || ( =libjpeg-turbo-... libjpeg ) With proper SONAMEs in libjpeg-turbo that would be a non-issue (bump the SONAME on incompatible change, revdep-rebuild does the rest). the only thing that's really broken is building against libjpeg-turbo, and then switching to ijg's jpeg without rebuilding the package I'm fine with not supporting that, provided keywords for libjpeg are dropped (except the 62 slot iirc). and downgrading of libjpeg-turbo I think this one should just work, or at least not allow obvious mistakes. See my a) b) c) notes above in this e-mail for possible solutions and ideal SONAME. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On 01/19/2012 05:56 AM, Rich Freeman wrote: On Thu, Jan 19, 2012 at 12:37 AM, Duncan1i5t5.dun...@cox.net wrote: Mike Frysinger posted on Wed, 18 Jan 2012 22:00:52 -0500 as excerpted: On Wednesday 18 January 2012 21:42:14 Michael Weber wrote: Um, what happend to the policy to not f*** around with stable ebuilds? I think there is a legitimate issue with changing dependencies on stable ebuilds. If for whatever reason a mistake is made, you just broke tons of stable systems - especially if people rebuild with -N. The idea is that stuff goes through testing before it hits stable, which is why we call it stable. If you change stable directly, then it isn't stable. :) Care certainly needs to be taken. However, for things like eclass changes, there may be no choice but to modify the metadata of all eclass consumers (regardless of stable keywords). I see a violation of this rule at least on [glibc-]2.13-r4, which leads to useless rebuilds on `emerge -avuND world` on every single gentoo install world-wide. i don't have too much compassion for -N. if people really care enough about it, they'd read the ChangeLog and see that it is meaningless. Until somebody posts a definitive list of which features we have compassion on, and which ones we don't, we should have compassion on anybody using standard portage features. It seems like when things go wrong with somebody's box the knee-jerk reaction is to say well, you should be running daily emerge -alphabetsoup world where alphabetsoup tends to vary by individual preference. I do recall some talk a few months ago about how it might not hurt to come up with a best-practices suggestion for doing regular upgrades, but it hasn't happened yet. I'm pretty sure -N was one of the items that was tossed around as a best practice. The fact is, the user is not being forced to rebuild anything. They can simply run full system updates with --newuse less often if it puts too much strain on them. It holds back progress for everyone if developers have to try to avoid making changes that trigger --newuse rebuilds. I'm more concerned about the tendency to introduce flags in our package manager, have them get promoted in various forums, and then have people more-or-less rebuked for using them. There is no problem in having flags that shouldn't be routinely used, but man pages and such should clearly indicate when this is the case (as is the case with --unmerge and so on). If we don't warn people not to use a flag, we shouldn't punish them when they do. It's only perceived as punishment to a person who is compelled to run a full system update with --newuse, but is unhappy with the number of packages it will cause to be rebuilt. As said, they can run updates less often if it's too much strain. -- Thanks, Zac
Re: [gentoo-dev] latest boost vs. eselected boost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 19 Jan 2012 11:50:47 -0500 Ian Stakenvicius a...@gentoo.org wrote: I thought there was a push to eventually de-slot boost? (in which case this issue just disappears) Boost doesn't have any ABI stability. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk8YU1sACgkQ96zL6DUtXhHsuwCgk3TfhqnKMwgkKdcSptePpZOT ohsAoIYkkO4EBbHJ7dSwjsGzOjsGXtha =snkX -END PGP SIGNATURE-
Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility
On 01/19/2012 07:16 PM, Paweł Hajdan, Jr. wrote: On 1/19/12 6:02 PM, Samuli Suominen wrote: On 01/19/2012 06:56 PM, Mike Frysinger wrote: that doesn't help. the libjpeg turbo peeps themselves have said they don't guarantee compatibility across their own versions. it's forward compatible, which is all we should care about Just a note: that'd require me to DEPEND on a recent enough version of libjpeg-turbo in the www-client/chromium ebuild, which would mean either: a) changing the virtual/jpeg dependency to=libjpeg-turbo-... will be done soon as 1.2.0 is released and stabilized, i'd like to skip 1.1.90 and downgrading of libjpeg-turbo I think this one should just work, or at least not allow obvious mistakes. See my a) b) c) notes above in this e-mail for possible solutions and ideal SONAME. a) is fine, preventing any downgrades. a fatal check, like glibc and qt4 has to prevent downgrading is an option too, but a bit overkill imho
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glib
Rich Freeman posted on Thu, 19 Jan 2012 08:56:57 -0500 as excerpted: On Thu, Jan 19, 2012 at 12:37 AM, Duncan 1i5t5.dun...@cox.net wrote: Mike Frysinger posted on Wed, 18 Jan 2012 22:00:52 -0500 as excerpted: On Wednesday 18 January 2012 21:42:14 Michael Weber wrote: Um, what happend to the policy to not f*** around with stable ebuilds? I think there is a legitimate issue with changing dependencies on stable ebuilds. If for whatever reason a mistake is made, you just broke tons of stable systems - especially if people rebuild with -N. The idea is that stuff goes through testing before it hits stable, which is why we call it stable. If you change stable directly, then it isn't stable. :) In theory at least, gentoo/kde has a rather firm policy that no change to either the ebuilds or the eclasses goes directly to tree (stable OR ~arch). Instead, it gets introduced into the overlay first, with several gentoo/kde devs and app-testers plus random brave/stupid-enough-to-run- overlay users like me testing it there, before it's introduced to the main tree, at all. Since from my observation at least, they're usually quite good about this, precisely BECAUSE of the possibility of mistakes you mention, and the costs of such a mistake especially for eclasses used by hundreds of packages, I'd be rather surprised if that didn't happen here. None-the-less, there are enough differences between overlay and the main tree, that such testing isn't likely to give 100% coverage. More importantly, many in-tree packages don't have such an overlay or if they do, such a strict test-in-overlay-first policy. AFAIK glibc is one such package and your point thus remains very valid in general and for that package (and eclasses), even if less so for projects like gentoo/kde with active overlays and strict overlay-first policies. I'm not going to complain much about a mere single package, glibc, triggering a -N rebuild. But I'm not going to complain about gentoo/kde doing it with 200-ish, either (way more if I had all of kde installed, I don't), for several reasons: 1) I'm not only running ~arch, I'm running the overlay. I'm running stable amd64 and the same kde issue directly hit stable. Oh, this is two days after the version bump hit stable - so that is 200 packages twice in two days. So, I will point out that this could have been better coordinated, although the extra rebuilds are harmless. Ouch! If that hit stable too, and was so uncoordinated with stabilizing whole kde versions that they stable-bumped two days before introducing this change, that changes the entire picture. Dd right were I a stable user I'd be complaining about that! (Even given the existence of the --exclude option mentioned elsewhere and below. You just don't do that to stable users for multi-hundred-package updates!) The USE flag was masked. But they knew a vote was coming on it and they could have either held up stabilizing for a couple extra days to coordinate it, or failing that, just left well enough alone /because/ the flag was masked, until they could drop it in coordination with the next mass stabilization. 3) Mike's right. The -N is simply available to give users a way to be notified of such changes if they wish to be, presumably thru use of -p or -a. So, suppose I don't want to update those 200 kde packages, but I don't want to ignore the odd package that does come up in -N in the future? Do I just run a daily emerge -puDN world, look at the output, then manually remove the 200 kde packages, and then run a manually-constructed emerge -1 with a bunch of individual packages on it? Obviously I'm just going to clench my teeth and run emerge -N anyway since spending 25 cpu-hours on pointless recompiles is less annoying than having those packages come up anytime I want to tweak a USE flag or whatever. Piotr mentions the helpful if AFAIK relatively new --exclude option, which I vaguely knew about but haven't actually had occasion to use, in part because my reaction is much like yours, knowing the change is there I'd rather grit my teeth and get it over with than wait. Even so, especially for multi-hundred-package projects like kde, it's a big deal, particularly for stable users, who presumably have chosen to use stable in part /because/ they don't want to be bothered with such things, far preferring that it just work by the time they get it and not to be bothered with unnecessary churn, even at the cost of being months or years behind, sometimes. But since it came up: @ Zac: Could the output of an emerge --pretend (or --ask) account for -newuse, and include a boilerplate sentence or so about --exclude, if the proposed package merge list includes any same-version remerges due to --newuse? Or if tracking --newuse packages is too much, just trigger the boilerplate if --newuse is among the passed (or default) options. @ gentoo/kde: Barring that or meanwhile,
[gentoo-dev] Re: How help in arch testing work
Mike Frysinger posted on Thu, 19 Jan 2012 11:46:21 -0500 as excerpted: On Wednesday 18 January 2012 21:23:47 Duncan wrote: If people want it, they can merge it, just like any other package. Really, the same applies to busybox, and arguably, even to module-init-tools (and the more recent replacement, kmod...), since that's not needed if people choose to build all their drivers into the kernel. not really. the # of people who build their kernel without module support is such a minority that they can suck it up and accept the additional dep, or simply use one of the many existing knobs in /etc/portage/ to disable it. That's why I said arguably, even... for the kernel modules suggestion. I wasn't seriously making that argument, only stating that it could be made. busybox is there because we believe Gentoo should have a rescue shell installed for when the system/user eats things and needs recovery without resorting to a livecd. if you never make a mistake, then you're free to ignore it like anything else. Having other recovery arrangements (like the mentioned system backup partition, reachable with a simple alternate root= on the command line) != never make a mistake! In fact, it's precisely because I'm all too aware of the possibility of my own fat-fingering (or neural short- circuiting) as well as recognition of the fact that I DO run ~arch and even masked packages (like the live-git openrc-) that I set it up that way, the rootbak solution being at once both FAR more resilient than a busybox after all still installed on the same working partition that we're assuming now has major faults of an unspecified type, thus triggering the emergency in the first place, AND far more flexible, since the rootbaky solution has all of the same tools in the same configuration as the user was using at the time the backup took place. So if (as happened to a famous LWN editor at one point) an in-hindsight unwise system update shortly before a conference where an important presentation was to be made breaks the working installation, simply boot to rootbak instead, and do the presentation using a snapshot of the system taken when it was known to be working say a month or two earlier. Busybox installed on a broken partition isn't going to help; neither will busybox alone allow you to do your presentation coming up in 15 minutes, if it's going to take 30 minutes of hacking to find and fix the problem. Simply rebooting to a tested working rootbak snapshot of the system made when it WAS working, using an alternate root= on the kernel command line, allows both, and a single root= change in grub is going to be far easier than working in an unfamiliar busybox environment, as well. Of course, that implies changes to the handbook, etc, to encourage users to setup their rootbak partition (partitions, if /usr and /var are on separate partitions), and to periodically update AND TEST the rootbak system snapshot(s), when the system is known to be in a reasonably stable state. But still, openssh is certainly the low hanging fruit, here, busybox less so and not at all as long as it remains the recommended and default emergency solution, and module-init-tools/kmod is only included as an example of an excludeable should we REALLY want to get strict with @system. Meanwhile, the great thing about Gentoo is that it provides mechanisms such as /etc/portage/profile/packages for users who wish to, to make such changes on their own. On that I'm quite sure pretty much everyone here can agree, or we'd not be here discussing it in the first place! =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On 01/19/2012 03:38 PM, Duncan wrote: @ Zac: Could the output of an emerge --pretend (or --ask) account for -newuse, and include a boilerplate sentence or so about --exclude, if the proposed package merge list includes any same-version remerges due to --newuse? Or if tracking --newuse packages is too much, just trigger the boilerplate if --newuse is among the passed (or default) options. Maybe it would be enough to add a suggestion about --exclude in the --newuse section of the emerge man page? I don't think this is confusing enough to qualify for an interactive suggestion. -- Thanks, Zac
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glib
Zac Medico posted on Thu, 19 Jan 2012 16:39:12 -0800 as excerpted: Maybe it would be enough to add a suggestion about --exclude in the --newuse section of the emerge man page? I don't think this is confusing enough to qualify for an interactive suggestion. I'd find that exactly right, here. However, it could be argued that the various boilerplate handholding we're already doing has set the precedent. That's actually where I got the idea, after all. But I'm not going to argue it. I'd be more inclined to argue that we're already over the line in some places, and that if users really need this, they really should consider a different distribution as gentoo's obviously not right for them. So yeah, a mention of --exclude in the manpage's --newuse discussion sounds quite balanced, to me. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On 01/19/2012 07:33 PM, Duncan wrote: However, it could be argued that the various boilerplate handholding we're already doing has set the precedent. That's actually where I got the idea, after all. But I'm not going to argue it. I'd be more inclined to argue that we're already over the line in some places, and that if users really need this, they really should consider a different distribution as gentoo's obviously not right for them. If they don't recognize the connection between --newuse and rebuilds, then I think it's pretty clear that they need to spend some time with the man page to learn the meanings of the options that they're using. So yeah, a mention of --exclude in the manpage's --newuse discussion sounds quite balanced, to me. =:^) http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b6c51afdaa69eb648cd71e07c880051bf734b8cd -- Thanks, Zac
Re: [gentoo-dev] latest boost vs. eselected boost
Am Donnerstag, den 19.01.2012, 11:50 -0500 schrieb Ian Stakenvicius:
On 19/01/12 03:27 AM, Paweł Hajdan, Jr. wrote:
On 1/19/12 9:05 AM, Johannes Huber wrote:
Summary of the comments: 1) Ebuilds should always pick the latest
boost version. 2) Boost should be compared to gcc, python, ruby
etc
[1] https://bugs.gentoo.org/show_bug.cgi?id=335108
Right, Tiziano Müller's (dev-zero) comments are pretty clear that
ebuilds should use latest boost.
I'm fine with last-riting eselect-boost, and I'm also fine with
eselect-boost applying to ebuilds too, like eselect-python.
What I mostly care about is consistency and principle of least
surprise.
I thought there was a push to eventually de-slot boost? (in which
case this issue just disappears)
No.
Anyways, if we ARE going to keep boost slotted, we should probably
have a mechanism within ebuilds to select the boost version that will
be used -- simiar to/same as python and ruby (or perhaps closer to
autotools? unsure which paradigm best fits). Yes, I know how much of
a potential mess this could be and how much of a PITA it's going to be
to do.* I'm not sure if using eselect-boost for this would be a good
idea, though; isn't eselect mainly just for the system? IE, when a
user is using boost for their own stuffs?
Yes, exactly. As I wrote in the bug: the eselect-boost module was for
the transition from unslotted to slotted boost as well as for people
doing development on Gentoo using boost.
If you want compare the boost-case to something, it's probably best
compared to sys-libs/db.
Two years ago (maybe there is a better solution by now) I used something
like this to extract the boost-include directory in an ebuild:
BOOST_PKG=$(best_version =dev-libs/boost-1.35.0-r5)
BOOST_VER=$(get_version_component_range 1-2 ${BOOST_PKG/*boost-/})
BOOST_INC=/usr/include/boost-$(replace_all_version_separators _
${BOOST_VER})
Maybe someone can come up with a wrapper to have something like this:
WORKING_BOOST_SLOTS=1.37 1.38 1.42 1.45
[...]
DEPEND=$(slot_deps dev-libs/boost ${WORKING_BOOST_SLOTS})
[...]
BOOST_SLOT=$(best_slot dev-libs/boost ${WORKING_BOOST_SLOTS})
BOOST_INC=$(best_slot_boost_include ${WORKING_BOOST_SLOTS})
which could be used for other slotted libs, like sys-libs/db.
(basically a generalization of the db-use.eclass)
Cheers,
Tiziano
smime.p7s
Description: S/MIME cryptographic signature
