[gentoo-dev] Re: openrc portage news item
Brian Harring posted on Fri, 29 Apr 2011 21:59:45 -0700 as excerpted: > Checking the boot levels, udev included, same thing- if ROOT=/ and > baselayout is there already you likely *could* look at the running > system to see what's needed/in use, and kick rc-update as needed for > spots where it *isn't*. Um... 32-bit chroots for amd64 comes to mind, tho that's just a single supported case of the general idea. Here, I've adapted the idea slightly by simply installing a complete system to the chroot, just never actually /running/ it from there, as a maintained system image that was initially transferred to USB, now updated thru rsync, for my netbook. Portage's ROOT is unchanged in these cases, but depending on how the detection of the running system is achieved, the script might attempt changes based on the components of the 64-bit HOST system, not the 32-bit chroot system image, or conversely, changes inappropriate for an image that never actually boots on its host system. That would *NOT* be a good thing! So any such detection would have to be based on far more than the setting for ROOT and existence of baselayout. Meanwhile, all this is a rather nice idea in theory, but with literally days left before pulling the trigger, now's rather late in the game to bring the suggestion. Development and proper testing of such a script would certainly take months, at least. This whole idea, suggested now, seems to me to be a rather advanced case of letting the perfect be the enemy of the far better but nobody claiming perfect. The time for such a suggestion would have been several months ago when the final push toward stabilization and development of the final migration technique was announced. And certainly, trying to shove the required development and testing into anything less something like six more months reasonable minimum, is folly indeed. Meanwhile, existing stable gets further and further behind and harder to maintain, and Gentoo looks more and more "legacy". Are you actually trying to delay the upgrade to OpenRC /forever/? Why? There's other questions I could ask but there ARE things worse than unasked questions. I'm seriously fighting the urge to go there as that bit of list history is something that doesn't need repeated, for sure. Meanwhile, Gentoo has always been about expecting Gentoo's users to take responsibility as their own sysadmins. Yes, we document, and automate where reasonably possible, but there's a reason for etc-update, dispatch- conf, etc. This is as good a case for letting Gentoo users take ultimate responsibility as admins on their own systems as it gets. We've waited long enough. The guides are ready. The systems are ready. The warnings are ready. Now it's time to pull that trigger. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
> sources.gentoo.org is for that. ChangeLog is for users, and "old" is > not useful information to them > > So no, I won't start cluttering up ChangeLogs and I would prefer if > others would stop it as well This makes no sense. Either you document things, and then you have to keep the documentation complete. Or you dont bother with documentation at all. I'd suggest having repoman force a changelog entry on ebuild removal. Alternatively we forget about the ChangeLogs with the git migration and move to git logs. (With a dcvs merging ChangeLogs will be a pain anyway.) But that is a different discussion. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
Samuli Suominen posted on Sat, 30 Apr 2011 08:15:55 +0300 as excerpted: > On 04/30/2011 07:45 AM, Matt Turner wrote: >> On Sat, Apr 30, 2011 at 12:39 AM, Samuli Suominen >> wrote: >>> sources.gentoo.org is for that. ChangeLog is for users, and "old" is >>> not useful information to them >> >> So it follows that users don't need to see when ebuilds were removed? >> >> > Correct. That information is not useful, except when it is (like when > last stable was removed for some reason) > > Enjoy: > > http://bugs.gentoo.org/show_bug.cgi?id=365373 I'm a user, and despite the fact that I tend to run ~arch or even pre-tree testing overlays, I find ebuild removal information in the changelog WAY more useful than, say, when some obscure arch keyworded a version. Ergo, the argument that users don't find that info useful is disproven. Users DO find it useful. I /as/ a user find it useful and get rather annoyed when I'm trying to trace a change and there's no entry at all for it in the changelog! So, please /do/ make ebuild removal entries in the changelog, as users /do/ find them useful. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
В Сбт, 30/04/2011 в 07:39 +0300, Samuli Suominen пишет: > On 04/30/2011 07:10 AM, Jeremy Olexa wrote: > sources.gentoo.org is for that. It's not convenient to use browser to read ChangeLog. > So no, I won't start cluttering up ChangeLogs and I would prefer if > others would stop it as well I'm the user and this information is useful for me. Please, stop thinking for me and start adding ChangeLog entries. If you think this clutters ChangeLog it's possible to make format more terse, but please, document all changes (but typos and comments). -- Peter.
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
В Чтв, 28/04/2011 в 18:06 +0300, Panagiotis Christopoulos пишет: > On 16:07 Thu 28 Apr, Christian Ruppert wrote: > > So once again: > > > > https://bugs.gentoo.org/docs/en/html/lifecycle.html I'm all for new lifecycle. > > CLOSED gone. VERIFIED will be added. > What is the meaning of VERIFIED? (I also never understood the meaning of > the old CLOSED). The user who had bug checked (verified) that it does not exists any more. -- Peter.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
On 04/30/2011 07:39 AM, Samuli Suominen wrote: > > sources.gentoo.org is for that. ChangeLog is for users, and "old" is > not useful information to them > > So no, I won't start cluttering up ChangeLogs and I would prefer if > others would stop it as well > Individual developers (especially QA project members) should not be ignoring policies when they feel like it. http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html If you want to try and change the policy then put it on the agenda of the next council meeting as there does not seem to be a consensus backing your opinion. Until then everyone is expected to play by the rules. Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
On 04/30/2011 10:22 AM, Andreas K. Huettel wrote: > > I'd suggest having repoman force a changelog entry on ebuild removal. > Opened yesterday: http://bugs.gentoo.org/show_bug.cgi?id=365361 Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
On 04/30/2011 11:03 AM, Petteri Räty wrote: > On 04/30/2011 07:39 AM, Samuli Suominen wrote: > >> >> sources.gentoo.org is for that. ChangeLog is for users, and "old" is >> not useful information to them >> >> So no, I won't start cluttering up ChangeLogs and I would prefer if >> others would stop it as well >> > > > Individual developers (especially QA project members) should not be > ignoring policies when they feel like it. > > http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html > > If you want to try and change the policy then put it on the agenda of > the next council meeting as there does not seem to be a consensus > backing your opinion. Until then everyone is expected to play by the rules. > > Petteri > It no where in the link you provided mentions ChangeLog is required for removals. Removing an unused ebuild is not the same as making changes to an ebuild. We have no policy for logging removals. And that's like it should be.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
On 04/30/2011 11:12 AM, Samuli Suominen wrote: > > It no where in the link you provided mentions ChangeLog is required for > removals. Removing an unused ebuild is not the same as making changes to > an ebuild. > > We have no policy for logging removals. And that's like it should be. > It doesn't explicitly mention adding new ebuilds either so that's optional too? I thought this issue would already be covered by common sense but as it doesn't seem so we can clarify the issue in the next council meeting. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
> On Sat, 30 Apr 2011, Petteri Räty wrote: > Individual developers (especially QA project members) should not be > ignoring policies when they feel like it. > http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html While I'm all for adding a ChangeLog entry when removing an ebuild, this devmanual section doesn't say anything about it. It mentions only changes to ebuilds, not removals. Ulrich
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On 04/28/2011 04:07 PM, Christian Ruppert wrote: > So once again: > > https://bugs.gentoo.org/docs/en/html/lifecycle.html > > *Every* new bug filed by a user without editbugs will have "UNCONFIRMED" > (old NEW) as fixed status. > *If* we don't enable the UNCONFIRMED status at all then it will > CONFIRMED as default but we would enable the UNCONFIRMED status. > > Bug wranglers can then assign the bug and they also *can* mark it as > CONFIRMED *if* they *can* confirm it. > The maintainer may change the status to IN_PROGRESS (old ASSIGNED) > afterwards. > > The snipped of my first mail may be a bit confusing... It just means: > NEW will become CONFIRMED, NEW has been fully replaced by CONFIRMED so > NEW is gone but CONFIRMED is *not* the new default status. CONFIRMED > would/could be the default for everybody with editbugs. > ASSIGNED gone, replacement: IN_PROGRESS, > REOPENED gone, > CLOSED gone. VERIFIED will be added. > > So I think we should convert... > I think I'll convert the workflow in about 24h if nobody really complains. There is more positive feedback anyway. -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
On 04/30/2011 11:35 AM, Ulrich Mueller wrote: >> On Sat, 30 Apr 2011, Petteri Räty wrote: > >> Individual developers (especially QA project members) should not be >> ignoring policies when they feel like it. > >> http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html > > While I'm all for adding a ChangeLog entry when removing an ebuild, > this devmanual section doesn't say anything about it. It mentions only > changes to ebuilds, not removals. > For me a removal is a change to the set of ebuilds in a package. Any way I will start a new thread for a clearer text. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Devmanual text on ChangeLogs
http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html There doesn't seem to be a common opinion on what the policy for ChangeLog entries is. See: http://archives.gentoo.org/gentoo-dev/msg_f829da2375f1ceab766a800913cc4998.xml I propose a simple new text: "Every commit should have an entry in ChangeLog." If we eventually autogenerate them from git logs this would happen any way (unless some kind of filtering system is in the middle) so we could already start now. I think it's better to have more than less information available to users. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Devmanual text on ChangeLogs
On 04/30/2011 11:46 AM, Petteri Räty wrote: > http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html > > There doesn't seem to be a common opinion on what the policy for > ChangeLog entries is. See: > > http://archives.gentoo.org/gentoo-dev/msg_f829da2375f1ceab766a800913cc4998.xml > > I propose a simple new text: "Every commit should have an entry in > ChangeLog." If we eventually autogenerate them from git logs this would > happen any way (unless some kind of filtering system is in the middle) > so we could already start now. I think it's better to have more than > less information available to users. > > Regards, > Petteri > "Every new file, and modification to existing file should have an entry in ChangeLog." to skip the proper ChangeLog-less removals.
Re: [gentoo-dev] openrc portage news item
> I don't remember the details right now, but I remember speaking with > vapier when I first started working on openrc, and he stated that he > felt we should stay away from higher eapis for system packages. > > I don't really remember his reasoning for that right now, but I remember > that is why I didn't migrate the ebuild to a higher eapi a while back. Ebuild installability on horribly outdated systems? (where portage is too old to support recent EAPIs). -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] Devmanual text on ChangeLogs
> On Sat, 30 Apr 2011, Petteri Räty wrote: > I propose a simple new text: "Every commit should have an entry in > ChangeLog." This would throw the baby out with the bath water. I won't clutter ChangeLogs with useless entries for whitespace changes or spelling fixes in comments, for example. They already account for a considerable (too large?) percentage of the portage tree [1], and we shouldn't blow them up further by adding useless information. Ulrich [1] http://blog.flameeyes.eu/2009/09/28/the-size-of-the-gentoo-tree (this is from 2009, so probably it's even worse now)
Re: [gentoo-dev] Devmanual text on ChangeLogs
El sáb, 30-04-2011 a las 11:46 +0300, Petteri Räty escribió: > http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html > > There doesn't seem to be a common opinion on what the policy for > ChangeLog entries is. See: > > http://archives.gentoo.org/gentoo-dev/msg_f829da2375f1ceab766a800913cc4998.xml > > I propose a simple new text: "Every commit should have an entry in > ChangeLog." If we eventually autogenerate them from git logs this would > happen any way (unless some kind of filtering system is in the middle) > so we could already start now. I think it's better to have more than > less information available to users. > > Regards, > Petteri > I don't have a strong opinion about what option is the one I think the best but, either way, could http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap8 be updated also with the final decision? That is the doc I periodically review to remember exact steps when cleaning old packages. Thanks a lot signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Devmanual text on ChangeLogs
On 11:07 Sat 30 Apr , Ulrich Mueller wrote: > ... > I won't clutter ChangeLogs with useless entries for whitespace changes > or spelling fixes in comments, for example. They already account for a > considerable (too large?) percentage of the portage tree [1], and we > shouldn't blow them up further by adding useless information. > ... Taking the latest portage snapshot from a mirror, the sum* of the apparent sizes of all its files (forgetting directories, filesystems. overhead etc.) is ~189Mb. The sum of ChangeLog files is ~66Mb, that is a ~35% fraction. Yes, I know this doesn't say much and I don't know the internals of the rsync protocol (someone can say that communication lines are now better, and cpu processing/disk space costs less than water/oil etc. so what are we talking about?), however it is a fact, if anyone cares. If I find a 1-year old portage snapshot I may calculate better statistics based on fixed number of ChangeLogs that existed then and now to see how they increased over the time. *doing very quick calculations -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgp1iYJRBLdbG.pgp Description: PGP signature
Re: [gentoo-dev] Re: openrc portage news item
On Sat, Apr 30, 2011 at 07:13:59AM +, Duncan wrote: > Brian Harring posted on Fri, 29 Apr 2011 21:59:45 -0700 as excerpted: > > > Checking the boot levels, udev included, same thing- if ROOT=/ and > > baselayout is there already you likely *could* look at the running > > system to see what's needed/in use, and kick rc-update as needed for > > spots where it *isn't*. > > Um... 32-bit chroots for amd64 comes to mind, tho that's just a single > supported case of the general idea. Here, I've adapted the idea slightly > by simply installing a complete system to the chroot, just never actually > /running/ it from there, as a maintained system image that was initially > transferred to USB, now updated thru rsync, for my netbook. What I'm suggesting is mangling the default configs that get pushed in via postinst to reflect the old configs for the spots where it's necessary. The 32bit/64bit scenario there still is addressable- scan the pre-existing rc-update show. If you're just chroot'ing into the sucker without kicking any services within it, you're unaffected either way if it rc-update's a couple of services- you weren't starting the services in the /first/ place after all, so no further fall out. If you were starting services, udev for example, spotting that and transferring it across isn't hard. It's actually slightly more complex than that to track the settings from setup through postinst, but that's implementation details, secondary issue to my original question. > Portage's ROOT is unchanged in these cases, but depending on how the > detection of the running system is achieved, the script might attempt > changes based on the components of the 64-bit HOST system, not the 32-bit > chroot system image, or conversely, changes inappropriate for an image > that never actually boots on its host system. That would *NOT* be a good > thing! Already outlined above how this interpretation is incorrect. It's basically identification of scenarios- your posited (presumably what you run locally since you seem fairly heated about it) scenario looks like it still would fly due to pre-existing configuration being referencable- or you weren't actually configuring it in full, nor running the services from w/in it, so it's a non issue anyways. Either way, I did not say it was necessarily simple; I'm fundamentally asking why those potentials, from the rough look of it, were ruled out. If they were considered, then it should be reasonably easy to point folks at bugs/discussions clarifying why it wasn't considered viable. 32bit chroot is one example of where it might be dicey, although frankly I still consider that deployment a bit whacked on it's own. I'm looking for more than just that however > Meanwhile, all this is a rather nice idea in theory, but with literally > days left before pulling the trigger, now's rather late in the game to > bring the suggestion. It's an arbitrary deadline. To be clear, it's an arbitrary deadline that has a horrid ass set of "do these things or your system is fubared", plus that pkg_pretend frankly is a different form of horrible beyond that. While late in the game, frankly it just came to the attention- I've ran openrc basically since day 1. It crossed the radar only recently due to the desired announcement requesting feedback- which means feedback on the change itself, fundamentally. Regardless, what you're offering up here is deflections/excuses to just do it. Which... frankly, that's fine. If that's peoples decision in full, fine, they own that decision. If the potentials weren't explored, it would be useful *knowing* so looking at reducing the pain can be done- if they *were* explored and discarded, then it saves folks the time of digging into it further. Simple enough. > Are you actually trying to delay the upgrade to OpenRC /forever/? Why? Chill the hell down. I didn't kick your puppy, nor did I steal your lunch money in 7th grade. I may have mocked your 'flock of seagulls' haircut (or 'bieber' haircut for the younguns), but they're stupid haircuts- it was deserved ;) Joke aside, I asked a valid question. Rhetorical nonsense isn't a valid response, nor useful. > Meanwhile, Gentoo has always been about expecting Gentoo's users to take > responsibility as their own sysadmins. Yes, we document, and automate > where reasonably possible, but there's a reason for etc-update, dispatch- > conf, etc. While that's a fun quotation to use, you basically just aligned with exactly why I'm asking this. Yes, users must function as the sysadmin/SA of their system. A proper SA avoids upgrade pathways were possible that require manual intervention. This requires manual intervention. Said proper SA's also have a rather large hatred of anything that can leave a system nonbootable (rant: including crappy SA's who don't verify the !@#*ing thing comes back up in a proper hot/warm state). This qualifies for that.
Re: [gentoo-dev] Re: openrc portage news item
On Sat, Apr 30, 2011 at 7:46 AM, Brian Harring wrote: > A proper SA avoids upgrade pathways were possible that require > manual intervention. This requires manual intervention. > > Said proper SA's also have a rather large hatred of anything that can > leave a system nonbootable (rant: including crappy SA's who don't > verify the !@#*ing thing comes back up in a proper hot/warm state). > This qualifies for that. This will be far from the first Gentoo upgrade which has required either manual intervention, or which leaves the system in a potentially-unbootable state. Gentoo just generally doesn't offer the level of handholding that you are asking for. Users who want that kind of experience may be better off with RHEL or another platform. I think we need a reasonable balance here. From what I've seen the openrc upgrade seems pretty straightforward. The only caveat is that you need to read the instructions before doing it. Nervous users should burn rescue discs in advance. I think the important thing is to widely announce the upgrade. The maintainers intend to do exactly this. I have complained in the past when maintainers have made disruptive changes without notice, or with notice committed at the same time as the change (which means that if your emerge --sync is in a cron job you first hear about it AFTER running emerge -au world). This isn't being done here. I'm afraid that if we set the bar as high as you're proposing, then nobody will ever get around to providing an Ubuntu-like level of polish or whatever and we'll just end up with two baselayouts for the next five years. Keep in mind that ~arch having such major differences from stable defeats some of the purpose of testing. Sure, if somebody worked hard I'm sure they could meet your level of polish in a few weeks, but unless you're personally willing to do it I'm not sure that the maintainers are going to be willing - this is a volunteer organization so when you say "do it this way or don't do it at all" you're more likely to get the latter than the former. My feeling is that the openrc upgrade fragility is in keeping with the general traditions of Gentoo - we expect Gentoo users to be reasonably willing to get their hands dirty. I'm more concerned with making sure our users are INFORMED than hand-held. And as far as "proper SAs" go - a "proper SA" always deploys changes on a production-equivalent test environment anyway. Most "proper SAs" also make backups and VM snapshots so that a borked upgrade is just a bump in the road. "Proper SAs" also run on managed hardware so that they can boot off of a rescue disc without being physically present. Most of these "Proper SAs" also run RHEL anyway. :) Rich
Re: [gentoo-dev] Devmanual text on ChangeLogs
В Сбт, 30/04/2011 в 12:02 +0300, Samuli Suominen пишет: > On 04/30/2011 11:46 AM, Petteri Räty wrote: > > I propose a simple new text: "Every commit should have an entry in > > ChangeLog." Nonfunctional commits should not be recored in ChangeLog. Personally I quite frequently add URLs of upstream bug reports in ChangeLog. I don't think this addition should be recorded in ChangeLog. > > If we eventually autogenerate them from git logs this would > > happen any way (unless some kind of filtering system is in the middle) > > so we could already start now. Without filtering system ChangeLogs are useless. Also I need some way to edit ChangeLogs manually. > "Every new file, and modification to existing file should have an entry > in ChangeLog." to skip the proper ChangeLog-less removals. Removal is quite functional change so it should be recored. -- Peter.
[gentoo-dev] Re: Devmanual text on ChangeLogs
Il giorno sab, 30/04/2011 alle 11.07 +0200, Ulrich Mueller ha scritto: > > I won't clutter ChangeLogs with useless entries for whitespace changes > or spelling fixes in comments, for example. They already account for a > considerable (too large?) percentage of the portage tree [1], and we > shouldn't blow them up further by adding useless information. If you read the last paragraph in my suggestion was to cycle the logs... -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
[gentoo-dev] Re: udev installs now to /lib/udev (was: rfc: libexec directory inconsistency)
On Sonntag, 24. April 2011, Matthias Schwarzott wrote: > Getting that discussion back on top. > > On Samstag, 22. Januar 2011, Diego Elio Pettenò wrote: > > Il giorno sab, 22/01/2011 alle 11.02 -0600, William Hubbs ha scritto: > > > Is there a reason for this? If not, would it break things if we start > > > using /libexec as well as /usr/libexec? > > > > More or less and yes, it would create one more root directory that has > > no real usage to be there anyway... > > > > > I noticed that for dhcpcd and openrc we force their LIBEXECDIR to be > > > $(get_libdir)/foo, which puts things in different directories > > > depending on whether the system is multilib or not. > > > > Which is wrong, it should be /lib/foo instead, not $(get_libdir), to > > follow what udev and other software in Linux has been using for a very > > long time now. > > Sounds like we should fix udev ebuild and some ebuilds installing udev > rules to not use /$(get_libdir)/udev, but plain /lib/udev. > > I used that in believe that /lib is identical or links to /$(get_libdir) > and multilib-strict requires it, but it seems to be intelligent enough to > only deny 64-bit libs to go to /lib. > > So proper udev should use /lib/udev, correct? > sys-fs/udev-168 does now install to /lib/udev unconditionally. Regards Matthias
Re: [gentoo-dev] openrc portage news item
On 2011.04.30 01:34, William Hubbs wrote: [snip] > > Also, this patch doesn't stop baselayout-2 from being installed, so I > do > not know what state it would leave a system in if you ran this and > happened to upgrade baselayout, then reboot without installing > openrc. > > William > > William, I've been there and done that. My firewall was blocking git as I thought I had no use for it, so I got baselayout2 but not openrc. openrc was only available from git in 2007 I was late, so I just switched off and went to bed. I had to back out baselayout2 and do it again. Its was fairly easy for me as I keep binpackages of everything I build. It still needed a liveCD boot. -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees pgpM8hqxKcRS8.pgp Description: PGP signature
Re: [gentoo-dev] Re: openrc portage news item
On Sat, Apr 30, 2011 at 08:03:43AM -0400, Rich Freeman wrote: Frankly getting fairly annoyed people are immediately taking it to the rhel/ubuntu extremes- that is *not* what I asked and is frankly a strawman argument. Occasional pain on upgrades is a given in gentoo, although anyone claiming we've not kept an eye on those sharp corners is delusional (versioned eapi, etc-update's very existance, portage warning on removal of a pkg in the system set, the list goes on). Hell, even the notification mechanism y'all want to use for informing is an example of trying to soften those corners were possible, rather than precluding their existance. I asked if we had looked at scripting away some of the upgrade pains. It's a pretty simple fucking question requiring either a 5 second "no" or 5 minutes of "yes, heres what we looked at, they were deemed too painful". Answering that also is a helluva lot quicker then people trading barbs over "we need to release it now" or proper SA; while your retort was dead on for what folks should do, it was completely unrelated to answering the question I'm *asking*. If we didn't look into it, that's fine. Means I've got something to poke at over the weekend. If we did, and it was ruled out, awesome, I have other things on my todo list I'll poke at this weekend. ~harring pgpABmwbRwHHD.pgp Description: PGP signature
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On 14:28 Sat 30 Apr , Diego Elio Pettenò wrote: > If you read the last paragraph in my suggestion was to cycle the logs... Maybe this would be better together with a mechanism (automatic?) to keep the complete ChangeLogs (as they are now) somewhere (but not in the main tree). Sometimes, full history/ChangeLog can be useful, eg. when you want to see quickly how old a package in the tree is, or find bug numbers of fixes you may want to recheck etc etc. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgp07fj0BJKHE.pgp Description: PGP signature
Re: [gentoo-dev] Re: openrc portage news item
On 04/30/2011 07:58 AM, Brian Harring wrote: On Sat, Apr 30, 2011 at 08:03:43AM -0400, Rich Freeman wrote: Frankly getting fairly annoyed people are immediately taking it to the rhel/ubuntu extremes- that is *not* what I asked and is frankly a strawman argument. Occasional pain on upgrades is a given in gentoo, although anyone claiming we've not kept an eye on those sharp corners is delusional (versioned eapi, etc-update's very existance, portage warning on removal of a pkg in the system set, the list goes on). Hell, even the notification mechanism y'all want to use for informing is an example of trying to soften those corners were possible, rather than precluding their existance. I asked if we had looked at scripting away some of the upgrade pains. This openrc upgrade is the *least* painful Gentoo upgrade I have experienced. What a waste of time (IMO) to "script" some defaults. -Jeremy It's a pretty simple fucking question requiring either a 5 second "no" or 5 minutes of "yes, heres what we looked at, they were deemed too painful". Answering that also is a helluva lot quicker then people trading barbs over "we need to release it now" or proper SA; while your retort was dead on for what folks should do, it was completely unrelated to answering the question I'm *asking*. If we didn't look into it, that's fine. Means I've got something to poke at over the weekend. If we did, and it was ruled out, awesome, I have other things on my todo list I'll poke at this weekend. ~harring
Re: [gentoo-dev] Re: openrc portage news item
On Sat, Apr 30, 2011 at 08:06:37AM -0500, Jeremy Olexa wrote: > This openrc upgrade is the *least* painful Gentoo upgrade I have > experienced. What a waste of time (IMO) to "script" some defaults. Basically answering my question- it wasn't considered since it ain't worth the time. Danke- consider it dropped. ~harring pgphnFvXUK6v9.pgp Description: PGP signature
Re: [gentoo-dev] Devmanual text on ChangeLogs
On Sat, Apr 30, 2011 at 12:02:35PM +0300, Samuli Suominen wrote: > On 04/30/2011 11:46 AM, Petteri Räty wrote: > > http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html > > > > There doesn't seem to be a common opinion on what the policy for > > ChangeLog entries is. See: > > > > http://archives.gentoo.org/gentoo-dev/msg_f829da2375f1ceab766a800913cc4998.xml > > > > I propose a simple new text: "Every commit should have an entry in > > ChangeLog." If we eventually autogenerate them from git logs this would > > happen any way (unless some kind of filtering system is in the middle) > > so we could already start now. I think it's better to have more than > > less information available to users. > > > > Regards, > > Petteri > > > > "Every new file, and modification to existing file should have an entry > in ChangeLog." to skip the proper ChangeLog-less removals. > I am actually with Samuli on this. Unless there is a particular reason for removing a package, I don't see any point of documenting this change anywhere. What difference would it make to you if you see an entry " -foo-1.0 old". It makes absolutely no sense. Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgpgrTEJFbVK2.pgp Description: PGP signature
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On 4/30/11 3:05 PM, Panagiotis Christopoulos wrote: > On 14:28 Sat 30 Apr , Diego Elio Pettenò wrote: >> If you read the last paragraph in my suggestion was to cycle the logs... > Maybe this would be better together with a mechanism (automatic?) to keep the > complete ChangeLogs (as they are now) somewhere (but not in the main > tree). Sometimes, full history/ChangeLog can be useful, eg. when you > want to see quickly how old a package in the tree is, or find bug numbers of > fixes you may want to recheck etc etc. Seconded. I sometimes read entire ChangeLogs, for example for abandoned packages or packages I suspect to be abandoned, sometimes I read them for fun, and so on. I'm fine with shipping a trimmed down versions to users, but I think the full version must be easy to access. A possible solution would be to truncate the logs in the cvs->rsync migration. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On Sat, Apr 30, 2011 at 9:44 AM, "Paweł Hajdan, Jr." wrote: > I'm fine with shipping a trimmed down versions to users, but I think the > full version must be easy to access. If the changelogs were accessible via a predicable URL then a simple command-line tool or portage option might display them on request. echangeinfo cat/pkg is probably no harder for the average end-user to type than less /usr/portage/cat/pkg/ChangeLog. Rich
Re: [gentoo-dev] Devmanual text on ChangeLogs
On Sat, Apr 30, 2011 at 02:42:08PM +0100, Markos Chandras wrote: > I am actually with Samuli on this. Unless there is a particular reason > for removing a package, I don't see any point of documenting this change > anywhere. > What difference would it make to you if you see an entry " -foo-1.0 > old". It makes absolutely no sense. Removing versions has implications for the depgraph which make having it documented locally fairly required. Broken dependencies is the usual example, (consider developmental profiles), but it gets nastier than that; consider a pkg depping on || ( =foo-1.0 !block-some-other-crap ) Yes that's a screwed up dep, but people come up with some weird stuff- the point either way is that removal of 1.0 can have implications beyond just the perceived cleanup. Usage of --force in conjunction with it makes it worse. Not opposed to pruning the logs (every few years we seem to go cleanup the offenders), but removals *matter* for the depgraph, thus have been required to be documented long term. ~harrng pgpxUiuOn97nG.pgp Description: PGP signature
[gentoo-dev] Proposal: include dbus session handling in baselayout (or somewhere, in which case where?)
Hi all This is something like net-misc/keychain is for key management. My main use case so far is to do with gnome-keyring-daemon for Subversion. If you want to have a password-locked keyring, you will have to unlock it every time you have a new dbus instance, which can pretty much happen every time you open a new shell in tmux or whatnot since Subversion needs dbus to communicate with keyring. /etc/profile.d/dbus-session.sh attached, looking for feedback about problems with it and if the whole approach even makes sense. I might be not knowing something important. -- Leho Kraav, M.Sc. dbus-session.sh Description: application/shellscript
[gentoo-dev] No more old-style virtuals
With the conversion of linux-sources to a new-style virtual today, all old-style virtuals are gone from the portage tree. See GLEP 37 and bug 350792 for details. Thanks to everyone who has helped with conversion or cleanup. I hope that I didn't step on too many toes for the conversions I did myself. I suggest that a warning for PROVIDE should be added to repoman, mainly to prevent unintentional readdition of old-style virtuals when ebuilds are copied from an overlay to the main tree. Ulrich
Re: [gentoo-dev] Devmanual text on ChangeLogs
On Sat, Apr 30, 2011 at 02:42:08PM +0100, Markos Chandras wrote: > On Sat, Apr 30, 2011 at 12:02:35PM +0300, Samuli Suominen wrote: > > On 04/30/2011 11:46 AM, Petteri Räty wrote: > > > http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html > > > > > > There doesn't seem to be a common opinion on what the policy for > > > ChangeLog entries is. See: > > > > > > http://archives.gentoo.org/gentoo-dev/msg_f829da2375f1ceab766a800913cc4998.xml > > > > > > I propose a simple new text: "Every commit should have an entry in > > > ChangeLog." If we eventually autogenerate them from git logs this would > > > happen any way (unless some kind of filtering system is in the middle) > > > so we could already start now. I think it's better to have more than > > > less information available to users. > > > > > > Regards, > > > Petteri > > > > > > > "Every new file, and modification to existing file should have an entry > > in ChangeLog." to skip the proper ChangeLog-less removals. > > > I am actually with Samuli on this. Unless there is a particular reason > for removing a package, I don't see any point of documenting this change > anywhere. > What difference would it make to you if you see an entry " -foo-1.0 > old". It makes absolutely no sense. There are times when you need to know where a version went. That alone is enough to warrant updating the ChangeLog. Having to check a second place through a slow interface sucks :) -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgpDC2ZAOXxKN.pgp Description: PGP signature
[gentoo-dev] Use of use.mask
Hi all, I was thinking of adding SVN snapshot ebuilds of PHP to the tree. Ebuilds for PHP extensions use USE_EXPAND to decide which slots (and thus, which ABIs) of PHP the extension should be built for, much like ruby does. A new USE_EXPAND USE flag should therefore be added for the SVN snapshot slot. The problem is that the ABI is not stable and should only be used by people who 'know what they are doing', and the snapshot ebuilds will probably always be without keywords. This will cause some dependency problems. The only solution I could think of would be to add this new USE flag to use.mask. But as far as I could tell, use.mask is meant for masking USE flags that do not work on certain architectures etc. It is also a bit tricky for users to unmask USE flags. Is this still the best way to do this? Or are there any better ways that I did not think of? Cheers, Ole Markus signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Use of use.mask
On 04/30/2011 02:47 PM, Ole Markus With wrote: > Hi all, > > I was thinking of adding SVN snapshot ebuilds of PHP to the tree. > Ebuilds for PHP extensions use USE_EXPAND to decide which slots (and > thus, which ABIs) of PHP the extension should be built for, much like > ruby does. A new USE_EXPAND USE flag should therefore be added for the > SVN snapshot slot. The problem is that the ABI is not stable and should > only be used by people who 'know what they are doing', and the snapshot > ebuilds will probably always be without keywords. This will cause some > dependency problems. > > The only solution I could think of would be to add this new USE flag to > use.mask. But as far as I could tell, use.mask is meant for masking USE > flags that do not work on certain architectures etc. It is also a bit > tricky for users to unmask USE flags. > > Is this still the best way to do this? Or are there any better ways that > I did not think of? > > Cheers, > Ole Markus > I don't see that this is much different in philosophy than p.masking experimental/broken ebuilds which we add to the tree for dev only testing. In both cases a user who thinks they 'know what they're doing' can locally unmask, at their own risk. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] Devmanual text on ChangeLogs
On 12:02 Sat 30 Apr , Samuli Suominen wrote: > > "Every new file, and modification to existing file should have an entry > in ChangeLog." to skip the proper ChangeLog-less removals. There is something I can't undestand reading all the previous discussions. You disagree with logging removals only because you don't like the idea (you think it's useless information) or also because if this becomes a policy, it will increase more the size of ChangeLogs? You (and others) would still be negative if the problem with sizes etc. was solved somehow? -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgp4Yd511drK4.pgp Description: PGP signature
Re: [gentoo-dev] Review for initial systemd.eclass
Here's the second version. Changes: - switched to /lib (like upstream and udev now does), - polished docs and added an example of use, - added systemd_to_myeconfargs() to allow clean argument appending with preservation of whitespace. -- Best regards, Michał Górny systemd.eclass Description: Binary data signature.asc Description: PGP signature
Re: [gentoo-dev] python-namespaces.eclass
2011-04-04 13:48:43 Brian Harring napisał(a): > > # @ECLASS: python-namespaces.eclass > > # @MAINTAINER: > > # Gentoo Python Project > > # @BLURB: Eclass for packages installing Python namespaces > > # @DESCRIPTION: > > # The python-namespaces eclass defines phase functions for packages > > installing Python namespaces. > > ^^^ This isn't a useful description. IMHO it's sufficient, but could you suggest some sentences of description? -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] python-namespaces.eclass
On Sat, Apr 30, 2011 at 11:27:47PM +0200, Arfrever Frehtes Taifersar Arahesis wrote: > 2011-04-04 13:48:43 Brian Harring napisał(a): > > > # @ECLASS: python-namespaces.eclass > > > # @MAINTAINER: > > > # Gentoo Python Project > > > # @BLURB: Eclass for packages installing Python namespaces > > > # @DESCRIPTION: > > > # The python-namespaces eclass defines phase functions for packages > > > installing Python namespaces. > > > > ^^^ This isn't a useful description. > > IMHO it's sufficient, but could you suggest some sentences of description? It probably is sufficient for *you*- you're knee deep in the guts of python, and know it's purpose. Plus you wrote the eclass ;) The purpose of the description, and general code comments is for *other* folk who may be looking at that code/problem for the first time. It needs to be written aimed at them. I'd suggest doing a grep of DESCRIPTION w/in eclasses and working from the clearer examples- just looking at the first few examples returned, alternatives for example has enough in the opening description to understand exactly what it's for, same for apache-2. One thing to keep in mind is that even for folk who know python, this is actually an area that doesn't match the normal verbage, and is a bit niche in it's usage- try googling 'python namespaces' sometime, note that it's scope discussions rather than pkgutil/distribute importation across multiple directories. To be clear, 'python namespaces' is a whole other thing from what this is doing- this is manipulation of importation pathways (the module/import hierarchy/namespace, rather than the common scope terminology). Either way, rough suggestion: """ This eclass handles installation/creation of python 2.7 and higher pkgutil namespaces, and the equivalent distibute functionality. See zope's (example ebuild) for examples of usage. """ Rewording it might be wise, but that lays out exactly what this is for, it's intended usage, and gives folks a pointer were to look for usage examples. ~brian pgp5hKpiCAPC2.pgp Description: PGP signature
Re: [gentoo-dev] python-namespaces.eclass
2011-05-01 00:32:13 Brian Harring napisał(a): > On Sat, Apr 30, 2011 at 11:27:47PM +0200, Arfrever Frehtes Taifersar Arahesis > wrote: > > 2011-04-04 13:48:43 Brian Harring napisał(a): > > > > # @ECLASS: python-namespaces.eclass > > > > # @MAINTAINER: > > > > # Gentoo Python Project > > > > # @BLURB: Eclass for packages installing Python namespaces > > > > # @DESCRIPTION: > > > > # The python-namespaces eclass defines phase functions for packages > > > > installing Python namespaces. > > > > > > ^^^ This isn't a useful description. > > > > IMHO it's sufficient, but could you suggest some sentences of description? > > It probably is sufficient for *you*- you're knee deep in the guts of > python, and know it's purpose. Plus you wrote the eclass ;) > > The purpose of the description, and general code comments is for > *other* folk who may be looking at that code/problem for the first > time. It needs to be written aimed at them. > > I'd suggest doing a grep of DESCRIPTION w/in eclasses and working from > the clearer examples- just looking at the first few examples returned, > alternatives for example has enough in the opening description to > understand exactly what it's for, same for apache-2. > > One thing to keep in mind is that even for folk who know python, this > is actually an area that doesn't match the normal verbage, and is a > bit niche in it's usage- try googling 'python namespaces' sometime, > note that it's scope discussions rather than pkgutil/distribute > importation across multiple directories. > > To be clear, 'python namespaces' is a whole other thing from what this > is doing- this is manipulation of importation pathways (the > module/import hierarchy/namespace, rather than the common scope > terminology). > > Either way, rough suggestion: > """ > This eclass handles installation/creation of python 2.7 and higher __init__.py files generated by this eclass work with Python 2.4. (I haven't tested them with older versions.) > pkgutil namespaces, and the equivalent distibute functionality. See > zope's (example ebuild) for examples of usage. > """ -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
Duncan wrote: I'm a user, and despite the fact that I tend to run ~arch or even pre-tree testing overlays, I find ebuild removal information in the changelog WAY more useful than, say, when some obscure arch keyworded a version. Ergo, the argument that users don't find that info useful is disproven. Users DO find it useful. I /as/ a user find it useful and get rather annoyed when I'm trying to trace a change and there's no entry at all for it in the changelog! So, please /do/ make ebuild removal entries in the changelog, as users /do/ find them useful. =:^) I'm a user, tho a lowly one, and even I look in the changelogs from time to time. I don't even see why this should be discussed. If you *change* something, but it in the *change* log. If not, maybe the changelog should be called something else. Using the logic that something being removed is not a change, then adding something is a change either. Adding something is important and I think something being removed is important too. Dale :-) :-)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
Dale wrote: I'm a user, tho a lowly one, and even I look in the changelogs from time to time. I don't even see why this should be discussed. If you *change* something, but it in the *change* log. If not, maybe the changelog should be called something else. Using the logic that something being removed is not a change, then adding something is a change either. Adding something is important and I think something being removed is important too. Dale I'm a user, tho a lowly one, and even I look in the changelogs from time to time. I don't even see why this should be discussed. If you *change* something, put it in the *change* log. If not, maybe the changelog should be called something else. Using the logic that something being removed is not a change, then adding something is not a change either. Adding something is important and I think something being removed is important too. Dale :-) :-) P. S. Corrected some bad typos. lol I need new glasses and better fingers.
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On Thursday 28 of April 2011 16:07:24 Christian Ruppert wrote: > So once again: > > https://bugs.gentoo.org/docs/en/html/lifecycle.html > > *Every* new bug filed by a user without editbugs will have "UNCONFIRMED" > (old NEW) as fixed status. > *If* we don't enable the UNCONFIRMED status at all then it will > CONFIRMED as default but we would enable the UNCONFIRMED status. > > Bug wranglers can then assign the bug and they also *can* mark it as > CONFIRMED *if* they *can* confirm it. > The maintainer may change the status to IN_PROGRESS (old ASSIGNED) > afterwards. > > The snipped of my first mail may be a bit confusing... It just means: > NEW will become CONFIRMED, NEW has been fully replaced by CONFIRMED so > NEW is gone but CONFIRMED is *not* the new default status. CONFIRMED > would/could be the default for everybody with editbugs. > ASSIGNED gone, replacement: IN_PROGRESS, > REOPENED gone, +1 (with comment, see below) It makes a lot more sense (and it's free from enterprisey meaning wrt ASSIGNED and such) I'd leave the default resolution status for newly created bug as UNCONFIRMED also for editbugs-accounts. It's not that it cannot be changed to CONFIRMED in 'new bug' extended form. > CLOSED gone. VERIFIED will be added. I have a little worry thought (that may have been addressed somewhere in this thread) - why is VERIFIED being added? To me it's not needed at all and there are people who seem to have the same opinion: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg39023.html -- regards MM signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2
> On Fri, 29 Apr 2011, Michał Górny wrote: >> Among the options I see is the following: >> >> A) Find out how to render g-metal.blend with recent Blender >> (2.57b at best) to give pixel-identical results to Blender 2.04. >> Needs an advanced Blender user ideally. >> >> B) Port Blender 2.26 to a recent version of Python. >> >> Are there any other options? Could you bisect Blender to find out why it doesn't work with the new version? > Maybe it's time to make the SVG variant the official logo, and leave > the blender file as a historical variant. The Blender variant looks better though, especially at high resolutions. Ulrich
Re: [gentoo-dev] Re: [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2
On Sun, 1 May 2011 06:10:02 +0200 Ulrich Mueller wrote: > > Maybe it's time to make the SVG variant the official logo, and leave > > the blender file as a historical variant. > > The Blender variant looks better though, especially at high > resolutions. Isn't it possible to create a better SVG then? I think such a variant would be much more portable and reproducible than blender files. -- Best regards, Michał Górny signature.asc Description: PGP signature
