Re: [gentoo-dev] Make "sound" a global USE flag?
On 8 February 2011 01:18, Petteri Räty wrote: > On 02/07/2011 08:08 PM, Samuli Suominen wrote: [...] >> The "means" are commonly used as USE flag names with "result" in USE >> flag description. Think of "gstreamer", or "xine" for example. Both of these are reasonably well-known, libcanberra is not. Moreover, when these are available, they might represent a choice of backends, with maintainers ideally picking one that is preferable, leaving the picking an alternative choice to users. >> 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 This sounds reasonable. Did I miss some conversation somewhere, because it appears that "libcanberra" got finalised [1] on (even though I believe it's a horribly unintuitive name to foist on users). [1] https://bugs.gentoo.org/show_bug.cgi?id=354585 Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> "UM" == Ulrich Mueller writes: JC> Unless, of course, a patch is added which makes «set term pdf» an JC> alias for «set term cairopdf». UM> Upstream has wisely named the terminal pdfcairo (not cairopdf). UM> Therefore, gnuplot's autocompletion will do its job, without any UM> additional patch. I should've remembered that when I replied. [SIGH] And it looks like pdfcairo alread is sufficiently compatible with pdf. So no objections here to the change you already pushed. ☺ -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade
On 02/24/2011 05:26 PM, Enrico Weigelt wrote: > And it's exactly what I'm going to fix in OSS-QM when I'm adding > libpng-1.5 in a few days. not this oss-qm again... not sure how to put "nobody cares" politely
Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade
* Alexis Ballier schrieb: > > so why dont you ask the libpng upstream people ? > > ask what ? > "pretty please dont install libpng.pc/.so, Exactly that. And it's exactly what I'm going to fix in OSS-QM when I'm adding libpng-1.5 in a few days. > pretty please force every consumer to hardcode the version > because i know people that want to do this" ? No, they should use pkg-config at buildtime and do the version selection there (eg. the eselect-way). > Thanks, I'm fine with having it non slotted. And ending up with largely broken systems once again (and again, and again, with coming releases) ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
[gentoo-dev] Re: RFC: check_license deprecation
On 02/21/2011 03:46 PM, Zac Medico wrote: > Hi, > > In theory, the check_license function from eutils.eclass is obsoleted by > ACCEPT_LICENSE support which has been available in stable since January > 2010 when sys-apps/portage-2.1.7.16 was marked stable [1]. > > We may want to actively remove this function from ebuilds, especially > for cases in which it is the only reason that PROPERTIES=interactive is > set (PROPERTIES=interactive is annoying because it inhibits parallel > builds via emerge --jobs). > > [1] https://bugs.gentoo.org/show_bug.cgi?id=302001 I've updated the latest net-wireless/broadcom-sta ebuild with this change [1], since that's the only ebuild that I had installed with PROPERTIES=interactive. Please do the same for any other ebuilds where you notice that check_license is the only reason for PROPERTIES=interactive being set. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-wireless/broadcom-sta/broadcom-sta-5.100.82.38-r1.ebuild?view=log#rev1.2 -- Thanks, Zac
