Re: [gentoo-dev] Baselayout 2 stabilisation todo
Hi! On Fri, 22 May 2009, Dawid Węgliński wrote: Haven't tested it yet on my box, but i'd like to know if openrc handles 801.2Q support. Near as I can tell, it does (some lines shortened for brevity): [r...@sareth ~]# eix -Ic openrc [I] sys-apps/openrc (0.4.3...@05/15/2009): OpenRC manages the services, startup and shutdown of a host [r...@sareth ~]# ip addr sh [...] 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff 3: eth1: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 [...] link/ether 00:1e:0b:46:50:b8 brd ff:ff:ff:ff:ff:ff 4: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 192.168.2.166/28 brd 192.168.2.175 scope global eth0.381 inet 192.168.2.164/28 brd 192.168.2.175 scope global secondary eth0.381 inet 192.168.2.165/28 brd 192.168.2.175 scope global secondary eth0.381 5: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 192.168.3.102/24 brd 192.168.3.255 scope global eth0.146 6: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 10.104.22.1/24 brd 10.104.22.255 scope global eth0.271 [r...@sareth ~]# grep -v '^#' /etc/conf.d/net routes_eth0_381=(default via 192.168.2.161) config_eth1=( null ) config_eth0=( null ) vlans_eth0=381 146 271 config_eth0_381=( 192.168.2.166/28 192.168.2.164/28 192.168.2.165/28 ) config_eth0_146=(192.168.3.102/24) config_eth0_271=(10.104.22.1/24) Regards, Tobias -- panic(%s: CORRUPTED BTREE OR SOMETHING, __FUNCTION__); linux-2.6.6/fs/xfs/xfs_bmap.c
Re: [gentoo-dev] Baselayout 2 stabilisation todo
On Saturday 23 of May 2009 10:53:49 Tobias Klausmann wrote: Hi! On Fri, 22 May 2009, Dawid Węgliński wrote: Haven't tested it yet on my box, but i'd like to know if openrc handles 801.2Q support. Near as I can tell, it does (some lines shortened for brevity): [r...@sareth ~]# eix -Ic openrc [I] sys-apps/openrc (0.4.3...@05/15/2009): OpenRC manages the services, startup and shutdown of a host [r...@sareth ~]# ip addr sh [...] 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff 3: eth1: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 [...] link/ether 00:1e:0b:46:50:b8 brd ff:ff:ff:ff:ff:ff 4: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 192.168.2.166/28 brd 192.168.2.175 scope global eth0.381 inet 192.168.2.164/28 brd 192.168.2.175 scope global secondary eth0.381 inet 192.168.2.165/28 brd 192.168.2.175 scope global secondary eth0.381 5: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 192.168.3.102/24 brd 192.168.3.255 scope global eth0.146 6: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 10.104.22.1/24 brd 10.104.22.255 scope global eth0.271 [r...@sareth ~]# grep -v '^#' /etc/conf.d/net routes_eth0_381=(default via 192.168.2.161) config_eth1=( null ) config_eth0=( null ) vlans_eth0=381 146 271 config_eth0_381=( 192.168.2.166/28 192.168.2.164/28 192.168.2.165/28 ) config_eth0_146=(192.168.3.102/24) config_eth0_271=(10.104.22.1/24) Regards, Tobias Thank you very much Tobias!
Re: [gentoo-dev] Baselayout 2 stabilisation todo
Doug Goldstein wrote: The only reason why OpenRC has not come up for stabilization by it's maintainers is the fact that everytime there's a new version readied for release, on the horizon there's new incompatible changes being planned for the next version. The OpenRC maintainers in Gentoo have always chosen to wait until OpenRC settles down a little bit. Now with the plan to drop support for certain features (ADSL and PPP support in the networking code), it's going to rewrite more Gentoo people to step up to develop and maintain this code. rp-pppoe support should be removed because its scripts don't work well under baselayout, but are you sure OpenRC mantainers also plan to drop generic PPP support? signature.asc Description: OpenPGP digital signature
[gentoo-dev] The VMware packages are in need of a maintainer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Everybody, Last week I stepped down from the vmware herd, and since I was the only member left, there are no more maintainers for the vmware packages in the tree. The current packages are vmware-workstation, vmware-server, vmware-player, vmware-modules, and open-vm-tools; and there are two more that should probably be masked and removed (vmware-dsp and vmware-gsx-console). All emails being delivered to vmw...@g.o and all bugs assigned to the vmware herd are going unread. The software is effectively in the maintainer-needed group, just with its own email address. As such, for vmware to continue to be supported under Gentoo we need some developers or new recruits to look after the packages. If you want to help look after these packages, please contact me (off-list) and I'll be happy to start training you in how the ebuilds/eclasses work and give you guidance about how vmware packages their software. If you're not a Gentoo developer yet, but are interested in becoming one to look after the vmware packages, do also feel free to contact me and we can look at getting you recruited. The sort of information you'll need to become a Gentoo developer is available at [1], [2] and [3]. The kinds of challenges you'll be dealing with are mostly kernel related, ensuring that the modules are working with various gentoo supported kernels, etc. The current vmware installer is written in python, whilst previously a perl script was used, so knowledge of both of these languages would be advantageous. If you've got any other questions or comments, again feel free to contact me. Mike 5:) [1] http://www.gentoo.org/doc/en/index.xml?catid=gentoodev [2] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml [3] http://devmanual.gentoo.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoYajUACgkQu7rWomwgFXo9lACdEnYCocadAGfMKKeXZFK7Rqni XK8An2P5Akzf4WzIVyIrlxPYXMSaEK3p =KmWx -END PGP SIGNATURE-
Re: [gentoo-dev] Baselayout 2 stabilisation todo
Alin Năstac wrote: Doug Goldstein wrote: The only reason why OpenRC has not come up for stabilization by it's maintainers is the fact that everytime there's a new version readied for release, on the horizon there's new incompatible changes being planned for the next version. The OpenRC maintainers in Gentoo have always chosen to wait until OpenRC settles down a little bit. Now with the plan to drop support for certain features (ADSL and PPP support in the networking code), it's going to rewrite more Gentoo people to step up to develop and maintain this code. rp-pppoe support should be removed because its scripts don't work well under baselayout, but are you sure OpenRC mantainers also plan to drop generic PPP support? I don't usually troll -dev anymore, but I feel urged to reply to this. Basically as Doug said, each OpenRC version comes with a few big chances. Well not massive as in your box will break now, but just a different spin on how things should work. OpenRC-0.5 will have the biggest re-spin to date - net.lo (net.eth0 etc) is considered deprecated. Instead OpenRC now ships with network (provides net) which is a simple wrapper around calling ifconfig (or ip) and with the ability to run shell scripts. Attached is the new conf.d/net sample. You'll notice it's a lot smaller than the old one as it relies heavily on the user being able to read and understand man pages for userland tools requires to do the job. Now, the one weakness with this approach is that the Linux userland tools are quite frankly crap compared to the BSD counterparts. Why is there the need for many badly written tools to configure a network interface? As such, a side project I've started is a new ifconfig tool [1] to handle everything from vlans, to bridging, to bonding, to wireless (up to WEP) with a similar syntax to the BSD ifconfig. However, work on this has stopped as a side product of this means I have to get some wpa_supplicant changes I have pushed upstream so it can start on any wireless interface - and when it appears (pcmcia, etc). One side effect of this is that daemons such was wpa_supplicant and PPP are now init scripts proper - this is good. The only downside is that you lose the ability to control each interface via init.d. Instead I propose you control this via ifconfig. This decision is heavily influenced by NetBSD (disclaimer - I'm now a NetBSD dev). FWIW, the only re-spin I have on my list is to remove dependencies from rc and runscript so that dependencies are only taken into account when rc is run and not for each script. Essentially, making rc and runscript light shell wrappers and removing a few tools so that it's smaller for space critical devices. Thanks Roy
Re: [gentoo-dev] Baselayout 2 stabilisation todo
Roy Marples wrote: One side effect of this is that daemons such was wpa_supplicant and PPP are now init scripts proper - this is good. The only downside is that you lose the ability to control each interface via init.d. Instead I propose you control this via ifconfig. Uh, so in summary any external daemons such as wpa_supplicant and PPP will be controlled fully by init scripts external to OpenRC. OpenRC may supply example init scripts, but not installed by default. Thanks Roy
Re: [gentoo-dev] Baselayout 2 stabilisation todo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roy Marples wrote: Attached is the new conf.d/net sample. Sorry, I missed those. Did lists.g.o remove them, or were they not attached? As such, a side project I've started is a new ifconfig tool [1] to handle everything from vlans, to bridging, to bonding, to wireless (up to WEP) with a similar syntax to the BSD ifconfig. Also [1]'s missing, and I couldn't find it at http://roy.marples.name/. Where should I be looking? This decision is heavily influenced by NetBSD (disclaimer - I'm now a NetBSD dev). Congrats on becoming a NetBSD dev! 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoYdCoACgkQu7rWomwgFXq5NwCfdI7nIk7Am0goWcbip9eCWBE/ iHgAnjHS2V/HpvngD9EUmnBa3ZNCUk4D =aiQu -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: Accessibility on our release media
William Hubbs wrote: [snip] My question for the group is, how do you feel about speech software being on our minimal cd as well as our live cd? I agree, it should be in our minimal and live CD's. There is no reason to consider blind persons out of the minimal CD. Mounir
Re: [gentoo-dev] rfc: Accessibility on our release media
On 05/23/2009 05:56 PM, Mounir Lamouri wrote: William Hubbs wrote: [snip] My question for the group is, how do you feel about speech software being on our minimal cd as well as our live cd? I agree, it should be in our minimal and live CD's. There is no reason to consider blind persons out of the minimal CD. The real issue here is the size. If these additional packages plus all of the alsa modules add 20MB to the minimal CD, it's just not worth it. It's not minimal anymore. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] rfc: Accessibility on our release media
On Sun, May 24, 2009 at 1:14 AM, Andrew Gaffney agaff...@gentoo.org wrote: The real issue here is the size. If these additional packages plus all of the alsa modules add 20MB to the minimal CD, it's just not worth it. It's not minimal anymore. Could you elaborate whom that change would affect (negatively)? 83MB for current x86 isn't really minimal any more, anyway. I don't see the difference between 83MB and 103MB: - Makes no difference on blank CD (even those minis have ~200MB). - Regarding download size, well, after the CD you'll have to get the stage tarball and most probably source tarballs as well. -- Thomas Pani
Re: [gentoo-dev] rfc: Accessibility on our release media
Thomas Pani wrote: On Sun, May 24, 2009 at 1:14 AM, Andrew Gaffney agaff...@gentoo.org wrote: The real issue here is the size. If these additional packages plus all of the alsa modules add 20MB to the minimal CD, it's just not worth it. It's not minimal anymore. Could you elaborate whom that change would affect (negatively)? 83MB for current x86 isn't really minimal any more, anyway. I don't see the difference between 83MB and 103MB: - Makes no difference on blank CD (even those minis have ~200MB). - Regarding download size, well, after the CD you'll have to get the stage tarball and most probably source tarballs as well. -- Thomas Pani For a person on dial-up, about 2 1/2 hours of additional download. That said, I'd be OK with the increase in size if it would help a person who can't see the screen. Dale :-) :-)
Re: [gentoo-dev] rfc: Accessibility on our release media
On Sat, 23 May 2009 18:14:57 -0500 Andrew Gaffney agaff...@gentoo.org wrote: On 05/23/2009 05:56 PM, Mounir Lamouri wrote: William Hubbs wrote: [snip] My question for the group is, how do you feel about speech software being on our minimal cd as well as our live cd? I agree, it should be in our minimal and live CD's. There is no reason to consider blind persons out of the minimal CD. The real issue here is the size. If these additional packages plus all of the alsa modules add 20MB to the minimal CD, it's just not worth it. It's not minimal anymore. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead If the 20MB is a real problem, I think the alternative is to have two versions of the minimal CD. Otherwise it seems to me that Gentoo is discriminating against people who cannot see the screen, and I would consider that to be very tacky at best. Someone (rdalek1967) said the problem was an extra 2.5 hours time for download over dialup. If that is correct, we are looking at 12.5 hours instead of 10 hours (about 25% increase, but 10 hours is a long time, and I don't know that 12.5 hours is subjectively that much longer). So, to answer William's original question, one way or another we should provide a minimal CD with the speech software on it in my opinion. Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: Accessibility on our release media
Ferris McCormick wrote: If the 20MB is a real problem, I think the alternative is to have two versions of the minimal CD. Otherwise it seems to me that Gentoo is discriminating against people who cannot see the screen, and I would consider that to be very tacky at best. Someone (rdalek1967) said the problem was an extra 2.5 hours time for download over dialup. If that is correct, we are looking at 12.5 hours instead of 10 hours (about 25% increase, but 10 hours is a long time, and I don't know that 12.5 hours is subjectively that much longer). So, to answer William's original question, one way or another we should provide a minimal CD with the speech software on it in my opinion. Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) One problem I will mention but in most cases wouldn't matter. Most dial-up ISPs have connect time limits. ATT for example is 12 hours, my current ISP is 10 but some are as little as 4 hours. When that limit is reached, it disconnects. This happens even if there is data flowing. If, this is a big if here, a person has one of these and cannot resume the download, this could become a issue even if they have a long connect time like ATT. I use Kget to download huge files or CDs since it has a resume feature. However, are the tools on the CD, wget I guess, resumable? I do think this is a good idea even if it is a separate CD to download. Also something to remember when making the stage tarballs I guess. Dale :-) :-)
Re: [gentoo-dev] rfc: Accessibility on our release media
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, May 23, 2009 at 07:32:18PM -0500, Dale wrote: Thomas Pani wrote: On Sun, May 24, 2009 at 1:14 AM, Andrew Gaffney agaff...@gentoo.org wrote: The real issue here is the size. If these additional packages plus all of the alsa modules add 20MB to the minimal CD, it's just not worth it. It's not minimal anymore. Could you elaborate whom that change would affect (negatively)? 83MB for current x86 isn't really minimal any more, anyway. I don't see the difference between 83MB and 103MB: - Makes no difference on blank CD (even those minis have ~200MB). - Regarding download size, well, after the CD you'll have to get the stage tarball and most probably source tarballs as well. -- Thomas Pani For a person on dial-up, about 2 1/2 hours of additional download. That said, I'd be OK with the increase in size if it would help a person who can't see the screen. It is impossible for a person who can't see the screen to install gentoo linux from our current release media unless they do what I did, which was to have someone read the screen to me long enough to assist me with starting an ssh server on the livecd and figure out the IP address of the computer, so that I could ssh in from my second computer to do the install. In other words, putting this software on our media will not just help, but make it possible for a blind person to install gentoo independently. Only adding the software to the live cd is not an option for me, because I feel that all of our release media should be accessible. Yes, there will be a size increase for the release media, but, unless the alsa modules and alsa-utils are over 15 mb, it will not be a 20 mb increase. - -- William Hubbs gentoo accessibility team lead willi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoYpmQACgkQblQW9DDEZThbRwCdGswP4rJIEkREb54LG9Z3PjjH eF0AmQHXE6keEZDxA2r0bLe1rfakmR9C =ThQY -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: Accessibility on our release media
On Sat, 23 May 2009 20:12:17 -0500 Dale rdalek1...@gmail.com wrote: Ferris McCormick wrote: If the 20MB is a real problem, I think the alternative is to have two versions of the minimal CD. Otherwise it seems to me that Gentoo is discriminating against people who cannot see the screen, and I would consider that to be very tacky at best. Someone (rdalek1967) said the problem was an extra 2.5 hours time for download over dialup. If that is correct, we are looking at 12.5 hours instead of 10 hours (about 25% increase, but 10 hours is a long time, and I don't know that 12.5 hours is subjectively that much longer). So, to answer William's original question, one way or another we should provide a minimal CD with the speech software on it in my opinion. Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) One problem I will mention but in most cases wouldn't matter. Most dial-up ISPs have connect time limits. ATT for example is 12 hours, my current ISP is 10 but some are as little as 4 hours. When that limit is reached, it disconnects. This happens even if there is data flowing. If, this is a big if here, a person has one of these and cannot resume the download, this could become a issue even if they have a long connect time like ATT. I use Kget to download huge files or CDs since it has a resume feature. However, are the tools on the CD, wget I guess, resumable? wget claims it is: The example in the man page is === wget -c ftp://sunsite.doc.ic.ac.uk/ls-lR.Z If there is a file named ls-lR.Z in the current directory, Wget will assume that it is the first portion of the remote file, and will ask the server to continue the retrieval from an offset equal to the length of the local file. I do think this is a good idea even if it is a separate CD to download. Also something to remember when making the stage tarballs I guess. Dale :-) :-) Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: Accessibility on our release media
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, May 23, 2009 at 08:12:17PM -0500, Dale wrote: Ferris McCormick wrote: If the 20MB is a real problem, I think the alternative is to have two versions of the minimal CD. Otherwise it seems to me that Gentoo is discriminating against people who cannot see the screen, and I would consider that to be very tacky at best. Someone (rdalek1967) said the problem was an extra 2.5 hours time for download over dialup. If that is correct, we are looking at 12.5 hours instead of 10 hours (about 25% increase, but 10 hours is a long time, and I don't know that 12.5 hours is subjectively that much longer). So, to answer William's original question, one way or another we should provide a minimal CD with the speech software on it in my opinion. Keep in mind that if we produce a separate cd with the speech software, that means yet another cd for each architecture that we know the speech software runs on, so I think the better route would be to just put it on all of our media that we produce for the affected architectures instead of asking releng to produce a separate cd for each release or autobuild. - -- William Hubbs gentoo accessibility team lead willi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoYr30ACgkQblQW9DDEZTglhgCgtLVGTtFjMCn3CsLxcAddj9iQ c7YAoLOnpvcO9aB+qeu+Ba19vPaPuxdN =heml -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: Accessibility on our release media
William Hubbs wrote: On Sat, May 23, 2009 at 07:32:18PM -0500, Dale wrote: For a person on dial-up, about 2 1/2 hours of additional download. That said, I'd be OK with the increase in size if it would help a person who can't see the screen. It is impossible for a person who can't see the screen to install gentoo linux from our current release media unless they do what I did, which was to have someone read the screen to me long enough to assist me with starting an ssh server on the livecd and figure out the IP address of the computer, so that I could ssh in from my second computer to do the install. In other words, putting this software on our media will not just help, but make it possible for a blind person to install gentoo independently. Only adding the software to the live cd is not an option for me, because I feel that all of our release media should be accessible. Yes, there will be a size increase for the release media, but, unless the alsa modules and alsa-utils are over 15 mb, it will not be a 20 mb increase. Maybe I am being misunderstood. I'm all for it even if it does make it bigger. It's a good idea in my opinion. Dale :-) :-)
Re: [gentoo-dev] rfc: Accessibility on our release media
William Hubbs wrote: On Sat, May 23, 2009 at 08:12:17PM -0500, Dale wrote: Ferris McCormick wrote: If the 20MB is a real problem, I think the alternative is to have two versions of the minimal CD. Otherwise it seems to me that Gentoo is discriminating against people who cannot see the screen, and I would consider that to be very tacky at best. Someone (rdalek1967) said the problem was an extra 2.5 hours time for download over dialup. If that is correct, we are looking at 12.5 hours instead of 10 hours (about 25% increase, but 10 hours is a long time, and I don't know that 12.5 hours is subjectively that much longer). So, to answer William's original question, one way or another we should provide a minimal CD with the speech software on it in my opinion. Keep in mind that if we produce a separate cd with the speech software, that means yet another cd for each architecture that we know the speech software runs on, so I think the better route would be to just put it on all of our media that we produce for the affected architectures instead of asking releng to produce a separate cd for each release or autobuild. I agree. I think it is a good idea regardless of if it is a separate CD or not. If the people that does this wants to make it a separate CD, that's cool too. Otherwise, just add it to the CD that we already have. Dale :-) :-)
Re: [gentoo-dev] rfc: Accessibility on our release media
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, May 23, 2009 at 09:47:24PM -0500, Dale wrote: Maybe I am being misunderstood. I'm all for it even if it does make it bigger. It's a good idea in my opinion. Hi Dale, no, I didn't misunderstand you, and I am sorry if I came across that way. I just wanted to make sure that everyone here knows that this isn't just something that would help blind users to be able to install our distro. It would do more than help, it would make it possible. :-) - -- William Hubbs gentoo accessibility team lead willi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoYuyAACgkQblQW9DDEZTiyhwCdFnwZGghO0JfhT0PmTfU0elBY fM8AnjXxOtQFWeDMTGYrsFXA3LrgMPf/ =9Dnm -END PGP SIGNATURE-
[gentoo-dev] Last rites: dev-python/glewpy and dev-python/pycrash
Hello everyone, dev-python/pycrash and dev-python/glewpy are either dead or unmaintained so im masking them for removal in 30 days. There are some non-fixable bugs regarding this packages. (see bug #198330 for glewpy and #221267 for pycrash) Best regards, Jesus Rivero (Neurogeek) Gentoo Python Team signature.asc Description: OpenPGP digital signature
