Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 14:45:55 -0700 Zac Medico wrote: > Can you explain how Exherbo is handling dbus-glib rebuilds after > glib:2 updates? Badly, most likely. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] x32 release candidate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/12 05:17, Mike Frysinger wrote: > On Wednesday 06 June 2012 15:40:18 Gregory M. Turner wrote: >>> i'm pleased to announce the initial x32 release candidate: >>> http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz >> >> Also pleased to hear this! Thanks! Can't wait to find the time to play >> with it. Did you do all that work yourself? > > H.J.Lu did all the real work in the relevant toolchain/kernel projects. i > merely did the distro integration. > >> Is there a wiki or forum thread somewhere where folks can gloat and/or >> commiserate? > > i haven't set up anything Shall we start a http://wiki.gentoo.org/wiki/amd64-x32 page? > -mike - -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/QRnwACgkQ6Ex4woTpDjTPhACdE6Xo4tJONuO6ZjsEaAU7k4pr QQ0AoN2yKaWZFPpVpcz+uzallp4gTV3M =0wnw -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 14:21:40 -0700 Zac Medico wrote: > > You'd have a slot per ABI, and be encouraged to allow multiple > > versions of glib to be installed in parallel. If you really > > couldn't do that (and you should think very carefully before saying > > you can't, since this directly affects users in a huge way), you > > can make the slots block each other. > > It seems like you're trying to make glib fit your SLOT operator model, > even though it's a natural fit for the ABI_SLOT operator model. No, I'm trying to strongly encourage people to make proper use of slots to avoid having mass breakages and annoyances on user systems, even if it means more work for developers. Broken linkage due to an upgrade really shouldn't happen. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] multiprocessing.eclass: doing parallel work in bash
On Tuesday 05 June 2012 02:14:36 Mike Frysinger wrote: > v4 committed with test cases -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] x32 release candidate
On Wednesday 06 June 2012 15:40:18 Gregory M. Turner wrote: > > i'm pleased to announce the initial x32 release candidate: > > http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz > > Also pleased to hear this! Thanks! Can't wait to find the time to play > with it. Did you do all that work yourself? H.J.Lu did all the real work in the relevant toolchain/kernel projects. i merely did the distro integration. > Is there a wiki or forum thread somewhere where folks can gloat and/or > commiserate? i haven't set up anything -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: > On Wed, 06 Jun 2012 21:16:05 +0200 > Pacho Ramos wrote: >> Well, I think reading this thread is more or less clear what it would >> be supposed to do, also Zac suggested it and looks to have an idea >> about what should it do. > > There's a big leap from "more or less clear" and "an idea" to the kind > of knowledge we want to have. Think REQUIRED_USE for how this can go > wrong... > > If you think ABI_SLOT is essential, why not try implementing it and > trying it out in a large number of packages, and reporting your results? It's pretty close to the SLOT operator model, and it seems like it should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, and test it in an overlay before we include it in the final EAPI 5. -- Thanks, Zac
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
On 06/06/2012 02:59 PM, Brian Harring wrote: > On Tue, Jun 05, 2012 at 07:18:01PM -0700, Zac Medico wrote: >> On 06/05/2012 05:51 PM, Michael Weber wrote: >>> Is there any chance to detect this ZLIB_VERSION problem with >>> revdep-rebuild (worst case: add a list of possibly broken packages >>> with tests)? >> >> I'd suggest a special ebuild phase to check for ABI changes, like the >> pre_pkg_preinst_abi_check phase suggested here: >> >> https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 > > Same thing I said in '07; I don't have a problem w/ hooks for ebuilds > to specify additional QA checks, but this *cannot* be the user's end > solution- it needs to be purely for making it easier for devs to spot > their screwups. In other words, revdep-rebuild shouldn't be involved; > this should spot/complain that zlib (for example) changed abi w/out a > matching metadata setting/whatever, rather than having checks done in > the consumers. > > Using this for anything other than a QA check of the originating > package, basically has an end result of us going towards a > non-deterministic resolution model- which is a clusterfuck, frankly. Yeah, I'm sure we can all agree that we would like the dependency resolver to be able to predict/display all of the rebuilds that will need to occur, before any building starts. -- Thanks, Zac
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
On Tue, Jun 05, 2012 at 07:18:01PM -0700, Zac Medico wrote: > On 06/05/2012 05:51 PM, Michael Weber wrote: > > Is there any chance to detect this ZLIB_VERSION problem with > > revdep-rebuild (worst case: add a list of possibly broken packages > > with tests)? > > I'd suggest a special ebuild phase to check for ABI changes, like the > pre_pkg_preinst_abi_check phase suggested here: > > https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 Same thing I said in '07; I don't have a problem w/ hooks for ebuilds to specify additional QA checks, but this *cannot* be the user's end solution- it needs to be purely for making it easier for devs to spot their screwups. In other words, revdep-rebuild shouldn't be involved; this should spot/complain that zlib (for example) changed abi w/out a matching metadata setting/whatever, rather than having checks done in the consumers. Using this for anything other than a QA check of the originating package, basically has an end result of us going towards a non-deterministic resolution model- which is a clusterfuck, frankly. ~harring
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 10:19 AM, Ciaran McCreesh wrote: > On Wed, 06 Jun 2012 10:32:08 +0200 > Pacho Ramos wrote: >>> We do? Please tell us. I was under the impression that we still >>> didn't fully know what the problem was. >> >> Well, could you please let me know how to handle some issues already >> mentioned? For example: >> - Rebuild dbus-glib and gobject-introspection after major glib update. >> - Rebuild x11 drivers after xorg-update > > Those are the ones we probably do understand. You just up the SLOT (and > if you really need to, use blockers between slots, although this is > discouraged in favour of writing better ebuilds), and everything that > build+run-deps upon these things uses := dependencies. Can you explain how Exherbo is handling dbus-glib rebuilds after glib:2 updates? It seems that dbus-glib is not using a SLOT operator for its glib:2 dependency: http://git.exherbo.org/summer/packages/dev-libs/dbus-glib/index.html -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 10:16 AM, Ciaran McCreesh wrote: > On Wed, 06 Jun 2012 11:48:26 +0200 > Pacho Ramos wrote: >> That looks nice, only two notes: >> - Looks like would be more sense on distinguish between "SLOT" and >> ABI_SLOT, for example: >> * dbus-glib would rdepend on glib:2 >> * if glib:2 abi changes, we would pull a ABI_SLOT="2.32" >> inside glib-2 ebuild >> * dbus-glib rdepending on glib:=2 would get rebuilt >> If we would use "SLOT" for all the cases, how would we handle it? I >> mean, glib slot would be bumped to "2.32" and dbus-glib ebuilds >> updated to rdepend on every new slot? Or would package managers >> distinct between "versions" inside the same SLOT variable? > > You'd have a slot per ABI, and be encouraged to allow multiple versions > of glib to be installed in parallel. If you really couldn't do that > (and you should think very carefully before saying you can't, since > this directly affects users in a huge way), you can make the slots > block each other. It seems like you're trying to make glib fit your SLOT operator model, even though it's a natural fit for the ABI_SLOT operator model. -- Thanks, Zac
Re: [gentoo-dev] Lastrite: net-libs/xulrunner
On Wed, Jun 06, 2012 at 09:50:01PM +0300, Samuli Suominen wrote: > then when they do upgrade to new xulrunner, it's possible to package it > from firefox tarball > mozilla upstream doesn't support this, but some other distribs are > packaging it[1] > > [1] http://www.archlinux.org/packages/extra/x86_64/xulrunner/ > > but nothing in portage is requiring this, so -1 for packaging it from > me, as they should really upgrade to something else, like webkit-gtk... Can you run an app that relies on remotely served XUL under WebKit, on Windows, OSX, Linux with that? If so, I'll suggest it to upstream. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] x32 release candidate
Il 06/06/2012 21:40, Gregory M. Turner ha scritto: - Original Message - i'm pleased to announce the initial x32 release candidate: http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz Also pleased to hear this! Thanks! Can't wait to find the time to play with it. Did you do all that work yourself? Is there a wiki or forum thread somewhere where folks can gloat and/or commiserate? I'm cautiously hopeful/enthusiastic about x32's prospects and a prefix seems like a fantastic way to bootstrap a community which could blueprint "cheat sheets" for prospective binary package maintainers (potentially driving adoption -- at least in my fantasies -- in the Grandma Zone). -gmt seem LWN was pleased too: http://lwn.net/Articles/500482/ Congratulations for the achievement, this has been more than 7 month of work right? It would be very interesting to see were it goes. - Francesco
Re: [gentoo-dev] x32 release candidate
- Original Message - > i'm pleased to announce the initial x32 release candidate: > http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz Also pleased to hear this! Thanks! Can't wait to find the time to play with it. Did you do all that work yourself? Is there a wiki or forum thread somewhere where folks can gloat and/or commiserate? I'm cautiously hopeful/enthusiastic about x32's prospects and a prefix seems like a fantastic way to bootstrap a community which could blueprint "cheat sheets" for prospective binary package maintainers (potentially driving adoption -- at least in my fantasies -- in the Grandma Zone). -gmt
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 20:23 +0100, Ciaran McCreesh escribió: > On Wed, 06 Jun 2012 21:16:05 +0200 > Pacho Ramos wrote: > > Well, I think reading this thread is more or less clear what it would > > be supposed to do, also Zac suggested it and looks to have an idea > > about what should it do. > > There's a big leap from "more or less clear" and "an idea" to the kind > of knowledge we want to have. Think REQUIRED_USE for how this can go > wrong... > > If you think ABI_SLOT is essential, why not try implementing it and > trying it out in a large number of packages, and reporting your results? > Because I don't have the skills to do it myself signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 21:16:05 +0200 Pacho Ramos wrote: > Well, I think reading this thread is more or less clear what it would > be supposed to do, also Zac suggested it and looks to have an idea > about what should it do. There's a big leap from "more or less clear" and "an idea" to the kind of knowledge we want to have. Think REQUIRED_USE for how this can go wrong... If you think ABI_SLOT is essential, why not try implementing it and trying it out in a large number of packages, and reporting your results? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles
El mié, 06-06-2012 a las 14:53 -0400, Mike Frysinger escribió: > On Wednesday 06 June 2012 14:06:47 Pacho Ramos wrote: > > The problem is that grep keeps linked against libpcre and it can cause > > problems like pointed in referred bug report, and it's really risky as > > people can have their portage completely broken for example when libpcre > > is downgraded for some reason. That doesn't sound like a good *default* > > behavior for me > > there are plenty of core tools that can be broken by other packages forcing > broken behavior like library downgrades. I know that, but I am simply trying to get safer values that could help to minimize the risk a bit and, since enabling pcre system wide didn't look (and still don't look) really needed to me, I asked to stop enabling it to prevent this exact risk that looks major enough to me > and FEATURES=preserve-libs would > gracefully handle this. > > off the top of my head, lib dependencies that can bring a system down: > - bash links against ncurses & readline > - sed links against acl > - coreutils links against acl/libcap/selinux/gmp > - grep links against pcre > (with at least USE=acl being a profile default) > > so highlighting the grep/pcre dep doesn't seem like it accomplishes much > -mike I am not trying to reach the safest and unbreakable update path that won't ever fail as explained at top ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 19:33 +0100, Ciaran McCreesh escribió: > On Wed, 06 Jun 2012 20:30:52 +0200 > Pacho Ramos wrote: > > > > Also, how could this be handled in dbus-glib side? I mean, would > > > > we need to update dbus-glib update from RDEPENDing on glib:2.30 to > > > > glib:2.32? :O > > > > > > Noo. You'd use := dependencies, possibly with a >= constraint. > > > > But, what would occur if we have three slots (for example gtk+), and > > app needs to RDEPEND on slot 2? How would we set it to use every 2.* > > SLOT and not >=2? > > Then you'd need range dependencies. > > > Also, what is the reason to try to skip "ABI_SLOT" way? > > No-one's ever implemented it, or knows how it works, or knows what > exactly it's supposed to do. The only advantage ABI_SLOT has is that we > don't know what its limitations are, other than that it doesn't > solve any new problems (although it might slightly simplify certain > specific cases, maybe). Well, I think reading this thread is more or less clear what it would be supposed to do, also Zac suggested it and looks to have an idea about what should it do. In summary: we would still need to use a "top layer" SLOT for packages really being able to be parallel installed and those that need to be parallel installable because reverse dependencies doesn't work with latest version (like glib, libgda, gtk+...). ABI_SLOT would be more "internal" to allow portage managers to know that abi changed and reverse dependencies would need a later rebuild. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrite: net-libs/xulrunner
On 06/06/2012 08:28 PM, Robin H. Johnson wrote: On Wed, Jun 06, 2012 at 04:19:58PM +0300, Samuli Suominen wrote: # Samuli Suominen (06 Jun 2012) # Vulnerable and no longer used by anything in tree wrt #403415 # Removal in 30 days What do we do about other apps that are XULRunner based, and NOT yet updated by upstream to the new xulrunner (it actually depends on remote XUL loading that got removed in newer versions too). (In my case, http://open-ils.org/) we don't do anything, but you can keep on using it by copying the ebuild to your local overlay (don't forget distfiles) then when they do upgrade to new xulrunner, it's possible to package it from firefox tarball mozilla upstream doesn't support this, but some other distribs are packaging it[1] [1] http://www.archlinux.org/packages/extra/x86_64/xulrunner/ but nothing in portage is requiring this, so -1 for packaging it from me, as they should really upgrade to something else, like webkit-gtk...
Re: [gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles
On Wednesday 06 June 2012 14:06:47 Pacho Ramos wrote: > The problem is that grep keeps linked against libpcre and it can cause > problems like pointed in referred bug report, and it's really risky as > people can have their portage completely broken for example when libpcre > is downgraded for some reason. That doesn't sound like a good *default* > behavior for me there are plenty of core tools that can be broken by other packages forcing broken behavior like library downgrades. and FEATURES=preserve-libs would gracefully handle this. off the top of my head, lib dependencies that can bring a system down: - bash links against ncurses & readline - sed links against acl - coreutils links against acl/libcap/selinux/gmp - grep links against pcre (with at least USE=acl being a profile default) so highlighting the grep/pcre dep doesn't seem like it accomplishes much -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 20:30:52 +0200 Pacho Ramos wrote: > > > Also, how could this be handled in dbus-glib side? I mean, would > > > we need to update dbus-glib update from RDEPENDing on glib:2.30 to > > > glib:2.32? :O > > > > Noo. You'd use := dependencies, possibly with a >= constraint. > > But, what would occur if we have three slots (for example gtk+), and > app needs to RDEPEND on slot 2? How would we set it to use every 2.* > SLOT and not >=2? Then you'd need range dependencies. > Also, what is the reason to try to skip "ABI_SLOT" way? No-one's ever implemented it, or knows how it works, or knows what exactly it's supposed to do. The only advantage ABI_SLOT has is that we don't know what its limitations are, other than that it doesn't solve any new problems (although it might slightly simplify certain specific cases, maybe). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 19:15 +0100, Ciaran McCreesh escribió: > On Wed, 06 Jun 2012 20:02:24 +0200 > Pacho Ramos wrote: > > Probably other gnome team could reply this better than me, but I don't > > think slotting every glib-2 due ABI changes deserves the huge effort. > > Think of the users. I am thinking on them (well, I started this thread because I was thinking as a user). > > > Also, we want people to rebuild them against, for example, glib-2.32 > > ABI, not to keep glib-2.30 and 2.32 installed in parallel and some > > packages built against 2.30 and others against 2.32. > > Well, you can do that if you really want... > > > Also, how could this be handled in dbus-glib side? I mean, would we > > need to update dbus-glib update from RDEPENDing on glib:2.30 to > > glib:2.32? :O > > Noo. You'd use := dependencies, possibly with a >= constraint. > But, what would occur if we have three slots (for example gtk+), and app needs to RDEPEND on slot 2? How would we set it to use every 2.* SLOT and not >=2? Also, what is the reason to try to skip "ABI_SLOT" way? It would have some advantages, and would allow us to make ABI_SLOTs mutually exclusive by default (as most cases would need) instead of needing to move this "mutual exclussion" on every ebuild needing to use SLOTs for ABI bumps. It looks cleaner to me over being constraint to SLOT :| signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 20:02:24 +0200 Pacho Ramos wrote: > Probably other gnome team could reply this better than me, but I don't > think slotting every glib-2 due ABI changes deserves the huge effort. Think of the users. > Also, we want people to rebuild them against, for example, glib-2.32 > ABI, not to keep glib-2.30 and 2.32 installed in parallel and some > packages built against 2.30 and others against 2.32. Well, you can do that if you really want... > Also, how could this be handled in dbus-glib side? I mean, would we > need to update dbus-glib update from RDEPENDing on glib:2.30 to > glib:2.32? :O Noo. You'd use := dependencies, possibly with a >= constraint. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles
El mié, 06-06-2012 a las 13:23 -0400, Mike Frysinger escribió: > On Wednesday 06 June 2012 04:26:11 Pacho Ramos wrote: > > I think that would be interesting to try to not get grep build with pcre > > support by default, specially after reading "man grep" and seeing that > > its support is tagged as experimental: > >-P, --perl-regexp > > Interpret PATTERN as a Perl regular expression. This is > > highly > > experimental and grep -P may warn of unimplemented > > features. > > the experimental aspect doesn't matter. don't use -P and it isn't an issue. > > personally, i don't care about pcre. > -mike The problem is that grep keeps linked against libpcre and it can cause problems like pointed in referred bug report, and it's really risky as people can have their portage completely broken for example when libpcre is downgraded for some reason. That doesn't sound like a good *default* behavior for me Of course, other option would be to default to "-pcre" for grep only (by default), but I don't know if we really want every package to have pcre by default... signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 18:19 +0100, Ciaran McCreesh escribió: > On Wed, 06 Jun 2012 10:32:08 +0200 > Pacho Ramos wrote: > > > We do? Please tell us. I was under the impression that we still > > > didn't fully know what the problem was. > > > > Well, could you please let me know how to handle some issues already > > mentioned? For example: > > - Rebuild dbus-glib and gobject-introspection after major glib update. > > - Rebuild x11 drivers after xorg-update > > Those are the ones we probably do understand. You just up the SLOT (and > if you really need to, use blockers between slots, although this is > discouraged in favour of writing better ebuilds), and everything that > build+run-deps upon these things uses := dependencies. > > > - Rebuild python/perl/ocaml stuff after python/perl/ocaml update > > That depends. If you only have to do it after an upgrade, same > solution. If you have to do it with a rebuild too, then that's one of > the situations I claim we don't fully understand because no-one has > specified what the exact general problem is (although lots of people > have looked at one particular case and assumed that their case holds > for everything, which isn't true). > I think they are only needed on upgrades, not rebuilds, but I cannot assure that, probably their maintainers will know better :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 18:16 +0100, Ciaran McCreesh escribió: > On Wed, 06 Jun 2012 11:48:26 +0200 > Pacho Ramos wrote: > > That looks nice, only two notes: > > - Looks like would be more sense on distinguish between "SLOT" and > > ABI_SLOT, for example: > > * dbus-glib would rdepend on glib:2 > > * if glib:2 abi changes, we would pull a ABI_SLOT="2.32" > > inside glib-2 ebuild > > * dbus-glib rdepending on glib:=2 would get rebuilt > > If we would use "SLOT" for all the cases, how would we handle it? I > > mean, glib slot would be bumped to "2.32" and dbus-glib ebuilds > > updated to rdepend on every new slot? Or would package managers > > distinct between "versions" inside the same SLOT variable? > > You'd have a slot per ABI, and be encouraged to allow multiple versions > of glib to be installed in parallel. If you really couldn't do that > (and you should think very carefully before saying you can't, since > this directly affects users in a huge way), you can make the slots > block each other. Probably other gnome team could reply this better than me, but I don't think slotting every glib-2 due ABI changes deserves the huge effort. Also, we want people to rebuild them against, for example, glib-2.32 ABI, not to keep glib-2.30 and 2.32 installed in parallel and some packages built against 2.30 and others against 2.32. Also, how could this be handled in dbus-glib side? I mean, would we need to update dbus-glib update from RDEPENDing on glib:2.30 to glib:2.32? :O > > > - What would occur with packages forced to use eapi0 due backwards > > compat? We could probably deprecate eapis older than 5 to allow all > > the tree be consistent with this rebuilds forcing, but no idea what > > to do with system packages still needing to use eapi0 and maybe > > changing their ABI too :/ > > The situation for older packages remains the same. > Maybe we have a third option that could allow us to not use ABI_SLOT if you prefer: - eapi5 could allow the usage of depending on multiple slots, for example, dbus-glib would RDEPEND on dev-libs/glib:2.*:= Then, we would have dev-libs/glib:2.30 and dev-libs/glib:2.32, both mutually exclusive but ebuilds RDEPENDing on them not needing to be updated on every abi bump due them really working for both ABIs. - Package managers would still rebuild all apps with that ":=" syntax - We would be able to skip ABI_SLOT needing - If a package is RDEPENDing on an old eapi0 package, that package could still use SLOT="2.32" or "2.30" and eapi5 ebuild rdepending on it still behaving in the same way. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrite: net-libs/xulrunner
On Wed, Jun 06, 2012 at 04:19:58PM +0300, Samuli Suominen wrote: > # Samuli Suominen (06 Jun 2012) > # Vulnerable and no longer used by anything in tree wrt #403415 > # Removal in 30 days > http://open-ils.org/) -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles
On Wednesday 06 June 2012 04:26:11 Pacho Ramos wrote: > I think that would be interesting to try to not get grep build with pcre > support by default, specially after reading "man grep" and seeing that > its support is tagged as experimental: >-P, --perl-regexp > Interpret PATTERN as a Perl regular expression. This is > highly > experimental and grep -P may warn of unimplemented > features. the experimental aspect doesn't matter. don't use -P and it isn't an issue. personally, i don't care about pcre. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 10:32:08 +0200 Pacho Ramos wrote: > > We do? Please tell us. I was under the impression that we still > > didn't fully know what the problem was. > > Well, could you please let me know how to handle some issues already > mentioned? For example: > - Rebuild dbus-glib and gobject-introspection after major glib update. > - Rebuild x11 drivers after xorg-update Those are the ones we probably do understand. You just up the SLOT (and if you really need to, use blockers between slots, although this is discouraged in favour of writing better ebuilds), and everything that build+run-deps upon these things uses := dependencies. > - Rebuild python/perl/ocaml stuff after python/perl/ocaml update That depends. If you only have to do it after an upgrade, same solution. If you have to do it with a rebuild too, then that's one of the situations I claim we don't fully understand because no-one has specified what the exact general problem is (although lots of people have looked at one particular case and assumed that their case holds for everything, which isn't true). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 11:48:26 +0200 Pacho Ramos wrote: > That looks nice, only two notes: > - Looks like would be more sense on distinguish between "SLOT" and > ABI_SLOT, for example: > * dbus-glib would rdepend on glib:2 > * if glib:2 abi changes, we would pull a ABI_SLOT="2.32" > inside glib-2 ebuild > * dbus-glib rdepending on glib:=2 would get rebuilt > If we would use "SLOT" for all the cases, how would we handle it? I > mean, glib slot would be bumped to "2.32" and dbus-glib ebuilds > updated to rdepend on every new slot? Or would package managers > distinct between "versions" inside the same SLOT variable? You'd have a slot per ABI, and be encouraged to allow multiple versions of glib to be installed in parallel. If you really couldn't do that (and you should think very carefully before saying you can't, since this directly affects users in a huge way), you can make the slots block each other. > - What would occur with packages forced to use eapi0 due backwards > compat? We could probably deprecate eapis older than 5 to allow all > the tree be consistent with this rebuilds forcing, but no idea what > to do with system packages still needing to use eapi0 and maybe > changing their ABI too :/ The situation for older packages remains the same. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce prune_libtool_files().
On Tue, 5 Jun 2012 02:00:34 -0400 Mike Frysinger wrote: > if no one else has feedback, i guess merge it /var/cvsroot/gentoo-x86/eclass/ChangeLog,v <-- ChangeLog new revision: 1.291; previous revision: 1.290 /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v <-- eutils.eclass new revision: 1.395; previous revision: 1.394 -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Lastrite: =thunderbird-3.1*, enigmail, replytolist, cxterm
On 06/06/2012 05:12 PM, Duncan wrote: Samuli Suominen posted on Wed, 06 Jun 2012 15:37:17 +0300 as excerpted: # Jory A. Pratt (06 Jun 2012) # Upstream discontinued security support for 3.6 series. # If you still need these, now is the time to copy them # Enigmail now installed with thunderbird with crypt useflag. # to your local overlay. # Masked for removal in 30 days. =mail-client/thunderbird-3.1* x11-plugins/enigmail x11-plugins/replytolist What happened with the enigmail sentence there? Seems to be inserted in the middle of the copy-to-overlay sentence. Yes, I've noticed same, and the grammar is now fixed in tree.
Re: [gentoo-dev] Lastrite: net-libs/xulrunner
On 06/06/2012 05:07 PM, Ulrich Mueller wrote: On Wed, 06 Jun 2012, Samuli Suominen wrote: # Samuli Suominen (06 Jun 2012) # Vulnerable and no longer used by anything in tree wrt #403415 # Removal in 30 days Why a version dependent mask? There's nothing>2.0.1-r1 in the tree. Ulrich I've seen overlays with >=net-libs/xulrunner-10.0 snatched from the firefox tarball. So just trying to be polite towards people doing so...
Re: [gentoo-dev] Lastrite: net-libs/xulrunner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/06/12 10:07 AM, Ulrich Mueller wrote: >> On Wed, 06 Jun 2012, Samuli Suominen wrote: > >> # Samuli Suominen (06 Jun 2012) # >> Vulnerable and no longer used by anything in tree wrt #403415 # >> Removal in 30 days > Why a version dependent mask? There's nothing >2.0.1-r1 in the > tree. > > Ulrich > Other distros are distributing xulrunner-10, I expect the mask is there because gentoo might do so as well soon, if/when the need arises. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/PaGIACgkQ2ugaI38ACPD4NgEAqa4brrpI8MIwZZn5b/Z9HEU2 FpUTwn8cVQAs8kbZKd8A/ityigdTOoYv76fslXOV0KtLN+8sJRc7kcmixjSJoyzb =atcw -END PGP SIGNATURE-
[gentoo-dev] Re: Lastrite: =thunderbird-3.1*, enigmail, replytolist, cxterm
Samuli Suominen posted on Wed, 06 Jun 2012 15:37:17 +0300 as excerpted: > # Jory A. Pratt (06 Jun 2012) > # Upstream discontinued security support for 3.6 series. > # If you still need these, now is the time to copy them > # Enigmail now installed with thunderbird with crypt useflag. > # to your local overlay. > # Masked for removal in 30 days. > =mail-client/thunderbird-3.1* > x11-plugins/enigmail > x11-plugins/replytolist What happened with the enigmail sentence there? Seems to be inserted in the middle of the copy-to-overlay sentence. -- 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] Lastrite: net-libs/xulrunner
> On Wed, 06 Jun 2012, Samuli Suominen wrote: > # Samuli Suominen (06 Jun 2012) > # Vulnerable and no longer used by anything in tree wrt #403415 > # Removal in 30 days > 2.0.1-r1 in the tree. Ulrich
[gentoo-dev] Lastrite: net-libs/xulrunner
# Samuli Suominen (06 Jun 2012) # Vulnerable and no longer used by anything in tree wrt #403415 # Removal in 30 days
[gentoo-dev] Lastrite: =thunderbird-3.1*, enigmail, replytolist, cxterm
# Jory A. Pratt (06 Jun 2012) # Upstream discontinued security support for 3.6 series. # If you still need these, now is the time to copy them # Enigmail now installed with thunderbird with crypt useflag. # to your local overlay. # Masked for removal in 30 days. =mail-client/thunderbird-3.1* x11-plugins/enigmail x11-plugins/replytolist # Samuli Suominen (01 Jun 2012) # Fails to run with font issues wrt bug 418259 # Last release was back in 2003 # Removal in 30 days x11-terms/cxterm
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 02:48 AM, Pacho Ramos wrote: > El mié, 06-06-2012 a las 02:17 -0700, Zac Medico escribió: >> On 06/06/2012 01:28 AM, Pacho Ramos wrote: >>> El mar, 05-06-2012 a las 16:07 -0700, Zac Medico escribió: The "SLOT operator" dependencies that Ciaran has been advocating are very close to a good solution. However, if we want it to work with unslotted packages, then we need to introduce a separate ABI_SLOT variable as discussed here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 It's really no more difficult to do than "SLOT operator" dependencies, it's more flexible, and we can do it in EAPI 5. >>> >>> In that case, I obviously wouldn't have any problem with that approach >>> (it sound even better :)). Is there any place where I could get a bit >>> more documentation about how this "SLOT operator" way would work? For >>> example, how would work for rebuilding x11 drivers after updating xorg >>> or rebuilding gobject-introspection after major glib update... >> >> Whenever you have an ABI change, the developer doing the version bump >> needs to increment the SLOT (or ABI_SLOT if we use a separate variable) >> in the package. Packages that depend on the package with the ABI change >> (reverse dependencies) append a := operator to their dependency atoms, >> indicating that they are locked to the ABI of the SLOT that they are >> built against. The package manager translates the := operators into a >> dependencies on specific SLOTs at build time, so that when you update >> your system next time, it can use this information to trigger rebuilds >> automatically when necessary. > > That looks nice, only two notes: > - Looks like would be more sense on distinguish between "SLOT" and > ABI_SLOT, for example: > * dbus-glib would rdepend on glib:2 > * if glib:2 abi changes, we would pull a ABI_SLOT="2.32" inside glib-2 > ebuild > * dbus-glib rdepending on glib:=2 would get rebuilt > If we would use "SLOT" for all the cases, how would we handle it? I > mean, glib slot would be bumped to "2.32" and dbus-glib ebuilds updated > to rdepend on every new slot? Or would package managers distinct between > "versions" inside the same SLOT variable? For this situation, it seems like it's easier to have separate SLOT and ABI_SLOT entities. Maybe the dbus-glib dependency would be expressed as glib:2:= and the package manager would translate that to glib:2:2.32 at build time. So, the atom has separate SLOT and ABI_SLOT parts. > - What would occur with packages forced to use eapi0 due backwards > compat? We could probably deprecate eapis older than 5 to allow all the > tree be consistent with this rebuilds forcing, but no idea what to do > with system packages still needing to use eapi0 and maybe changing their > ABI too :/ All EAPIs have SLOT, so at least the reverse dependencies on these system packages would be able to use SLOT operator deps. It's also conceivable that ABI_SLOT support could be retroactively added to older EAPIs. Obviously, the SLOT operator := dependencies themselves can only be used in new EAPIs, so you won't be able to use them until you're willing to bump the EAPI of your package. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 02:17 -0700, Zac Medico escribió: > On 06/06/2012 01:28 AM, Pacho Ramos wrote: > > El mar, 05-06-2012 a las 16:07 -0700, Zac Medico escribió: > >> The "SLOT operator" dependencies that Ciaran has been advocating are > >> very close to a good solution. However, if we want it to work with > >> unslotted packages, then we need to introduce a separate ABI_SLOT > >> variable as discussed here: > >> > >> https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 > >> > >> It's really no more difficult to do than "SLOT operator" dependencies, > >> it's more flexible, and we can do it in EAPI 5. > > > > In that case, I obviously wouldn't have any problem with that approach > > (it sound even better :)). Is there any place where I could get a bit > > more documentation about how this "SLOT operator" way would work? For > > example, how would work for rebuilding x11 drivers after updating xorg > > or rebuilding gobject-introspection after major glib update... > > Whenever you have an ABI change, the developer doing the version bump > needs to increment the SLOT (or ABI_SLOT if we use a separate variable) > in the package. Packages that depend on the package with the ABI change > (reverse dependencies) append a := operator to their dependency atoms, > indicating that they are locked to the ABI of the SLOT that they are > built against. The package manager translates the := operators into a > dependencies on specific SLOTs at build time, so that when you update > your system next time, it can use this information to trigger rebuilds > automatically when necessary. That looks nice, only two notes: - Looks like would be more sense on distinguish between "SLOT" and ABI_SLOT, for example: * dbus-glib would rdepend on glib:2 * if glib:2 abi changes, we would pull a ABI_SLOT="2.32" inside glib-2 ebuild * dbus-glib rdepending on glib:=2 would get rebuilt If we would use "SLOT" for all the cases, how would we handle it? I mean, glib slot would be bumped to "2.32" and dbus-glib ebuilds updated to rdepend on every new slot? Or would package managers distinct between "versions" inside the same SLOT variable? - What would occur with packages forced to use eapi0 due backwards compat? We could probably deprecate eapis older than 5 to allow all the tree be consistent with this rebuilds forcing, but no idea what to do with system packages still needing to use eapi0 and maybe changing their ABI too :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 02:10 AM, Pacho Ramos wrote: > El mié, 06-06-2012 a las 01:54 -0700, Zac Medico escribió: > On 06/06/2012 01:46 AM, Pacho Ramos wrote: El mar, 05-06-2012 a las 19:18 -0700, Zac Medico escribió: > On 06/05/2012 05:51 PM, Michael Weber wrote: >> Is there any chance to detect this ZLIB_VERSION problem with >> revdep-rebuild (worst case: add a list of possibly broken >> packages with tests)? > > I'd suggest a special ebuild phase to check for ABI changes, like > the pre_pkg_preinst_abi_check phase suggested here: > > https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 I guess, that phase would detect ABI change and package manager would know how to handle it by itself? > > Yeah, it would be like a warning system, do detect cases when the > SLOT/ABI_SLOT were not bumped when they should have been. The idea is > that the developer who's doing the version bump will see the warning > and bump the SLOT/ABI_SLOT before committing the ebuild. >> >> > > And once we bump SLOT/ABI_SLOT, package manager would know about how to > handle that situation and rebuild needed stuff? Right, as long as the reverse dependencies use the := "SLOT operator" like they're supposed to. That's how they let the package manager know that they'll need to be rebuilt when the ABI changes. > If we use SLOT only, I guess we would need to allow (or make more > common) pulling multiple slot but all of them mutually exclusive no? Yeah, blockers are already used like this sometimes, like for google-chrome which has mutually exclusive stable, beta, and unstable SLOTs. > I > have no problem with that of course, but I thought it wasn't "desired" > in general. Well, we can always introduce a separate ABI_SLOT variable in a later EAPI, if we want. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 01:28 AM, Pacho Ramos wrote: > El mar, 05-06-2012 a las 16:07 -0700, Zac Medico escribió: >> The "SLOT operator" dependencies that Ciaran has been advocating are >> very close to a good solution. However, if we want it to work with >> unslotted packages, then we need to introduce a separate ABI_SLOT >> variable as discussed here: >> >> https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 >> >> It's really no more difficult to do than "SLOT operator" dependencies, >> it's more flexible, and we can do it in EAPI 5. > > In that case, I obviously wouldn't have any problem with that approach > (it sound even better :)). Is there any place where I could get a bit > more documentation about how this "SLOT operator" way would work? For > example, how would work for rebuilding x11 drivers after updating xorg > or rebuilding gobject-introspection after major glib update... Whenever you have an ABI change, the developer doing the version bump needs to increment the SLOT (or ABI_SLOT if we use a separate variable) in the package. Packages that depend on the package with the ABI change (reverse dependencies) append a := operator to their dependency atoms, indicating that they are locked to the ABI of the SLOT that they are built against. The package manager translates the := operators into a dependencies on specific SLOTs at build time, so that when you update your system next time, it can use this information to trigger rebuilds automatically when necessary. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 01:54 -0700, Zac Medico escribió: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/06/2012 01:46 AM, Pacho Ramos wrote: > > El mar, 05-06-2012 a las 19:18 -0700, Zac Medico escribió: > >> On 06/05/2012 05:51 PM, Michael Weber wrote: > >>> Is there any chance to detect this ZLIB_VERSION problem with > >>> revdep-rebuild (worst case: add a list of possibly broken > >>> packages with tests)? > >> > >> I'd suggest a special ebuild phase to check for ABI changes, like > >> the pre_pkg_preinst_abi_check phase suggested here: > >> > >> https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 > > > > I guess, that phase would detect ABI change and package manager > > would know how to handle it by itself? > > Yeah, it would be like a warning system, do detect cases when the > SLOT/ABI_SLOT were not bumped when they should have been. The idea is > that the developer who's doing the version bump will see the warning > and bump the SLOT/ABI_SLOT before committing the ebuild. > - -- > Thanks, > Zac > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.19 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk/PGt4ACgkQ/ejvha5XGaMt8QCffullYkU7EQXeE7TeUri4nQya > ysIAoMhPQT+rEZbxKNvMiX8qNOEndiM1 > =V7Tz > -END PGP SIGNATURE- > > And once we bump SLOT/ABI_SLOT, package manager would know about how to handle that situation and rebuild needed stuff? If we use SLOT only, I guess we would need to allow (or make more common) pulling multiple slot but all of them mutually exclusive no? I have no problem with that of course, but I thought it wasn't "desired" in general. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/06/2012 01:46 AM, Pacho Ramos wrote: > El mar, 05-06-2012 a las 19:18 -0700, Zac Medico escribió: >> On 06/05/2012 05:51 PM, Michael Weber wrote: >>> Is there any chance to detect this ZLIB_VERSION problem with >>> revdep-rebuild (worst case: add a list of possibly broken >>> packages with tests)? >> >> I'd suggest a special ebuild phase to check for ABI changes, like >> the pre_pkg_preinst_abi_check phase suggested here: >> >> https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 > > I guess, that phase would detect ABI change and package manager > would know how to handle it by itself? Yeah, it would be like a warning system, do detect cases when the SLOT/ABI_SLOT were not bumped when they should have been. The idea is that the developer who's doing the version bump will see the warning and bump the SLOT/ABI_SLOT before committing the ebuild. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/PGt4ACgkQ/ejvha5XGaMt8QCffullYkU7EQXeE7TeUri4nQya ysIAoMhPQT+rEZbxKNvMiX8qNOEndiM1 =V7Tz -END PGP SIGNATURE-
Re: [gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles
El mié, 06-06-2012 a las 10:37 +0200, "Paweł Hajdan, Jr." escribió: > On 6/6/12 10:26 AM, Pacho Ramos wrote: > > After reading: > > https://bugs.gentoo.org/show_bug.cgi?id=419795 > > > > I think that would be interesting to try to not get grep build with pcre > > support by default, specially after reading "man grep" and seeing that > > its support is tagged as experimental: > > This is more a reason to mask USE=pcre for grep, rather than taking > global action, where pcre may have different meaning or status for other > packages. > I thought about that option at first time, but later I checked grep ChangeLog and saw "pcre" USE flag was dropped time ago but later readded due user request. > > Also, at least of my systems there are only a few installed packages > > with this USE flag and, then, I am unsure about real advantage of having > > it enabled by default :-/ > > This is a possible reason for dropping it, but I'm not sure. What > exactly uses it and why? > > Paweł > In my laptop, just now, only a few: $ equery hasuse pcre * Searching for USE flag pcre ... [IP-] [ ] app-admin/syslog-ng-3.2.5:0 [IP-] [ ] dev-lang/swig-2.0.4-r1:0 [IP-] [ ] dev-libs/rasqal-0.9.28:0 [IP-] [ ] sys-apps/grep-2.9:0 but running it with "-p" shows me there are a lot that I don't know if their support deserves to be enabled by default :( signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
El mar, 05-06-2012 a las 19:18 -0700, Zac Medico escribió: > On 06/05/2012 05:51 PM, Michael Weber wrote: > > Is there any chance to detect this ZLIB_VERSION problem with > > revdep-rebuild (worst case: add a list of possibly broken packages > > with tests)? > > I'd suggest a special ebuild phase to check for ABI changes, like the > pre_pkg_preinst_abi_check phase suggested here: > > https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 I guess, that phase would detect ABI change and package manager would know how to handle it by itself? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 02:51 +0200, Michael Weber escribió: [...] > > [1] if you forget the -X on module-rebuild, you might no longer have > the virtualbox-modules version installed in the tree (no packages > satisfy ...). virtualbox does remove old versions real quick. > > The fun part comes with non-root users trying to log in: Yeah, I also had a similar problem with nvidia-drivers, maybe module-rebuild should default to "-X" behavior, or is there any reason why forcing the current behavior is better? Do we really should support by default setups that don't apply all updates (neither locally mask unwanted newer versions) after syncing their tree? > > [2] You've updated nvidia-drivers (kernel module providers in general) > userland and kernel modules, but forget to `rmmod nvidia`, or you > can't without terminating user sessions, it impossible to start new X > servers due to version mismatch between userland and kernel (applies > for virtualbox as well) > Maybe if we were able to call "rmmod -w nvidia" from nvidia-drivers ebuild... that way, once you log out from X, old module would be outloaded and new one loaded by X when restarting. The problem is that there is no way to run this command after emerge "automatically" > [3] You've updated zlib, but failed to recognize it in the emerge -av > output. You get angry reports about broken luatex and inkscape > (imagemagik) because of some nasty zlib abi version mismatch, hidden > from revdep-rebuild. > > [5] lafilefixer (funny) I am not sure if this is still needed these days :-/, at least portage looks to fix them, but I think this is not supported on other PMs (or maybe they handle this other way apart from lafilefixer also) > [4] python-updater (rare) > [6] ocaml gets broken after update w/o lablgl rebuild > https://bugs.gentoo.org/385869 > > Well, I'm lazy, and do this in the backgound, half asleep. > And I admit that [1] and [2] are my faults, but [3] is very annoying > (just like libdl related stuff) and esp. kernel+module updates take a > lot more than just a few 'REBUILD' packages. > > Is there any chance to detect this ZLIB_VERSION problem with > revdep-rebuild (worst case: add a list of possibly broken packages > with tests)? > > = > > I understand the urge for `eupdate` but that needs an agreement on > the implementation, and I see some rought edges here, where unattended > script magic most likely fails. > > Michael -- half asleep > > - -- > Gentoo Dev > http://xmw.de/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles
On 6/6/12 10:26 AM, Pacho Ramos wrote: > After reading: > https://bugs.gentoo.org/show_bug.cgi?id=419795 > > I think that would be interesting to try to not get grep build with pcre > support by default, specially after reading "man grep" and seeing that > its support is tagged as experimental: This is more a reason to mask USE=pcre for grep, rather than taking global action, where pcre may have different meaning or status for other packages. > Also, at least of my systems there are only a few installed packages > with this USE flag and, then, I am unsure about real advantage of having > it enabled by default :-/ This is a possible reason for dropping it, but I'm not sure. What exactly uses it and why? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 06:33 +0100, Ciaran McCreesh escribió: > On Tue, 05 Jun 2012 15:31:01 +0200 > Pacho Ramos wrote: > > We all know what would be the "ideal solution", the problem is how to > > implement it (and how many years we need to wait to get it working). > > We do? Please tell us. I was under the impression that we still didn't > fully know what the problem was. > Well, could you please let me know how to handle some issues already mentioned? For example: - Rebuild dbus-glib and gobject-introspection after major glib update. - Rebuild x11 drivers after xorg-update - Rebuild python/perl/ocaml stuff after python/perl/ocaml update Please take care I am simply asking your for information about how to handle it with the "SLOT operator" way or, at least, show me an example, because I don't know much about it. Thanks a lot for the info :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mar, 05-06-2012 a las 16:07 -0700, Zac Medico escribió: > On 06/05/2012 06:31 AM, Pacho Ramos wrote: > > El mar, 05-06-2012 a las 08:44 -0400, Aaron W. Swenson escribió: > >> The ideal solution is for the Ebuild to instruct the PMS to rebuild > >> the dependent packages. > >> > >> We can have a variable called REBUILD. All packages that would need to > >> be rebuilt can be listed in it. Only those packages that are installed > >> would be built. The actual list of the packages to be rebuilt would be > >> determined at dependency checking time. That way, the user can approve > >> the rebuild of the packages. > > > > We all know what would be the "ideal solution", the problem is how to > > implement it (and how many years we need to wait to get it working). > > This REBUILD variable is the first idea that pops into the head of > anyone who's never worked on a dependency resolver before. It's > backwards because it requires a package to have knowledge of *all* of > its reverse dependencies, and it should not need to know about *any* of > them. > > The "SLOT operator" dependencies that Ciaran has been advocating are > very close to a good solution. However, if we want it to work with > unslotted packages, then we need to introduce a separate ABI_SLOT > variable as discussed here: > > https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 > > It's really no more difficult to do than "SLOT operator" dependencies, > it's more flexible, and we can do it in EAPI 5. In that case, I obviously wouldn't have any problem with that approach (it sound even better :)). Is there any place where I could get a bit more documentation about how this "SLOT operator" way would work? For example, how would work for rebuilding x11 drivers after updating xorg or rebuilding gobject-introspection after major glib update... Thanks a lot for the info :) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles
After reading: https://bugs.gentoo.org/show_bug.cgi?id=419795 I think that would be interesting to try to not get grep build with pcre support by default, specially after reading "man grep" and seeing that its support is tagged as experimental: -P, --perl-regexp Interpret PATTERN as a Perl regular expression. This is highly experimental and grep -P may warn of unimplemented features. Also, at least of my systems there are only a few installed packages with this USE flag and, then, I am unsure about real advantage of having it enabled by default :-/ What do you think? signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH autotools] Support calling tools handled by gnome-autogen.sh.
This includes gtkdocize, gnome-doc-prepare & glib-gettextize.
---
gx86/eclass/autotools.eclass | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/gx86/eclass/autotools.eclass b/gx86/eclass/autotools.eclass
index 2d165e0..30f2ac5 100644
--- a/gx86/eclass/autotools.eclass
+++ b/gx86/eclass/autotools.eclass
@@ -165,10 +165,13 @@ eautoreconf() {
# Run all the tools before aclocal so we can gather the .m4 files.
local i tools=(
#
- gettext false "eautopoint --force"
+ glibgettext false "autotools_run_tool glib-gettextize --copy
--force"
+ gettext false "eautopoint --force"
# intltool must come after autopoint.
- intltool false "autotools_run_tool intltoolize --automake
--copy --force"
- libtool false "_elibtoolize --install --copy --force"
+ intltoolfalse "autotools_run_tool intltoolize --automake
--copy --force"
+ gtkdoc false "autotools_run_tool gtkdocize --copy"
+ gnomedocfalse "autotools_run_tool gnome-doc-prepare --copy
--force"
+ libtool false "_elibtoolize --install --copy --force"
)
for (( i = 0; i < ${#tools[@]}; i += 3 )) ; do
if _at_uses_${tools[i]} ; then
@@ -222,11 +225,14 @@ _at_uses_pkg() {
egrep -q "${args[@]}" configure.??
fi
}
-_at_uses_autoheader() { _at_uses_pkg AC_CONFIG_HEADERS; }
-_at_uses_automake() { _at_uses_pkg AM_INIT_AUTOMAKE; }
-_at_uses_gettext(){ _at_uses_pkg AM_GNU_GETTEXT_VERSION; }
-_at_uses_intltool() { _at_uses_pkg {AC,IT}_PROG_INTLTOOL; }
-_at_uses_libtool(){ _at_uses_pkg A{C,M}_PROG_LIBTOOL LT_INIT; }
+_at_uses_autoheader() { _at_uses_pkg AC_CONFIG_HEADERS; }
+_at_uses_automake(){ _at_uses_pkg AM_INIT_AUTOMAKE; }
+_at_uses_gettext() { _at_uses_pkg AM_GNU_GETTEXT_VERSION; }
+_at_uses_glibgettext() { _at_uses_pkg AM_GLIB_GNU_GETTEXT; }
+_at_uses_intltool(){ _at_uses_pkg {AC,IT}_PROG_INTLTOOL; }
+_at_uses_gtkdoc() { _at_uses_pkg GTK_DOC_CHECK; }
+_at_uses_gnomedoc(){ _at_uses_pkg GNOME_DOC_INIT; }
+_at_uses_libtool() { _at_uses_pkg A{C,M}_PROG_LIBTOOL LT_INIT; }
# @FUNCTION: eaclocal_amflags
# @DESCRIPTION:
@@ -462,8 +468,11 @@ ALL_AUTOTOOLS_MACROS=(
AC_CONFIG_SUBDIRS
AC_CONFIG_AUX_DIR AC_CONFIG_MACRO_DIR
AM_INIT_AUTOMAKE
+ AM_GLIB_GNU_GETTEXT
AM_GNU_GETTEXT_VERSION
{AC,IT}_PROG_INTLTOOL
+ GTK_DOC_CHECK
+ GNOME_DOC_INIT
)
autotools_check_macro() {
[[ -f configure.ac || -f configure.in ]] || return 0
--
1.7.10.2
