Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?
On Tue, 30 Apr 2013 19:52:03 -0600 Ryan Hill dirtye...@gentoo.org wrote: Then the person implementing the code for Paludis is either a monkey or a robot*. *or both (?!) I believe they prefer the term mathematician. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?
On Tue, 30 Apr 2013, Ryan Hill wrote: Then the person implementing the code for Paludis is either a monkey or a robot*. Anyone capable of reasoning could puzzle out the implications of not allowing user-given options to override the defaults. Obviously you can write code that follows a spec but is still broken or useless. *or both (?!) Oh please... The person simply made a mistake, which happens when programming, and which he fixed. No reason for calling him names. Ulrich
Re: [gentoo-dev] Re: GCC USE flag changes
On 01/05/2013 06:29, Rick Zero_Chaos Farina wrote: I don't mean to start a flamewar here but the test suite situation is so bad with circular deps (I'm looking at you ruby herd) and random failures that I only enable tests for my own packages. Sadly it is so bad that we have a FEATURES=test-fail-continue I can't really say anything negative, that fact really says it all... You might not mean to but honestly, do you really think that we have circular deps because we like them? FFS I've been the biggest user of FEATURES=test, and the one who poured in more time to get stuff to work, so please don't effing go around blaming people without even having a clue about what's going on, you just piss me off. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Handling of tests (was: GCC USE flag changes)
On Tue, 30 Apr 2013 21:25:40 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'm also going to rename the test flag to regression-test or something similar to get it out of FEATURES=test control. The testsuite is a huge time-suck and only useful to developers IMO (always expected to fail and primarily meant to be used to check for regressions between patchsets). I'm a big supporter of FEATURES=test by default and I think this is a small step towards that. This step is so tiny that we wont ever reach the goal like this. Let's start to properly classify test into categories, like for instance - expected to be run (cheap, no silly deps) - good thing if run (still reasonable wrt resources) (current src_test) - if you are the maintainer or simply curious. (boost, jtreg and friends) ... and improve on how to configure Portage whether to run tests of any given category. signature.asc Description: PGP signature
Re: [gentoo-dev] GNOME migrating from GConf to GSettings; effects on Gentoo?
On Wed, May 01, 2013 at 12:10:33AM -0400, Alexandre Rostovtsev wrote On Tue, 2013-04-30 at 23:26 -0400, Walter Dnes wrote: On Tue, Apr 30, 2013 at 11:17:35PM -0400, Alexandre Rostovtsev wrote It impacts users who use stable keywords and are therefore stuck with GNOME-2.32. The workaround is for affected users to switch to ~arch keywords (note that GNOME-3.x ebuilds in ~arch get vastly more care and attention from us than the theoretically stable GNOME-2.32). And the real solution is to finally stabilize some release of GNOME-3.x Thanks for the info. I didn't realize that stable was that far behind. Now to see how much I have to keyword. If you want a ready-to-use package.keywords file for GNOME 3, we have one in the gnome overlay that is reasonably well-maintained: http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=blob;f=status/portage-configs/package.keywords.gnome3 I think I just realized what this means. I run ICEWM, not GNOME. GNUMERIC and ABIWORWD and GIMP are the 3 GNOME apps that I use a lot. Do I have to emerge GNOME-BASE in it's entirety just to get GSettings working? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: GCC USE flag changes
On Wed, 01 May 2013 01:29:05 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: Sadly it is so bad that we have a FEATURES=test-fail-continue I can't really say anything negative, that fact really says it all... My beef is not with the existence of this FEATURE but that it's enabled in the dev profile. I was lucky once to not commit a broken testsuite.
[gentoo-dev] Re: RANT: Upgrade icu and KDE at once
Hi Zac,
Zac Medico wrote:
On Tue, Apr 30, 2013 at 9:51 AM, Jörg Schaible joerg.schai...@gmx.de
wrote:
The most annoying fact is, that none of this would have been necessary
with portage 2.2, but maybe we have to wait for 2.1.11.500 before 2.2
gets stable...
Since portage-2.1.11.20 [1], you can do this:
echo 'FEATURES=${FEATURES} preserve-libs' /etc/portage/make.conf
[1]
[http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/
That announcement slipped somehow my awareness. Indeed an upgrade of a
different machine with preserve-libs added to FEATURES went fine. Still, I
wonder what prevents portage-2.2 form going stable, I have one machine where
I use that one for years without any flaws and a lot of benefits.
- Jörg
Re: [gentoo-dev] RANT: Upgrade icu and KDE at once
Jörg Schaible wrote: icu. The ebuild happily removes any trace of the old shared libs with the result that half of the stuff that is *required* to build kdelibs is now broken. The build aborts and leaves behind a broken system. And this happened now not for the first time! Tom Wijsman wrote: Well, here we go again! Again an update of Gentoo stable where emerge tries to upgrade icu and KDE in one run (and this time additionally libreoffice). If you don't want that to happen, use package sets and exclusion. Wait - using default settings results in emerge leaving a broken system, and your response is take non-default actions to avoid that ? //Peter
Re: [gentoo-dev] RANT: Upgrade icu and KDE at once
On Wed, 1 May 2013 11:20:37 +0200 Peter Stuge pe...@stuge.se wrote: Tom Wijsman wrote: Well, here we go again! Again an update of Gentoo stable where emerge tries to upgrade icu and KDE in one run (and this time additionally libreoffice). If you don't want that to happen, use package sets and exclusion. Wait - using default settings results in emerge leaving a broken system, and your response is take non-default actions to avoid that ? in one run, I see no mention of broken in what I quoted here; don't pull it out of its context, it was just a suggestion. -- 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] Making systemd more accessible to normal users
PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. - genkernel should at least support plymouth (work in progress my side) - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). All this would come with no cost for the current openrc state (actually, my initramfs speed improvements patches in genkernel.git also benefit openrc). If Gentoo is about choice, we should give our users the right to choose between the init system they like the most. It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) - we give the users the right to choose without driving them nuts with weird emerge-fu. - we make possible to support new init systems in future, and even specific init wrappers (bootchart anyone?) - we prepare the path towards a painless migration from consolekit (deprecated for long time now) to logind (we probably need to fork it off the systemd pkg -- upstream projects are _dropping_ consolekit support right now!) - we put back some fun into Gentoo If you want to see a working implementation of my systemd-love efforts, just go download [1] and see things working yourself. [1] http://www.sabayon.org/release/press-release-sabayon-1304 [2] https://github.com/Sabayon/systemd-love [3] For instance: https://bugs.gentoo.org/show_bug.cgi?id=465236 [4] useless crap: https://bugs.gentoo.org/show_bug.cgi?id=399615 Cheers, -- Fabio Erculiani
Re: [gentoo-dev] RANT: Upgrade icu and KDE at once
Peter Stuge wrote: Jörg Schaible wrote: icu. The ebuild happily removes any trace of the old shared libs with the result that half of the stuff that is *required* to build kdelibs is now broken. The build aborts and leaves behind a broken system. And this happened now not for the first time! Tom Wijsman wrote: If you don't want that to happen, use package sets and exclusion. Wait - using default settings results in emerge leaving a broken system, and your response is take non-default actions to avoid that ? in one run, I see no mention of broken in what I quoted here; don't pull it out of its context, it was just a suggestion. The way I understood Jörg was that the greater context is that files needed in later steps of an emerge were removed by earlier steps. Even if this doesn't happen very regularly I think it's a problem that it can happen at all. I guess the solution is known, but not there yet? //Peter
Re: [gentoo-dev] Making systemd more accessible to normal users
El mié, 01-05-2013 a las 12:04 +0200, Fabio Erculiani escribió: [...] - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). [...] Can't them be stolen from other distros running systemd? [...] The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. I am unable to find exact advantage of changing init system without rebooting :/, what is the advantage of booting with an init.d and shutting down with a different one? The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) Are udev and systemd-udev-part really equivalent? I mean, since they are maintained by different people downstream, I am not sure if there would be differences in how udev from udev ebuild and udev from systemd ebuild will behave. Best regards and thanks for your work!
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 1, 2013 at 12:50 PM, Pacho Ramos pa...@gentoo.org wrote: El mié, 01-05-2013 a las 12:04 +0200, Fabio Erculiani escribió: [...] - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). [...] Can't them be stolen from other distros running systemd? Sure, Arch and Fedora repositories are a good source. [...] The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. I am unable to find exact advantage of changing init system without rebooting :/, what is the advantage of booting with an init.d and shutting down with a different one? No, you don't boot with A and shutdown with B. B is loaded by the kernel at the next boot. Switching init system is the only way to roll out a migration path, among other things I already wrote about on the eselect-sysvinit bug. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) Are udev and systemd-udev-part really equivalent? I mean, since they are maintained by different people downstream, I am not sure if there would be differences in how udev from udev ebuild and udev from systemd ebuild will behave. This needs investigation. Best regards and thanks for your work! -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
El mié, 01-05-2013 a las 13:00 +0200, Fabio Erculiani escribió: [...] The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. I am unable to find exact advantage of changing init system without rebooting :/, what is the advantage of booting with an init.d and shutting down with a different one? No, you don't boot with A and shutdown with B. B is loaded by the kernel at the next boot. Switching init system is the only way to roll out a migration path, among other things I already wrote about on the eselect-sysvinit bug. Ah! OK, I misunderstood the runtime sense, in that case looks interesting :D
Re: [gentoo-dev] GNOME migrating from GConf to GSettings; effects on Gentoo?
On Wed, 2013-05-01 at 04:19 -0400, Walter Dnes wrote: I think I just realized what this means. I run ICEWM, not GNOME. GNUMERIC and ABIWORWD and GIMP are the 3 GNOME apps that I use a lot. Do I have to emerge GNOME-BASE in it's entirety just to get GSettings working? Then I misunderstood. I thought that you were running GNOME-2.32 and were complaining that while 2.32-era programs like epiphany-2.32, gnome-control-center-2.32, etc. expect all their settings to be stored in gconf, modern programs or libraries designed for GNOME-3 expect these settings to be stored in gsettings, which results in inconsistencies and strange behavior. But if you are running IceWM, this should not be a problem. To get gsettings working, you only need 4 things: dbus, glib, dconf, and gsettings-desktop-schemas. And the latest stable versions of them would be sufficient.
[gentoo-dev] Re: Making systemd more accessible to normal users
On Wed, May 01, 2013 at 12:04:00PM +0200, Fabio Erculiani wrote: PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. That's great: well done :-) Can I just check: what about people not using consolekit nor logind? It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. I don't think you help yourself by making that kind of remark: when I read those bugs I see some valid concerns being raised, which you just ignore. For instance, wrt nonsensical blockers I too would like to know some examples, as was queried in comment 27 [3]. In fact it was the first thing that came to mind when reading your post, as I thought where possible things were just installed for systemd (such as unit files) even when the user is not using it. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so Again, what about people not using consolekit, nor logind, with no intention of ever installing systemd? I've got nothing against this so long as it is guaranteed not to break my pam setup. As-is I feel *very* wary of a change that unconditionally requires a 'pam_systemd.so'. Please note I am not hostile to your aims: I am merely seeking reassurance. - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Why is that such a miracle? openrc has worked with lvm since the beginning afair, and is both clean, portable C, and modular. Alternatively, we should migrate to dracut. - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. Sounds reasonable; since I don't use it, that can't affect me in any case. - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. - genkernel should at least support plymouth (work in progress my side) - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). All this would come with no cost for the current openrc state (actually, my initramfs speed improvements patches in genkernel.git also benefit openrc). If Gentoo is about choice, we should give our users the right to choose between the init system they like the most. I must be missing something as I thought they already had that choice. From reading the bug, the only pro of your approach is that the user does not have to edit the kernel command-line to try out a new init. Initially, you tried to sell this as lowering the bar which is actually a con afaic: if someone is trying to run Gentoo and is incapable of dealing with the kernel command-line, it's likely they won't be able to install it; they certainly won't be able to maintain it, ime. Later, we get the some EFI bootloaders don't allow it. Could you elaborate on how a system we install grub to, won't allow us to change anything? I am not doubting you: I just think we need more explanation of the exact context where we can install Gentoo, but not a bootloader. It looks like there is some consensus on the effort of making systemd more accessible, Sure there is: there's also consensus that this approach is wrong for Gentoo. And I have to concur, without further reasoning from you. Switching init isn't done that often, and when it is a Gentoo user is expected to deal with configuration. In this case, it's a doddle to set the command-line to init=/sbin/fubar to try it, and then when it's running the user can change the symlink, or just revert as they choose. If they can't handle the above, they shouldn't be on Gentoo imo. And sabayon already sets up systemd, so I don't see the use-case frankly. Apart from making Gentoo base-system more suitable for direct usage in Sabayon, which is not our problem. What are the effects for other downstreams? Funtoo for instance, has been swimming against the upstream udev/systemd mania, from glancing at their site recently. Have you consulted with other downstreams about their needs and got buy-in from them too? That would strengthen your case, tho imo it's weak irrespective of what systemd-preferring downstreams want: after all, they're distros, not
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
On Wed, May 1, 2013 at 2:54 PM, Steven J. Long sl...@rathaus.eclipse.co.uk wrote: On Wed, May 01, 2013 at 12:04:00PM +0200, Fabio Erculiani wrote: PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. That's great: well done :-) Can I just check: what about people not using consolekit nor logind? This has nothing to do with it. If you don't want consolekit nor logind just USE=-consolekit -systemd. It looks like you haven't clear what I'm writing about, though. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. I don't think you help yourself by making that kind of remark: when I read those bugs I see some valid concerns being raised, which you just ignore. For instance, wrt nonsensical blockers I too would like to know some examples, as was queried in comment 27 [3]. In fact it was the first thing that came to mind when reading your post, as I thought where possible things were just installed for systemd (such as unit files) even when the user is not using it. Have you ever tried to fully migrate to systemd from openrc? Clearly not. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so Again, what about people not using consolekit, nor logind, with no intention of ever installing systemd? I've got nothing against this so long as it is guaranteed not to break my pam setup. As-is I feel *very* wary of a change that unconditionally requires a 'pam_systemd.so'. Please note I am not hostile to your aims: I am merely seeking reassurance. Do you know how pam works? And did you understand the meaning of my words? Do you know what optional means in this context? - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Why is that such a miracle? openrc has worked with lvm since the beginning afair, and is both clean, portable C, and modular. Do you know how LVM and udev and systemd interact wrt volumes activation? Alternatively, we should migrate to dracut. - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. Sounds reasonable; since I don't use it, that can't affect me in any case. My goal wrt openrc is to keep the current level of support and just make systemd users' life easier. - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. - genkernel should at least support plymouth (work in progress my side) - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). All this would come with no cost for the current openrc state (actually, my initramfs speed improvements patches in genkernel.git also benefit openrc). If Gentoo is about choice, we should give our users the right to choose between the init system they like the most. I must be missing something as I thought they already had that choice. Please, write about something you actually manage to _know_. And also, please do read my post title. This is not a flamewar topic, I want to discuss about improving the systemd experience. From reading the bug, the only pro of your approach is that the user does not have to edit the kernel command-line to try out a new init. Initially, you tried to sell this as lowering the bar which is actually a con afaic: if someone is trying to run Gentoo and is incapable of dealing with the kernel command-line, it's likely they won't be able to install it; they certainly won't be able to maintain it, ime. Later, we get the some EFI bootloaders don't allow it. Could you elaborate on how a system we install grub to, won't allow us to change anything? I am not doubting you: I just think we need more explanation of the exact context where we can install Gentoo, but not a bootloader. Being Gentoo does not absolutely mean that we have to craft watches and play VHS with the tongue every time we want to do something. Making things easy is an orthogonal concept! It looks like there is some consensus on the effort of making systemd more accessible, Sure there is: there's also
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/01/13 05:04, Fabio Erculiani wrote: PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. - genkernel should at least support plymouth (work in progress my side) - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). All this would come with no cost for the current openrc state (actually, my initramfs speed improvements patches in genkernel.git also benefit openrc). If Gentoo is about choice, we should give our users the right to choose between the init system they like the most. It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) - we give the users the right to choose without driving them nuts with weird emerge-fu. - we make possible to support new init systems in future, and even specific init wrappers (bootchart anyone?) - we prepare the path towards a painless migration from consolekit (deprecated for long time now) to logind (we probably need to fork it off the systemd pkg -- upstream projects are _dropping_ consolekit support right now!) - we put back some fun into Gentoo If you want to see a working implementation of my systemd-love efforts, just go download [1] and see things working yourself. [1] http://www.sabayon.org/release/press-release-sabayon-1304 [2] https://github.com/Sabayon/systemd-love [3] For instance: https://bugs.gentoo.org/show_bug.cgi?id=465236 [4] useless crap: https://bugs.gentoo.org/show_bug.cgi?id=399615 Cheers, Isn't there a tracker (and if not, why have you not created one yet :P ) -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
There is no tracker yet. But it may be very well materialize at some point. -- Fabio Erculiani
Re: [gentoo-dev] RANT: Upgrade icu and KDE at once
On Tue, Apr 30, 2013 at 2:53 PM, Zac Medico zmed...@gentoo.org wrote:
On Tue, Apr 30, 2013 at 9:51 AM, Jörg Schaible joerg.schai...@gmx.de wrote:
The most annoying fact is, that none of this would have been necessary with
portage 2.2, but maybe we have to wait for 2.1.11.500 before 2.2 gets
stable...
Since portage-2.1.11.20 [1], you can do this:
echo 'FEATURES=${FEATURES} preserve-libs' /etc/portage/make.conf
[1]
http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/
I think it is time to consider enabling this by default. Hopefully any
ABI bumps will be accompanied by a subslot / slot-operator migration
at this point.
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 1, 2013 at 6:04 AM, Fabio Erculiani lx...@gentoo.org wrote: - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. I'm not sure what migrating to dracut actually means. A gentoo install doesn't include genkernel in the first place - it is installed manually. If you mean documenting how to use dracut in the handbook, then I think that makes sense - we already document multiple alternatives like genkernel, manual kernel builds, grub, lilo, etc. I've been running dracut for almost a year now and it has been working well, though I might note that I had to build a custom module to get mdadm+LVM to work (not sure if current versions work out of the box, and my use of old mdadm metadata versions due to previously having followed the Gentoo mdadm+lvm guide might have something to do with it). Honestly, I'm not sure how important it is to be able to switch back/forth at runtime. We should definitely support both options reasonably well, but not to the point where people end up with a lot of dependencies/complexity that a typical user doesn't actually have need for. Rich
Re: [gentoo-dev] Re: RANT: Upgrade icu and KDE at once
On 05/01/2013 02:07 AM, Jörg Schaible wrote:
Hi Zac,
Zac Medico wrote:
On Tue, Apr 30, 2013 at 9:51 AM, Jörg Schaible joerg.schai...@gmx.de
wrote:
The most annoying fact is, that none of this would have been necessary
with portage 2.2, but maybe we have to wait for 2.1.11.500 before 2.2
gets stable...
Since portage-2.1.11.20 [1], you can do this:
echo 'FEATURES=${FEATURES} preserve-libs' /etc/portage/make.conf
[1]
[http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/
That announcement slipped somehow my awareness. Indeed an upgrade of a
different machine with preserve-libs added to FEATURES went fine. Still, I
wonder what prevents portage-2.2 form going stable, I have one machine where
I use that one for years without any flaws and a lot of benefits.
I think it's more useful to talk about specific features and their
readiness to be enabled by default in stable, rather then when
everything in portage-2.2 should go stable. Which features in
portage-2.2 are you using that are ready for stable?
Not that the difference between portage-2.1 and portage-2.2 is just the
constants that you can see in this commit:
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=92ce3fcbf2c6d791151afc6edbbb18a530db12e2
--
Thanks,
Zac
Re: [gentoo-dev] RANT: Upgrade icu and KDE at once
On 05/01/2013 07:46 AM, Mike Gilbert wrote:
On Tue, Apr 30, 2013 at 2:53 PM, Zac Medico zmed...@gentoo.org wrote:
On Tue, Apr 30, 2013 at 9:51 AM, Jörg Schaible joerg.schai...@gmx.de wrote:
The most annoying fact is, that none of this would have been necessary with
portage 2.2, but maybe we have to wait for 2.1.11.500 before 2.2 gets
stable...
Since portage-2.1.11.20 [1], you can do this:
echo 'FEATURES=${FEATURES} preserve-libs' /etc/portage/make.conf
[1]
http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/
I think it is time to consider enabling this by default. Hopefully any
ABI bumps will be accompanied by a subslot / slot-operator migration
at this point.
Yeah, I'm pretty happy with the slot-operator adoption, so it feels like
it's about time to enable preserve-libs by default in stable. I know
that this feature has been questioned by some, especially by people
involved with Paludis (which doesn't implement preserve-libs). Maybe it
would be a good idea to get an opinion from the council on whether or
not it should be enabled by default in stable portage.
--
Thanks,
Zac
Re: [gentoo-dev] RANT: Upgrade icu and KDE at once
On Wed, May 1, 2013 at 11:01 AM, Zac Medico zmed...@gentoo.org wrote:
On 05/01/2013 07:46 AM, Mike Gilbert wrote:
On Tue, Apr 30, 2013 at 2:53 PM, Zac Medico zmed...@gentoo.org wrote:
On Tue, Apr 30, 2013 at 9:51 AM, Jörg Schaible joerg.schai...@gmx.de
wrote:
The most annoying fact is, that none of this would have been necessary with
portage 2.2, but maybe we have to wait for 2.1.11.500 before 2.2 gets
stable...
Since portage-2.1.11.20 [1], you can do this:
echo 'FEATURES=${FEATURES} preserve-libs' /etc/portage/make.conf
[1]
http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/
I think it is time to consider enabling this by default. Hopefully any
ABI bumps will be accompanied by a subslot / slot-operator migration
at this point.
Yeah, I'm pretty happy with the slot-operator adoption, so it feels like
it's about time to enable preserve-libs by default in stable. I know
that this feature has been questioned by some, especially by people
involved with Paludis (which doesn't implement preserve-libs). Maybe it
would be a good idea to get an opinion from the council on whether or
not it should be enabled by default in stable portage.
I have requested that this be added to the agenda for the next council
meeting in a couple of weeks.
[gentoo-dev] Re: Re: Making systemd more accessible to normal users
On Wed, May 01, 2013 at 03:14:07PM +0100, Fabio Erculiani wrote: On Wed, May 1, 2013 at 2:54 PM, Steven J. Long sl...@rathaus.eclipse.co.uk wrote: On Wed, May 01, 2013 at 12:04:00PM +0200, Fabio Erculiani wrote: PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. That's great: well done :-) Can I just check: what about people not using consolekit nor logind? This has nothing to do with it. If you don't want consolekit nor logind just USE=-consolekit -systemd. It looks like you haven't clear what I'm writing about, though. Ah I see: sorry you're taking my email in the wrong spirit. I thought I made it quite clear I'm not hostile to your intentions, but you appear to be hostile to everything I've written. FTR, as I said I was just checking that there would not be a hard dependency introduced, since a) it would affect me and b) I wanted to know you're aware of those use-cases, and that you already keep them in mind, going forward. When someone says just checking or can I just check.. it means they don't expect there's any issue, but they'd like to be sure. Hence just a check. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. I don't think you help yourself by making that kind of remark: when I read those bugs I see some valid concerns being raised, which you just ignore. For instance, wrt nonsensical blockers I too would like to know some examples, as was queried in comment 27 [3]. In fact it was the first thing that came to mind when reading your post, as I thought where possible things were just installed for systemd (such as unit files) even when the user is not using it. Have you ever tried to fully migrate to systemd from openrc? Clearly not. OFC not, that's the point: it's why I'm asking you. The other person in the bug clearly has some experience, and you refrained from answering him too. Oh well. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so Again, what about people not using consolekit, nor logind, with no intention of ever installing systemd? I've got nothing against this so long as it is guaranteed not to break my pam setup. As-is I feel *very* wary of a change that unconditionally requires a 'pam_systemd.so'. Please note I am not hostile to your aims: I am merely seeking reassurance. Do you know how pam works? And did you understand the meaning of my words? Again, you're not helping yourself with this attitude. Just a friendly warning. Do you know what optional means in this context? Always enable the optional.. means require the currently optional.. to me. - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Why is that such a miracle? openrc has worked with lvm since the beginning afair, and is both clean, portable C, and modular. Do you know how LVM and udev and systemd interact wrt volumes activation? I have a fair idea of how lvm, udev and openrc interact, after making udev start after localmount last August. But really, all your replies are along the lines of questioning my competence instead of answering the point. I still don't see why you think it's a miracle openrc works with lvm, unless you mean it was an effort for you. I do recall a bug with lvm a couple of months ago I had to patch the lvm initscript for; but I notified the openrc channel about it and they fixed it pretty quickly. Again, more experience that clearly makes me incompetent. Alternatively, we should migrate to dracut. - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. Sounds reasonable; since I don't use it, that can't affect me in any case. My goal wrt openrc is to keep the current level of support and just make systemd users' life easier. snip If Gentoo is about choice, we should give our users the right to choose between the init system they like the most. I must be missing something as I thought they already had that choice. Please, write about something you actually manage to _know_. And also, please do read my post title. This is not a flamewar topic, I want to discuss about improving the systemd experience. Hmm.. no. I'm afraid you
Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?
On 1 May 2013 02:52, Ryan Hill dirtye...@gentoo.org wrote: Then the person implementing the code for Paludis is either a monkey or a robot*. *or both (?!) Alternative possibilities include ninja, zombie and wizard.
[gentoo-dev] Last rites: www-apache/mod_loopback, www-apache/mod_watch
# Ulrich Müller u...@gentoo.org (01 May 2013) # HOMEPAGE and SRC_URI dead, tarball not redistributable. # Last upstream release in 2004. # Masked for removal in 30 days, bug #464938. www-apache/mod_loopback # Ulrich Müller u...@gentoo.org (01 May 2013) # HOMEPAGE and SRC_URI dead, tarball not redistributable. # Last upstream release in 2004. # Masked for removal in 30 days, bug #464934. www-apache/mod_watch pgpvNomczl4B5.pgp Description: PGP signature
Re: [gentoo-dev] GCC USE flag changes
On 4/30/13 8:25 PM, Ryan Hill wrote: I'm also going to rename the test flag to regression-test or something similar to get it out of FEATURES=test control. The testsuite is a huge time-suck and only useful to developers IMO (always expected to fail and primarily meant to be used to check for regressions between patchsets). I'm a big supporter of FEATURES=test by default and I think this is a small step towards that. +1 I'll make these changes at the same time as 4.7.3 is bumped to minimize rebuilding but of course stable versions will be affected as well. That's just waiting for me to go through the open bugs so probably end of weekish. Sounds good. I'd also like to drop graphite support for versions 4.4 and 4.5. We use a patch to dlopen graphite libs but older versions were written for ppl-0.10/0.11 (0.12 is the current version) so I doubt they still work properly (missing symbols and whatnot). Some archs still have 4.5 as the latest stable but graphite isn't a supported feature and the number of users on those archs is likely tiny. Yeah, +1 as well. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On 5/1/13 3:04 AM, Fabio Erculiani wrote: It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. [4] useless crap: https://bugs.gentoo.org/show_bug.cgi?id=399615 As far as I read the bug, Mike (vapier) is doing the right thing. Distros doing lots of custom changes can only add more chaos to the picture. Have you reached out to relevant upstreams? If they refuse to make changes, that's a different story. So far I think it's reasonable to go to upstreams first. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, 01 May 2013 12:52:09 -0700 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 5/1/13 3:04 AM, Fabio Erculiani wrote: It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. [4] useless crap: https://bugs.gentoo.org/show_bug.cgi?id=399615 As far as I read the bug, Mike (vapier) is doing the right thing. Distros doing lots of custom changes can only add more chaos to the picture. Have you reached out to relevant upstreams? If they refuse to make changes, that's a different story. So far I think it's reasonable to go to upstreams first. Well, the first thing to do would be making /sbin/init a symlink and renaming sysvinit. Now, why would sysvinit upstream do such a thing? I doubt it's a change that upstream should be willing to do because of what downstream wants to do afterwards... -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] [PATCHES] distutils-r1: support 'edefault' in sub-phase functions
Hi, everyone.
This one goes to gentoo-dev since it's a potentially wider idea
and I'd like to get other developers opinion on.
As you most likely already know, distutils-r1 allows ebuilds to define
sub-phase functions like:
python_compile() {
# commands which will be run for each impl
do_something_magical
}
Often, ebuilds do not want to override the sub-phases completely
but instead call the default implementation:
python_install_all() {
use doc local HTML_DOCS=( doc/html/. )
distutils-r1_python_install_all
}
So the behavior is quite similar to the regular phase functions.
However, the function names ended up quite verbose.
To make this more friendly, I would likely to locally introduce
'edefault' function in the eclass (name can change). The function would
-- similarly to 'default' in regular phase functions -- call
the default code for the sub-phase.
For example, the above would change to:
python_install_all() {
use doc local HTML_DOCS=( doc/html/. )
edefault
}
I will send in reply a patch adding the described magic to the eclass,
and a second one showing how an example ebuild can be changed
(dev-python/setuptools).
What are your thoughts?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH 1/2] Introduce edefault() as a friendly default sub-phase wrapper.
---
gx86/eclass/distutils-r1.eclass | 18 ++
1 file changed, 18 insertions(+)
diff --git a/gx86/eclass/distutils-r1.eclass b/gx86/eclass/distutils-r1.eclass
index 47b5b97..4c2e819 100644
--- a/gx86/eclass/distutils-r1.eclass
+++ b/gx86/eclass/distutils-r1.eclass
@@ -206,6 +206,20 @@ fi
# }
# @CODE
+# @FUNCTION: edefault
+# @USAGE: [args...]
+# @DESCRIPTION:
+# Runs the default distutils-r1 sub-phase implementation for the current
+# sub-phase. Available only in distutils-r1 sub-phases.
+#
+# Example:
+# @CODE
+# python_install_all() {
+# use doc local HTML_DOCS=( doc/html/. )
+# edefault # == distutils-r1_python_install_all
+# }
+# @CODE
+
# @FUNCTION: esetup.py
# @USAGE: [args...]
# @DESCRIPTION:
@@ -515,8 +529,12 @@ distutils-r1_run_phase() {
mkdir -p ${TMPDIR} || die
+ eval edefault() { ${1} }
+
${@}
+ unset -f edefault
+
if [[ ${DISTUTILS_IN_SOURCE_BUILD} ! ${DISTUTILS_SINGLE_IMPL} ]]
then
popd /dev/null || die
--
1.8.2.1
[gentoo-dev] [PATCH 2/2] Example use of edefault.
---
gx86/dev-python/setuptools/setuptools-0.6.33.ebuild | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gx86/dev-python/setuptools/setuptools-0.6.33.ebuild
b/gx86/dev-python/setuptools/setuptools-0.6.33.ebuild
index 4f4f3aa..91a8d57 100644
--- a/gx86/dev-python/setuptools/setuptools-0.6.33.ebuild
+++ b/gx86/dev-python/setuptools/setuptools-0.6.33.ebuild
@@ -37,7 +37,7 @@ python_prepare_all() {
# Disable tests requiring network connection.
rm -f setuptools/tests/test_packageindex.py
- distutils-r1_python_prepare_all
+ edefault
}
python_test() {
@@ -48,5 +48,5 @@ python_test() {
python_install() {
DISTRIBUTE_DISABLE_VERSIONED_EASY_INSTALL_SCRIPT=1 \
DONT_PATCH_SETUPTOOLS=1 \
- distutils-r1_python_install
+ edefault
}
--
1.8.2.1
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 1, 2013 at 9:52 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 5/1/13 3:04 AM, Fabio Erculiani wrote: As far as I read the bug, Mike (vapier) is doing the right thing. Distros doing lots of custom changes can only add more chaos to the picture. We are a distribution, we have our own goals, thus we change the code to better integrate with our ecosystem. That's part of the game. If we don't want to do that, we shouldn't be running a distro in the first place. Have you reached out to relevant upstreams? If they refuse to make changes, that's a different story. So far I think it's reasonable to go to upstreams first. For just a symlink swap and some file moves? (re: sysvinit) We don't need to bless upstream first for such small changes. Paweł -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
Fabio, I think you're doing awesome work! Steven, I think you can behave a lot better on the internet. kthx. Steven J. Long wrote: It looks like there is some consensus on the effort of making systemd more accessible, Sure there is: there's also consensus that this approach is wrong for Gentoo. In my world naysayers have no say and doers decide, as long as there are no obvious negative consequences from doing. In my world it is also an absolute no-brainer to try to make systemd as accessible as possible in Gentoo. Switching init isn't done that often That doesn't mean that it couldn't be, and it also doesn't mean that it wouldn't be handy to use eselect to do so. and when it is a Gentoo user is expected to deal with configuration. I don't know where such expectation could come from since, as you write, switching init isn't done that often; so there can't be a lot of user feedback from doing it, and it hasn't been discussed very much by developers. If you mean that *you* expect users to deal with configuration then that's fine and valid, but I think that if we can find a neat way for users *not* to have to deal with configuration when they want to switch init then that would be really nice! In this case, it's a doddle to set the command-line to init=/sbin/fubar to try it I think it's less about telling the kernel which binary will be process 1 and more about what gets started by process 1 on next boot. If they can't handle the above, they shouldn't be on Gentoo imo. You have all right to your opinion, but I for one don't share this opinion. If we can make it easy to switch around I think that's awesome. I don't see the use-case frankly. I would say that it is to make migration easy. So I just don't see which Gentoo users this is helping. Anyone who has a Gentoo system using OpenRC who would like to try out systemd. Making it even more trivial to change init than it already is, is actually a bad thing in my eyes. It gives the impression that it can be undertaken lightly which is simply bad practice. Sorry, I don't buy your argument. Consider how lightly I can undertake deletion of all my data, which is also bad practise: rm -rf ~ AFAIK it's been policy for a while that systemd unit files should be installed by default, for all the reasons you've given. I can't see a maintainer being bothered by the systemd herd adding them when they have no interest: after all users can already set an INSTALL_MASK, and it makes binpkgs more useful. Yep, +1 for all of this. I think Fabio shouldn't let unresponsiveness of others create very long wait states when doing benign changes. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) How is adding USE=systemd to a system with it switched off (ie: enabling it), *not* going to lead to recompilation? Setting the USE flag doesn't lead to recompilation per se, but the question is good - what will the USE flag actually mean when we arrive at the final outcome? Will it do anything at all? Fabio? In the end, maybe it would just control if baselayout DEPENDs on openrc or systemd? - we make possible to support new init systems in future, and even specific init wrappers (bootchart anyone?) Which is possible already, so this is null. Consider that Fabio and I are not native english speakers. I would recommend spending more time seeking to understand what was intended to be transmitted, rather than merely interpreting the words received. Communication becomes significantly more effectively that way, which you probably don't need me to bring up, if you're used to talking to users on forums. :) - we put back some fun into Gentoo Eh, I've been having much more fun since .. .. the latter is only possible because Unix is designed on a modular basis, and we can still swap components in and out on Linux (for now.) You are implicitly communicating that systemd can not be fun because it is not modular. Basic flaming. What's the point of that? Please note: I fully support your effort to make it easy to switch back and forth I have no doubts that this was true in your original email, but you should consider that the words you chose communicate something very different. I just don't think that adding a fragile eselect module (along with this needs investigation as things come up) is the way to do it. I think the point is to investigate exactly to ensure that the module *is not* fragile. Nor should someone change init on a whim, without being ready to handle configuration. I think it would be awesome if we can allow changing init on a whim, without having to handle configuration. In fact, dumbing down Gentoo is dangerous imo. I think you misinterpret the intention.
Re: [gentoo-dev] GNOME migrating from GConf to GSettings; effects on Gentoo?
On Wed, May 01, 2013 at 09:22:56AM -0400, Alexandre Rostovtsev wrote On Wed, 2013-05-01 at 04:19 -0400, Walter Dnes wrote: I think I just realized what this means. I run ICEWM, not GNOME. GNUMERIC and ABIWORWD and GIMP are the 3 GNOME apps that I use a lot. Do I have to emerge GNOME-BASE in it's entirety just to get GSettings working? Then I misunderstood. I thought that you were running GNOME-2.32 and were complaining that while 2.32-era programs like epiphany-2.32, gnome-control-center-2.32, etc. expect all their settings to be stored in gconf, modern programs or libraries designed for GNOME-3 expect these settings to be stored in gsettings, which results in inconsistencies and strange behavior. But if you are running IceWM, this should not be a problem. To get gsettings working, you only need 4 things: dbus, glib, dconf, and gsettings-desktop-schemas. And the latest stable versions of them would be sufficient. Thank you very much. This will be helpful on my netbook (2 gigs ram and Intel Atom processor). Gnome 3.x would be too much for it to run. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 1, 2013 at 2:40 PM, Peter Stuge pe...@stuge.se wrote: Steven, I think you can behave a lot better on the internet. kthx. Amazing. I came to the exact opposite conclusion.
[gentoo-dev] Re: GCC USE flag changes
On Wed, 01 May 2013 08:00:29 +0100 Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 01/05/2013 06:29, Rick Zero_Chaos Farina wrote: I don't mean to start a flamewar here but the test suite situation is so bad with circular deps (I'm looking at you ruby herd) and random failures that I only enable tests for my own packages. Sadly it is so bad that we have a FEATURES=test-fail-continue I can't really say anything negative, that fact really says it all... You might not mean to but honestly, do you really think that we have circular deps because we like them? FFS I've been the biggest user of FEATURES=test, and the one who poured in more time to get stuff to work, so please don't effing go around blaming people without even having a clue about what's going on, you just piss me off. He wasn't singling you out, just naming a part of the tree that has a lot of circular deps. He could've said python just as easy. Relax, have a Guinness. -- gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Re: Handling of tests (was: GCC USE flag changes)
On Wed, 1 May 2013 10:14:02 +0200 Ralph Sennhauser s...@gentoo.org wrote: On Tue, 30 Apr 2013 21:25:40 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'm also going to rename the test flag to regression-test or something similar to get it out of FEATURES=test control. The testsuite is a huge time-suck and only useful to developers IMO (always expected to fail and primarily meant to be used to check for regressions between patchsets). I'm a big supporter of FEATURES=test by default and I think this is a small step towards that. This step is so tiny that we wont ever reach the goal like this. I was hoping it would set a precedent and then people would start thinking of splitting up test into categories, maybe even start a thread about it ;). Let's start to properly classify test into categories, like for instance - expected to be run (cheap, no silly deps) - good thing if run (still reasonable wrt resources) (current src_test) - if you are the maintainer or simply curious. (boost, jtreg and friends) Something like dev-test or qa-test? I can think of a couple packages.. ... and improve on how to configure Portage whether to run tests of any given category. Yeah I'd love to be able to do something like emerge TESTS=dev qa system -extradeps -expensive @world. -- gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Handling of tests (was: GCC USE flag changes)
2 other classes of tests you may want to consider : - network/internet accessibility required tests - markers for tests that are known/expected to fail under many conditions and are not worth end-user-testing, but end-users can force-running any way if they really want to see the individual failures. On 2 May 2013 13:18, Ryan Hill dirtye...@gentoo.org wrote: On Wed, 1 May 2013 10:14:02 +0200 Ralph Sennhauser s...@gentoo.org wrote: On Tue, 30 Apr 2013 21:25:40 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'm also going to rename the test flag to regression-test or something similar to get it out of FEATURES=test control. The testsuite is a huge time-suck and only useful to developers IMO (always expected to fail and primarily meant to be used to check for regressions between patchsets). I'm a big supporter of FEATURES=test by default and I think this is a small step towards that. This step is so tiny that we wont ever reach the goal like this. I was hoping it would set a precedent and then people would start thinking of splitting up test into categories, maybe even start a thread about it ;). Let's start to properly classify test into categories, like for instance - expected to be run (cheap, no silly deps) - good thing if run (still reasonable wrt resources) (current src_test) - if you are the maintainer or simply curious. (boost, jtreg and friends) Something like dev-test or qa-test? I can think of a couple packages.. ... and improve on how to configure Portage whether to run tests of any given category. Yeah I'd love to be able to do something like emerge TESTS=dev qa system -extradeps -expensive @world. -- gcc-porting toolchain, wxwidgets @ gentoo.org -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
[gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?
On Wed, 1 May 2013 08:57:35 +0200 Ulrich Mueller u...@gentoo.org wrote: On Tue, 30 Apr 2013, Ryan Hill wrote: Then the person implementing the code for Paludis is either a monkey or a robot*. Anyone capable of reasoning could puzzle out the implications of not allowing user-given options to override the defaults. Obviously you can write code that follows a spec but is still broken or useless. *or both (?!) Oh please... The person simply made a mistake, which happens when programming, and which he fixed. No reason for calling him names. Sorry, I was under the impression that they were refusing to acknowledge it as a mistake on the grounds that it was allowed by the spec, despite the consequences, and demanding ebuilds to be fixed instead. I have other names for those people I could use but I doubt you'd like them any better. -- gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GCC USE flag changes
On Wed, May 1, 2013 at 5:59 PM, Ryan Hill dirtye...@gentoo.org wrote: On Wed, 01 May 2013 08:00:29 +0100 Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 01/05/2013 06:29, Rick Zero_Chaos Farina wrote: I don't mean to start a flamewar here but the test suite situation is so bad with circular deps (I'm looking at you ruby herd) and random failures that I only enable tests for my own packages. Sadly it is so bad that we have a FEATURES=test-fail-continue I can't really say anything negative, that fact really says it all... You might not mean to but honestly, do you really think that we have circular deps because we like them? FFS I've been the biggest user of FEATURES=test, and the one who poured in more time to get stuff to work, so please don't effing go around blaming people without even having a clue about what's going on, you just piss me off. He wasn't singling you out, just naming a part of the tree that has a lot of circular deps. He could've said python just as easy. He may not have meant to, but he said ruby herd specifically... on which Diego does a lot of work.
[gentoo-dev] Re: Making systemd more accessible to normal users
Steven J. Long posted on Wed, 01 May 2013 19:52:03 +0100 as excerpted: Gentoo is about choice, which to me also means embrace diversitiy. If you want to keep living in your little world, fine, you can and you're very welcome, but also people who want to have fun with new stuff should get the same respect. You mean the respect you've shown me in this email, in my little world? *swoon* you hero. I give up trying to be polite in the face of such crap, it's more than I can stomach. Implementing new stuff also means making things easier, especially in the systemd case. LMAO. You go girl, strut that nonsense like it means something. No way, sunshine. [...] Or at very least be polite when someone queries it. Unfortunately, I believe the above demands a public post... The above is taking it too far. Please take a bit of time to cool off if you need it, then apologize, or if you choose not to do that, refrain from further posts to the list. (I don't necessarily agree with all he posted and in fact had some of the same questions you did about optional being made non-optional, but (despite the little world comment which I agree was going a bit far, but just because he did, you didn't have to go one worse) he wasn't getting personal to the degree you did above, and the elements of your reply above simply have no place on this list. If indeed it is more than you can stomach and you can't at least be polite and avoid going personal, you really do need to consider getting off the list. The list has been rather better lately as to their credit people /have/ been keeping it civil despite obviously strong disagreements. There's no place for this sort of personal name calling by analogy on this list now, and despite past history to the contrary, never was or at least never should have been. So if you insist on taking it to that level, do it elsewhere.) (Just to make clear I'm just a gentoo user and list participant too. I've no authority to kick you from the list, but I can make clear that as part of the gentoo community, /I/ don't like that behavior, and believe it far enough out of bounds to ask for an apology. What others with said authority do after that isn't up to me.) -- 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: Making systemd more accessible to normal users
On 01/05/13 10:11 PM, Duncan wrote as excerpted: Steven J. Long posted on Wed, 01 May 2013 19:52:03 +0100 as excerpted: Gentoo is about choice, which to me also means embrace diversitiy. If you want to keep living in your little world, fine, you can and you're very welcome, but also people who want to have fun with new stuff should get the same respect. You mean the respect you've shown me in this email, in my little world? *swoon* you hero. I give up trying to be polite in the face of such crap, it's more than I can stomach. Implementing new stuff also means making things easier, especially in the systemd case. LMAO. You go girl, strut that nonsense like it means something. No way, sunshine. [...] Or at very least be polite when someone queries it. Unfortunately, I believe the above demands a public post... The above is taking it too far. Please take a bit of time to cool off if you need it, then apologize, or if you choose not to do that, refrain from further posts to the list. Agreed in full. I was prepared to write a response, but this is far more eloquent than anything I could have written. I'll go one step further, and say that this is just an example of the toxic behavior that's been shown in the Gentoo community, in particular this mailing list. This complete lack of any semblance of empathy, even in some *Gentoo developers* is entirely unacceptable. Things like a bunch of crybabies, whinging threads, Avoid spreading FUD, Really, please stop spreading FUD. (from different people), Good arguments! As usual I'd say. (sarcasm), Just to annoy people who have successfully used..., ad nauseam are, at best, not remotely productive. Please, just consider for a second how your words will, or even /might/ be perceived by others. Even better: although it might seem beneath you, consider how you yourself might perceive them, were they to be said from someone else. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 01, 2013 at 03:13:54PM +0200, Pacho Ramos wrote: El mié, 01-05-2013 a las 13:00 +0200, Fabio Erculiani escribió: [...] The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. I am unable to find exact advantage of changing init system without rebooting :/, what is the advantage of booting with an init.d and shutting down with a different one? No, you don't boot with A and shutdown with B. B is loaded by the kernel at the next boot. Switching init system is the only way to roll out a migration path, among other things I already wrote about on the eselect-sysvinit bug. Ah! OK, I misunderstood the runtime sense, in that case looks interesting :D I still don't see the advantage of eselect-sysvinit over editing your boot loader configuration and changing the init= kcl option, as I said on the bug. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 01, 2013 at 11:14:28PM +0200, Fabio Erculiani wrote: On Wed, May 1, 2013 at 9:52 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 5/1/13 3:04 AM, Fabio Erculiani wrote: As far as I read the bug, Mike (vapier) is doing the right thing. Distros doing lots of custom changes can only add more chaos to the picture. We are a distribution, we have our own goals, thus we change the code to better integrate with our ecosystem. That's part of the game. If we don't want to do that, we shouldn't be running a distro in the first place. Have you reached out to relevant upstreams? If they refuse to make changes, that's a different story. So far I think it's reasonable to go to upstreams first. For just a symlink swap and some file moves? (re: sysvinit) We don't need to bless upstream first for such small changes. Like I've already said too, I don't see that we need to do this change. Systemd is called /usr/lib/systemd/systemd (it should be /lib/systemd/systemd), and sysvinit is called /sbin/init,, so I don't see the need for moving init around and creating all of these symlinks. I guess I'm not completely opposed to it, I just want you to convince me that doing it has value. Where I am now is I feel like it adds complexity for almost no gain. William signature.asc Description: Digital signature
[gentoo-dev] Re: RANT: Upgrade icu and KDE at once
Zac Medico posted on Wed, 01 May 2013 08:01:45 -0700 as excerpted: On 05/01/2013 07:46 AM, Mike Gilbert wrote: I think it is time to consider enabling [preserve-libs] by default. Hopefully any ABI bumps will be accompanied by a subslot / slot-operator migration at this point. Yeah, I'm pretty happy with the slot-operator adoption, so it feels like it's about time to enable preserve-libs by default in stable. I know that this feature has been questioned by some, especially by people involved with Paludis (which doesn't implement preserve-libs). Maybe it would be a good idea to get an opinion from the council on whether or not it should be enabled by default in stable portage. FWIW I've been running 2.2 (and won't touch paludis with a 3 metre pole) for some time, but turned preserved-libs off here because it simply complicates things for me. After some early issues with too much magic re preserved-libs (possibly long since fixed but I wouldn't know as I have the feature turned off), I originally would rather let the upgrades happen as they always did and simply run revdep-rebuild afterward, and preserved-libs interfered with that as the libs were still there so revdep-rebuild didn't find anything to rebuild. Of course with sub-slots doing it the 'correct' way revdep-rebuild isn't finding so much to rebuild anymore, anyway, so like most people I think, I'm a big subslots fan, but that doesn't mean I trust preserved- libs any more than I did. But I've no objection to preserved-libs becoming the default and while it's not for me personally, I'm cautiously in favor of the idea as a default, as long as it remains a togglable feature. While I /am/ cautiously in favor, I definitely believe running it by council is a good idea, as it should help put to bed any remaining controversy over the idea. Neither the formal speak now or forever hold your peace aspect nor the CYA and it's voted and settled now, don't reopen the topic unless there's GOOD reason a council blessing provides can be a bad thing. =:^) -- 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] [RFC] Shall econf append its arguments to end of ./configure invocation?
On Tuesday 30 April 2013 12:38:03 Ciaran McCreesh wrote: On Tue, 30 Apr 2013 15:25:08 +0200 Ulrich Mueller wrote: On Tue, 30 Apr 2013, Ulrich Mueller wrote: Below is a patch that brings the spec in line with common sense. And in fact, I wonder why we're even discussing the issue. Paludis was fixed already more than a year ago: http://git.exherbo.org/paludis/paludis.git/commit/?id=ad2ae2ba3b6fc8f1136 38a86de0e7d8a6a046091 We're discussing a matter of principle... we all get the principle. the only contribution you've made here is to waste everyone's time. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Handling of tests (was: GCC USE flag changes)
On Wednesday 01 May 2013 21:24:07 Kent Fredric wrote: please do not top post -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Making systemd more accessible to normal users
On 2 May 2013 15:18, William Hubbs willi...@gentoo.org wrote: Like I've already said too, I don't see that we need to do this change. Systemd is called /usr/lib/systemd/systemd (it should be /lib/systemd/systemd), and sysvinit is called /sbin/init,, so I don't see the need for moving init around and creating all of these symlinks. I guess I'm not completely opposed to it, I just want you to convince me that doing it has value. Where I am now is I feel like it adds complexity for almost no gain. William The best arguments I have for the symlink approach, are: - its a consistent approach that is bootloader agnostic - it doesn't require you to understand your bootloaders scripting system to add it to the init= line - its no brains required, and hard to mess up bootloader configuration under grub1 for instance, was quite straight-forward. Now with grub-2, its quite convoluted, for me at least. Its also sometimes a bit confusing if you need something other than /sbin/init as your init, because sometimes you need some pre-init stuff ( like genkernel does ), and you need some /other/ parameter other than init= so that the pre-init still runs and then passes over to init Having a symlink that will just do the right thing is helpful for these cases. Against, the symlink may introduce parts that are breakable, like if user messes up and places the destination of the symlink on a different partition ( shouldn't be a problem, but might be ), or if you're doing an initird that has init baked into it, you'd have to regenerate that initrd after changing the symlink ( I think, maybe not, its probably not even a problem, its just something I'd have to check ) And also, if for whatever reason systemd becomes unbootable it might be slightly hard to boot with the right init if you can't change kernel parameters during boot time. But noted, those last 2 against reasons are edge cases, where the arguments for it are majority cases, so collectively I'm still in favour of the eselect + symlinks approach. -- Kent
Re: [gentoo-dev] Re: Handling of tests (was: GCC USE flag changes)
On 2 May 2013 16:21, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 01 May 2013 21:24:07 Kent Fredric wrote: please do not top post -mike My apologies, Gmail has forced upon us this new message composer, and it sucks, it actively discourages bottom posting, and I'm stuck with it. I even complained to them about it during their transition/experimentation/beta period, and they made it adequately clear to me they don't give a shit about technical users, especially not technical users who participate in lengthy mailing lists :( I do try, but basically, I have to mentally remember to work around its banal annoying changes for each message :( -- Kent
Re: [gentoo-dev] Re: GCC USE flag changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/01/2013 03:00 AM, Diego Elio Pettenò wrote: On 01/05/2013 06:29, Rick Zero_Chaos Farina wrote: I don't mean to start a flamewar here but the test suite situation is so bad with circular deps (I'm looking at you ruby herd) and random failures that I only enable tests for my own packages. Sadly it is so bad that we have a FEATURES=test-fail-continue I can't really say anything negative, that fact really says it all... You might not mean to but honestly, do you really think that we have circular deps because we like them? FFS I've been the biggest user of FEATURES=test, and the one who poured in more time to get stuff to work, so please don't effing go around blaming people without even having a clue about what's going on, you just piss me off. I am sorry that I have offended you, but unfortunately this is what happens when I try to enable tests: http://dev.gentoo.org/~zerochaos/distfiles/ruby_test_deps.txt As you can see, enabling this by default in any profile would be rather crippling to gentoo as a whole. I am not blaming anyone, nor do I understand what has caused the current situation. What I do understand is that I am unable to run with FEATURES=test enabled by default despite having the desire to do so. I have the hardware to run automated test, I have the desire to run automated tests, the only thing I don't have is the time to sort out hundreds of circular deps in ruby. If it helps lower the tempers, I don't bitch about things I'm not willing to help fix. If someone from the ruby team wants to discuss this with me (on or off this list) I will be happy to listen to the problem and try to find a sane solution. Likely this will require changes to the dep structure or portage, but these subjects interest me very much and I feel it is well worth my time to help with this. You have two choices: 1.) Continue to curse me and we stay where we are 2.) accept the help offered Your call. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRgfJFAAoJEKXdFCfdEflKyYUP/R+GNFv9SC4NASSFAh8nSNBH MUG3+5k5UpI1AtbSyt1VdnQztgK5b4x9RmSard0PptlOgB0g/Nf24b6qbaT/SYFR DI8FmhQaZLmf4icw2/LjK6mO0r9gPfiB5Rm4LFmkHMJVDxd2HmkV4bMV2Y+zfoLZ A0SwK2Y3jMGjTmL4Eg/j3ExRVYDQP2Uo1uF56XU6+5pcn+gI4gA+dCB3Q7RDEqtM L8sds5WijA10Jd5q6QKSNnDQmv7jLioRqFuVupJ5QlieIdQCY0jaYEwlasTfGKKh FlxmSLF3Uw08tLDgMWXpjrRsnyzup9V/zNwQiMD6SOukTvqoQPJ1p+/5qrur+OVD /NjvdqXBk8kYjmhXVGdyOhVDgeEyknG/hqxgT/z7abNqIaYPufel8tV5+DQL28H+ 2FLU8DorMfXBzpYqPW/g55gSalOytR3jpVGPEthTt91b8YbbvOgdWkdIl0c8qmeV r7xrPhMQ6wZUX0hapcX3670sUYXeLjactYvJLj6WQyT+pIfnSTaI0QYjsDpnmOfy 0KPuw3MMjuSYdp0iIq8IxVRbUJ94sM9PqzoFVp8hXHFf80IWV7RaZBzABwzBY9fW eKlWTylRM7rw08SddHaU4lSiOhN3y9AtPV0NQSnxq5klT5IH8MSTwgB4t3oo5M7h xlkncCfm1vHt9kS3A5Qi =SO5/ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Handling of tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/01/2013 09:18 PM, Ryan Hill wrote:
On Wed, 1 May 2013 10:14:02 +0200
Ralph Sennhauser s...@gentoo.org wrote:
On Tue, 30 Apr 2013 21:25:40 -0600
Ryan Hill dirtye...@gentoo.org wrote:
I'm also going to rename the test flag to regression-test or
something similar to get it out of FEATURES=test control. The
testsuite is a huge time-suck and only useful to developers IMO
(always expected to fail and primarily meant to be used to check for
regressions between patchsets). I'm a big supporter of
FEATURES=test by default and I think this is a small step towards
that.
This step is so tiny that we wont ever reach the goal like this.
I was hoping it would set a precedent and then people would start thinking of
splitting up test into categories, maybe even start a thread about it ;).
Let's
start to properly classify test into categories, like for instance
- expected to be run (cheap, no silly deps)
- good thing if run (still reasonable wrt resources) (current src_test)
- if you are the maintainer or simply curious. (boost, jtreg and
friends)
Something like dev-test or qa-test? I can think of a couple packages..
... and improve on how to configure Portage whether to run tests of any
given category.
Yeah I'd love to be able to do something like emerge TESTS=dev qa
system -extradeps -expensive @world.
Honestly, IMHO, I think breaking it down to more than test and qa is
excessive. I certainly wouldn't block anyone that wishes to do that
work, but I think we all realize that enabling tests (and especially
some of the really awesome QA tests Diego does in the tinderbox) are
really expensive time wise. The average user should never have this
enabled, and honestly, most devs shouldn't have it enabled either as
they simply won't have the hardware to run the tests every time (I know
I've commited things from my chromebook without excessive testing...).
I have a little cron script that builds all the packages I'm marked
maintainer of every night with FEATURES=test and would be easy enough to
adapt to looking at herd instead of maintainer.
I don't claim to be the expert on testing, but in case anyone finds
something like this useful... here:
#!/bin/sh
emerge --sync -q
#maintainer check (excluding madwifi)
MAINTAINER_OF=$(fgrep 'zeroch...@gentoo.org'
/usr/portage/*/*/metadata.xml | cut -d/ -f4-5 | grep -v madwifi)
#build test
FEATURES=test emerge --deep --oneshot -q ${MAINTAINER_OF}
if [ $? -ne 0 ]; then
echo build failed, see above
fi
#repoman check
for atom in ${MAINTAINER_OF}; do
cd /usr/portage/${atom}
repoman -qd full /dev/null
if [ $? -ne 0 ]; then
repoman -qd full
fi
done
Thanks,
Zero
PS I welcome suggestions for this script, new functionality is always
welcome
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRgfRKAAoJEKXdFCfdEflKJPYP/2qUMB5T3KZ1jT2dusdgg3KA
yuPAc6xL9VNg25pnVYl14JoS66z1hKpisSCCZeeGT7uqRDEkh+jseEaZIOhrektb
Zgn3WXmekmU5pc9wicUW4aYVzNyc9PBbw2NcBWq1HwgfMcwBoX87FxVECw0L71dO
hNOWQbJ1amGGoLXiMmAI/S4CpkZcfX3WZv0R2oosKK/Iu34gZeHGk2w5ui4tuY6g
sZmKawjXTFzbluIcaZlUPyajBjyZEXx0Vsp3uYUY1lStUNG45q5jaz3/83V+NkF2
Lu0FHrXrSW97f19k2HkcTdl4icF48k6bmIbw22xZ1lII+rnV/3uqsok/UayRyF1c
w6EIFnS37M/MhDknJ9R65P18v/SWAP2MLnfhcIqFDWs6jXZqq8vpBOfW+waEWsKK
8qflxpU08joUBsUSBcz+Y8s6JBxbWVdlY+f+jLsP6kPUH5otHKym7vB2P0nqCGQQ
SayT8fpK5izX4UraNhpuOiDV8nH7cvD1h3t6MRlSzRshj7UWyw4nYIkhqFZJhFzW
g6hfmLUGqHeHxRKMyImVLY4+PST820s+5mTTG57YuXmzD/nYU9N2Yor61FtgLR26
975mApTT4cunHdiUudyGbeaE0j0f/wOe1CAivzTCmDi+tM4dYR78XscPRZCsrk2+
JeNw6XtA5A6jvVk12jYN
=+Zzv
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: GCC USE flag changes
On Thu, 2013-05-02 at 00:57 -0400, Rick Zero_Chaos Farina wrote: On 05/01/2013 03:00 AM, Diego Elio Pettenò wrote: On 01/05/2013 06:29, Rick Zero_Chaos Farina wrote: I don't mean to start a flamewar here but the test suite situation is so bad with circular deps (I'm looking at you ruby herd) and random failures that I only enable tests for my own packages. Sadly it is so bad that we have a FEATURES=test-fail-continue I can't really say anything negative, that fact really says it all... You might not mean to but honestly, do you really think that we have circular deps because we like them? FFS I've been the biggest user of FEATURES=test, and the one who poured in more time to get stuff to work, so please don't effing go around blaming people without even having a clue about what's going on, you just piss me off. I am sorry that I have offended you, but unfortunately this is what happens when I try to enable tests: http://dev.gentoo.org/~zerochaos/distfiles/ruby_test_deps.txt Note that these are not circular dependencies. dev-ruby/mocha should really be slotted now. This has been creeping up on us with versions initially looking to be upward compatible. I've put it on my todo list. I'll have a look at ruby_parser and sexp-processor as well. You have two choices: 1.) Continue to curse me and we stay where we are 2.) accept the help offered Fixing https://bugs.gentoo.org/show_bug.cgi?id=175808 would be useful (though it wouldn't help with this particular problem). Hans
Re: [gentoo-dev] Re: RANT: Upgrade icu and KDE at once
On Thu, 2 May 2013 03:38:24 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: After some early issues with too much magic re preserved-libs Why is it magic? It is well explained what it does (eg. man make.conf). I originally would rather let the upgrades happen as they always did and simply run revdep-rebuild afterward You know that if you enable preserve-libs that you have to instead run `emerge @preserved-rebuild`, which has a much shorter runtime. and preserved-libs interfered with that as the libs were still there so revdep-rebuild didn't find anything to rebuild. `emerge @preserved-rebuild` will find and rebuild them. -- 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] Making systemd more accessible to normal users
On Thu, May 2, 2013 at 5:26 AM, Kent Fredric kentfred...@gmail.com wrote: [snip] Against, the symlink may introduce parts that are breakable, like if user messes up and places the destination of the symlink on a different partition ( shouldn't be a problem, but might be ), or if you're doing an initird that has init baked into it, you'd have to regenerate that initrd after changing the symlink ( I think, maybe not, its probably not even a problem, its just something I'd have to check ) eselect-sysvinit handles symlink swapping among files in /sbin/init.d. So you cannot run into partitioning issues directly. And also, if for whatever reason systemd becomes unbootable it might be slightly hard to boot with the right init if you can't change kernel parameters during boot time. The same happens if you change the boot arguments and reboot. This is not something eselect-sysvinit is supposed to solve. But anyway, eselect-sysvinit is a marginal thing and can be supported by just providing a more experimental, perhaps masked, sysvinit ebuild. I am more concerned about the rest of the story. But noted, those last 2 against reasons are edge cases, where the arguments for it are majority cases, so collectively I'm still in favour of the eselect + symlinks approach. -- Kent -- Fabio Erculiani
[gentoo-portage-dev] portage 9999 at commit 2d5e38b495776e5bb2266848a3365667f3ca7233 **SLOW**
My typical emerge -upvDN world went up from 10s of minutes to several hours sometime between portage 37f33e9 and 2d5e38b. I noticed by way of strace(8) that it access(2)es each ebuild in /usr/portage on each configured overay 10 times. Each. It does so in order from the last overlay in PORTDIR_OVERLAY to the first. It is the whole cycle which repeats a total of 10 iterations. Seems it would be simpler to do the python equiv of ls */*/*.ebuild in each overlay's top dir, note what ebuilds exist in each overlay in a data structure, and use that. Portage shouldn't worry about any changes which occur in the middle of any single run. (Which is not to claim that it currently does, lest that sentence be misunderstood. :) Each access(2) is averaging about 300 or so micro seconds. So about 66 miliseconds per ebuild. There are 33728 ebuild files in /usr/portage, so that is about 2226 seconds. Or nearly 40 minutes just wasting time. I run it in script(1) these days; /usr/bin/time output for one run was: 4314.78user 305.06system 5:17:03elapsed 24%CPU (0avgtext+0avgdata 4977056maxresident)k 145208inputs+14296outputs (9major+34541240minor)pagefaults 0swaps So that is on the order of 20 times as long as it used to take. I looked at git log. The depgraph commit (62dbcaa4d873784f1) seems to be the only one in that range which could have an effect. At least at first glance. After doing the 7420160 access(2) calls, it read in some from a file (the descriptor was closed by the time a was able to run lsof(8) to see what fd 4 was), seek(2)ing between reads, and then seems to have started doing the 7420160 access(2) calls again. (!) As if once wasn't enough. :^/ No wonder the first run took 5+ hours. (I'm falling asleep at the kbd; I hope I didn't miss any needed edits above.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
