Re: [gentoo-dev] Make sound a global USE flag?
Le lundi 07 février 2011 à 08:36 +0100, Ulrich Mueller a écrit : It's used by several packages as a local flag, and its meaning seems to be similar enough. app-editors/emacs:sound - Enable sound app-editors/emacs-vcs:sound - Enable sound app-misc/anki:sound - Enable support for adding sound to cards games-arcade/tuxanci:sound - Enable sound games-board/pysolfc:sound - Enable sound support usingdev-python/pygame games-roguelike/angband:sound - Enable and install sounds games-rpg/eternal-lands-data:sound - Adds in-game sound effects. games-strategy/freeciv:sound - Add support for sound provided by media-libs/sdl-mixer gnome-extra/gnome-games:sound - Enable sound using media-libs/libcanberra media-libs/libcanberra:sound - Install x11-themes/sound-theme-freedesktop to get sounds on Gnome and Xfce. net-irc/xchat-gnome:sound - Enable sound event support with media-libs/libcanberra net-p2p/transmission:sound - Enable sound event support with media-libs/libcanberra xfce-base/xfce4-settings:sound - Enable sound event support with media-libs/libcanberra any gnome packages listed here is a bug if the only pulled dependency is libcanberra. The herd has a policy to always depend on libcanberra. It is a lightweight library that can be build with no sound output for those who don't like it and it saves needless USE flags. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
[gentoo-dev] Last rites: dev-php5/mongo
# Ole Markus With olemar...@gentoo.org (7 Feb 2011) # Masked for removal in 30 days. Replaced by dev-php5/pecl-mongo. dev-php5/mongo signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Removing profiles/use.local.desc file from CVS on 2011-02-11
Le dimanche 06 février 2011 à 23:52 -0600, Jeremy Olexa a écrit : As for the re-syncing all files thing - I can't reproduce that, though I've seen multiple reports. Did it settle down now? (I assume so) -Jeremy synced my laptop this morning around 11AM UTC and was hit by this mysterious resyncs whole tree problem. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Make sound a global USE flag?
On 02/07/2011 09:36 AM, Ulrich Mueller wrote: It's used by several packages as a local flag, and its meaning seems to be similar enough. app-editors/emacs:sound - Enable sound app-editors/emacs-vcs:sound - Enable sound app-misc/anki:sound - Enable support for adding sound to cards games-arcade/tuxanci:sound - Enable sound games-board/pysolfc:sound - Enable sound support usingdev-python/pygame games-roguelike/angband:sound - Enable and install sounds games-rpg/eternal-lands-data:sound - Adds in-game sound effects. games-strategy/freeciv:sound - Add support for sound provided by media-libs/sdl-mixer gnome-extra/gnome-games:sound - Enable sound using media-libs/libcanberra media-libs/libcanberra:sound - Install x11-themes/sound-theme-freedesktop to get sounds on Gnome and Xfce. net-irc/xchat-gnome:sound - Enable sound event support with media-libs/libcanberra net-p2p/transmission:sound - Enable sound event support with media-libs/libcanberra xfce-base/xfce4-settings:sound - Enable sound event support with media-libs/libcanberra +1 with exception that those using USE=sound for libcanberra should be split into it's own USE flag called USE=libcanberra and USE=sound should be kept for the generic ones I just added USE=sound to xfce4-settings only because other ebuilds (gnome ones) already did, wanted to use USE=libcanberra ...
Re: [gentoo-dev] Re: [gentoo-dev-announce] Removing profiles/use.local.desc file from CVS on 2011-02-11
On Mon, 07 Feb 2011 13:47:55 +0100 Gilles Dartiguelongue e...@gentoo.org wrote: Le dimanche 06 février 2011 à 23:52 -0600, Jeremy Olexa a écrit : As for the re-syncing all files thing - I can't reproduce that, though I've seen multiple reports. Did it settle down now? (I assume so) -Jeremy synced my laptop this morning around 11AM UTC and was hit by this mysterious resyncs whole tree problem. I'm still seeing this too on the _first_ sync on a system after the 4th of February. Subsequent syncs exhibit normal behavior and speed. It's basically a one-time-per-system thing, at least that's what I see. -- Best regards, Luca Longinotti aka chtekk. LongiTEKK Networks Admin: cht...@longitekk.com TILUG Member: cht...@tilug.ch
[gentoo-dev] avoiding urgent stabilizations
From time to time there are stabilization bugs where the current stable is broken. For example, https://bugs.gentoo.org/show_bug.cgi?id=353487 However, in theory that should not happen, because presumably the current stable has been tested in the past and considered not broken. Of course that would be rather idealistic to assume such situation will never happen, but can we do something more to avoid detecting important problems in the stable tree too late? Are we missing something when stabilizing some important packages that later causes the breakages and need for urgent stabilizations? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] avoiding urgent stabilizations
On 02/07/2011 06:19 PM, Paweł Hajdan, Jr. wrote: From time to time there are stabilization bugs where the current stable is broken. For example, https://bugs.gentoo.org/show_bug.cgi?id=353487 However, in theory that should not happen, because presumably the current stable has been tested in the past and considered not broken. In this case, xdm has been broken for more than a year because it has been ignoring pambase by not using system-local-login. Only the problem came to light after ConsoleKit really started to require this functionality from pambase. Tricky... But it was still tested, unfortunately the test environment that was used leaked some environment variables that made XDM appear to work, so this was catched too late. Sorry. - Samuli
Re: [gentoo-dev] avoiding urgent stabilizations
El lun, 07-02-2011 a las 18:43 +0200, Samuli Suominen escribió: On 02/07/2011 06:19 PM, Paweł Hajdan, Jr. wrote: From time to time there are stabilization bugs where the current stable is broken. For example, https://bugs.gentoo.org/show_bug.cgi?id=353487 However, in theory that should not happen, because presumably the current stable has been tested in the past and considered not broken. In this case, xdm has been broken for more than a year because it has been ignoring pambase by not using system-local-login. Only the problem came to light after ConsoleKit really started to require this functionality from pambase. Tricky... But it was still tested, unfortunately the test environment that was used leaked some environment variables that made XDM appear to work, so this was catched too late. Sorry. - Samuli I think that maybe we could have an even higher priority field called, for example, Broken Stable that should be *only* used for that cases and that arch teams should try fix sooner. What do you think? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] avoiding urgent stabilizations
We've been discussing this @FOSDEM too. My suggestion was that any bug that visibly hurts stable users should always be considered at least MAJOR in bugzilla. To expand on this a bit more * a stable update that makes the computer nonfunctional is definitely BLOCKER (and should be reverted in CVS immediately when it becomes known, at latest when it is understood, by anyone who is around at the time and can do so) * a non-functional stable package in the system set should be CRITICAL. Just my 2ct, but it is really important not to hurt stable users. This is how we lose most people. I think that maybe we could have an even higher priority field called, for example, Broken Stable that should be *only* used for that cases and that arch teams should try fix sooner. What do you think? -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Make sound a global USE flag?
On 02/07/2011 03:15 PM, Samuli Suominen wrote: +1 with exception that those using USE=sound for libcanberra should be split into it's own USE flag called USE=libcanberra and USE=sound should be kept for the generic ones libcanberra describes the means and not the results so we should try to come up with something else. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Make sound a global USE flag?
On 02/07/2011 07:55 PM, Petteri Räty wrote: On 02/07/2011 03:15 PM, Samuli Suominen wrote: +1 with exception that those using USE=sound for libcanberra should be split into it's own USE flag called USE=libcanberra and USE=sound should be kept for the generic ones libcanberra describes the means and not the results so we should try to come up with something else. Regards, Petteri The means are commonly used as USE flag names with result in USE flag description. Think of gstreamer, or xine for example. But I'm open to suggestions... Unlike GNOME we have no plans in making libcanberra mandatory for xfce4-settings as it pulls in too much bloat (like gconfd which Xfce doesn't use).
Re: [gentoo-dev] Make sound a global USE flag?
On 02/07/2011 08:08 PM, Samuli Suominen wrote: On 02/07/2011 07:55 PM, Petteri Räty wrote: On 02/07/2011 03:15 PM, Samuli Suominen wrote: +1 with exception that those using USE=sound for libcanberra should be split into it's own USE flag called USE=libcanberra and USE=sound should be kept for the generic ones libcanberra describes the means and not the results so we should try to come up with something else. Regards, Petteri The means are commonly used as USE flag names with result in USE flag description. Think of gstreamer, or xine for example. But I'm open to suggestions... How about event-sounds? libcanberra is an implementation of the XDG Sound Theme and Name Specifications, for generating event sounds on free desktops, such as GNOME. http://0pointer.de/lennart/projects/libcanberra/#overview Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please review: updates for bzr.eclass
UM == Ulrich Mueller u...@gentoo.org writes:
UM 1) initial branch with bzr branch --no-tree,
UM 2) subsequent updates with bzr pull,
UM 3) export to ${WORKDIR} with bzr export.
I applaud those changes, but please mv(1) old repos rather than rm(1)ing
them; bandwidth is often more of a premium than storage and a manual
cleanup is better than a magic behind-the-back permanent deletion. This
follows the same principles as portage does in $DISTFILES.
Thank you.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] avoiding urgent stabilizations
On Mon, Feb 07, 2011 at 06:45:10PM +0100, Andreas K. Huettel wrote: We've been discussing this @FOSDEM too. My suggestion was that any bug that visibly hurts stable users should always be considered at least MAJOR in bugzilla. To expand on this a bit more * a stable update that makes the computer nonfunctional is definitely BLOCKER (and should be reverted in CVS immediately when it becomes known, at latest when it is understood, by anyone who is around at the time and can do so) * a non-functional stable package in the system set should be CRITICAL. Just my 2ct, but it is really important not to hurt stable users. This is how we lose most people. The rolling way we stabilize the packages makes the stable tree pretty much fragile to breakages and stuff. This is because you cannot predict what is going to happen to the rest of the tree if you stabilize a newer package. It may have unpredictable consequences to the rest of the packages. My suggestion, as I said to fosdem, is to freeze, or take a snapshot if you like, of the current tree, stabilize what you need to stabilize, test the whole tree ( at least compile wise ) for a couple of weeks and then replace the existing stable tree. Of course this requires automated script testing, hardware facilities etc etc that we don't have so claiming that stable tree is stable is quite wrong. Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgpF2aIntpgO2.pgp Description: PGP signature
Re: [gentoo-dev] avoiding urgent stabilizations
On 2/7/11 9:50 PM, Markos Chandras wrote: My suggestion, as I said to fosdem, is to freeze, or take a snapshot if you like, of the current tree, stabilize what you need to stabilize, test the whole tree ( at least compile wise ) for a couple of weeks and then replace the existing stable tree. Of course this requires automated script testing, hardware facilities etc etc that we don't have so claiming that stable tree is stable is quite wrong. This more thorough testing sounds really interesting. But do we really lack hardware resources? There are machines available for various arches at http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml. I have at least a few chromium-related chroots on miranda, and I've never heard complaints, so it seems a few more chroots for arch testing wouldn't hurt. Of course for testing bootability and whether X11 starts up correctly, etc we'd probably have to host some virtual machines, but better compile testing (for example for toolchain updates) would be a good start. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please review: updates for bzr.eclass
On Mon, 07 Feb 2011, James Cloos wrote:
UM 1) initial branch with bzr branch --no-tree,
UM 2) subsequent updates with bzr pull,
UM 3) export to ${WORKDIR} with bzr export.
I applaud those changes,
Thanks. :)
but please mv(1) old repos rather than rm(1)ing them; bandwidth is
often more of a premium than storage and a manual cleanup is better
than a magic behind-the-back permanent deletion. This follows the
same principles as portage does in $DISTFILES.
Is the following better?
https://overlays.gentoo.org/proj/emacs/changeset?reponame=new=1609%40emacs-overlay%2Feclass%2Fbzr.eclassold=1608%40emacs-overlay%2Feclass%2Fbzr.eclass
Ulrich
[gentoo-dev] Re: [gentoo-dev-announce] Removing profiles/use.local.desc file from CVS on 2011-02-11
On Mon, 7 Feb 2011 16:09:30 +0100 Luca Longinotti cht...@longitekk.com wrote: On Mon, 07 Feb 2011 13:47:55 +0100 Gilles Dartiguelongue e...@gentoo.org wrote: Le dimanche 06 février 2011 à 23:52 -0600, Jeremy Olexa a écrit : As for the re-syncing all files thing - I can't reproduce that, though I've seen multiple reports. Did it settle down now? (I assume so) -Jeremy synced my laptop this morning around 11AM UTC and was hit by this mysterious resyncs whole tree problem. I'm still seeing this too on the _first_ sync on a system after the 4th of February. Subsequent syncs exhibit normal behavior and speed. It's basically a one-time-per-system thing, at least that's what I see. Every sync I've done on my laptop so far has done a full sync. Last one was two minutes ago. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] automated testing framework for Gentoo on Supercell at the OSL
Hi all, Is anyone interested in getting some type of automated Gentoo testing framework setup on the new Supercell infrastructure [1] at the OSUOSL? In a nutshell, Supercell allows projects to spin up their own VMs on demand using Ganeti Web Manager [2]. For those who don't know, a lot of infrastructure at the OSL runs on Gentoo (including Supercell) and there are two Gentoo devs working full-time for the OSL so I think we have a good chance of getting access to some of Supercell's resources if we can come up with a decent proposal and submit a feedback form [3]. Tim [1] http://supercell.osuosl.org/ [2] http://code.osuosl.org/projects/ganeti-webmgr [3] http://supercell.osuosl.org/feedback
[gentoo-dev] Re: avoiding urgent stabilizations
Paweł Hajdan, Jr. posted on Mon, 07 Feb 2011 22:02:36 +0100 as excerpted: On 2/7/11 9:50 PM, Markos Chandras wrote: My suggestion, as I said to fosdem, is to freeze, or take a snapshot if you like, of the current tree, stabilize what you need to stabilize, test the whole tree ( at least compile wise ) for a couple of weeks and then replace the existing stable tree. Of course this requires automated script testing, hardware facilities etc etc that we don't have so claiming that stable tree is stable is quite wrong. This more thorough testing sounds really interesting. But do we really lack hardware resources? Disclaimer: I run ~arch (plus choice unmasks/overlays where ~arch is already unsuitably outdated for my tastes), so this doesn't affect me regardless. That said... The above suggestion sounds to me like increasing the bureaucracy and hassle of stabilizing packages even more. We already have trouble with outdated stable, especially on some archs. Do we /really/ want the reputation of competing with Debian-stal^hble for staleness? Every few years someone comes up with the idea of creating a /truly/ stable, aka enterprise keyword/branch/whatever. Every few years, it doesn't happen, for both resource and (arguably) philosophical reasons. IMO, that's simply not suitable for or compatible with mainline Gentoo and its rolling updates, etc. Yes, it's possible to do it. A lot of things are possible, but that doesn't mean they're practical. It's Gentoo, Jim, but not as we know it! As such, if someone/somegroup does decide to go that route, IMO the best approach would be a separate Gentoo-based distribution, where freezing and testing an entire tree for self-consistency and compatibility makes a bit more sense. There are already a number of Gentoo-based distributions out there. Certainly, talking to them about the problems they face and the solutions they use, if not using one of them directly, could be a good place to start. Similarly, just as Gentoo has never made any bones about not being a hand- holding distribution, in many cases, you break, you get to keep the pieces (tho users and devs do try to help and devs do try to prevent, where it's sane to do so), and it's not uncommon to see people saying that if the install speed of a binary distribution or the centrally controlled decisions of an Ubuntu are what one is after, Gentoo isn't really where you should be looking, I'd say the same applies, to some degree, here. Yes, we can try to keep stable breakage to a minimum, but on a rolling release system, it's /going/ to happen, and I'd argue that the sort of wholesale freeze-and-test discussed above really /would/ be Gentoo, Jim, but not as we know it, were it to be implemented as such in Gentoo. That's not what Gentoo is /about/. The rolling updates are so much a part of what makes Gentoo /Gentoo/, that take them out, as wholesale freeze and test would effectively do, and you no longer have Gentoo, at least as historically known. That being the case, why confuse people about both the new product and Gentoo as it currently is, by calling the new product Gentoo at all? If it's effectively a Gentoo-based distribution that isn't itself Gentoo, at least as historically considered, call it a Gentoo based distribution. Don't call it Gentoo, thus avoiding the confusion on both sides. JMHO, but I've been around long enough to have seen this discussion cycle at least twice before... Unfortunately, the result is often the loss of a few devs. OTOH, if their goal is to make Gentoo a wholesale freeze and test distribution, perhaps it's better for both them and Gentoo that such efforts get applied somewhere more appropriate to that goal. OTOH, if some big name comes up with suitable big resources to devote to such a project and they like the Gentoo name, perhaps a Gentoo-Enterprise might indeed be practical. But the resource scaling that's going to require is enough beyond what we're doing today that I'd think seeing someone step up with an offer of such resources before we start seriously discussing it, is a worthwhile prerequisite. And even then, making Gentoo that dependent on that sort of major sponsorship, regardless of who or what form, would change the historically community distribution aspect substantially enough that arguably, that would be Gentoo, Jim, but not as we know it, as well. But at that point I guess it'd be a question for the Gentoo foundation to decide, since they own the name and decide permissions for it in that regard. -- 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
