[gentoo-dev] Re: [RFC] Dropping slotted boost
Diego Elio Pettenò posted on Tue, 30 Oct 2012 17:45:27 -0700 as excerpted: > On 30/10/2012 17:42, Duncan wrote: >> >> icu-49.1.2 seems to build just fine against glibc-2.16.0, here. I just >> rebuilt to be sure. (With gcc-4.7.2.) > > I said "1.50+", I'm referring to Boost. Thanks. Makes MUCH more sense when I have the right package (and version) in mind! =;^) (I had mixed them up before, but caught myself until now. This time I didn't. Thanks again.) -- 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] [RFC] Dropping slotted boost
Am Dienstag, den 30.10.2012, 22:48 -0700 schrieb Diego Elio Pettenò: > On 30/10/2012 22:44, Tiziano Müller wrote: > > I agree. It really doesn't make sense to keep unbuildable stuff in the > > tree. The point of slotting it in the first place was also to force a > > rebuild of reverse dependencies to have them use newer boost (since at > > that time when boost slotting was introduced we had some API breakages > > occurring between versions). > > Now with the sub-slots we can simply use this feature to tell the PM to > > rebuild the stuff. > > Well, as long as the soname is correct (which it is), with > preserved-rebuild (which is now available on ~arch Portage as well), > this is basically already possible to some extent without even using > subslots. > > Each new minor version bump (1.49 -> 1.50) will orphan the 1.49 > libraries, @preserved-rebuild will rebuild the linked packages. > > Of course for those that don't link to the objects, but only use the > headers, the sub-slots make it possible as well. > Didn't have @preserved-rebuild back then and I don't really consider this a feature (but that's just a side note). One reason for the slotting was also to give people developing code on Gentoo the chance to easily have multiple versions of boost in parallel (for testing, etc.). This was also the main reason to introduce eselect-boost (besides making the transition to slotted boost easier .. a transition which never really happened since everyone kept relying on eselect-boost). But that too stems from a time when boost got a release once a year, so by now slotting is really just a burden. Question is: do we want to keep the versioned soname scheme (which doesn't make much sense without the slotting) or not. I would like to see it removed together with the slotting. Concerning the maintenance: I'd prefer cpp and nothing else. The reason for this is that boost is tied to the development of C++ itself pretty closely and we want that people who take care of boost have enough knowledge about C++ itself.. and then: why not share your knowledge by taking care of some other C++ packages as well.
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 22:44, Tiziano Müller wrote: > I agree. It really doesn't make sense to keep unbuildable stuff in the > tree. The point of slotting it in the first place was also to force a > rebuild of reverse dependencies to have them use newer boost (since at > that time when boost slotting was introduced we had some API breakages > occurring between versions). > Now with the sub-slots we can simply use this feature to tell the PM to > rebuild the stuff. Well, as long as the soname is correct (which it is), with preserved-rebuild (which is now available on ~arch Portage as well), this is basically already possible to some extent without even using subslots. Each new minor version bump (1.49 -> 1.50) will orphan the 1.49 libraries, @preserved-rebuild will rebuild the linked packages. Of course for those that don't link to the objects, but only use the headers, the sub-slots make it possible as well. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] Dropping slotted boost
Am Dienstag, den 30.10.2012, 11:30 -0700 schrieb Diego Elio Pettenò: > Given the amount of headaches that Boost seems to give us all, now > thanks to the recent changes even more because Gentoo's boost is > different from all others and no upstream default check seem to work > correctly with it, I'm questioning the usefulness of having it slotted. > > Among other things, with each GCC/GLIBC update all but a handful of > slots are kept working; in this case I think most if not all <1.50 are > broken. > > So given that it's a PITA for the maintainers, a PITA for the users, > eselect boost has been shown to be a bad idea and so on ... can we just > go back to just install it and that's about it? I agree. It really doesn't make sense to keep unbuildable stuff in the tree. The point of slotting it in the first place was also to force a rebuild of reverse dependencies to have them use newer boost (since at that time when boost slotting was introduced we had some API breakages occurring between versions). Now with the sub-slots we can simply use this feature to tell the PM to rebuild the stuff. I'll also put cpp as herd for it in metadata.xml.
[gentoo-dev] Re: [RFC] Dropping slotted boost
Okay let's see a moment what's going on with the slotted boost. www-plugins/gnash has a blocker on the old unslotted boost because it doesn't really support multiple boost that well, like most other packages. sci-biology/cufflinks and sci-biology/express are next to completely screwed because they are hardcoding boost-1.46 (which is soon going to make them unusable). Besides, cufflinks shows that it's the kind of crap that should never have entered the tree, considering that filter-ldflags on --as-needed which is not going to do its job even if you pray. dev-util/intel-ocl-sdk does the same, but it might just install its own version since it's not going to work anyway. There was an ebuild for net-analyzer/sslsniff but I removed it since there was a -r1 that works just fine with 1.47 and later. I'm going to give it time till tomorrow to hear if somebody has a good reason to have the slotting (which has to be a _valid_ reason, not a fantasy reason like the ones I heard today about being able to install 1.35 on a modern system). If nobody else can demonstrate a need and a way to leverage the slotting, I'll go with just go this way: - maintainership moved to me+scarabeus+cpp herd (which means Tiziano is still there, btw); - blocker on gnash removed; - intel-ocl-sdk, cufflinks and express will request a particular version (which makes them trouble, but it's mesesd up all the same — optionally I could just go and mask them until properly fixed); - old ebuilds removed from tree with their files, to reduce the rsync trouble. Hopefully then it'll work just as before, with the latest version available unversioned so that old packages relying on eselect will work out of the box, which is what should happen anyway. I'll also run a tinderbox against 1.51, and will start to look into what has to be done to fix whatever is still incompatible with it to work, so that when glibc 2.16 gets out we can unmask this without breaking the 70% of the tree like an unmask of >=1.50-r2 would cause right now. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On 30/10/2012 20:18, Arfrever Frehtes Taifersar Arahesis wrote: > One of major problems with this tinderbox is that it cannot be used > to test packages against newer versions of packages present in > overlays [1] Which is not a problem since we're _not_ talking about packages in overlays but of a bump in the main tree which is not fixed. Really, I would like to ask you to step off of the discussion, you've proven yourself incapable to work within the constraint of the tree already a long time ago. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
2012-10-31 04:18:14 Arfrever Frehtes Taifersar Arahesis napisał(a): > Besides founding problems in about 10% of packages s/founding/finding/ -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
2012-10-29 23:07:15 Diego Elio Pettenò napisał(a): > c) try to get betas and rcs in asap _but masked_; >=sys-devel/gcc-4.7.0, whose usage is required to trigger some problems, is >already package.masked. > d) call for a tinderbox run (I can do that with a quick email); One of major problems with this tinderbox is that it cannot be used to test packages against newer versions of packages present in overlays [1], but it can be very useful. E.g. before release of Python 3.3.0 I had tested about 200 packages against snapshots of Python 3.3 found in an overlay. Besides founding problems in about 10% of packages, I also found some regressions in Python 3.3 [2], which were later fixed before final release of Python 3.3.0. > In this case all should have stopped at a) since libreoffice-bin has a > =49* dep, for obvious reasons. > > Since there was no hurry of security issues to get icu-50 in, I don't > see why this was all forced through -50_rc without giving time to the > _one_ package that was using an older version to update. Maintainers of app-office/libreoffice-bin always build it against stable versions of its dependencies, so maintainers of app-office/libreoffice-bin can be asked to build it against ICU 50 after stabilization of ICU 50. [1] http://blog.flameeyes.eu/2010/08/fixed-in-overlay-read-not-fixed [2] http://bugs.python.org/issue15925 http://bugs.python.org/issue15926 -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 19:50, Arfrever Frehtes Taifersar Arahesis wrote: > I think that slotting is needed, but pkg_postinst() could create > (without using `eselect boost`) symlinks like /usr/include/boost > etc. It is possible that a package works with e.g. Boost 1.50, but > not 1.51, so it could use boost-utils.eclass with BOOST_MAX_SLOT set > to "1.50". That still does *not* solve a thing. It solves the _current_ issue with glibc-2.16, and we'll be back to square one with gcc 4.8, or glibc 2.17, or icu 51, or $whatever_else_the_fuck $n+1. Crazy slots for no reason just have to stop. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] Dropping slotted boost
2012-10-30 19:30:16 Diego Elio Pettenò napisał(a): > Given the amount of headaches that Boost seems to give us all, now > thanks to the recent changes even more because Gentoo's boost is > different from all others and no upstream default check seem to work > correctly with it, I'm questioning the usefulness of having it slotted. > > Among other things, with each GCC/GLIBC update all but a handful of > slots are kept working; in this case I think most if not all <1.50 are > broken. > > So given that it's a PITA for the maintainers, a PITA for the users, > eselect boost has been shown to be a bad idea and so on ... can we just > go back to just install it and that's about it? I think that slotting is needed, but pkg_postinst() could create (without using `eselect boost`) symlinks like /usr/include/boost etc. It is possible that a package works with e.g. Boost 1.50, but not 1.51, so it could use boost-utils.eclass with BOOST_MAX_SLOT set to "1.50". -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [RFC] Dropping slotted boost
On 30/10/2012 17:49, Ryan Hill wrote: > And I had to argue to get 1.48 fixed. I'm not sure why we have to keep so > many unbuildable versions in the tree. Because as mgorny explained earlier he's expecting some fairy to make it possible to _always_ install an older boost just because it's slotted. Honestly, from what I can tell, Mike is doing, exactly like for ICU, a direct proxying of commits from a developer that has been explicitly kicked out by Gentoo, mgorny is in some fantasyland where the presence of an ebuild makes it possible to build it just because it's slotted (and his only commit is to add himself to metadata), Tiziano has been last seen dropping eselect boost in favour of ... nothing, and Sebastian Luther I have no word of in a long time. I'm pretty sure that if the package was moved to cpp, or toolchain, or whatever, is going to be better maintained by whatever is going on now even if it's just going to be re-active instead of pro-active. In the list of bugs for boost, most of the recently RESOLVED ones are NOT related to boost itself, but to the reverse dependencies — lots of them also seem to be due to >=boost-1.50-r2 which is without eselect boost. Of the open ones, I'm pretty sure that a lot of them are obsolete such as bug #334659 "dev-libs/boost is built as non-PIC on amd64", plus we got a number of trackers, ICEs, stabilization bugs still open, and so on so forth. I have unfortunately a few packages using it; so does Tomáš — KDE and MySQL depend on it as well. Is there somebody else interested in the package? We might just want to take this over and restore some sanity. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] Re: [RFC] Dropping slotted boost
On Tue, 30 Oct 2012 19:34:02 -0400 James Cloos wrote: > > "DEP" == Diego Elio Pettenò writes: > > DEP> Among other things, with each GCC/GLIBC update all but a handful of > DEP> slots are kept working; in this case I think most if not all <1.50 > DEP> are broken. > > One datapoint: > > Since protage failed to preserve icu-49 for me, upon which boost > depends, I found that 1.48 and 1.49 build with gcc 4.7.2; but none > of the earlier versions did. And I had to argue to get 1.48 fixed. I'm not sure why we have to keep so many unbuildable versions in the tree. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Dropping slotted boost
On 30/10/2012 17:42, Duncan wrote: > > icu-49.1.2 seems to build just fine against glibc-2.16.0, here. I just > rebuilt to be sure. (With gcc-4.7.2.) I said "1.50+", I'm referring to Boost. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] Re: [RFC] Dropping slotted boost
Diego Elio Pettenò posted on Tue, 30 Oct 2012 16:41:40 -0700 as excerpted: > On 30/10/2012 16:34, James Cloos wrote: >> Since protage failed to preserve icu-49 for me, upon which boost >> depends, I found that 1.48 and 1.49 build with gcc 4.7.2; but none of >> the earlier versions did. > > And only 1.50+ will work with glibc-2.16. ??? icu-49.1.2 seems to build just fine against glibc-2.16.0, here. I just rebuilt to be sure. (With gcc-4.7.2.) I have 50 masked due to the gptfdisk bug, but 49.1.2 continues to build, and AFAICT, work, here. And I just double-checked, nothing in /etc/portage/patches or /etc/portage/env, and no overlay ebuild either, so I'm building straight from tree. Of course being UTF8.en-US, I don't do anything exotic with unicode except the occasional web page or net radio or utube/minitube video, but I've not seen any crashing. -- 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
[gentoo-dev] Re: [RFC] Dropping slotted boost
On Tue, 30 Oct 2012 13:45:38 -0700 Diego Elio Pettenò wrote: > Besides, honestly it's not that bad. I think that half the headache that > we're having is due to the slotting more than from boost itself. And the > other half is due to people actually not going to fix their crap because > "oh I can just use the older version" (until a new compiler or C library > comes out). Ding! We have a winner. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
[gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On Tue, 30 Oct 2012 23:28:47 +0200 Samuli Suominen wrote: > Only every second person is using the ChangeLog in eclass/ as pointed > out and discussed in this ML for so many times it's ridicilous. So step up and set a good example. Since when do we defer to the LCD (Laziest Common Developer)? > The file is pointless if not everyone is using it. I've offered to > remove the file before, and I'm reoffering to do so now. It's pointy enough for most uses. Let's keep it that way. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 16:34, James Cloos wrote: > Since protage failed to preserve icu-49 for me, upon which boost > depends, I found that 1.48 and 1.49 build with gcc 4.7.2; but none > of the earlier versions did. And only 1.50+ will work with glibc-2.16. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] Dropping slotted boost
> "DEP" == Diego Elio Pettenò writes: DEP> Among other things, with each GCC/GLIBC update all but a handful of DEP> slots are kept working; in this case I think most if not all <1.50 DEP> are broken. One datapoint: Since protage failed to preserve icu-49 for me, upon which boost depends, I found that 1.48 and 1.49 build with gcc 4.7.2; but none of the earlier versions did. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Re: glibc-2.16 moving to ~arch
Diego Elio Pettenò posted on Tue, 30 Oct 2012 10:56:11 -0700 as excerpted: > On 30/10/2012 10:46, Duncan wrote: >> ... tho I had to remask gnutls-3.1.3 as I experienced some problem >> (IDR what) with it. But I'm running 3.1.2 without issue. >> What gnutls-3.1.x are you planning to unmask? Do I need to try 3.1.3 >> again and file a bug (if there's not one filed already) if the problem >> still exists, or is 3.1.2 good enough? > > Given that 3.1.2 is not in tree anymore there's no choice uh? Beside, I > don't go masking micro versions around. If you think there's a problem > with 3.1.3, please test and let us know as I haven't hit any (that's > what I've been using myself, and testing the tinderbox against). Followup, FWIW... I forgot I had copied the gnutls 3.1.2 ebuild from /var/db/pkg to keep portage from trying to unmerge it, when 3.1.3 wouldn't build. But it seems the problem I had must have been the parallel-build issue fixed on Oct. 19, according to the changelog. The date on my 3.1.2 binpkg rebuild is Oct. 17, while 3.1.2 was removed with the 3.1.3 introduction on the 13th. So I obviously tried to build it and failed, then with it masked again, found the old version unavailable in-tree, so copied it to my overlay from portage's pkg database, in ordered to keep portage from trying to downgrade to 2.x. But it built and installed just fine when I tried it just now. Thanks to you and Dane S. both! =:^) -- 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-x86/eclass: udev.eclass
On Tue, 30 Oct 2012 15:47:51 -0500 Doug Goldstein wrote: > Stop the bike shedding. Provide real constructive improvements. I'm > not copying and pasting the same hunk of code in a bunch of ebuilds. The point of getting approval for eclasses is not to force you to copy and paste code. It's to ensure that the code you would otherwise be copying and pasting is correct. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On 30/10/12 23:24, Michał Górny wrote: On Tue, 30 Oct 2012 20:17:25 +0100 Fabian Groffen wrote: On 30-10-2012 19:08:39 +, Samuli Suominen wrote: Added: udev.eclass Log: New eclass to determine udevdir from udev.pc pkg-config file as requested by many people, without ML review due to unproductive feedback Uhm... Please, stop doing this! Also, please notice the ChangeLog file you are ignoring. Only every second person is using the ChangeLog in eclass/ as pointed out and discussed in this ML for so many times it's ridicilous. Even direct contact with the people ignoring the ChangeLog in eclass/ has not changed their behavior. Some have replied something in line with "make repoman, or other post commit hook work in eclass directory if you want consistent behavior for the file" The file is pointless if not everyone is using it. I've offered to remove the file before, and I'm reoffering to do so now. And I'm not going to discuss this again, it's been vetted dozens of times here already to no result. So this is my last mail on that subject. - Samuli
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On 30/10/12 23:16, Fabian Groffen wrote: On 30-10-2012 15:47:51 -0500, Doug Goldstein wrote: On Tue, Oct 30, 2012 at 2:17 PM, Fabian Groffen wrote: On 30-10-2012 19:08:39 +, Samuli Suominen wrote: Added: udev.eclass Log: New eclass to determine udevdir from udev.pc pkg-config file as requested by many people, without ML review due to unproductive feedback Uhm... Please, stop doing this! Stop the bike shedding. Provide real constructive improvements. I'm not copying and pasting the same hunk of code in a bunch of ebuilds. We just have policies. It is a bad habit to believe one is not affected by them. Samuli just introduced an eclass for which he had to make at least two commits now right after its introduction to fix issues, and still it has incorrect code, that should be fixed. (So far he just ignored the issue.) One of the commits was before anything was said to ML (the EAPI change), the comment was later but the commenter didn't notice it just got fixed minutes before that. I didn't ignore anything, but pointed this thread and the comments to mgorny since the exact same EPREFIX code is in systemd.eclass too. If you think this is incorrect, I would expect prefix@ maintainers to provide a patch to correct it. And as I already pointed out, i'll be reusing the internal function later on in the ebuild just like systemd.eclass does, like for example, $(udev_do_rules_d) function. We discussed also the conversion from echo to printf and saw it unnecessary. So exactly what is (your) problem with the current eclass now?
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On Tue, 30 Oct 2012 20:17:25 +0100 Fabian Groffen wrote: > On 30-10-2012 19:08:39 +, Samuli Suominen wrote: > > Added: udev.eclass > > Log: > > New eclass to determine udevdir from udev.pc pkg-config file as requested > > by many people, without ML review due to unproductive feedback > > Uhm... > Please, stop doing this! Also, please notice the ChangeLog file you are ignoring. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, Oct 30, 2012 at 4:59 PM, Samuli Suominen wrote: > > On 30/10/12 22:49, Michael Mol wrote: >> >> On Tue, Oct 30, 2012 at 4:45 PM, Diego Elio Pettenò >> mailto:flamee...@flameeyes.eu>> wrote: >> >> On 30/10/2012 13:39, Michael Mol wrote: >> > In general, I agree...but Boost wasn't intended to be a shared >> library, >> > so there shouldn't be a conflict there. >> >> But there are shared libraries, and they are not small either. And >> I'd >> rather, say, hunt an RWX section problem (a security problem) with a >> single shared library rather than having to hunt it down in a dozen >> or so. >> >> Besides, honestly it's not that bad. I think that half the headache >> that >> we're having is due to the slotting more than from boost itself. And >> the >> other half is due to people actually not going to fix their crap >> because >> "oh I can just use the older version" (until a new compiler or C >> library >> comes out). >> >> I've had to do my share of porting to newer boost — and as I said >> most >> of the headaches have been for the build system to find the object, >> rather than anything else. >> >> >> Thank you. That was enlightening. :) > > > Please remove HTML from your e-mail clients settings, at least for this > mailing list. It's unreadable. Apologies; didn't even realize it was enabled. Incidentally can you forward a screenshot to me so I can see exactly how poorly it integrated with your normal settings? I don't expect I can get GMail to take a bug report, but if its HTML emails are setting things like fixed sizes, that's something that needs to be brought up. (I certainly wasn't copy/pasting or setting _anything_ manually. I avoid that as much as possible.) -- :wq
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On 30-10-2012 15:47:51 -0500, Doug Goldstein wrote: > On Tue, Oct 30, 2012 at 2:17 PM, Fabian Groffen wrote: > > On 30-10-2012 19:08:39 +, Samuli Suominen wrote: > >> Added: udev.eclass > >> Log: > >> New eclass to determine udevdir from udev.pc pkg-config file as > >> requested by many people, without ML review due to unproductive feedback > > > > Uhm... > > Please, stop doing this! > > Stop the bike shedding. Provide real constructive improvements. I'm > not copying and pasting the same hunk of code in a bunch of ebuilds. We just have policies. It is a bad habit to believe one is not affected by them. Samuli just introduced an eclass for which he had to make at least two commits now right after its introduction to fix issues, and still it has incorrect code, that should be fixed. (So far he just ignored the issue.) I wouldn't classify the feedback he got as "unproductive" at all. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/12 22:49, Michael Mol wrote: On Tue, Oct 30, 2012 at 4:45 PM, Diego Elio Pettenò mailto:flamee...@flameeyes.eu>> wrote: On 30/10/2012 13:39, Michael Mol wrote: > In general, I agree...but Boost wasn't intended to be a shared library, > so there shouldn't be a conflict there. But there are shared libraries, and they are not small either. And I'd rather, say, hunt an RWX section problem (a security problem) with a single shared library rather than having to hunt it down in a dozen or so. Besides, honestly it's not that bad. I think that half the headache that we're having is due to the slotting more than from boost itself. And the other half is due to people actually not going to fix their crap because "oh I can just use the older version" (until a new compiler or C library comes out). I've had to do my share of porting to newer boost — and as I said most of the headaches have been for the build system to find the object, rather than anything else. Thank you. That was enlightening. :) Please remove HTML from your e-mail clients settings, at least for this mailing list. It's unreadable.
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, Oct 30, 2012 at 4:45 PM, Diego Elio Pettenò wrote: > On 30/10/2012 13:39, Michael Mol wrote: > > In general, I agree...but Boost wasn't intended to be a shared library, > > so there shouldn't be a conflict there. > > But there are shared libraries, and they are not small either. And I'd > rather, say, hunt an RWX section problem (a security problem) with a > single shared library rather than having to hunt it down in a dozen or so. > > Besides, honestly it's not that bad. I think that half the headache that > we're having is due to the slotting more than from boost itself. And the > other half is due to people actually not going to fix their crap because > "oh I can just use the older version" (until a new compiler or C library > comes out). > > I've had to do my share of porting to newer boost — and as I said most > of the headaches have been for the build system to find the object, > rather than anything else. > Thank you. That was enlightening. :) -- :wq
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On Tue, Oct 30, 2012 at 2:17 PM, Fabian Groffen wrote: > On 30-10-2012 19:08:39 +, Samuli Suominen wrote: >> Added: udev.eclass >> Log: >> New eclass to determine udevdir from udev.pc pkg-config file as requested >> by many people, without ML review due to unproductive feedback > > Uhm... > Please, stop doing this! > > > -- Stop the bike shedding. Provide real constructive improvements. I'm not copying and pasting the same hunk of code in a bunch of ebuilds. -- Doug Goldstein
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 13:39, Michael Mol wrote: > In general, I agree...but Boost wasn't intended to be a shared library, > so there shouldn't be a conflict there. But there are shared libraries, and they are not small either. And I'd rather, say, hunt an RWX section problem (a security problem) with a single shared library rather than having to hunt it down in a dozen or so. Besides, honestly it's not that bad. I think that half the headache that we're having is due to the slotting more than from boost itself. And the other half is due to people actually not going to fix their crap because "oh I can just use the older version" (until a new compiler or C library comes out). I've had to do my share of porting to newer boost — and as I said most of the headaches have been for the build system to find the object, rather than anything else. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, Oct 30, 2012 at 4:26 PM, Diego Elio Pettenò wrote: > On 30/10/2012 12:31, Michael Mol wrote: > > > > I've never understood why Gentoo uses a separate ebuild for it. I mean, > > I can understand some efficiency gains from having a single compiled > > copy, but it shouldn't be surprising in the least when upstream makes > > breaking changes in the API. > > Because bundled libraries are bad. > In general, I agree...but Boost wasn't intended to be a shared library, so there shouldn't be a conflict there. Now, I understand that it's supremely convenient to be able to fix a bug in one place, rather than grep and patch that bug in the source of all the other packages...but then you come back to messes spawning from upstream not treating that as a supported configuration. Though since I'm not contributing labor (apart from the five minutes to write this email), I probably don't really have the right perspective. -- :wq
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 13:10, Michał Górny wrote: > By inheriting boost-utils and using the correct function to use older > boost slot? Which will not work. Can you build boost-1.49 with glibc-2.16? NO! At least not without patching it by changing its API. So how do you propose to solve package A that doesn't build with boost-1.50? Depend on 1.49? Which then depends on http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 13:04, Ian Stakenvicius wrote: > #1 - the MAX_BOOST_VERSION thing isn't needed anymore (and i get the > impression that it actually is, but putting that aside since i don't > maintain any packages that depend on boost), and It'll just behave like _every other library_ we have in the tree, as Samuli and Alexis already said. And it'll follow the same policy. > #2 - anything requiring boost gets bumped to EAPI5 to get the > slot-operator benefits for rebuilds, I'm not sure if it's strictly needed but it's fine. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 12:31, Michael Mol wrote: > > I've never understood why Gentoo uses a separate ebuild for it. I mean, > I can understand some efficiency gains from having a single compiled > copy, but it shouldn't be surprising in the least when upstream makes > breaking changes in the API. Because bundled libraries are bad. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass
On 30/10/12 22:18, Michał Górny wrote:
On Tue, 30 Oct 2012 17:08:07 -0300
Alexis Ballier wrote:
On Tue, 30 Oct 2012 21:57:11 +0200
Samuli Suominen wrote:
On 30/10/12 21:56, Alexis Ballier wrote:
On Tue, 30 Oct 2012 19:08:39 + (UTC)
"Samuli Suominen (ssuominen)" wrote:
[...]
case ${EAPI:-0} in
0|1|2|3|4) ;;
*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
established." esac
sounds like a useless and annoying check for just exporting one
function
RDEPEND=""
useless?
if the ebuild is EAPI=0 or EAPI=1 then DEPEND expands to RDEPEND, so
setting empty RDEPEND prevents that, or am I missing something?
even with eclasses and inheritence ? maybe you're right but i wouldnt
bet anything
DEPEND="virtual/pkgconfig"
# @FUNCTION: _udev_get_udevdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed udevdir.
_udev_get_udevdir() {
if $($(tc-getPKG_CONFIG) --exists udev); then
echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
udev)" else
echo -n /lib/udev
fi
}
# @FUNCTION: udev_get_udevdir
# @DESCRIPTION:
# Output the path for the udev directory (not including ${D}).
# This function always succeeds, even if udev is not installed.
# The fallback value is set to /lib/udev
udev_get_udevdir() {
has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
debug-print-function ${FUNCNAME} "${@}"
echo -n "${EPREFIX}$(_udev_get_udevdir)"
}
local foo=""
unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
printf ...$foo
kill the extra internal fucntion that seems useless.
echo isn't really reliable for precise formatting, prefer printf
when it matters. (in this case it doesn't matter but seems good
practices)
have you checked what is the udevdir value on prefix, if at all
relevant ? I fear a double prefix issue.
the code is more or less same as systemd.eclass has, I don't want to
diverge too much from that since we are essentially dealing with the
same package (tarball)
well, two bad do not make a good
consider the above remarks to apply to systemd.eclass too then, and
either explain why they're not relevant or apply them to both eclasses
if you want to avoid divergence.
Don't even try to touch any of my eclasses without prior asking.
And the additional internal function there was used in order to get
unprefixed path for do*() and new*() functions.
same as i'll propably reuse the function for something like
$(do_udev_rules) later on
the udev.eclass might have one function now, but that's just a
rudementary start to drop most of the duplication from ebuilds
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass
On Tue, 30 Oct 2012 17:08:07 -0300
Alexis Ballier wrote:
> On Tue, 30 Oct 2012 21:57:11 +0200
> Samuli Suominen wrote:
>
> > On 30/10/12 21:56, Alexis Ballier wrote:
> > > On Tue, 30 Oct 2012 19:08:39 + (UTC)
> > > "Samuli Suominen (ssuominen)" wrote:
> > >
> > > [...]
> > >>
> > >> case ${EAPI:-0} in
> > >> 0|1|2|3|4) ;;
> > >> *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> > >> established." esac
> > >
> > > sounds like a useless and annoying check for just exporting one
> > > function
> > >
> > >>
> > >> RDEPEND=""
> > >
> > > useless?
> >
> > if the ebuild is EAPI=0 or EAPI=1 then DEPEND expands to RDEPEND, so
> > setting empty RDEPEND prevents that, or am I missing something?
>
> even with eclasses and inheritence ? maybe you're right but i wouldnt
> bet anything
>
> >
> > >
> > >> DEPEND="virtual/pkgconfig"
> > >>
> > >> # @FUNCTION: _udev_get_udevdir
> > >> # @INTERNAL
> > >> # @DESCRIPTION:
> > >> # Get unprefixed udevdir.
> > >> _udev_get_udevdir() {
> > >> if $($(tc-getPKG_CONFIG) --exists udev); then
> > >> echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
> > >> udev)" else
> > >> echo -n /lib/udev
> > >> fi
> > >> }
> > >>
> > >> # @FUNCTION: udev_get_udevdir
> > >> # @DESCRIPTION:
> > >> # Output the path for the udev directory (not including ${D}).
> > >> # This function always succeeds, even if udev is not installed.
> > >> # The fallback value is set to /lib/udev
> > >> udev_get_udevdir() {
> > >> has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> > >> debug-print-function ${FUNCNAME} "${@}"
> > >>
> > >> echo -n "${EPREFIX}$(_udev_get_udevdir)"
> > >> }
> > >
> > > local foo=""
> > > unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
> > > printf ...$foo
> > >
> > > kill the extra internal fucntion that seems useless.
> > > echo isn't really reliable for precise formatting, prefer printf
> > > when it matters. (in this case it doesn't matter but seems good
> > > practices)
> > >
> > > have you checked what is the udevdir value on prefix, if at all
> > > relevant ? I fear a double prefix issue.
> > >
> >
> > the code is more or less same as systemd.eclass has, I don't want to
> > diverge too much from that since we are essentially dealing with the
> > same package (tarball)
>
> well, two bad do not make a good
> consider the above remarks to apply to systemd.eclass too then, and
> either explain why they're not relevant or apply them to both eclasses
> if you want to avoid divergence.
Don't even try to touch any of my eclasses without prior asking.
And the additional internal function there was used in order to get
unprefixed path for do*() and new*() functions.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, 30 Oct 2012 16:02:59 -0400 Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 30/10/12 04:00 PM, Alexis Ballier wrote: > > On Tue, 30 Oct 2012 15:56:21 -0400 Ian Stakenvicius > > wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > >> > >> On 30/10/12 03:45 PM, Tomáš Chvátal wrote: > >>> Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a): > On Tue, 30 Oct 2012 11:30:16 -0700 > > Diego Elio Pettenò wrote: > >> > > > So given that it's a PITA for the maintainers, a PITA for > > the users, eselect boost has been shown to be a bad idea > > and so on ... can we just go back to just install it and > > that's about it? > > How are you going to solve the issue of a lot of packages > being broken with new boost versions? Are you volunteering to > keep fixing them with each release? > >>> > >>> Simple, as any other lib, depend on older version and possibly > >>> port it forward. If that does not work then mask and wipe. Life > >>> goes on. > >>> > >> > >> If we un-slot boost there won't be an 'older' version available > >> on users systems anymore; when the new boost hits ~arch and then > >> stable, all ~arch / stable rdeps will -need- to build against > >> that version of boost, period (or be lastrite'd as ssuominen > >> suggested) unless i'm missing your meaning here? > > > > a sane pm wont try to upgrade to version 5 if <5 is required by > > some package. > > > > +1 for unslotting > > > > ..until something else ~arch (or stable) in the tree -needs- >=5 (and > we only need one fairly common package for that to happen), and then > it all falls apart with same-slot conflicts. > the good solution is obviously to keep it masked while proactively fixing packages and then unmask it. then there is absolutely no problem and that's what is generally done for other libraries.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass
On 30/10/12 22:06, Ian Stakenvicius wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/10/12 03:56 PM, Alexis Ballier wrote:
On Tue, 30 Oct 2012 19:08:39 + (UTC) "Samuli Suominen
(ssuominen)" wrote:
[...]
case ${EAPI:-0} in 0|1|2|3|4) ;; *) die "${ECLASS}.eclass API in
EAPI ${EAPI} not yet established." esac
sounds like a useless and annoying check for just exporting one
function
Also we have EAPI=5 now, so that check needs to be expanded.
already done :)
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, 30 Oct 2012 12:32:57 -0700 Diego Elio Pettenò wrote: > On 30/10/2012 12:24, Michał Górny wrote: > > How are you going to solve the issue of a lot of packages being broken > > with new boost versions? Are you volunteering to keep fixing them with > > each release? > > How are you going to solve the problem that the packages that are not > fixed to work with a new boost are not going to work anyway because > boost.m4 will still get the latest one, and most of the old ones > wouldn't work anyway because they are not compatible with the compiler/C > library/whatever? By inheriting boost-utils and using the correct function to use older boost slot? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/12 22:02, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/10/12 04:00 PM, Alexis Ballier wrote: On Tue, 30 Oct 2012 15:56:21 -0400 Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/10/12 03:45 PM, Tomáš Chvátal wrote: Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a): On Tue, 30 Oct 2012 11:30:16 -0700 Diego Elio Pettenò wrote: So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? Simple, as any other lib, depend on older version and possibly port it forward. If that does not work then mask and wipe. Life goes on. If we un-slot boost there won't be an 'older' version available on users systems anymore; when the new boost hits ~arch and then stable, all ~arch / stable rdeps will -need- to build against that version of boost, period (or be lastrite'd as ssuominen suggested) unless i'm missing your meaning here? a sane pm wont try to upgrade to version 5 if <5 is required by some package. +1 for unslotting ..until something else ~arch (or stable) in the tree -needs- >=5 (and we only need one fairly common package for that to happen), and then it all falls apart with same-slot conflicts. the new boost will be p.masked for long as every package in tree has been fixed for it, or masked for lastrite the policy is same as for any other package, can't set < dependencies on the same stabilization level that would cause same-slot conflicts so no problem there
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass
On Tue, 30 Oct 2012 21:57:11 +0200
Samuli Suominen wrote:
> On 30/10/12 21:56, Alexis Ballier wrote:
> > On Tue, 30 Oct 2012 19:08:39 + (UTC)
> > "Samuli Suominen (ssuominen)" wrote:
> >
> > [...]
> >>
> >> case ${EAPI:-0} in
> >>0|1|2|3|4) ;;
> >>*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> >> established." esac
> >
> > sounds like a useless and annoying check for just exporting one
> > function
> >
> >>
> >> RDEPEND=""
> >
> > useless?
>
> if the ebuild is EAPI=0 or EAPI=1 then DEPEND expands to RDEPEND, so
> setting empty RDEPEND prevents that, or am I missing something?
even with eclasses and inheritence ? maybe you're right but i wouldnt
bet anything
>
> >
> >> DEPEND="virtual/pkgconfig"
> >>
> >> # @FUNCTION: _udev_get_udevdir
> >> # @INTERNAL
> >> # @DESCRIPTION:
> >> # Get unprefixed udevdir.
> >> _udev_get_udevdir() {
> >>if $($(tc-getPKG_CONFIG) --exists udev); then
> >>echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
> >> udev)" else
> >>echo -n /lib/udev
> >>fi
> >> }
> >>
> >> # @FUNCTION: udev_get_udevdir
> >> # @DESCRIPTION:
> >> # Output the path for the udev directory (not including ${D}).
> >> # This function always succeeds, even if udev is not installed.
> >> # The fallback value is set to /lib/udev
> >> udev_get_udevdir() {
> >>has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> >>debug-print-function ${FUNCNAME} "${@}"
> >>
> >>echo -n "${EPREFIX}$(_udev_get_udevdir)"
> >> }
> >
> > local foo=""
> > unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
> > printf ...$foo
> >
> > kill the extra internal fucntion that seems useless.
> > echo isn't really reliable for precise formatting, prefer printf
> > when it matters. (in this case it doesn't matter but seems good
> > practices)
> >
> > have you checked what is the udevdir value on prefix, if at all
> > relevant ? I fear a double prefix issue.
> >
>
> the code is more or less same as systemd.eclass has, I don't want to
> diverge too much from that since we are essentially dealing with the
> same package (tarball)
well, two bad do not make a good
consider the above remarks to apply to systemd.eclass too then, and
either explain why they're not relevant or apply them to both eclasses
if you want to avoid divergence.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/10/12 03:56 PM, Alexis Ballier wrote:
> On Tue, 30 Oct 2012 19:08:39 + (UTC) "Samuli Suominen
> (ssuominen)" wrote:
>
> [...]
>>
>> case ${EAPI:-0} in 0|1|2|3|4) ;; *) die "${ECLASS}.eclass API in
>> EAPI ${EAPI} not yet established." esac
>
> sounds like a useless and annoying check for just exporting one
> function
>
Also we have EAPI=5 now, so that check needs to be expanded.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlCQMz0ACgkQ2ugaI38ACPBuuwD+MCMAnbp3d8O/rnTdhNe/W/KW
qIipm9jLbGDf5Hc9w+QBALmbJDmeOc7KUcGellrNFGRS5xWhjhhG9M0z5gb370XR
=WHxK
-END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass
On 30-10-2012 16:56:21 -0300, Alexis Ballier wrote:
> > # @FUNCTION: _udev_get_udevdir
> > # @INTERNAL
> > # @DESCRIPTION:
> > # Get unprefixed udevdir.
> > _udev_get_udevdir() {
> > if $($(tc-getPKG_CONFIG) --exists udev); then
> > echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
> > udev)" else
> > echo -n /lib/udev
> > fi
> > }
> >
> > # @FUNCTION: udev_get_udevdir
> > # @DESCRIPTION:
> > # Output the path for the udev directory (not including ${D}).
> > # This function always succeeds, even if udev is not installed.
> > # The fallback value is set to /lib/udev
> > udev_get_udevdir() {
> > has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> > debug-print-function ${FUNCNAME} "${@}"
> >
> > echo -n "${EPREFIX}$(_udev_get_udevdir)"
> > }
>
> local foo=""
> unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
> printf ...$foo
>
> kill the extra internal fucntion that seems useless.
> echo isn't really reliable for precise formatting, prefer printf when
> it matters. (in this case it doesn't matter but seems good practices)
echo -n is not always working, but in this case no point in using it at
all.
> have you checked what is the udevdir value on prefix, if at all
> relevant ? I fear a double prefix issue.
I definitely share your concern. (_udev_get_udevdir has a broken
implementation, given its contract per documentation)
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/10/12 02:30 PM, Diego Elio Pettenò wrote: > Given the amount of headaches that Boost seems to give us all, now > thanks to the recent changes even more because Gentoo's boost is > different from all others and no upstream default check seem to > work correctly with it, I'm questioning the usefulness of having it > slotted. > > Among other things, with each GCC/GLIBC update all but a handful > of slots are kept working; in this case I think most if not all > <1.50 are broken. > > So given that it's a PITA for the maintainers, a PITA for the > users, eselect boost has been shown to be a bad idea and so on ... > can we just go back to just install it and that's about it? > > Thanks, As log as: #1 - the MAX_BOOST_VERSION thing isn't needed anymore (and i get the impression that it actually is, but putting that aside since i don't maintain any packages that depend on boost), and #2 - anything requiring boost gets bumped to EAPI5 to get the slot-operator benefits for rebuilds, ..seems to make sense to me also. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlCQMtYACgkQ2ugaI38ACPANHgEAkEFD/m87xg3KY6pzazUSqmZT MWxLJDgC1sy8GlYeEzUA/iIdCu0pPOC90FUMSXP2tjCgZeiGu/OmjM0iJa4rtPUi =FgJE -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Dropping slotted boost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/10/12 04:00 PM, Alexis Ballier wrote: > On Tue, 30 Oct 2012 15:56:21 -0400 Ian Stakenvicius > wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> On 30/10/12 03:45 PM, Tomáš Chvátal wrote: >>> Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a): On Tue, 30 Oct 2012 11:30:16 -0700 Diego Elio Pettenò wrote: >> > So given that it's a PITA for the maintainers, a PITA for > the users, eselect boost has been shown to be a bad idea > and so on ... can we just go back to just install it and > that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? >>> >>> Simple, as any other lib, depend on older version and possibly >>> port it forward. If that does not work then mask and wipe. Life >>> goes on. >>> >> >> If we un-slot boost there won't be an 'older' version available >> on users systems anymore; when the new boost hits ~arch and then >> stable, all ~arch / stable rdeps will -need- to build against >> that version of boost, period (or be lastrite'd as ssuominen >> suggested) unless i'm missing your meaning here? > > a sane pm wont try to upgrade to version 5 if <5 is required by > some package. > > +1 for unslotting > ..until something else ~arch (or stable) in the tree -needs- >=5 (and we only need one fairly common package for that to happen), and then it all falls apart with same-slot conflicts. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlCQMnMACgkQ2ugaI38ACPAfSAD/d4PZXfXVhZRFaG+fVCa64vYn r7MbrM6QH/pwadKWDpYBAIfyeLGjroVxVwwOpmozkL6GBxLPTIgAMfMu9Fbe/zYw =f3Oe -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass
On 30/10/12 21:56, Alexis Ballier wrote:
On Tue, 30 Oct 2012 19:08:39 + (UTC)
"Samuli Suominen (ssuominen)" wrote:
[...]
case ${EAPI:-0} in
0|1|2|3|4) ;;
*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
established." esac
sounds like a useless and annoying check for just exporting one function
RDEPEND=""
useless?
if the ebuild is EAPI=0 or EAPI=1 then DEPEND expands to RDEPEND, so
setting empty RDEPEND prevents that, or am I missing something?
DEPEND="virtual/pkgconfig"
# @FUNCTION: _udev_get_udevdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed udevdir.
_udev_get_udevdir() {
if $($(tc-getPKG_CONFIG) --exists udev); then
echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
udev)" else
echo -n /lib/udev
fi
}
# @FUNCTION: udev_get_udevdir
# @DESCRIPTION:
# Output the path for the udev directory (not including ${D}).
# This function always succeeds, even if udev is not installed.
# The fallback value is set to /lib/udev
udev_get_udevdir() {
has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
debug-print-function ${FUNCNAME} "${@}"
echo -n "${EPREFIX}$(_udev_get_udevdir)"
}
local foo=""
unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
printf ...$foo
kill the extra internal fucntion that seems useless.
echo isn't really reliable for precise formatting, prefer printf when
it matters. (in this case it doesn't matter but seems good practices)
have you checked what is the udevdir value on prefix, if at all
relevant ? I fear a double prefix issue.
the code is more or less same as systemd.eclass has, I don't want to
diverge too much from that since we are essentially dealing with the
same package (tarball)
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, 30 Oct 2012 15:56:21 -0400 Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 30/10/12 03:45 PM, Tomáš Chvátal wrote: > > Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a): > >> On Tue, 30 Oct 2012 11:30:16 -0700 > >> > >> Diego Elio Pettenò wrote: > > >> > >>> So given that it's a PITA for the maintainers, a PITA for the > >>> users, eselect boost has been shown to be a bad idea and so on > >>> ... can we just go back to just install it and that's about > >>> it? > >> > >> How are you going to solve the issue of a lot of packages being > >> broken with new boost versions? Are you volunteering to keep > >> fixing them with each release? > > > > Simple, as any other lib, depend on older version and possibly port > > it forward. If that does not work then mask and wipe. Life goes > > on. > > > > If we un-slot boost there won't be an 'older' version available on > users systems anymore; when the new boost hits ~arch and then stable, > all ~arch / stable rdeps will -need- to build against that version of > boost, period (or be lastrite'd as ssuominen suggested) unless > i'm missing your meaning here? a sane pm wont try to upgrade to version 5 if <5 is required by some package. +1 for unslotting
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass
On Tue, 30 Oct 2012 19:08:39 + (UTC)
"Samuli Suominen (ssuominen)" wrote:
[...]
>
> case ${EAPI:-0} in
> 0|1|2|3|4) ;;
> *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> established." esac
sounds like a useless and annoying check for just exporting one function
>
> RDEPEND=""
useless?
> DEPEND="virtual/pkgconfig"
>
> # @FUNCTION: _udev_get_udevdir
> # @INTERNAL
> # @DESCRIPTION:
> # Get unprefixed udevdir.
> _udev_get_udevdir() {
> if $($(tc-getPKG_CONFIG) --exists udev); then
> echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
> udev)" else
> echo -n /lib/udev
> fi
> }
>
> # @FUNCTION: udev_get_udevdir
> # @DESCRIPTION:
> # Output the path for the udev directory (not including ${D}).
> # This function always succeeds, even if udev is not installed.
> # The fallback value is set to /lib/udev
> udev_get_udevdir() {
> has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> debug-print-function ${FUNCNAME} "${@}"
>
> echo -n "${EPREFIX}$(_udev_get_udevdir)"
> }
local foo=""
unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
printf ...$foo
kill the extra internal fucntion that seems useless.
echo isn't really reliable for precise formatting, prefer printf when
it matters. (in this case it doesn't matter but seems good practices)
have you checked what is the udevdir value on prefix, if at all
relevant ? I fear a double prefix issue.
Re: [gentoo-dev] [RFC] Dropping slotted boost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/10/12 03:45 PM, Tomáš Chvátal wrote: > Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a): >> On Tue, 30 Oct 2012 11:30:16 -0700 >> >> Diego Elio Pettenò wrote: >> >>> So given that it's a PITA for the maintainers, a PITA for the >>> users, eselect boost has been shown to be a bad idea and so on >>> ... can we just go back to just install it and that's about >>> it? >> >> How are you going to solve the issue of a lot of packages being >> broken with new boost versions? Are you volunteering to keep >> fixing them with each release? > > Simple, as any other lib, depend on older version and possibly port > it forward. If that does not work then mask and wipe. Life goes > on. > If we un-slot boost there won't be an 'older' version available on users systems anymore; when the new boost hits ~arch and then stable, all ~arch / stable rdeps will -need- to build against that version of boost, period (or be lastrite'd as ssuominen suggested) unless i'm missing your meaning here? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlCQMOQACgkQ2ugaI38ACPCGAwEAi1Oe50EPF87hI11hUVkovcvM xs/DOoDXKkuxArfdKjQA/0AFMkOhITgb1QcSwisO6jGREewZgUt/XKNnoRP2bx7q =u7CM -END PGP SIGNATURE-
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On 30/10/12 21:17, Fabian Groffen wrote: On 30-10-2012 19:08:39 +, Samuli Suominen wrote: Added: udev.eclass Log: New eclass to determine udevdir from udev.pc pkg-config file as requested by many people, without ML review due to unproductive feedback Uhm... Please, stop doing this! http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-power/upower/upower-0.9.18.ebuild?r1=1.4&r2=1.5 Take a look at that for example what this eclass does -> Drops duplicated code, that's all
Re: [gentoo-dev] [RFC] Dropping slotted boost
Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a): > On Tue, 30 Oct 2012 11:30:16 -0700 > > Diego Elio Pettenò wrote: > > Given the amount of headaches that Boost seems to give us all, now > > thanks to the recent changes even more because Gentoo's boost is > > different from all others and no upstream default check seem to work > > correctly with it, I'm questioning the usefulness of having it slotted. > > Could you elaborate on that? I don't remember having problems with > boost.m4 or cmake's default checks unless I'm missing something which > is obvious to you. Michal, given my affiliation with libreoffice I am handling quite few sh*t about buildsystems there. Currently we have orcus/wps/visio and libreoffice itself checking for internal components of boost in the configure scripts. You basically want me to add 1 kB m4 file from some github site (aside from fact it is nicely licensed GPLv3) and change all those checks we have to confor with this m4 so they work again for Gentoo. Here let me put the emphasis on "FOR GENTOO" because no other distro on to this day had problem with the boost setup lo projects are using, and we include stuff like win and mac. My alternative for this work is to do this on gentoo side and add append cflags and libs in each pkg using the boost-utils eclass and again add more shit i have to maintain into each ebuild. > > > So given that it's a PITA for the maintainers, a PITA for the users, > > eselect boost has been shown to be a bad idea and so on ... can we just > > go back to just install it and that's about it? > > How are you going to solve the issue of a lot of packages being broken > with new boost versions? Are you volunteering to keep fixing them with > each release? Simple, as any other lib, depend on older version and possibly port it forward. If that does not work then mask and wipe. Life goes on. Do we have at least some good use case on split boost requirement? Tomas
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/12 21:24, Michał Górny wrote: On Tue, 30 Oct 2012 11:30:16 -0700 So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? That would be the job for the maintainers of the packages. If they don't fix it, they lastrite it. Simple as that. No reason to treat boost any different from, say, jpeg or libpng
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On 30/10/12 21:17, Fabian Groffen wrote: On 30-10-2012 19:08:39 +, Samuli Suominen wrote: Added: udev.eclass Log: New eclass to determine udevdir from udev.pc pkg-config file as requested by many people, without ML review due to unproductive feedback Uhm... Please, stop doing this! This was sent to ML before and after conversation with another base-system@ member at #gentoo-dev we agreed to go on with it. 20:39 <@Cardoe> ssuominen: That's why you don't ask the ML 20:39 <@Cardoe> Too many cooks 20:39 <@Cardoe> Just do Post feedback is still accepted and appericiated. And, dozens of ebuilds implement the exact same code already, this was just to stop the pointless duplication tree-wide.
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 12:24, Michał Górny wrote: > How are you going to solve the issue of a lot of packages being broken > with new boost versions? Are you volunteering to keep fixing them with > each release? How are you going to solve the problem that the packages that are not fixed to work with a new boost are not going to work anyway because boost.m4 will still get the latest one, and most of the old ones wouldn't work anyway because they are not compatible with the compiler/C library/whatever? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, Oct 30, 2012 at 3:24 PM, Michał Górny wrote: > On Tue, 30 Oct 2012 11:30:16 -0700 > Diego Elio Pettenò wrote: > > > Given the amount of headaches that Boost seems to give us all, now > > thanks to the recent changes even more because Gentoo's boost is > > different from all others and no upstream default check seem to work > > correctly with it, I'm questioning the usefulness of having it slotted. > > Could you elaborate on that? I don't remember having problems with > boost.m4 or cmake's default checks unless I'm missing something which > is obvious to you. > > > So given that it's a PITA for the maintainers, a PITA for the users, > > eselect boost has been shown to be a bad idea and so on ... can we just > > go back to just install it and that's about it? > > How are you going to solve the issue of a lot of packages being broken > with new boost versions? Are you volunteering to keep fixing them with > each release? > It's worth noting that Boost themselves recommend developers inline the code they want to use. I've never understood why Gentoo uses a separate ebuild for it. I mean, I can understand some efficiency gains from having a single compiled copy, but it shouldn't be surprising in the least when upstream makes breaking changes in the API. -- :wq
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, 30 Oct 2012 11:30:16 -0700 Diego Elio Pettenò wrote: > Given the amount of headaches that Boost seems to give us all, now > thanks to the recent changes even more because Gentoo's boost is > different from all others and no upstream default check seem to work > correctly with it, I'm questioning the usefulness of having it slotted. Could you elaborate on that? I don't remember having problems with boost.m4 or cmake's default checks unless I'm missing something which is obvious to you. > So given that it's a PITA for the maintainers, a PITA for the users, > eselect boost has been shown to be a bad idea and so on ... can we just > go back to just install it and that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On 30-10-2012 19:08:39 +, Samuli Suominen wrote: > Added: udev.eclass > Log: > New eclass to determine udevdir from udev.pc pkg-config file as requested > by many people, without ML review due to unproductive feedback Uhm... Please, stop doing this! -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
[gentoo-dev] [RFC] Dropping slotted boost
Given the amount of headaches that Boost seems to give us all, now thanks to the recent changes even more because Gentoo's boost is different from all others and no upstream default check seem to work correctly with it, I'm questioning the usefulness of having it slotted. Among other things, with each GCC/GLIBC update all but a handful of slots are kept working; in this case I think most if not all <1.50 are broken. So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? Thanks, -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: glibc-2.16 moving to ~arch
On 30/10/2012 10:46, Duncan wrote: > ... I've been running gnutls-3.x for some time (at one point it was > needed for the live-git pan I run), tho I had to remask gnutls-3.1.3 as I > experienced some problem (IDR what) with it. But I'm running 3.1.2 > without issue. I've been using gnutls-3 on one of my devsystems as well, it's just as you can see from a tracker that some software is still working properly. But today's screwup with libtasn1 3.0 shows that we really can't keep it masked much more. > What gnutls-3.1.x are you planning to unmask? Do I need to try 3.1.3 > again and file a bug (if there's not one filed already) if the problem > still exists, or is 3.1.2 good enough? Given that 3.1.2 is not in tree anymore there's no choice uh? Beside, I don't go masking micro versions around. If you think there's a problem with 3.1.3, please test and let us know as I haven't hit any (that's what I've been using myself, and testing the tinderbox against). > FWIW, I also recently did a full emerge --empty-tree @world too, so there > shouldn't be any hidden problems lurking around to bite on either > package, at least with my @world and USE flag combo, either. The only big problem we're going to hit as I said is that Boost 1.50-r1 and 1.51 don't use eselect boost any longer, which means that the reverse dependencies need to be updated. Scarabeus was looking into it earlier today, I was waiting to hear from him as I don't want to go near Boost in the near future if I can avoid it. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] Re: glibc-2.16 moving to ~arch
Diego Elio Pettenò posted on Tue, 30 Oct 2012 07:44:20 -0700 as excerpted: > On 30/10/2012 00:22, Mike Frysinger wrote: >> reminder: plan on landing this week. glibc-2.17 is in the process of >> shaking out upstream. > > *shrug* we've got the warning so it's fair for it to land. I recommend > people who're using ~arch to mask it on their systems for a short while > though, as we still have quite a few failures that haven't been solved — > but if they haven't been solved this month they'll require the > maintainer to stumble across them *hard*. > > https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.16 FWIW, I unmasked and have been running glibc-2.16 since a couple days after the earlier announcement. I had boost-1.50 unmasked and merged before trying glibc-2.16, so that wasn't a problem, and... > Speaking of which, I confirm my plan to unmask GnuTLS 3.1 for basically > the same reason. Upstream is moving on to new versions, we're behind one > major and one minor right now. > > https://bugs.gentoo.org/show_bug.cgi?id=gnutls-3 ... I've been running gnutls-3.x for some time (at one point it was needed for the live-git pan I run), tho I had to remask gnutls-3.1.3 as I experienced some problem (IDR what) with it. But I'm running 3.1.2 without issue. What gnutls-3.1.x are you planning to unmask? Do I need to try 3.1.3 again and file a bug (if there's not one filed already) if the problem still exists, or is 3.1.2 good enough? FWIW, I also recently did a full emerge --empty-tree @world too, so there shouldn't be any hidden problems lurking around to bite on either package, at least with my @world and USE flag combo, either. -- 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] About unresolved bugs assigned to mobile for ages
On Mon, 2012-10-29 at 09:50 +, Markos Chandras wrote: > On Sun, Oct 28, 2012 at 12:26 PM, Pacho Ramos wrote: > > Hello > > > > I would like to know about mobile team status and also show that this > > team has important bugs assigned to them for a long time, some of them > > with patches (and reporters angry because of seeing things untouched for > > a long time). > > > > If anyone has time to join to the team and help, nice, if the team needs > > to drop from some packages maintainership due lack of manpower, please > > tell us what packages do you want up for grabs. > > > > Thanks > > I don't believe anyone is active in the mobile herd anymore. Probably > the packages need to be > moved to maintainer-needed@ so individual developers can take care of them. > As far as I know, I'm the only one in the mobile herd (actually I think it's 3 of us total), and I don't have the hardware to even test some things with it anymore (e.g. pcmciautils - which REALLY needs a fix and some lovin from someone) - I'd definitely agree that the mobile herd could go away, or if some people wanted to join and help out, that would be greatly appreciated.
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On 30/10/2012 08:21, Rich Freeman wrote: > That might warrant a news item. Sure, they're ~arch, but they're not > going to know about this unless somebody tells them. Is it just my impression or did you just volunteer? ;) -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On Tue, Oct 30, 2012 at 10:44 AM, Diego Elio Pettenò wrote: > On 30/10/2012 00:22, Mike Frysinger wrote: >> reminder: plan on landing this week. glibc-2.17 is in the process of shaking >> out upstream. > > *shrug* we've got the warning so it's fair for it to land. I recommend > people who're using ~arch to mask it on their systems for a short while > though, as we still have quite a few failures that haven't been solved — That might warrant a news item. Sure, they're ~arch, but they're not going to know about this unless somebody tells them. Rich
[gentoo-dev] Re: spotify license
On 10/29/2012 03:32 PM, Matija Šuklje wrote:
> On Ponedeljek 29. of October 2012 15.52.20 Ulrich Mueller wrote:
>>> On Mon, 29 Oct 2012, Matthew Thode wrote:
>>> It's looking hard to be able to add the spotify ebuild to tree because
>>> of licensing concerns.
>>>
>>> http://www.spotify.com/us/legal/end-user-agreement/
>>
>> This concerns not so much the client software, but their "service" and
>> the contents provided through it.
>
> Well, the “Spotify Software” is included at least it §4 and also in general
> included in the “service” term. The license agreement is lacking though.
>
> In any case Gentoo can’t be the 3rd party here and therefore not redistribute
> it.
>
>>> 10:02 < prometheanfire > do you have a plaintext version? I can copy
>>> the text, but just thought I'd ask :D
>>> 10:02 < dan^spotify > No, and copy+pasting it into a text file isn't
>>> something we really want you to to do, since it changes from time-to-time
>>> 10:04 < prometheanfire > ok, I'll see what the proper course of action
>>> is, I think you have us accept the license on first start right?
>>> 10:04 < dan^spotify > Correct
>>> 10:04 < dan^spotify > Well, first login
>>> 10:05 < prometheanfire > just as good probably
>>> 10:05 < dan^spotify > If you've already accepted the most up-to-date
>>> license on another machine, you won't be prompted again
>>>
>>> https://bugs.gentoo.org/show_bug.cgi?id=373093
>>>
>>> They want it to be accepted through the app. Is there a way this is
>>> compatible with Gentoo?
>>
>> We need a plaintext license file for the client that we put in
>> ${PORTDIR}licenses/, so users can look at it before they install the
>> package.
>
> Yup.
>
> They probably deem §§ 3 and 4 to be the license, but it’s quite lacking IMHO.
> So since full copyright is default, this means that we’re not allowed to
> redistribute it. RESTRICT="mirror" we have to do here.
>
> As a sub-optimal solution, Rich’s idea to create a Spotify license and point
> the users to the actual EULA.
>
> But unless they clarify the software license for their *client*, I’d rather
> we
> don’t include it. Too messy.
>
>> Maybe it would make more sense to add one of the free alternatives?
>>
>>http://despotify.se/
>>https://gitorious.org/libopenspotify
>>
>> media-sound/despotify is already in Sunrise, bug 307795.
>
> Seems a better idea IMHO.
>
>
> cheers,
> Matija
>
> P.S. As Rich mentioned, the difference between a (real) license and “license
> agreement” is that a license grants you more rights then you get by law and
> therefore you don’t have to agree to it, since your rights are not
> diminished;
> a so called license agreement (EULA, ToS, whatever_agreement) has nothing to
> do with a (real) license apart from the falsely borrowed name and you have to
> agree with it, since your statutory rights are diminished/voided.
>
Got confirmation via irc that the license is for the client as well,
dunno if that's good enough...
--
-- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On 30/10/2012 00:22, Mike Frysinger wrote: > reminder: plan on landing this week. glibc-2.17 is in the process of shaking > out upstream. *shrug* we've got the warning so it's fair for it to land. I recommend people who're using ~arch to mask it on their systems for a short while though, as we still have quite a few failures that haven't been solved — but if they haven't been solved this month they'll require the maintainer to stumble across them *hard*. https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.16 Speaking of which, I confirm my plan to unmask GnuTLS 3.1 for basically the same reason. Upstream is moving on to new versions, we're behind one major and one minor right now. https://bugs.gentoo.org/show_bug.cgi?id=gnutls-3 -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Let's populate IUSE_IMPLICIT in the base profile
On Thursday 27 September 2012 12:02:58 Ian Stakenvicius wrote: > build is specifically for catalyst and/or for building the stages, > right? If so, this one makes sense to me to add. this is used in a few packages, but we should encourage trimming it rather than expanding. i see that the kernel & gcc account for the most usage. > bootstrap I would guess is similar? Unsure how that one is used at > present. If IUSE_IMPLICIT would still allow the boostrapping tool to > set the use flag, i see no issues having it in the list. bootstrap is used by two packages (gcc and freebsd-lib). in the gcc case, we should kill it. so this is not a flag we should be encouraging at all. file https://bugs.gentoo.org/440224 for killing both in gcc -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
On Monday 15 October 2012 13:45:22 Mike Frysinger wrote:
> On Monday 15 October 2012 11:20:19 Zac Medico wrote:
> > On 10/14/2012 09:22 PM, Mike Frysinger wrote:
> > > sounds like we should extend the profiles.desc file or profile
> > > structure to include a description so that people know the intention
> > > of each one. the only marker we had before was implicitly in the name
> > > (".../server" and ".../desktop").
> >
> > Maybe put a metadata.xml file in the profile directory. Then you can
> > list the description, maintainer, and anything else you want in there.
>
> SGTM. then we just update eselect to parse that if it's available.
https://bugs.gentoo.org/440220
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On Tuesday 02 October 2012 15:53:41 Mike Frysinger wrote: > On Friday 17 August 2012 23:31:36 Mike Frysinger wrote: > > with glibc-2.15 gone stable, it's time to get 2.16 in the pipe. the big > > issues have been sorted out already. there's a few packages still known > > to build fail, but they've had quite some time to sort their stuff out, > > so i don't see delaying further making a difference there. if anything, > > they'll be more inclined to get their stuff fixed ;). > > this will be happening by the end of October or when boost-1.50 is sorted > out. whichever comes first. reminder: plan on landing this week. glibc-2.17 is in the process of shaking out upstream. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About DESCRIPTION in ebuilds needing to end with a dot "."
On Friday 19 October 2012 15:01:57 Pacho Ramos wrote:
> At least in spanish, it's mandatory to end phrases with a dot ".", would
> you agree with trying to enforce this trivial change with a repoman
> warning?
actually the opposite here ... DESCRIPTION should be a sentence fragment, and
should avoid useless self referencing. such as starting with "${PN} is ...".
thanks, i can already connect the ${PN} to this description.
i clean that up (and delete the trailing dot) whenever i see it.
-mike
signature.asc
Description: This is a digitally signed message part.
