Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
Am 15.02.2013 01:19, schrieb Diego Elio Pettenò: On 15/02/2013 01:15, Rich Freeman wrote: How? We don't support overlays in the main tree. I could see a package maintainer being nice if pinged by an overlay maintainer and delaying some change for a short time to let an overlay be updated, but issues that impact overlays should not be considered blockers on closing bugs on the main tree. The problem is when you have to triple-check that the user hasn't enabled some random fucked up overlay and you have to guess whether that might be the cause of the problem. Yes it happens, not so rarely. If there is something wrong with the proaudio overlay just don't use it. The same would apply to sunset. I don't use it; people still report bugs with it. I understand your argument but isn't something like graveyard actually an advantage in this case? If people use local or less clearly named overlays, it's hard so say whether that is the problem. If they install packages outside of portage, you have no way of knowing it before they mention it, either. Graveyard, on the other hand, shows up clearly in `emerge --info` and is, in my opinion, one of the most justified reasons to close a bug with WONTFIX without looking further. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/02/13 01:19, Diego Elio Pettenò wrote: The problem is when you have to triple-check that the user hasn't enabled some random fucked up overlay and you have to guess whether that might be the cause of the problem. Yes. It's difficult to govern freedom. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEeDvkACgkQRtClrXBQc7UMeQD6AkaKr3Zk0aYCbMDhIihkrRkP 8fFaJvptfpEZ9b12scMA/14vmSZiCMwzWtDoL0wuEvBjkVwNH9GsPgVRoOVpfPmE =knmq -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
On 15 February 2013 00:19, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 15/02/2013 01:15, Rich Freeman wrote: How? We don't support overlays in the main tree. I could see a package maintainer being nice if pinged by an overlay maintainer and delaying some change for a short time to let an overlay be updated, but issues that impact overlays should not be considered blockers on closing bugs on the main tree. The problem is when you have to triple-check that the user hasn't enabled some random fucked up overlay and you have to guess whether that might be the cause of the problem. Yes it happens, not so rarely. That's not a good argument. You can't stop people from using whatever external sources they want. But you can easily spot what they use from a simple eix -e broken-package or emerge --info and close the bug as INVALID in the blink of an eye -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Last time touched bugs by year
2013/2/14 Agostino Sarubbo a...@gentoo.org: Probably we don't need to see maintainer-wanted stuff.. Oh but we need to see them, quite few of those can be closed as invalid because the upstream is long ago dead. Tom
Re: [gentoo-dev] Last time touched bugs by year
On 14 February 2013 19:26, Tomáš Chvátal tomas.chva...@gmail.com wrote: Dne Čt 14. února 2013 18:34:10, Markos Chandras napsal(a): Why not 2011 and 2012 as well? Feel free to add more, its on qa-scripts git repository. Ok I was just wondering if there was a reason you did not add them along with the others. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
On Thu, Feb 14, 2013 at 4:19 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 15/02/2013 01:15, Rich Freeman wrote: How? We don't support overlays in the main tree. I could see a package maintainer being nice if pinged by an overlay maintainer and delaying some change for a short time to let an overlay be updated, but issues that impact overlays should not be considered blockers on closing bugs on the main tree. The problem is when you have to triple-check that the user hasn't enabled some random fucked up overlay and you have to guess whether that might be the cause of the problem. Yes it happens, not so rarely. I empathize, but I'm not really sure it is a blocker for this effort. Developers already have to evaluate whether the bug the user filed is legitimate; I don't think this makes that significantly more difficult. As stated. spotting overlay usage is pretty simple as-is. If there is something wrong with the proaudio overlay just don't use it. The same would apply to sunset. I don't use it; people still report bugs with it. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Last time touched bugs by year
On Fri, Feb 15, 2013 at 1:41 AM, Tomáš Chvátal tomas.chva...@gmail.com wrote: 2013/2/14 Agostino Sarubbo a...@gentoo.org: Probably we don't need to see maintainer-wanted stuff.. Oh but we need to see them, quite few of those can be closed as invalid because the upstream is long ago dead. Tom I was under the impression we just left those bugs open forever...are we closing them now? -A
Re: [gentoo-dev] Last time touched bugs by year
2013/2/15 Alec Warner anta...@gentoo.org: I was under the impression we just left those bugs open forever...are we closing them now? Why should we keep them opened forever. They should be closed when the package is no longer provided anywhere or obsoleted by something else.
Re: [gentoo-dev] Last time touched bugs by year
2013/2/15 Markos Chandras hwoar...@gentoo.org: On 14 February 2013 19:26, Tomáš Chvátal tomas.chva...@gmail.com wrote: Dne Čt 14. února 2013 18:34:10, Markos Chandras napsal(a): Why not 2011 and 2012 as well? Feel free to add more, its on qa-scripts git repository. Ok I was just wondering if there was a reason you did not add them along with the others. I was just too lazy and i was only curious for the long open bugs :P
[gentoo-dev] Relaying a message from python software foundation
In case you missed it and work in Europe with Python, http://pyfound.blogspot.fr/2013/02/python-trademark-at-risk-in-europe-we.html -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Last time touched bugs by year
Le jeudi 14 février 2013 à 19:19 +0100, Tomáš Chvátal a écrit : Hi, I added the bug queries to http://qa-reports.gentoo.org/ based by year of last being touched. Take look, try to close the oldest ones/invalid ones and so on. I think it is lame we have bugs last touched in 2k5 :-P This is nice. On another note, I just saw a report for EAPI per eclass which is super nice but unfortunately, EAPI=5 is listed but actually unsupported by the result of the scan :) -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Last time touched bugs by year
2013/2/15 Gilles Dartiguelongue e...@gentoo.org: On another note, I just saw a report for EAPI per eclass which is super nice but unfortunately, EAPI=5 is listed but actually unsupported by the result of the scan :) This can't be done better right now, as we use pkgcore to gather these stats and it is still not supporting eapi5. At the point it gets interpreted by pkgcore it will sort itself out. Tom
Re: [gentoo-dev] Last time touched bugs by year
On Thu, Feb 14, 2013 at 7:19 PM, Tomáš Chvátal tomas.chva...@gmail.com wrote: I think it is lame we have bugs last touched in 2k5 :-P Yeah, very useful. I went through most of the Python bugs and cleaned some up. It looks like there's a *lot* of maintainer-wanted bugs that are very old. I wonder if we can script cleaning those up; check how many CC addresses, see if the upstream HOMEPAGE is still up, that kind of things. Cheers, Dirkjan
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
On Fri, Feb 15, 2013 at 09:39:34AM +, Markos Chandras wrote: On 15 February 2013 00:19, Diego Elio Pettenò flamee...@flameeyes.eu wrote: The problem is when you have to triple-check that the user hasn't enabled some random fucked up overlay and you have to guess whether that might be the cause of the problem. Yes it happens, not so rarely. That's not a good argument. You can't stop people from using whatever external sources they want. But you can easily spot what they use from a simple eix -e broken-package or emerge --info and close the bug as INVALID in the blink of an eye Not really, this works when the bug is opened against a given package from an overlay. Diego's raised issue is about some *DEPEND installed from an overlay, but the failing package is from the tree. emerge --info will not report from which overlays the *DEPEND has been installed. I don't know of a simple command to list installed reverse dependencies; qdepends -Q does not show repo_name info. -- Cyprien Nicolas (Fulax) Gentoo Lisp project contrib signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
On 15/02/2013 11:33, Alexander Berntsen wrote: Yes. It's difficult to govern freedom. Freedom is overrated, especially by those who use such sound bites. Let me guess, you use CFLAGS=-O3 -funroll-loops? I sure hope not. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/02/13 13:58, Diego Elio Pettenò wrote: Freedom is overrated, especially by those who use such sound bites. Whilst you do get to decide how and if you choose to value my freedom, you most certainly do *not* get to decide how I should rate it. Let me guess, you use CFLAGS=-O3 -funroll-loops? I have performed benchmarking that suggested that O3 is detrimental to runtime half the time, and only marginally positive the other half (and unroll-loops (which of course is very sensitive to context) never resulted in big enough an improvement to make it worth using) -- regardless of CPU and architecture -- so no. I do not fully see the relevance to the conversation, so I suggest you take inquiries regarding compiler flags to me privately, or make a new thread. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEeM2MACgkQRtClrXBQc7XpdAEAoYJm9Av+zy/b4YVCvGp78Oy8 h6wzr5SX87gPJNNkx7UA/2xiWgvzuy8sEmIhd0HjQdOWER950FUd9lIKwkwzW6NW =UMkA -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
On Fri, Feb 15, 2013 at 01:48:34PM +0100, Cyprien Nicolas wrote: Not really, this works when the bug is opened against a given package from an overlay. Diego's raised issue is about some *DEPEND installed from an overlay, but the failing package is from the tree. emerge --info will not report from which overlays the *DEPEND has been installed. I don't know of a simple command to list installed reverse dependencies; qdepends -Q does not show repo_name info. Forget about reverse dependencies and the -Q switch, It is out of topic here (and emerge -pc list them). The rest holds, qdepend won't list slots or repositories. -- Cyprien Nicolas (Fulax) Gentoo Lisp project contrib signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/02/13 08:10 AM, Cyprien Nicolas wrote: On Fri, Feb 15, 2013 at 01:48:34PM +0100, Cyprien Nicolas wrote: Not really, this works when the bug is opened against a given package from an overlay. Diego's raised issue is about some *DEPEND installed from an overlay, but the failing package is from the tree. emerge --info will not report from which overlays the *DEPEND has been installed. I don't know of a simple command to list installed reverse dependencies; qdepends -Q does not show repo_name info. Forget about reverse dependencies and the -Q switch, It is out of topic here (and emerge -pc list them). The rest holds, qdepend won't list slots or repositories. I expect to see the full result one would have to emerge -epv [package] , at least that will report the repos for all *DEPENDs (although it is a bit overkill to have users submit that in the general case) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlEePMcACgkQ2ugaI38ACPC+lgEAvt9MIA9b9fVj2e527d4VNKbs UwQXS87lxvLIZ3ELVs0A/2TPDdCprzgP1tmawD7vaGniSqEJkki4SFcy3MdyNSRM =2JkD -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
On Fri, Feb 15, 2013 at 7:48 AM, Ian Stakenvicius a...@gentoo.org wrote: I expect to see the full result one would have to emerge -epv [package] , at least that will report the repos for all *DEPENDs (although it is a bit overkill to have users submit that in the general case) There are also commands like eix --installed-from-overlay to see at a glance what questionable packages may be in play. Clearly we have a dev or 2 with some overlay hate, but I don't really think that's relevant to this project discussion. It certainly shouldn't be a show stopper. -Ben
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
On 15/02/2013 10:44, Alec Warner wrote: I empathize, but I'm not really sure it is a blocker for this effort. Developers already have to evaluate whether the bug the user filed is legitimate; I don't think this makes that significantly more difficult. As stated. spotting overlay usage is pretty simple as-is. Did I say that I don't like the graveyard project? I didn't think so. I only wanted to make it clear to Rich, who seemed not to know or remember, that overlays are not harmless in and by themselves. (But I would still argue that spotting overlay usage is not always as simple; at least in one case I got somebody who was trying to hide their use of proaudio.) -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
On 15 February 2013 22:34, Diego Elio Pettenò flamee...@flameeyes.eu wrote: (But I would still argue that spotting overlay usage is not always as simple; at least in one case I got somebody who was trying to hide their use of proaudio.) Users editing the output of emerge --info and hiding they overlay usage is another problem. Anyway, overlays are not going away, so we just need to streamline our process of dealing with the resulting bugs. To bring this back on topic, users are going to get tree-cleaned ebuilds anyway, putting them in their local overlays if they want to use these packages. We're just facilitating them with a more centralized solution for this, as there is obvious demand for it. Plus, this may be a stepping stone for users fixing those packages and taking up proxy-maintainership. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/14/2013 05:39 PM, Samuli Suominen wrote: On 15/02/13 00:27, Rick Zero_Chaos Farina wrote: Remove firmware from users systems with no upgrade path and then ask users to file a bug? That's pretty awesome, how can those people file a You have very broken definition of removing/breaking users systems. Masking is not breaking. The message was very careful. Don't over dramatize this. What happens why a user runs --depclean and has a masked package installed? Oh that's right, it uninstalls. My systems do that automatically, but you are welcome to assume stupid user didn't read messages if that is easier. About the others, losing them is not too dramatic. This was worked out between ssuominen and myself on irc nearly a week ago. I believe we were both happy when we were done. Sorry for not updating the list but the issue hasn't been dire for a while. If you mean working out it by you doing unnecessary yelling on public IRC channel and me ignoring it, then sure. ;-) I'm sorry you feel that way. My intent was to work with you to solve the problem in the fastest way possible to avoid users cleaning firmware from their only network card. It was not my intent to demean you in any way. Multiple lines in that mask were an issue, not only that but you said you would mask firmware that was in linux-firmware and/or didn't install properly in /lib/firmware then proceeded to mask firmware that didn't fit either category. If you would like to continue pretending you didn't make a mistake that is fine, but please don't pretend I was unreasonably attacking you as I was not unreasonable nor attacking you. - -ZC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHyJrAAoJEKXdFCfdEflKCA8P/1w0t8gLROkFg8+ioPrTHX3g y9sKwKa5Sw0zxnTPYAZ75hoI6xP3H6WzhTPfMRpaOHR24PRMgmRTumelHShhf76z S4XxP8HUjnysjuPS70lBTU/cFi93sut+C/s4//k6wni3SzS7xq/BlkD4rwAYYBaI SSOxEeys5M5ghkPG0Wrj1x7m9j/ud0h6CTCbRBaxK7W1uMdRqXzaZmyYPcJ3lsZ3 Q+gHWOJZdAymput0CZ61CjpcAdmU+hsQk5A3L1dXxKCuxaEt/GgiNkm82UKjZyg2 o2hactvPQFH9VUyFGm96tG+L3E1o05uvXQEf0MUFDxcH7iG6HFdiyCC5pcsACo0z Z+FB+nb9y/AE6AWxfx5jiuizo+KWFkOH/RhyE91MbqEnRRSWoyBExQQu3tqfrfAr RCgKbKOZXLCEKeIoFAzsprNcwcullnDr4g3a0Fdjouz9b4nNEoojJjX3IU086bkp 3nwNFbguWBwIWB+YJ6KSZ42Kw08FZYQRIccV/khXmfFYyWgXj1twOE3CqDKWDr4N gvZauSfsoHgQkXIn02+eiDnZW60QYONfKTnDmJ68BdXpoFAi0/h0sQg7OS5+E2KN d+5/2vHINR/pphVbVK2Ku44c7h3J7Qj1xMiNa8CxL9AtCkqMKhliykOSpD6bsyUJ IlTiv2rnuYCNuKd56nKt =RM+e -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/12/2013 05:30 PM, Christopher Head wrote: On Tue, 12 Feb 2013 20:51:15 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Christopher Head posted on Tue, 12 Feb 2013 11:38:14 -0800 as excerpted: On Sun, 10 Feb 2013 20:43:02 +0100 Dirkjan Ochtman d...@gentoo.org wrote: On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani lx...@gentoo.org wrote: +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? Please don't make kernel sources RDEPEND on firmware. The kernel DOES NOT depend on firmware to work properly. Well over half my machines prove that: they work perfectly fine (read: 100% of their hardware works) with no firmware at all installed. Not a problem as long as the RDEPEND is under USE=firmware or similar. No USE=firmware, no rdepend! =:^) Kernel sources providing /lib/firmware itself shouldn't be a problem either, as that's just a dir, which many packages may own. The individual firmware files would be a problem, but the USE=firmware RDEPEND solution should solve that. Yes, of course, I meant please don’t depend unconditionally. A conditional depend is fine by me, and I don’t care about one random directory being created—I just don’t want a whole package being pulled in for nothing. While much of this thread is un-actionable I believe this is a good idea to do. What is everyone's opinion of adding a USE=firmware option to pull in PDEPEND=linux-firmware in linux-2.eclass? Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHyO1AAoJEKXdFCfdEflKV/UQAI3NTvDcGQs7hjzhkecIgxNh 11OLTv43CxLRUg4OeYJppeavxvV//LPIdroVUS2e7GgF3fQ++8HKa5s9xUzi7pmy FoWgzoTG+IeTu7NF6MVMbyLO1hhH59+TEapBn4IFE4Da7qgK+3JrbF7Lx4cpxgnL s7pJxQ2Fvm6x8Bz7NUwi4R1xnYKUJhEvxOJVCtWeChjr8c2u0zHahHnmAs9bdyeF pnE4O7RD4I+lBUNI4kJGVM8EMK31LwFLgfyHkX8mPUyXQ9rA5+ofnxAHRIuV2zEA g1f59f8b46VUy3mAJ296EXz//GZ+KxMtucAAwNLpEHEKoEj4Ypyb7rfQTlsSxUXu kXVpB7bcDah5wT4i++UFpzzTx+wLVUxgOf/idRCUqDB8l2VqSSIqq6yJ+YA3eLoY wCd9wEXR2sHaHxlwYvakMr0na3lAMIopPAM0t/0cwwIJYXlScYw6f5iEUDSo1if6 B+pUw7Hst4XsRWcQpzfjnR3tiKK9U7vTc58blz7pkkZo2cV/+PLlFzQf+WlPaxzU ZRzcxoZnQFDifu/eXLQdVNzIfAuAzCYXiU2Rv3gowmwXlUuCQiyYcYUioCMRwFwt 7yPEXIGsMCX02sjLammF9ZM2RdyKjt/daKc1vMU29aMF/WB8T1nYUKVY/XZmJ+YR YrDEf3MaIKbKoXXRuINy =y/cz -END PGP SIGNATURE-
