[gentoo-dev] Re: RFC: virtual/libudev
Ben de Groot posted on Wed, 11 Jul 2012 12:51:50 +0800 as excerpted: > When upstream moved the udev sources to the systemd repo, they promised > that udev would continue to be able to be used separately from systemd. > We should hold them to that promise. > > If they break their promise (as it seems they are bent on doing), then > we should go ahead with the fork as discussed earlier. I'm sure other > distros such as Debian and Slackware would be happy to join us in that > effort. Given the size of debian, I'd guess we'd likely be joining them, rather than the other way around, tho slack would I'd guess be joining us... Regardless, I agree with the point, and yes, debian at least will certainly be doing something as they have non-linux to worry about too, tho OTOH they move slow enough they might indeed be joining us, size or no size. -- 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: virtual/libudev
On 11 July 2012 03:23, Thomas Sachau wrote: > Michał Górny schrieb: >> Hello, all. >> >> Since nowadays udev is bundled within systemd, we start having two >> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making >> the long story short, I would like to introduce a virtual for libudev >> which would pull in either of those two. >> [...] >> What are you thoughts? > > As discussed on IRC, there is still no consensus for installing the udev > files with systemd, which is the beginning for the block and the > virtual. So we should first sort that point out, before we even start to > think about an ebuild for an udev virtual. > > So for now: A clear no, i am against adding a virtual/libudev ebuild. Me too. When upstream moved the udev sources to the systemd repo, they promised that udev would continue to be able to be used separately from systemd. We should hold them to that promise. If they break their promise (as it seems they are bent on doing), then we should go ahead with the fork as discussed earlier. I'm sure other distros such as Debian and Slackware would be happy to join us in that effort. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] rfc: old udev versions
On 11 July 2012 02:30, William Hubbs wrote: > All, > > the last thread started by mgorny has prompted me to ask here on the > list which versions of udev we really need in the tree. Personally, I'm holding on to 171. I have masked >=181 because of bad decisions upstream and I want to see how the situation will stabilize. Since 171 is the latest stable, I would think most of our users are on this version anyway. Since upstream seems to be unwilling to work with us, I think we should seriously consider doing a fork. I know there are other distros like Debian and Slackware who would be happy to join us in that effort. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] More packages looking for new maintainers
On Sun, Jul 8, 2012 at 12:14 PM, Diego Elio Pettenò wrote: > Just a few more packages that I'm no longer using or for which I no > longer have hardware or so on so forth. Yes I'm still cleaning this > stuff up. > > Notes in brackets below a list. > * indicates a dependency of the described package; > + indicates there is another maintainer/herd for it anyway. > sys-power/apcupsd + I can take apcupsd if the base-system herd doesn't want it all for itself :)
Re: [gentoo-dev] rfc: old udev versions
> I've looked at the kernel packages we have in /usr/portage, but have no > guide there either. If I go by gentoo-sources, I could get rid of all > but very recent versions of udev, but I have heard some things also > about people using older kernels. Also, vanilla-sources goes all the way > back to 2.6.16 (I have no idea why)? > I think, at the very least, we want to support kernel 2.6.32 or later via whatever methods are required in Gentoo to allow those existing systems to keep running and recompile as needed. 2.6.32 is used by a number of mainstream distributions as a long term stable release. And, cautious admins migrating to Gentoo or supporting the same apps on multiple distributions may want to continue to stick with that kernel release for awhile. I'm also aware that 2.6.36 was widely deployed for gentoo servers around here, although some of those systems have started to migrate to 3.2.I'm not sure how much of a need there would be for anything older than 2.6.32. 2.6.32 would seem to be a reasonable cutoff. As for udev specifically, 171 is what is deployed on most boxes here to avoid any possible need for an initrd or other possible bugs with newer releases... Reading the udev-171 ebuild, it appears it supports >2.6.16 so I'm not sure if there is any need for udev versions earlier than 171.
Re: [gentoo-dev] rfc: old udev versions
> I've looked at the kernel packages we have in /usr/portage, but have no > guide there either. If I go by gentoo-sources, I could get rid of all > but very recent versions of udev, but I have heard some things also > about people using older kernels. Also, vanilla-sources goes all the way > back to 2.6.16 (I have no idea why)? Well just for the record my vserver (xen domU) hoster is still going strong with 2.6.30 ... I'm trying to get that changed but with 10€/month I'm probably not the strongest financial incentive... a pity because otherwise I'm really very happy with the company... -a -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] RFC: virtual/libudev
On Tue, Jul 10, 2012 at 05:18:00PM +0200, Michał Górny wrote: > Hello, all. > > Since nowadays udev is bundled within systemd, we start having two > libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making > the long story short, I would like to introduce a virtual for libudev > which would pull in either of those two. > > There are three USE flags used in conditionals when depending on udev: > - gudev - for glib wrapper on udev, > - hwdb - to pull in hwids, > - static-libs. > > The former two were previously provided by 'extras' USE flag, > and the third was unconditional. > > I'm attaching an example virtual/libudev which does the job. Sadly, > because of the 'extras' compatibility it's a big ugly conditional. I'm going to ask here, because of the discussion on IRC, that you not commit this yet. There are issues still we need to work out wrt packaging systemd and udev. William pgpCws1oiVjUh.pgp Description: PGP signature
Re: [gentoo-dev] RFC: virtual/libudev
Michał Górny schrieb: > Hello, all. > > Since nowadays udev is bundled within systemd, we start having two > libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making > the long story short, I would like to introduce a virtual for libudev > which would pull in either of those two. > > There are three USE flags used in conditionals when depending on udev: > - gudev - for glib wrapper on udev, > - hwdb - to pull in hwids, > - static-libs. > > The former two were previously provided by 'extras' USE flag, > and the third was unconditional. > > I'm attaching an example virtual/libudev which does the job. Sadly, > because of the 'extras' compatibility it's a big ugly conditional. > > An alternative would be to provide separate virtual/libudev > and virtual/libgudev; and maybe changing ebuilds not to depend on > [hwids] but rather pull in sys-apps/hwids directly (since that's what > the flag does). > > What are you thoughts? > As discussed on IRC, there is still no consensus for installing the udev files with systemd, which is the beginning for the block and the virtual. So we should first sort that point out, before we even start to think about an ebuild for an udev virtual. So for now: A clear no, i am against adding a virtual/libudev ebuild. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] rfc: old udev versions
All, the last thread started by mgorny has prompted me to ask here on the list which versions of udev we really need in the tree. I know that all versions before 133 must go because openrc has a requirement for at least that version. I've looked at the kernel packages we have in /usr/portage, but have no guide there either. If I go by gentoo-sources, I could get rid of all but very recent versions of udev, but I have heard some things also about people using older kernels. Also, vanilla-sources goes all the way back to 2.6.16 (I have no idea why)? Any thoughts would be helpful. Thanks, William pgpCF1apq2yMO.pgp Description: PGP signature
Re: [gentoo-dev] RFC: virtual/libudev
On Tue, Jul 10, 2012 at 07:57:50PM +0200, Michał Górny wrote: > On Tue, 10 Jul 2012 12:54:31 -0400 > Alexis Ballier wrote: > > > On Tue, 10 Jul 2012 17:18:00 +0200 > > Michał Górny wrote: > > > > > The former two were previously provided by 'extras' USE flag, > > > and the third was unconditional. > > > > since udev-171 seems to be going stable, why not simply drop the > > 'extras' compatibility ? > > then you could just use 'gudev?' usedeps it seems > > I heard that people are still bound to old udev versions because of > kernel requirements introduced by newer ones. The eventual plan is to kill off the extras use flag in favor of the others. It is only there to allow packages that depended on udev[extras] to be moved to depend on the correct use flag, so I think we should be able to kill it at some point. I just haven't looked into doing that. William pgpmzWHl1WZae.pgp Description: PGP signature
Re: [gentoo-dev] RFC: virtual/libudev
On Tue, 10 Jul 2012 12:54:31 -0400 Alexis Ballier wrote: > On Tue, 10 Jul 2012 17:18:00 +0200 > Michał Górny wrote: > > > The former two were previously provided by 'extras' USE flag, > > and the third was unconditional. > > since udev-171 seems to be going stable, why not simply drop the > 'extras' compatibility ? > then you could just use 'gudev?' usedeps it seems I heard that people are still bound to old udev versions because of kernel requirements introduced by newer ones. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: virtual/libudev
On Tue, 10 Jul 2012 17:18:00 +0200 Michał Górny wrote: > The former two were previously provided by 'extras' USE flag, > and the third was unconditional. since udev-171 seems to be going stable, why not simply drop the 'extras' compatibility ? then you could just use 'gudev?' usedeps it seems A.
Re: [gentoo-dev] inittab with SIGPWR support
Il 10/07/2012 18:44, James Cloos ha scritto: > I'm embarrased to have to say that I hadn't noticed that gentoo lacked power > lines in its inittab(5). They _are_ deprecated after all. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] inittab with SIGPWR support
> "DEP" == Diego Elio Pettenò writes: DEP> To have a better support for Gentoo lxc guests, it would be nice if our DEP> default inittab contained a line for handling SIGPWR sent to PID 1 to DEP> shut the system down. I'm embarrased to have to say that I hadn't noticed that gentoo lacked power lines in its inittab(5). Please cover the set, not just powerfail. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] RFC: virtual/libudev
Hello, all. Since nowadays udev is bundled within systemd, we start having two libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making the long story short, I would like to introduce a virtual for libudev which would pull in either of those two. There are three USE flags used in conditionals when depending on udev: - gudev - for glib wrapper on udev, - hwdb - to pull in hwids, - static-libs. The former two were previously provided by 'extras' USE flag, and the third was unconditional. I'm attaching an example virtual/libudev which does the job. Sadly, because of the 'extras' compatibility it's a big ugly conditional. An alternative would be to provide separate virtual/libudev and virtual/libgudev; and maybe changing ebuilds not to depend on [hwids] but rather pull in sys-apps/hwids directly (since that's what the flag does). What are you thoughts? -- Best regards, Michał Górny # Copyright 1999-2012 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ EAPI=4 DESCRIPTION="Virtual for libudev providers" HOMEPAGE="" SRC_URI="" LICENSE="" SLOT="0" KEYWORDS="alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~x86-linux" IUSE="gudev hwdb static-libs" RDEPEND=" gudev? ( hwdb? ( || ( >=sys-fs/udev-171[gudev,hwdb,static-libs(+)?] =sys-apps/systemd-185[gudev,static-libs(+)?] ) ) !hwdb? ( || ( >=sys-fs/udev-171[gudev,static-libs(+)?] =sys-apps/systemd-185[gudev,static-libs(+)?] ) ) ) !gudev? ( hwdb? ( || ( >=sys-fs/udev-171[hwdb,static-libs(+)?] =sys-apps/systemd-185[static-libs(+)?] ) ) !hwdb? ( || ( sys-fs/udev[static-libs(+)?] >=sys-apps/systemd-185[static-libs(+)?] ) ) )" signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Output / End User Experience
On Tue, Jul 10, 2012 at 7:18 AM, Rich Freeman wrote: > On Tue, Jul 10, 2012 at 3:25 AM, Ben de Groot wrote: >> On 10 July 2012 11:03, Rich Freeman wrote: >> >> You keep saying that, but do you have any actual data to back up >> that claim? There is no doubt that Chromium is a mainstream and >> popular package, but I doubt if it is quite *that* popular as you >> make it seem. > > See http://en.wikipedia.org/wiki/Usage_share_of_web_browsers . > > Seems like most of those collecting data estimate Chrome use at 33% > market share. Of course, that is across all OSes, and IE has another > 33%. I doubt that 33% of Gentoo users are using IE. > > Until we have statistics collection with a substantial number of > participants we'll never really know for sure. Some ideas for reasonable statistic gathering: * What's the user agent distribution for accessing bugs.gentoo.org? * Which distfiles have been retrieved from mirrors most frequently? UA stats from bugs.gentoo.org would be nicely biased towards Gentoo users. As for distfile retrieval logs, you don't need data from all of the mirrors, just the top 10% or so would likely be statistically sufficient, even if you only have the HTTP retrievals, not the FTP retrievals. [snip the rest; I don't have a position or the expertise for preferring any of the suggested technical solutions...] -- :wq
Re: [gentoo-dev] Portage Output / End User Experience
On Tue, Jul 10, 2012 at 3:25 AM, Ben de Groot wrote: > On 10 July 2012 11:03, Rich Freeman wrote: > > You keep saying that, but do you have any actual data to back up > that claim? There is no doubt that Chromium is a mainstream and > popular package, but I doubt if it is quite *that* popular as you > make it seem. See http://en.wikipedia.org/wiki/Usage_share_of_web_browsers . Seems like most of those collecting data estimate Chrome use at 33% market share. Of course, that is across all OSes, and IE has another 33%. I doubt that 33% of Gentoo users are using IE. Until we have statistics collection with a substantial number of participants we'll never really know for sure. > To make a better informed decision, it would be really helpful > to have some numbers of users who have both qt-webkit and > chromium, and those who have qt-webkit but not chromium. Certainly agree with that, but it will be ages before we ever have those kinds of stats. It doesn't appear that we have any working stats collections at the moment (though it seems like an annual GSoC project). > > We all want to improve the user experience. I'm just not convinced > that enabling icu by default, and letting the users deal with the > fallout, is the best way of doing that. Well, I'll agree that finding some way to make it more clear to the user what the compromise is would be better. The problem is that we just don't have any mechanism to do this right now. We could send out news, but that wouldn't make things clearer to new users. We could put it in the handbook, but do we really want these kinds of details there? It seems like portage improvements are the only long-term solutions. Two are necessary in this case (and one likely involves PMS as well): 1. Detection of complementary use deps like these and showing the user the minimum number of changes needed to resolve them all, perhaps with a few alternatives. These could include unselecting packages, or changing their flags/keywords. 2. The ability to trigger package rebuilds when another package changes in certain ways, despite there being no clear link breakage. I believe this was the topic of a lengthy thread and my intent is not to restart it here. There are two weaker substitutes for #1: a. Improve the blocker warning for the !use? case (or its long form), to indicate both ways to resolve the block. I would think that would be a fairly easy change. It won't give the complete solution, but the error messages would contain more of the info to work things out. b. Some kind of hinting system for users might be an option instead. Maybe define some way to include instructions in an ebuild when a particular block is an issue, conditional upon other packages. So, if a user goes to emerge either package and the other is installed/selected, then both packages could display the text "If you want to install both chromium and qt-webkit you need to set USE=icu for qt-webkit and libxml2, and stick a note on your monitor to manually re-install qt anytime icu changes until we fix this mess." I would encourage us to continue to coordinate icu and qt upgrades and continue to send out notices to users every time they need to rebuild qt-core (not that we sent out a notice the first time), until some portage mechanism for doing this exists. The bug isn't really fixed - it just affects fewer people. I'm not sure if we can somehow force qt to link to icu even though it isn't needed just so that revdep-rebuild can detect the breakage (I have no idea what happens when you try to dynamically load an already-linked library). Users who run Gentoo don't mind the odd intervention to keep things moving. However, the problem is that sometimes things break and it is not at all obvious how to resolve them. When error messages occur in some other piece of software it is not clear what needs to be rebuilt, especially when the package isn't linked in. It really isn't ideal to have to hunt in forums or bugzilla to figure out what is going on. Rich
Re: [gentoo-dev] Portage Output / End User Experience
On 10 July 2012 11:03, Rich Freeman wrote: > Yup, this issue hit anybody who has qt-webkit and chromium installed. > > I wouldn't be surprised if that is half of the entire userbase. I would be. > We ran into another confusing icu-related issue with qt-core a few > weeks ago (bug 413541). I can understand that the qt maintainers want > to get away from enabling icu for this reason, but chromium is a VERY > popular package so it is really only disabled in the sense that it > annoys a bazillion people who have to un-disable it and then still run > into the problems. You keep saying that, but do you have any actual data to back up that claim? There is no doubt that Chromium is a mainstream and popular package, but I doubt if it is quite *that* popular as you make it seem. > Better portage logic might help here, but I think we need to consider > whether a non-optimal decision from a single package perspective is > going to lead to a better overall experience for our userbase. Zac > suggested adding icu to the profile, which would work, though really > just adding it as the default for these two packages would really > address the issue until portage can catch up. > > Those who REALLY don't want icu support in qt-webkit can always > disable it manually now that the flag is there. If there is a fear > that this default will lead to more bugs, those bugs will happen > anyway, since anybody running chromium has to enable that flag. But for all we know, that is a minority of our users. To make a better informed decision, it would be really helpful to have some numbers of users who have both qt-webkit and chromium, and those who have qt-webkit but not chromium. We all want to improve the user experience. I'm just not convinced that enabling icu by default, and letting the users deal with the fallout, is the best way of doing that. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Portage Output / End User Experience
On 10 July 2012 09:41, Zac Medico wrote: > On 07/09/2012 06:11 PM, Rich Freeman wrote: >> So, seems like there is still room for improvement... > > Aside from the obvious need to improve the portage behavior, we might > also want to consider enabling USE=icu by default in the profile. Enabling icu causes problems such as bug #413541. See also https://bugs.gentoo.org/show_bug.cgi?id=425016#c5 Until the problems with icu are resolved, we (the Qt maintainers) are opposed to enabling that useflag by default in profiles. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
