Re: [gentoo-dev] Make sound a global USE flag?
On Mon, 07 Feb 2011, 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 That would be the following packages, as far as I can see: gnome-extra/gnome-games:sound - Enable sound using media-libs/libcanberra 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 I've opened bug 354585 for them. Ulrich
Re: [gentoo-dev] Gentoo Installer (text-based)
On Thu, 10 Feb 2011, Donnie Berkholz wrote: On 21:18 Wed 09 Feb , Fabian Groffen wrote: This is a post-FOSDEM call for people with interest for a Gentoo text-based installer. If you are a developer, or Gentoo user, and feel like spending some time on (possibly) creating a text-based installer for Gentoo in cooperation with others, please contact me (off-list). Like http://agaffney.org/quickstart.php ? We mentioned quickstart on FOSDEM and getting boxes installed up to stage4 so they have all the software one wants to get them into production. Fabian, is your thread about this or about something else? Regards, Jorge Manuel B. S. Vicetto
Re: [gentoo-dev] Gentoo Installer (text-based)
On 12-02-2011 11:47:09 +, Jorge Manuel B. S. Vicetto wrote: Like http://agaffney.org/quickstart.php ? We mentioned quickstart on FOSDEM and getting boxes installed up to stage4 so they have all the software one wants to get them into production. Fabian, is your thread about this or about something else? It doesn't ring a bell to me, so I think it is about something else. Anyway, I think enough people have responded to my call for help now. Thanks to all who considered. I carried over the idea/project to other devs now, that will implement it and announce as they see fit. -- Fabian Groffen Gentoo on a different level
[gentoo-dev] Lastrite: sys-apps/halevt
# Samuli Suominen ssuomi...@gentoo.org (12 Feb 2011) # Masked for removal. # Replaced by udisks-glue, udiskie, uam or traydevice. # You have 60 days left to migrate your configuration. dev-libs/boolstuff sys-apps/halevt There would also be: http://dev.gentoo.org/~ssuominen/uevt-2.1.ebuild But it fails to compile against libnotify-0.7 because of vala:0.10 right now. And fails to build against :0.12 slot that would propably solve the libnotify issue. If you want to take a stab at it, it's all yours. Then there is: http://igurublog.wordpress.com/downloads/script-devmon/ But I haven't tried it yet, and it's just a script... Not sure if it's worth of packaging. Either way, both are up for grabs if you used halevt before. - Samuli
Re: [gentoo-dev] Lastrite: sys-apps/halevt
On 02/12/2011 05:58 PM, Samuli Suominen wrote: # Samuli Suominen ssuomi...@gentoo.org (12 Feb 2011) # Masked for removal. # Replaced by udisks-glue, udiskie, uam or traydevice. # You have 60 days left to migrate your configuration. dev-libs/boolstuff sys-apps/halevt There would also be: http://dev.gentoo.org/~ssuominen/uevt-2.1.ebuild But it fails to compile against libnotify-0.7 because of vala:0.10 right now. And fails to build against :0.12 slot that would propably solve the libnotify issue. If you want to take a stab at it, it's all yours. Then there is: http://igurublog.wordpress.com/downloads/script-devmon/ But I haven't tried it yet, and it's just a script... Not sure if it's worth of packaging. Either way, both are up for grabs if you used halevt before. In fact, all of udisks-glue, udiskie and traydevice are also up for grabs. I only added them to replace the HAL functionality, and not really using them... feel free to replace me (or desktop-misc herd) in metadata.xml :) - Samuli
Re: [gentoo-dev] Re: Downgrading glibc?
On Saturday, February 12, 2011 00:37:12 Ryan Hill wrote: Tracker: https://bugs.gentoo.org/353816 typo; you meant: https://bugs.gentoo.org/354107 -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] libpng-1.5 smooth upgrade
On Friday, February 11, 2011 11:49:43 Samuli Suominen wrote: On 02/11/2011 06:38 PM, Paweł Hajdan, Jr. wrote: 4) What have we learned from libpng 1.2 - 1.4 upgrade? I'd just like to be better informed. One way under consideration: We have been discussing about removing libpng.pc, libpng.so and unversioned headers from the libpng 1.5.x package allowing it to install parallel with libpng 1.4.x. That means every package that has been checked working against 1.5.x, will need to be patched to link against -lpng15, use headers from the libpng15/ directory and use libpng15.pc instead. Or we go with the old route as with 1.2 to 1.4 but that means everything must be ported before it gets KEYWORDS. i dont see any real advantages with SLOT-ed installs of libpng beyond ABI (i.e. what we're doing today with libpng-1.2.x and libpng-1.4.x). there are however plenty of downsides. patching packages in the tree is a huge hassle, you add hassle to end users who d/l random packages and try to build things themselves, and you make Gentoo non-standard wrt every other distro out there. best we follow what everyone else is already doing, and what upstream packages will have to ultimately do anyways -- fix their code to work with libpng-1.5 when the API has been forcibly broken. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-dev-announce] Removing profiles/use.local.desc file from CVS on 2011-02-11
On 02/04/2011 01:50 PM, Jeremy Olexa wrote: Hello, The CVS-RSYNC service has moved hosts and now we generate the use.local.desc file via egencache. As such, there is no need for this file to be in CVS anymore and will be removed on 2011-02-11. This email is meant as a heads up as I am not sure about everyone's individual setups or what repercussions there might be. -Jeremy This file is now removed from CVS. + 12 Feb 2011; Robin H. Johnson robb...@gentoo.org -use.local.desc: + use.local.desc is now generated purely in the rsync tier and is no longer + required in CVS. If you were looking to change it, you should be using + metadata.xml instead. If you've been following the thread, you've seen people complain that emerge --sync is re-syncing a bunch of files. I've confirmed with multiple people that the syncing is normal again, it was just a one time hit. I am sorry for that happening, but we now have greater reliability in the CVS-RSYNC service. :) Thanks, Jeremy
[gentoo-dev] Re: libpng-1.5 smooth upgrade
On 02/13/2011 01:21 AM, Mike Frysinger wrote: On Friday, February 11, 2011 11:49:43 Samuli Suominen wrote: On 02/11/2011 06:38 PM, Paweł Hajdan, Jr. wrote: 4) What have we learned from libpng 1.2 - 1.4 upgrade? I'd just like to be better informed. [...] We have been discussing about removing libpng.pc, libpng.so and unversioned headers from the libpng 1.5.x package allowing it to install parallel with libpng 1.4.x. [...] i dont see any real advantages with SLOT-ed installs of libpng beyond ABI (i.e. what we're doing today with libpng-1.2.x and libpng-1.4.x). there are however plenty of downsides. patching packages in the tree is a huge hassle, you add hassle to end users who d/l random packages and try to build things themselves, and you make Gentoo non-standard wrt every other distro out there. best we follow what everyone else is already doing, and what upstream packages will have to ultimately do anyways -- fix their code to work with libpng-1.5 when the API has been forcibly broken. Or you can mask libpng-1.5 since most users aren't interested in having the latest version of something they won't be using directly. Wait until packages have been fixed upstream. Then 8 months or a year later, unmask it.
Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade
On Saturday, February 12, 2011 18:31:12 Nikos Chantziaras wrote: On 02/13/2011 01:21 AM, Mike Frysinger wrote: On Friday, February 11, 2011 11:49:43 Samuli Suominen wrote: On 02/11/2011 06:38 PM, Paweł Hajdan, Jr. wrote: 4) What have we learned from libpng 1.2 - 1.4 upgrade? I'd just like to be better informed. We have been discussing about removing libpng.pc, libpng.so and unversioned headers from the libpng 1.5.x package allowing it to install parallel with libpng 1.4.x. i dont see any real advantages with SLOT-ed installs of libpng beyond ABI (i.e. what we're doing today with libpng-1.2.x and libpng-1.4.x). there are however plenty of downsides. patching packages in the tree is a huge hassle, you add hassle to end users who d/l random packages and try to build things themselves, and you make Gentoo non-standard wrt every other distro out there. best we follow what everyone else is already doing, and what upstream packages will have to ultimately do anyways -- fix their code to work with libpng-1.5 when the API has been forcibly broken. Or you can mask libpng-1.5 since most users aren't interested in having the latest version of something they won't be using directly. Wait until packages have been fixed upstream. Then 8 months or a year later, unmask it. that isnt how we work -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: libpng-1.5 smooth upgrade
Il giorno sab, 12/02/2011 alle 18.21 -0500, Mike Frysinger ha scritto: patching packages in the tree is a huge hassle, you add hassle to end users who d/l random packages and try to build things themselves, and you make Gentoo non-standard wrt every other distro out there. What I had in mind was something that would work for upstreams as well, mostly by having fallback; so if a package supported up to libpng 1.4 it would search for -lpng14, then -lpng12, then -lpng (and in Gentoo would hit -lpng14); while one supporting 1.5 as well would go -lpng15 -lpng14 -lpng12 -lpng ... i.e. what most already do for berkdb but at some point with us not providing -lpng at all, if most upstreams would like that idea. But it's still a bit hairy at the moment, I admit it might just not fly. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
[gentoo-portage-dev] About how to make compilation think some files are missing
This comes from glitz removal (bug #330397), as soon as cairo-1.10 gets stabilized, depclean will try to remove glitz, but removing glitz will break a lot of apps, needing to rebuild them and, until then, having a partially broken system. I then thought on running revdep-rebuild --library libglitz-glx.so.1 BEFORE removing glitz (to prevent breakage), but later I remembered it wouldn't work as rebuilt packages would link again against libglitz-glx.so.1. Then, my idea would the following: Would be nice if I could tell portage to make compilation think libglitz-glx.so.1 is not present in real system (maybe sandbox could prevent its readability inside build environment), and then, I could run revdep-rebuild --library libglitz-glx.so.1 before removing glitz and affected apps would not link to it, allowing me to safely remove glitz later without having had a broken system at any time. What do you think? Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] About how to make compilation think some files are missing
Dne 12.2.2011 16:50, Pacho Ramos napsal(a): Then, my idea would the following: Would be nice if I could tell portage to make compilation think libglitz-glx.so.1 is not present in real system (maybe sandbox could prevent its readability inside build environment), and then, I could run revdep-rebuild --library libglitz-glx.so.1 before removing glitz and affected apps would not link to it, allowing me to safely remove glitz later without having had a broken system at any time. What do you think? Thanks I think you want to update to portage-2.2 (you need to unmask it manually). It does exactly what you want in this case. Regards, Martin Doucha
Re: [gentoo-portage-dev] About how to make compilation think some files are missing
El sáb, 12-02-2011 a las 18:22 +0100, Martin Doucha escribió: Dne 12.2.2011 16:50, Pacho Ramos napsal(a): Then, my idea would the following: Would be nice if I could tell portage to make compilation think libglitz-glx.so.1 is not present in real system (maybe sandbox could prevent its readability inside build environment), and then, I could run revdep-rebuild --library libglitz-glx.so.1 before removing glitz and affected apps would not link to it, allowing me to safely remove glitz later without having had a broken system at any time. What do you think? Thanks I think you want to update to portage-2.2 (you need to unmask it manually). It does exactly what you want in this case. Regards, Martin Doucha I am not sure if portage-2.2 would also cover this case: in this example, the problem appears because of people uninstalling *intentionally* media-libs/glitz (as it's no longer needed) signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] About how to make compilation think some files are missing
On 02/12/2011 07:50 AM, Pacho Ramos wrote: This comes from glitz removal (bug #330397), as soon as cairo-1.10 gets stabilized, depclean will try to remove glitz, but removing glitz will break a lot of apps, needing to rebuild them and, until then, having a partially broken system. I then thought on running revdep-rebuild --library libglitz-glx.so.1 BEFORE removing glitz (to prevent breakage), but later I remembered it wouldn't work as rebuilt packages would link again against libglitz-glx.so.1. Then, my idea would the following: Would be nice if I could tell portage to make compilation think libglitz-glx.so.1 is not present in real system (maybe sandbox could prevent its readability inside build environment), and then, I could run revdep-rebuild --library libglitz-glx.so.1 before removing glitz and affected apps would not link to it, allowing me to safely remove glitz later without having had a broken system at any time. What do you think? Thanks Ideally, the build system(s) involved would have options to explicitly disable linking against the deprecated library. Barring that possibility, something like your sandbox idea seems like the second-best solution. On par with the the sandbox idea would be to migrate the deprecated library to a directory which is not included in the default library search path, and to use a global LD_LIBRARY_PATH setting so that your apps can find it until they are rebuilt. Then you could execute your rebuilds in an environment with a modified LD_LIBRARY_PATH value that excludes the path of the deprecated library. -- Thanks, Zac
