Re: [gentoo-dev] net-fs/netatalk is facing removal
On Fri, Jan 8, 2010 at 2:38 PM, Samuli Suominen ssuomi...@gentoo.org wrote: since noone seems to care about this package, and it's blocking glibc stabilization it will be removed from tree wrt bug 300218 last chance thanks, Samuli Its been saved. -- Doug Goldstein
Re: [gentoo-dev] adding a modification timestamp to the installed pkgs database (vdb)
On Mon, 11 Jan 2010 15:35:51 -0700 Denis Dupeyron calc...@gentoo.org wrote: I'm a bit surprised by the low amount of discussions this topic has generated. There's no discussion because Brian refuses to address any comments on the proposal and just says we should do it anyway, and if you want it done properly instead, do it yourself. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
2010-01-11 12:04:05 Gilles Dartiguelongue napisał(a): It looks like what you really want is a ranged dependencies. Dependencies specified in PYTHON_DEPEND can be expanded into ranged dependencies in EAPIs, which support ranged dependencies. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
2010-01-11 11:14:11 Maciej Mrozowski napisał(a): On Monday 11 of January 2010 01:25:45 Arfrever Frehtes Taifersar Arahesis wrote: 2010-01-10 21:56:01 Fabian Groffen napisał(a): On 10-01-2010 09:29:28 +0100, Arfrever Frehtes Taifersar Arahesis wrote: I would like to suggest introduction of support for PYTHON_DEPEND variable, which would be a better replacement for NEED_PYTHON variable. NEED_PYTHON variable does not allow to specify that e.g. only versions of Python 2 are accepted. (Eventually PYTHON_DEPEND variable will have to be set only in ebuilds of packages not supporting installation for multiple versions of Python.) Can you explain the intended use of this variable, and why normal DEPEND is not sufficient? PYTHON_DEPEND is intented to simplify specification of dependency on Python. PYTHON_DEPEND=2:2.5 is shorter than: DEPEND=|| ( =dev-lang/python-2.7* =dev-lang/python-2.6* =dev-lang/python-2.5* ) Doesn't that accidentally mean that dev-lang/python is improperly slotted and all 2.x releases should be slotted with :2? dev-lang/python is properly slotted. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
2010-01-11 11:14:40 Fabian Groffen napisał(a): On 11-01-2010 08:29:32 +, Duncan wrote: Fabian Groffen posted on Mon, 11 Jan 2010 08:50:30 +0100 as excerpted: On 11-01-2010 01:25:45 +0100, Arfrever Frehtes Taifersar Arahesis wrote: Can you explain the intended use of this variable, and why normal DEPEND is not sufficient? PYTHON_DEPEND is intented to simplify specification of dependency on Python. PYTHON_DEPEND=2:2.5 is shorter than: DEPEND=|| ( =dev-lang/python-2.7* =dev-lang/python-2.6* =dev-lang/python-2.5* ) So if there is enough space to express the dependency with the current syntax, is it worth introducing a new shorthand for it then? Also for this example, why does 2:2.5 expand to 2.7, 2.6 and 2.5? I would have expected 2.0 ... 2.5. Maybe the language isn't as intuitive then as Sebastian pointed out. Initially intuitive, perhaps not, but reasonably easy after reading the explanation: The first position is major python version, the second if present, minimal version (within that major), so it can be read as =version, the third if present, maximum version (within that major), so it can be read as =. Thus, the above 2:2.5 means major version 2, minimal version 2.5 (no maximum version within that major), so 2.5+. what's wrong with =2.5 3.0 then? It's too long and harder to parse. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On Tuesday 12 January 2010 04:22:05 Jeroen Roovers wrote: On Tue, 12 Jan 2010 02:02:14 +0100 Jeroen Roovers j...@gentoo.org wrote: I'm working on getting 2.5.1 in the tree (and fixing a USE=python and some other issues while I'm at it). net-nntp/inn-2.5.1 is in the tree and fixes many (QA) issues. Please track bug #300650 [1] if you want to stay informed of its stabilisation, which should be performed in about a month unless more non-trivial issues get uncovered. I applied all of the QA changes to 2.5.0 for convenience. I also removed the package.mask, and closed both(!) open bug reports as FIXED (in 2.5.*). jer [1] https://bugs.gentoo.org/show_bug.cgi?id=300650 Thanks for saving this package. As Jeremy said, there is absolutely no way to measure the popularity of a package. So if it has no maintainer, and open bugs we have to mask it and announce it here. It is up to you whether you want to save it or not Anyway, sorry for the inconvenience -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On 01/11/2010 10:43 PM, Jeremy Olexa wrote: (A general reply, not targeted towards you, Rich) No prob - my post wasn't really directed personally at anybody. Speaking on behalf of the treecleaners: The fact is, some of us have never heard of inn and until Gentoo has some sort of popularity tracking software/tool, the treecleaners will continue to mask unmaintained software. Yikes - just goes to show how NNTP is starting to fade into the past. :) I'm not sure if it would cause undue overhead, but perhaps a solution would be to: 1. Open a bug stating that the package will be discarded - assign to the maintainer. This gives the maintainer a chance to wake up. You can even do this without having to try to contact them first which might save you a step if you're doing that now. 2. Periodically post a list of packages that have said bugs logged for more than two weeks on -dev-announce - reference the bug number. That gives the community at large a chance to pick up the package. 3. In another two weeks, if some dev hasn't stepped in to maintain, then mask as usual. Don't announce this since anybody who cares should have CC'ed themselves on the bug. 4. Of course, security issues / etc take priority and appropriate action is taken quickly (try to find a maintainer, but mask otherwise). I'd think that if you tagged bugs appropriately you could largely automate #2 and #3 - just query for bugs over a certain age with a given keyword or whatever. This would probably lengthen the time needed to get rid of a package, but it wouldn't really increase the work needed by too much. You already announce on the list that you're masking packages - now you'd announce two weeks earlier and skip the announcement when the mask is made. This is just a suggestion, but it does eliminate the need to try to make judgment calls about whether a given package is or isn't important. Rich
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On Tue, 12 Jan 2010 18:32:06 +0200 Markos Chandras hwoar...@gentoo.org wrote: Thanks for saving this package. As Jeremy said, there is absolutely no way to measure the popularity of a package. So if it has no maintainer, and open bugs we have to mask it and announce it here. It is up to you whether you want to save it or not I don't think the (perceived) popularity of the package has anything to do with it. I do think maybe treecleaner@ needs to set up policies with regard to methods of investigation, thoroughness, and transparency. In the case at hand, treecleaner shouldn't have been called in (you're not the bloody cavalry you know! ;-) in the first place, and should certainly not have acted (so quickly). It's not clear to me generally what you (treecleaner@) all do and why you do it - but it *is* clear that it's very easy to `rm -r *' to get rid of some old stuff and that you may end up regretting it later. Particularly, it looks like the net-mail, net-news and netmon herds are understaffed and have been for a while, and I see a general shift of developers towards desktop oriented packages and away from the nuts and bolts that make it all go. I think (but have no facts apart from talking to people and handling network package related bugs in every way possible) that our userbase is still much more technically oriented. If that's all true, then doing some `rm net-*/*' cleanups may well end up hurting Gentoo as you would drive out more of the networking oriented people (users and developers) that I feel we still need to support, and turn into Yet Another Desktop Oriented Distro (which we also need, but that's already covered quite well). ISTR treecleaner@ already had some policy in place that requires some $period to pass before you mask for removal. Maybe you should announce an upcoming mask nice and early to keep that shock wave from reaching users straight away. Regards, jer
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On Tuesday 12 January 2010 20:21:59 Jeroen Roovers wrote: On Tue, 12 Jan 2010 18:32:06 +0200 Markos Chandras hwoar...@gentoo.org wrote: Thanks for saving this package. As Jeremy said, there is absolutely no way to measure the popularity of a package. So if it has no maintainer, and open bugs we have to mask it and announce it here. It is up to you whether you want to save it or not I don't think the (perceived) popularity of the package has anything to do with it. I do think maybe treecleaner@ needs to set up policies with regard to methods of investigation, thoroughness, and transparency. In the case at hand, treecleaner shouldn't have been called in (you're not the bloody cavalry you know! ;-) in the first place, and should certainly not have acted (so quickly). It's not clear to me generally what you (treecleaner@) all do and why you do it - but it *is* clear that it's very easy to `rm -r *' to get rid of some old stuff and that you may end up regretting it later. Particularly, it looks like the net-mail, net-news and netmon herds are understaffed and have been for a while, and I see a general shift of developers towards desktop oriented packages and away from the nuts and bolts that make it all go. I think (but have no facts apart from talking to people and handling network package related bugs in every way possible) that our userbase is still much more technically oriented. If that's all true, then doing some `rm net-*/*' cleanups may well end up hurting Gentoo as you would drive out more of the networking oriented people (users and developers) that I feel we still need to support, and turn into Yet Another Desktop Oriented Distro (which we also need, but that's already covered quite well). So what do you suggest? Have old, unmaintained and broken ( or forgotten ) packages under those categories in order to preserve the personality of Gentoo? IMHO ( this is not a treecleaners@ opinion, i m just talking for my self ), announcing and masking a package is a good way to inform and wake up everybody to take care of this package if they really really want to stay on portage. Having broken and unmaintained packages on tree, just to say that we have plenty of packages on portage is not acceptable policy imho. So if you want a package, plz take care of it :) ISTR treecleaner@ already had some policy in place that requires some $period to pass before you mask for removal. Maybe you should announce an upcoming mask nice and early to keep that shock wave from reaching users straight away. Having open bugs for months isn't a way to let everybody know that this package is broken for long time, so it is a valid candidate for removal? Should we send that via e-mail as well? Regards, jer -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On 01/12/2010 01:30 PM, Markos Chandras wrote: IMHO ( this is not a treecleaners@ opinion, i m just talking for my self ), announcing and masking a package is a good way to inform and wake up everybody to take care of this package if they really really want to stay on portage. I agree with the announce part, and the THREAT of masking. I just don't think that the masking should happen at the same time as the announcement. Having open bugs for months isn't a way to let everybody know that this package is broken for long time, so it is a valid candidate for removal? Should we send that via e-mail as well? I don't think an open bug constitutes notice. It is valid notice to the maintainer of the package, but not to the larger community. I probably have 100-200 packages installed, and I'd probably be annoyed if any of them went away (I'm still missing kdirstat, but that isn't really the kde team's fault). If an important one was about to go away I might step in to maintain it, and I'm sure a lot of other people feel the same way. At the same time, I can't monitor the bugs on 100-200 packages - that is the reason for having a maintainer. I think the concern is that some maintainers don't respond in a timely manner. Now, I don't know that maintainers have an obligation to fix every bug within a certain timeframe - some packages are problematic and I'm not sure that we should discard a 98% solution in favor of a 0% one because we don't have a 100% one. However, serious issues should be in scope for treecleaners, but the first goal should be to find a maintainer, and only if that fails should we consider masking. Also - if a maintainer can't be found we might also try to coordinate with the Sunrise folks to see if they're willing to take it over. We should also solicit proxy-maintainers among the user community when we announce pending removals. That could be very helpful with something like inn: I use it VERY lightly and I'm not a news guru, but I am a dev. I bet we have users who are news gurus and who care about inn, but they aren't Gentoo devs. Together we could probably cover the gaps and I'm sure devs would be more willing to pick up a package if they knew they had some help with the nuances of the package itself. If that falls apart later, at least an active dev is assigned to the package, and they can always decide to try to find a new maintainer or kill the package (saving treecleaners the work of doing so). In short - treecleaners should be about getting packages back into the mainstream maintenance model, with removal being the fallback option if that doesn't work. They shouldn't have to go out of their way to do this, but an advance announcement and some coordination is probably a good idea. Rich
[gentoo-dev] Re: Last rites: net-nntp/inn
Le Tue, Jan 12, 2010 at 08:30:26PM +0200, Markos Chandras a écrit: So if you want a package, plz take care of it :) From a user point of view, having submitted ebuilds, patches ideas and questions here and there on bugs.go, I must admit I end up putting up my contributions on my local /usr/local/portage because it never makes it to the official tree. I love Gentoo, but sometimes I feel like I'm using a debian stable :) I do not say everything should be bloody-edge at all times, but as a hoster, I use a lot of those so-called servers -- apache, mysql, cyrus-imapd, inn, postfix, amavisd, maia (which has a working, if not perfect, ebuild standing in bugs.go for years now -- #130068 -- and which is in maintainer-needed status), etc) , and I have to put them under our local tree to use them. For example, I've one for pondus, a very small gnome app which tracks your weight... I never bothered submitting it to bgo. I wonder how much time flies before users begin to stop posting their corrections to bugs.go and keep them local, because they never get committed. I agree that some management is needed, but I feel like it's becoming more and more complicated to participate in the project -- either you have to write a document showing you understand how the management works (why should I care ? I just want to add a patch), either your patch/ebuild is ignored for years. It might not be the case for every herd, though. It seems to me it was easier to participate in 2004... BTW, I'm not looking to troll here, so please: no flamewar. It's just my humble opinion, I don't want to get people mad, and I can very much be completely wrong. Arnaud. pgpztwoVPV3ph.pgp Description: PGP signature
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On Tuesday 12 January 2010 21:40:37 Arnaud Launay wrote: Le Tue, Jan 12, 2010 at 08:30:26PM +0200, Markos Chandras a écrit: So if you want a package, plz take care of it :) From a user point of view, having submitted ebuilds, patches ideas and questions here and there on bugs.go, I must admit I end up putting up my contributions on my local /usr/local/portage because it never makes it to the official tree. I love Gentoo, but sometimes I feel like I'm using a debian stable :) I do not say everything should be bloody-edge at all times, but as a hoster, I use a lot of those so-called servers -- apache, mysql, cyrus-imapd, inn, postfix, amavisd, maia (which has a working, if not perfect, ebuild standing in bugs.go for years now -- #130068 -- and which is in maintainer-needed status), etc) , and I have to put them under our local tree to use them. If you feel like it, become a proxy-maintainer and poke a developer to put your ebuilds on tree. Have you ever heard of that ? :) For example, I've one for pondus, a very small gnome app which tracks your weight... I never bothered submitting it to bgo. Same rule applies here I wonder how much time flies before users begin to stop posting their corrections to bugs.go and keep them local, because they never get committed. Arnaud. -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: net-nntp/inn
On Monday 11 January 2010 20:00:40 Jeroen Roovers wrote: On Mon, 11 Jan 2010 17:31:08 -0500 Mike Frysinger wrote: On Monday 11 January 2010 16:05:16 Markos Chandras wrote: # Markos Chandras hwoar...@gentoo.org (11 Jan 2010) # Fails with -Wl,--as-needed # bug #182782. Removal in 30 days net-nntp/inn is as-needed support really a valid reason for punting a package ? i dont think it is. Bad research - he simply lists the wrong reason. Lack of maintainer attention would have been a better description. which is still not a good enough reason for removal if the version in the tree still works -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On Monday 11 January 2010 22:43:18 Jeremy Olexa wrote: On Mon, 11 Jan 2010 20:36:37 -0500, Richard Freeman wrote: On 01/11/2010 06:30 PM, Arnaud Launay wrote: As a newsmaster, I'm a bit concerned by this. Yeah, inn seems like a really high-profile package to mask for removal. It would be conspicuous in its absence. Would it make sense to post on -dev BEFORE masking packages like this? I'm sure there are lots of people who would chip in before something like this dies. (A general reply, not targeted towards you, Rich) Speaking on behalf of the treecleaners: The fact is, some of us have never heard of inn and until Gentoo has some sort of popularity tracking software/tool, the treecleaners will continue to mask unmaintained software. We can't possible know about every package in the tree and if it looks like it is unmaintained (open bugs w/o action) then we will mask it for removal unless someone fixes it and maintains it. you need to fix your filter then. an open bug is not an acceptable reason for masking a package. if you're going to clean a package, you need to research actual reasons to mask punt. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 12.1.2010 21:33, Mike Frysinger napsal(a): On Monday 11 January 2010 22:43:18 Jeremy Olexa wrote: On Mon, 11 Jan 2010 20:36:37 -0500, Richard Freeman wrote: On 01/11/2010 06:30 PM, Arnaud Launay wrote: As a newsmaster, I'm a bit concerned by this. Yeah, inn seems like a really high-profile package to mask for removal. It would be conspicuous in its absence. Would it make sense to post on -dev BEFORE masking packages like this? I'm sure there are lots of people who would chip in before something like this dies. (A general reply, not targeted towards you, Rich) Speaking on behalf of the treecleaners: The fact is, some of us have never heard of inn and until Gentoo has some sort of popularity tracking software/tool, the treecleaners will continue to mask unmaintained software. We can't possible know about every package in the tree and if it looks like it is unmaintained (open bugs w/o action) then we will mask it for removal unless someone fixes it and maintains it. you need to fix your filter then. an open bug is not an acceptable reason for masking a package. if you're going to clean a package, you need to research actual reasons to mask punt. -mike Dont be joking, Your approach of adding new packages to main tree is that you add them with empty metadata.xml and we have to remove them in few years because they are steaming piles of bugs... Lack of maintainer and open bugs are valid reasons. And since WE want to enable as-needed as default at some time we need to work on the bugs - if packages have no maintainer and fails it we will have to punt them (that bug was open for 2 years+, and clearly there were even newer versions none bothered to bump to). If anyone picks them up and fix in the mask for cleaning that's great, because that is the reason for having that mask, so people can be loud about removal. We could simply punt things at the moment we want without any notice if we would not care about user responses for such actions. Currently there are 109 reason [1] why as-needed cant be done, if the package has maintainer he should work on it, otherwise byes, there are quite large unmaintained areas in the tree we have to care about. [1] http://bugs.gentoo.org/buglist.cgi?bug_id=182324,249450,226909,299077,247869,248195,248437,285747,280705,247931,297193,278310,207605,284921,247067,248586,277655,246755,277206,249295,248548,247043,248678,278423,247088,282426,24,246729,246961,274385,278104,300515,248345,277169,248356,277227,248169,295199,247761,277769,247444,294396,247768,247844,276303,278069,276250,246726,257996,247731,247054,277925,276873,294971,278100,297025,248549,247779,276295,247712,260226,280922,248556,248163,248192,298152,274700,265643,257918,277938,287933,248143,248571,276928,226863,247991,226885,248152,248573,247044,296631,248351,248552,247748,226917,246875,248555,294738,277794,277050,246970,248159,248605,247919,276506,297409,277640,248357,294878,248579,132992,248577,248551,278086,276796,248411,299478,248580,276302 - Tomáš Chvátal Gentoo Linux Developer [KDE/Overlays/QA/X11] E-Mail : scarab...@gentoo.org GnuPG FP: 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587 GnuPG ID: 03414587 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktM4NAACgkQHB6c3gNBRYeCSQCfSWnP07SLw9sBLUENdN9ZAEYT kcoAoLSM6ohZ3wzn47LdcEWDq8oTGQZk =1n2p -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
2010/1/12 Tomáš Chvátal scarab...@gentoo.org: Dont be joking, [...] Mmmh? Take a deep breath, a long walk, a large beer, or whatever works. Because you need it. Denis.
[gentoo-dev] Re: Digest of gentoo-dev@lists.gentoo.org issue 763 (39032-39081)
On Tue, 12 Jan 2010 06:08:34 + (UTC)
gentoo-dev+h...@lists.gentoo.org wrote:
Topics (messages 39032 through 39081):
[gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date
39032 - Mike Frysinger vap...@gentoo.org
[gentoo-dev] Non-free software in Gentoo
39033 - Richard Freeman ri...@gentoo.org
[gentoo-dev] Lastrite: dev-libs/dbus-qt3-old and
x11-themes/licq-themes 39034 - Samuli Suominen ssuomi...@gentoo.org
[gentoo-dev] net-fs/netatalk is facing removal
39035 - Samuli Suominen ssuomi...@gentoo.org
[gentoo-dev] Virtuals don't have a license
39036 - Ulrich Mueller u...@gentoo.org
[gentoo-dev] Farewell, Gentoo.
39037 - Alexander Færøy a...@0x90.dk
[gentoo-dev] rewritten epatch
39038 - Mike Frysinger vap...@gentoo.org
[gentoo-dev] rewritten epatch
39039 - Diego E. “Flameeyes” Pettenò flamee...@gmail.com
[gentoo-dev] Lastrite: net-analyzer/zabbix-{agent,frontend,server}
39040 - Patrick Lauer patr...@gentoo.org
[gentoo-dev] Monthly Gentoo Council Reminder for January
39041 - Pacho Ramos pa...@gentoo.org
[gentoo-dev] Documentation licenses and license_groups
39042 - Ulrich Mueller u...@gentoo.org
[gentoo-dev] Some ideas on the licensing issue
39043 - Ulrich Mueller u...@gentoo.org
[gentoo-dev] Some ideas on the licensing issue
39044 - Robin H. Johnson robb...@gentoo.org
[gentoo-dev] Documentation licenses and license_groups
39045 - Vincent Launchbury vinc...@doublecreations.com
[gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39046 - Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org
[gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39047 - Sebastian Pipping sp...@gentoo.org
[gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39048 - Fabian Groffen grob...@gentoo.org
[gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39049 - Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org
[gentoo-dev] QA last rites for net-misc/gfax
39050 - Diego E. Pettenò flamee...@gmail.com
[gentoo-dev] Automated Package Removal and Addition Tracker, for the
week ending 2010-01-10 23h59 UTC 39051 - Robin H. Johnson
robb...@gentoo.org
[gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39052 - Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org
[gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39053 - Sebastian Pipping sp...@gentoo.org
[gentoo-dev] Re: Election for the Gentoo Council empty seat -
nominations closed and voting delayed 24 hours 39054 - Jorge Manuel
B. S. Vicetto jmbsvice...@gentoo.org
[gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39055 - Fabian Groffen grob...@gentoo.org
[gentoo-dev] Re: PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39056 - Duncan 1i5t5.dun...@cox.net
[gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39057 - Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org
[gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39058 - Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org
[gentoo-dev] Re: PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39059 - Fabian Groffen grob...@gentoo.org
[gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39060 - Maciej Mrozowski reave...@gmail.com
[gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
39061 - Gilles Dartiguelongue e...@gentoo.org
[gentoo-dev] Last rites: ccc.eclass
39062 - Raúl Porcel armi...@gentoo.org
[gentoo-dev] RFC: ruby-ng-gnome2.eclass
39063 - Hans de Graaff gra...@gentoo.org
[gentoo-dev] Last rites: app-dicts/qvortaro
39064 - Markos Chandras hwoar...@gentoo.org
[gentoo-dev] Last rites: ccc.eclass
39065 - Raúl Porcel armi...@gentoo.org
[gentoo-dev] Last rites: kde.eclass, kde-meta.eclass,
kde-functions.eclass 39066 - Jonathan Callen a...@gentoo.org
[gentoo-dev] Last rites: net-nntp/inn
39067 - Markos Chandras hwoar...@gentoo.org
[gentoo-dev] Last rites: ccc.eclass
39069 - Brian Harring ferri...@gmail.com
[gentoo-dev] Last rites: net-nntp/inn
39070 - Mike Frysinger vap...@gentoo.org
[gentoo-dev] adding a modification timestamp to the installed pkgs
database (vdb) 39071 - Denis Dupeyron calc...@gentoo.org
[gentoo-dev] Last rites: ccc.eclass
39072 - Tomáš Chvátal scarab...@gentoo.org
[gentoo-dev] Re: Last rites: net-nntp/inn
39073 - Arnaud Launay a...@launay.org
39076 - Duncan 1i5t5.dun...@cox.net
[gentoo-dev] Last rites: net-nntp/inn
39074 - Jeroen Roovers j...@gentoo.org
[gentoo-dev] Re: Last rites: net-nntp/inn
39075 - Jeroen Roovers j...@gentoo.org
[gentoo-dev] Re: Last rites: net-nntp/inn
39077 - Richard Freeman
[gentoo-dev] Re: Last rites: net-nntp/inn
Ben de Groot posted on Tue, 12 Jan 2010 21:35:45 +0100 as excerpted: 2010/1/12 Markos Chandras hwoar...@gentoo.org: If you feel like it, become a proxy-maintainer and poke a developer to put your ebuilds on tree. Have you ever heard of that ? :) Proxy-maintainership should be given a MUCH higher profile in Gentoo, in my opinion. It is a virtually unknown option. Yay! =:^) Another thing that works in my experience, but this is up to the herds/projects, is having an official overlay where devs and users can work closely together. Again! =:^) But I also believe we need a better structure to handle maintainer-needed, maintainer-wanted and nominally maintained but ignored packages. Maybe we should form a team, which would be dedicated to take care of such things, and which would have a review policy for user submitted ebuilds and patches in bugzilla. A bit like treecleaners, but bringing life instead of death. What do you think? Well, sunrise was supposed to be that for packages not yet in the tree. The devs shepherding that work hard with the users doing the ebuilds to get them up to tree quality, so they're ready for devs to take on with little work (or to go into proxy maintainership), when it's that package's time. I know I've used a handful of sunrise packages that ultimately ended up in the tree, which is pretty good, considering I don't even have the sunrise overlay enabled unless there's something I specifically want from it. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Last rites: net-nntp/inn
Le Tue, Jan 12, 2010 at 10:37:19PM +, Duncan a écrit: FWIW, I feel for the treecleaners. It's a job with little thanks and lots of chance to make someone mad at you, but I'm glad /someone's/ doing it! =:^) Yeah. I'm glad each time I see old things getting deleted, abandoned software and such. So, yeah, thanks, treecleaners. Your job is as easy as a sysadmin's one: no one knows you exist, except when someone needs to scream at you... In the case of the INNs of the tree, that should prevent masking entirely, since popular packages will certainly have someone raising the roof on just the warning, within a day or two. That was certainly the case here. No masking means ordinary users won't have to ever know it happened. Well, as it happens, I knew it was being masked because I got the mail warning from gentoo-dev-announce, which is unfortunately a bit badly advertised. Anyway, I would have scratched my head far, far more if I had to understand WTF portage would complain about an inn masked... I don't care when it's small, unused package -- last time it was lprof, and I didn't really care, it was a bit still here from a package I installed years ago, and which passed through depclean. So, what about something like: * mail on gentoo-dev-announce, saying heads up. mask in one week * one week later, mask and classical mail foo/bar masked I have absolutely no idea how much work it requires, so I won't complain if TC says it's too complicated/unpratical/etc. BTW, I have no knowledge of the concept of proxy-maintainer, I'll look at it tomorrow, it's 2am here... :) I don't even think I ever heard of it before, but I didn't brush my gentoo-fu for a few years, that may explain... Arnaud.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On Tue, 12 Jan 2010 21:51:28 +0100 Tomáš Chvátal scarab...@gentoo.org wrote: you need to fix your filter then. an open bug is not an acceptable reason for masking a package. if you're going to clean a package, you need to research actual reasons to mask punt. -mike Dont be joking, Your approach of adding new packages to main tree is that you add them with empty metadata.xml and we have to remove them in few years because they are steaming piles of bugs... Er, say whah? Flinging mud? Mike's got a very valid point, in that you don't mask a package because of an open bug. All the rest of what you added below is about --as-needed, which doesn't apply to the bug in case and which is still no valid reason to mask a package anyway. End of discussion, plz? Yah, jer
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On Tue, 12 Jan 2010 22:37:19 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: So going with this idea... Isn't the treecleaner masking 30-day at present? What about extending that just a bit, to 5 weeks total, while reducing the actual masking to 4 weeks, with the extra week a wait time between the traditional last-rites mail and the masking? No, masking for removal should take 30 days. I strongly feel that before treecleaner@ does any masking, an announcement should go to -dev@ and -announce@ a pretty long time in advance, maybe two months, especially with the two cockups a month that I am counting now. jer
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On Wed, 13 Jan 2010 02:18:59 +0100 Arnaud Launay a...@launay.org wrote: I have absolutely no idea how much work it requires, so I won't complain if TC says it's too complicated/unpratical/etc. rm -r * is easy. BTW, I have no knowledge of the concept of proxy-maintainer, I'll look at it tomorrow, it's 2am here... :) I don't even think I ever heard of it before, but I didn't brush my gentoo-fu for a few years, that may explain... It should probably be documented at the official places [1][2]. [1] http://devmanual.gentoo.org [2] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml [3] [3] Why weren't these merged years ago?
Re: [gentoo-portage-dev] equery displays warnings about masked deps, even when those deps are deeper than --depth specification
On Tue, Jan 12, 2010 at 1:50 AM, Amit Dor-Shifer ami...@oversi.com wrote: amit0 ~ # qfile -v $(which equery) app-portage/gentoolkit-0.2.4.5 (/usr/bin/equery) The newest version of gentoolkit has slightly changed the way depgraph prints output. Could you try checking with the latest unstable version of gentoolkit and submit a bug if you get the same results? Thanks, -Doug P.S. Replying below the quote is the convention on most mailing lists. It's more readable if everyone does it... thanks :)
