Re: [gentoo-dev] Mailing list moderation and community openness
Hey!!! I'm not going to open that bug, read all these related mailing list discussions or waste time on whatever! Instead, I think it's important some of you read this message: I hope that you choose to stand still for some time, or even sit or lie down for once. Take a deep breath and count to ten, then think about what the goal of Gentoo is and what your goal in this context is. Don't let these goals confuse others into random directions, but make it clear to yourself and everyone what they are. And with those thoughts, as well as second guesses; decide what you really want to do with it, for yourself and for others... Live your life; live it together <3 P.S: Not responding to you in particular, I'm spending my last time to collectively answer multiple threads from now and history On 3/20/2018 1:17 PM, Michael Palimaka wrote: I see that in bug #650964[1] Council is pushing forward again with implementing user whitelisting on this mailing list (ie. anyone that is not "approved" will have their mail rejected). Could someone please explain how this doesn't directly contradict the core tenets of an open and inclusive community? 1: https://bugs.gentoo.org/650964
Re: [gentoo-dev] ATTN: Fw: "Please let's talk if spamming everyone pointlessly is really needed."
Suspension shouldn't leave you out of receiving e-mails from Bugzilla;
if so, I consider that a bug.
On 6/9/2018 12:59 PM, Jeroen Roovers wrote:
Hello fellow humans,
this is a brief headsup about my current inability to communicate
through the official channel bugs.gentoo.org because of what seems like
a ComRel[1] action[2] suspending my account. If you have important
information to share on the many hundreds of packages I maintain, do
not hesitate to use my e-mail address directly or approach me on IRC
(Freenode or OFTC).
Kind regards,
jer
[1] I.e. the people purportedly responsible for ensuring proper
communications between members of the Gentoo Linux community.
[2]
https://rooversj.home.xs4all.nl/gentoo/2018-06-07-204422_1920x1080_scrot.png
Begin forwarded message:
Date: Thu, 07 Jun 2018 22:39:22 +0200
From: "Andreas K. Huettel"
To: Jeroen Roovers
Cc: bugzi...@gentoo.org, com...@gentoo.org
Subject: Re: "Please let's talk if spamming everyone pointlessly is
really needed."
Am Donnerstag, 7. Juni 2018, 20:51:30 CEST schrieb Jeroen Roovers:
What's going on here?
"Please let's talk if spamming everyone pointlessly is really needed."
^^^
If your mind is made up about the point of mass
changes, then why bother enquiring about it? I would think infra@
takes such actions to protect the services, not to argue about the
merits of changes.
This wasn't infra, this was me. Following a complaint on #g-comrel, I
checked the bug backlog and saw that you changed (likely much) more
than 50 bugs in a very short time. On a quick glance the changes were
against longstanding policy.
Thank you for getting back.
* If you see the necessity to change a long-standing guideline,
* and if that involves a lot of people getting a lot of non-informative
bugmail ("spam"),
I would be very grateful if you could
* inform the community about the policy change on the mailing lists,
* and coordinate with Infra so the mails are suppressed somehow.
Thank you. I will happily re-activate your account if you agree to
this, otherwise I'll defer a decision on that to the rest of comrel and
a vote.
For my part, I was doing what I have been doing for more than a
decade.
That is part of the problem.
Re: [gentoo-dev] metadata.xml unherd/-ization, v2
On Tue, 9 Dec 2014 16:23:57 +0100 Jeroen Roovers j...@gentoo.org wrote: On Tue, 9 Dec 2014 12:59:26 +0100 Ulrich Mueller u...@gentoo.org wrote: On Tue, 9 Dec 2014, Michał Górny wrote: As for the exact details, I've pretty much decided to go for featurism here, IOW making everyone happy. It also proves how absurd typing maintainers is but if you really feel like having it, sure. The default is 'developer', herd/ tags would be converted into 'herd' and there are other options including 'proxy-maintainer', 'project', 'team' meant to fit all our wannabies. The diff explains the particular options. !ELEMENT maintainer ( email, (description| name)* ) +!-- maintainer organizational type -- +!-- developer: regular Gentoo developer (direct e-mail) -- +!-- herd: herd (defined in herds.xml) -- As the previously stated goal was to get rid of herds, I don't understand why you want to reintroduce them as a value of the type attribute. The existing herd elements should become either type=project or type=team (everything that is not a project, I suppose). Probably because of the rather verbose criticism brought forward by a single developer. Probably because of the rather verbose burden of proof by another one.
Re: [gentoo-dev] Re: more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On Wed, 26 Nov 2014 16:52:07 -0500 Rich Freeman ri...@gentoo.org wrote: On Wed, Nov 26, 2014 at 4:21 PM, Tom Wijsman tom...@gentoo.org wrote: On Sat, 22 Nov 2014 00:34:33 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: 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. Toxic wars have casualties; in one of the sides, or in both of them. IOTW; you're already dealing with it, you can only change the outcome. Can you be clear as to what you're recommending? To look at the outcome and shape it for the better, whichever way fits. Are you suggesting that instead of trying to mediate between people who don't get a long, it would be better to just pick one or the other as the winner and boot the other out? ..., or in both of them; and to be complete, let me add or neither. One of the challenges here is that if we were talking about just one productive person who tended to drive everybody away that would be one thing. The problem is that we have a lot of productive people who have different sorts of personality quirks. They range from blowing up in public, to constant passive-aggression, to just silently doing their own thing completely ignoring any input whatsoever. I'm sure I missed a few, like writing excessively-long emails. :) The challenge lies in how far to push and/or hold back people and/or their content; exploring the spectrum between active and passive moderation, as well as the different types of warnings and actions. One or more clear positive messages, followed by an action of 24h, ... I guess one of the advantages of a model where devs turn into reviewers instead of authors is that you can prioritize people skills since their main role isn't to actually write the code so much as to coordinate things. However, this assumes that people would still contribute in such a model. It also assumes the model to change attitude.
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On Fri, 21 Nov 2014 16:32:15 + Diego Elio Pettenò flamee...@flameeyes.eu wrote: So really, I'm tired to be insulted, and this was the last drop. Goodbye. Diego Elio Pettenò — Flameeyes +1! Given our invested time; it's not the lack of encouragement, but rather the presence of discouragement that sets up for unpleasant moments. Every drop is one too much...
Re: [gentoo-dev] Re: more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On Sat, 22 Nov 2014 00:34:33 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: 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. Toxic wars have casualties; in one of the sides, or in both of them. IOTW; you're already dealing with it, you can only change the outcome. 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. Ignoramus et ignorabimus. IOTW; you can't see the future, gut feeling play a very big role. 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. Band-aids don't fix bullet holes. IOTW; while it may or may not change the outcome, war is a real threat.
Re: [gentoo-dev] Java7 stabilization
On Mon, 10 Nov 2014 12:23:43 +0100 Pacho Ramos pa...@gentoo.org wrote: Hello Hello, this is an individual response. I would like to see if we could finally try to stabilize java7 on Gentoo as some external tools start to require it. There is currently this tracker opened: https://bugs.gentoo.org/show_bug.cgi?id=384609 I am unsure why: https://bugs.gentoo.org/show_bug.cgi?id=483018 should block the stabilization as we can have multiple java versions installed due slots Multiple stable Java versions means more work; so, you'll instead want to bring incompatible packages forward to Java 7 or mask and lastrite them as time goes by. The tracker list two broken packages that would need either patching or to be forced to use older slots and this one: Under the work train of thoughts, an older slot is a temporary measure. https://bugs.gentoo.org/show_bug.cgi?id=515830 That looks more important. Then, I also wonder about what implementations are we meant to look for this stabilization. Should we look for bugs affecting icedtea-bin and also oracle's implementation? If you look at the history, multiple implementations are stabilized; this means that bugs should indeed look at whether they affect both versions. In general, fixing a bug for one implementation fixes it for the other implementation or the other implement didn't even have the bug to begin with; but that shouldn't fool us to check them both out. (I was wondering if the tracker was really collecting all the issues :/) Doubtful. A tree wide check is necessary to confirm that all Java based packages build with the to be stabilized Java 7 implementations.
Re: [gentoo-dev] Packages up for grabs
On Tue, 11 Nov 2014 16:59:46 +0200 Pavlos Ratis daster...@gentoo.org wrote: I will also drop myself from the net-proxy herd. Drawing extra attention to this sentence; it looks like the herd is (once again) going to be empty, as the result of a lack of interest. If someone does have a real interest in this herd; please step up now, otherwise this herd is probably going to face a removal in the future.
[gentoo-dev] Packages up for grabs
Hello all Due to lack of time I'm giving up some packages. Feel free to take them: app-admin/ec2-ami-tools app-admin/ec2-api-tools These command-line tools serve as the client interface to the Amazon EC2 web service app-admin/logmon Split-screen terminal/ncurses based log viewer app-admin/usermin A web-based user administration interface app-admin/yaala Yet Another Log Analyzer app-editors/retext A Qt-based text editor for Markdown and reStructuredText app-misc/fslint A utility to find various forms of lint on a filesystem app-text/logmerge Merge multiple logs such that multilined entries appear in chronological order without breaks dev-games/aseprite Animated sprite editor and pixel art tool dev-python/markups A wrapper around various text markups dev-util/cdiff Colored, side-by-side diff terminal viewer dev-util/oprofile A transparent low-overhead system-wide profiler media-libs/libmkv Lightweight Matroska muxer written for HandBrake media-sound/teamspeak-client-bin media-sound/teamspeak-server-bin TeamSpeak Client / Server (Voice Communication Software) media-video/openshot Free, open-source, non-linear video editor to create and edit videos and movies sys-apps/epoch An init system (analogous to systemd or upstart) for Linux by Subsentient; it is intended as a lightweight solution for lightweight distributions that don't want a huge mess just to boot up; it has one unified configuration file, is very small in size, and it has no external dependencies besides glibc or similar; installing a shell for /bin/sh is strongly recommended sys-process/ftop Monitor open files and filesystems www-misc/monitorix A lightweight system monitoring tool x11-misc/growl-for-linux A Linux-compatible version of Growl, a notification system for Mac OS X Thanks, Tom Wijsman
Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml
On Wed, 8 Oct 2014 09:22:30 +0200 Jeroen Roovers j...@gentoo.org wrote: On Wed, 8 Oct 2014 00:07:07 +0200 Tom Wijsman tom...@gentoo.org wrote: If the name is omitted, then we lose that; that is not the way forward. I'm pretty sure we already addressed this in another branch of this thread. No. Bringing up the workings of IRC bots doesn't add anything. It is not about the workings, it is about the need for it to work; if we break it, we also break our ability to use it! Don't omit anything.
Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml
On Sun, 5 Oct 2014 22:53:13 +0200 Jeroen Roovers j...@gentoo.org wrote: On Sun, 5 Oct 2014 18:30:04 +0200 Tom Wijsman tom...@gentoo.org wrote: On Sat, 4 Oct 2014 09:18:55 +0200 Jeroen Roovers j...@gentoo.org wrote: herdemailf...@gentoo.org/email/herd herdname.../nameemail.../email/herd to keep willikins' !meta -v functionality working. You mean we should design our organisational structures around an IRC bot now? We should design metadata for our consumers; which include IRC bots, an often used interface through which herd member list information is read. If the name is omitted, then we lose that; that is not the way forward.
Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml
On Sat, 4 Oct 2014 09:18:55 +0200 Jeroen Roovers j...@gentoo.org wrote: herdemailf...@gentoo.org/email/herd herdname.../nameemail.../email/herd to keep willikins' !meta -v functionality working.
Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml
On Tue, 30 Sep 2014 00:40:50 +0200 Jeroen Roovers j...@gentoo.org wrote: On Mon, 29 Sep 2014 23:16:32 +0200 Tom Wijsman tom...@gentoo.org wrote: On Mon, 29 Sep 2014 18:42:40 +0200 Jeroen Roovers j...@gentoo.org wrote: On IRC we seem to have found some consensus about metadata.xml: IRC is huge; where did you manage to find consensus in there with whom? I have no idea how to respond to that. It doesn't matter whether you were there or not: this was the outcome we agreed on and here is a proposal that should make working with the bug tracker a lot easier. The outcome of what? Who agreed on it? If these questions have no answers, the statements made have no meaning; they hide away the true goal, which now becomes clear in proposal to make bug tracker easier. Then we arrive at the next question: What is so hard about bug tracking? 1 ) We should 1a) deprecate the herd tag in metadata.xml (that's 17,856 files or so?) in favour of 1b) a conversion to their respective maintainer tags 1c) where the email tag serves the same purpose as herd but bypasses herds.xml completely by just using the intended alias and not the name of the herd (which some developers might want to keep in the name tag for whatever purpose). This loses information that denotes it to be a herd, not a maintainer. maintainer email[address of the herd]/email name[name of the herd]/name !-- if you like -- /maintainer Please provide some examples of when and how that piece of information, herd, is important. Knowing whether to contact one or more persons; eg., /nick cjk on IRC can confuse this easily, where !herd cjk was as obvious as can be. Note that the proposal involves trade-offs and consequences. 2 ) Important to note is that this makes the order in which tags in metadata.xml are used in assigning bugs is made more explicit and simple. Previously the first maintainer or in its absence the first herd would be the Assignee, and the rest would be CC'd. This changes now to a much simpler scheme where 2a) the first maintainer is always the Assignee, and the rest is CC'd, so that 2b) instances where metadata.xml lists a maintainer tag after a herd tag would need to have the order fixed: the herd tags that are converted to maintainer tags should be moved to a place in the file after the original first maintainer tag. This loses the lack of ordering, requiring unnecessary attention to it. There has never been a lack of ordering. The way bugs are assigned since 2008 is as described in 2a. It requires not reordering the XML tags. 2b says the order of appearance denotes the Assignee. A comparison reveals that ordering gets introduced by this proposal: Before: maintainer always goes _before_ herd After: maintainer goes _before or after_ the new herd maintainer Therefore there was a lack of ordering; whereas the maintainer vs herd order was implicit before, the proposal makes the order explicit. 3 ) We end up with metadata.xml files that have no herd tags and only maintainer tags. 3a) herds.xml is now unimportant in assigning bugs. 3b) Tools that use herds.xml no longer need a copy of herds.xml to look up who is responsible for a package. 3c) herds.xml can be safely kept up to date and used elsewhere and can be safely phases out in time. This is nice to have, as automatic assignments reveal; but this makes it harder for a herd to change its e-mail address, which happens sometimes. Go back in history and tell us how often herds change their e-mail address. And how many metadata.xml files would have been affected. And how that reflects on the future. And then compare that with the everday chore of doing the extra lookup in herds.xml that shouldn't be needed at all if the only thing you need is an e-mail address. 4 ) We might achieve the herd = maintainer conversion by 4a) setting up repoman to deny commits that keep herd or 4b) setting up repoman to automatically convert the entire thing 4c) both of which might end up taking a good while to complete, or 4d) do an automated mass conversion of the entire gentoo-x86 tree. We might not need a conversion; it also changes/requires another tool. The proposal says we convert herd to maintainer in metadata.xml. 4d explains how you wouldn't need changes to repoman. The proposal is unaware of the amount of metadata.xml files; the extra mapped lookup in herds.xml is free, changing metadata.xml files is not. 5a) All ontological discussion of the meaning of herds and projects is entirely unrelated - we're just looking to make it much easier to look up metadata about packages using as few resources as possible. 5b) All ontological discussion of the meaning of herds and projects is instantly rendered a lot less important. We have less need to bring this up every year or so. That important
Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml
On Tue, 30 Sep 2014 09:12:13 -0400 Rich Freeman ri...@gentoo.org wrote: On Tue, Sep 30, 2014 at 3:00 AM, Ulrich Mueller u...@gentoo.org wrote: I had just given some reasons above, in the part that you haven't quoted. My main issue was with the burden of proof bit. This isn't a court - we're free to do whatever seems to make the most sense, and not worry about what kind of precedent it sets, since the next Council can do whatever makes the most sense at that time. :) Is it fine to replace something that has worked for years without proof? I'm all for something that covers the bases but is a bit cleaner in design. Right now we have different sources for membership lists of different kinds of groups, and that just seems like poor normalization. Why does it seem poor? How to have a single list for different kinds? Is normalization necessary? Does normalization make it cleaner at all? The groups are of a different kind for a reason; normalization, YAGNI.
Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml
On Tue, 30 Sep 2014 23:03:51 +0200 Jeroen Roovers j...@gentoo.org wrote: On Tue, 30 Sep 2014 13:01:35 +0200 Ulrich Mueller u...@gentoo.org wrote: On Tue, 30 Sep 2014, Jeroen Roovers wrote: The same tags shouldn't be used for different things. Then we might as well extend the DTD to have a required email tag nested in each herd tag. But IIUC, the DTD must be changed also if the herd tag is removed? (Unless we want to leave a dead element in there.) If people are that attached to herd then we should apparently fix it instead of removing it, possibly by making it closely resemble maintainer. This sub proposal is a solution to most of the proposal disagreements. +1
Re: [gentoo-dev] Add bc back to the stage3
On Tue, 30 Sep 2014 18:58:18 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 29 Sep 2014 23:37:20 +0200 Tom Wijsman tom...@gentoo.org wrote: On Mon, 29 Sep 2014 04:05:19 + (UTC) Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: On Sat, 27 Sep 2014, Tom Wijsman wrote: On Sat, 27 Sep 2014 13:22:45 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 27 Sep 2014 12:47:14 +0200 Luca Barbato lu_z...@gentoo.org wrote: Because I'd expect a stage3 to be posix compliant I agree. It's time to replace nano with Vim. It seems like everyone needs to chill a bit. Ciaran wasn't trolling, he was making a point. I'm sure everyone around here understood his point. There were no attacks and no foul language, so can we move forward? Constructiveness does not rely on just making points, as replacing nano with Vim is out of the context of adding bc back to stage3. Editors are a world apart from a build tool, even more so from being POSIX. In order to move forward beyond this point, that needs to be recognized. Ah, quotes are getting cut out, lovely; it focuses on what is crucial.
Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml
On Mon, 29 Sep 2014 18:42:40 +0200 Jeroen Roovers j...@gentoo.org wrote: On IRC we seem to have found some consensus about metadata.xml: IRC is huge; where did you manage to find consensus in there with whom? 1 ) We should 1a) deprecate the herd tag in metadata.xml (that's 17,856 files or so?) in favour of 1b) a conversion to their respective maintainer tags 1c) where the email tag serves the same purpose as herd but bypasses herds.xml completely by just using the intended alias and not the name of the herd (which some developers might want to keep in the name tag for whatever purpose). This loses information that denotes it to be a herd, not a maintainer. 2 ) Important to note is that this makes the order in which tags in metadata.xml are used in assigning bugs is made more explicit and simple. Previously the first maintainer or in its absence the first herd would be the Assignee, and the rest would be CC'd. This changes now to a much simpler scheme where 2a) the first maintainer is always the Assignee, and the rest is CC'd, so that 2b) instances where metadata.xml lists a maintainer tag after a herd tag would need to have the order fixed: the herd tags that are converted to maintainer tags should be moved to a place in the file after the original first maintainer tag. This loses the lack of ordering, requiring unnecessary attention to it. 3 ) We end up with metadata.xml files that have no herd tags and only maintainer tags. 3a) herds.xml is now unimportant in assigning bugs. 3b) Tools that use herds.xml no longer need a copy of herds.xml to look up who is responsible for a package. 3c) herds.xml can be safely kept up to date and used elsewhere and can be safely phases out in time. This is nice to have, as automatic assignments reveal; but this makes it harder for a herd to change its e-mail address, which happens sometimes. 4 ) We might achieve the herd = maintainer conversion by 4a) setting up repoman to deny commits that keep herd or 4b) setting up repoman to automatically convert the entire thing 4c) both of which might end up taking a good while to complete, or 4d) do an automated mass conversion of the entire gentoo-x86 tree. We might not need a conversion; it also changes/requires another tool. 5a) All ontological discussion of the meaning of herds and projects is entirely unrelated - we're just looking to make it much easier to look up metadata about packages using as few resources as possible. 5b) All ontological discussion of the meaning of herds and projects is instantly rendered a lot less important. We have less need to bring this up every year or so. That important ontological discussion is related as it is the origin, the proposal changes a fundamental file of the Gentoo Herds Project[1]; by doing so, you make changes in the meaning of a herd and its context. Reading further, we interestingly see that per the project page[1] 1) the metadata in metadata.xml must have a herd tag present, 2) a herd in herds.xml is not required to have an e-mail address; where the latter (2) is even confirmed by the herds.xml DTD[2]. [1]: http://www.gentoo.org/proj/en/metastructure/herds/ [2]: http://www.gentoo.org/dtd/herds.dtd
Re: [gentoo-dev] Add bc back to the stage3
On Mon, 29 Sep 2014 04:05:19 + (UTC) Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: On Sat, 27 Sep 2014, Tom Wijsman wrote: On Sat, 27 Sep 2014 13:22:45 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 27 Sep 2014 12:47:14 +0200 Luca Barbato lu_z...@gentoo.org wrote: Because I'd expect a stage3 to be posix compliant I agree. It's time to replace nano with Vim. Vim is not fully POSIX compliant; you may find it claim mostly in its documentation, but that's where it stays at and thus doesn't suffice... While we're at it, we must make everyone use a POSIX IDE with a ribbon! Jokes aside, this sub discussion is pointless; if we want results, a moderated mailing list as suggested in a reply won't cut it! It seems like everyone needs to chill a bit. Ciaran wasn't trolling, he was making a point. I'm sure everyone around here understood his point. There were no attacks and no foul language, so can we move forward? Constructiveness does not rely on just making points, as replacing nano with Vim is out of the context of adding bc back to stage3. Editors are a world apart from a build tool, even more so from being POSIX. In order to move forward beyond this point, that needs to be recognized. Does that make him attacking / foulish / trollish / unchilling? No; actually, it is helpful / smart / fluffy / chilling towards consensus as both the opposite and sarcastic interpretations help form that. What is really needed here is a vote by the Council on whether to add bc back to the stage3. If the people do insist, another vote regarding adding or changing an editor to stage3 could be done as well. No, there isn't a need for a Council vote here. Not in the way of having the Council actually vote, but by waking up everyone from these endless side points sub discussions by escalation. This is something up to Releng (in respect to what is in the stages) and to everyone in respect to what is part of the system set. Further, to me, this is a case where if anyone tries to side-step Releng and go over it with a Council decision, than the council members should be ready to start doing Releng work. I've stopped following this mailing list regularly quite sometime ago. To see this thread is still going on and no one bothered to cc releng, to me shows a lack of respect for the people actually doing releases around here, as well as a real lack of interest in getting this done as you can discuss this all you want, but in the end, it's releng that works on this. If people desire a change, it'll be discussed for an eternity; until ...
Re: [gentoo-dev] Add bc back to the stage3
On Mon, 29 Sep 2014 06:08:11 +0200 Peter Stuge pe...@stuge.se wrote: Jorge Manuel B. S. Vicetto wrote: I've stopped following this mailing list regularly quite sometime ago. To see this thread is still going on and no one bothered to cc releng, to me shows a lack of respect I expected you to participate on the developer list to some degree, since you are developers. Isn't that even mentioned in a quiz somewhere? Only a small few MLs are mandatory; as for most others, a developer is free to sub/unsub to/from a ML as they see fit. There was a mail[1] send out by the Gentoo Council regarding awareness of gentoo-dev ML threads. [1]: http://article.gmane.org/gmane.linux.gentoo.project/3549 (see 2-3)
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Sun, 28 Sep 2014 00:21:43 +0200 Michał Górny mgo...@gentoo.org wrote: I don't know if you know it but setting up the project wiki page takes less time than reaching into depths of CVS and editing herds.xml. Editing and committing a change to herds.xml takes me less characters than this quoted paragraph, done in under a minute; in comparison, a project wiki page involves a browser, waiting time and more characters. Otherwise, we'll never going to get out of the dumb distinction what project and herd is and isn't, and when one or the other, or both should be used. The documentation and GLEP(s) are pretty clear about that; as for how to use it, that are semantics that are up for the projects and herds. This has worked fine for ages, point me to old threads discussing this if you claim that to not be the case. Recent assumptions make it look like it is a problem, but a history of experience tell us otherwise...
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Sat, 27 Sep 2014 18:45:12 -0400 Rich Freeman ri...@gentoo.org wrote: So, there was some discussion on -dev, apparently some discussion I wasn't a part of, and some that I was (such is the nature of IRC). Knowledge codification is nice; otherwise, this is just-another-thread. I think it would make sense to take a step back and ask what we'd do if we were starting with a blank slate. Aliases, herds, and projects are all ways of grouping people, but they are used in different ways, sometimes. Looking at a blank slate hides the origin of these ways. Aliases set up mails on the infrastructure. Herds assign multiple relevant maintainers to multiple packages. Projects are a need for serious organization. This is what we have ended up with starting from that blank slate. My real problem with herds isn't the idea of having more than one way to group people. My real issue is that we have several ways of grouping people and no consistent way of doing so. You have to look in different places to find out who is on an alias/herd/project. We have cases where more than one of these are loosely associated, but membership is inconsistent. Aliases are there to support herds or projects, it shouldn't be seen as a separate way to group people. The other groups are straight froward; herds for groups that maintains packages, projects for groups that take on a serious project. Projects that take on packages have created herds (eg. proxy-maintainers, ...); so, this is or can be consistent. We have inactive examples of all three. Yes, they capture inactivity; iotw, what's in a herd/project name? :) So, let's step back and think about why developers would want to be part of a group, forget about what we call these groups, and then figure out what kind of model makes the most sense and how to get there. In the final design we might want to not split groupings up all over the place (wiki vs herds.xml vs alias files that nobody but devs can read). So, one level of association might be registering an interest - such as what is sometimes done with a mail alias. A developer, or even a non-developer, might want to be informed about what is going on with a package or group of packages, but they are not making any kind of commitment to actually taking care of them. The opposite would be a project as defined in GLEP 39. This is a formal association of developers that elects a lead, and acts as a unit. The project could establish policies and it is generally expected that they be followed (we can escalate to the Council if there is a problem). This is especially valuable for core dependencies like toolchain, frameworks, etc where good planning makes everybody's lives easier. Then you have groups of people who sort-of maintain peripheral packages, which is what I think is what many herds are (but their use is totally inconsistent, so this isn't true everywhere). If read and compared correctly, the origin paragraph is a TL;DR to this. My issue with this sort of thing is that it is really hard to tell if a package is actually maintained. Devs basically drop-in to scratch an itch and then abandon things. Emails to aliases get ignored, since nobody in particular is in charge. That is my main issue with herds - they're dumping grounds for bugs that nobody seems to care about, at least in some cases. +1, as some of us revealed; but note that projects can also hide abandoned efforts, eg. the Council recently cleaning old dead projects. With a project you can at least ask have you selected a lead in the last year and get some kind of pulse on activity. There are projects which haven't selected a new lead for years ... Herds are nice from the standpoint that they cost nothing to maintain, but that also means that there is no way to gauge commitment. Having an election is a big like some proposals to charge $1 to register a copyright renewal - it isn't about the cost so much as just making somebody actually do something to prevent de-listing. ... thus it only works when some entity external to the project forces new lead elections; as otherwise, projects have no such $1 ping-pong. I guess my question is when is something like a herd the best solution to a problem, and what is that problem? Unnecessary stuff: Organization, knowledge codification, time, work, ... I don't want to change for the sake of change. If we stay the same I'd like it to be because what we're doing actually makes sense. It made sense to me from day #1 of contributing to Gentoo; it surprises me that this all of the sudden is assumed to be a problem, it makes me rather skeptic about whether a structure change is needed. If we do keep something like herds, I'd still consider some way to consolidate herd/project membership lists so that tools can scan a single location. Whether a group is a herd/project/alias could be an attribute. This is no different than not having separate ldap
Re: [gentoo-dev] Add bc back to the stage3
On Sat, 27 Sep 2014 19:39:44 -0400 Anthony G. Basile bluen...@gentoo.org wrote: And now for something completely different ... drum roll ... Really! We have to have a council vote on whether bc goes into stage3? If this does go to the council, then I want a pre-vote vote: should we bounce the decision back to the releng team? We should not micro manage to this level. The Council gets involved when there is disagreement, which makes this more serious than micro management; but sure, if they want to revisit the case then that could work out as well. The releng team's input on this case is important, even if it ends up going to Council.
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Sat, 27 Sep 2014 06:25:28 -0400 Rich Freeman ri...@gentoo.org wrote: On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers j...@gentoo.org wrote: Right now, CC'ing a single alias is inconvenient, but under your proposal, you might need to CC a dozen or more people instead of that alias. That is incorrect. Herds would be replaced with projects, not with lists of individual (non-)maintainers. I don't think that anybody thinks that having groups of devs isn't useful. The problem is that we have two different mechanisms for having groups of people, and one of them seems to make more sense than the other. Answer this: 5 developers want to maintain a group of packages together. Should they form a herd, or a project? Under what circumstances should they choose one vs the other? I don't think the distinction is particularly useful, and projects at least have a straightforward governance model. -- Rich Herds cannot be replaced by projects, because projects can contain multiple herds; iotw, there's no one-to-one mapping between them. I don't think having multiple mechanisms to form groups is a problem; from my previous paragraph, it becomes clear that it is a solution. Answer: The project model has some concepts that herds do not have. I don't think discussing this is useful, projects are documented.
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Sat, 27 Sep 2014 09:11:57 -0400 Rich Freeman ri...@gentoo.org wrote: Is there some policy that says that a project cannot be a maintainer? Is there some policy that says that a herd cannot be a herd?
Re: [gentoo-dev] Add bc back to the stage3
On Sat, 27 Sep 2014 13:22:45 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 27 Sep 2014 12:47:14 +0200 Luca Barbato lu_z...@gentoo.org wrote: Because I'd expect a stage3 to be posix compliant I agree. It's time to replace nano with Vim. Vim is not fully POSIX compliant; you may find it claim mostly in its documentation, but that's where it stays at and thus doesn't suffice... While we're at it, we must make everyone use a POSIX IDE with a ribbon! Jokes aside, this sub discussion is pointless; if we want results, a moderated mailing list as suggested in a reply won't cut it! What is really needed here is a vote by the Council on whether to add bc back to the stage3. If the people do insist, another vote regarding adding or changing an editor to stage3 could be done as well.
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On Fri, 19 Sep 2014 16:03:57 +0200 Tobias Klausmann klaus...@gentoo.org wrote: As I pointed out, getting the right code into the tree is not the problem here. It is extra work over the current way of doing it (since I need to deal with a local commit that can't be ff'd or rebased as git is very line-oriented. It can be rebased when you use branches, which is less line-oriented; yeah, that indeed is extra work over plain single commit. This can be improved with shell aliases or functions, to spare out on key presses... On top of the extra work, there have been several mentions that only meaning ful merge-commits are wanted in the tree (or not wanted at all). AIUI, avoiding them in the keywording/stabilizing phase is currently very difficult, unless we split KEYWORDS into separate lines or find another mechanism (like having the maintainer/keyword-requestor do all the edits after the archs sign off on them). Not a problem when you rebase. I'd be delighted to hear a simpler solution that only involves doing the semantic merge (like we do now with CVS). Create one or two shell aliases or functions for pulling that do: 1) stashes your local modifications 2) create a new branch with your local commits 3) reset the master branch to the last upstream commit 4) pulls new changes into the master branch 5) rebases your new branch onto master 6) remove the master branch and rename your new branch to it 7) applies the stash from step (1) Given that the rebase is interactive, 1-5 and 5-7 will probably be separate shell aliases or functions; nonetheless, this takes away a ton of manual typing giving you more time for where the actual work is. I would advise against this automation for other projects; but given the plain single commit nature we're used to, this works for Portage tree. And at least in my case, collisions during keywording are fairly common, and will be even more so with git since fetch/pull are slower than for a CVS subdir (since git checks the whole tree for local changes, not just the current subtree, AIUI). Has this been experimented with? Is the Portage tree that big? Afaik Git does a lot to be fast, whereas I experience CVS to be slow; I would be surprised if Git were to be slower than faster compared to CVS. Again, correct me if I'm wrong. I've been using git for ~4 years, but only in single-developer mode. And even there I managed to make a mess of repo histories :-/ Fortunately, nobody cares about my stuff. Reading into Git workflows and documentation about stashing, rebasing, ... can make a world of difference to turn mess into a gem.
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On Mon, 22 Sep 2014 08:56:04 +0200 Michał Górny mgo...@gentoo.org wrote: How can we distinguish between accidental and intentional stable keyword removals? :) (The lack of) Proper commit messages that point out those removals! ;) But well, yeah, that'll require consistency and so on...
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On Thu, 18 Sep 2014 19:39:08 +0200 Tobias Klausmann klaus...@gentoo.org wrote: AIUI, we try to avoid merge conflicts, unless the merge is a meaningful integration of divergent processes. However, one aspect of how ebuilds are written these days will cause a non-trivial amount of merge commits that are not actually useful in that sense. The concept of rebasing your commits has been invented for this. In the less common case that multiple people change the keywords, a manual three way merge is a breeze; taking into consideration that maintainers should be aware of KEYWORDS and other recent changes to their packages.
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
On Thu, 11 Sep 2014 23:40:32 + hasufell hasuf...@gentoo.org wrote: I don't see [...] It is hard to connect the dots if you don't know about the dots; do your homework to find them, ask questions when you don't. [...] any sense in what you say. You sound confused. Without those dots, your sound of confusion sees no sense.
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
On Sat, 13 Sep 2014 22:44:49 + hasufell hasuf...@gentoo.org wrote: Jauhien Piatlicki: In the ideal country of elves. In the real life it can be not possible to build and install software in a given distribution without downstream patches. You can find examples of such live ebuilds in Gentoo tree. I think it's not appropriate and shouldn't generally be done (with a few exceptions). If the live ebuild needs heavy patching to even work, then don't commit it to the tree. Patches come and go, that has nothing to do with its presence in the Portage tree. We shouldn't remove and add them based on the varying amount of patches, as that is much work with an unfavorable result. Anyway, summarizing, it is completely impossible to be sure that live ebuild will be buildable for you on a given arch in the next 15 min., even if it was so in the last 15 min. That goes for almost all ebuild variables. So you either drop the whole concept of live ebuilds or you do what is reasonable: Given that some users specifically request them, the concept lives on. a) provide consistent ebuild information, including keywords KEYWORDS= is as consistent as it can get. b) ask upstream about their git workflow, which branches they use, what arches they even officially support This is not how we fill in KEYWORDS. c) only add live ebuilds if the upstream git model is something that can be relied upon in one way or another and if you can keep up with the changes The entire package presence depends on this, not just the live ebuilds. If your live ebuild breaks every 15 minutes, then it shouldn't be in the tree. Bleeding edge is designed to break every 15 minutes; live ebuilds are bleeding edge, some users do want bleeding edge in the Portage tree. I actually don't commit live ebuild unless I know that upstream is collaborative and I'v contributed to almost all of the projects which I package as live ebuilds. Consider to step outside the ideal country of elves* and explore. (* quoting Jauhien's words)
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Thu, 11 Sep 2014 21:00:16 +0100 Markos Chandras hwoar...@gentoo.org wrote: please do not go offtopic discussing the recruitment process. I simply mentioned one of the designated ways we have to ask for help. If you don't like it, propose a better method. Please do not go offtopic about your own getting people on board. I simply suggested improvements to one of the designated ontopic problems that can be seen in herds. If you don't like it, write a better reply.
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
On Mon, 15 Sep 2014 10:11:08 +0100 Georg Rudoy 0xd34df...@gmail.com wrote: How frequently the list of supported arches does shrink? Is it statistically significant? The amount of software that exists makes this impossible to determine.
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
On Mon, 15 Sep 2014 10:28:16 +0100 Georg Rudoy 0xd34df...@gmail.com wrote: Let's limit our sample to Gentoo tree then. How frequently arches list shrinked as a result of bumping the version (because the upstream has chosen so, not because of insufficient resources to keep testing all previously stated arches)? They do not shrink only due to a result of bumping. In the ideal case it is indeed announced and we can do it at bump time; in the less ideal case they rather shrink due to us finding out that a particular major feature does no longer work on an architecture. This could thus also happen due to an incompatibility with one or another dependency for which no further architecture specific code is written, or perhaps due to an architecture specific bug that has arisen. In the ideal case, shrinking wouldn't be a problem; in the less ideal case, having no keywords is preferable to shrinking as continuously testing live ebuilds isn't affordable.
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
On Wed, 10 Sep 2014 15:09:38 + hasufell hasuf...@gentoo.org wrote: Tom Wijsman: It improves usability by providing additional information. Usability is not to be found in information that is subject to change. Please also set DEPEND, RDEPEND, EGIT_REPO_URI, DESCRIPTION and the rest of them to , because they are all subject to change. Most of them are destructive to proper arch testing, where keywords are not destructive to it. As for DESCRIPTION, that is not subject. So, both quotes reveal that empty keywords fit very well; No, they just reveal that people didn't think carefully enough before establishing that policy. Check the history instead of making wild guesses about past thoughts; if you want to rate context, give facts and references to back it up. by limiting its length. Welcome to 2014. We have tools that can aid you with dealing with big files. Even in 2014, we clean crap; tools aren't an excuse for not recycling. Information that is a given; as known, live ebuilds miss arch testing. If an ebuild hasn't been tested on _any_ arch, then it shouldn't be in the tree at all. Live ebuilds are an exception that can be in the Portage tree. If you want to suggest their removal from the Portage tree, start a new thread. In addition, it is obviously wrong, since most people will at least test their own live ebuilds on major arches and they are allowed to add those keywords without involving arch teams. So, they throw proper arch testing and snapshots out of the window?
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Wed, 10 Sep 2014 21:21:24 +0100 Markos Chandras hwoar...@gentoo.org wrote: On 09/10/2014 03:01 PM, Tom Wijsman wrote: +1; to summarize my thoughts: Herds misrepresent manpower. true and false. More true than false. undertakers often remove dead herds. How often? What is considered dead? How about semi-dead? How about the misrepresented ones? Are metrics like commit and bug ratios considered? Relevant: http://www.gossamer-threads.com/lists/gentoo/dev/258463 And herds in need for more people should really make use of this wiki page https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs They do and don't. Those that do, are drowned in a long list that rarely attracts new devs; those that don't, don't have time for it as they are drowned in work. The recruitment process is too lengthy compared to the amount of people that can actively recruit new developers; as a result, this contributes to the rarity of attracting new developers to that list. This lengthy process is also unattractive to new recruiters; whom are not kept in the loop when showing interest, eg. I've watched a few sessions and then heard nothing (because there barely are recruiters?). If we want to thrive, both the student and recruiter recruitment processes need to be revised; at this moment, 13 students are in the queue. Some of them have been waiting for weeks or months... how do you expect to get more people on board if you don't make it known where help is actually needed? This acknowledges that the herds concept hides where help is needed; but as revealed in the last paragraphs, that's not the only problem.
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
On Tue, 09 Sep 2014 19:12:28 + hasufell hasuf...@gentoo.org wrote: Jauhien Piatlicki: When I accept ~arch I expect that no live ebuilds will be built. I think other gentoo users expect the same. Just because users are used to it doesn't make it better. How does it make it better for users that are used to what works well? Emerging live ebuild usually is quite a risky thing, so hiding such stuff behind dropped keywords is quite reasonable. That's why you can mask them. Masking is for packages that are known to be broken, not for risks. Hiding useful information from users is not reasonable. Eh? Jauhien talks about hiding the visibility from the package manager. The same flawed logic of empty KEYWORDS could actually be applied to any ebuild variable. You say we can't test if it works for all these architectures reliably and for every single commit. Yeah, same goes for dependencies, license and even the description. Because it's a live ebuild, all of them can change. KEYWORDS is no special exception. KEYWORDS is a special exception because it involves arch testing.
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Tue, 9 Sep 2014 21:45:49 +0200 Michał Górny mgo...@gentoo.org wrote: Let's keep it short: I think herds don't serve any special purpose nowadays. Their existence is mostly resulting in lack of consistency and inconveniences. +1; to summarize my thoughts: Herds misrepresent manpower.
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
On Wed, 10 Sep 2014 13:56:04 + hasufell hasuf...@gentoo.org wrote: Tom Wijsman: On Tue, 09 Sep 2014 19:12:28 + hasufell hasuf...@gentoo.org wrote: Jauhien Piatlicki: When I accept ~arch I expect that no live ebuilds will be built. I think other gentoo users expect the same. Just because users are used to it doesn't make it better. How does it make it better for users that are used to what works well? It improves usability by providing additional information. Usability is not to be found in information that is subject to change. Emerging live ebuild usually is quite a risky thing, so hiding such stuff behind dropped keywords is quite reasonable. That's why you can mask them. Masking is for packages that are known to be broken, not for risks. PMS doesn't specify what exactly package.mask is for, so scm ebuilds is a perfectly valid use case, unless you can come up with an alternative that is not wrong like empty KEYWORDS. That something is not in PMS does not make it a valid use case; the Portage tree is subject to more specifications, like for example that the devmanual has a very specific paragraph on this case: CVS ebuilds must be either with empty KEYWORDS or package.masked (but not both). Empty KEYWORDS are strongly preferred. This applies to live ebuilds (-) and to ebuilds that extract a static revision but still use CVS for fetching. http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources We can also find more about empty keywords: No keyword: If a package has no keyword for a given arch, it means it is not known whether the package will work, or that insufficient testing has occurred for ~arch. http://devmanual.gentoo.org/keywording So, both quotes reveal that empty keywords fit very well; package.mask rather fits when there is a good reason to it, especially since the idea of QA is to keep package.mask maintainable by limiting its length. In doing so, QA can keep an eye on what is broken; which allows either fixing or removing ebuilds that stay there too long. In this context, a masked live ebuild would be interpreted as a live ebuild that fails to fetch, compile or run for a prolonged time; eg. due to an inactive or dead upstream, or an upstream that refuses to support that broken part. The same flawed logic of empty KEYWORDS could actually be applied to any ebuild variable. You say we can't test if it works for all these architectures reliably and for every single commit. Yeah, same goes for dependencies, license and even the description. Because it's a live ebuild, all of them can change. KEYWORDS is no special exception. KEYWORDS is a special exception because it involves arch testing. Yes, and you hide this information from the user. Information that is a given; as known, live ebuilds miss arch testing.
Re: [gentoo-dev] Removing 'selinux? ( sec-policy/selinux-*)' from DEPEND
On Fri, 29 Aug 2014 15:30:29 + Sven Vermeulen sw...@gentoo.org wrote: [...] With this change, we implement the same end result (correctly labeled files after installation) while removing the need for the DEPEND dependency. After all, this was not a build-time dependency but a merge-time one, which we abused a bit to make things work. With this change in place, we can now update the tree (at least, for those packages that do not have other SELinux related dependency requirements - those that link with libselinux still need it in DEPEND of course) to remove the USE=selinux conditional dependency from DEPEND. Given the discussion on dynamic dependencies and so, I am thinking about doing this as follows: 1. Create a tracker with separate bugs for every package where this change can be made 2. Give developers time to apply this (simple) change together with whatever other changes they were planning. 3. After 6 months or so, do the change myself (with revbump) [...] Is this a good approach to take? [...] LGTM; we should avoid unnecessary bumps rebuilds for trivial changes, especially when a USE flag based dependency line is removed from DEPEND. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: mysql-5.5 upgrade and mysql-5.1 mask news item
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 14 Aug 2014 15:58:41 -0400 Brian Evans grkni...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Title: MySQL 5.5 upgrade procedures Author: Brian Evans grkni...@gentoo.org Content-Type: text/plain Posted: 2014-08-14 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: dev-db/mysql-5.5 MySQL 5.5 is now stable across all arches. The upgrade process will be require you to rebuild everything linked to [...] ^^ This word 'be' should be removed. The other typo has already mentioned, as well as a question asked; so, apart from that the rest of the news item looks good to me. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJT7RiqAAoJEPWZc8roOL/QWD4H/jeGkrKHalQIVMw2Db51XKKd EumDXKuH9V8Ua7pp8733yl7MufvhEFd5JT+XmQvscMtxEbuYsREbk1c2SNldFSwp pCPbSjkUaVg0Mo2bnzB1aFxliTMIB2ui+lt/8gIuTK/V1Be1JGJmTrQuzf+8sVgh xVy9WSuVTi99i7m5EFaMoZ65Kyj8Xmb69gB0gZFpc9Hydn3zpGNtd9kRbYiAHy/T /xgUoj0KU5o2WZ8tElsfp/su2KHjhF2JGRSN4+rw11nD1Om+k7//IgYSkZDYrqi8 NWFGuiG8EB6sRttIhCzH6CtUlMjB2ZU8hT8aLloqmluFxmHDheuP/BbSee1EJ30= =zv9o -END PGP SIGNATURE-
Re: [gentoo-dev] Clarifying if some arch teams allows maintainers to stabilize package on arches they can test
On Sun, 27 Jul 2014 15:55:49 +0200 Pacho Ramos pa...@gentoo.org wrote: Today some user on IRC noted that there were some doubts about if developers are allowed to stabilize packages they maintain when they are able to test on relevant arches (I guess this would benefit amd64 and x86 mostly as it's likely more spread). If I don't misremember amd64 team allows that, but looks like devmanual doesn't reflect that yet: http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/ Then, I guess we would need a confirmation to fix devmanual and, in advance, know more about if there is any other arch team allowing it (x86?) Of course, developers stabilizing packages should still follow the usual test procedures as arch teams members will do. https://bugs.gentoo.org/show_bug.cgi?id=510198 -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Wed, 30 Jul 2014 13:48:37 +0200 Luis Ressel ara...@aixah.de wrote: I think I'd rather go with the original workflow. Okay, perhaps package.masking - is a bit uncommon and clutters package.mask, but it's not all *that* bad and it eases the workflow. Depends on whose workflow you are referring to; it doesn't affect the maintainer, but the clutter can be a pain if you attempt to keep the p.mask size low. Having package.mask as a directory would be a solution to this; however, there's not much other need for it to be a directory. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[OT] Re: [gentoo-dev] minimalistic emerge
On Sat, 9 Aug 2014 19:25:56 +0400 Igor lanthrus...@gmail.com wrote: In my experience - hacking into 96 system with a 0 door is much harder than in 2014. In most cases unless you're an expert on 96 software which is difficult nowadays due to human memory. Why does one need to be an expert? How about known and/or implemented exploits? To really break in you need to reproduce server environment as close as possible or/and have a clear understanding how this particular software works. Try to assemble a 96 system on modern hardware or assemble it as they were back in 96, not all sources are online any longer, that is a hard job. 2014 systems are much easier to assemble and get a peek to the sources is a trifle. Why reproduce the environment? Is the sources' availability the only factor? As Linux software is open-source it's often easier to break in Linux than in Windows systems. The open source is only theoretically safer. Many belive that because the code is open - it's reviewed and checked and the number of critical bugs is low. But the reality is that there is usually no time to review code. Many modern software is very complex with millions lines and it's not realistic to check or understand how it works before you use it in your project. Tell me how many libraries that you use right now are reviewed by you personally? Not many. And that is a door that is NEVER going to be closed. There are bugs, rest assured, if you pull any soft right now and spend time you will find them. If you have an expertise on cross platforms - you will find even more as developers used to focus on one platform the birth platform. Can you back up that open source is theoretically safer / harder / ...? It depends on how you look at the source code and binaries; having either doesn't necessarily make it easier or harder to accomplish, especially if you want to find run-time behavior to exploit. You could scan through the source code looking for known errors or so; however, the same is possible to do with the machine code. Both can be done manually or automatically; whether it gets tedious to find, depends on what it is exactly that you are trying to find and how you find it. If you compare the number of bugs you find in 1996 software and in 2014 - the numbers would approximately be the same. That reads like a wild guess due to too much assumptions / conditionals. Usually 1996 system is patched or protected against known issues and you have to deal with unknown which in case of 1996 is much harder. This also reads like a wild guess; words ending in -ly like usually indicate that you're not sure about it and how much of it really is as such, a more believable statement would read like ...% of the systems in 1996 are ... [reference to research]. Another weak link with open source is software developers. Many of them spend a lot of time on their software not always getting a fair monetary reward. So if you a very shrewd and have resources - you go to developers and offer them money to introduce a subtle bug into the main tree. After the software is adopted then you have open doors in EVERY updated linux on the planet. Personally I belive Heart Bleed bug is one of such. You can never proof if the bug is artificial or not - how? The same true for Microsoft soft. You can basically go to a ntkernel developer offer him 500 000$ if have them and he would add a bug and explain you how to use it and you're everywhere :-) but this is usually the government's methods. They used to keep them secret. Have you considered steady high incomes and the aftermath? With a steady high income and a high level job as Microsoft kernel developer, 500 000$ and the aftermath of consequences loses traction. You might be able to convince that single kernel developer; however, that developer still has to slip this by the rest of the kernel development team as well as quality assurance processes and measures. Getting by the static and dynamic analyzers as well as other run-time measures they have to their availability for awareness is harder than without it; apart from it, there's are also human code reviews and QA. The story gets somewhat different when people don't end up using them, or not spend an equivalent effort; like for example with Heart Bleed. Think about some random unrelated pieces of open source libraries; did that get run through analyzers and include run-time measures, have code reviews like kernels would have and extended QA procedures? https://i.imgflip.com/b3mx0.jpg -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] minimalistic emerge
On Fri, 8 Aug 2014 15:32:37 +0200 Jeroen Roovers j...@gentoo.org wrote: Nice capitalisation! Speaking of which, where is the US$ 1,000,000 (ONE MILLION UNITED STATES DOLLARS) you promised in your last e-mail? Nice placement of the space behind the dollar sign! No money for you. Don't bother to file bug reports if you think a fully up to date system is not for you. Where do we state to have a fully up-to-date system before filing a bug? This in particular becomes interesting to do when the bug keeps you from updating your system; or even further, rendering it non bootable. We need to fix things such that people have a working system that they can bring up-to-date; not the other way around, as that is pointless. Automatic updates is a goal to pursue; well, at least if you want everyone to have a fully up-to-date bootable system that can update. Is there any option in emerge to pull MINIMUM packages to get the result - install the application you need, leaving everything else AS IS untouched and stable? RTFM. Why do you point to a manual which does not document such feature? If no such USE flag, what about stabilize gentoo with STABILIZED flag implementation in make.conf? Next time, please bother the gentoo-user@ mailing list. No. The gentoo-user@ ML can't do anything about a missing feature. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] minimalistic emerge
On Sat, 9 Aug 2014 18:10:51 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 09 Aug 2014 11:12:46 -0400 Chris Reffett creff...@gentoo.org wrote: Then write it. Portage's source is available to anyone. It's quicker to start from scratch than to try to add things to Portage's source... But do we want to be quicker? If you want a lot of input, Portage... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] minimalistic emerge
On Fri, 08 Aug 2014 23:04:40 +0200 Johannes Huber j...@gentoo.org wrote: /me is thinking: Your caps lock key is broken and about the content: man portage || use linux from scratch Caps lock highlighting is a common practice. Why do you tell him to read a manual or use a distribution that both lack the requested feature? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings
On Mon, 11 Aug 2014 20:48:20 -0500 William Hubbs willi...@gentoo.org wrote: On Sun, Aug 10, 2014 at 03:22:11PM +0300, Sergei Trofimovich wrote: Hello World! TL;DR: This evening I plan to mangle ~3000 ebuilds in the main tree by dropping trailing '.' in all 'DESCRIPTION=' fields (except etc. case) Long story: As you may know newest portage release 2.2.11 got a minor (but chatty) QA warning: DESCRIPTION ends with a '.' character Why is this a QA warning in the first place? It isn't or shouldn't be; in the future, it would be nice if this type passes by QA / Council before being acked into the Portage tree code. Looking at the commit, the ack / commit has completely bypassed QA; we also were not involved on the related bug, thus we were unaware of it. I don't recall a policy mandating that descriptions can't end with '.'. I asked our QA lead about it and was told that he didn't recall that we have an official policy about it either. Also, the devmanual never mentions any such requirement. It has been a common belief to drop '.' among some from what I've seen. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 12 Aug 2014 10:04:58 -0400 Ian Stakenvicius a...@gentoo.org wrote: I'm wondering what everyone thinks of having a --nonag option to repoman and shoving some of the more trivial/style-related repoman 'warnings' into a 'nag' level warning? What is the point of a repoman 'warning' if it doesn't nag anymore? IIRC at least one of the QA team members is so tired of the warnings that they want to make every single one of them errors; the --nonag option would allow those warnings to remain in repoman (ie to help guide new dev's or non-dev's using repoman on their local repos) but since they don't relate to actual technical breakage they can just be turned off during QA runs, etc. For all I know the QA team tries to get rid of them where we can with the resources available; we're not necessarily tired of seeing them, but what is the point in having such repoman 'warning' if maintainers as a whole don't pursue the same goal as the QA team is trying to do here? These repoman warnings don't block commits; so, they're not problematic in terms of being able to do your workflow. There has been talk by Patrick to turn some of the warnings into errors, but that doesn't imply that the QA team or community necessarily thinks in the same way. So, I don't think that's something to worry about; especially with the increased awareness after the DESCRIPTION.punctuation happening. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJT6yY7AAoJEPWZc8roOL/Q9YcH/1uQ4yxS19X/EKb0x3RZWK5M Yk3HRJoFidD1q0mcVhqmYs8ZU+y6kppE3yHw0hpPMt3yEzym9ObB+EFl8C4841cr 3wlyY4hLNjn+hHvgiZMi3c2+OTiKZB02z7sZ/gRb5Q0oWWINZn7buWGvI0Y2iuk/ URKjn73yPsg4EisPDrfpX8NdHqSZP5MV1/EFibU0zmd97L0O/mcB/UvTOMQYegyL NEE9hLPcrU9BTl4KYsRCDhqssKu7RFsMtbuzHHrswmSMUtPtUcjeVt5EFTjYt+0k lzDEGREh9kYd87vapeUmShTZXJcK8TnwDDwh2qbNcc+M8fgOoqTbR1rmOiIjFwA= =cFld -END PGP SIGNATURE-
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Wed, 30 Jul 2014 15:38:43 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: That's what I've been trying to point out, people are seriously suggesting disabling dynamic deps for race conditions It's like fixing one audio driver in the kernel by deleting whole ALSA block It is more like fixing multiple broken audio drivers; if there is only a single problem with dynamic deps, it wouldn't receive much attention. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sun, 27 Jul 2014 05:30:26 +1000 Michael Palimaka kensing...@gentoo.org wrote: On 07/27/2014 05:21 AM, Tom Wijsman wrote: On Sun, 27 Jul 2014 03:12:07 +1000 Michael Palimaka kensing...@gentoo.org wrote: On 07/26/2014 07:59 AM, Tom Wijsman wrote: On Wed, 23 Jul 2014 22:14:41 +1000 Michael Palimaka kensing...@gentoo.org wrote: Shouldn't we strive to avoid the unnecessary rebuilds in the first place? Doing updates on your schedule only avoids the symptom, not the problem. We should strive to do both; cause less rebuilds, update less often. It is comparable to flooding on IRC channels; if you send much more messages, you are much more likely to experience a kick and/or a ban. It is easier not to flood than to convince people there is no problem with you flooding the channel; out of all the IRC channels I know of, I've only come across one where they don't mind pasted long code blocks but that's mostly because of the lack of active moderation and people. (With flooding as updating and kick/ban as rebuilds) Each person should update at a frequency that suits them. Recommending to update every $period is not a valid solution to unnecessary rebuilds. The more one floods, the more one accepts kicks and/or bans; expected. How about just not causing the problem in the first place? :-) That's the ideal, no revision bumps needed at all; though, the lack of resources doesn't make that possible. Attempts to do it stall the introduction of the ebuild; so, that's why we release and revbump it. This story goes further upstream; if they would list deps right, we wouldn't need to revbump. So; if we want to fix the cause, we would need to fix it upstream although they experience a lack of resources. TL;DR: With the water tap wide open, we'll keep mopping. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 14:25:23 + (UTC) Martin Vaeth mar...@mvath.de wrote: Tom Wijsman tom...@gentoo.org wrote: Michael Palimaka kensing...@gentoo.org wrote: What a great way to kill the distro. I can already heat my house with the number of unnecessary rebuilds Do you upgrade @world every hour and thus have it cause excessive heat? If I upgrade every X weeks they become much more cool and necessary... One of the main advantages of gentoo is the flowing upgrade, especially since this can only be very poorly emulated by a binary distro. If you really suggest that the user waits one month and then recompiles the whole installation, you give up this advantage of gentoo: The user is not up-to-date for a long time, and moreover, then needs practically a full reinstall; both are things which he wants to avoid and why perhaps he has chosen gentoo in the first place. At least, for me it is the case: if I have to reinstall all packages every months - and even have delay in security updates for a month - I will certainly switch the distribution. I guess many others think similarly. Simple equation: The more frequent the user updates, the more frequent the user will experience the minor inconveniences by upstream and distribution maintainers. Otherwise we'd be using a -only system. Dynamic deps, as well as rev bumps, alter this equation; the problem with that is that such alterations don't come free and without flaws, which is essentially where you get to reconsider how you alter it. In a similar way the user has to reconsider whether updating less is acceptable compared to compiling an occasional inconvenience. Choosing between a stable and non-stable tree is a big gap of difference in convenience, choosing how often you update is fine tuning. To get the idea: Upstream released W.X.Y.Z+1; it was only yesterday I've compiled W.X.Y.Z, turns out the difference is not so important. Agreed that this can very well be an important security update; but if you go back to the equation, that still is a minor inconvenience. PS: Not suggesting 1 month; but rather that updating not enough, or too much, can make one experience serious effects that such choices imply. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Sat, 26 Jul 2014 12:36:31 +0800 Patrick Lauer patr...@gentoo.org wrote: On Wednesday 23 July 2014 01:06:15 Tom Wijsman wrote: On Tue, 22 Jul 2014 08:10:20 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 22/07/14 04:05, Rick Zero_Chaos Farina wrote: And just for fun, since no one has mentioned it yet, dynamic deps don't work at all on binpkgs since the Packages file contains the deps (like vardb) and it doesn't get updated (just like vardb). Known long standing pitfall. It's managable. It is one of the reasons I see binpkgs as breaking progress instead of being part of the progress; it is manageable, but it could be better. So you'd rather have people not using Gentoo because you can't agilely pivot your strategy mixin? No, that's not what I've said; the paragraph you quote is based on an observation, not a statement. In that observation; if people want a mixin, they would go for a full mixin and not for a half broken mixin. Without binpkg support I'd feel the need to hack it up, just to get things fast enough. It's one of the features that haven't been made popular enough (eh, we could easily provide binpkg-updates for @system for all profiles and the most common arches (amd64, x86, maybe arm) - I've been running a cronjob doing that for x86+amd64 for about a year now) This perspective of I don't need it, thus it shouldn't exist is quite ... amusing. +1; It doesn't work, it shouldn't exist is less amusing, more ideal it should be it doesn't work, let's fix or replace it if we can... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sun, 27 Jul 2014 03:12:07 +1000 Michael Palimaka kensing...@gentoo.org wrote: On 07/26/2014 07:59 AM, Tom Wijsman wrote: On Wed, 23 Jul 2014 22:14:41 +1000 Michael Palimaka kensing...@gentoo.org wrote: On 07/23/2014 09:36 AM, Tom Wijsman wrote: On Tue, 22 Jul 2014 18:21:00 +1000 Michael Palimaka kensing...@gentoo.org wrote: What a great way to kill the distro. I can already heat my house with the number of unnecessary rebuilds Do you upgrade @world every hour and thus have it cause excessive heat? If I upgrade every X weeks they become much more cool and necessary... Shouldn't we strive to avoid the unnecessary rebuilds in the first place? Doing updates on your schedule only avoids the symptom, not the problem. We should strive to do both; cause less rebuilds, update less often. It is comparable to flooding on IRC channels; if you send much more messages, you are much more likely to experience a kick and/or a ban. It is easier not to flood than to convince people there is no problem with you flooding the channel; out of all the IRC channels I know of, I've only come across one where they don't mind pasted long code blocks but that's mostly because of the lack of active moderation and people. (With flooding as updating and kick/ban as rebuilds) Each person should update at a frequency that suits them. Recommending to update every $period is not a valid solution to unnecessary rebuilds. The more one floods, the more one accepts kicks and/or bans; expected. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Wed, 23 Jul 2014 22:14:41 +1000 Michael Palimaka kensing...@gentoo.org wrote: On 07/23/2014 09:36 AM, Tom Wijsman wrote: On Tue, 22 Jul 2014 18:21:00 +1000 Michael Palimaka kensing...@gentoo.org wrote: What a great way to kill the distro. I can already heat my house with the number of unnecessary rebuilds Do you upgrade @world every hour and thus have it cause excessive heat? If I upgrade every X weeks they become much more cool and necessary... Shouldn't we strive to avoid the unnecessary rebuilds in the first place? Doing updates on your schedule only avoids the symptom, not the problem. We should strive to do both; cause less rebuilds, update less often. It is comparable to flooding on IRC channels; if you send much more messages, you are much more likely to experience a kick and/or a ban. It is easier not to flood than to convince people there is no problem with you flooding the channel; out of all the IRC channels I know of, I've only come across one where they don't mind pasted long code blocks but that's mostly because of the lack of active moderation and people. (With flooding as updating and kick/ban as rebuilds) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Fri, 25 Jul 2014 05:44:34 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: How long have dynamic-deps been around? Since EAPI-0? Because if so, that interpretation must be incorrect, since EAPI-0 was defined as portage behavior at the time, and AFAIK, no EAPI since then has been approved without a working portage implementation. Good question, probably needs a dig in the old Portage history; it is something long the search terms of dynamic dependencies in FakeVarTree, given that the parameter[1] has been added later on. EAPI specifies what PMs need to conform to, not the other way around; EAPI-0 may very well be derived from Portage, that doesn't make such side features that have not been specified in EAPI-0 a part of EAPI-0. [1]: Add emerge --dynamic-deps y|n option. http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f8e0c75e In the context of dynamic-deps I'd interpret the above to mean within a single portage session. What happens some sessions later when an ebuild's deps are dynamic-updated after a tree sync is an entirely new session, and unless I'm missing something, the above PMS requirements can be met within a single session with dynamic-deps. Apart from the words merge and batch, which are in the piece of text that I've quoted; I'm not sure how for the rest of the piece a session can be deduced or interpreted from what is specified. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Tue, 22 Jul 2014 08:10:20 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 22/07/14 04:05, Rick Zero_Chaos Farina wrote: And just for fun, since no one has mentioned it yet, dynamic deps don't work at all on binpkgs since the Packages file contains the deps (like vardb) and it doesn't get updated (just like vardb). Known long standing pitfall. It's managable. It is one of the reasons I see binpkgs as breaking progress instead of being part of the progress; it is manageable, but it could be better. Revbump or make dynamic deps actually work (ha). If they are really as broken people claim, why is the feature enabled by default in the official package manager? Why are these discussions resounding more strongly with each occurrence? As in, why I'm not seeing a bug with title sys-apps/portage: disable dynamic deps by default https://bugs.gentoo.org/show_bug.cgi?id=516612 with a Comment #0 listing all the culprits why it should be disabled by default? They've been gathered throughout this thread; yes, they could use a summary, but that doesn't change that all the culprits exist out there. Or do people think it works well enough, so that it's pros overweight the cons? I do, and many others seem to think so as well. Depends on what the pros and cons are; it makes the difference between merely thoughts and an actual reality, to construct towards a decision. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 21:53:04 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: Actually the quizzes are pretty much clear on that. Revision must be bumped when the on-disk files installed by the ebuild are changed. Nothing about dependencies. This has been policy for a LONG time, and we're not going to change it overnight just because you protest. As suggested, later PMS features (eg. (+) / (-), ...) and PM features (eg. binpkgs, ...) can change that; so, a policy adaption or a clearly described workflow may at some point be necessary to stay actual. Now... whether dynamic deps are technically the right thing to do is another question. It merits discussion, but we need to be really sure about the consequences of any change. To deal with that one needs a clear workflow; given that it replaces an automatic feature or hack without much rebuilds, by something that needs you to decide whether or not to rev bump and cause more rebuilds. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 22:42:23 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Revision bumping for dependency change that doesn't cause the package's file content to change doesn't make sense; triggers useless rebuilds for users. A merged ebuild that misses a dependency needs an useless extra emerge. Think about the triggers instead of the extra rebuilds or extra emerges. Portage is the official package manager, and has dynamic deps enabled by default. Is it a feature or is it a hack? And it's already in ebuild-quiz.txt to ensure knowing when to, or not to, revbump: *** Ebuild technical/policy questions 1.You change a package's ebuild to install an init script. Previously, the package had no init script at all. Is a revision bump necessary? Why? What about when adding a patch? That's not about dynamic dependencies; but yes, too much rev bumps. So, -1, useless rebuilds is one of the biggest problems lately, it's an relatively new problem, people are revbumping packages for the simplest things like EAPI4-5 Useless triggers are the problem; why are the rev bumps needed, why are dependencies forgotten, ...? Sounds like a developer work flow issue... https://bugs.gentoo.org/show_bug.cgi?id=499852 -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 23:01:58 +0200 Jeroen Roovers j...@gentoo.org wrote: So you suggest we work around a bug in the PM which would be a single fix. Everywhere. Which bugs? Which fixes? Where? ... Did this thread spawn from nothing? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 17:52:51 -0500 William Hubbs willi...@gentoo.org wrote: My concern about doing a revbump just because the deps change is that the new revision has to be committed in ~arch, so we then have to hit the arch teams, which we know are overworked anyway, with stable requests just because we changed the dependencies. Isn't that causing a lot of possibly unnecessary work for our arch teams? Rev bumps that only add dependencies shouldn't need separate STABLEREQs. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 22 Jul 2014 20:50:55 +0200 Alexander Berntsen berna...@gentoo.org wrote: On 22/07/14 20:44, Kent Fredric wrote: So we'll probably need a repoman check that is smart enough to know X is modified and compare the DEPEND fields with the previous incarnation prior to commit, and then at very least, warn people doing `repoman full` that they've modified the dependencies, and that a -r1 bump is thus highly recommended. And that check can be added *now* prior to banning/disabling dynamic deps. And people who want to pay attention to that warning can start doing it before policy dictates they must. This would be a good thing to do. Would you like to try implementing it? Just a side note, this would need VCS diff support in Repoman; there are some other feature requests on b.g.o that are also pending this VCS diff support, but it takes some understanding of the Repoman code. This becomes easier to implement after the refactor of Repoman completes; checks are organized and consolidated into several files due to the refactor, rather than mixed together in a giant single file. Having repoman help with the developer workflow sounds like a neat idea. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJTzvOZAAoJEPWZc8roOL/QVcoH/0JhGPYQg5yPYDafriSIxpD+ ydS0jwCZudHiX7YZk/L5XiVLKTiwEPNLUzEmmYtkCnPXtJAZTFUYlTmn9sY9GUEh dV9Gr6gG5LpwjGDF2E9F5ivkSdUqGbx8ztqKibSAm4POy+uLm7EDEBtRJe095VVo k/kKukGSpa9hlnLB43hP9u1rs0vuwx0YB6FwK+dRVxGJAyPipgxg1jt6uRqOO9+a sBOzc910js8rpO1bkL4vGbrRViVUoFFOylWrXDxEuuyoaAWROZbItqe4xK2XagI3 wYJa/aLzGO9b3oTDQPVSEdIpgqfuJCI39BH4UrlAUZgT4GIuB8VroOx9MAOtHZc= =jVQd -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
On Tue, 22 Jul 2014 22:05:54 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Not before someone has implemented an alternative way to avoid useless rebuilding. The quality of the distribution doesn't improve by killing one of the most important features the package manager has. The quality of the distribution improves by providing an alternative with less problems. Those are apples with eggs; what you claim to be most important in itself also has problems as stated in this thread, it doesn't stop there as even beyond that it is a hack that deals with triggered problems. So, I don't think it is right to discuss replacing problems with problems. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Tue, 22 Jul 2014 23:11:37 +0200 Michał Górny mgo...@gentoo.org wrote: [citation needed]. In other words, please support such claims with evidence. Because honestly I didn't see very much people complaining about unnecessary rebuilds, except in this specific thread. But I guess they're indeed a larger issue than, for example, portage forcing wrong branches of || dependencies or other dependency calculation errors that result in people being unable to update their systems. But I don't really visit Forums often. [citation needed]. Actually, please try to go a step further and reproduce it; surprise! If you ever happen to change EAPI in a stable ebuild without revbump, please be kind enough to revoke your own commit rights. Thanks. So much revocations. Thanks. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 21:34:10 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: On Mon, 2014-07-21 at 22:56 +0200, Michał Górny wrote: Yes, it does. I'm not sure if it leads anywhere, though. Dynamic deps are a pipe dream. You can't implement them properly, so we're using half-working implementation as an excuse to be lazy. Why not adapt the updates mechanism for modifying rdepends? Perhaps something like rdepends-add foo-bar/blah-3.14 wombat? ( =dev-libs/wombat-1.0 ) This would give the package manager all the benefits of static dep resolution while allowing us to dynamically make simple changes (like adding a missing dependency to an ebuild) without forcing users to rebuild the package. Thinking this through: 1) What about rdepends-change and rdepends-del? If you only support addition; you get the same problem as with things like pkgmove, changing and/or removing it could become somewhat problematic. 2) This needs two commits every time you want to do this; one commit for the updates/, another to keep the ebuild recent for (rev)bumps. 3) It'll be a lot of fun to attempt to support this in Repoman. 4) How do we clean up these entries? Doesn't this info grow fast? 5) The first paramater: Should that point to a single ebuild? Should that support ranges? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 19:37:17 + hasufell hasuf...@gentoo.org wrote: afaiu dynamic deps are broken and not defined in PMS It goes a step further than that! The PMS imposes certain limits on dependencies; it states that DEPEND must be present before executing src_* phases, that RDEPEND must be present before treating the results as usable and that PDEPEND must be done before finishing the batch of installs. http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-750008.1 If you attempt to fit in dynamic dependencies in that specification; the src_* phases could never run, the results can never be considered usable and the batch of installs can never finish. still... people seem to fix deps without revbumping, causing users who either don't use dynamic deps (it's optional for portage through --dynamic-deps=y, although it's on by default) or who use a different PM to not get the fix, at worst resulting in broken dependency calculation Why do we have a PMS if we don't take into account other PMs? Is Gentoo still a meta distribution? How does the Portage tree portage? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 21 Jul 2014 16:41:39 -0400 Ian Stakenvicius a...@gentoo.org wrote: I wonder if there may be some form of extension we could add to portage, such that it could do a VDB-only re-emerge somehow, when the in-tree ebuild doesn't match the in-VDB one. If that could be implemented properly (and i'm not sure that it could, tbh), maybe that would help reduce issues with dynamic deps, too... Hmm, dynamic dependencies ... dynamic rebuilds ... dynamic compilation; one day we will have hot code pushes where upstream changes immediately reflects itself upon one's system. Does such a gimmick succeed? Meteor! - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJTzuAsAAoJEPWZc8roOL/QNYsH/1uJrazScukDYnGj3lsPkl7P 5l7l7caugq5CwFfJ+VLZR5byV6MePBff+rJsO6Ch8v4yM+h+IFnOn7pLS27Oqm71 LRaGHeTH/pge3jq9mm53b7ABi2IjuNSKIr69/loYMJaNgHQLZCtR/wFVxKR3XFrA dhJN7WKhHAG0+1HRlNWCdYpHllG+cmayLARlwfWGbZii/OZWh0eAVEUV0pFdZwlP WaeOcnLebn+TFWPyKEkGKkmz7yI7fFMaoKBueEAZ9PwEUmhdSK5PEeY2U/OpLOA7 7wOYDe9J1k04q5DwLzZe9LvqjwjYtGIP4sL1/b+9TCw59+akKC+DmnDv67vuTHs= =wV/h -END PGP SIGNATURE-
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Tue, 22 Jul 2014 18:21:00 +1000 Michael Palimaka kensing...@gentoo.org wrote: What a great way to kill the distro. I can already heat my house with the number of unnecessary rebuilds Do you upgrade @world every hour and thus have it cause excessive heat? If I upgrade every X weeks they become much more cool and necessary... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Tue, 22 Jul 2014 09:25:45 +0200 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: One question: why for Removal of a USE flag along with the relevant dependencies dynamic deps say revbump + unnecessary rebuild? What would happen without the revbump? Assuming dynamic dependencies don't exist, another package would still depend on the USE flag in the vdb; the only way to force that USE flag dependency to go away is with an unnecessarily rebuilding rev bump, as without it it would complain that the USE flag doesn't exist. (We're talking about RDEPEND=some/pkg[useflag] -- RDEPEND=some/pkg) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 22 Jul 2014 09:53:49 -0400
Ian Stakenvicius a...@gentoo.org wrote:
Using ${PVR} to detect how portage should update things
would be asking for trouble, imo.
This entire sub thread reads like a dynamic dependencies alternative in
disguise, the difference lies in an increase of the level of control
and in the place where this then gets reimplemented.
The increase of control comes from the maintainer being able to decide
whether the dependencies in the vdb are updated or not; however, this
gives rise to a mindset where you consider this level of control for
other variables as well (which syntax we'll [ab]use for that?) as well
as end up with more ebuilds for the sake of updating vdb dependencies.
Using an extension like -rX.Y seems odd; at the very least, I think an
incremental variable or something along that line in the ebuild would
work better. This allows for array usage like VERSION[dependencies]=1,
thus allowing other variables to be dynamic as well; you compare that
number against the one in the vdb, bingo...
Or is it just a figment?
Please think a design through and don't take a cheap shot with -rX.Y.
- --
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBAgAGBQJTzulZAAoJEPWZc8roOL/QzSMH/0wrGF+6joDtUlmUiNuTZBHB
Y0aYkr+Je7R4jj+NQxMY08j+odyImgnT+IrNrQcs7VEboXkrKS0s7ZEmQqCpNvmp
vVLvGUeAlzPgGz31aKIzMBhe5TuyCTwOvArU+DVcxDEktcbHP+sDBPTojQAr932e
qJtf6fdXDaUklu+MPlNofroREd2hjUrkS34ll6W5E+KizNMfRO7n4SAN38pkkE+C
4t3elp1I2Eei7HQT/cNUY78ab8Sgiy6N5CryN73zx6jyw9EwShLFV/8VN3M9SJ1B
jvBmD01EjsW6FLz6fvUPy2dz4GBKaC4YY0qhK5XocBwROUu2yCGV/w/es1JROB0=
=xuKt
-END PGP SIGNATURE-
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-07-20 23h59 UTC
On Mon, 21 Jul 2014 02:35:45 -0500 Dale rdalek1...@gmail.com wrote: Diamond wrote: On Mon, 21 Jul 2014 00:25:02 + Robin H. Johnson robb...@gentoo.org wrote: Removals: net-misc/curl 2014-07-15 09:29:56 blueness Is this a joke? Isn't curl as basic package as wget? Look under additions. It's there. It is probable that the wrong package was auto-completed by accident. Removals: net-misc/curl 2014-07-15 09:29:56 blueness net-libs/cyassl 2014-07-15 10:09:41 blueness Additions: net-misc/curl 2014-07-15 09:40:13 blueness -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[OT] Rock stars' inter-hindrance time after time, 'cause love is blind (was: Re: [gentoo-dev] The request to abolish games team policy)
On Sat, 12 Jul 2014 16:26:10 -0600 Denis Dupeyron calc...@gentoo.org wrote: Please do not take this personally. OK, let us try that; interesting to note though, is that this has also been stated in the OP of this thread. People seem to do care personally about this; repeatedly telling them not do, what effect does that have? I honestly wonder what all the fuss is about. Honest questions help. There are a few games I've helped with over the years and I've never had any trouble at all having my stuff reviewed and accepted. And I'm a lousy ebuild writer. Every time I'd suggest a fix, bump, or new package, and I came with an ebuild, I would get constructive criticism and I could then commit it myself. Not one single time did I get a no. Not once. We've been there; however, that's not the issue at hand, it takes a non-lousy ebuild writer to see that monopoly surrounds the core of it. Why is that? Because it only starts to matter when it starts to matter. You had a fix and it was refused? Have you ever considered you may have been doing it wrong? I understand having to have your code reviewed and accepted sounds like an insult to a rock star like you, but that's the way it is in the real world. It is still beyond my understanding that code reviews are not mandatory for anything that is committed in Gentoo. We all are rock stars, right? Rich, if I may have a suggestion, it would be that instead of meddling with projects that have been doing their best with what they have for years, and which need praise rather than hindrance, you instead start a project to get people to think positively and accept criticism. The amount of energy that was spent in this thread and many others in pure loss could have gone a long way. Hmm, we're not sure whether we're all Rich though; if I were, I would wonder if you have considered that hindrance works in both directions? We are rock stars; if rock star X hinders rock star Y, Y can hinder X. The effect of telling them to not take it personally, is that they will. This thread is pure win, it just takes some time to see good results... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: The request to abolish games team policy
On Wed, 09 Jul 2014 09:06:11 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 09/07/14 07:24, Tom Wijsman wrote: [...] confusions with newer people... Ironically; my first Portage tree action add a directory got a don't throw [expletive] into [games category] reply, before adding the ebuild. One really can't expect new people to start to address a team like that prior to addition; I've assumed for some time that contacting the teams is a necessity before addition of an ebuild, but that quickly turned out to be false for most if not all other teams. Well, I consider gnome-base/ to be [...] True, but as rich0 has written a detailed reply about is that it isn't about the categories; it's rather just that it becomes more noticeable when it is committed to such, that doesn't imply that all GNOME-ly packages in other categories are suddenly GNOME team reviewed. There's like for example an unofficial MATE display manager floating around, I think it's mdm in short; I wouldn't care if someone added it to the Portage tree, as long as it isn't given an official appearance. It's not like I'll be thoroughly reviewing it as a MATE maintainer... Hence, given I assume my ebuilds are of sufficiently high quality and therefore stable candidates, I rarely contact team leads; for those that are of worse quality, I'll contact them soon enough as I'll probably do need the help and/or review then due to lack of knowledge. That makes me think that it becomes odd when such stable candidates suddenly receive non maintainer commits or removals as I've read here. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: The request to abolish games team policy
On Wed, 09 Jul 2014 21:01:02 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 09/07/14 18:35, Vadim A. Misbakh-Soloviov wrote: В письме от Вт, 8 июля 2014 18:22:50 пользователь Samuli Suominen написал: It seems to me like people aren't making the effort of joining to the team and meeting the high quality ebuild syntax they've kept up... Samuli! With all my respect to you personally, please, don't tell anything about high quality of ebuilds syntax by the games team. Please. There are open bugs (non-ebuild bugs), sure There are sometimes wrong dependencies in old binary-only games which require special CD-ROM or other distfile, because that's when we rely upon users to report the dependencies But, the ebuild syntax is good as it's in eg. base-system, toolchain And games ebuilds are nice examples for people learning to write ebuilds So, don't know what you are referring to... The coin has two sides; while you may shine a good light on the ebuilds in the Portage tree, it may shine a bad light on those in game overlays as I think this comparison was made somewhere earlier in this thread. From what I know, people appreciate those game overlays; so, while I'm not suggesting that you do shine such light, I'd just like to ask like mva for everyone to stop making such comparisons and/or quality checks. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: The request to abolish games team policy
On Wed, 09 Jul 2014 06:55:54 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 08/07/14 19:17, Michael Palimaka wrote: On 07/09/2014 01:22 AM, Samuli Suominen wrote: And some personal thoughts about the initial proposal... I don't care about the suggestion 3. in mgorny's proposal at all, but 1. and 2. should definately stay as is. What authority does the game team have over anything? Did it get special blessing from the Council? Isn't it just another regular project as per GLEP 39? Not everything we have had since-always-standing is documented, unfortunately -- games has always been special from others Still, even if it's undocumented, it doesn't mean it doesn't exist If it would have special blessing, it would be documented in one of the Council logs and/or summaries; that is about the only way it can receive it, apart from a large scale thread showing the same wide agreement. [...] confusions with newer people... Ironically; my first Portage tree action add a directory got a don't throw [expletive] into [games category] reply, before adding the ebuild. One really can't expect new people to start to address a team like that prior to addition; I've assumed for some time that contacting the teams is a necessity before addition of an ebuild, but that quickly turned out to be false for most if not all other teams. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] new profile layout with flavors and mix-ins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 02 Jul 2014 14:41:03 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: I've talked to the funtoo devs a few times about stealing their profile idea. A few things need to be done to make this happen, mainly eselect, catalyst, and repoman support. I can do the eselect and catalyst changes myself, however, I'll require some help for the repoman support most likely. I'll prototype this locally, see what I can make work, and then see about making it usable for others to test. Did the Funtoo devs tell you that they don't run repoman because of the explosive set of possible combinations that flavors mix-ins introduce? Having it run over them should be easy; but having it run within a reasonable time when scaling up is going to be quite painful, ... It sounds like a trade-off between better profiles and better repoman. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJTteLDAAoJEPWZc8roOL/QXbIIAJpM1QZhfu51deklcxIi+6PJ 6yxNc1CA6eJfhQouGYR2QgEHUI4YASEz0invFpXbv4IM/NYY/JSX/e+EOoykqcub eN9ZIFcUOdnuP7GnG+tVOe0oMJ0jhj7yEB/+Iifz63qPlL04gMqZDYnMpz2EIrUB 2SmiFKaxWaJBv/nFoVF2ErWuNjVTMwZE8cP7Eob2HO+G2N2tLbRVMf0cJPOYHGGt 00Y+4c8EPnWvdcnHN0ei14FyTYKb+eRnvGsN5xqTnMw6oG/bGhEiHtIkdMGfrzfq UeG5cPGfxll7u8m9isA22c+lKdtnLZ9EIQtPs7Jxg09hSW3HqiNgkA5b/o/m+1A= =ROh0 -END PGP SIGNATURE-
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 15:19:59 -0400 Rich Freeman ri...@gentoo.org wrote: On Mon, Jun 30, 2014 at 3:11 PM, Tom Wijsman tom...@gentoo.org wrote: A test of a package to determine whether it appears to be working OK or whether it destructs your system isn't too much asked for; if it works it can then be ~arch tested, if it breaks you have a bug # for p.mask. If someone can't test it at all, why was it added in the first place? So that it can be tested? Maybe the maintainer doesn't have the ability to test the package (might require special hardware). Maybe the maintainer doesn't have the time to test it right away, but wants to allow others to do so (especially if others show an interest). That is an edge case; it's somewhat hard to maintain a package if you can't test it, and there are occasions (eg. Amazon EC2 related packages) where this is indeed needed. I don't see a need to introduce that masked though; but again, it depends on how edgy it is... Sure, I can set up yet another overlay, which will be empty 99% of the time. But, what is the harm in just using a mask? I've yet to leave one sitting around for years (well, not for testing at least). No problem with that if it is for a safe introduction, although I'm not quite sure how much that really invites actual testing; however it's not about that, everything that stays longer forms the problem. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] package.mask vs ~arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 30 Jun 2014 15:44:21 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/06/14 03:14 PM, Tom Wijsman wrote: Setting up an overlay for this and poking a stick at a few developers to try it out could help as an intermediary test, to ensure that you don't break every ~arch user in the progress. Better than all or nothing... Or i can just use the same stick to poke them about the p.masked version in the tree. :) All of this just means, to me, that as long as the packages indeed are actively being pursued for testing, I think it's still fine to use package.mask. However, if things aren't being actively tested (ie they've been forgotten about) then probably whomever added the mask should be pinged relentlessly about it until it's resolved one way or another. At least, I would find it perfectly acceptable to being pinged on any mask I've left rotting in the tree. +1 One could say that ensuring it is tested is part of the workflow; and then I don't mean your own testing, but inviting others to do so. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJTtEguAAoJEPWZc8roOL/QKKoIAI0KlFu28ri4KB7gAWJAQXe/ cgvNYy7Gy5kwbl9pagCSP9NhBO0VZ4LNRZIMY0OqOhv/fs9pM2+tdKOV3c/f+8mo 3PvE2zW6+U0NUDBeYDmSdRoCVuFecuZiLk9y8gciGLIipLVZ9jaIwW2N5l/jvT69 KZFLLRgoFvLeXFvg05LUbZgKlMsvpi3DJh0HWG2l0CCuGAw+vNSnFqviPyFWnVCP mhZZuYh3Xwf9/yyrWwKHFY+JjlHD2aqCd1rO9q7Ght/Wbi1knzBt4PE+kgj7xTSo 7BVTEuskcAq4yU9wvmxUYKIyGGwnjmVD5L+fK+LcVnWp4A8zwQG6bk6opiSIFN0= =R2Cc -END PGP SIGNATURE-
[OT] Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 02:04:20 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: I realize that not everybody agrees with me, but I see ~arch as a semi-stable branch - an internally consistent branch for people who don't feel like maintaining a horrific mess of keywords and masks in their /etc/portage and don't want to wait weeks/months for bugfixes to their favorite ebuilds to be marked stable by overworked arch teams, and who don't mind seeing an occasional build failure or crash as a consequence of standing closer to the bleeding edge. [[ TL;DR: This mail is a confirmation with some more side details. ]] +1. I do agree; it works well, and the occasional regression that manages to get through often isn't too bad. Maybe once in multiple years you end up with a broken boot; however, that's not a huge problem if you plan upgrades to not be in front of a deadline / presentation. In my view, experimental work not ready for general exposure should be kept in overlays and/or the main tree's package.mask, depending on how the particular project's workflow is organized. Indeed; take for example MATE, I bump the packages over a span of a few days and keep it masked until mate-base/mate. With GNOME it is similar. This is a case where I need more packages do the standard developer testing; so, I can't just have an individual package unmasked without being able to confirm that it actually works at run-time. For version bumps / new packages I just don't add them to the tree till I have confidently tested for it to not be a bug magnet, but rather a stabilization candidate; I thus don't understand such p.mask entries. At any given stability level, a system-critical library ideally ought to be better-tested than, say, a game or a media player. In practice, this sometimes doesn't happen, because some system-critical library maintainers don't care about ~arch users and dump experimental code in their laps, and in my view that's a bad thing because it encourages users to come up with ad-hoc mixed arch/~arch setups which have *never* been tested by any developer. The granted ability to make a choice brings its own limits. :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 10:12:14 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: Masked commit: * a part of a bigger version bump, i.e. one of many packages that need to update together * or something where I *know* that issues preventing normal function still exist. I.e., I want to be able to ask others for testing, but something is still missing and I'm actively working on it. This is how I like it to be; for ebuilds that are known as broken, even when that is due to them being incomplete (multiple packages). When testing packages are added as masked, they miss out on more testing; now consider that they might just work, you can miss out on smaller edge case^ bugs if a faster stabilization* must follow later. ^ The more users, the more different system environments, ... * Reverse dependency that needs it, security and so on. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 10:48:22 -0400 Rich Freeman ri...@gentoo.org wrote: On Mon, Jun 30, 2014 at 10:15 AM, Jeroen Roovers j...@gentoo.org wrote: On Mon, 30 Jun 2014 09:25:27 -0400 Rich Freeman ri...@gentoo.org wrote: Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Developers who HAVEN'T [...] TESTED AT ALL and still commit their changes to the tree should immediately hand in their toys and leave the project. What harm does it cause to commit an untested package in a masked state to the tree? Doing so violates no policy, and IMHO it shouldn't be considered a policy violation either, especially if it makes life easier on anybody who has actually volunteered to test it. should != must; that joke aside, while it's not punishable by policy (and shouldn't even be punished if it's not repeated behavior) we rather need to keep the package.mask file of a reasonable size. The goal of this file is to have an overview of what _is_ BROKEN; when you add a lot of UNSURE, its contents will diverge away from this goal. A test of a package to determine whether it appears to be working OK or whether it destructs your system isn't too much asked for; if it works it can then be ~arch tested, if it breaks you have a bug # for p.mask. If someone can't test it at all, why was it added in the first place? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] package.mask vs ~arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 30 Jun 2014 11:40:19 -0400 Ian Stakenvicius a...@gentoo.org wrote: On 30/06/14 11:36 AM, Michał Górny wrote: Dnia 2014-06-30, o godz. 11:22:07 Ian Stakenvicius a...@gentoo.org napisał(a): Here's a great example of this -- dev-libs/nss-3.16-r1 is p.masked by me for testing, because when I converted it to multilib i needed to change the way it does some internal ABI determination tests, and although I know it does work fine on multilib-amd64 and (non-multilib) x86, I am not confident without more testing that it will work for cross-compiles or other non-multilib arches. As such, it -is- in the tree, but I've masked it until I can test it myself in these circumstances or find someone else that can do it for me. But... if you unmask it, someone will test it and report whether it works :P. But... if I unmask it, -everyone- using ~arch will install it and it'll break all the systems that it doesn't work on, which -could- be quite a lot at this point. :D Setting up an overlay for this and poking a stick at a few developers to try it out could help as an intermediary test, to ensure that you don't break every ~arch user in the progress. Better than all or nothing... - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJTsbcmAAoJEPWZc8roOL/QOVMH/3PXYSKNIOnEbsuo6JbHoksZ UO7D88KNsN0Z8sbygsjM3H6Qkh6+iQSIqIhu8g6Y5OvT2bndz/qoJI3jIyO/Kjg/ no9tfiuCT61erHpQDg81LuPA2IaQnL1DbnNmsYl+j7SIMxu3R7nWLu0VmZbp1DA+ aEWn4eZX9z6IMqQWRDGmiJ7LAyJk36qFZwsvIlUJvfEJQEr0nIhJ+9UQsiNq0sPJ ytZ5VI14MXW2bY84THWxn12Svey42AEsd9ggzgHnWp04v08NWseypvI69kAyvM0z pu2G9k7QAx/ULNz9BuzZUm2vBO7D5qROy1G3EEY+GqySkqYNefOgobtY3CT/T8M= =1qIF -END PGP SIGNATURE-
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 11:32:35 -0500 William Hubbs willi...@gentoo.org wrote: As said before, ~arch users know that their systems will break sometimes, so if the package works for you, unleash it on ~arch. If someone using a configuration you don't have finds that it breaks, I'm sure it would be reported. Then you could determine whether the bug is severe enough to warrant a mask. As long as important/core/system packages don't result in a wide scale breakage on ~arch this approach should be fine; we've been doing fine before, so I don't think that this warrants a change in what we do. Just want to note that you can get an idea from previous outages (or similar events like python-exec / UPower) on how much testing is needed. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sat, 28 Jun 2014 20:46:08 -0700 Greg KH gre...@gentoo.org wrote: So, given a total lack of testing by anyone, I might as well just remove the mask, so it can actually be done given that people are wanting the latest Docker release, especially due to the security fixes in it over the one that is currently not masked... When you do this, please make sure to test the lxc USE flag to see if it actually works; because if it is _broken_, it needs to be put in a package.use.mask file instead until it is fixed up. Consider to not unmask lxc itself until you get response from hwoarang. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sun, 29 Jun 2014 09:09:36 +0100 Markos Chandras hwoar...@gentoo.org wrote: It's been a long time. To be honest I don't remember masking docker but I most likely did it because I was asked to mask =lxc-1.0.0 by the virtualization team (and Diego (flameeyes). And docker depends on lxc-1.0.0 according to the ebuild. But now that you have unmasked docker, i think the deptree will be broken since lxc is still masked. Repoman is monitored; therefore, someone from the QA team or so has probably masked Docker. Given that broken dependency tree again it is likely to happen again. So, please set it up a satisfiable state. :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sun, 29 Jun 2014 09:25:16 +0100 Markos Chandras hwoar...@gentoo.org wrote: It's been a long time and sources.g.o is down so i can't check the history of that file. $ cvsps -u -f package.mask -l '.*docker.*' -q -g ... --- gentoo-x86/profiles/package.mask:1.15773Tue Jun 10 02:03:02 2014 +++ gentoo-x86/profiles/package.mask Tue Jun 10 02:10:24 2014 @@ -1,5 +1,5 @@ -# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.15773 2014/06/10 02:03:02 floppym Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.15774 2014/06/10 02:10:24 patrick Exp $ # # When you add an entry to the top of this file, add your name, the date, and # an explanation of why something is getting masked. Please be extremely @@ -201,6 +201,7 @@ # Markos Chandras hwoar...@gentoo.org (03 May 2014) # Masked for further testing =app-emulation/lxc-1.0.0 +=app-emulation/docker-1.0.0 # Tom Wijsman tom...@gentoo.org (03 May 2014) # Needs to be further tested and revised by both Java and Ruby herds. ... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
On Sun, 15 Jun 2014 16:06:57 +0700 Vadim A. Misbakh-Soloviov m...@mva.name wrote: My idea is to allow failing for some patches without breaking build at all. And, in parallel, to add groupping. [...] Any objections/approvals/suggestions? What are the use cases of this idea? What is its goal? In my use case, I've found or written patches with a permanent purpose; therefore, I'd like the patches to apply or die hard with a purpose. I can't imagine an use case where you don't want them to apply. Temporary backported patches (eg. from version 2) come to mind; it then becomes tricky to know whether it fails because it is the new version (2), or whether it is a version (2) in between that breaks. That would become a whole new feature request with specific directory, file or header syntaxes, which takes time to implement; at which point, one wonders if just (re)moving away the patch when you see it fail in the early src_prepare phase followed by a --resume is more favorable. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] The state and future of the OpenRC project
On Tue, 10 Jun 2014 10:57:32 +0200 Thomas Kahle to...@gentoo.org wrote: I was mentored on the QA issues and have come to 'this attitude' myself. Take sci-mathematics/singular: Upstream is genuinely not interested in supporting distriutions or their petty QA unless you can prove them that there is a problem that massively hurts them. Fixing compatibility with user specified LDFLAGS? They'll laugh at you. Their attitude is a result of years and years of struggling with too little manpower themselves. They can hardly keep up with scientific developments. My personal attitude: It is just not worth the effort to rewrite their build systems for the ~10 users out there. I have better things to do with my time and I think that these packages can live forever in the overlay and that is completely OK this way. Yeah, it behaves like a trade-off in manpower; the type of QA brought up here is an enhancement, where it would be nice if someone could make the *FLAGS, CC, LD, ... supported but definitely not a requirement. This is not a reason to keep it in an overlay (or block stabilization). I think that's a different point. I've also met people who just don't want to become developers because their it's not worth my time boundary is on the other side of the quizzes. So one could say yes, contributing to overlays is convenient enough to never do quizzes. The arguments I have heard are not about bugzilla workflow. They are: I don't get that much more from being a full dev, so I don't bother taking the quizzes. Yes; becoming a full Gentoo Developer can help to go across certain restrictions, as well as can become more handy if you do work all over the place in the Portage tree. Other than that I think there is a lot you can get accomplished as an user; that is, if there is enough manpower to make those accomplishments of the users have an effect: https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs Here's a positive thing: There are many ways to contribute, even without taking lenghty quizzes :) Indeed, here is a lengthy summary that is probably not complete: https://wiki.gentoo.org/wiki/Contributing_to_Gentoo -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] The state and future of the OpenRC project
On Mon, 09 Jun 2014 21:45:26 + hasufell hasuf...@gentoo.org wrote: Probably because no one mentored them on how to fix these QA issues. Otherwise... if that's attitude, then that's just sad and has to be fixed by those who run that overlay (review, contribution guidelines). And I still think that the top 1 reason people run an overlay is because it's easier than contributing directly. A lot of overlay maintainers I tried to convince on getting more involved even said that. Even sunrise workflow has proven too slow and cumbersome... look at the commit history, it's constantly decreasing. Sure, reasons may vary, but there is not much positive to say about current gentoo workflow. We are setting up https://github.com/gentoo/proxy-maintainers to deal with some of these problems; if sunrise continues to decrease activity, I suspect this repository has a chance to become its successor. Travis integration is used to cover QA issues, see https://travis-ci.org/gentoo/proxy-maintainers which runs repoman on the overlay for each commit; therefore, QA issues don't go unnoticed. To improve the workflow further; we use app-portage/overlint to catch differences between that repository and the Portage tree, after which there is room for even much more automation; thus more time reviewing. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] The state and future of the OpenRC project
Hello developers and users The OpenRC project appears less active these days than it used to be. There are many commits per month the last years, but the amount of commits in 2014 per month has noticeably decreased to a crawl [1]. Alongside that, there appears to be around ~100 bugs open for OpenRC [2] on Gentoo Bugzilla; some of which are left without a response. This gives the impression that the development of it is slowing down. Worth noting is that WilliamH recently had problems with his system, we have since not seen him on IRC for almost a month; so, this can for a part explain the last month of inactivity. Although the other months of 2014 and even 2013 to some extent show a decreasing trend. The state and future of the OpenRC project could be of concern. Therefore this call for general awareness; such that people that are interested in this project can help, discuss measures to help the users of these bugs as well as ensure the future of the OpenRC project. Thank you in advance. [1]: Short log of proj/openrc history, decreasing commits in 2014. http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=shortlog [2]: Overview of bugs that involve OpenRC, most for the package itself. https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc Disclaimer: Just to be sure, I'm not affiliated with the OpenRC project. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Wed, 04 Jun 2014 08:44:45 +0800 Patrick Lauer patr...@gentoo.org wrote: On 06/04/2014 08:24 AM, Tom Wijsman wrote: On Wed, 04 Jun 2014 07:55:50 +0800 Patrick Lauer patr...@gentoo.org wrote: On 06/03/2014 07:25 PM, Samuli Suominen wrote: On 03/06/14 14:40, J. Roeleveld wrote: Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost No clue what you mean, sys-power/upower-pm-utils doesn't depend on sys-apps/systemd, and whole Portage tree is converted to proper dependencies and the conversion went in the correct steps. The only step missing is: Mask the new version on all non-systemd profiles so that portage doesn't try to install it (I wonder why systemd and the related stuff isn't masked on non-systemd profiles anyway ...) There is no such thing as a non-systemd profile; a sub directory is a specialization, that doesn't mean that it parents suddenly become the opposite of that. No, the parents are just generalizations that aren't as specific as the sub directory. Since systemd needs special profiles to be easy to use ... No, these systemd profiles are only introduced for GNOME and KDE ... ... it'd be the boring and easy way to restrict it to those profiles so that dependency changes don't cause this needless amount of work for users, and this indecent amount of mail on this mailinglist ..., which means that your restriction doesn't hold ... Doing what you've suggested everywhere but in gnome/systemd and kde/systemd is a recipe to upset everyone whom runs systemd on another desktop environment than GNOME or KDE; so, that's not a way forward. I have no idea what you are trying to say, but there's a desktop profile ...; because systemd users also use the desktop profiles ... Another option is to create no-systemd sub directories; but such profiles will be highly controversial, besides helping the exponential grow of the profiles directories as well as be a non-default profile. The default is already that, all I'm suggesting is masking systemd there so that portage doesn't needlessly antagonize users ..., which makes your suggestion not an option. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: news item for upower
On Wed, 04 Jun 2014 07:29:17 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 04/06/14 07:11, Samuli Suominen wrote: I'm just expecting more from our users. I don't think the news items were ever designed for simplistic things like this. As in, GLEP 42 Critical News Item != Learning tool for understanding Portage output Simplistic things don't make a lot of users ask for support, file bugs, etc...; so, it is less simple to users than what you might infer. UPower is a dependency of a lot of desktop enviroments; besides that, I still believe that the majority of users don't run systemd. This makes a blocker like this so wide scale that it at least becomes important, as it is used much more compared to the CDDA reader example. Now what makes the difference between important and critical is the potential to become disastrous; this is where it becomes harder to judge how critical it is, but at the very least it affects a large share of users now as well as in future upgrades. They appreciate news. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? They need to do an emerge -1 sys-power/upower-pm-utils to actually get the new package, But the user doesn't want systemd; so, then why does the user have to perform a manual step every time that systemd has an acquirement? otherwise portage is going to try to switch them from udev to systemd, There is the problem, the user doesn't want systemd; so, why is Portage (regardless of a systemd mask) trying to bring it to the user anyway? since packages like kdelibs list upower first, and portage has no way of knowing that this is a big change. And this is where you can make Portage smarter. http://www.funtoo.org/Flavors_and_Mix-ins We don't have to go through all this if you had a no-systemd mix-in, where you could simply make out the choices in favor of the user instead of having to document and announce them all over the place. That mix-in could do something like masking the new upower that depends on systemd; when doing so, no more blockers all over the place. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 03 Jun 2014 15:24:22 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 15:08, Tom Wijsman wrote: On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? IMHO, not every singular dependency change (even blocker) needs one. Regardless of that, most acquirements have lead to a news item. For those failing to read `eix upower` That command doesn't tell anything helpful for this blocker. or `emerge -C upower` For that you need to already know that you have to unmerge upower; it is also not going to help anything in terms of dependency calculation, except for a small amount of users that might have selected it. or masking systemd, Masking systemd has the same effect as having udev selected; so, taking this action has zero effect and results in the blocker to still be there. The output has perhaps changed a little, the idea is the same. or number of other ways the blocker can be solved, There is the problem, new Gentoo users can't solve it; that's why it's all over the place, as you've mentioned below. And some of it contains misinformation, like the gentoo-user thread you have responded to. Why do the users need to keep solving these nasty blockers? You could solve it if you use --tree --unordered-display; go through the dependency chain to check the reverse dependencies, write down what is going on and finally come to the conclusion of it all. But how are new users supposed to know all that? Why is --tree --unordered-display still not a default? In other words, why is the list of packages still flat by default? the answer is in Gentoo news letter, Hidden somewhere in the middle, assuming users read about the update. forums, As long as the activity of these topics last. first hits in Google, Nothing found when I search for things like gentoo systemd blocker. /topic of #gentoo at Freenode, MLs, pretty much everywhere. Which amounts to only a certain share of the users. But news item has been planned all along for when UPower 0.99.0 goes stable, propably GNOME 3.12 and some 0.99.0 consumers, when there are enough steps to accumulate as news worthy. Your reply doesn't answer the posed questions; instead, it demonstrates that it costs a lot more human resources the way we do things now. Users have to figure it out the hard way, developers then have to bring out the news the hard way; just like most of the previous times. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 09:04:23 -0400 Rich Freeman ri...@gentoo.org wrote: The whole point of news is to tell people about an action they need to take before they have to take it. The output of portage doesn't really tell you what is going on. Note that I'm not against a news item in the short term; what I am suggesting with mix-ins is even a step before that, but that's something only achievable in the long term and of course not now. So, yes, please write and send a news item out as soon as possible. The article in GMN doesn't provide clear instructions on what needs to be done, and refers to 0.99.0 when the issue impacts 0.9.23 as well. Besides that, a longer title would help; currently it reads to me like X update, which means that if I don't care about X or don't know X that I'm very likely to skip it. Mentioning systemd somewhere in there, as well as transition; could help with drawing attention to it. But given a news item, this GMN entry would become less important; regardless, it can help for those that manage to skip reading the item. This has already hit stable. The dependency on systemd is present in sys-power/upower-0.9.23-r3, which was just stablized. Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; in comparison, 0.99.0 mainly wants you to run it with systemd: 26 May 2014; Samuli Suominen ssuomi...@gentoo.org upower-0.99.0.ebuild: This release is mainly for use with sys-apps/systemd because upstream removed support for sys-power/pm-utils completely from git master. The 0.9 branch is for sys-power/pm-utils use. Adjust ebuild accordingly. Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency; I thought it had one, but maybe it is in another package I'm unaware of. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 03 Jun 2014 16:28:47 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 16:20, Tom Wijsman wrote: Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; No, it doesn't. Nevermind, `cvs up`-ed; heh, I don't understand how you've got to that change, I thought there only was a problem with 0.99.0? in comparison, 0.99.0 mainly wants you to run it with systemd: mainly, as in, since 0.99.0 removed support for hibenate/suspend in favour of systemd, the power/session managers need to integrate their own hibernate/suspend support diffently. Ah, right; thinking of MATE, I understand the 0.99.0 bit now. 26 May 2014; Samuli Suominen ssuomi...@gentoo.org upower-0.99.0.ebuild: This release is mainly for use with sys-apps/systemd because upstream removed support for sys-power/pm-utils completely from git master. The 0.9 branch is for sys-power/pm-utils use. Adjust ebuild accordingly. Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency; I thought it had one, but maybe it is in another package I'm unaware of. Outdated ChangeLog entry from March, those were the facts we dealt back then, only partly true anymore, consumers have evolved Which means that the situation I am assuming right now is outdated; so, if you don't mind feel free to highlight why 0.9.23-r3 needs systemd. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 09:29:59 -0400 Rich Freeman ri...@gentoo.org wrote: No use conditional there... Yeah, I was a checkout behind; I'm clueless wrt the new revision bump. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Jun 2014 09:26:09 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/06/14 08:08 AM, Tom Wijsman wrote: On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? They need to do an emerge -1 sys-power/upower-pm-utils to actually get the new package, But the user doesn't want systemd; so, then why does the user have to perform a manual step every time that systemd has an acquirement? That's easy -- we don't have a way to do vdb updates that will split a package, only move a package. And since this isn't a package move (as the original package still exists) we can't leverage that. - From the dependency viewpoint this isn't a package split or move, it is rather an introduction of || ( A B ) alternatives in the dependency chain. In this case, the first option (A) is tried and exhausted; this complexity results in other options (B) not being thoroughly considered. If you want Portage to make a transition to alternatives, you need to get a mask in place for the first option; so, we can leverage this: 1. || ( A B ) with A masked causes Portage to install B instead; 2. || ( A-0.99 B ) with =A-0.99 masked causes a downgrade to A-2. So, what misses here is that mask; which you could put in a mix-in. (In this specific case A is upower and B is upower-pm-utils.) otherwise portage is going to try to switch them from udev to systemd, There is the problem, the user doesn't want systemd; so, why is Portage (regardless of a systemd mask) trying to bring it to the user anyway? since packages like kdelibs list upower first, and portage has no way of knowing that this is a big change. And this is where you can make Portage smarter. http://www.funtoo.org/Flavors_and_Mix-ins We don't have to go through all this if you had a no-systemd mix-in, where you could simply make out the choices in favor of the user instead of having to document and announce them all over the place. That mix-in could do something like masking the new upower that depends on systemd; when doing so, no more blockers all over the place. Technically we could do this via a systemd profile too -- ie, mask new upower everywhere but systemd profiles, and in systemd profile mask upower-pm-utils. In doing so, you assume that non-systemd profiles are anti-systemd; however, that's not the case. Currently GNOME and KDE have systemd profiles; but, there are a lot of other desktop environments in the Portage tree that have support for systemd. So, this means we would have to go and create a profile for each desktop environment and within such profile yet another profile for systemd; this becomes somewhat tedious if you can cover all that in a mixin instead. You're going to need mixins at some point when it's not just systemd that is a specialization but something else as well; unless you want to create even more directories for the possible combinations: - gnome/somethingelse - gnome/systemd - gnome/systemd+somethingelse However, that doesn't get around the actual need to - --unmerge upower and emerge upower-pm-utils (or hopefully just do the latter as a soft-block will do the unmerge?) Portage does this for you if you mask upower and provide it with sufficient backtracking; so, there's no need to do this manually. More explicitly noted: An upower mask allows us to say that an upgrade should do `emerge -C upower` and `emerge upower-pm-utils`, in the case that there is || ( upower upower-pm-utils ) listed as a dependency. Unless you have selected upower on purpose; which would be a different case than the one we're discussing here, also giving different output as it'll point out that @selected brings in what (upower) has been masked. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJTjdWXAAoJEPWZc8roOL/QTwAIAJeYIYpF4JIclsGY67ZHDpuM D2rY3JlCEof4iMcPGccR+lsiTWp0inRRkR5YYejPTMupD/MUqmhuxAogLcUE79m6 lBGQOmO9G4Iduvuoesa99x7UUW6Ihx9TrmoPmn++S9Bn8FrFq+52rUkRDFrlbsrP +wyrc2Dh8SQlI7Bf2r0WcloE9xb+TVXKeyJeZs9eN0afQXqtFJraoGuPYsj7yF7f JWHq26HWRBd+EM8Gyx0OHgPW4Uc7mwhabywxfh44HcjLvh5DN+4/fXbLXc6ytBvi Z5+4UMMXNEUloovKKHT45uVCJ159njFk9KW5SQhKRihaQD63USMm+sKGm0Kx0Ek= =Sugk -END PGP SIGNATURE-
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 09:53:45 -0400 Rich Freeman ri...@gentoo.org wrote: Whatever - short of profiles/mix-ins or whatever you want to do on a big scale there isn't a simple solution to problems like this. Why is the mix-in not a simple solution? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 10:09:42 -0400 Rich Freeman ri...@gentoo.org wrote: Maybe in these cases the PM should make it more clear that there was an alternative option. Yes, Portage could also be helped out with some output improvements. It requires an analysis on its own, among the kind of collecting bad non understandable output and the solution to it; then try to make up favorable output for it. After which it has to be seen if the needed information can be obtained, as well as the algorithms for that favorable output can be implemented. Somewhere in that flow we also need to have some kind of quality review cycle to see if the favorable output helps; otherwise, it could make the situation worse instead of better. Because, really, ... http://bpaste.net/raw/Pp9Iv18ehzzHKVbm4Sbe/ ... does not give away upower as a root blocker cause; even going further than that, it doesn't suggest upower-pm-utils as an alternative. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 16:52:30 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 3 Jun 2014 17:48:05 +0200 Tom Wijsman tom...@gentoo.org wrote: On Tue, 3 Jun 2014 10:09:42 -0400 Rich Freeman ri...@gentoo.org wrote: Maybe in these cases the PM should make it more clear that there was an alternative option. Yes, Portage could also be helped out with some output improvements. That isn't the issue... Developers need to stop being clever in expressing dependencies, and start giving the package mangler explicit information about what a dependency means. Relying upon heuristics to figure out what a complicated mess of || ( ) and blockers means just leads to things intermittently going horribly wrong. Which brings me back to the mix-in suggestion, which improves input. :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
