Re: [gentoo-dev] borked release media
On Sat, Dec 8, 2012 at 12:25 AM, Matt Turner matts...@gentoo.org wrote: I have never once been able to grab a portage snapshot and build a stage 1, 2, 3 series from it without encountering at least a couple of problems with the tree. Ditto - the latest issue I've run into is: 443472. Probably won't impact the average user, and perhaps I should just modify the script to not bother reading that file and figure out what the latest build is on its own. I think we should consider things that break release media serious regressions. I don't know what that entails specifically, but whether it need be QA bashing down your door or a quick fix or revert, it sure would be nice to get Gentoo to a place where release media always works. Agreed. If a user can't just burn a CD and then do an emerge kde-meta there is a problem. In short, I think the conversation we should be having should be about how to avoid breaking release builds and how to quickly fix problems when they're discovered. I think those working with catalyst have the most to add regarding what breaks them. As far as detect-ability goes, do we need some kind of tinderbox that just does a daily build. Perhaps just build from stage3 to a couple of world targets, including one with some server-oriented software, one with gnome, and one with kde? I've reported a bunch of bugs with the EC2 bootstrap script described on my blog (not my original work), but it is only automated from a build perspective - testing is manual. That takes about 18 hours to build (with an emphasis on economy), and I use spot instances so it really only costs maybe a buck or two. My experience has been that if it builds it usually works. So, simply testing for whether the build completes is a pretty-good first step. Of course, for system packages our recourse isn't necessarily good, since we don't have a test branch or anything like that. If we wanted to revert we'd have to impact users who already upgraded. Obviously the goal would be to fix in place with a new revbump, assuming that were possible. Rich
[gentoo-dev] [RFC] Global USE=systemd
A growing number of packages use USE=systemd in a semi-controlled way. Therefore, I suggest establishing a global flag described as: systemd - Enable use of systemd-specific libraries and services like socket activation or session tracking $ quse -D systemd local:systemd:app-admin/openrc-settingsd: Use the versions of dbus and polkit files provided by sys-apps/systemd local:systemd:app-emulation/qemu-guest-agent: Install SystemD init script instead of OpenRC local:systemd:gnome-base/gdm: Use sys-apps/systemd for session tracking local:systemd:gnome-base/gnome-control-center: Use sys-apps/systemd instead of sys-auth/consolekit for session tracking local:systemd:gnome-base/gnome-session: Use sys-apps/systemd instead of sys-auth/consolekit for session tracking local:systemd:gnome-base/gnome-settings-daemon: Use sys-apps/systemd instead of sys-auth/consolekit for session tracking local:systemd:gnome-base/gnome-shell: Use sys-apps/systemd instead of sys-auth/consolekit for session tracking local:systemd:gnome-base/gvfs: Use sys-apps/systemd seat information for tracking owners of removable volumes local:systemd:gnome-extra/gnome-packagekit: Use sys-apps/systemd instead of sys-auth/consolekit for rebooting local:systemd:gnome-extra/gnome-screensaver: Support sys-apps/systemd's logind local:systemd:gnome-extra/gnome-system-monitor: Display sys-apps/systemd metadata, e.g. unit names, for running processes local:systemd:media-sound/mpd: Enable support for systemd socket activation local:systemd:media-sound/pulseaudio: Build with sys-apps/systemd support to replace standalone ConsoleKit. local:systemd:net-misc/networkmanager: Use sys-apps/systemd instead of sys-auth/consolekit for session tracking local:systemd:net-print/cups: Add support for systemd socket activation. local:systemd:sys-apps/accountsservice: Use sys-apps/systemd instead of sys-auth/consolekit for session tracking local:systemd:sys-apps/busybox: Support systemd local:systemd:sys-apps/dbus: Build with sys-apps/systemd at_console support local:systemd:sys-apps/udevil: Support for sys-apps/systemd local:systemd:sys-auth/pambase: Use pam_systemd module to register user sessions in the systemd control group hierarchy. local:systemd:sys-auth/polkit: Use sys-apps/systemd instead of sys-auth/consolekit for session tracking local:systemd:sys-fs/udisks: Support sys-apps/systemd's logind local:systemd:sys-power/upower: Use sys-apps/systemd for hibernate and suspend -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Global USE=systemd
Does it really have to be useflag? Can't we simply just install the file every time like we do with everything else? Logrotate/normal initscripts/etc/etc. There should be no issue with that if we install the service files every time, they just take few kbs in /etc/
Re: [gentoo-dev] [RFC] Global USE=systemd
On Sat, Dec 8, 2012 at 8:53 AM, Tomáš Chvátal tomas.chva...@gmail.com wrote: Does it really have to be useflag? Can't we simply just install the file every time like we do with everything else? Logrotate/normal initscripts/etc/etc. There should be no issue with that if we install the service files every time, they just take few kbs in /etc/ For unit files I'd tend to agree. However, these did not control the installation of unit files (unless I missed something in there). Many controlled whether the package used consolekit vs systemd, so unless somebody defines a common API between them and a virtual a USE flag makes sense. I'm not as certain about the socket file use case. If the use flag is triggering both the installation of a socket file and also the disabling of something else it might be necessary. On the other hand, if it is just toggling between installing the socket file for systemd vs under xinetd.d then it might be safe to just install both since I doubt systemd users are likely to also run xinetd. That might not be a safe assumption - during the transition they might end up running both.
Re: [gentoo-dev] [RFC] Global USE=systemd
On Sat, 8 Dec 2012 14:53:02 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: Does it really have to be useflag? Can't we simply just install the file every time like we do with everything else? Logrotate/normal initscripts/etc/etc. There should be no issue with that if we install the service files every time, they just take few kbs in /etc/ It's not about unit files. For those, I tend to kill people for putting them behind a flag. This is mostly about: a) using logind instead of consolekit, b) linking programs against systemd libraries (hard dep on systemd). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] borked release media
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/08/2012 06:50 AM, Rich Freeman wrote: On Sat, Dec 8, 2012 at 12:25 AM, Matt Turner matts...@gentoo.org wrote: I have never once been able to grab a portage snapshot and build a stage 1, 2, 3 series from it without encountering at least a couple of problems with the tree. Ditto - the latest issue I've run into is: 443472. Probably won't impact the average user, and perhaps I should just modify the script to not bother reading that file and figure out what the latest build is on its own. I think we should consider things that break release media serious regressions. I don't know what that entails specifically, but whether it need be QA bashing down your door or a quick fix or revert, it sure would be nice to get Gentoo to a place where release media always works. Agreed. If a user can't just burn a CD and then do an emerge kde-meta there is a problem. In short, I think the conversation we should be having should be about how to avoid breaking release builds and how to quickly fix problems when they're discovered. I think those working with catalyst have the most to add regarding what breaks them. As far as detect-ability goes, do we need some kind of tinderbox that just does a daily build. Perhaps just build from stage3 to a couple of world targets, including one with some server-oriented software, one with gnome, and one with kde? I've reported a bunch of bugs with the EC2 bootstrap script described on my blog (not my original work), but it is only automated from a build perspective - testing is manual. That takes about 18 hours to build (with an emphasis on economy), and I use spot instances so it really only costs maybe a buck or two. I build about ~1300 packages for amd64 and x86 nearly every day from a fresh snapshot. I'm working on automating it so it really is every day. Once it is automated I suppose I can add kde-meta to the list, even though... well... it's kde. - -Zero My experience has been that if it builds it usually works. So, simply testing for whether the build completes is a pretty-good first step. Of course, for system packages our recourse isn't necessarily good, since we don't have a test branch or anything like that. If we wanted to revert we'd have to impact users who already upgraded. Obviously the goal would be to fix in place with a new revbump, assuming that were possible. Rich -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQw2tZAAoJEKXdFCfdEflKrh4P/i1aJCtnVWh5IlTJ5QMd36S+ eE6chQuZGpm+7TLUsGkRG3rfTKe1vTkDj+e0R5KNQTWL3URsfo9Bc+x87EKBDlZd xkx2VRA+AojFcKwJzUDznwAwCYRz9NIhEz+6bX/Gd0w1PR7ig6JucPa9e6dj4XqG pWvf9me3D78WuNOGcQ70jYX7JxNr0+vzzRu0e4EoEphSLYzIPpdz2FIs6CHov0qD y/imKNG8TjpWRP6/It4s3+83B6nsPfGl9JcwlMXjqncAXNHc0WStFWx5oV/NfqT/ myvV/90YdY2oI5++RcWXsI52aEYuTfvnxZM1WghiymW0UVdR7r7OYMHbiE3Tq59f p8kLgGSxwyleOQHmX9o822mIF53A2PRZ/FEs6Jhr7r1R/NTnvMnePQUUMEAntwlq DjPKui7MhQr8KgnekAqw6EU42spgyKc22QXvp2rdAUnviBA5+c5CtU3RDvx5b9GO VDvuCCI24fsXe9/HyKknoyLjMwfQGHIFp8Cy3oLG40pT9LLzip+jehdv+Kdmy7nX x69bsEioIoVw23wtuWou1+a+HAlfZzTQWlr4TbeAZug9V1YGg9HxP/amzxOrBbcs qbT4Rtf332Kzx4FqYfU/ex6uaMN9fHLv6MAfS5D0l3+P5KK9zMc5P8Tlla3pRFZN I0g6imtLeVA0pMQFgsym =2tcz -END PGP SIGNATURE-
Re: [gentoo-dev] borked release media
Matt Turner wrote: I think we should consider things that break release media serious regressions. I think we should consider things that break anything serious regressions. Why should release media be more special than anything else? My email and bugzilla sweep a few days ago was during a stage4 catalyst run. I found several trivial problems which I fixed in seconds by pushing some commits to my overlay. In Gentoo, nothing has changed since then. Nothing has happened to those bugs in bugzilla, and nothing has happened in gentoo-x86. I don't think it's neccessarily less serious that existing tested trivial bug fixes don't make it to the tree. //Peter
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
On Tue, 4 Dec 2012 18:51:36 + Markos Chandras hwoar...@gentoo.org wrote: Bug-wranglers are supposed to do that by default. When you see a non-gentoo developer in metadata.xml, the default action is to assume his is the real maintainer and the bugs should be assigned to him. Such guidance should be documented in the bug-wranglers project page and not on the proxy-maintainers one. The b-w project page already explains how you can get someone in the Assignee field: by listing them first. Nothing needs to change except people's desire to format metadata.xml in whatever pretty pleases them. For anyone who doesn't want to go and look it up: The bug's Assignee field will have: 1) First listed maintainer from the top of the file 2) Lacking maintainer tags, the first listed herd tag The bug's CC field will contain every maintainer and herd left, except upstream ones. Elaborate descriptionAssign to this person when in doubt, but not during a full moon/description tags are likely to get ignored. Tags like maintainer restrict=gt;=sys-boot/grub-2... complicate matters slightly, but are much more useful than description tags (or !-- comments --, FCOL) that explain intricate hierarchical maintainer modes. Regards, jer
Re: [gentoo-dev] Re: Packages up for grabs due lavajoe retirement
On Sat, 1 Dec 2012 21:41:35 -0500 Rich Freeman ri...@gentoo.org wrote: On Sat, Dec 1, 2012 at 9:37 PM, Alec Warner anta...@gentoo.org wrote: Look, if you want to make a policy about the stuff, then make a policy, get council approval, and write it down. Don't make up silly half-solutions. Sure, but I'm not aware of any policy at all concerning packages that contain bundled libraries. https://bugs.gentoo.org/show_bug.cgi?id=251464 jer
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On Fri, Nov 30, 2012 at 10:44:31AM -0500, Richard Yao wrote: On 11/30/2012 06:46 AM, Sven Vermeulen wrote: On Nov 29, 2012 10:24 AM, Markos Chandras hwoar...@gentoo.org wrote: We could slightly simplify the handbook installation procedure if we told people to use emerge-webrsync to fetch the initial snapshot. What do people think? Seems a good improvement to me. I'm ok with it as well. I'll draft up something. I suspect emerge-webrsync is available on all platforms? It is part of sys-apps/portage. Okay, I've updated the instructions. First, I removed the references to the stage3 snapshots on the Universal CD as I don't think we have a (recent enough) Universal CD, and we would recommend the stage3 files from our mirrors anyway. Second, the Portage tree snapshots are now installed through emerge-webrsync (which means the entire section on downloading the tarballs, checking integrity, extracting is now a single paragraph). Finally, the section on updating the Portage tree (using emerge --sync) is now marked as optional, with the remark that if you're behind a firewall you can safely ignore this section as the user will already have a quite up-to-date tree installed. I don't know if we should remove the section altogether (about emerge --sync) or not. It is a small step and users *will* create bug reports about it if they don't notice it in the documentation anymore. Marking it optional seems to be a good approach here. Wkr, Sven Vermeulen PS Commit was made a few minutes ago, so please give it an hour before it shows up on the site.
[gentoo-dev] Handbook updates Was: Using emerge-webrsync to simplify the handbook
Sven Vermeulen posted on Sat, 08 Dec 2012 20:41:42 + as excerpted: On Fri, Nov 30, 2012 at 10:44:31AM -0500, Richard Yao wrote: On 11/30/2012 06:46 AM, Sven Vermeulen wrote: On Nov 29, 2012 10:24 AM, Markos Chandras hwoar...@gentoo.org wrote: We could slightly simplify the handbook installation procedure if we told people to use emerge-webrsync to fetch the initial snapshot. What do people think? Okay, I've updated the instructions. Second, the Portage tree snapshots are now installed through emerge-webrsync (which means the entire section on downloading the tarballs, checking integrity, extracting is now a single paragraph). Thanks, swift. =:^) Finally, the section on updating the Portage tree (using emerge --sync) is now marked as optional, with the remark that if you're behind a firewall you can safely ignore this section as the user will already have a quite up-to-date tree installed. I don't know if we should remove the section altogether (about emerge --sync) or not. It is a small step and users *will* create bug reports about it if they don't notice it in the documentation anymore. Marking it optional seems to be a good approach here. ++ on optional. IMHO, one of the finer points of a good handbook-based install is that it sets the user up for success by encouraging correct routine maintenance practices in the future, stepping them thru the process once during the initial install. Unfortunately, there's /way/ too many users that read only the handbook's install section (and perhaps Working with Gentoo) and never read the rest, so instilling at least some minimal basics of good routine practices there is important. Thus, even if the webrsync process grabbed them a reasonably fresh (24 hours) initial tree, keeping the now optional section on updating the tree to the very latest is a good idea, since even if it's optional, it'll step the new user thru the process at least once, establishing a good idea of that routine basic as a good practice for future updates. ... For the same reason (but likely more controversially), I'd actually argue that the install section should (optionally?) step thru installing gentoolkit and running revdep-rebuild and emerge --depclean (with an appropriate --ask/--pretend first) as the (near) final steps of the initial install, as well, even if gentoolkit is the only thing in @world when they do so, and it's technically unnecessary as there should be nothing to rebuild or depclean. For depclean especially, establishing the practice right at the beginning will help to ensure that @world always contains all desired leaf packages, and that as a result, users will never accumulate a huge backlog of uncovered packages subject to getting stale due to lack of @world updating, and that an initial depclean run when they DO get around to it won't accidentally uninstall half their system, because it never got in @world to begin with. (Of course, a successful emerge run now includes a helpful depclean reminder anyway, but stepping the user thru the process once during the initial guided install certainly can't hurt.) A quick review of the installation section in the manual suggests either covering this as part of chapter 11, Finalizing your Gentoo Installation, or instead, inserting it as chapter 11, bumping the current 11 and 12 to 12 and 13. I'd suggest the latter, with a title for the new chapter 11 of something like Your first emerge --update @world. It could encourage readers to look at the working with gentoo and working with portage sections for more, but would be an initial step-thru of a basic emerge --update @world and related maintenance (allowing a condensing of the corresponding chapters in the other sections), for those who never read past install in the handbook. Additionally, with such a title it'd be easier for users to refer back to (and see the encouragement to read the other sections again, when they maybe have more time to do so) for their second update, etc, if they needed to. One more suggestion while I'm at it. I remember all those many years ago when I first installed gentoo, even after reading and absorbing the handbook well enough to be pointing people to specific chapters and subchapters in answer to specific questions on the user list, I was still somewhat confused about the exact nature of the world list, and what packages should be listed there vs. those that shouldn't. Unless I've overlooked it, to this day there's still not a real good explanation of the distinction between leaf packages and dependencies, and why leaf packages belong in @world but dependencies don't. Something along the lines of: If you want to use and care about that specific package, put it in the world list with emerge package, without --oneshot. If you don't really care about that specific package and it's simply pulled in by something else that you DO care about, but you
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On Sat, Dec 8, 2012 at 3:41 PM, Sven Vermeulen sw...@gentoo.org wrote: Second, the Portage tree snapshots are now installed through emerge-webrsync (which means the entire section on downloading the tarballs, checking integrity, extracting is now a single paragraph). Uh, does emerge-webrsync have some kind of automagical detection of the fact that you're building a chroot? I would think that it would sync /usr/portage, and not /mnt/gentoo/usr/portage. Perhaps you should move that down into the chroot section, and mkdir /usr/portage if that is needed? Rich
Re: [gentoo-dev] borked release media
On Fri, Dec 07, 2012 at 08:55:04PM -0800, Pawe?? Hajdan, Jr. wrote The serious problem here is that we need *new* users. A non-working install CD is a really bad thing here, don't you think? ;-) While we're at it, can we please also make a USB-key install ISO? I'm not asking merely because other distros do it. I'm asking because the situation has changed in the past half-dozen years. Back in 2005 or 2006, almost all machines had a CD and/or DVD, and many older PC BIOSes did not allow for booting from a USB key. Fast-forward to 2012 (and soon 2013) and... * just about every PC is capable of booting from USB * quite a few netbooks/notebooks do not have a CD or DVD drive. E.g. I had to boot from a Knoppix USB key as my working environment to do the initial portion of the Gentoo install on my netbook. Yes, I'm aware of http://www.gentoo.org/doc/en/liveusb.xml, but even I have occasionally fouled up those intructions. It doesn't exactly encourage new Gentoo users to have to go through that tap-dance. Arch linux https://wiki.archlinux.org/index.php/USB_Installation_Media manages to have a dual-bootable (CD / USB-key) image as a standard feature. In addition to installation, it would make the base of a good system rescue utility. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] borked release media
iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. # isohybrid image.ISO # did if=image.ISO of=/dev/sdb bs=8192k sdb being your removable device. Also keep in mind that any data on sdb will be wiped after running the dd command. likewhoa Walter Dnes waltd...@waltdnes.org wrote: On Fri, Dec 07, 2012 at 08:55:04PM -0800, Pawe?? Hajdan, Jr. wrote The serious problem here is that we need *new* users. A non-working install CD is a really bad thing here, don't you think? ;-) While we're at it, can we please also make a USB-key install ISO? I'm not asking merely because other distros do it. I'm asking because the situation has changed in the past half-dozen years. Back in 2005 or 2006, almost all machines had a CD and/or DVD, and many older PC BIOSes did not allow for booting from a USB key. Fast-forward to 2012 (and soon 2013) and... * just about every PC is capable of booting from USB * quite a few netbooks/notebooks do not have a CD or DVD drive. E.g. I had to boot from a Knoppix USB key as my working environment to do the initial portion of the Gentoo install on my netbook. Yes, I'm aware of http://www.gentoo.org/doc/en/liveusb.xml, but even I have occasionally fouled up those intructions. It doesn't exactly encourage new Gentoo users to have to go through that tap-dance. Arch linux https://wiki.archlinux.org/index.php/USB_Installation_Media manages to have a dual-bootable (CD / USB-key) image as a standard feature. In addition to installation, it would make the base of a good system rescue utility. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] borked release media
Fernando Reyes wrote: iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. # isohybrid image.ISO Please send a patch to the gentoo-catalyst@ list which adds this as an optional step in the catalyst livecd2 target in a nice way, and file a bug with updated ebuilds for catalyst which add the dependency. Many thanks! //Peter
Re: [gentoo-dev] borked release media
The problem with the isohybrid approach is that it doesn't support UEFI booting and this is why I wouldn't recommended as a feature in catalyst. However, this should be documented somewhere so that users know its possible without having to follow the liveusb guide which is probably outdated by today's standards. likewhoa Peter Stuge pe...@stuge.se wrote: Fernando Reyes wrote: iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. # isohybrid image.ISO Please send a patch to the gentoo-catalyst@ list which adds this as an optional step in the catalyst livecd2 target in a nice way, and file a bug with updated ebuilds for catalyst which add the dependency. Many thanks! //Peter
