Re: Please stop useless removals (was: [gentoo-dev] last rites: games-arcade/bitefusion)
On Thu, Jan 31, 2013 at 11:36 PM, Vaeth va...@mathematik.uni-wuerzburg.de wrote: # Upstream is dead and gone. # Masked for removal on 20130302 Erm, so this is the _only_ reason - dead upstream? ++ Please, please, stop removing packages for no reason! This happens now way too often: app-dicts/ispell* app-portage/epm app-text/ispell games-arcade/bitefusion games-arcade/xboing games-action/trackballs games-emulation/xmame ... These are just some of the previous examples which I remember because I had to put them in my local overlay. None of these removals alone was so valuable to me that I saw a reason to step up, but the removals for no reasons accumulate previously so much that I see the need to say something: If folks do not want to maintain it anymore, then it will be removed. Feel free to contribute to Gentoo and maintain the packages. You are destroying the charme of gentoo by systematically removing all these little tools and toys. The availability of a lot of software was once a strength of gentoo, so removing these things is really bad, especially if it happens for no real reason. Gentoo is not a software archival service. I was understanding if e.g. someting was removed which needs the gtk-2 or qt-4 framework or something similar and had a dead upstream. But just needing a small tool like imake (xboing) or having open feature requestes (epm) or even nothing and just dead upstream is IMHO really not a reason. If something really does not compile anymore and nobody cares, then remove keywords (or, for god's sake, mask it); if something might theoretically become a security issue (xpdf) then it should be masked. But please do not throw things out of the tree unless really necessary: It does not hurt anybody to have such package in the tree, but removing it - especially if upstream is dead - means that the tarbalös will be removed from the mirrors and thus nobody is able anymore to install it (even if he would care and fix some minor issues) unless he had kept a copy on his local machine (which will mean in the future that he can only do it if he had used gentoo already many years ago and cared during the time of the removal). Again I highly recommend archiving the software yourself; but I don't think Gentoo should be doing it. -A (If the resources are an argument: I am not speaking about monster packages taking gigabytes of data - these might need to be discussed separately - but mainly about reasonably sized packages which even if summed up do not take much data). Regards Martin
[gentoo-dev] frozen overlay Re: Please stop useless removals
On 02/01/2013 09:21 AM, Alec Warner wrote: On Thu, Jan 31, 2013 at 11:36 PM, Vaeth va...@mathematik.uni-wuerzburg.de wrote: # Upstream is dead and gone. # Masked for removal on 20130302 Erm, so this is the _only_ reason - dead upstream? If folks do not want to maintain it anymore, then it will be removed. Feel free to contribute to Gentoo and maintain the packages. Hereby done, becoming a dev is a big step for just one package a user would keep. Ihmo, what you call upstream dead is a kind of positive situation. If the author has no longer time to contribute (we all have a real life) then it's ok, no need to wipe his contribution from the face of the world. If the software is just working as the author intendend, and it has no major bugs, then there's no need to do further trivial releases just to keep the disto maintainers busy. If it's broken, uncompatible and nobody steps up, drop it, agreed. You are destroying the charme of gentoo by systematically removing all these little tools and toys. The availability of a lot of software was once a strength of gentoo, so removing these things is really bad, especially if it happens for no real reason. We need to maintain a certain quality. Sheer mass does has no charm, if nothing works. But I'd rather like to see gentoo as a broad selection of tools, that build. maybe some really cool stuff nobody else has. Gentoo is not a software archival service. I was understanding if e.g. someting was removed which needs the gtk-2 or qt-4 framework or something similar and had a dead upstream. But just needing a small tool like imake (xboing) or having open feature requestes (epm) or even nothing and just dead upstream is IMHO really not a reason. If something really does not compile anymore and nobody cares, then remove keywords (or, for god's sake, mask it); if something might theoretically become a security issue (xpdf) then it should be masked. But please do not throw things out of the tree unless really necessary: It does not hurt anybody to have such package in the tree, but removing it - especially if upstream is dead - means that the tarbalös will be removed from the mirrors and thus nobody is able anymore to install it (even if he would care and fix some minor issues) unless he had kept a copy on his local machine (which will mean in the future that he can only do it if he had used gentoo already many years ago and cared during the time of the removal). Again I highly recommend archiving the software yourself; but I don't think Gentoo should be doing it. It costs resources: - distfiles and all their mirrors accumulate - emerge dependency calculation If it's out-waged by increasing disc capacity and processor power is up to discussion. Last but not least, we have gattered some extra info besides the tarballs, our precious ebuild scripts. Which is why I started my involvement with Gentoo (maybe somebody should have told me about BSDs tree before that). As Martin said, tarballs get lost. I steal them from debian mirror on a regular basis, maybe we should contribute ourselves. PROPOSAL Let's create an overlay frozen stuff which contains all the software no longer developed with following features: Users showed interest in having them Web-presence to be picked up on Google search. (viewvc.cgi show dead is kinda hidden [1]) Separate distfile mirror no need to stress our mirror peers make it a sepearate repo, feed by upstream and mirror://gentoo I can contribute the space/bandwith. Feedback/Bugs/Voting can be handled inside b.g.o no need for extra login, frozen-bugs can be auto-generated, whitelist [frozen] just like the sunrise tracker bugs. BENEFIT User can choose whether or not layman -a frozen. Non-trivial ebuilds are preserved. Tarballs are preserved. Nobody gets hurt. Comments? [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] frozen overlay Re: Please stop useless removals
01.02.2013 12:53, Michael Weber wrote: BENEFIT User can choose whether or not layman -a frozen. Non-trivial ebuilds are preserved. Tarballs are preserved. Nobody gets hurt. Well, we can move such software to sunrise, can't we? But proposition of splitted mirrors makes sense, cause quite often dead upstream means dead links to original tarballs too. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] frozen overlay Re: Please stop useless removals
HI Michael: I can think of it's almost kind of a staging area, some package may be partial broken(or partial functional), but still useful for user. Generally speaking, It should be a good idea! The end users will benefit a lot. Also if user show his interests, then he can report bug, send patch, or step in to active maintain the package. Leave a opportunity to him... Dennis On Fri, Feb 1, 2013 at 4:53 PM, Michael Weber x...@gentoo.org wrote: On 02/01/2013 09:21 AM, Alec Warner wrote: On Thu, Jan 31, 2013 at 11:36 PM, Vaeth va...@mathematik.uni-wuerzburg.de wrote: # Upstream is dead and gone. # Masked for removal on 20130302 Erm, so this is the _only_ reason - dead upstream? If folks do not want to maintain it anymore, then it will be removed. Feel free to contribute to Gentoo and maintain the packages. Hereby done, becoming a dev is a big step for just one package a user would keep. Ihmo, what you call upstream dead is a kind of positive situation. If the author has no longer time to contribute (we all have a real life) then it's ok, no need to wipe his contribution from the face of the world. If the software is just working as the author intendend, and it has no major bugs, then there's no need to do further trivial releases just to keep the disto maintainers busy. If it's broken, uncompatible and nobody steps up, drop it, agreed. You are destroying the charme of gentoo by systematically removing all these little tools and toys. The availability of a lot of software was once a strength of gentoo, so removing these things is really bad, especially if it happens for no real reason. We need to maintain a certain quality. Sheer mass does has no charm, if nothing works. But I'd rather like to see gentoo as a broad selection of tools, that build. maybe some really cool stuff nobody else has. Gentoo is not a software archival service. I was understanding if e.g. someting was removed which needs the gtk-2 or qt-4 framework or something similar and had a dead upstream. But just needing a small tool like imake (xboing) or having open feature requestes (epm) or even nothing and just dead upstream is IMHO really not a reason. If something really does not compile anymore and nobody cares, then remove keywords (or, for god's sake, mask it); if something might theoretically become a security issue (xpdf) then it should be masked. But please do not throw things out of the tree unless really necessary: It does not hurt anybody to have such package in the tree, but removing it - especially if upstream is dead - means that the tarbalös will be removed from the mirrors and thus nobody is able anymore to install it (even if he would care and fix some minor issues) unless he had kept a copy on his local machine (which will mean in the future that he can only do it if he had used gentoo already many years ago and cared during the time of the removal). Again I highly recommend archiving the software yourself; but I don't think Gentoo should be doing it. It costs resources: - distfiles and all their mirrors accumulate - emerge dependency calculation If it's out-waged by increasing disc capacity and processor power is up to discussion. Last but not least, we have gattered some extra info besides the tarballs, our precious ebuild scripts. Which is why I started my involvement with Gentoo (maybe somebody should have told me about BSDs tree before that). As Martin said, tarballs get lost. I steal them from debian mirror on a regular basis, maybe we should contribute ourselves. PROPOSAL Let's create an overlay frozen stuff which contains all the software no longer developed with following features: Users showed interest in having them Web-presence to be picked up on Google search. (viewvc.cgi show dead is kinda hidden [1]) Separate distfile mirror no need to stress our mirror peers make it a sepearate repo, feed by upstream and mirror://gentoo I can contribute the space/bandwith. Feedback/Bugs/Voting can be handled inside b.g.o no need for extra login, frozen-bugs can be auto-generated, whitelist [frozen] just like the sunrise tracker bugs. BENEFIT User can choose whether or not layman -a frozen. Non-trivial ebuilds are preserved. Tarballs are preserved. Nobody gets hurt. Comments? [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On 1 February 2013 02:59, Pacho Ramos pa...@gentoo.org wrote: El dom, 27-01-2013 a las 18:47 +0100, Pacho Ramos escribió: El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió: Currently, when people uses DOC_CONTENTS variable to place their desired messages, they are automatically reformatted by fmt to get proper messages (for example, splitting long lines). But, in some cases, may be useful to disable this behavior and respect strictly how DOC_CONTENTS was formatted, for example in that kind of messages telling people to run a command and, then, requiring a new line to be used. This can also be useful to append extra information to DOC_CONTENTS when, for example, additional info is needed when enabling a USE flag. Well, after reading man echo I see all this is not needed, I simply need to use echo -e to get it understand \n to create new lines New patch attached This will add an option to disabling autoformatting to let people get their doc_contents 100% respected if they want How about using an as-is argument to readme.gentoo_create_doc? That would be more concise. :-) -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] frozen overlay Re: Please stop useless removals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/01/2013 10:35 AM, Dennis Lan (dlan) wrote: HI Michael: I can think of it's almost kind of a staging area, some package may be partial broken(or partial functional), but still useful for user. Please see [1] for the proposal of betagarden overlay, which might grab attention by posting a project page, @sping *plz* Generally speaking, It should be a good idea! The end users will benefit a lot. thanks. On 02/01/2013 10:30 AM, Sergey Popov wrote: Well, we can move such software to sunrise, can't we? But proposition of splitted mirrors makes sense, cause quite often dead upstream means dead links to original tarballs too. Maybe betagarden/sunrise would benefit from mirror-coverage, hosting situation is a recurring question on #-sunrise. Votes? Sunrise commit access is limited to sunrise devs. And I see the _rise_ in context of software and devs. I don't say sundown, cause for mentioned arguments, I just wanna have functioning/maybe superseeded software around, regardless of it's commit-frequency, author involvement or century of creation. Again: We need to proceed as a contemporary distribution (Does not build with latest ~** gcc/ argument), but we can preserve our trail for those who like. The line between removed packages and obsoleted slots has to be drawn. I'm in a tension between overlay scatter and providing an automated time capsule (that certainly will mess up any of the aforementioned repos). [1] http://archives.gentoo.org/gentoo-dev/msg_384ad55a02bf02154397f29d10a0f68e.xml - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlELnq4ACgkQknrdDGLu8JAY3gD/TOifKZZNqVb6VJkfp/VLGaGT MZzWVOYVsPPAQi0B+voA/3D8afTh5TjxeWJvAKIZwIG6O/rwVrVBAI4YHgC4T59x =bnDb -END PGP SIGNATURE-
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On 02/01/2013 10:55 AM, Ben de Groot wrote: On 1 February 2013 02:59, Pacho Ramos pa...@gentoo.org wrote: El dom, 27-01-2013 a las 18:47 +0100, Pacho Ramos escribió: El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió: Currently, when people uses DOC_CONTENTS variable to place their desired messages, they are automatically reformatted by fmt to get proper messages (for example, splitting long lines). But, in some cases, may be useful to disable this behavior and respect strictly how DOC_CONTENTS was formatted, for example in that kind of messages telling people to run a command and, then, requiring a new line to be used. This can also be useful to append extra information to DOC_CONTENTS when, for example, additional info is needed when enabling a USE flag. Well, after reading man echo I see all this is not needed, I simply need to use echo -e to get it understand \n to create new lines New patch attached This will add an option to disabling autoformatting to let people get their doc_contents 100% respected if they want How about using an as-is argument to readme.gentoo_create_doc? That would be more concise. :-) PLEASE, add define DOC_CONTENTS in an non-global scope, use src_prepare/pkg_setup instead to the eclass documentation of readme.gentoo_print_elog, Thanks ++ for the eclass, the README.gentoo might submerge into the users handling of Gentoo Systems. (I always laughed about README.Debian) [1] show an report about exactly the non-atomar situation of elog and application usage. While [2] complained about elog cluttering, I try to migrate x11-wm/xpra-0.8.0 (upcoming), am I doing it right? DOC_CONTENTS= please make your Xorg binary readable for users of xpra chmod a+r /usr/bin/Xorg and think about the security impact A copy at ~/.xpra/Xorg matching the current modules is sufficient. ^^ clearly would benefit from non-formatting. repoman full complains about Ebuild contains leading spaces on line. [1] https://bugs.gentoo.org/show_bug.cgi?id=448588 [2] https://bugs.gentoo.org/show_bug.cgi?id=440464 -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: Please stop useless removals (was: [gentoo-dev] last rites: games-arcade/bitefusion)
On Fri, Feb 1, 2013 at 3:21 AM, Alec Warner anta...@gentoo.org wrote: On Thu, Jan 31, 2013 at 11:36 PM, Vaeth va...@mathematik.uni-wuerzburg.de wrote: Please, please, stop removing packages for no reason! This happens now way too often: If folks do not want to maintain it anymore, then it will be removed. Feel free to contribute to Gentoo and maintain the packages. I think this makes sense, IFF there is something fundamentally wrong with the package. Being unmaintained in and of itself is not something fundamentally wrong with the package. Having a few open bugs is not either. Having security problems or being unusable is. I'd throw in things like serious file collisions and similar serious quality problems as well. I'd even throw in a missing distfile, but only if no user of the software is willing to proxy maintain that aspect of the package. The one thing missing from this discussion is that users CAN proxy-maintain things. Oh, and ANYBODY can run an overlay (it just won't necessarily be listed in layman - but that is how every distro does it). I do think it is a loss for Gentoo if we start removing packages simply because they don't change (which is all a dead upstream means - it isn't always a bad thing). Rich
Re: [gentoo-dev] Re: changes to tested bugzilla keyword proposal
On Fri, Feb 1, 2013 at 12:37 AM, Ryan Hill dirtye...@gentoo.org wrote: If we added a Keyword/Stable Request component to the Gentoo Linux product we could also have it dependent on that, so only bugs in that component would display the flags. You'd need to include security bugs as well at the very least as they almost always include keyword changes. Are there any issues with changing the product/component on existing bugs? I could see things turn into keyword requests which didn't start out as such. We can also make it so only people with editbugs privileges can request or set flags. ++ Rich
[gentoo-dev] Re: Please stop useless removals
On 01/02/2013 12:11, Rich Freeman wrote: I do think it is a loss for Gentoo if we start removing packages simply because they don't change (which is all a dead upstream means - it isn't always a bad thing). The problem is that a package that doesn't change _will_ bitrot. Full stop. Trying to pretend that the problem does not exist, that an unmaintained package is just as fine as a maintained one is stupid and shortsighted, and explains why I have 1600 bugs open... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Please stop useless removals
On Fri, Feb 1, 2013 at 6:20 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 01/02/2013 12:11, Rich Freeman wrote: I do think it is a loss for Gentoo if we start removing packages simply because they don't change (which is all a dead upstream means - it isn't always a bad thing). The problem is that a package that doesn't change _will_ bitrot. Full stop. Then remove it when it does. Full stop. Rich
Re: [gentoo-dev] frozen overlay Re: Please stop useless removals
On Fri, 01 Feb 2013 13:30:04 +0400 Sergey Popov pinkb...@gentoo.org wrote: 01.02.2013 12:53, Michael Weber wrote: BENEFIT User can choose whether or not layman -a frozen. Non-trivial ebuilds are preserved. Tarballs are preserved. Nobody gets hurt. Well, we can move such software to sunrise, can't we? But proposition of splitted mirrors makes sense, cause quite often dead upstream means dead links to original tarballs too. No, Sunrise project has rather specific goals [1] and is certainly not supposed to be a junkyard for packages removed from Gentoo. I'd even say that packages are put in Sunrise with some hope that they will be moved to gx86 at some point, not the other way. [1]:http://www.gentoo.org/proj/en/sunrise/ -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Please stop useless removals
On 02/01/2013 12:20 PM, Diego Elio Pettenò wrote: On 01/02/2013 12:11, Rich Freeman wrote: I do think it is a loss for Gentoo if we start removing packages simply because they don't change (which is all a dead upstream means - it isn't always a bad thing). The problem is that a package that doesn't change _will_ bitrot. Full stop. Trying to pretend that the problem does not exist, that an unmaintained package is just as fine as a maintained one is stupid and shortsighted, and explains why I have 1600 bugs open... Making up new situations up like cross-dev, Gentoo/Prefix, or jet another cluttered C compiler should not doom working software. I agree on your testing effort and practice, but compliance with the weirdest of all setups shouldn't be ultimate reason. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] Re: Please stop useless removals
On 01/02/2013 13:07, Michael Weber wrote: Making up new situations up like cross-dev, Gentoo/Prefix, or jet another cluttered C compiler should not doom working software. Which would be all fine and dandy I agree on your testing effort and practice, but compliance with the weirdest of all setups shouldn't be ultimate reason. ... if you had a clue on what you were saying. The tinderbox _by design_ is not testing weirdest of all setups, it's testing baseline. And if nobody's interested in getting (example) media-video/w3cam working (#247917 — last activity on the bug by me on 2010; last activity by someone else in 2008!), I don't see why it should be kept in tree. Bloody hell, I wonder how many people complaining about removing packages are actually using said packages, rather that complaining on principles! -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Please stop useless removals
On 02/01/2013 01:22 PM, Diego Elio Pettenò wrote:
On 01/02/2013 13:07, Michael Weber wrote:
Making up new situations up like cross-dev, Gentoo/Prefix, or jet
another cluttered C compiler should not doom working software.
Which would be all fine and dandy
I agree on your testing effort and practice, but compliance with the
weirdest of all setups shouldn't be ultimate reason.
... if you had a clue on what you were saying.
The tinderbox _by design_ is not testing weirdest of all setups, it's
testing baseline.
Yeah, but test for /usr/share/doc/${PF} (random to irrelevant),
$CFLAGS/$LDFLAGS/$AR (enable these miraculous setup), automake-1.12 (at
what point in future do you see that as oldest in-tree) last are no
statement regarding a packages functionality on a plain system.
And if nobody's interested in getting (example)
media-video/w3cam working (#247917 — last activity on the bug by me on
2010; last activity by someone else in 2008!), I don't see why it should
be kept in tree.
*insert random example here*
I did not argue to keep these in tree, or to label them a+++.
Martin and I did not argue that there are no circumstances an software
should be left alone. We both said, that not working with qt3/... may be
a strong argument.
Bloody hell, I wonder how many people complaining about removing
packages are actually using said packages, rather that complaining on
principles!
Keep on the ground.
I rather prefer a combined discussion on principles or workflow, than
bringing up this discussion for every single package.
This is a general Gentoo list, so the mails might get some kind of
general.
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] Re: Please stop useless removals
On 01/02/2013 13:36, Michael Weber wrote:
Yeah, but test for /usr/share/doc/${PF} (random to irrelevant),
Which I don't open bugs about any longer.
$CFLAGS/$LDFLAGS/$AR (enable these miraculous setup),
WTF does enable these miraculous setup mean? Seriously.
Also, no I don't test or bother opening bugs for either $AR or $CC. I do
test for and open bugs for $CFLAGS/$LDFLAGS handling because _that is
what Gentoo is about_ and among other things they work as a good sanity
check.
automake-1.12 (at
what point in future do you see that as oldest in-tree)
Are you dense? If automake-1.12 is installed, the majority of the tree
_will_ use it. The fact that I test for it is to avoid you getting the
bugs from users who really want to use your package.
last are no
statement regarding a packages functionality on a plain system.
If the package is TFU, and nobody cares enough to fix it, the
functionality on a plain system is screwed up anyway.
If you can't be bothered to make your package comply with at least the
minimum style of the rest of the tree, I'd honestly prefer you gave up
tree access.
Keep on the ground.
I rather prefer a combined discussion on principles or workflow, than
bringing up this discussion for every single package.
This is a general Gentoo list, so the mails might get some kind of
general.
The problem here is that it's not general. It's fantasy.
I'm not saying that we should remove a package because it has one
trivial bug not fixed in three months. But when upstream is dead, and
nobody in Gentoo is caring for it, has half a dozen open bug (trivial or
not), unsolved or unsolvable for over an year... punt the crap from the
tree and reduce the overload.
Also, since you are a dev, instead of complaining at how team $x removes
their packages, you can step in and save the package. As Alec said
Gentoo is not a software archival service. so arguing on the principle
that we should never delete any package from our tree is simply
preposterous.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] frozen overlay Re: Please stop useless removals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/02/13 05:53 AM, Michael Weber wrote: Sunrise commit access is limited to sunrise devs. And I see the _rise_ in context of software and devs. I don't say sundown, ..there once was a sunset overlay, wasn't there? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlELwb4ACgkQ2ugaI38ACPC9xgD+NYja02p1q1tQTrTkjBBpyoop xLFmGsGcw6sUT6e4bY4A/RiMbkAM0b6nmYkhA/zfJLFqMUudTAWd8VaLB7aD9nBe =WePv -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Please stop useless removals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/02/13 06:20 AM, Diego Elio Pettenò wrote: On 01/02/2013 12:11, Rich Freeman wrote: I do think it is a loss for Gentoo if we start removing packages simply because they don't change (which is all a dead upstream means - it isn't always a bad thing). The problem is that a package that doesn't change _will_ bitrot. Full stop. Trying to pretend that the problem does not exist, that an unmaintained package is just as fine as a maintained one is stupid and shortsighted, and explains why I have 1600 bugs open... True -- but then, the reason for that package's removal is one or many of those bugs, not because upstream is dead and the package is old and might at some point in the future have bugs due to bitrot. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlELwj4ACgkQ2ugaI38ACPCa1QEAggm0vXETySkPrLJD3Lquvc4Q Kkt7ft0dBamMGH86bE4BAL1S1X7T9dZZS88on2GhAZKy81iY8G8VWch8GUXw3Q5k =6TbE -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Please stop useless removals
On Fri, Feb 1, 2013 at 7:53 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: I'm not saying that we should remove a package because it has one trivial bug not fixed in three months. But when upstream is dead, and nobody in Gentoo is caring for it, has half a dozen open bug (trivial or not), unsolved or unsolvable for over an year... punt the crap from the tree and reduce the overload. Open trivial bugs don't create any overload, except for those who go looking at them and worrying about them at night. As long as it builds on 80%+ of systems and has no serious issues (security in particular) there is no reason to remove a package. Yes, quality issues might cause it to have issues on 80% of systems in the future, and when that happens prune it. I have no idea how many open bugs Gentoo has. The reason for this is that I search for bugs that I care about, and the only thing that has to worry about the rest is the database server. If we had a trillion open bugs I'd start worrying about that more, though simply closing them wouldn't help in that case. Remove things when they cause problems, not before. Rich
Re: [gentoo-dev] Re: Please stop useless removals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01.02.2013 14:26, Rich Freeman wrote: As long as it builds on 80%+ of systems and has no serious issues (security in particular) there is no reason to remove a package. And how will you get to know about current or future security issues if nobody (in Gentoo) cares about the package? Remove things when they cause problems, not before. You mean, not before your users' systems have been compromised and they complain loudly about it? Best regards, Wulf -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlELxNgACgkQnuVXRcSi+5qP8wCghvWTuQvcFfJojX9HS8Jln6O/ 144AnipUMY1NU8DbrtzesEbvpSHeYkPt =awFq -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Please stop useless removals
On Fri, Feb 1, 2013 at 8:36 AM, Wulf C. Krueger w...@mailstation.de wrote: And how will you get to know about current or future security issues if nobody (in Gentoo) cares about the package? The same way that you know about security issues in Firefox or Chromium - somebody reports them. Security bugs still go to the security team, and they're welcome to treeclean with a vengence. I guarantee that you have unreported security bugs in whatever browser and email client you're using right now. Until somebody tells upstream about them you're going to be vulnerable. That said, I'm fine with having some kind of overlay for stuff like this (we need to reduce the stigma on overlays), and I think that having some kind of quality tagging system also makes sense for communicating just how clean packages are. Give the users a choice. Overlays seem to be largely used to do just this - the overlay itself has some connotation of level-of-quality. Rich
[gentoo-dev] Re: Please stop useless removals
On 2/02/2013 00:36, Wulf C. Krueger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01.02.2013 14:26, Rich Freeman wrote: As long as it builds on 80%+ of systems and has no serious issues (security in particular) there is no reason to remove a package. And how will you get to know about current or future security issues if nobody (in Gentoo) cares about the package? The security team routinely monitors various information sources to ensure that issues are tracked regardless of maintainer. Remove things when they cause problems, not before. You mean, not before your users' systems have been compromised and they complain loudly about it? Best regards, Wulf -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlELxNgACgkQnuVXRcSi+5qP8wCghvWTuQvcFfJojX9HS8Jln6O/ 144AnipUMY1NU8DbrtzesEbvpSHeYkPt =awFq -END PGP SIGNATURE-
[gentoo-dev] Removals reply (I am not going to figure out which tread of those all should i reply to)
Hello guys, just to be sure here Removals are completely up to the maintainer to decide, with expection of QA removal where the package must be already broken to get punted. If you as developers and users find some package useful you can retake the maintainership (or became proxy-maint) which also expects you to take care of the bugs (QA can prune it even if you take the maintainership but ignore failures [even if your personal feeling is that it is corner case, it is for QA to deicde]). For dead upstream packages there are quite few problems you, who support keeping it in tree, seem not to notice. The distro patches will blob up (with each distro having different stuff) as things break with shiny new updates (and no saying it builds with older xyz does not make it work), users have no chance to report problems with the package elsewhere than to our bugzilla, etc, etc. This is the reason why the fedorahosted.org was fired up. So if you care about the package, take your time, fire up VCS/homepage/tracker there and try to work on it or find someone else interested to help you with becaming at least pseodo-upstream. Cheers Tom
Re: [gentoo-dev] Re: Please stop useless removals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01.02.2013 14:47, Rich Freeman wrote: And how will you get to know about current or future security issues if nobody (in Gentoo) cares about the package? The same way that you know about security issues in Firefox or Chromium [...] Until somebody tells upstream about them you're going to be vulnerable. Indeed. In contrast to many of the packages that were mentioned in this thread, Firefox and Chromium have an active upstream, though. What do you think will happen to projects with a dead upstream? I think the answer is pretty simple: Nothing. Thus, your users' systems will remain vulnerable and you won't even know about it. Best regards, Wulf -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlELyXkACgkQnuVXRcSi+5q6UgCfQLgmYQkShYNu2bwokxzP32Fv FBEAoNz/qw2QRArkSUugGXgL3bII6zn9 =aboK -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Please stop useless removals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/02/13 08:56 AM, Wulf C. Krueger wrote: On 01.02.2013 14:47, Rich Freeman wrote: And how will you get to know about current or future security issues if nobody (in Gentoo) cares about the package? The same way that you know about security issues in Firefox or Chromium [...] Until somebody tells upstream about them you're going to be vulnerable. Indeed. In contrast to many of the packages that were mentioned in this thread, Firefox and Chromium have an active upstream, though. What do you think will happen to projects with a dead upstream? I think the answer is pretty simple: Nothing. Not really, no. A dead upstream means that there isn't an upstream to push a fix or release a new version. That's all. If security bugs occur then there's two options -- fix, or remove. So if the gentoo dev in question doesn't have time/ability/desire to fix, they or security remove it at that point. This isn't nothing to me; I must be missing something from your response? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlELyo8ACgkQ2ugaI38ACPC1FAD/fxM93LFEKtl8t87qc6QSIkTL HkQtk2t4xFQxoBAZNIUBALrMJxstxw4pBwOytiQfJq9CLxf3dOnUIQCdRDwIxA6Y =j28W -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Please stop useless removals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry for quoting a lot this time but it's important for understanding the issue. On 01.02.2013 15:00, Ian Stakenvicius wrote: On 01/02/13 08:56 AM, Wulf C. Krueger wrote: On 01.02.2013 14:47, Rich Freeman wrote: And how will you get to know about current or future security issues if nobody (in Gentoo) cares about the package? The same way that you know about security issues in Firefox or Chromium [...] Until somebody tells upstream about them you're going to be vulnerable. Indeed. In contrast to many of the packages that were mentioned in this thread, Firefox and Chromium have an active upstream, though. What do you think will happen to projects with a dead upstream? I think the answer is pretty simple: Nothing. Not really, no. A dead upstream means that there isn't an upstream to push a fix or release a new version. That's all. If security bugs occur then there's two options -- fix, or remove. So if the gentoo dev in question doesn't have time/ability/desire to fix, they or security remove it at that point. This isn't nothing to me; I must be missing something from your response? Yes, the topmost two lines in my quote: And how will you get to know about current or future security issues if nobody (in Gentoo) cares about the package? In the dead upstream case it's unlikely anyone is checking the package for security issues in the first place. So neither the Gentoo security people will get notice via the usual sources nor will any upstream be informed. If there's a *known* bug, you're right. Case closed. If the package in question is just bit-rotting and nobody cares, you most likely won't ever know about any security issues, though - until something nasty happens. This is one of the problems with dead upstream packages. Best regards, Wulf -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlELzGEACgkQnuVXRcSi+5rJAwCfYGcHAJzmxwD+2L0WZlajnfP4 TzsAn1NN88QQDG3Q9br73nM1KcFT9rDW =5aeo -END PGP SIGNATURE-
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
Well done! Binary packages is now broken :-/ ## SPM: post-install phase * ERROR: x11-misc/bumblebee-3.0.1-r2 failed (postinst phase): * README.gentoo wasn't created at src_install! * * Call stack: * ebuild.sh, line 93: Called pkg_postinst * environment, line 2080: Called readme.gentoo_pkg_postinst * environment, line 2230: Called readme.gentoo_print_elog * environment, line 2245: Called die * The specific snippet of code: * die README.gentoo wasn't created at src_install!; * * If you need support, post the output of `emerge --info '=x11-misc/bumblebee-3.0.1-r2'`, * the complete build log and the output of `emerge -pqv '=x11-misc/bumblebee-3.0.1-r2'`. * The complete build log is located at '/var/tmp/entropy/packages/amd64/5/x11-misc_bumblebee-3.0.1-r2_0.tbz2/portage/x11-misc/bumblebee-3.0.1-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/entropy/packages/amd64/5/x11-misc_bumblebee-3.0.1-r2_0.tbz2/portage/x11-misc/bumblebee-3.0.1-r2/temp/environment'. * Working directory: '/var/tmp/entropy/packages/amd64/5/x11-misc_bumblebee-3.0.1-r2_0.tbz2/portage/x11-misc/bumblebee-3.0.1-r2' * S: '/var/tmp/entropy/packages/amd64/5/x11-misc_bumblebee-3.0.1-r2_0.tbz2/portage/x11-misc/bumblebee-3.0.1-r2/work/bumblebee-3.0.1' -- Fabio Erculiani
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
No FILESDIR nor T in pkg_* phases please! -- Fabio Erculiani
Re: [gentoo-dev] Re: Please stop useless removals
On Fri, Feb 1, 2013 at 9:08 AM, Wulf C. Krueger w...@mailstation.de wrote: In the dead upstream case it's unlikely anyone is checking the package for security issues in the first place. So neither the Gentoo security people will get notice via the usual sources nor will any upstream be informed. That seems rather speculative. I'm sure that people look for vulnerabilities in unmaintained software - if they didn't then nobody would be able to exploit them in the first place (you have to find a vulnerability to exploit it). I imagine most vulnerabilities are found by people outside of projects in the first place. We don't know how many vulnerabilities there are in maintained packages, let alone unmaintained ones, so a comparison is a bit difficult. Popularity is probably a better indicator of whether something will have vulnerabilities reported than whether it has an upstream. The two are of course loosely connected. Rich
Re: [gentoo-dev] Removals reply (I am not going to figure out which tread of those all should i reply to)
On Fri, Feb 1, 2013 at 8:53 AM, Tomáš Chvátal tomas.chva...@gmail.com wrote: If you as developers and users find some package useful you can retake the maintainership (or became proxy-maint) which also expects you to take care of the bugs (QA can prune it even if you take the maintainership but ignore failures [even if your personal feeling is that it is corner case, it is for QA to deicde]). Citation? I don't see any GLEPs or other Council-approved policies to that effect. And this is of course why nobody actually wants to maintain these packages - everybody is going to be looking over your shoulder because they've already decided that the existence of the package bothers them. Honestly, threads like this bug me so much that I'm half-tempted to take over maintainership of one of these packages just to be a test case... Ugh - time for an email break... Rich
Re: [gentoo-dev] Re: Please stop useless removals
On 02/01/2013 07:07 AM, Michael Weber wrote: On 02/01/2013 12:20 PM, Diego Elio Pettenò wrote: On 01/02/2013 12:11, Rich Freeman wrote: I do think it is a loss for Gentoo if we start removing packages simply because they don't change (which is all a dead upstream means - it isn't always a bad thing). The problem is that a package that doesn't change _will_ bitrot. Full stop. Trying to pretend that the problem does not exist, that an unmaintained package is just as fine as a maintained one is stupid and shortsighted, and explains why I have 1600 bugs open... Making up new situations up like cross-dev, Gentoo/Prefix, or jet another cluttered C compiler should not doom working software. I agree on your testing effort and practice, but compliance with the weirdest of all setups shouldn't be ultimate reason. Being broken on one architecture should not prevent a package from being available to others where it works. You just do not keyword things on architectures where they are broken. This is why we have keywording. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Please stop useless removals
On 02/01/2013 02:36 AM, Vaeth wrote: # Upstream is dead and gone. # Masked for removal on 20130302 Erm, so this is the _only_ reason - dead upstream? ++ Please, please, stop removing packages for no reason! This happens now way too often: app-dicts/ispell* app-portage/epm app-text/ispell games-arcade/bitefusion games-arcade/xboing games-action/trackballs games-emulation/xmame ... These are just some of the previous examples which I remember because I had to put them in my local overlay. None of these removals alone was so valuable to me that I saw a reason to step up, but the removals for no reasons accumulate previously so much that I see the need to say something: You are destroying the charme of gentoo by systematically removing all these little tools and toys. The availability of a lot of software was once a strength of gentoo, so removing these things is really bad, especially if it happens for no real reason. I was understanding if e.g. someting was removed which needs the gtk-2 or qt-4 framework or something similar and had a dead upstream. But just needing a small tool like imake (xboing) or having open feature requestes (epm) or even nothing and just dead upstream is IMHO really not a reason. If something really does not compile anymore and nobody cares, then remove keywords (or, for god's sake, mask it); if something might theoretically become a security issue (xpdf) then it should be masked. But please do not throw things out of the tree unless really necessary: It does not hurt anybody to have such package in the tree, but removing it - especially if upstream is dead - means that the tarbalös will be removed from the mirrors and thus nobody is able anymore to install it (even if he would care and fix some minor issues) unless he had kept a copy on his local machine (which will mean in the future that he can only do it if he had used gentoo already many years ago and cared during the time of the removal). (If the resources are an argument: I am not speaking about monster packages taking gigabytes of data - these might need to be discussed separately - but mainly about reasonably sized packages which even if summed up do not take much data). Regards Martin I suspect that the removal message is inaccurate. The actual reason for removal is the following: https://bugs.gentoo.org/show_bug.cgi?id=425298 If you were to make a webpage for it and host the tarball for people, it should be possible to resolve that bug. That should be sufficient to have the removal mask removed. I suspect that the Anapnea network will be more than happy to provide you with hosting for this: http://www.anapnea.net/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Removals reply
If security bugs occur then there's two options -- fix, or remove. (Or maybe mask with message clearly indicating security issues or warn about possibly unknown security issues). I agree. But security bugs are really relevant only for a rather limited types of packages: Those which are SUID (or have caps) or automatically called by other programs and reading untrusted data: Libraries (or used as such like movie players, viewers etc), or programs tightly coupled to the net (browsers, net games, etc). So e.g., I completely agree with masking xpdf for security reasons if nobody wants to care about security issues, although this does not necessarily mean that it has to be removed from the tree. However, for all other packages I mentioned, e.g. simple games (I was not speaking about net games), security issues are not security relevant: It is really the user's fault if he feeds them untrusted data, and in this case the user's data can be harmed. This he should know in advance, anyway. Regards Martin
Re: [gentoo-dev] Removals reply (I am not going to figure out which tread of those all should i reply to)
2013/2/1 Rich Freeman ri...@gentoo.org: On Fri, Feb 1, 2013 at 8:53 AM, Tomáš Chvátal tomas.chva...@gmail.com wrote: If you as developers and users find some package useful you can retake the maintainership (or became proxy-maint) which also expects you to take care of the bugs (QA can prune it even if you take the maintainership but ignore failures [even if your personal feeling is that it is corner case, it is for QA to deicde]). Citation? I don't see any GLEPs or other Council-approved policies to that effect. You my friend are slowly pissing me of as I read through all the flames you cause on -dev. There is no council vote required as it is already defined within qa team specs (and glep too when i think of it, so yep there is glep for you). And this is of course why nobody actually wants to maintain these packages - everybody is going to be looking over your shoulder because they've already decided that the existence of the package bothers them. No, they won't get anyone looking over their shoulder unless they decide to neglect the bugs as few maintainers did. I didn't see a lot forced removals caused by qa, did you? The existence of the package usually does not bother anyone, maintainer just decided that its burden so it will be removed, he could've put it to m-n but its up to every maintainer to decide what to do if the package has bugs he deem serious. If anyone else decide to pick up where they left, it is his job to ensure the package gets fixed and up-par to work nicely. Bit ago we had this discussion about keeping broken shit in tree masked or just prune it, and obvious solution was to remove it as there is just few of us and if anyone wants to start where we left he can pick out the ebuild from attic and put into his own overlay where it might work for him or even put it back to tree fixed. Honestly, threads like this bug me so much that I'm half-tempted to take over maintainership of one of these packages just to be a test case... Ugh - time for an email break... Go for it, i wrote exactly what to do, create vcs/tracker/homepage and it can stay.
Re: [gentoo-dev] Removals reply (I am not going to figure out which tread of those all should i reply to)
On 01/02/2013 18:00, Tomáš Chvátal wrote:
No, they won't get anyone looking over their shoulder unless they
decide to neglect the bugs as few maintainers did.
I didn't see a lot forced removals caused by qa, did you?
As far as I can tell, they come down to two:
- webmin; which was saved after a masking and ended up not going
anywhere, as most of the bugs (most security-related due to the nature
of webmin!) were still around months after the unmask;
- ${forgothename} which Robbins claimed he fixed in five minutes and
our QA was bad — where his fix was exchanging a build-time failure with
a runtime abort, and thus was kicked just as fine;
You could possibly add the damn squeezebox software that even Logitech
discontinued, but for that I'd just refer to the previous flame which
for my side boiled down if you want to keep it around, mask the fucker
because it's crap.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Removals reply
[...] and if anyone wants to start where we left he can pick out the ebuild from attic and put into his own overlay where it might work for him or even put it back to tree fixed. And this is exactly what *cannot* be done after a while: The ebuild is still available by CVS (or maybe git in future), but if there were already a lot of gentoo patches, the tarball with these patches is lost forever. If even upstream is dead, not even the main tarball will be available anymore. Go for it, i wrote exactly what to do, create vcs/tracker/homepage and it can stay. And what if somebody decides to do so in a year? E.g. if somebody gets some hardware in a year and needs support of a package which was removed? Or if he was not yet a gentoo user at the time when the package was removed (or absent/busy for a long period)? Then he is lost unless a distribution with bigger resources as gentoo has decided to keep the package. Not really a selling point for gentoo.
Re: [gentoo-dev] Re: Please stop useless removals
On Fri, 1 Feb 2013 09:45:07 -0500 Rich Freeman ri...@gentoo.org wrote: That seems rather speculative. I'm sure that people look for vulnerabilities in unmaintained software - if they didn't then nobody would be able to exploit them in the first place (you have to find a vulnerability to exploit it). I imagine most vulnerabilities are found by people outside of projects in the first place. We don't know how many vulnerabilities there are in maintained packages, let alone unmaintained ones, so a comparison is a bit difficult. Also, there are plenty of packages that can't really *have* interesting security vulnerabilities in the first place. I don't know the specifics of the games that were removed, but games in general, if they are purely single-player and only ever read and write files in the player's home directory, don't really have an attack surface to start with. You can't remotely exploit a program that never creates a socket, and you can't locally exploit a program that never tries to access files other than those in its invoker's home directory and root-writable directories like /usr/share, and does so with the invoker's usual privileges. Do you treeclean those because they might have security holes? Chris
Re: [gentoo-dev] Removals reply
Dne Pá 1. února 2013 18:40:32, Vaeth napsal(a): [...] and if anyone wants to start where we left he can pick out the ebuild from attic and put into his own overlay where it might work for him or even put it back to tree fixed. And this is exactly what *cannot* be done after a while: The ebuild is still available by CVS (or maybe git in future), but if there were already a lot of gentoo patches, the tarball with these patches is lost forever. If even upstream is dead, not even the main tarball will be available anymore. Oh but it can mostly these archaic packages do not have patchsets. You still can count the packages using huge patchsets using just your hands. Also there is proposal to create git repository with patches exactly for this purposes. So bribe infra people with cookies to focus on it and you will get your stuff done :-) Go for it, i wrote exactly what to do, create vcs/tracker/homepage and it can stay. And what if somebody decides to do so in a year? If you are person who didn't touch his Gentoo box within a year hire some guy to maintain it. Seriously after a year without syncing and checkign the masks it is just walking security hole. E.g. if somebody gets some hardware in a year and needs support of a package which was removed? Well we never remove stuff right away, so we can say someone get hardware that is at least decade old, honestly just obtain distros build around such HW (like debian stable). Or if he was not yet a gentoo user at the time when the package was removed (or absent/busy for a long period)? Well he would found out after sync that it is removed, but he still can have it on his system, not available package does not mean that you have to uninstall it from that box. Then he is lost unless a distribution with bigger resources as gentoo has decided to keep the package. Not really a selling point for gentoo. Gentoo is not a distro with bigger resources, there is only few developers working on everything (yeah we show that 250 devs are still around, but question is how much of those are active). If you want real support you can always go for paid distros (thats their purpose, to support stuff where OSS is out of loop). PS: threading is broken in your mail client. or I dunno why this reply appeared out of thread.
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El vie, 01-02-2013 a las 17:55 +0800, Ben de Groot escribió: On 1 February 2013 02:59, Pacho Ramos pa...@gentoo.org wrote: El dom, 27-01-2013 a las 18:47 +0100, Pacho Ramos escribió: El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió: Currently, when people uses DOC_CONTENTS variable to place their desired messages, they are automatically reformatted by fmt to get proper messages (for example, splitting long lines). But, in some cases, may be useful to disable this behavior and respect strictly how DOC_CONTENTS was formatted, for example in that kind of messages telling people to run a command and, then, requiring a new line to be used. This can also be useful to append extra information to DOC_CONTENTS when, for example, additional info is needed when enabling a USE flag. Well, after reading man echo I see all this is not needed, I simply need to use echo -e to get it understand \n to create new lines New patch attached This will add an option to disabling autoformatting to let people get their doc_contents 100% respected if they want How about using an as-is argument to readme.gentoo_create_doc? That would be more concise. :-) I have no problem on either solution... but don't have time just now to work on a patch to achieve it, if you have a bit time, I would really appreciate :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c
On 01/17/13 13:21, Pacho Ramos wrote: # Pacho Ramos pa...@gentoo.org # Multiple bugs (#449458). No maintained at all and upstream # dead. Removal in a month. app-portage/epm Peter Weilbacher has stepped up to maintain this package and I am acting as his proxy. app-portage/epm-1.40 has been added to the tree that fixes most of the bugs. I have removed the package mask entry and updated metadata and bugzilla appropriately. Regards, Paul Varner tools-portage lead
Re: [gentoo-dev] Re: Please stop useless removals
On Fri, Feb 1, 2013 at 10:51 AM, Richard Yao r...@gentoo.org wrote: I suspect that the removal message is inaccurate. The actual reason for removal is the following: https://bugs.gentoo.org/show_bug.cgi?id=425298 If you were to make a webpage for it and host the tarball for people, it should be possible to resolve that bug. That should be sufficient to have the removal mask removed. Yes, after sending out my email I took a closer look and came to the same conclusion. I'm perfectly fine with masking/removing packages that do not have valid SRC_URIs, and if somebody wants to host the tarball somewhere and submit a patch to fix it we shouldn't have a problem with a dev committing that patch and prolonging the package a bit longer (though ideally a proxy maintainer would be helpful). Bottom line is that we shouldn't drop packages simply because they're unmaintained or lack an upstream. Missing SRC_URIs on unmaintained packages are fair game, however, as are other serious issues. I have no desire to make the mirror maintainers sort through log noise on something like this. For those who are doing the treecleaning, please do yourself a favor and point out the actual show-stoppers so that you don't have a war on your hand every time you mask something. :) Rich
Re: [gentoo-dev] Re: Please stop useless removals
On 01/02/2013 23:52, Rich Freeman wrote: For those who are doing the treecleaning, please do yourself a favor and point out the actual show-stoppers so that you don't have a war on your hand every time you mask something. :) Or maybe, you know, stop starting idiotic flamewars on principles assuming that all of QA is out to ruin your life, which seems to happen pretty often to you. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Please stop useless removals
On Fri, Feb 1, 2013 at 5:54 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 01/02/2013 23:52, Rich Freeman wrote: For those who are doing the treecleaning, please do yourself a favor and point out the actual show-stoppers so that you don't have a war on your hand every time you mask something. :) Or maybe, you know, stop starting idiotic flamewars on principles assuming that all of QA is out to ruin your life, which seems to happen pretty often to you. The argument was made that unmaintained packages that have dead upstreams should be removed. I explained why this was bad policy. This is not a flamewar. It turns out that this wasn't actually why these packages were removed, but it doesn't really change the validity of anything I said. In the end the error wasn't in the removal of the packages, but in the justification for doing so. It really isn't meant personally, and I certainly don't take it as such. Rich
Re: [gentoo-dev] Re: Please stop useless removals
On 02/02/2013 12:17 AM, Rich Freeman wrote: On Fri, Feb 1, 2013 at 5:54 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 01/02/2013 23:52, Rich Freeman wrote: For those who are doing the treecleaning, please do yourself a favor and point out the actual show-stoppers so that you don't have a war on your hand every time you mask something. :) Or maybe, you know, stop starting idiotic flamewars on principles assuming that all of QA is out to ruin your life, which seems to happen pretty often to you. The argument was made that unmaintained packages that have dead upstreams should be removed. I explained why this was bad policy. This is not a flamewar. +1 Dead upstream is no reason alone to treeclean any package. A reason would be a severe runtime or buildtime bug, that needs a non-trivial fix, but no upstream to take care of that.
Re: [gentoo-dev] Re: Please stop useless removals
130201 Rich Freeman wrote: On Fri, Feb 1, 2013 at 10:51 AM, Richard Yao r...@gentoo.org wrote: The actual reason for removal is the following: https://bugs.gentoo.org/show_bug.cgi?id=425298 I'm perfectly fine with masking/removing packages that do not have valid SRC_URIs and if somebody wants to host the tarball somewhere and submit a patch to fix it we shouldn't have a problem with a dev committing that patch and prolonging the package a bit longer. Bottom line is that we shouldn't drop packages simply because they're unmaintained or lack an upstream. +1 Missing SRC_URIs on unmaintained packages are fair game, however, as are other serious issues. I have no desire to make the mirror maintainers sort thro log noise on something like this. If a mere user may comment (smile), I use = 1 pkg which hasn't been updated for a long time, Apwal, but is in fact an excellent little app which deserves wider knowledge. It's one of those apps which needs no further development. There are also pkgs like Nethack, which is hard-masked because there's a serious security bug on multi-user systems, but which offers no problems on a single-user desktop. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
