[gentoo-dev] Lastrites: dev-libs/libtomcrypt, app-admin/srlog2, dev-libs/tomsfastmath, gnome-extra/hardware-monitor, dev-dotnet/gluezilla
# Pacho Ramos pa...@gentoo.org (18 Mar 2012) # Broken in several ways, removal in 30 days. # Bug 262601 dev-libs/libtomcrypt app-admin/srlog2 dev-libs/tomsfastmath # Pacho Ramos pa...@gentoo.org (18 Mar 2012) # Upstream dead, nobody willing to maintain it and # buggy, bug #348500. Removal in 30 days. gnome-extra/hardware-monitor # Pacho Ramos pa...@gentoo.org (18 Mar 2012) # Unmaintained, nothing needs it, bug #363205 # Removal in 30 days. dev-dotnet/gluezilla signature.asc Description: This is a digitally signed message part
Anybody willing to take care of sgml herd? (Was: Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty)
El dom, 18-03-2012 a las 18:01 +0100, Pacho Ramos escribió: El vie, 09-03-2012 a las 21:21 +0100, Pacho Ramos escribió: El vie, 09-03-2012 a las 21:15 +0100, Pacho Ramos escribió: El vie, 09-03-2012 a las 22:02 +0200, Samuli Suominen escribió: On 03/09/2012 09:48 PM, Pacho Ramos wrote: El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió: On Fri, 09 Mar 2012 09:02:23 +0100 Pacho Ramospa...@gentoo.org wrote: El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: Even if they have some people in their mail aliases, looks like herds are empty. If nobody volunteers to join to them, I think we should drop that herds and move their packages to maintainer-needed in a week or so. What do you think? The same applies to sgml now that cryos is retiring :( and text-markup, I think it's the last empty herd now Maybe we could do the same as did in the past for openoffice herd: - Change metadatas and bugs to assign them to maintainer-needed (and reflect reality) - Keep herd in metadatas and CCed them to bug reports The other option would be to simply drop that herds, assign packages to maintainer-needed and wait developers to grab whatever they want For net-zope, I'd prefer dropping it. We decided to get rid of Zope, removed almost all relevant packages, so there's no point in keeping the herd. OK but, what about the rest? ;) Please leave at least media-optical@ be as it is. Changing it doesn't make any sense. Well, the idea would be to get their bugs assigned to maintainer-needed and media-optical CCed if somebody wants to take that stuff someday, it would reflect better reality as, currently, their bugs are being assigned to an empty herd (yes, xarthisius (I think he was in alias but not officially in herd last time I checked, anyway it's only one example, nothing personal against him of course :)). What will occur when he simply drops his mail from alias as he never wanted to be a member of that herd? What would occur if he only wants to maintain some packages but others are getting ignored? The idea to get them moved to orphan is to reflect reality and, that way, try to get developers (or users willing to proxy maintain them) involved on exact apps they really want to keep maintained. As talked just now with Samuli, he added him to media-optical (both, to alias and herds.xml) and then, this no longer applies to media-optical obviously ;) Will then do the following: - Add a maintainer tag to their metadatas to get bugs assigned to maintainer-needed - Keep herd to get it CCed (like was done some weeks ago with openoffice herd) This applies to sgml and text-markup since media-optical is active again and looks like net-zope packages will go away soon Finally, only sgml is inside this case as it contains a lot of packages: app-doc/halibut app-emacs/nxml-mode app-emacs/psgml app-office/passepartout app-text/asciidoc app-text/build-docbook-catalog app-text/docbook-dsssl-stylesheets app-text/docbook-sgml-dtd app-text/docbook-sgml-utils app-text/docbook-sgml app-text/docbook-xml-dtd app-text/docbook-xml-simple-dtd app-text/docbook-xsl-stylesheets app-text/docbook2X app-text/gentoo-guide-xml-dtd app-text/gnome-doc-utils app-text/grutatxt app-text/highlight app-text/html-xml-utils app-text/html2text app-text/html401 app-text/htmlrecode app-text/htmltidy app-text/linuxdoc-tools app-text/openjade app-text/opensp app-text/robodoc app-text/sablotron app-text/scrollkeeper-dtd app-text/scrollkeeper app-text/sgml-common app-text/sgmltools-lite app-text/sgrep app-text/txt2tags app-text/webgen app-text/xhtml1 app-text/xml2 app-text/xml2doc app-text/xmlformat app-text/xmlstarlet app-text/xmlto dev-ruby/xml-simple www-client/htmlview Is anyone willing to join the herd? If not, maybe somebody could take a few packages if they want to take care of only a set of them and not all the beast :-/ signature.asc Description: This is a digitally signed message part
Re: Anybody willing to take care of sgml herd? (Was: Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty)
El dom, 18-03-2012 a las 13:38 -0400, Mike Gilbert escribió: On Sun, Mar 18, 2012 at 1:28 PM, Pacho Ramos pa...@gentoo.org wrote: Is anyone willing to join the herd? If not, maybe somebody could take a few packages if they want to take care of only a set of them and not all the beast :-/ I took a look at the sgml bugs list, and most of them seem pretty straightforward. I'll add myself and work on them as I have time. Please don't let that stop you if you are thinking of picking up any of the packages in pacho's list. Thanks a lot Mike :D signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
El vie, 09-03-2012 a las 21:21 +0100, Pacho Ramos escribió: El vie, 09-03-2012 a las 21:15 +0100, Pacho Ramos escribió: El vie, 09-03-2012 a las 22:02 +0200, Samuli Suominen escribió: On 03/09/2012 09:48 PM, Pacho Ramos wrote: El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió: On Fri, 09 Mar 2012 09:02:23 +0100 Pacho Ramospa...@gentoo.org wrote: El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: Even if they have some people in their mail aliases, looks like herds are empty. If nobody volunteers to join to them, I think we should drop that herds and move their packages to maintainer-needed in a week or so. What do you think? The same applies to sgml now that cryos is retiring :( and text-markup, I think it's the last empty herd now Maybe we could do the same as did in the past for openoffice herd: - Change metadatas and bugs to assign them to maintainer-needed (and reflect reality) - Keep herd in metadatas and CCed them to bug reports The other option would be to simply drop that herds, assign packages to maintainer-needed and wait developers to grab whatever they want For net-zope, I'd prefer dropping it. We decided to get rid of Zope, removed almost all relevant packages, so there's no point in keeping the herd. OK but, what about the rest? ;) Please leave at least media-optical@ be as it is. Changing it doesn't make any sense. Well, the idea would be to get their bugs assigned to maintainer-needed and media-optical CCed if somebody wants to take that stuff someday, it would reflect better reality as, currently, their bugs are being assigned to an empty herd (yes, xarthisius (I think he was in alias but not officially in herd last time I checked, anyway it's only one example, nothing personal against him of course :)). What will occur when he simply drops his mail from alias as he never wanted to be a member of that herd? What would occur if he only wants to maintain some packages but others are getting ignored? The idea to get them moved to orphan is to reflect reality and, that way, try to get developers (or users willing to proxy maintain them) involved on exact apps they really want to keep maintained. As talked just now with Samuli, he added him to media-optical (both, to alias and herds.xml) and then, this no longer applies to media-optical obviously ;) Will then do the following: - Add a maintainer tag to their metadatas to get bugs assigned to maintainer-needed - Keep herd to get it CCed (like was done some weeks ago with openoffice herd) This applies to sgml and text-markup since media-optical is active again and looks like net-zope packages will go away soon signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical and net-zope herds are empty
El dom, 04-03-2012 a las 15:11 +0100, Dirkjan Ochtman escribió: On Sun, Mar 4, 2012 at 14:31, Pacho Ramos pa...@gentoo.org wrote: Only two for net-zope, but many more for, for example, sgml and media-optical. We just cleaned out most of the net-zope packages. The remaining net-zope packages will be maintained by the python team; the net-zope herd can probably be removed. Cheers, Dirkjan Just moved two remaining packages to python ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo CJK team empty, or anyone knows about ibus?
El lun, 05-03-2012 a las 07:12 -0800, Jack Morgan escribió: I'd like to help with this and will take a look at the bug below. I'd like to be part of the cjk herd as well. On 03/05/12 05:56, Samuli Suominen wrote: Really need a reply on http://bugs.gentoo.org/405777 and nobody seems to be listening the cjk@ alias Should I just roll a dice and CC arch's? Thanks, Will CC cjk team then to let them know you are interested to join (looks like there are four devs in cjk alias...) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due iluxa retirement
Due his retirement the following packages need a new maintainer: dev-cpp/cppserv Thanks for taking them signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due jokey retirement
Due his retirement the following packages need a new maintainer: app-misc/ytree app-portage/maintainer-helper app-shells/pdmenu dev-libs/libmba dev-vcs/easygit net-misc/italc net-misc/proxytunnel net-misc/x-lite (has a proxy maintainer!) sys-fs/archfs Thanks for taking them signature.asc Description: This is a digitally signed message part
[gentoo-dev] lcd herd is empty
With jokey retirement (#118003) lcd has become empty, is anybody willing to join or should their packages be moved to maintainer-needed (CCing that empty herd to allow somebody joining in the future to easily resurrect the herd)? Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due bass retirement
Due his retirement the following packages need a new maintainer: app-admin/localepurge app-admin/recursos app-doc/ebookmerge app-misc/gnomecatalog dev-embedded/gnap-dev dev-embedded/gnap net-analyzer/midas-nms net-im/coccinella net-misc/htbinit net-nds/lat Thanks for taking them signature.asc Description: This is a digitally signed message part
[gentoo-dev] www-servers herd is empty
With bass retirement (#391429) lcd has become empty, is anybody willing to join or should their packages be moved to maintainer-needed (CCing that empty herd to allow somebody joining in the future to easily resurrect the herd)? Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] www-servers herd is empty
El dom, 18-03-2012 a las 20:29 -0400, Chris Reffett escribió: Hi, I'd be interested in helping with www-servers, but I would have to help by proxy because I am not a dev yet. Chris Reffett On 03/18/12 15:27, Pacho Ramos wrote: With bass retirement (#391429) lcd has become empty, is anybody willing to join or should their packages be moved to maintainer-needed (CCing that empty herd to allow somebody joining in the future to easily resurrect the herd)? Thanks Thanks for offering your help, will CC gentoo-dev mailing list and proxy-maint to see how we could handle this case signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Packages up for grabs due bass retirement
El dom, 18-03-2012 a las 23:56 -0600, Ryan Hill escribió: On Sun, 18 Mar 2012 20:25:58 +0100 Pacho Ramos pa...@gentoo.org wrote: Due his retirement the following packages need a new maintainer: app-doc/ebookmerge This is something bass wrote that grabs html manuals from http://htmlhelp.berlios.de (which doesn't exist anymore - it moved to http://code.google.com/p/htmlhelp/). I don't really see the usefulness of it since almost all of the content is just html versions of standard info/man pages. Anyways, it's completely broken as-is. I also though it could be treecleaned until I saw patches to fix that issues are included in: https://bugs.gentoo.org/show_bug.cgi?id=388927 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo CJK team empty, or anyone knows about ibus?
El lun, 19-03-2012 a las 13:32 +0900, Naohiro Aota escribió: Hi, It is great to hear Jack is willing to join cjk herd. I can help Jack working on cjk bugs. But, to be honest, I'm not familiar with recruiting process so I need some devs to do or to help me on the recruiting. Also I've read the Mentor Guide [1] and found your project lead must be CC'd. I'm concerning about this project. Does he need some project to join in? or is it just enough to join cjk herd? [1] http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml I think joining to cjk would be enough :-/ Pacho Ramos pa...@gentoo.org writes: El lun, 05-03-2012 a las 07:12 -0800, Jack Morgan escribió: I'd like to help with this and will take a look at the bug below. I'd like to be part of the cjk herd as well. On 03/05/12 05:56, Samuli Suominen wrote: Really need a reply on http://bugs.gentoo.org/405777 and nobody seems to be listening the cjk@ alias Should I just roll a dice and CC arch's? Thanks, Will CC cjk team then to let them know you are interested to join (looks like there are four devs in cjk alias...) signature.asc Description: This is a digitally signed message part
[gentoo-dev] About maintaining sci-physics/abinit
Hello As talked some time ago with Donnie, sci-physics/abinit is hard to maintain and, then, he would like to lastrite it after moving package to sci overlay because looks like nobody from sci team wants to take it. If anybody is willing to help with maintaining abinit, could he take it? If not, could anybody with commit access to sci overlay to move abinit to it and let us lastrite it from main tree? Thanks a lot signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due jokey retirement
El lun, 19-03-2012 a las 10:56 -0500, Paul Varner escribió: On 03/18/12 13:50, Pacho Ramos wrote: Due his retirement the following packages need a new maintainer: app-portage/maintainer-helper Thanks for taking them I've added app-portage/maintainer-helper to the tools-portage herd, however, I've left it as maintainer-needed. So if anyone wants to take it, feel free. The tools-portage herd will fix bugs for it as we find the time. Regards, Paul I disagree with leaving maintainer-needed as default assign, if you will fix bugs when you have time it's better than what I will do with maintainer-needed packages. Also, I think most of maintainers would like to have help with a lot of packages, but that is not enough reason to change their metadatas to get bugs assigned to maintainer-needed and us CCed Have you seen any case when if anyone wants to take it he is not able to because the package is owned by a herd? If you want to promote that package be taken by other as soon as possible, add a note to metadata telling that (I have seen it in some cases) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] www-servers herd is empty
El lun, 19-03-2012 a las 20:48 +, Markos Chandras escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/19/2012 08:32 AM, Pacho Ramos wrote: El dom, 18-03-2012 a las 20:29 -0400, Chris Reffett escribió: Hi, I'd be interested in helping with www-servers, but I would have to help by proxy because I am not a dev yet. Chris Reffett On 03/18/12 15:27, Pacho Ramos wrote: With bass retirement (#391429) lcd has become empty, is anybody willing to join or should their packages be moved to maintainer-needed (CCing that empty herd to allow somebody joining in the future to easily resurrect the herd)? Thanks Thanks for offering your help, will CC gentoo-dev mailing list and proxy-maint to see how we could handle this case It is very unlikely for proxy-maintainers to proxy an entire herd. Sorry - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 We need to try to find a way to let him contribute, the problem is that I don't know much about Chris to know if he is ready to try to become a gentoo-dev in the near future :S signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due jokey retirement
El lun, 19-03-2012 a las 22:41 -0500, Paul Varner escribió: On 3/19/12 2:26 PM, Pacho Ramos wrote: El lun, 19-03-2012 a las 10:56 -0500, Paul Varner escribió: On 03/18/12 13:50, Pacho Ramos wrote: Due his retirement the following packages need a new maintainer: app-portage/maintainer-helper Thanks for taking them I've added app-portage/maintainer-helper to the tools-portage herd, however, I've left it as maintainer-needed. So if anyone wants to take it, feel free. The tools-portage herd will fix bugs for it as we find the time. I disagree with leaving maintainer-needed as default assign, if you will fix bugs when you have time it's better than what I will do with maintainer-needed packages. Okay, I've taken out the maintainer-needed as the maintainer and have just left it assigned to the herd. However, in reading through http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=4, I don't see a good mechanism to convey that the package is up for grabs, but in the meantime go ahead and assign any bugs to the herd. Regards, Paul Yeah, a mechanism for indicating a package is up for grabs would be interesting, the problem is how to prevent people from tagging as so a lot of packages and, then, making that mechanism completely useless as wouldn't distinct between real up for grabs packages or not as real :( But thanks a lot for taking care :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] www-servers herd is empty
El mar, 20-03-2012 a las 11:40 +0200, Samuli Suominen escribió: On 03/20/2012 11:36 AM, Pacho Ramos wrote: El lun, 19-03-2012 a las 20:48 +, Markos Chandras escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/19/2012 08:32 AM, Pacho Ramos wrote: El dom, 18-03-2012 a las 20:29 -0400, Chris Reffett escribió: Hi, I'd be interested in helping with www-servers, but I would have to help by proxy because I am not a dev yet. Chris Reffett On 03/18/12 15:27, Pacho Ramos wrote: With bass retirement (#391429) lcd has become empty, is anybody willing to join or should their packages be moved to maintainer-needed (CCing that empty herd to allow somebody joining in the future to easily resurrect the herd)? Thanks Thanks for offering your help, will CC gentoo-dev mailing list and proxy-maint to see how we could handle this case It is very unlikely for proxy-maintainers to proxy an entire herd. Sorry - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 We need to try to find a way to let him contribute, the problem is that I don't know much about Chris to know if he is ready to try to become a gentoo-dev in the near future :S I find the whole concept of www-servers herd flawed. It's not very likely one person would be running many different servers, and thus be able to contribute to them. Propably why the team has no members in the first place... Then, the way to go would be to move them to maintainer-needed and let people pick whatever they want. I agree and can do it myself just now if you let me do signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due www-server herd removal
As discussed in [gentoo-dev] www-servers herd is empty thread, we agreed with dropping this herd and let people get what they want to maintain. This is the list of orphan packages: www-servers/boa www-servers/bozohttpd www-servers/cherokee www-servers/fnord www-servers/lighttpd www-servers/mini_httpd www-servers/monkeyd www-servers/pound www-servers/pshs www-servers/publicfile www-servers/spawn-fcgi www-servers/thttpd www-servers/varnish www-servers/webfs Thanks for taking them signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Packages up for grabs due www-server herd removal
El mié, 21-03-2012 a las 12:26 +0100, Pacho Ramos escribió: As discussed in [gentoo-dev] www-servers herd is empty thread, we agreed with dropping this herd and let people get what they want to maintain. This is the list of orphan packages: [...] www-servers/bozohttpd [...] This is a false positive: it already has a maintainer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Packages up for grabs due www-server herd removal
El mié, 21-03-2012 a las 12:28 +0100, Pacho Ramos escribió: El mié, 21-03-2012 a las 12:26 +0100, Pacho Ramos escribió: As discussed in [gentoo-dev] www-servers herd is empty thread, we agreed with dropping this herd and let people get what they want to maintain. This is the list of orphan packages: [...] www-servers/bozohttpd [...] This is a false positive: it already has a maintainer The same for: www-servers/lighttpd www-servers/pshs signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] www-servers herd is empty
El jue, 22-03-2012 a las 15:46 +, Sven Vermeulen escribió: On Wed, Mar 21, 2012 at 09:22:19AM +0100, Dirkjan Ochtman wrote: Then, the way to go would be to move them to maintainer-needed and let people pick whatever they want. I agree and can do it myself just now if you let me do Seems sensible. I also dont mind helping out here, I use nginx, privoxy, squid and apache on a daily basis (albeit not to their full potential). Wkr, Sven Vermeulen The herd removal and assign to maintainer-needed was already done, then, feel free to add yourself to metadatas you prefer ;) (and remember to reassign existing bugs) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: net-im/msn-transport, net-im/yahoo-transport, net-p2p/giftoxic, net-p2p/dchub, dev-cpp/cppcsp2, dev-util/radare, www-servers/mini_httpd, net-analyzer/midas-nms, media-sound/dem
# Pacho Ramos pa...@gentoo.org # Fails to build (#239789), dead project (#303695). # Removal in 30 days. net-im/msn-transport # Pacho Ramos pa...@gentoo.org # Fails to build (#153266), dead. Removal in 30 days. net-im/yahoo-transport # Pacho Ramos pa...@gentoo.org # Segfaults, bug #168802. Dead since 2003. Removal in # 30 days. net-p2p/giftoxic # Pacho Ramos pa...@gentoo.org # Fails to build (#205375), doesn't respect LDFLAGS # (#337310), dead since 2006 (#370603). Removal in 30 # days. net-p2p/dchub # Pacho Ramos pa...@gentoo.org # Fortify kills its tests (#294824), dead since 2009 # and nothing needs it in the tree. Removal in 30 days. dev-cpp/cppcsp2 # Pacho Ramos pa...@gentoo.org # Installs to hard-coded python paths (#297040), buffer # overflow (#337478), nobody willing to maintain/fix it. # Removal in 30 days. dev-util/radare # Pacho Ramos pa...@gentoo.org # Security bugs (#301909, #303755). Removal in 30 days. www-servers/mini_httpd # Pacho Ramos pa...@gentoo.org # Tries to install data from local install (#332469), # doesn't respect LDFLAGS (#332467), dead since 2004. # Removal in 30 days. net-analyzer/midas-nms # Pacho Ramos pa...@gentoo.org # Doesn't respect LDFLAGS (#334717), still using glib:1, # dead upstream. Removal in 30 days. media-sound/demolition # Pacho Ramos pa...@gentoo.org # Overflows and multiple other problems (#336606), # removal in 30 days. net-fs/coda # Pacho Ramos pa...@gentoo.org # Propietary now, overflows (#337087). Removal in 30 # days. dev-db/ingres # Pacho Ramos pa...@gentoo.org # Buffer overflow (#337676), no update since 2003. # Removal in 30 days. net-irc/echat # Pacho Ramos pa...@gentoo.org # Buffer overflow (#338151), no release since 2007, # nothing in the tree needs it. Removal in 30 days. media-libs/libgiigic # Pacho Ramos pa...@gentoo.org # Buffer overflow (#339746), upstream dead, bundles # some libs. Removal in 30 days. app-editors/cssed # Pacho Ramos pa...@gentoo.org # Buffer overflow (#339842), dead since 2006. Removal # in 30 days. net-im/gyach # Pacho Ramos pa...@gentoo.org # Buffer overflow (#343575), dead since 2006. Removal # in 30 days. net-analyzer/pathrate # Pacho Ramos pa...@gentoo.org # Upstream dead, fails to build with gcc-4.6 (#363465), # removal in 30 days. dev-libs/sucs # Pacho Ramos pa...@gentoo.org # Fails to build (#367697), dead project. Removal in # 30 days. x11-misc/expocity # Pacho Ramos pa...@gentoo.org # Became propietary and no longer provides linux version, # removal in 30 days. net-misc/x-lite # Pacho Ramos pa...@gentoo.org # Needs net-misc/mDNSResponder (#405395), dead since # 2005 and not compatible with recent asterisk. Removal # in 30 days. net-misc/asterisk-res_bondia signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages maintained by volkmar need a co-maintainer
Due lack of time, volkmar's packages need a co-maintainer as talked with him: app-emulation/playonlinux app-emulation/vboxgtk dev-libs/xmlrpc-epi dev-python/graphy dev-util/bam media-libs/pnglite media-video/miro net-misc/plowshare net-misc/yaydl sci-libs/plotmm Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
Hello I am a bit surprised handbook still doesn't suggest people to create a separate partition for /usr/portage tree. I remember my first Gentoo systems had it inside / and that lead to a lot of fragmentation, much slower emerge -pvuDN world (I benchmarked it when I changed my partitioning scheme to put /usr/portage) separate and a lot of disk space lost (I remember portage tree reached around 3 GB of disk space while I am now running with 300MB) Could handbook suggest people to put /usr/portage on a different partition then? The only doubt I have is what filesystem would be better for it, in my case I am using reiserfs with tail enabled, but maybe you have other different setups. Thanks for discussing this :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
Will start to reply but will take some time as I don't have much this days :( El mar, 27-03-2012 a las 20:01 +0200, Sven Vermeulen escribió: On Tue, Mar 27, 2012 at 07:49:00PM +0200, Pacho Ramos wrote: I am a bit surprised handbook still doesn't suggest people to create a separate partition for /usr/portage tree. I remember my first Gentoo systems had it inside / and that lead to a lot of fragmentation, much slower emerge -pvuDN world (I benchmarked it when I changed my partitioning scheme to put /usr/portage) separate and a lot of disk space lost (I remember portage tree reached around 3 GB of disk space while I am now running with 300MB) Could handbook suggest people to put /usr/portage on a different partition then? The only doubt I have is what filesystem would be better for it, in my case I am using reiserfs with tail enabled, but maybe you have other different setups. To be honest, I don't think it is wise to describe it in the Gentoo Handbook just yet. I don't mind having it documented elsewhere, but the separate partition is not mandatory for getting Gentoo up and running. The instructions currently also just give an example partition layout and tell users that different layouts are perfectly possible. We need to take into consideration what is needed (must) for a Gentoo installation, what is seriously recommended (should), what is nice to have (could), etc. And for me, having a separate /usr/portage is a nice-to-have imo. Wkr, Sven Vermeulen My idea is to add a comment about this because it's not obvious having portage tree in a common partition with the rest of the system has some problems like high fragmentation, waste of disk space and also performance problems. I discovered it empirically when trying to get emerge -pvuDN world a bit faster. Also, once a partition scheme is chosen when installing Gentoo at first time, it's sometimes difficult to modify (for example, I was luck in my cases because I had big swap partitions I shrinked a bit for portage tree. You can probably see it's nice-to-have (as partition scheme that is shown in handbook showing partitions for /var, /home...), but it's better than letting people put their portage trees in a standard partition with the rest of the system signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El mar, 27-03-2012 a las 14:34 -0400, Alexandre Rostovtsev escribió: On Tue, 2012-03-27 at 20:01 +0200, Sven Vermeulen wrote: On Tue, Mar 27, 2012 at 07:49:00PM +0200, Pacho Ramos wrote: I am a bit surprised handbook still doesn't suggest people to create a separate partition for /usr/portage tree. I remember my first Gentoo systems had it inside / and that lead to a lot of fragmentation, much slower emerge -pvuDN world (I benchmarked it when I changed my partitioning scheme to put /usr/portage) separate and a lot of disk space lost (I remember portage tree reached around 3 GB of disk space while I am now running with 300MB) Could handbook suggest people to put /usr/portage on a different partition then? The only doubt I have is what filesystem would be better for it, in my case I am using reiserfs with tail enabled, but maybe you have other different setups. To be honest, I don't think it is wise to describe it in the Gentoo Handbook just yet. I don't mind having it documented elsewhere, but the separate partition is not mandatory for getting Gentoo up and running. The instructions currently also just give an example partition layout and tell users that different layouts are perfectly possible. We need to take into consideration what is needed (must) for a Gentoo installation, what is seriously recommended (should), what is nice to have (could), etc. And for me, having a separate /usr/portage is a nice-to-have imo. [...] 2. The handbook should mention that a separate small /usr/portage partition can noticeably improve performance for users with a rotational hard drive, and that it's not needed for solid-state drives. It should also mention that using Gentoo with a separate /usr/portage partition will require some additional configuration (such as changing DISTDIR and PKGDIR to avoid running out of space). -Alexandre. This would be nice :D signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El mar, 27-03-2012 a las 14:53 -0400, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/03/12 02:47 PM, Rich Freeman wrote: On Tue, Mar 27, 2012 at 2:34 PM, Alexandre Rostovtsev tetrom...@gentoo.org The partitioning scheme is something that the user needs to decide on *before* getting Gentoo up and running. After the user had finished installing the operating system, it's too late to inform him about the advantages of a separate /usr/portage. Yes and no (if you have free space, you could easily move /usr/portage - some other changes are harder). However, you could extend this line of argument to raid, lvm, and even stuff like the use of systemd or an alternative package manager. All of those things are much easier to implement if you just start out with them. I'm all for creating a wiki to talk about some alternative options. Perhaps even link to it at the start of the handbook in the intro (if you're not in a rush and want to read about more advanced configurations, check out ...). However, I tend to agree that the handbook should be a nearly-foolproof no-frills Gentoo installation. You know, we have Code Listing 2.1: Filesystem Example in Section 4, we could always adjust that to have a /usr/portage partition in it (take a bit of space away from /home, or something) It doesn't recommend/require anything, but when users see it they'll think about it. This would be a good option, but I would anyway add a note warning people about the cons of having portage tree in a normal partition with the rest of the system, otherwise people could simply ignore that code listing because they could thing it's there simply on a try to get all system splitted ;) (for example, I don't usually have a separate partition for all what is listed there, only /, /home and /usr/portage) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El mar, 27-03-2012 a las 16:05 -0400, Alec Moskvin escribió: On Tuesday 27 March 2012 14:34:03, Alexandre Rostovtsev wrote: On Tue, 2012-03-27 at 20:01 +0200, Sven Vermeulen wrote: On Tue, Mar 27, 2012 at 07:49:00PM +0200, Pacho Ramos wrote: I am a bit surprised handbook still doesn't suggest people to create a separate partition for /usr/portage tree. I remember my first Gentoo systems had it inside / and that lead to a lot of fragmentation, much slower emerge -pvuDN world (I benchmarked it when I changed my partitioning scheme to put /usr/portage) separate and a lot of disk space lost (I remember portage tree reached around 3 GB of disk space while I am now running with 300MB) Could handbook suggest people to put /usr/portage on a different partition then? The only doubt I have is what filesystem would be better for it, in my case I am using reiserfs with tail enabled, but maybe you have other different setups. To be honest, I don't think it is wise to describe it in the Gentoo Handbook just yet. I don't mind having it documented elsewhere, but the separate partition is not mandatory for getting Gentoo up and running. The instructions currently also just give an example partition layout and tell users that different layouts are perfectly possible. We need to take into consideration what is needed (must) for a Gentoo installation, what is seriously recommended (should), what is nice to have (could), etc. And for me, having a separate /usr/portage is a nice-to-have imo. The partitioning scheme is something that the user needs to decide on *before* getting Gentoo up and running. After the user had finished installing the operating system, it's too late to inform him about the advantages of a separate /usr/portage. It does not have to be a separate *physical* partition. It could be set up as a loop device without any real downsides: /usr/portage/tree.ext4/usr/portage/tree ext4loop,noatime 0 0 An advantage is that it can be easily resized if necessary. IMHO, chapter 4 of the handbook needs the following changes: 1. ext4, not ext3, needs to be recommended as the default filesystem. We have kernel 3.2 marked stable, there is no need to keep talking about ext4 as if it's something experimental. 2. The handbook should mention that a separate small /usr/portage partition can noticeably improve performance for users with a rotational hard drive, and that it's not needed for solid-state drives. It should also mention that using Gentoo with a separate /usr/portage partition will require some additional configuration (such as changing DISTDIR and PKGDIR to avoid running out of space). -Alexandre. (I think this last reply can complete my replies to this thread for now :)) Looks then that there are several alternatives for portage tree, then, maybe the option would be to add a note to Gentoo Handbook explaining the cons of having portage tree on a standard partition and, then, put a link to a wiki page (for example) where all this alternatives are explained. What do you think about this approach? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El sáb, 31-03-2012 a las 08:44 +, Sven Vermeulen escribió: On Fri, Mar 30, 2012 at 10:06:18AM +0200, Pacho Ramos wrote: Looks then that there are several alternatives for portage tree, then, maybe the option would be to add a note to Gentoo Handbook explaining the cons of having portage tree on a standard partition and, then, put a link to a wiki page (for example) where all this alternatives are explained. What do you think about this approach? I don't like the cons approach, as it gives the impression that users are pushed into a negative solution, whereas the current situation works just fine for almost all users. The approach for a different partition is for performance reasons (which most users don't have any negative feelings about) and as such might be read as a ricer approach. But perhaps it would be more lean to just start with a wiki page (or document) for alternative / better partitioning layouts, and when that has stabilized then we can talk about Handbook integration, not? Wkr, Sven Vermeulen Current solution works but causes a really slow portage tree when ages passes (I still have a machine with tree in / and is really really slow but, since it's used by my father at his job, I am unable to solve it :( ). And not, I don't think it's a ricer approach at all, it's for performance and for save a lot of disk space too. About the wiki page, I can only document reiserfs+tail usage as it's the one I use and I know, about other alternatives like using squashfs, loop mount... I cannot promise anything as I simply don't know how to set them. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El sáb, 31-03-2012 a las 02:35 -0700, Brian Harring escribió: On Sat, Mar 31, 2012 at 08:44:02AM +, Sven Vermeulen wrote: On Fri, Mar 30, 2012 at 10:06:18AM +0200, Pacho Ramos wrote: Looks then that there are several alternatives for portage tree, then, maybe the option would be to add a note to Gentoo Handbook explaining the cons of having portage tree on a standard partition and, then, put a link to a wiki page (for example) where all this alternatives are explained. What do you think about this approach? I don't like the cons approach, as it gives the impression that users are pushed into a negative solution, whereas the current situation works just fine for almost all users. The approach for a different partition is for performance reasons (which most users don't have any negative feelings about) and as such might be read as a ricer approach. For modern hardware w/ a modern kernel (or at least =2.6.38 for the dcache resolution optimizations)... does anyone actually have real performance stats for this? If the notion is a seperate FS, one tailored to the portage tree's usage models (tail packing for example), sure, grok that although I question how much people really are getting out of it. In the past, situation definitely differed- I'm just wondering if the gain is actually worth debating it, rather than just ignoring it (or sticking it in a foot note for people trying to use durons). ~harring I did performance stats one year ago or so, but I don't have time to redo all of them to simply confirm how behave now with recent kernel (in that time, I checked reiserfs, ext2 with multiple block sizes). Regarding disk space usage, it's still valid today for sure signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El sáb, 31-03-2012 a las 19:25 -0400, Walter Dnes escribió: On Sat, Mar 31, 2012 at 10:42:50AM -0700, Zac Medico wrote On 03/31/2012 06:34 AM, Pacho Ramos wrote: About the wiki page, I can only document reiserfs+tail usage as it's the one I use and I know, about other alternatives like using squashfs, loop mount... I cannot promise anything as I simply don't know how to set them. Squashfs is really simple to use: mksquashfs /usr/portage portage.squashfs mount -o loop portage.squashfs /usr/portage Don't the space-saving filesystems (squashfs, reiserfs-with-tail, etc) run more slowly due to their extra finicky steps to save space? If you really want to save a gigabyte or 2, run eclean -d distfiles and localepurge after every emerge update. I've also cobbled together my own autodepclean script that check for, and optionally unmerges unneeded stuff that was pulled in as a dependancy of a package that has since been removed. I have distfiles on a completely different dir and, using different partition for ages for portage tree hasn't show that space saving problems signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Packages up for grabs due bass retirement
El lun, 19-03-2012 a las 21:20 -0600, Ryan Hill escribió: On Mon, 19 Mar 2012 09:34:22 +0100 Pacho Ramos pa...@gentoo.org wrote: El dom, 18-03-2012 a las 23:56 -0600, Ryan Hill escribió: On Sun, 18 Mar 2012 20:25:58 +0100 Pacho Ramos pa...@gentoo.org wrote: Due his retirement the following packages need a new maintainer: app-doc/ebookmerge This is something bass wrote that grabs html manuals from http://htmlhelp.berlios.de (which doesn't exist anymore - it moved to http://code.google.com/p/htmlhelp/). I don't really see the usefulness of it since almost all of the content is just html versions of standard info/man pages. Anyways, it's completely broken as-is. I also though it could be treecleaned until I saw patches to fix that issues are included in: https://bugs.gentoo.org/show_bug.cgi?id=388927 Okay, I suppose people do use it. I'd like to start an app-doc herd (I think vapier and me have half of app-doc/* covered anyways). This would fit in there. In the meantime I'll take it. Any news on this herd creation? Looks like that package is still in maintainer-needed domain, for now I have fixed all his bugs I think, but better create that one for this and other packages that could benefit from active maintainers :) Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About maintaining sci-physics/abinit
El lun, 19-03-2012 a las 10:22 +0100, Pacho Ramos escribió: Hello As talked some time ago with Donnie, sci-physics/abinit is hard to maintain and, then, he would like to lastrite it after moving package to sci overlay because looks like nobody from sci team wants to take it. If anybody is willing to help with maintaining abinit, could he take it? If not, could anybody with commit access to sci overlay to move abinit to it and let us lastrite it from main tree? Thanks a lot Maybe we could mask it for removal anyway as looks nobody wants to maintain it and our current versions are really old :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo CJK team empty, or anyone knows about ibus?
El lun, 19-03-2012 a las 09:37 +0100, Pacho Ramos escribió: El lun, 19-03-2012 a las 13:32 +0900, Naohiro Aota escribió: Hi, It is great to hear Jack is willing to join cjk herd. I can help Jack working on cjk bugs. But, to be honest, I'm not familiar with recruiting process so I need some devs to do or to help me on the recruiting. Also I've read the Mentor Guide [1] and found your project lead must be CC'd. I'm concerning about this project. Does he need some project to join in? or is it just enough to join cjk herd? [1] http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml I think joining to cjk would be enough :-/ Pacho Ramos pa...@gentoo.org writes: El lun, 05-03-2012 a las 07:12 -0800, Jack Morgan escribió: I'd like to help with this and will take a look at the bug below. I'd like to be part of the cjk herd as well. On 03/05/12 05:56, Samuli Suominen wrote: Really need a reply on http://bugs.gentoo.org/405777 and nobody seems to be listening the cjk@ alias Should I just roll a dice and CC arch's? Thanks, Will CC cjk team then to let them know you are interested to join (looks like there are four devs in cjk alias...) Any updates on this? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Doubts about need for ewarn when strip-linguas is used
El vie, 09-03-2012 a las 09:00 +0100, Pacho Ramos escribió:
El mar, 06-03-2012 a las 11:46 +0100, Pacho Ramos escribió:
I usually read messages in /var/log/portage/elog/summary.log to simply
warn me about es es_ES LINGUAS not being supported by that package.
That comes from eutils.eclass inside strip-linguas:
ewarn Sorry, but ${PN} does not support the LINGUAS: ${nols}
Is this warning really required, personally I know a lot of packages
that don't support spanish translations and I get no warning from them
(as they don't use strip-linguas). When I set LINGUAS variable in my
make.conf I assume a lot of packages won't support spanish translations,
and I see no point on being informed about that for some packages using
strip-linguas.
What do you think?
OK with dropping message completely or use einfo instead of ewarn?
Just done
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [RFC] enable verbose build whenever it's possible
El sáb, 05-11-2011 a las 21:03 -0600, Ryan Hill escribió: On Sat, 5 Nov 2011 21:00:32 +0100 Maciej Mrozowski reave...@gmail.com wrote: I've seen too many bugs reports today that gave me cute, colorful build.logs and almost no information about underlaying bug... That's usually because users sometimes attach only relevant parts of build log (well, relevant according to their taste = last lines, even when they use parallel compilation). I think you're confusing build log with build output. Any particular example of bug report with entire build log from cmake-utils in fancy mode, and still being unable to locate the problem? I ask, because we're appending summary just after configure phase to make vorbose logging of whole build process unecessary. How are you supposed to debug a compile or linker error without the compiler command line? How all this ended up? It would still be nice to have verbose output enabled by default (even people being able to use emerge --quiet to silent it) to check for undesired flags (like -Werror, -DG_DISABLE_DEPRECATED...) easily :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About maintaining sci-physics/abinit
El mar, 03-04-2012 a las 08:43 +0200, justin escribió: On 03/04/12 00:11, Pacho Ramos wrote: El lun, 19-03-2012 a las 10:22 +0100, Pacho Ramos escribió: Hello As talked some time ago with Donnie, sci-physics/abinit is hard to maintain and, then, he would like to lastrite it after moving package to sci overlay because looks like nobody from sci team wants to take it. If anybody is willing to help with maintaining abinit, could he take it? If not, could anybody with commit access to sci overlay to move abinit to it and let us lastrite it from main tree? Thanks a lot Maybe we could mask it for removal anyway as looks nobody wants to maintain it and our current versions are really old :/ Oh I am sorry for not replying. We have a contributor who is doing a great job and maintains it in the sci overlay. As there is currently no active contribution from the developer teams site I would vote for removal and help Honza with his contributions outside the tree. justin Done: https://bugs.gentoo.org/show_bug.cgi?id=410639 Best regards signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due mrness retirement
Due his retirement the following packages need a new maintainer: dev-util/dialogblocks dev-util/helpblocks net-mail/sendEmail net-misc/openswan net-misc/taylor-uucp Thanks for taking them signature.asc Description: This is a digitally signed message part
[gentoo-dev] About how to handle wxGTK based packages with gnome profiles
Currently gnome profiles enable automatically gtk USE flag and, then, most gtk based GUIs are installed by default on systems using that profile. A special situation occurs when the package is based in wxGTK as explained in: https://bugs.gentoo.org/show_bug.cgi?id=411053 Currently, packages like mkvtoolnix simply builds without no gui at all when using gnome profile because its gui is build with wxwidgets USE flag. At first, I suggested to move from wxwidgets to gtk USE flag for that package because that wxwidgets based gui is the only gtk gui offered by that package. The problem is that their maintainers disagree with that approach as explained in referred bug report. Other option would be to enable wxwidgets by default for that profiles. What do you think? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About how to handle wxGTK based packages with gnome profiles
El mar, 10-04-2012 a las 09:12 +0200, Paweł Hajdan, Jr. escribió: On 4/10/12 8:58 AM, Pacho Ramos wrote: Other option would be to enable wxwidgets by default for that profiles. I prefer this. Changing USE flag meaning in a counter-intuitive way (to let gtk mean wxwidgets) would seem frustrating to me. With wxwidgets enabled by default people will get the most likely desired result (i.e. GUI) out of the box, and setting USE=-wxwidgets will have desired effect. Note that with USE=gtk really meaning USE=wxwidgets, -wxwidgets would have no effect on such a package, which is the potentially surprising behavior I mentioned earlier. OK, looks like I misunderstood how wxwidgets work and most opinions point to enable wxwidgets by default in gnome profiles, ok with that solution? signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages maintained by trapni need a co-maintainer
Due long devaway, his packages need a co-maintainer, feel free to add to metadata if you want. Thanks: dev-util/ciabot-svn media-sound/teamspeak-client-bin media-sound/teamspeak-server-bin sys-apps/newrelic-sysmond signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages maintained by mduft need a co-maintainer
Due long devaway, his packages need a co-maintainer, feel free to add to metadata if you want. Thanks: app-portage/prefix-chain-setup net-proxy/cntlm sys-apps/prefix-chain-utils sys-devel/parity sys-libs/itx-bind sys-libs/suacomp signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages maintained by trapni need a co-maintainer
El sáb, 14-04-2012 a las 14:24 +0300, Samuli Suominen escribió: On 04/14/2012 02:16 PM, Pacho Ramos wrote: Due long devaway, his packages need a co-maintainer, feel free to add to metadata if you want. Thanks: dev-util/ciabot-svn media-sound/teamspeak-client-bin media-sound/teamspeak-server-bin sys-apps/newrelic-sysmond I believe it's time to lastrite teamspeak* because they link against mysql libraries with SONAME we don't ship anymore Therefore rendering the packages useless - Samuli Fine with me if nobody wants to take care of that package and fixing it soon signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About adding a way to check for bugs referring to no longer existing packages in the tree
El sáb, 14-04-2012 a las 12:42 -0300, Alexis Ballier escribió: On Sat, 14 Apr 2012 13:02:27 +0200 Pacho Ramos pa...@gentoo.org wrote: Hello From time to time I see old bug reports that are still wrongly opened and referring to old packages no longer in the tree. Would be possible to add a way to periodically check for bugs referring in summary to obsolete packages and, then, allow us to have a cleaner bug list? -1, you really cant automate this. - for eg, keyword req, the version doesnt really matter and is usually just there to help but should really be read as latest version; closing/ignoring the bug while the latest version still lacks the keywords is just wrong. - for stablereq, that's a different story - for other bugs, some may have been fixed independently upstream, but usually, they dont fix by themselves, so if a bug didnt get attention, chances are its still valid. moreover, doing this, you'll just encourage people not to fill the version IOW: If you want a cleaner bug list, ignore stable/kw reqs, then pay attention to your bugs and fix them :) A. It's not for versions, only package names (there are still bugs referring to already removed packages for months) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About adding a way to check for bugs referring to no longer existing packages in the tree
El dom, 15-04-2012 a las 02:47 -0600, Ryan Hill escribió:
From time to time I see old bug reports that are still wrongly opened
and referring to old packages no longer in the tree. Would be possible
to add a way to periodically check for bugs referring in summary to
obsolete packages and, then, allow us to have a cleaner bug list?
How exactly would you do this? Maintain a list of all packages ever removed
from the tree? What if the package name is a common word? What about bugs
requesting a previously removed package be re-added? Or a different
project using the same name?
Well, I currently manually do eix searching to check it, maybe would be
a way to compare eix outputs with ${CATEGORY}/${PKGNAME} from bug
summaries (bugs without that naming structure would be uncovered by
this, but we would still be able to easily check for obsolete bug
reports).
Regarding bugs asking package to be readded, that bugs should be
assigned to maintainer-wanted and, then, could be filtered.
It's not for versions, only package names (there are still bugs
referring to already removed packages for months)
The person dumping the package should be checking for open bugs at the time
of removal.
I agree... but it's usually forgotten as I have seen
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] About validate_desktop_entries in eutils.eclass
Hello I am unsure about validate_desktop_entries() utility. It's currently provided by eutils.eclass and only called by net-firewall/fwbuilder. Shouldn't this be moved to a qa check? Current way is pretty useless as it's not used by most of packages, and calling it from a lot of eclasses/ebuilds doesn't sound me like a good idea. What do you think? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About adding a way to check for bugs referring to no longer existing packages in the tree
El dom, 15-04-2012 a las 11:55 +0200, Pacho Ramos escribió:
El dom, 15-04-2012 a las 02:47 -0600, Ryan Hill escribió:
From time to time I see old bug reports that are still wrongly opened
and referring to old packages no longer in the tree. Would be possible
to add a way to periodically check for bugs referring in summary to
obsolete packages and, then, allow us to have a cleaner bug list?
How exactly would you do this? Maintain a list of all packages ever removed
from the tree? What if the package name is a common word? What about bugs
requesting a previously removed package be re-added? Or a different
project using the same name?
Well, I currently manually do eix searching to check it, maybe would be
a way to compare eix outputs with ${CATEGORY}/${PKGNAME} from bug
summaries (bugs without that naming structure would be uncovered by
this, but we would still be able to easily check for obsolete bug
reports).
Regarding bugs asking package to be readded, that bugs should be
assigned to maintainer-wanted and, then, could be filtered.
It's not for versions, only package names (there are still bugs
referring to already removed packages for months)
The person dumping the package should be checking for open bugs at the time
of removal.
I agree... but it's usually forgotten as I have seen
Also, the idea is to simply generate a list with possible obsolete bug
reports, closing would still be done manually after checking for false
positives ;)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About validate_desktop_entries in eutils.eclass
El dom, 15-04-2012 a las 16:02 +0200, Michał Górny escribió: On Sun, 15 Apr 2012 11:59:50 +0200 Pacho Ramos pa...@gentoo.org wrote: I am unsure about validate_desktop_entries() utility. It's currently provided by eutils.eclass and only called by net-firewall/fwbuilder. Shouldn't this be moved to a qa check? Current way is pretty useless as it's not used by most of packages, and calling it from a lot of eclasses/ebuilds doesn't sound me like a good idea. What do you think? Agreed. It should be in repoman. The check needs to be run over desktop file going to be installed, not sure how repoman can handle it, it looked to me more like a emerge job (like is done with other qa checks run before installation) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About adding a way to check for bugs referring to no longer existing packages in the tree
El dom, 15-04-2012 a las 17:47 +0200, Marcin Mirosław escribió: W dniu 2012-04-14 13:02, Pacho Ramos pisze: Hello From time to time I see old bug reports that are still wrongly opened and referring to old packages no longer in the tree. Would be possible to add a way to periodically check for bugs referring in summary to obsolete packages and, then, allow us to have a cleaner bug list? Hi, what about siutation package was removed from tree. After sometime other maintainer wants to put this package to the tree again, shouldn't fix those bugs before doing this? Marcin As that results will simply be used to generate a list, it will be a good opportunity to really check that developer is taking care of it (I have also seen a lot of cases where a dev has a bug for this assigned to him for months without action) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About adding a way to check for bugs referring to no longer existing packages in the tree
El dom, 15-04-2012 a las 19:10 +0300, Samuli Suominen escribió: On 04/15/2012 06:47 PM, Marcin Mirosław wrote: W dniu 2012-04-14 13:02, Pacho Ramos pisze: Hello From time to time I see old bug reports that are still wrongly opened and referring to old packages no longer in the tree. Would be possible to add a way to periodically check for bugs referring in summary to obsolete packages and, then, allow us to have a cleaner bug list? Hi, what about siutation package was removed from tree. After sometime other maintainer wants to put this package to the tree again, shouldn't fix those bugs before doing this? Marcin When package foobar gets removed from Portage, the remaining bugs affecting foobar gets closed with resolution WONTFIX/OBSOLETE/FIXED depending on type of the bug. When package foobar gets readded to Portage, the maintainer needs to check also for closed bugs. That's how it is now, and the workflow wouldn't change with this proposal. So you are right, but irrelevant to the /topic in hand. - Samuli The problem is that, in reality, some bugs are forgotten and are keep opened. Currently, I manually check for them, but it's sometimes hard to do this manually. The idea of generating a QA report (like others in http://qa-reports.gentoo.org/) would allow me to easily review that list periodically to check that obsolete bugs are closed. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About how to handle wxGTK based packages with gnome profiles
El mié, 11-04-2012 a las 13:02 +0300, Samuli Suominen escribió: On 04/11/2012 09:12 AM, Ryan Hill wrote: On Tue, 10 Apr 2012 22:21:20 +0200 Pacho Ramospa...@gentoo.org wrote: OK, looks like I misunderstood how wxwidgets work and most opinions point to enable wxwidgets by default in gnome profiles, ok with that solution? As I mentioned in the bug I'd like it default for desktop. There's nothing inherently gnome about wxwidgets other than the fact that it uses gtk+ widgets. If the idea is that you won't get any gui at all if wxwidgets isn't enabled (and I can't think of any packages where this isn't true) then kde users should be included too. +1 wxwidgets is not limited to gnome users, so goes to profiles/targets/desktop/make.defaults OK then to enable wxwidgets in desktop profile? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About how to handle wxGTK based packages with gnome profiles
El dom, 15-04-2012 a las 23:58 -0600, Ryan Hill escribió: On Sun, 15 Apr 2012 18:59:11 +0200 Pacho Ramos pa...@gentoo.org wrote: OK then to enable wxwidgets in desktop profile? Yes. Just done signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About adding a way to check for bugs referring to no longer existing packages in the tree
El lun, 16-04-2012 a las 03:04 +0200, Jeroen Roovers escribió:
On Sun, 15 Apr 2012 11:55:04 +0200
Pacho Ramos pa...@gentoo.org wrote:
Well, I currently manually do eix searching to check it, maybe would
be a way to compare eix outputs with ${CATEGORY}/${PKGNAME} from bug
summaries (bugs without that naming structure would be uncovered by
this, but we would still be able to easily check for obsolete bug
reports).
I only started fixing summaries to include valid, canonical
cat/pkg[-ver] strings a few years ago because searching for a full
atom in bugzilla's search would otherwise (and still does) fail.
Before that it was mayhem, and it's mainly the older bugs you appear be
worried about. Having a list of bugs to fix the cat/pkg for would have
more uses than the one you're interested in.
jer
I obviously agree, but both suggestions are not mutually exclusive I
think :)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Packages maintained by mduft need a co-maintainer
El lun, 16-04-2012 a las 11:00 +0200, Michael Haubenwallner escribió: On 04/14/2012 01:30 PM, Pacho Ramos wrote: Due long devaway, his packages need a co-maintainer, feel free to add to metadata if you want. Thanks: app-portage/prefix-chain-setup sys-apps/prefix-chain-utils Even if prefix-chaining most likely is broken ATM in prefix-portage, (IMO) they still belong to prefix herd. Why have they shown up at all? I probably missed prefix there when running epkginfo -Hm over mduft packages sys-libs/suacomp sys-devel/parity sys-libs/itx-bind Added myself, target Interix/Windows only. Not sure if we can/want/should take them to prefix herd. net-proxy/cntlm Still open. /haubi/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages inside lcd herd up for grabs
As lcd herd is empty for some time, these are the packages that are for grabs now: app-misc/g15mpd app-misc/glcdprocdriver app-misc/lcd-stuff app-misc/lcd4linux app-misc/lcdproc dev-libs/luise-bin dev-libs/serdisplib media-libs/libirman I will move them to maintainer-needed (keeping lcd herd and it CCed to allow the herd to revive in the future more easily) in a week. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About adding a way to check for bugs referring to no longer existing packages in the tree
El lun, 16-04-2012 a las 10:40 +0200, Pacho Ramos escribió:
El lun, 16-04-2012 a las 03:04 +0200, Jeroen Roovers escribió:
On Sun, 15 Apr 2012 11:55:04 +0200
Pacho Ramos pa...@gentoo.org wrote:
Well, I currently manually do eix searching to check it, maybe would
be a way to compare eix outputs with ${CATEGORY}/${PKGNAME} from bug
summaries (bugs without that naming structure would be uncovered by
this, but we would still be able to easily check for obsolete bug
reports).
I only started fixing summaries to include valid, canonical
cat/pkg[-ver] strings a few years ago because searching for a full
atom in bugzilla's search would otherwise (and still does) fail.
Before that it was mayhem, and it's mainly the older bugs you appear be
worried about. Having a list of bugs to fix the cat/pkg for would have
more uses than the one you're interested in.
jer
I obviously agree, but both suggestions are not mutually exclusive I
think :)
This is another example I hit today:
https://bugs.gentoo.org/show_bug.cgi?id=247750
that would benefit from this QA report
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] About dropping webapps-unmaintained alias
It's simply pointing to maintainer-needed and no bug is assigned to it. If a webapp package is orphan, it should go to maintainer-needed directly I think The same for webapps-request, that is a link to maintainer-wanted Thanks :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo
El lun, 23-04-2012 a las 10:17 -0400, Mike Gilbert escribió: On Mon, Apr 23, 2012 at 8:28 AM, Duncan 1i5t5.dun...@cox.net wrote: Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted: Title: The default JPEG implementation [...] All users are recommended to migrate: # emerge -C media-libs/jpeg:0 # emerge -1 media-libs/libjpeg-turbo That of course leaves the system without a jpeg library between the jpeg unmerge and the completion of the libjpeg-turbo merge. If the build process fails for some reason... There's no way to use portage's automatic block-resolving ability here to avoid that, I take it? This works for me. floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] media-libs/libjpeg-turbo-1.2.0-r1 USE=-java -static-libs 0 kB [uninstall ] media-libs/jpeg-8d USE=-static-libs [blocks b ] media-libs/jpeg:0 (media-libs/jpeg:0 is blocking media-libs/libjpeg-turbo-1.2.0-r1) I guess it will work when jpeg is not in world file... maybe people should be told to drop it and, then, let emerge do all the work automatically. signature.asc Description: This is a digitally signed message part
[gentoo-dev] dev-embedded/tigcc needs an urgent bump
Our stable versions are broken for a long time, they even don't compile, but we cannot stable latest testing version because of a buffer overflow problem. A bump could help, but looks like embedded team doesn't have enough time for it. Is anybody interested in taking care of it? Its bugs: https://bugs.gentoo.org/buglist.cgi?quicksearch=tigcclist_id=978701 Thanks signature.asc Description: This is a digitally signed message part
Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
El vie, 27-04-2012 a las 21:12 +0100, Ciaran McCreesh escribió: On Fri, 27 Apr 2012 21:58:24 +0200 Michał Górny mgo...@gentoo.org wrote: Of course, if we take the 'quick EAPI 5 route', it won't include anything useful. In the meantime, do we have a complete list of candidates for EAPI 5? Let's continue this on the PMS list. * user patches * EAPI parsing * the things that were left out of 4: + slot operator deps + profile IUSE * No -j1 for src_test * Remove deprecated stuff * Zero or one REQUIRED_USE operator These might be cheap now? * New bash version * Get a versionator replacement into the PM Could: https://bugs.gentoo.org/show_bug.cgi?id=408693 be handled also? Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrite app-text/chmsee. Semi-lastrite libopensync-plugin-google-calendar.
El dom, 29-04-2012 a las 13:54 +0300, Samuli Suominen escribió: On 04/28/2012 01:17 PM, Michael Weber wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 According to upstreams homepage [1], the current tagged v1.99.09 does support xulrunner 11.0. There is no such thing as separate Xulrunner 11.0. There is Firefox 11.0 but upstream stopped splitting it from Firefox and our Firefox package doesn't ship with pkg-config files for it. So chmsee upstream very much failed... He should switch to something else, like webkit-gtk or gtkhtml. - Samuli The problem is that looks like other major distributions are still providing xulrunner (from firefox): http://pkgs.fedoraproject.org/gitweb/?p=xulrunner.git;a=tree http://download.opensuse.org/factory/repo/src-oss/suse/src/xulrunner-12.0-1.1.src.rpm http://packages.debian.org/sid/xulrunner-10.0 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] dev-embedded/tigcc needs an urgent bump
El lun, 23-04-2012 a las 20:35 +0200, Pacho Ramos escribió: Our stable versions are broken for a long time, they even don't compile, but we cannot stable latest testing version because of a buffer overflow problem. A bump could help, but looks like embedded team doesn't have enough time for it. Is anybody interested in taking care of it? Its bugs: https://bugs.gentoo.org/buglist.cgi?quicksearch=tigcclist_id=978701 Thanks Or maybe we should simply treeclean it if nobody is willing to fix/maintain it and since nothing in the tree needs it... signature.asc Description: This is a digitally signed message part
[gentoo-dev] About remembering to block bug 406437 for glib-2.32/gtk+-3.4 issues
Hello Please remember to make your bugs related with glib-2.32/gtk+-3.4 issues block bug 406437. That will allow us to get needed things stabilized in the future when we stabilize newer glib/gtk+ Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About validate_desktop_entries in eutils.eclass
El lun, 30-04-2012 a las 10:05 -0700, Zac Medico escribió: On 04/29/2012 09:45 AM, Petteri Räty wrote: On 15.04.2012 17:12, Pacho Ramos wrote: El dom, 15-04-2012 a las 16:02 +0200, Michał Górny escribió: On Sun, 15 Apr 2012 11:59:50 +0200 Pacho Ramos pa...@gentoo.org wrote: I am unsure about validate_desktop_entries() utility. It's currently provided by eutils.eclass and only called by net-firewall/fwbuilder. Shouldn't this be moved to a qa check? Current way is pretty useless as it's not used by most of packages, and calling it from a lot of eclasses/ebuilds doesn't sound me like a good idea. What do you think? Agreed. It should be in repoman. The check needs to be run over desktop file going to be installed, not sure how repoman can handle it, it looked to me more like a emerge job (like is done with other qa checks run before installation) There's actually already code in repoman that runs desktop-file-validate. It of course only works for installed packages. Someone could make it run runtime too. The repoman code works on $FILESDIR. It looks like we also want to run it after src_install. Also, it looks like we might need to handle a special case for Konqueror Service Menus: https://bugs.gentoo.org/show_bug.cgi?id=414125 Yes, I would like to also check other desktop files than those coming from FILESDIR signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] cmake-utils.eclass: set default of CMAKE_VERBOSE=1
El sáb, 05-05-2012 a las 09:49 +0200, Kacper Kowalik escribió: On 04.05.2012 18:30, hasufell wrote: # @ECLASS-VARIABLE: CMAKE_VERBOSE # @DESCRIPTION: # Set to enable verbose messages during compilation. By default this is deactivated which is inconvenient imo and results in pastes having minimum information. I have to tell users every time to recompile with CMAKE_VERBOSE=1 so that I have proper information on what is going on. Are there any arguments against this being default? Hi, It's been discussed previously here [1] with nack from cmake-utils.eclass maintainers and general conclusion that's too expensive to write to stdout :/ If you're gonna make it happen this time, I'll owe you a beer... Cheers, Kacper [1] http://archives.gentoo.org/gentoo-dev/msg_1b58b577fde07f7735ae6b9eb34885be.xml That would be a good step to get https://bugs.gentoo.org/show_bug.cgi?id=384193 implemented some day ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
El dom, 06-05-2012 a las 07:33 -0400, Rich Freeman escribió: On Sun, May 6, 2012 at 5:37 AM, Michał Górny mgo...@gentoo.org wrote: I don't think even heavyweight DE/WM usually needs ldap... Tend to agree. I don't think we want to create a new profile every time we want to change one of the flags. Some other questionable ones: emboss - Adds support for the European Molecular Biology Open Software Suite firefox - probably OK for what it does now, but not everybody uses it xulrunner - not even used now There will always be some level of variation if you are looking at single flags. What matters isn't coming up with profiles that exactly match all of our users, but rather ones that are good for 80+% of them. As far as ldap goes, if we wanted an enterprise desktop profile that might be a good fit for such a configuration. I agree that -ldap isn't really a lightweight desktop so much as a normal one. If you really wanted lightweight then you'd probably not be running desktop at all, or the regular desktop vs kde/gnome. Maybe desktop should be more lightweight oriented and for people (like me) wanting more, use gnome/kde instead (or create xfce/lxde... if they need other flags...) The bottom line is that we don't need 47 different profile targets - there will always be a use for 1 more. That's why we all run Gentoo - we aren't bound by the decisions made for us by the package maintainers. Rich signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
El dom, 06-05-2012 a las 14:41 +0300, Samuli Suominen escribió: eclass/ has a ChangeLog (and this is getting old that everyone keeps ignoring it, I've proposed punting the ChangeLog from eclass/ directory once, and repeating it now) Maybe we could punt ChangeLog from eclass/ and generate it automatically from commit messages signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages maintained by trapni need a co-maintainer
El dom, 15-04-2012 a las 17:09 +0200, Philipp Riegger escribió: On Sat, 14 Apr 2012 14:24:25 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 04/14/2012 02:16 PM, Pacho Ramos wrote: Due long devaway, his packages need a co-maintainer, feel free to add to metadata if you want. Thanks: dev-util/ciabot-svn media-sound/teamspeak-client-bin media-sound/teamspeak-server-bin sys-apps/newrelic-sysmond I believe it's time to lastrite teamspeak* because they link against mysql libraries with SONAME we don't ship anymore Therefore rendering the packages useless Can you elaborate on this? I have these ebuilds in my local overlay, renamed to install the latest versions. So maybe a (really simple) version bump would be enough. Philipp Well, in tree versions are still buggy and outdated, I would vote for either: 1. Mask them for removal (server is already hardmasked, but client not). 2. Proxy maintain them if anyone volunteers. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
El dom, 06-05-2012 a las 18:10 +0200, Andreas K. Huettel escribió: Am Sonntag, 6. Mai 2012, 14:03:02 schrieb Pacho Ramos: El dom, 06-05-2012 a las 14:41 +0300, Samuli Suominen escribió: eclass/ has a ChangeLog (and this is getting old that everyone keeps ignoring it, I've proposed punting the ChangeLog from eclass/ directory once, and repeating it now) Maybe we could punt ChangeLog from eclass/ and generate it automatically from commit messages Maybe we could punt ChangeLogs generally and generate them from commit messages... err... hasn't this been discussed before? :o( Well, in this case I intentionally was referring only to eclass/ as maybe it can be implemented for it even handling normal packages as currently signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
El dom, 06-05-2012 a las 19:28 +0200, Fabian Groffen escribió: On 06-05-2012 19:23:47 +0200, Pacho Ramos wrote: El dom, 06-05-2012 a las 18:10 +0200, Andreas K. Huettel escribió: Maybe we could punt ChangeLogs generally and generate them from commit messages... err... hasn't this been discussed before? :o( Well, in this case I intentionally was referring only to eclass/ as maybe it can be implemented for it even handling normal packages as currently The implementation has never been the problem. It's that people want to be able to edit (correct) the messages. In that case... :-( Thanks for noticing signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: app-benchmarks/bootchart, dev-embedded/parapin-driver, dev-perl/adocman, media-tv/linuxtv-dvb
# Pacho Ramos pa...@gentoo.org (11 May 2012) # No GPL releases for a long time, bundles external classes (#162788) # Use app-benchmarks/bootchart2 instead. Removal in a month. app-benchmarks/bootchart # Pacho Ramos pa...@gentoo.org (11 May 2012) # Fails to build, bug #280920 and is unmaintained for a long time. # Removal in a month. dev-embedded/parapin-driver # Pacho Ramos pa...@gentoo.org (11 May 2012) # Unmaintained since 2005, see bug #281502 for reference. Removal # in a month. dev-perl/adocman # Pacho Ramos pa...@gentoo.org (11 May 2012) # Old and only for kernel-2.4, bug #287125. Removal in a month. media-tv/linuxtv-dvb signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] pushing fixes to stable before closing bugs
El sáb, 12-05-2012 a las 12:34 +0200, Paweł Hajdan, Jr. escribió: I noticed a general tendency to close bugs affecting stable before pushing the fix to stable. One recent example is https://bugs.gentoo.org/show_bug.cgi?id=399291, but there are more. The idea is that if you only fix in ~arch, you risk a serious and _known_ regression in stable, which could be easily avoided. Do you have any ideas how do we: 1. Make as many developers (everyone?) as possible aware of this. 2. Handle already closed bugs with no fix in stable? I've seen people closing the bugs again. Paweł I guess it depends in how major is the fixed bug, if it's not too major, I think we can wait for next stabilization round (we tend to do it in gnome team) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: media-video/undvd, media-sound/ssrc, net-firewall/ipchains, media-libs/libflash, net-fs/fusesmb, net-im/jabberd, app-mobilephone/galicesms, sys-boot/cromwell, net-misc/batmand,
# Pacho Ramos pa...@gentoo.org (13 May 2012) # Upstream dead, needs to be ported to mp4v2-1.9.1 or gpac utils. # Removal in a month. media-video/undvd # Pacho Ramos pa...@gentoo.org (13 May 2012) # Overflow (#337410), no new version for a long time and nothing # needs it. Removal in a month. media-sound/ssrc # Pacho Ramos pa...@gentoo.org (13 May 2012) # For kernel-2.2, doesn't respect LDFLAGS (#337685). Removal in a # month. net-firewall/ipchains # Pacho Ramos pa...@gentoo.org (13 May 2012) # Doesn't respect LDFLAGS (#337906), only supports really old # flash. Removal in a month. media-libs/libflash # Pacho Ramos pa...@gentoo.org (13 May 2012) # Dead for a long time, opened bugs, doesn't work (#356241). Use # net-fs/smbnetfs instead. Removal in a month. net-fs/fusesmb # Pacho Ramos pa...@gentoo.org (13 May 2012) # Fails to build (#361317), replaced by jabberd2 for a long time. # Removal in a month. net-im/jabberd # Pacho Ramos pa...@gentoo.org (13 May 2012) # No longer works due Telecom Italia modifications in their # website (#363115). Removal in a month. app-mobilephone/galicesms # Pacho Ramos pa...@gentoo.org (13 May 2012) # Fails to build against gcc-4.6 (#363535). Removal in a month. sys-boot/cromwell # Pacho Ramos pa...@gentoo.org (13 May 2012) # net-misc/batman-adv replaces them (#381659). Removal in a # month. net-misc/batmand net-misc/batman-vis # Pacho Ramos pa...@gentoo.org (13 May 2012) # No needed for a long time (#395545). Removal in a month. www-plugins/libflashsupport # Pacho Ramos pa...@gentoo.org (13 May 2012) # Broken, nobody wants to maintain it as it's hard to keep # in a proper state (#410639). Removal in a month. sci-physics/abinit # Pacho Ramos pa...@gentoo.org (13 May 2012) # Failing tests (#404989), nothing needs it. Removal in a # month. dev-util/dmake # Pacho Ramos pa...@gentoo.org (13 May 2012) # No needed since kernel-2.6.38 (#406577). Removal in a month. sys-kernel/xen-sources # Pacho Ramos pa...@gentoo.org (13 May 2012) # No release since 2006, broken with cups-1.5 (#408315), # nobody willing to maintain it. A lot of image viewers in the # tree to replace it. Removal in a month. media-gfx/flphoto # Pacho Ramos pa...@gentoo.org (13 May 2012) # Still needs old qof slot that relies on sqlite2 (#408831). # Removal in a month. dev-libs/qof:0 app-office/gnotime # Pacho Ramos pa...@gentoo.org (13 May 2012) # Still using glib-1, there are some replacements in the tree # and nothing RDEPENDs on it (#409537). Removal in a month. app-crypt/quintuple-agent # Pacho Ramos pa...@gentoo.org (13 May 2012) # Still using glib-1, only needed for really old devices and # only supporting up to 64 MB due a bug (#409539). Removal # in a month. app-misc/rio500 # Pacho Ramos pa...@gentoo.org (13 May 2012) # Nothing looks to need this old slot (#409833). Removal in a # month. dev-util/glade:2 # Pacho Ramos pa...@gentoo.org (13 May 2012) # Needs old tcl/tk, doesn't respect CC, LDFLAGS, CFLAGS (#410511). # Removal in a month. dev-ada/tash # Pacho Ramos pa...@gentoo.org (13 May 2012) # Doesn't connect at all, security issues as reported in debian # (#411205). Removal in a month. net-im/amsn x11-themes/amsn-skins # Pacho Ramos pa...@gentoo.org (13 May 2012) # Doesn't work (#412139), use games-misc/xpenguins instead. # Removal in a month. x11-misc/xsimpsons # Pacho Ramos pa...@gentoo.org (13 May 2012) # Only for kernel-2.4 (#412193). Removal in a month. sys-kernel/sparc-sources # Pacho Ramos pa...@gentoo.org (13 May 2012) # Upstream reports circumvention; developer has ceased # maintenance (#415255). Removal in a month. app-shells/rssh # Pacho Ramos pa...@gentoo.org (13 May 2012) # Replaced by x11-misc/gbdfed (#415651). Removal in a month. x11-misc/xmbdfed # Pacho Ramos pa...@gentoo.org (13 May 2012) # Dead for a long time and nothing needs them (#415669, #415675). # Removal in a month. x11-misc/fme x11-misc/fxred signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile
El lun, 14-05-2012 a las 11:09 -0400, Mike Gilbert escribió: On 5/14/2012 12:50 AM, Ben de Groot wrote: On 14 May 2012 04:27, Mike Gilbert flop...@gentoo.org wrote: To make ebuilds utilizing python-distutils-ng.eclass usable out-of-the-box, the python team would like to add the following to make.defaults in the base profile. PYTHON_TARGETS=python2_7 See also bug 415575 [1]. Any objections? I think this is a good addition. I would also like to include python3_2, but I do not think this will be possible due to dev-lang/python:3.2 not being stabilized on several arches. Perhaps this could be set in arch-specific profiles? Would that work? I don't see how python:3.2 is useful for most of our users. And I especially don't see how having two python versions installed (but only one active) is useful for most of our users. So let's make sure only one version gets pulled in, unless specifically configured by the user. So long as any installed package depends on dev-lang/python without specifying a version, the user will end up with python-3 unless they mask it. There is no easy way out of that situation at this point; I think it would basically require renaming =dev-lang/python-3 to something else. If we acknowledge that users have both python:3.2 and python:2.7 installed most of the time, I think it makes sense to set the default value of PYTHON_TARGETS to match that expectation. Would be too difficult to finally fix ebuilds to properly convet shebangs and so and then, be able to have a proper system even when python3 is main interpreter? Personally, I run with it as main interpreter to catch failures, and try to fix them when possible, maybe all devs should do the same to fix packages still not working at all. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: new global USE flag: jit
El lun, 14-05-2012 a las 20:09 +0200, Agostino Sarubbo escribió: On Monday 14 May 2012 14:05:12 Alexandre Rostovtsev wrote: I propose adding the following global USE flag: jit - Enable just-in-time compilation for improved performance. May prevent use of some PaX memory protection features in Gentoo Hardened. Current local flags that could probably be unified: app-arch/libzpaq:jit - Enable just-in-time compilation for faster compression (requires SSE2) dev-libs/libpcre:jit - Enable Just-In-Time compilation of regexp bytecode to machine code, through the SLJIT compiler. This feature might conflict wtih security mitigation strategies such as NX/PaX as enabled by Gentoo Hardened. dev-python/pypy:jit - Enable the JIT compiler dev-scheme/racket:jit - Enable just-in-time compiler media-sound/csound:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua net-libs/webkit-gtk:jit - Enable JIT javascript compiler (disabling it will cause performance penalty) www-client/epiphany:jit - Allow using net-libs/webkit-gtk that has the JIT javascript compiler enabled www-client/luakit:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua, which should make luakit faster. www-client/seamonkey:methodjit - Enable JIT for JavaScript using MethodJIT for faster JS performance. Hardened users can disable this USE-flag to use MPROTECT on grsecurity kernels. www-servers/nginx:pcre-jit - Enable JIT for pcre x11-libs/qt-core:jit - Enables JIT for Javascript usage inside Qt x11-libs/qt-script:jit - Enables JIT for Javascript usage inside Qt x11-libs/qt-webkit:jit - Enable JavaScriptCore just-in-time compiler for faster JavaScript execution -Alexandre. +1 +1 also ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] -Werror unwanted?
El lun, 14-05-2012 a las 20:24 +0200, Jeroen Roovers escribió: On Mon, 14 May 2012 18:01:22 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: -Werror is basically saying that it is not safe to ship code which produces warnings. An upstream demanding -Werror should work means upstream would need to test rather a lot more than their own favourite distro/architecture/library versions/kernel/userland, which isn't going to happen. I personally think that if an upstream says that no warnings must be produced by the code, and a developer should look at them before declaring any warnings safe, then that is best followed. Upstream does not need to take into account warnings produced by compilers for lesser known architectures, as explained above. As an upstream development aid to check code that has just been added or changed, -Werror is fine, but not in the wild jungle that is Gentoo. You might as well just look at the warnings themselves instead of breaking the build system by making them fatal. In other words, for upstream development it's convenient, but never for our users out there. Also, bug reports based on *FLAGS=-Werror will be closed as INVALID. (Perhaps we should document that too.) jer I fully agree with Jeroen on this, -Werror problems should be reported directly to upstream if people want to help them on fixing warnings. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages maintained by trapni need a co-maintainer
El dom, 06-05-2012 a las 18:38 +0200, Michael Weber escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/06/2012 05:35 PM, Pacho Ramos wrote: Well, in tree versions are still buggy and outdated, I would vote for either: 1. Mask them for removal (server is already hardmasked, but client not). 2. Proxy maintain them if anyone volunteers. I would proxy maintain. Feel free to send me a pm on #irc.freenode.net, user xmw. Michael Not sure how this ended finally :-/ Thanks for the news :) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due gmsoft concentrating in hppa work
As talked with him via mail, he will concentrate in hppa work and won't have time to take care of the following packages: net-misc/dibbler net-misc/aiccu Feel free to get them Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: Enable FEATURES=config-protect-if-modified by default?
El mié, 16-05-2012 a las 11:42 +0200, Fabian Groffen escribió: On 16-05-2012 12:36:03 +0300, Eray Aslan wrote: On 2012-05-16 12:13 PM, Andreas K. Huettel wrote: make.conf(5) man page: This causes the CONFIG_PROTECT behavior to be skipped for files that have not been modified since they were installed. +1 very good idea Hmm, does that mean that when a default changes in (or some new setting is added to) an app config file, I'll get no prompt and no warning assuming I go with the default settings in the app? That presumes that the new default or the new setting does not break my setup. That is a big assumption. I'd think so, yes But similar assumption applies to current behavior: if a user forgets to run dispatch-conf after updating and machine is rebooted (by error, due some power failure, due other users rebooting it...), they will probably get failures when booting and, for example, some init.d scripts file to start due obsolete conf.d files being preserved by default. Even if we go with enabling it by default, please have a news item so that one can turn it off if necessary. Even then, new installs will have to remember to turn it off. +1 But I also agree with releasing a news item for the change of course :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] autotools.eclass:eautoreconf now runs autopoint for you
El lun, 21-05-2012 a las 02:41 -0400, Alexandre Rostovtsev escribió: On Sun, 2012-05-20 at 06:32 -0400, Mike Frysinger wrote: i've extended eautoreconf to automatically call autopoint when the package uses gettext. the configure check might seem naïve, but this is how autoreconf itself does it. this hopefully shouldn't break any packages (at least, none that weren't already broken), but if you guys start seeing eautoreconf failures where there were none before, feel free to cc base-system. -mike [...] eaclocal - if grep -q '^AM_GNU_GETTEXT_VERSION' configure.?? ; then + # Follow gnome2-live.eclass and gnome-autogen.sh logic; bug #416789 + if grep -q '^AM_GNU_GETTEXT_VERSION' configure.?? ! grep -q '^AM_GLIB_GNU_GETTEXT' configure.?? ; then eautopoint --force fi + if grep -q ^AC_PROG_INTLTOOL\|^IT_PROG_INTLTOOL configure.?? ; then + autotools_run_tool intltoolize --force --copy --automake + fi _elibtoolize --install --copy --force eautoconf eautoheader With this change, we can start to no longer call intltoolize --force --copy --automake directly in ebuilds I guess, no? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!
El lun, 21-05-2012 a las 13:46 -0400, Alexandre Rostovtsev escribió: On May 20, autools.eclass was changed to no longer inherit eutils, see http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133r2=1.134 Relying on autotools.eclass for your eutils needs was always a terrible idea, but a few ebuilds did it anyway. Those ebuilds are now *broken* since they can no longer use epatch. See bug #416847 for an example. Check your ebuilds to make sure you inherit eutils in anything that uses epatch! -Alexandre Rostovtsev. Looks like ebuilds not inheriting eutils directly even using epatch are a lot as I have seen running: grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v eutils Maybe they should be checked and a repoman warning should be added when an ebuild is using epatch without inheriting eutils directly, otherwise this problem could reappear if some other eclass no longer inherit it in the future :-/ signature.asc Description: This is a digitally signed message part
Git migration (2012) (Was: Re: [gentoo-dev] Remove eclass/ChangeLog)
El mar, 22-05-2012 a las 11:22 +0200, Fabio Erculiani escribió: On Tue, May 22, 2012 at 11:01 AM, Michael Weber x...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/20/2012 03:55 PM, Andreas K. Huettel wrote: Am Sonntag 20 Mai 2012, 15:30:45 schrieb Nirbheek Chauhan: On Sun, May 20, 2012 at 6:55 PM, Michał Górny mgo...@gentoo.org wrote: I will repeat once again: autogenerate them. +1 for this, seriously. +1 and consider profiles/**/package.mask, too. and how about getting rid of echangelog and just have it autogenerated as well? Or even better, how about giving up with cvs once for all? Regarding migration to git, I think some people where working on it, but there were some pending problems preventing the migration: https://bugs.gentoo.org/show_bug.cgi?id=333531 there, you can see the blockers, the problem is that most of them are stalled :|, if you (or anybody) could take care of them... signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!
El lun, 21-05-2012 a las 12:25 -0700, Zac Medico escribió: On 05/21/2012 12:04 PM, Pacho Ramos wrote: El lun, 21-05-2012 a las 13:46 -0400, Alexandre Rostovtsev escribió: On May 20, autools.eclass was changed to no longer inherit eutils, see http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133r2=1.134 Relying on autotools.eclass for your eutils needs was always a terrible idea, but a few ebuilds did it anyway. Those ebuilds are now *broken* since they can no longer use epatch. See bug #416847 for an example. Check your ebuilds to make sure you inherit eutils in anything that uses epatch! -Alexandre Rostovtsev. Looks like ebuilds not inheriting eutils directly even using epatch are a lot as I have seen running: grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v eutils Maybe they should be checked and a repoman warning should be added when an ebuild is using epatch without inheriting eutils directly, otherwise this problem could reappear if some other eclass no longer inherit it in the future :-/ Yeah, we have a similar check for inherit of prefix.eclass: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b583812101f1156c553385effcd9dbee0b751087 Should we (I) open a bug report requesting that or this is enough as report? Thanks :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:
On 2012-05-22 03:46, Alexandre Rostovtsev wrote:
On May 20, autools.eclass was changed to no longer inherit eutils, see
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133r2=1.134
Relying on autotools.eclass for your eutils needs was always a terrible
idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
since they can no longer use epatch. See bug #416847 for an example.
Check your ebuilds to make sure you inherit eutils in anything that uses
epatch!
-Alexandre Rostovtsev.
Since eutils inherits multilib and user, the breakage extends beyond epatch.
For example, I just saw bug #417153, where a user reported failed calls
to enew{user,group}.
The autotools.eclass change should probably be reverted until things are
properly checked I think (and I will do it tomorrow if nobody disagrees)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
El mié, 23-05-2012 a las 10:31 +0100, Markos Chandras escribió:
On Wed, May 23, 2012 at 9:04 AM, Pacho Ramos pa...@gentoo.org wrote:
El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:
On 2012-05-22 03:46, Alexandre Rostovtsev wrote:
On May 20, autools.eclass was changed to no longer inherit eutils, see
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133r2=1.134
Relying on autotools.eclass for your eutils needs was always a terrible
idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
since they can no longer use epatch. See bug #416847 for an example.
Check your ebuilds to make sure you inherit eutils in anything that uses
epatch!
-Alexandre Rostovtsev.
Since eutils inherits multilib and user, the breakage extends beyond
epatch.
For example, I just saw bug #417153, where a user reported failed calls
to enew{user,group}.
The autotools.eclass change should probably be reverted until things are
properly checked I think (and I will do it tomorrow if nobody disagrees)
It is far too late to do that. What is done is done. Let try and fix
what is still broken
Regards,
Markos
But we still have no idea what kind of commands provided by eutils and
eclasses inheritted by it are now missing, epatch usage was fixes,
enewgroup/user will probably be done but... other missing commands could
still appear in the tree :|
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
El mié, 23-05-2012 a las 17:00 -0300, Ezequiel Garcia escribió: On Wed, May 23, 2012 at 4:37 PM, Arun Raghavan ford_pref...@gentoo.org wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. Perhaps it would be instructive if you could tell us one advantage of cvs over git. (This is me exposing me to your terrible dev-flames, I was feeling too cold ;) I think Arun's comment was sarcastic ;) I guess that cvsserver bug can be dropped from blockers, no? Now, the other pending blockers... :( signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] dev-libs/libusbx:1 the default provider for virtual/libusb:1 (for ~arch)
El dom, 27-05-2012 a las 17:16 -0700, Zac Medico escribió: On 05/27/2012 11:12 AM, Samuli Suominen wrote: Fedora rawhide and ArchLinux switched to libusbx and followed suit in our virtual/libusb:1. Debian is considering the switch also. We'll see... I've been in contact with the new maintainer, and he assured me the compability will be kept for libusb-compat. Happy testing, # emerge -C dev-libs/libusb:1 # emerge -1 dev-libs/libusbx:1 I've tried this on my laptop, and afterwards it wouldn't suspend to ram when it was supposed to. I didn't do any real troubleshooting, so I'm just mentioning it here in case it helps someone else recognize the source of the problem. This was with sys-power/upower-0.9.16 and dev-libs/libusbx-1.0.11 (I didn't try to rebuild upower after switching from dev-libs/libusb-1.0.9 to dev-libs/libusbx-1.0.11). Maybe you should open a bug report for it to not forget that problem (now that finally my laptop suspends even with upstream kernel and without TOI wouldn't like to see it magically failing again without remember the real culprit ;)) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH eutils] Move remove_libtool_files() from autotools-utils for wider use.
El lun, 28-05-2012 a las 09:58 +0200, Michał Górny escribió:
As autotools-utils exports phase functions, it will be better if
remove_libtool_files() functions would be somewhere else.
---
eutils.eclass | 68
+
1 file changed, 68 insertions(+)
diff --git a/eutils.eclass b/eutils.eclass
index c88ef35..fb92256 100644
--- a/eutils.eclass
+++ b/eutils.eclass
@@ -1330,6 +1330,74 @@ makeopts_jobs() {
echo ${jobs:-1}
}
+# @FUNCTION: remove_libtool_files
+# @USAGE: [all]
+# @DESCRIPTION:
+# Determines unnecessary libtool files (.la) and libtool static archives
(.a),
+# and removes them from installation image.
+#
+# To unconditionally remove all libtool files, pass 'all' as an argument.
+# Otherwise, libtool archives required for static linking will be preserved.
+remove_libtool_files() {
+ debug-print-function ${FUNCNAME} $@
+ local removing_all
+ [[ ${#} -le 1 ]] || die Invalid number of args to ${FUNCNAME}()
+ if [[ ${#} -eq 1 ]]; then
+ case ${1} in
+ all)
+ removing_all=1
+ ;;
+ *)
+ die Invalid argument to ${FUNCNAME}(): ${1}
+ esac
+ fi
+
+ local pc_libs=()
+ if [[ ! ${removing_all} ]]; then
+ local arg
+ for arg in $(find ${D} -name '*.pc' -exec \
+ sed -n -e 's;^Libs:;;p' {} +); do
+ [[ ${arg} == -l* ]] pc_libs+=(lib${arg#-l}.la)
+ done
+ fi
+
+ local f
+ find ${D} -type f -name '*.la' -print0 | while read -r -d '' f; do
+ local shouldnotlink=$(sed -ne '/^shouldnotlink=yes$/p' ${f})
+ local archivefile=${f/%.la/.a}
+ [[ ${f} != ${archivefile} ]] || die 'regex sanity check
failed'
+
+ # Remove static libs we're not supposed to link against.
+ if [[ ${shouldnotlink} ]]; then
+ einfo Removing unnecessary ${archivefile#${D%/}}
+ rm -f ${archivefile} || die
+ # The .la file may be used by a module loader, so avoid
removing it
+ # unless explicitly requested.
+ [[ ${removing_all} ]] || continue
+ fi
+
+ # Remove .la files when:
+ # - user explicitly wants us to remove all .la files,
+ # - respective static archive doesn't exist,
+ # - they are covered by a .pc file already,
+ # - they don't provide any new information (no libs no flags).
+ local removing
+ if [[ ${removing_all} ]]; then removing='forced'
+ elif [[ ! -f ${archivefile} ]]; then removing='no static
archive'
+ elif has $(basename ${f}) ${pc_libs[@]}; then
+ removing='covered by .pc'
+ elif [[ ! $(sed -n -e \
+
s/^\(dependency_libs\|inherited_linker_flags\)='\(.*\)'$/\2/p \
+ ${f}) ]]; then removing='no libs flags'
+ fi
+
+ if [[ ${removing} ]]; then
+ einfo Removing unnecessary ${f#${D%/}} (${removing})
+ rm -f ${f} || die
+ fi
+ done
+}
+
check_license() { die you no longer need this as portage supports
ACCEPT_LICENSE itself; }
fi
+1
This was the main reason for me still doing manually cleaning over using
this function
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
Hello, will send this to gentoo-dev mailing list per Zac's suggestion ;): Probably Zac already remembers my suggestion of: https://bugs.gentoo.org/show_bug.cgi?id=413619 Sorry for insisting a bit on it but this issue bites me periodically. Months ago, I was able to administrate myself some of my father and uncles systems in their jobs and homes but, since I moved to Madrid this year, I am not able to administrate them directly. They usually do a good job maintaining them, the only issue I see they hit from time to time is forgetting to run JUST AFTER updating their systems revdep-rebuild (well, this is so common that they usually don't forget to), rebuild dbus-glib/gobject-introspection after major glib update, rebuild X11 drivers... This is because, even if all this information is recorded in /var/log/portage/elog/summary.log, currently, that log file is cluttered of a lot of other elog lines that are not related at all with this important task of rebuilding packages. This is why I suggested: https://bugs.gentoo.org/show_bug.cgi?id=413619 That would create a new erebuild (or whatever the name you prefer) to ONLY contain exact command to run by admin to have a safe system after update. It would have as main advantage: - Looks easier to implement. - It relies in current and existing tools (python-updater, perl-cleaner, q, equery...), then, they could be used just now via a script running all of them. - It also looks much more professional to try to unify a bit what commands to run ;) (currently, some ebuilds tells you to manually re-emerge packages and some people wrongly run emerge dbus-glib when they should run emerge -1 dbus-glib. Telling us to people what exact command they need to copypasterun will help to get their systems cleaner also. Zac kindly pointed me to: https://bugs.gentoo.org/show_bug.cgi?id=192319 The problem of that one is that, even if it would be the perfect solution: - Looks to be stalled for a long time. - Looks to need a lot of functions (like revdep-rebuild, python-updater...) to be merged in portage itself. It will then probably take a lot of time to get them integrated (specially seeing we are still not able to use preserve-libs because it looks to cause some other problems) - In that bug report I have also seen discussion about whether handle this only via SLOTs (that personally think it will be even harder to achieve for all packages in the tree showing this kind of problems when updating, for example, I doubt how glib - dbus-glib/g-i case could be handled in this way. - Looks like there is no consensus about what to do and, then, this could probably be implemented on eapi... 7? While former could probably be implemented much sooner (probably even in eapi5) This is why I think we should try to push a bit my first suggestion for the short term until the perfect one is ready as, until then, we are having for years a problem that, personally, I think it should be handled a bit better. Thanks a lot for your attention signature.asc Description: This is a digitally signed message part
[gentoo-dev] About forcing rebuilds of other packages issue
Hello, will send this to gentoo-dev mailing list per Zac's suggestion ;): Probably Zac already remembers my suggestion of: https://bugs.gentoo.org/show_bug.cgi?id=413619 Sorry for insisting a bit on it but this issue bites me periodically. Months ago, I was able to administrate myself some of my father and uncles systems in their jobs and homes but, since I moved to Madrid this year, I am not able to administrate them directly. They usually do a good job maintaining them, the only issue I see they hit from time to time is forgetting to run JUST AFTER updating their systems revdep-rebuild (well, this is so common that they usually don't forget to), rebuild dbus-glib/gobject-introspection after major glib update, rebuild X11 drivers... This is because, even if all this information is recorded in /var/log/portage/elog/summary.log, currently, that log file is cluttered of a lot of other elog lines that are not related at all with this important task of rebuilding packages. This is why I suggested: https://bugs.gentoo.org/show_bug.cgi?id=413619 That would create a new erebuild (or whatever the name you prefer) to ONLY contain exact command to run by admin to have a safe system after update. It would have as main advantage: - Looks easier to implement. - It relies in current and existing tools (python-updater, perl-cleaner, q, equery...), then, they could be used just now via a script running all of them. - It also looks much more professional to try to unify a bit what commands to run ;) (currently, some ebuilds tells you to manually re-emerge packages and some people wrongly run emerge dbus-glib when they should run emerge -1 dbus-glib. Telling us to people what exact command they need to copypasterun will help to get their systems cleaner also. Zac kindly pointed me to: https://bugs.gentoo.org/show_bug.cgi?id=192319 The problem of that one is that, even if it would be the perfect solution: - Looks to be stalled for a long time. - Looks to need a lot of functions (like revdep-rebuild, python-updater...) to be merged in portage itself. It will then probably take a lot of time to get them integrated (specially seeing we are still not able to use preserve-libs because it looks to cause some other problems) - In that bug report I have also seen discussion about whether handle this only via SLOTs (that personally think it will be even harder to achieve for all packages in the tree showing this kind of problems when updating, for example, I doubt how glib - dbus-glib/g-i case could be handled in this way. - Looks like there is no consensus about what to do and, then, this could probably be implemented on eapi... 7? While former could probably be implemented much sooner (probably even in eapi5) This is why I think we should try to push a bit my first suggestion for the short term until the perfect one is ready as, until then, we are having for years a problem that, personally, I think it should be handled a bit better. Thanks a lot for your attention 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 08:44 -0400, Aaron W. Swenson escribió: [...] There's never anything important in all that text. - Anonymous Gentoo User We've already determined that the users don't read the output. This is a known fact. Something I repeat in #gentoo more often than I care to admit is Seriously, read the output. I agree with the users that there's too much output, and some of the output is indeed useless. The output they aren't reading isn't just rebuild commands, but also the next step they're supposed to take after the emerge has finished, groups their users need to be in to use a particular feature, et cetera. 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). Just placing the commands in a separate log won't really solve a whole lot. Further, it will bump any elog messages even further down in the importance ranking. It will allow administrators to easily automate via scripts rebuilding of packages, allowing them to get system more solid after a big update. Also, currently I usually need to surf in big summary.log to directly find commands to rebuild things because most of elog messages are useless to me (a lot of them because they are always shown in every update and are useful only the first time you read them, other times you already remember, for example, how to setup e4rat). Current situation of breaking systems when people don't read summary.log JUST AFTER update completes won't help to force people to read them, will simply break their systems and give a really poor impression of Gentoo breaking easily when updating. Think, for example, on a lot of people that leaves system updating at night time, then, when he/she tries to use it next morning he sees some things are broken and need to be rebuilt. All that rebuilding work could be done during the same night but, due current way of handling things, he needs to have his system broken during more hours (when he needs to use it) until things are rebuilt. 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
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
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 pa...@gentoo.org 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] [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] [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] 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] 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
