Re: [gentoo-dev] Re: Re: Lastrite: app-pda/libopensync and reverse dependencies
On Thursday 10 February 2011 22:57:41 Diego Elio Pettenò wrote: [snip] Repeat after me: Politeness and professional courtesy is an integral part of our QA team policy. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
[gentoo-dev] Downgrading glibc?
Hello! In relation to bug 354395 [1] I would like to downgrade my glibc back to 2.12.2. Portage doesn't allow me to do that: * Sanity check to keep you from breaking your system: * Downgrading glibc is not supported and a sure way to destruction * ERROR: sys-libs/glibc-2.12.2 failed (setup phase): * aborting to save your system Can anyone guide me or point me to a guide how to savely do that manually? Thanks, Sebastian [1] https://bugs.gentoo.org/show_bug.cgi?id=354395
[gentoo-dev] Re: Re: Re: Lastrite: app-pda/libopensync and reverse dependencies
Il giorno ven, 11/02/2011 alle 09.17 +0100, Andreas K. Huettel ha scritto: Repeat after me: Politeness and professional courtesy is an integral part of our QA team policy. Politeness is due where politeness is received. If you keep second-guessing QA team, without looking at the packages at all (see Samuli's mail) you're not going to receive any. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
[gentoo-dev] Re: Downgrading glibc?
Il giorno ven, 11/02/2011 alle 09.50 +0100, Sebastian Pipping ha scritto: Can anyone guide me or point me to a guide how to savely do that manually? There really isn't a safe way as soon as you built anything at all against the new version. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
[gentoo-dev] Re: Downgrading glibc?
Il giorno ven, 11/02/2011 alle 10.55 +0100, Michael Haubenwallner ha scritto: what do you think of working around the memcpy troubles with glibc-2.13 by simply redirecting memcpy to memmove within glibc, either unconditionally or optional/temporary (via USE-flag?) until everyone uses memmove where necessary? That unless things start crashing down nobody will fix the issues at all. We're not talking a last minute change! memcpy() *always* documented not to use overlapping memory areas. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
[gentoo-dev] Re: Downgrading glibc?
Diego Elio Pettenò posted on Fri, 11 Feb 2011 10:22:44 +0100 as excerpted: Il giorno ven, 11/02/2011 alle 09.50 +0100, Sebastian Pipping ha scritto: Can anyone guide me or point me to a guide how to savely do that manually? There really isn't a safe way as soon as you built anything at all against the new version. The glibc ebuild really needs an override, like the usual check for I_KNOW_WHAT_I_AM_DOING_AND_WILL_KEEP_THE_PIECES_IF_IT_BREAKS or some such, set in the environment. Failing to have such an override at all, seems rather unGentooish to me. Fortunately for me (I haven't upgraded to 2.13 yet, but ran into the need to downgrade an ~arch version myself not long ago, I hadn't emerged anything of major interest since so the warning was incorrect on its face), Gentoo has a number of alternative methods to enforce one's will over an obstinate system, if one believes it necessary. I think I copied to my personal overlay and edited the ebuild there... after cursing the fact that I couldn't simply set some sort of var to get the perfectly good binpkg of the old version to install. The problem has since been fixed and I've upgraded past it, since. If that hadn't worked, I'd have tried the untar-the-binpkg-over-the-live-fs thing. Either that, or the boot to backup snapshot, set ROOT appropriately, and emerge from there. -- 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] Downgrading glibc?
A little update from my side: I was abe to downgrade glibc to 2.12.2 and my sound problem [1] is now gone again! If it's not glibc itself, it's one of the packages re-installed after (again, see [1] for the list). If anyone considers masking glibc 2.13 for now: please take my vote. Best, Sebastian [1] https://bugs.gentoo.org/show_bug.cgi?id=354395
Re: [gentoo-dev] Downgrading glibc?
On 2/11/11 10:55 AM, Michael Haubenwallner wrote: what do you think of working around the memcpy troubles with glibc-2.13 by simply redirecting memcpy to memmove within glibc, either unconditionally or optional/temporary (via USE-flag?) until everyone uses memmove where necessary? I'm not a maintainer of base-system, but it seems to me that such a change in behavior would only add to the confusion. glibc behaving differently on Gentoo than other distros... no, that doesn't sound good. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Downgrading glibc?
On 2/11/11 1:06 PM, Sebastian Pipping wrote: I was abe to downgrade glibc to 2.12.2 and my sound problem [1] is now gone again! Just curious, what downgrade method did you use? Just untaring an older glibc package? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Downgrading glibc?
Il giorno ven, 11/02/2011 alle 13.06 +0100, Sebastian Pipping ha scritto: If anyone considers masking glibc 2.13 for now: please take my vote. It should have been masked _beforehand_, masking it now is going to cause more trouble. Remember: unless you're able to rebuild everything that was built afterwards without _using_ it, your system is going to be totally broken. Sure it sucks, haven't I said that enough times, regarding pushing stuff that's going to break other stuff straight to ~arch? -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] Downgrading glibc?
On 02/11/11 13:26, Paweł Hajdan, Jr. wrote: Just curious, what downgrade method did you use? Just untaring an older glibc package? This is what I did: 0) Log out of X, log in to root console 1) Collect packages emerged after previous update to glibc from files in PORT_LOGDIR (using simple shell scripting) 2) Emerge glibc 2.12.2 3) Re-emerge packages from (1) 4) Reboot WARNING: It may not work as well on your system. Best, Sebastian
Re: [gentoo-dev] Downgrading glibc?
On 02/11/2011 01:20 PM, Paweł Hajdan, Jr. wrote: On 2/11/11 10:55 AM, Michael Haubenwallner wrote: what do you think of working around the memcpy troubles with glibc-2.13 by simply redirecting memcpy to memmove within glibc, either unconditionally or optional/temporary (via USE-flag?) until everyone uses memmove where necessary? I'm not a maintainer of base-system, but it seems to me that such a change in behavior would only add to the confusion. glibc behaving differently on Gentoo than other distros... no, that doesn't sound good. While Fedora 14 has shipped with glibc-2.13 and vanilla memcpy it seems, I'm really curious if a next Red Hat Enterprise Linux or any distribution designed for enterprise environments would do so, risking commercial applications to break. So I'm not convinced yet that they can perpetuate this new memcpy implementation. /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Re: Downgrading glibc?
On 02/11/2011 11:12 AM, Diego Elio Pettenò wrote: Il giorno ven, 11/02/2011 alle 10.55 +0100, Michael Haubenwallner ha scritto: what do you think of working around the memcpy troubles with glibc-2.13 by simply redirecting memcpy to memmove within glibc, either unconditionally or optional/temporary (via USE-flag?) until everyone uses memmove where necessary? That unless things start crashing down nobody will fix the issues at all. We're not talking a last minute change! memcpy() *always* documented not to use overlapping memory areas. Yes, *documented*, I'm aware of that. But both that document as well as uncountable lines of source code are rather old. While the source code isn't that large a problem for Gentoo, existing binaries without source code still are. The questions simply are: *) Does anyone really need memcpy when there is memmove? *) Is it worth the effort to bug everyone to replace memcpy by memmove in their existing applications, with or without investigating that memcpy doesn't suffice? /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Re: Downgrading glibc?
On Fri, Feb 11, 2011 at 1:27 PM, Diego Elio Pettenò flamee...@gmail.com wrote: Il giorno ven, 11/02/2011 alle 13.06 +0100, Sebastian Pipping ha scritto: If anyone considers masking glibc 2.13 for now: please take my vote. It should have been masked _beforehand_, masking it now is going to cause more trouble. Given this situation; it is desirable for future Portage/EAPI to be able to create a deptree depending on whether an atom is already installed or not? With this functionality it is possible to mask a package-without-downgrade-path again for systems that haven't the new atom installed yet. It should be used as little as possible of course, but for situations like this the damage can be limited to as few systems as possible.
Re: [gentoo-dev] Re: Downgrading glibc?
On 02/11/2011 01:27 PM, Diego Elio Pettenò wrote: It should have been masked _beforehand_, masking it now is going to cause more trouble. Portage will propose a downgrade of glibc on emerge-update-world, okay. How bad would that be? Does it cause any other trouble? Remember: unless you're able to rebuild everything that was built afterwards without _using_ it, your system is going to be totally broken. Sure it sucks, haven't I said that enough times, regarding pushing stuff that's going to break other stuff straight to ~arch? In your eyes, is there anything we can do to improve the current situation? Best, Sebastian
[gentoo-dev] Re: Re: Downgrading glibc?
Il giorno ven, 11/02/2011 alle 15.37 +0100, Sebastian Pipping ha scritto: Portage will propose a downgrade of glibc on emerge-update-world, okay. How bad would that be? Does it cause any other trouble? And glibc will refuse to downgrade unless you hack the ebuild. Now let's say that the user rebuilt gcc after the glibc upgrade, and now forces downgrade; after forcing downgrade, gcc will fail to find the symbols with higher versioning (GNU versioning), which means it won't run. In your eyes, is there anything we can do to improve the current situation? Every time a base package changes that could cause huge breakage, mask, send a message to q...@gentoo.org to start up testing ebuild $foo with an unmask list, and wait till we give the go before unmasking. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
[gentoo-dev] Re: Re: Downgrading glibc?
Il giorno ven, 11/02/2011 alle 14.23 +0100, Michael Haubenwallner ha scritto: But both that document as well as uncountable lines of source code are rather old. While the source code isn't that large a problem for Gentoo, existing binaries without source code still are. Beside flash what else is involved for now? We can decide that once that's defined. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Re: Downgrading glibc?
On 02/11/2011 05:13 PM, Diego Elio Pettenò wrote: Il giorno ven, 11/02/2011 alle 15.37 +0100, Sebastian Pipping ha scritto: Portage will propose a downgrade of glibc on emerge-update-world, okay. How bad would that be? Does it cause any other trouble? And glibc will refuse to downgrade unless you hack the ebuild. Now let's say that the user rebuilt gcc after the glibc upgrade, and now forces downgrade; after forcing downgrade, gcc will fail to find the symbols with higher versioning (GNU versioning), which means it won't run. In your eyes, is there anything we can do to improve the current situation? Every time a base package changes that could cause huge breakage, mask, send a message to q...@gentoo.org to start up testing ebuild $foo with an unmask list, and wait till we give the go before unmasking. That will be definately done for libpng-1.5.1 that just hit tree with KEYWORDS=. It turns most, if not all deprecation warnings from libpng-1.4.x series to fatal errors. ABI break, .la files drop and the fun of 90% of packages not building against it \o/ - Samuli
Re: [gentoo-dev] Re: Re: Re: Lastrite: app-pda/libopensync and reverse dependencies
On Fri, 11 Feb 2011 10:23:19 +0100 Diego Elio Pettenò flamee...@gmail.com wrote: Politeness is due where politeness is received. If you keep second-guessing QA team, without looking at the packages at all (see Samuli's mail) you're not going to receive any. Sorry, but that violates the devrel Etiquette Policy [1], which quite clearly states that: One should try to not be rude, abusive or impolite under any circumstances. I look forward to seeing your proposed change to QA policy to bring it in line with this requirement. [1]: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=2 -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] libpng-1.5 smooth upgrade
I'm not a member of QA team or libpng maintainer, but hopefully I'm not going to write something horribly wrong here. To ensure good upgrade experience for our users, and learning some lessons from previous, um... disruptive upgrade (1.2 - 1.4), I'd have some questions: 1) Are we going to have a tinderbox run *before* libpng-1.5 gets keyworded? 2) If the upgrade is non-trivial, i.e. just emerge -uDNa world and revdep-rebuild isn't going to fix it, will we have an upgrade guide, possibly as a news item? 3) Can we do something to make catching libpng problems easier? As Samuli pointed out in https://bugs.gentoo.org/show_bug.cgi?id=354479 there is a predictable compilation warning. How about making portage print it as a QA warning, so more people can report the issues without even emerging libpng-1.5 on their systems? That may be a good backup option for the tinderbox too. 4) What have we learned from libpng 1.2 - 1.4 upgrade? I'd just like to be better informed. Finally, it seems that hard work on --as-needed and automatic fixing of .la files is going to make the upgrade experience better now, right? Paweł Hajdan, Jr. P.S. The 1.2 - 1.4 upgrade wasn't really bad for me, but I guess it could be frustrating for some people, and I just wonder if we can make it better. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] libpng-1.5 smooth upgrade
On 02/11/2011 06:38 PM, Paweł Hajdan, Jr. wrote: I'm not a member of QA team or libpng maintainer, but hopefully I'm not going to write something horribly wrong here. To ensure good upgrade experience for our users, and learning some lessons from previous, um... disruptive upgrade (1.2 - 1.4), I'd have some questions: 1) Are we going to have a tinderbox run *before* libpng-1.5 gets keyworded? Absolutely. 4) What have we learned from libpng 1.2 - 1.4 upgrade? I'd just like to be better informed. One way under consideration: We have been discussing about removing libpng.pc, libpng.so and unversioned headers from the libpng 1.5.x package allowing it to install parallel with libpng 1.4.x. That means every package that has been checked working against 1.5.x, will need to be patched to link against -lpng15, use headers from the libpng15/ directory and use libpng15.pc instead. Or we go with the old route as with 1.2 to 1.4 but that means everything must be ported before it gets KEYWORDS. Finally, it seems that hard work on --as-needed and automatic fixing of .la files is going to make the upgrade experience better now, right? Indeed. That's a blessing :)
Re: [gentoo-dev] libpng-1.5 smooth upgrade
On 02/11/2011 05:38 PM, Paweł Hajdan, Jr. wrote: To ensure good upgrade experience for our users, and learning some lessons from previous, um... disruptive upgrade (1.2 - 1.4), I'd have some questions: FWIW: For that upgrade I've not used lafile-fixer or anything like that on my stable x86 binhost. Instead, alternating 'emerge -uDN world' with 'revdep-rebuild' a couple of times until there was nothing more to do did work as well. /haubi/ -- Michael Haubenwallner Gentoo on a different level
[gentoo-dev] Re: libpng-1.5 smooth upgrade
Il giorno ven, 11/02/2011 alle 17.38 +0100, Paweł Hajdan, Jr. ha scritto: 1) Are we going to have a tinderbox run *before* libpng-1.5 gets keyworded? Absolutely. 2) If the upgrade is non-trivial, i.e. just emerge -uDNa world and revdep-rebuild isn't going to fix it, will we have an upgrade guide, possibly as a news item? As Samuli said we're planning on making it as standard as possible, similarly to what's done with Berkeley DB. This is going to take a bit more work than a standard bump but will avoid further breakage. Slotted installation is the thing that makes most sense, especially since upstream helps us there already by versioning the symbols. 3) Can we do something to make catching libpng problems easier? As Samuli pointed out in https://bugs.gentoo.org/show_bug.cgi?id=354479 there is a predictable compilation warning. How about making portage print it as a QA warning, so more people can report the issues without even emerging libpng-1.5 on their systems? That may be a good backup option for the tinderbox too. Tinderbox is also going to report all those warnings to me, which means I'll open them to the bugzilla. While it might not cover 100% use cases, I doubt adding the warning to Portage's reported ones is going to help, based on the experience of not even being able to get fortify-sources will overflow warnings to be acted upon. Finally, it seems that hard work on --as-needed and automatic fixing of .la files is going to make the upgrade experience better now, right? Most definitely, yes. It could have been better, to be honest, but it's definitely not going to be the many-tiers failure we have seen before. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
[gentoo-dev] Last rites: app-misc/magicdev
# Pacho Ramos pa...@gentoo.org (11 Feb 2011) # Upstream dead since a lot of time, still using gnome-vfs and # other deprecated stuff, replaced by udisks, udisks-glue, # udiskie or gvfs. Removal in 30 days. app-misc/magicdev signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Policy for conflicting USE flags
On 02/09/2011 03:11 PM, Zac Medico wrote: In order to try to avoid forcing users to micro-manage flags too much, it might make sense to avoid REQUIRED_USE whenever it's possible to do a build that will almost certainly suit the user's needs. The most common case that I can imagine where REQUIRED_USE is really necessary is for libraries were reverse USE dependencies might be broken without it. To clarify about issues with reverse USE dependencies, I mean any library with something like REQUIRED_USE=^^ ( a b ) where either a or b would be specified in reverse USE dependencies. Also, it's worth noting that something like REQUIRED_USE=c? ( ^^ ( a b ) ) may not need REQUIRED_USE if reverse USE dependencies dep on c rather than a or b. -- Thanks, Zac
[gentoo-dev] Last rites: app-text/ggv
# Pacho Ramos pa...@gentoo.org (11 Feb 2011) # Upstream dead for a long time, replaced by app-text/evince # Removal in 30 days. app-text/ggv signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Status of sparc-fbsd
On Friday, February 11, 2011 03:53:35 AM Torsten Veller wrote: * Samuli Suominen ssuomi...@gentoo.org: So I think your own chance is to contact aballier, ask if he still has access (or ask for renewed opinion for the killing) That was the intention. I cc'ed the bsd team and am still expecting a reply. I will move the sparc-bsd and amd-bsd profiles to exp in one week. I suggest to remove amd-bsd completely. as far as i'm concerned, you can proceed with this A. --- profiles.desc 14 Dec 2010 20:44:09 - 1.166 +++ profiles.desc 11 Feb 2011 06:49:12 - @@ -147,8 +147,8 @@ # Gentoo/FreeBSD Profiles -amd64-fbsd default/bsd/fbsd/amd64/7.2 dev -amd64-fbsd default/bsd/fbsd/amd64/8.0 dev -sparc-fbsd default/bsd/fbsd/sparc/7.2 dev -sparc-fbsd default/bsd/fbsd/sparc/8.0 dev +amd64-fbsd default/bsd/fbsd/amd64/7.2 exp +amd64-fbsd default/bsd/fbsd/amd64/8.0 exp +sparc-fbsd default/bsd/fbsd/sparc/7.2 exp +sparc-fbsd default/bsd/fbsd/sparc/8.0 exp x86-fbsd default/bsd/fbsd/x86/7.2dev x86-fbsd default/bsd/fbsd/x86/8.0dev
Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade
On Fri, Feb 11, 2011 at 8:07 PM, Diego Elio Pettenò flamee...@gmail.com wrote: Il giorno ven, 11/02/2011 alle 16.51 -0300, Alexis Ballier ha scritto: you are seriously considering patching every single package using libpng like this instead of fixing those that fail??? (and i'm not talking about the fact that these patches cannot be upstreamed...) Why not? We're *not* inventing the libpng15 thing at all... I was thinking there's no way this can be a good plan, but if a bunch packages have to be patched, we might as well slot libpng. I'm a little unclear about -lpng vs -lpng15. ssuominen tells me on IRC that probably 90% of packages linking with libpng will fail with 1.5. These 90% will link with -lpng until a version that supports 1.5 is released? The remaining 10% will go ahead and link with -lpng15? What happens when 1.6 is released and breaks compatibility again? Matt
[gentoo-dev] Re: libpng-1.5 smooth upgrade
Matt Turner posted on Fri, 11 Feb 2011 20:39:04 + as excerpted: I'm a little unclear about -lpng vs -lpng15. ssuominen tells me on IRC that probably 90% of packages linking with libpng will fail with 1.5. These 90% will link with -lpng until a version that supports 1.5 is released? The remaining 10% will go ahead and link with -lpng15? What happens when 1.6 is released and breaks compatibility again? That last is my first thought as well. If we go ahead and patch a whole bunch of stuff to -lpng15, we're locking ourselves in to screwing with them for 1.6 and beyond, as well. It seems to me that if we're going to patch, patch the real problem, so -lpng continues to work, and then we'll only be forced to fix what breaks with 1.6 when it comes out, not everything we broke by locking it to 1.5 specifically, as well. But I'm not the one doing the patching, so... -- 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: libpng-1.5 smooth upgrade
On Friday, February 11, 2011 05:07:50 PM Diego Elio Pettenò wrote: Il giorno ven, 11/02/2011 alle 16.51 -0300, Alexis Ballier ha scritto: you are seriously considering patching every single package using libpng like this instead of fixing those that fail??? (and i'm not talking about the fact that these patches cannot be upstreamed...) Why not? We're *not* inventing the libpng15 thing at all... as i read it, it's breaking the libpng.so/pc thing however... A.
Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade
On Friday, February 11, 2011 18:33:32 Alexis Ballier wrote: On Friday, February 11, 2011 05:07:50 PM Diego Elio Pettenò wrote: Il giorno ven, 11/02/2011 alle 16.51 -0300, Alexis Ballier ha scritto: you are seriously considering patching every single package using libpng like this instead of fixing those that fail??? (and i'm not talking about the fact that these patches cannot be upstreamed...) Why not? We're *not* inventing the libpng15 thing at all... as i read it, it's breaking the libpng.so/pc thing however... so why dont you ask the libpng upstream people ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade
On Friday, February 11, 2011 08:44:04 PM Mike Frysinger wrote: On Friday, February 11, 2011 18:33:32 Alexis Ballier wrote: On Friday, February 11, 2011 05:07:50 PM Diego Elio Pettenò wrote: Il giorno ven, 11/02/2011 alle 16.51 -0300, Alexis Ballier ha scritto: you are seriously considering patching every single package using libpng like this instead of fixing those that fail??? (and i'm not talking about the fact that these patches cannot be upstreamed...) Why not? We're *not* inventing the libpng15 thing at all... as i read it, it's breaking the libpng.so/pc thing however... so why dont you ask the libpng upstream people ? ask what ? pretty please dont install libpng.pc/.so, pretty please force every consumer to hardcode the version because i know people that want to do this ? Thanks, I'm fine with having it non slotted. A.
[gentoo-dev] Re: Downgrading glibc?
On Fri, 11 Feb 2011 16:24:14 +0100 Diego Elio Pettenò flamee...@gmail.com wrote: Il giorno ven, 11/02/2011 alle 14.23 +0100, Michael Haubenwallner ha scritto: But both that document as well as uncountable lines of source code are rather old. While the source code isn't that large a problem for Gentoo, existing binaries without source code still are. Beside flash what else is involved for now? We can decide that once that's defined. There's a patch for flash. Skype is broken. Tracker: https://bugs.gentoo.org/353816 -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: Lastrite: app-pda/libopensync and reverse dependencies
On Fri, 11 Feb 2011 07:40:53 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: On 02/10/2011 11:03 PM, Andreas K. Huettel wrote: I'm not sure if you understand opensync then, there's 3-4 series in tree and mostly not compatible with each other: 0.22, 0.36, 0.39 and latest being live . 0.39 is fixed. 0.36 we'll keep around since very few of the plugins seem to be ported to 0.39 (just looking at the dependencies), but it needs a lot more work than 0.39. I know barry needs 0.22 but I looked at cherry-picking some upstream patches to bring it up to date a few months ago. If there are no other users then I think we should stabilize 0.36 once it's resolved and drop 0.22. I'm not interested in maintaining the live ebuild but I can get it up to date at least. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
