Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model
On 11/20/14 5:15 PM, Ciaran McCreesh wrote: On Thu, 20 Nov 2014 01:36:32 +0100 hasufell hasuf...@gentoo.org wrote: Exherbo is already running a more modular approach, I'd be interested what they have to say about this or which problems they were facing. Well the big thing is that unlike Gentoo, Exherbo was able to switch to using Git for its repositories. On top of that, Exherbo also has proper automated tinderbox runs (with automated conflict resolution) for changes, including across repositories, and a much stronger culture of accepting that breaking changes to APIs and APIs that give an error on misuse are necessary for a quality product, and a tolerance of developers making those changes and then applying the fixes to other people's packages. Distributed is much easier to do if you're starting from something which is correct and verified... I'm glad Exherbo has been mentioned - this gives us something specific to discuss, including how it works in practice. Using git is certainly an advantage. Ciaran, could you share more about the automatic tinderbox runs and automated conflict resolution? I look at Exherbo site from time to time but didn't notice this. Please bear with my ignorance, I've even tried searching for things like Exherbo tinderbox. I think you have a good point about necessity of breaking changes from time to time, and APIs that give an error on misuse. This reminds me of these two other good resources: http://www.infoq.com/presentations/effective-api-design (just the slides are at http://www.newt.com/java/GoodApiDesign-JoshBloch.pdf) https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt Note that Linus Torvalds pays very close attention to never break userspace. But within the kernel, large-scale changes are not uncommon, which I think is a good thing. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
El jue, 20-11-2014 a las 23:04 +0100, Michał Górny escribió: [...] Here's how games-r1 would look like. However, now that I think about it, it may be actually useful to commit such an eclass. Otherwise people will keep thinking games.eclass is the way to go. Why isn't games.eclass deprecated then (like was done with old python eclasses) to let people to progressively stop using that at all?
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
El vie, 21-11-2014 a las 11:03 +0100, Pacho Ramos escribió: El jue, 20-11-2014 a las 23:04 +0100, Michał Górny escribió: [...] Here's how games-r1 would look like. However, now that I think about it, it may be actually useful to commit such an eclass. Otherwise people will keep thinking games.eclass is the way to go. Why isn't games.eclass deprecated then (like was done with old python eclasses) to let people to progressively stop using that at all? I clicked to send too fast sorry :S I meant that maybe we should simply deprecate it in the way that repoman will inform people that they need to stop using it ;)
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
On 11/21/2014 11:04 AM, Pacho Ramos wrote: El vie, 21-11-2014 a las 11:03 +0100, Pacho Ramos escribió: El jue, 20-11-2014 a las 23:04 +0100, Michał Górny escribió: [...] Here's how games-r1 would look like. However, now that I think about it, it may be actually useful to commit such an eclass. Otherwise people will keep thinking games.eclass is the way to go. Why isn't games.eclass deprecated then (like was done with old python eclasses) to let people to progressively stop using that at all? I clicked to send too fast sorry :S I meant that maybe we should simply deprecate it in the way that repoman will inform people that they need to stop using it ;) There are users who seem to like it and the games team wants to keep it as well, so I don't see a reason to push into that direction. The main thing is that you cannot turn off all the permission stuff in the eclass whether you like it or not. Changing the install variables thing is just for convenience and already possible.
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
On 2014-11-21 09:54, hasufell wrote: There are users who seem to like it and the games team wants to keep it as well, so I don't see a reason to push into that direction. The main thing is that you cannot turn off all the permission stuff in the eclass whether you like it or not. Changing the install variables thing is just for convenience and already possible. If people don't want to use the games eclass, then don't use it. I thought this had already been discussed and mostly ok-ed. I don't see the point of adding circumvention methods if you can just avoid it altogether. Tim pgpKweuVpdC43.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
El vie, 21-11-2014 a las 10:10 -0500, Tim Harder escribió: On 2014-11-21 09:54, hasufell wrote: There are users who seem to like it and the games team wants to keep it as well, so I don't see a reason to push into that direction. The main thing is that you cannot turn off all the permission stuff in the eclass whether you like it or not. Changing the install variables thing is just for convenience and already possible. If people don't want to use the games eclass, then don't use it. I thought this had already been discussed and mostly ok-ed. I don't see the point of adding circumvention methods if you can just avoid it altogether. Tim Personally I lost the track in all the games.eclass issue... I thought it was going to be dropped finally :/ The problem I see in keeping it and also allow people to not use that one is that we will have some games installed in different places and permissions than others... and that looks really inconsistent to me (I guess people will simply keep adding themselves to games group... but, in that case, what is the purpose of keeping that group and special paths?)
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
On 11/21/2014 04:10 PM, Tim Harder wrote: On 2014-11-21 09:54, hasufell wrote: There are users who seem to like it and the games team wants to keep it as well, so I don't see a reason to push into that direction. The main thing is that you cannot turn off all the permission stuff in the eclass whether you like it or not. Changing the install variables thing is just for convenience and already possible. If people don't want to use the games eclass, then don't use it. I thought this had already been discussed and mostly ok-ed. I don't see the point of adding circumvention methods if you can just avoid it altogether. Are you serious? Instead of creating random competing concepts in one repository we should rather enhance configuration options, so that the USER can choose what he likes instead of the developer. I think this is a very bad idea. If we all decide to drop the eclass, then fine. Until then, users don't have any convenient way to have games world-executable without overwriting the eclass (which I currently do myself).
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
On 2014-11-21 10:31, hasufell wrote: Are you serious? Instead of creating random competing concepts in one repository we should rather enhance configuration options, so that the USER can choose what he likes instead of the developer. I think this is a very bad idea. If we all decide to drop the eclass, then fine. Until then, users don't have any convenient way to have games world-executable without overwriting the eclass (which I currently do myself). Personally I've seen somewhat competing concepts evolve in the tree over the past years, specifically python/ruby eclass (r)evolution springs to mind. Stuff didn't immediately get deprecated in those cases but only after a certain period of burn-in for the newer work. I guess this case is somewhat different in that the outcome is a bit more visible to the average user and people want to remove the thing entirely. If this is a step in that direction fine and maybe this will help spur discussion to get that moving somewhere. Tim pgphhehLmVmBz.pgp Description: PGP signature
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
Before I reply with a simple four letter words let me restate one thing and than that will be it, and my next move unless council/devrel stops this for good my time will be spent better: playing Baldur's Gate. The problem is not that I don't know python. Because I do know python (now). The problem is that pybugz DOES NOT SOLVE A FREAKING THING. I scan between 100 to 500 logs a day, any second it takes me to open a new bug adds to the likeliness I have no time to do so. Right now the filing is done purely through the browser so my Bugzilla authentication never leaves it. I get the failed log, I click on the open bug button, it prefills it, I leave a proper summary to point out what the problem is and block the proper bug. If the app were to just open the bug for me, the app would have to have the credentials, which means I have to have the app behind authentication. And as I pointed out multiple time I have no time or interest in supporting a properly authenticated app FOR ONE PERSON REFUSING TO READ A LOG. Because sure, it's not an impossible amount of work, but it's a disproportionate amount of work when only one person requires it, and another 200 are perfectly fine with clicking on a link to read a log. Same thing with pybugz as a CLI tool; sure I could have it store a copy of my credentials on my laptop and now copy-paste the bug ID after opening and the log URL. But no thanks because it makes opening a bug a 40 seconds operation and prone to more mistakes and, once again, this is disproportioned to ONE person refusing to accept a setup. So really, I'm tired to be insulted, and this was the last drop. Goodbye. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 21 November 2014 07:51, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 11/20/14 5:04 PM, Ian Stakenvicius wrote: Ok, added the RESO/NEEDINFO case, and bumped my polling time to 5 minute intervals. Diego, please keep going, your efforts are still very much appreciated. +1, and thanks Ian for your script! Paweł
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
On Fri, Nov 21, 2014 at 10:31 AM, hasufell hasuf...@gentoo.org wrote: On 11/21/2014 04:10 PM, Tim Harder wrote: On 2014-11-21 09:54, hasufell wrote: There are users who seem to like it and the games team wants to keep it as well, so I don't see a reason to push into that direction. The main thing is that you cannot turn off all the permission stuff in the eclass whether you like it or not. Changing the install variables thing is just for convenience and already possible. If people don't want to use the games eclass, then don't use it. I thought this had already been discussed and mostly ok-ed. I don't see the point of adding circumvention methods if you can just avoid it altogether. Are you serious? Instead of creating random competing concepts in one repository we should rather enhance configuration options, so that the USER can choose what he likes instead of the developer. I think this is a very bad idea. If we all decide to drop the eclass, then fine. Until then, users don't have any convenient way to have games world-executable without overwriting the eclass (which I currently do myself). It wasn't obvious to me that these were variables intended for end-user usage. Perhaps you could make this more clear in the comments?
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
On 11/21/2014 10:08 PM, Mike Gilbert wrote: On Fri, Nov 21, 2014 at 10:31 AM, hasufell hasuf...@gentoo.org wrote: On 11/21/2014 04:10 PM, Tim Harder wrote: On 2014-11-21 09:54, hasufell wrote: There are users who seem to like it and the games team wants to keep it as well, so I don't see a reason to push into that direction. The main thing is that you cannot turn off all the permission stuff in the eclass whether you like it or not. Changing the install variables thing is just for convenience and already possible. If people don't want to use the games eclass, then don't use it. I thought this had already been discussed and mostly ok-ed. I don't see the point of adding circumvention methods if you can just avoid it altogether. Are you serious? Instead of creating random competing concepts in one repository we should rather enhance configuration options, so that the USER can choose what he likes instead of the developer. I think this is a very bad idea. If we all decide to drop the eclass, then fine. Until then, users don't have any convenient way to have games world-executable without overwriting the eclass (which I currently do myself). It wasn't obvious to me that these were variables intended for end-user usage. Perhaps you could make this more clear in the comments? I've already written a patch for fixing the documentation. The games team suggests to do: GAMES_GROUP=users if you want games world-executable which isn't particularly the same, but close enough I guess?
Re: [gentoo-dev] Running repoman on the portage tree
On Wed, Nov 19, 2014 at 08:07:36PM +0800, Patrick Lauer wrote: http://packages.gentooexperimental.org/repoman-checks/ updated per cron job, split by category. Much easier to handle :) Feel free to work on fixing things - there's enough issues that you won't run out of work this decade. So, lets assume that a lot of users get their hands on fixing things (lets make Gentoo a better distro!). What's the work path here? Fix, diff, new bug I fixed this and that!? git portage... pull request? Just asking, but I know that fixing things that will stay forever on Bugzilla is killing motivation. Piotr Szymaniak. -- Yeah I called her up, she gave me a bunch of crap about me not listening to her, or something, I don't know, I wasn't really paying attention. -- Harry, Dumb Dumber signature.asc Description: Digital signature
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
Dnia 2014-11-20, o godz. 08:06:05 Anthony G. Basile bluen...@gentoo.org napisał(a): On 11/20/14 04:37, Michał Górny wrote: Dnia 2014-11-19, o godz. 17:41:53 Diego Elio Pettenò flamee...@flameeyes.eu napisał(a): On 31 October 2014 09:28, Diego Elio Pettenò flamee...@flameeyes.eu wrote: So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 More! https://bugs.gentoo.org/show_bug.cgi?id=529788 Again, is somebody going to stand up and do something or can I shut down my tinderbox and spend my free time playing Baldur's Gate? Comrel, please either do something about vapier or reassign all his packages (and team positions) to a volunteering proxy developer who will handle human relations for him. Chill dude. You should probably know that telling someone angry to 'chill dude' only increases the anger. On the other hand, telling that to someone who's not angry is meaningless. And I'm just frustrated because I have a lot of work on Gentoo. The obvious fact is that Gentoo is undermanned. The non-obvious part is that many developers are retiring or decreasing their activity because of the growing frustration. One of the major sources of frustration is Mike's behavior -- lack of respect for Council and other authorities, complete ignorance of rules and good taste, thoughtless committing without proper reviews of warnings, writing poor quality code because 'why do you care'... So sure, he's doing a lot, he has skills etc. but in the end, *I* end up having more work on my shoulders because of him. Because developers who could've helped me don't want to work on Gentoo anymore. Because he committed some untested crap and we have to clean up the mess (see libltdl for a late example). Because someone will finally have to clean up after him, and as far as I know, that someone will have to be me because nobody else will do it. And yes, I'm waiting for some free time to redo the toolchain. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 11/21/14 18:05, Michał Górny wrote: And yes, I'm waiting for some free time to redo the toolchain. That I will help you with. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Re: Running repoman on the portage tree
Piotr Szymaniak posted on Fri, 21 Nov 2014 23:06:30 +0100 as excerpted: On Wed, Nov 19, 2014 at 08:07:36PM +0800, Patrick Lauer wrote: http://packages.gentooexperimental.org/repoman-checks/ updated per cron job, split by category. Much easier to handle :) Feel free to work on fixing things - there's enough issues that you won't run out of work this decade. So, lets assume that a lot of users get their hands on fixing things (lets make Gentoo a better distro!). What's the work path here? Fix, diff, new bug I fixed this and that!? git portage... pull request? Just asking, but I know that fixing things that will stay forever on Bugzilla is killing motivation. For portage (and portage-related) apps in particular, there's the portage- devel list, gentoo-portage-dev. Portage development has changed recently and is /much/ better in terms of bus-factor now, and that was reflected on the list, so I'd recommend that particularly people with an on-going interest subscribe there and skim a couple months back in the history to get a decent overview of how things work now in terms of patch submission norms, coding style, etc. See gentoo-portage-dev as covered on the main gentoo mailing lists page here: http://www.gentoo.org/main/en/lists.xml Meanwhile, also see the portage-project page, which covers much of the patch rules, etc and has links to both the IRC channel and mailing list, portage git repos and issues like running multiple portage versions on the same system, etc, here: http://wiki.gentoo.org/wiki/Project:Portage -- 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: more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
Michał Górny posted on Sat, 22 Nov 2014 00:05:09 +0100 as excerpted: Dnia 2014-11-20, o godz. 08:06:05 Anthony G. Basile bluen...@gentoo.org napisał(a): On 11/20/14 04:37, Michał Górny wrote: Dnia 2014-11-19, o godz. 17:41:53 Diego Elio Pettenò flamee...@flameeyes.eu napisał(a): On 31 October 2014 09:28, Diego Elio Pettenò flamee...@flameeyes.eu wrote: So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 More! https://bugs.gentoo.org/show_bug.cgi?id=529788 Again, is somebody going to stand up and do something or can I shut down my tinderbox and spend my free time playing Baldur's Gate? Comrel, please either do something about vapier or reassign all his packages (and team positions) to a volunteering proxy developer who will handle human relations for him. Chill dude. You should probably know that telling someone angry to 'chill dude' only increases the anger. On the other hand, telling that to someone who's not angry is meaningless. And I'm just frustrated because I have a lot of work on Gentoo. The obvious fact is that Gentoo is undermanned. The non-obvious part is that many developers are retiring or decreasing their activity because of the growing frustration. One of the major sources of frustration is Mike's behavior -- lack of respect for Council and other authorities, complete ignorance of rules and good taste, thoughtless committing without proper reviews of warnings, writing poor quality code because 'why do you care'... While it pains me to say this, unfortunately it looks like we have another toxic person situation to deal with, with all the implications that come with it. Maybe it's time to deal with it. Best wishes to those on the council ATM, however they go. It's not an easy job in the best circumstances and unfortunately, we're not talking the best circumstances ATM. However it resolves, they're going to need wisdom and guts and social skills. We can all hope/pray to $DEITY/$FATES/$HIGHER- POWERS they have what's required, because the bandages applied to date are clearly no longer working. -- 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
Re: [gentoo-dev] Running repoman on the portage tree
On 11/21/2014 05:06 PM, Piotr Szymaniak wrote: On Wed, Nov 19, 2014 at 08:07:36PM +0800, Patrick Lauer wrote: http://packages.gentooexperimental.org/repoman-checks/ updated per cron job, split by category. Much easier to handle :) Feel free to work on fixing things - there's enough issues that you won't run out of work this decade. So, lets assume that a lot of users get their hands on fixing things (lets make Gentoo a better distro!). What's the work path here? Fix, diff, new bug I fixed this and that!? git portage... pull request? The long answer is: please become a developer, that's really the best way. If you're interested in fixing repoman warnings, updating EAPIs, and things like that, the QA team might be a good place to look for a mentor (#gentoo-qa). In the meantime, anyone can fill out the quizzes: http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt That will save you a lot of time when you do begin the recruitment process, since you can just send off the quiz that you already have finished. Just asking, but I know that fixing things that will stay forever on Bugzilla is killing motivation. Indeed, I know the feeling. To avoid burning out, you'd have to pick issues that are likely to actually get fixed. As a non-developer, that rules out the areas that could most use the help: maintainer-needed packages, and packages belonging only to herds that are essentially abandoned. Without the threat of commit access behind you, it's going to be next to impossible to fix those. And stable ebuilds can't be changed, so those are out. So I would look for ebuilds with active, non-herd maintainers that are still in ~arch to work on. And then open bugs that will get assigned to the maintainer. A diff against the latest ebuild in the tree is fine. If you do find a mentor in QA, I believe they have the authority to fix these things, so you might get some help if your fixes are ignored. Another way you can help out is to find the bugs that belong to upstream (e.g. parallel compilation), and submit fixes to their respective bug trackers. Then you can open a Gentoo bug pointing to the upstream report. When the upstream bug is fixed, the workaround can go away.
[gentoo-portage-dev] [PATCH] install-qa-check.d/90world-writable: fix usage of missing function
Fixes: 6dafdc288976 (Remove __eqalog __eqawarnlog)
---
bin/install-qa-check.d/90world-writable | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/bin/install-qa-check.d/90world-writable
b/bin/install-qa-check.d/90world-writable
index 2b435ac..1fb2a8f 100644
--- a/bin/install-qa-check.d/90world-writable
+++ b/bin/install-qa-check.d/90world-writable
@@ -23,9 +23,8 @@ world_writable_check() {
if [[ -n ${unsafe_files} ]] ; then
eqawarn QA Notice: Unsafe files detected (set*id and world
writable)
- for x in $unsafe_files ; do
- __eqawarnlog world-writable-setid $x
- done
+ eqatag -v world-writable-setid $unsafe_files
+
die Unsafe files found in \${D}. Portage will not install
them.
fi
--
2.0.4
