Re: [gentoo-dev] status of releng project
On 9 August 2010 14:29, Mike Frysinger vap...@gentoo.org wrote: sure would be nice if someone picked up the installer again ... No, it wouldn't. Best leave that dead and buried. Cheers, Ben
Re: [gentoo-dev] RFC: Reviving GLEP33
On 7 August 2010 02:18, Brian Harring ferri...@gmail.com wrote: The thing you're ignoring out of this g55 idiocy is that people don't particularly seem to want it. There has been an extremely vocal subgroup of paludis/exherbo devs pushing for it while everyone else seems to have less than an interest in it. That's generalizing a bit, but is reasonably accurate. Exactly. This is Gentoo. Let Exherbo devs go develop their own distro and stop trying to interfere with Gentoo. It is time the council puts a definite stop to GLEP 55. _EITHER WAY_, rather than having g33 get beat down for unrelated reasons by people screaming they want their pony/g55, g33 can proceed despite claims to the contrary, and it doesn't require g55 as ciaran/crew have claimed. I for one am a strong supporter of GLEP 33. I believe it is one of the most promising ways to move forward. And I hope the council decides to get behind this. Cheers, Ben
Re: [gentoo-dev] RFC: Reviving GLEP33
On Thu, 12 Aug 2010 15:51:54 +0800 Ben de Groot yng...@gentoo.org wrote: Exactly. This is Gentoo. Let Exherbo devs go develop their own distro and stop trying to interfere with Gentoo. It is time the council puts a definite stop to GLEP 55. GLEP: 55 Author: Piotr Jaroszyński peper at gentoo.org ^ | Bad troll! No cookie! -+ And on top of that: 20090514: After quite a bit of confusion in the voting(people changing their votes), a tie(3-3) vote was reached. Therefore, no decision was reached. This vote will be brought up again next meeting so that the tie can be broken(hopefully with everyone present). 20090528: The council voted on whether they recognized the problem that GLEP 55 is attempting to solve is real. The vote was affirmative in recognition of the problem with two abstentions(leio and ulm). I wasn't aware that so many Gentoo developers and Council members were secretly actually Exherbo developers. Do you have a list somewhere that I can consult to find out just who all these undercover agents are? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] status of releng project
On Thu, Aug 12, 2010 at 9:35 AM, Ben de Groot yng...@gentoo.org wrote: On 9 August 2010 14:29, Mike Frysinger vap...@gentoo.org wrote: sure would be nice if someone picked up the installer again ... No, it wouldn't. Best leave that dead and buried. That one, for sure. Cheers, Ben -- Fabio Erculiani http://lxnay.com http://www.sabayon.org http://www.gentoo.org
[gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
Hi, Mike Frysinger vap...@gentoo.org: sounds like someone needs to update/extend the arch testing documentation. random e-mails posted to random dev lists are quickly forgotten. new arch testers however should be reading the arch tester documnt. It has been added to the x86 AT guide. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Reviving GLEP33
Ben de Groot yng...@gentoo.org said: On 7 August 2010 02:18, Brian Harring ferri...@gmail.com wrote: The thing you're ignoring out of this g55 idiocy is that people don't particularly seem to want it. There has been an extremely vocal subgroup of paludis/exherbo devs pushing for it while everyone else seems to have less than an interest in it. That's generalizing a bit, but is reasonably accurate. Exactly. This is Gentoo. Let Exherbo devs go develop their own distro and stop trying to interfere with Gentoo. It is time the council puts a definite stop to GLEP 55. if the council should stop anything, then rude behavior like you have shown. I am personally much in favor for GLEP55, as it solves a technical problem that keeps coming up and have no association with Exherbo at all. If you want to constructively contribute to Gentoo, i'd hope you reconsider a message like the above before sending it next time. _EITHER WAY_, rather than having g33 get beat down for unrelated reasons by people screaming they want their pony/g55, g33 can proceed despite claims to the contrary, and it doesn't require g55 as ciaran/crew have claimed. I for one am a strong supporter of GLEP 33. I believe it is one of the most promising ways to move forward. And I hope the council decides to get behind this. I for one am a strong supporter of GLEP 55. I believe it is one of the most promising ways to move forward. And I hope the council decides to get behind this. I also support the aims of GLEP33. Cheers, Ben signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] status of releng project
Ben de Groot yng...@gentoo.org said: On 9 August 2010 14:29, Mike Frysinger vap...@gentoo.org wrote: sure would be nice if someone picked up the installer again ... No, it wouldn't. Best leave that dead and buried. Could you explain why you think so? Cheers, Ben signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] status of releng project
On 12 August 2010 17:13, Thilo Bangert bang...@gentoo.org wrote: Ben de Groot yng...@gentoo.org said: On 9 August 2010 14:29, Mike Frysinger vap...@gentoo.org wrote: sure would be nice if someone picked up the installer again ... No, it wouldn't. Best leave that dead and buried. Could you explain why you think so? 1) it was an experiment plagued by bugs, some *very* serious 2) the normal, hands-on, follow the handbook, manual install has always been the recommended way to install Gentoo, and could be considered a rite of passage, familiarizing the user with how things are done in this distro 3) too few people are interested in developing, testing and maintaining this; making it more likely that a revival of this project will result in failure again 4) a buggy installer is a disservice to new users and can give them a false impression of Gentoo But that's just my opinion. :-) Cheers, Ben
Re: [gentoo-dev] status of releng project
On Thu, Aug 12, 2010 at 5:39 AM, Ben de Groot wrote: On 12 August 2010 17:13, Thilo Bangert wrote: Ben de Groot said: On 9 August 2010 14:29, Mike Frysinger wrote: sure would be nice if someone picked up the installer again ... No, it wouldn't. Best leave that dead and buried. Could you explain why you think so? 1) it was an experiment plagued by bugs, some *very* serious bugs are not a reason to not work on a solution many found useful 2) the normal, hands-on, follow the handbook, manual install has always been the recommended way to install Gentoo, and could be considered a rite of passage, familiarizing the user with how things are done in this distro *yawn* ... heralding from the age of everything is done from the console does not preclude simple and helpful GUI automation. no one is talking about changing the recommended install procedure, just providing more options. forcing a command line install can also waste time on repeat installs as knowledge of the install procedures really doesnt help you in maintenance of Gentoo once installed. 3) too few people are interested in developing, testing and maintaining this; making it more likely that a revival of this project will result in failure again that's why i said it'd be nice and not i'm going to do it -mike
Re: [gentoo-dev] RFC: Reviving GLEP33
On 12 August 2010 08:51, Ben de Groot yng...@gentoo.org wrote: Exactly. This is Gentoo. Let Exherbo devs go develop their own distro and stop trying to interfere with Gentoo. It is time the council puts a definite stop to GLEP 55. I've already discussed this with you, but it seems you still don't get it. People are not defined as Gentoo people or Exherbo people. I can't speak for anyone else, but I am a sentient being with enough mental capacity to be interested in more than one thing at once - in other words, being an Exherbo developer doesn't in any way interfere with wanting to see Gentoo improve. There is no activity from Exherbo trying to push anything on Gentoo, there is only Gentoo users contributing ideas towards developing the distribution.
[gentoo-dev] Re: Council Agenda 20100809 rev 01
On 7 August 2010 15:16, Brian Harring ferri...@gmail.com wrote: I suspect we may not wind up being able to get to it in the coming meeting, but I'd like g55 sorted. Specifically, if the authors of it (cc'd) want it to move forward, request the council vote on it. If you don't want it voted on, mark it moribund. As I stated at the last meeting, go ahead and vote on it. I still think it would be very useful for Gentoo to accept it, I just kinda lost hope after 2 or 3 times when it was supposed to be voted upon already. -- Best Regards Piotr Jaroszyński
[gentoo-dev] Last rites: sys-apps/ivman
# Markos Chandras hwoar...@gentoo.org (12 Aug 2010) # Depends to libxml2 version which is no longer on tree. # Latest release in 2007. Multiple QA bugs. See bug #257058 # Use sys-apps/halevt instead. Masked for removal in 2010-09-12 sys-apps/ivman -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpkFMaCzji4H.pgp Description: PGP signature
Re: [gentoo-dev] status of releng project
On Thu, Aug 12, 2010 at 4:39 AM, Mike Frysinger vap...@gentoo.org wrote: On Thu, Aug 12, 2010 at 5:39 AM, Ben de Groot wrote: On 12 August 2010 17:13, Thilo Bangert wrote: Ben de Groot said: On 9 August 2010 14:29, Mike Frysinger wrote: sure would be nice if someone picked up the installer again ... No, it wouldn't. Best leave that dead and buried. Could you explain why you think so? 1) it was an experiment plagued by bugs, some *very* serious bugs are not a reason to not work on a solution many found useful 2) the normal, hands-on, follow the handbook, manual install has always been the recommended way to install Gentoo, and could be considered a rite of passage, familiarizing the user with how things are done in this distro *yawn* ... heralding from the age of everything is done from the console does not preclude simple and helpful GUI automation. no one is talking about changing the recommended install procedure, just providing more options. forcing a command line install can also waste time on repeat installs as knowledge of the install procedures really doesnt help you in maintenance of Gentoo once installed. 3) too few people are interested in developing, testing and maintaining this; making it more likely that a revival of this project will result in failure again 2 questions: 1) I assume most people who are crazy enough to 'install gentoo on thousands of machines' use some kind of image based installation process and not a color-by-numbers install vis-a-vis the handbook? Has anyone written a Gentoo installer that is not image based? 1.5) There is a hidden assumption here that image based installations would not work for everyone (likely due to a lack of the 'right' image; too old, wrong arch, etc...) 2) Has anyone looked at just taking an existing installation framework (d-i? kickstart?) and just making it run different stuff? I honestly have not looked at either (someone else at work does that thank god) but it can't be outside of the realm of impossibility... -A that's why i said it'd be nice and not i'm going to do it -mike
Re: [gentoo-dev] status of releng project
On Thu, Aug 12, 2010 at 6:00 PM, Alec Warner anta...@gentoo.org wrote: 2 questions: [..] 2) Has anyone looked at just taking an existing installation framework (d-i? kickstart?) and just making it run different stuff? I honestly have not looked at either (someone else at work does that thank god) but it can't be outside of the realm of impossibility... I probably said this several times, in Sabayon we do use an almost vanilla Aanconda Installer, that does livecd/dvd to hd. Using Anaconda means that stuff like kickstart is supported (even if we never used that). The downside is: we need to use some of cr*ppy redhatish packages (only for the purpose of satisfying anaconda runtime deps), and libselinux/libsepol, which are known to cause automagic dependencies issues across a wide range of random pkgs. We solve that by bundling such libs in our app-admin/anaconda package and installing them on less annoying library path (/usr/lib/anaconda-runtime), something not really Gentoo-compliant. -A that's why i said it'd be nice and not i'm going to do it -mike -- Fabio Erculiani http://lxnay.com http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] status of releng project
On Thu, Aug 12, 2010 at 12:00 PM, Alec Warner wrote: 1) I assume most people who are crazy enough to 'install gentoo on thousands of machines' use some kind of image based installation process and not a color-by-numbers install vis-a-vis the handbook? Has anyone written a Gentoo installer that is not image based? 1.5) There is a hidden assumption here that image based installations would not work for everyone (likely due to a lack of the 'right' image; too old, wrong arch, etc...) 2) Has anyone looked at just taking an existing installation framework (d-i? kickstart?) and just making it run different stuff? I honestly have not looked at either (someone else at work does that thank god) but it can't be outside of the realm of impossibility... i dont particularly care what installer we utilize, it'd just be nice to have a helpful gui/curses based approach available as an option. i have toyed with anaconda in the past, but my personal experience has been that our gui python one was better. that and the insistence on redhat-only tools (like rpm) is obnoxious. -mike
Re: [gentoo-dev] status of releng project
On Thu, Aug 12, 2010 at 7:14 PM, Mike Frysinger vap...@gentoo.org wrote: On Thu, Aug 12, 2010 at 12:00 PM, Alec Warner wrote: 1) I assume most people who are crazy enough to 'install gentoo on thousands of machines' use some kind of image based installation process and not a color-by-numbers install vis-a-vis the handbook? Has anyone written a Gentoo installer that is not image based? 1.5) There is a hidden assumption here that image based installations would not work for everyone (likely due to a lack of the 'right' image; too old, wrong arch, etc...) 2) Has anyone looked at just taking an existing installation framework (d-i? kickstart?) and just making it run different stuff? I honestly have not looked at either (someone else at work does that thank god) but it can't be outside of the realm of impossibility... i dont particularly care what installer we utilize, it'd just be nice to have a helpful gui/curses based approach available as an option. i have toyed with anaconda in the past, but my personal experience has been that our gui python one was better. that and the insistence on redhat-only tools (like rpm) is obnoxious. -mike RPM dependency has been moved to the yum module inside anaconda and it's not required anymore. -- Fabio Erculiani http://lxnay.com http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] RFC: Reviving GLEP33
On Fri, Aug 06, 2010 at 07:34:09PM +0100, Ciaran McCreesh wrote: On Fri, 6 Aug 2010 11:18:46 -0700 Brian Harring ferri...@gmail.com wrote: And by right now, I assume you meant to say minimally a year down the line after a portage is stabled supporting g55 semantics and resolving any breakage it's usage induces. You know, the same issue EAPI itself had to go through to ensure that people had a reasonable chance of getting an appropriate error message and support being in place. Uh, no, since GLEP 55 doesn't need users to be using a newer Portage. That is one of the many ways in which it is a much better solution. Currently, a PM that doesn't support EAPI4 will tell you there is a version available, but I don't support this- upgrade me. Versus current PM's + g55 == I see no version. *addressing* that would be useful, rather than staying in g55 salesman mode. Like it or not, you switch out the compatibility mechanisms there are delays that go with it while waiting on the implementations to propagate. Now if your solution is they don't see the version till they upgrade, fine, at least it's accurate and it's stated. This is a fair bit more useful than there is no issue and it solves world hunger in it's spare time. Grok? New version formats aren't magically usable the moment g55 lands. At the very least you're forgetting about bundled glsa's and their knowledge of atom formats. Suppose the next comment will be they suck, throw them out, but so it goes. No, the fix is to give them EAPI suffixes too. You checked existing glsa parser to see what they'll do if they get new attributes/tags jammed into the format? Verifying they'll actually ignore the extension is needed rather than hand wavey crap. I'd hope they don't go boom, but there have been issues in the past of this sort. News items are another one that come to mind. Last glance, there wasn't a tag that was jammed into it stating to even interpret this atom you need to be at least eapi foo- glep42 surely doesn't cover it. Meaning that a proper implementation will parse it, and quite likely go boom. Meaning either those new version schemes you want can't be used for at least a year in news items. EAPI suffixes addresses one problem. Pretending it solves all is invalid however- GLSA's at the very least probably will have problems, NEWS items most definitely will. The restrictions are no new global functionality can set or influence EAPI. Basically the same restriction you forced on eclasses. It's nasty and arbitrary when I state it, but some how it is sane when you propose it the same thing? No, they're not. The restrictions are no changes that will make older package managers not realise that the EAPI was supposed to have been set to something else. That's not the same thing at all, especially on the using new Bash syntax front, and the very fact that you missed that point just goes to illustrate the difficulties involved. My stating of restrictions is actually the accurate one. If the rules were what you stated, eclasses would be allowed to set EAPI. Point is, ebuild's set the EAPI themselves. Even your g55 proposal requires this explicitly via the file naming. EAPI in the ebuild combined w/ global functionality never being allowed to screw with EAPI means global scope functionality that doesn't set/influence EAPI is entirely valid. If you're going to claim otherwise, provide an example of per pkg eclasses that fit the requirements stated above that would result in an invalid EAPI. Take an existing ebuild out of the tree to prove it. As for bash syntax, that's wholy unrelated to g33. g33, like normal eclasses, is bound by bash syntax requirements of the current eapi docs. Now removing that limitation might be nice, but it's not core to providing the functionality- as such lay off the bash crap, it's a selling point of g55, it's orthogonal to g33 however. The thing you're ignoring out of this g55 idiocy is that people don't particularly seem to want it. There has been an extremely vocal subgroup of paludis/exherbo devs pushing for it while everyone else seems to have less than an interest in it. That's generalizing a bit, but is reasonably accurate. Uh, no. Plenty of people want it. There has been an extremely vocal subgroup of people who will yell at anything they think is connected to the 'wrong people' pushing against it, thus making everyone else suffer. And plenty of people hate it too, for the abuse of extensions. The knee jerk claim that the only people who oppose this glep are anti-paludis/exherbo fan boys is the _same_ *bullshit* black/white nonsense y'all railed about it in a seperate part of this thread. Occusing others of fanboy idiocy while pulling the same to excuse away peoples complaints with the glep is hypocritical bullshit. It's very, very tiring, and there are groups on boths sides who pull
Re: [gentoo-dev] status of releng project
1) I assume most people who are crazy enough to 'install gentoo on thousands of machines' use some kind of image based installation process and not a color-by-numbers install vis-a-vis the handbook? Has anyone written a Gentoo installer that is not image based? 1.5) There is a hidden assumption here that image based installations would not work for everyone (likely due to a lack of the 'right' image; too old, wrong arch, etc...) agaffney had started work on quickstart, which basically did what the handbook did in an automatic fashion. i only tried it a couple of times, but it worked rather well. its a small and neat piece of code. for anybody looking at deploying Gentoo in an automatic fashion this is a good start: http://agaffney.org/quickstart.php kind regards Thilo signature.asc Description: This is a digitally signed message part.
[gentoo-dev] keepdir /var/run/package/?
It is perfectly legal to clear /var/run across reboots. Below is a bug
from a user that ran into some trouble because an init script assumes that
/var/run/package/ exists for its PID file:
http://bugs.gentoo.org/show_bug.cgi?id=332397
A quick grep through the tree shows 73 packages that keepdirs
/var/run/package/. Perhaps not all of them are bugs but they are
certainly redundant.
A mass bug-filing is probably not the correct thing to do but perhaps we
should document somewhere (devmanual?) that keepdir'ing a temp location
should be avoided. Suggestion:
--- a/ebuild-writing/common-mistakes/text.xml
+++ b/ebuild-writing/common-mistakes/text.xml
@@ -41,6 +41,18 @@ elog They are listed in the INSTALL file in
/usr/share/doc/${PF}
/body
/section
+section
+titleInvalid use of ckeepdir/cin src_install/title
+body
+The ckeepdir/c function should only be used to prevent directory removal
+during uninstallation. In particular, using ckeepdir/c for a temporary
+location - such as /var/run/package/ for a PID file - should be avoided. In
+such a case, init script either should make sure that /var/run/package/ exists
+or the package should use /var/run directly. Please note that /var/run can and
+will be cleaned across reboots.
+/body
+/section
+
/chapter
/guide
--
Eray
Re: [gentoo-dev] keepdir /var/run/package/?
On 8/12/10 11:29 AM, Eray Aslan wrote: It is perfectly legal to clear /var/run across reboots. Below is a bug from a user that ran into some trouble because an init script assumes that /var/run/package/ exists for its PID file: Can we add a repoman check for that? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] keepdir /var/run/package/?
What you're saying doesn't agree with http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA On Thu, Aug 12, 2010 at 2:29 PM, Eray Aslan eray.as...@caf.com.tr wrote: It is perfectly legal to clear /var/run across reboots. Below is a bug from a user that ran into some trouble because an init script assumes that /var/run/package/ exists for its PID file:
Re: [gentoo-dev] keepdir /var/run/package/?
On Thu, Aug 12, 2010 at 02:36:40PM -0400, Michael Sterrett wrote: What you're saying doesn't agree with http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA I do not understand. In the above link, it says: /var/run: [...]Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process. So we cannot assume that a directory exists under /var/run during boot. Hence, keepdiring a dir that will most probably be cleared during boot is pointless. Am I missing something? -- Eray
Re: [gentoo-dev] keepdir /var/run/package/?
On 08/12/2010 09:42 PM, Eray Aslan wrote: On Thu, Aug 12, 2010 at 02:36:40PM -0400, Michael Sterrett wrote: What you're saying doesn't agree with http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA I do not understand. In the above link, it says: /var/run: [...]Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process. So we cannot assume that a directory exists under /var/run during boot. Hence, keepdiring a dir that will most probably be cleared during boot is pointless. Am I missing something? It says Files under this directory, not Files and directories under this directory. Futhermore is continues with, Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file. So I'd say keepdir is legal here...
Re: [gentoo-dev] keepdir /var/run/package/?
On Thu, 12 Aug 2010 21:48:04 +0300, Samuli Suominen ssuomi...@gentoo.org wrote: It says Files under this directory, not Files and directories under this directory. Oh, cmon. If you are going to selectively quote, then I'll give you this: This directory contains system information data describing the system since it was booted. So in my opinion, it is fine to rm -rf /var/run/* on system shutdown... Futhermore is continues with, Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file. So I'd say keepdir is legal here... Then the app in question can (and should) make the directory, not the ebuild. -Jeremy
Re: [gentoo-dev] keepdir /var/run/package/?
On 08/12/2010 09:48 PM, Samuli Suominen wrote: It says Files under this directory, not Files and directories under this directory. Fair enough. So our policy basically is tmpfs is not supported for /var/run (and also for /var/lock I suppose). It will be somewhat more work but instead of the above, we can say tmpfs might be used for /var/run and /var/lock and the init scripts should handle this correctly. It feels (for want of a better word) better. -- Eray
Re: [gentoo-dev] keepdir /var/run/package/?
On Thu, Aug 12, 2010 at 3:33 PM, Eray Aslan wrote: On 08/12/2010 09:48 PM, Samuli Suominen wrote: It says Files under this directory, not Files and directories under this directory. Fair enough. So our policy basically is tmpfs is not supported for /var/run (and also for /var/lock I suppose). it may have been in the past, but it's best to move forward and not sit in the past It will be somewhat more work but instead of the above, we can say tmpfs might be used for /var/run and /var/lock and the init scripts should handle this correctly. It feels (for want of a better word) better. i certainly use a tmpfs on /var/run to minimize disk writes. packages that break i file bugs for and/or fix myself. it isnt that hard. plus, it's just good behavior. if /var/run gets removed for whatever reason, people have to re-emerge a bunch of packages to simply create a subdir ? that's silly. -mike
Re: [gentoo-dev] status of releng project
On 08/12/2010 08:23 PM, Thilo Bangert wrote: its a small and neat piece of code. for anybody looking at deploying Why isn't already an official project ^^? It looks quite what we need =P lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
[gentoo-dev] wxGTK 2.6 deprecation
Just a heads up - we're going to be dropping wxGTK and wxpython 2.6 sometime in the near-ish future. If you have packages still depending on these versions, please migrate them to 2.8 and drop versions using 2.6. If your package doesn't work with 2.8 then it probably hasn't seen a release in the last five years and should go away :P. The disruption should be minimal. Some packages will need to be removed, but most have been migrated and just need newer versions stabilized. There are no plans to drop support for 2.6 from the eclass or eselect at this time, so putting it in an overlay should continue to work. (I'll be adding the 2.9 development branch to the tree shortly, for those who have been waiting.) -- fonts, gcc-porting, and it's all by design toolchain, wxwidgetsto keep us from losing our minds @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Last rites - media-gfx/zphoto
# Ryan Hill dirtye...@gentoo.org (12 Aug 2010) # Mask for removal 20100912 # No maintainer, dead upstream (last release 2004), needs wxGTK-2.6. # Bug #332559 media-gfx/zphoto -- fonts, gcc-porting, and it's all by design toolchain, wxwidgetsto keep us from losing our minds @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
