Re: [gentoo-dev] Make "sound" a global USE flag?
> On Tue, 22 Feb 2011, Rich Freeman wrote: >> There's also a "sounds" local flag which generally means "install >> optional sound data". Maybe games-rpg/drascula should use this one >> instead? > I can vouch that eternal-lands-data uses the sound use flag in the > same way - the only difference it makes is whether it fetches and > installs a bunch of files. > Do we really need two different use flags for code-based sound > support vs file-based sound inclusion? Maybe it's similar enough. So, unify both "audio" and "sounds" with the global "sound" flag? Ulrich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
On Tuesday, February 22, 2011 15:18:18 Ulrich Mueller wrote: > > On Tue, 22 Feb 2011, Matt Turner wrote: > > Then please say that to begin with instead of something snooty like > > "You should check again." > > Sorry, but I don't see what would be snooty about it. That was not at > all my intention, and I apologise if it came across like that. *shrug* that's how i read it as well if cairo produces proper output now instead of faking it, i guess that qualifies as a suitable replacement for pdflib and we can chuck the pos. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> On Tue, 22 Feb 2011, Matt Turner wrote: > Then please say that to begin with instead of something snooty like > "You should check again." Sorry, but I don't see what would be snooty about it. That was not at all my intention, and I apologise if it came across like that. Francesco's statement was something like "many months ago I've checked cairo". I don't know what his exact usage case is (because he didn't say it). I only know that I don't have problems with my own usage case, which may be very different from Francesco's. So how can I learn if his problem persists, other than asking him to repeat the tests with a recent cairo version? Ulrich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
On Tue, Feb 22, 2011 at 7:13 PM, Ulrich Mueller wrote: >> On Tue, 22 Feb 2011, Tomáš Chvátal wrote: > >> Dne 22.2.2011 19:20, Mike Frysinger napsal(a): > Last time (many moons ago) I've checked cairo did not generated > pdf it did generated raster images and wrapped them in a thin pdf > layer. pdflib is generating vector pdf which is a different > thing. You should check again. >>> >>> are you saying that because you know cairo has fixed itself, or >>> because you dont know the answer yourself ? > > I know that for my usage cases, gnuplot's pdfcairo terminal produces > proper PDF output. Then please say that to begin with instead of something snooty like "You should check again."
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
Tomáš Chvátal dixit (2011-02-22, 19:39): > >>> On Tue, 22 Feb 2011, Francesco R wrote: > > Build gnuplot with USE="cairo" and you can get PDF output with the > > "pdfcairo" terminal. > >>> > >>> Last time (many moons ago) I've checked cairo did not generated pdf > >>> it did generated raster images and wrapped them in a thin pdf layer. > >>> pdflib is generating vector pdf which is a different thing. > >> > >> You should check again. > > > > are you saying that because you know cairo has fixed itself, or because you > > dont know the answer yourself ? > > -mike > To my best knowledge cairo can do proper pdf files. > > Courtesy of 12 lines of python, see the attachment, both vector curves > and normal text in one fancy pdf file. I don't see any curves (in any pdf viewer), only some ZOMG_TEXT. I always thought Python was suspicious :). -- [a] pgpbeRCIEtHeg.pgp Description: PGP signature
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> On Tue, 22 Feb 2011, Tomáš Chvátal wrote: > Dne 22.2.2011 19:20, Mike Frysinger napsal(a): Last time (many moons ago) I've checked cairo did not generated pdf it did generated raster images and wrapped them in a thin pdf layer. pdflib is generating vector pdf which is a different thing. >>> >>> You should check again. >> >> are you saying that because you know cairo has fixed itself, or >> because you dont know the answer yourself ? I know that for my usage cases, gnuplot's pdfcairo terminal produces proper PDF output. > To my best knowledge cairo can do proper pdf files. AFAIK, even programs like Inkscape use cairo for export of PostScript and PDF. Ulrich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
Dne 22.2.2011 19:20, Mike Frysinger napsal(a): > On Tuesday, February 22, 2011 12:54:11 Ulrich Mueller wrote: >>> On Tue, 22 Feb 2011, Francesco R wrote: > Build gnuplot with USE="cairo" and you can get PDF output with the > "pdfcairo" terminal. >>> >>> Last time (many moons ago) I've checked cairo did not generated pdf >>> it did generated raster images and wrapped them in a thin pdf layer. >>> pdflib is generating vector pdf which is a different thing. >> >> You should check again. > > are you saying that because you know cairo has fixed itself, or because you > dont know the answer yourself ? > -mike To my best knowledge cairo can do proper pdf files. Courtesy of 12 lines of python, see the attachment, both vector curves and normal text in one fancy pdf file. Tom output.pdf Description: Adobe PDF document signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
On Tuesday, February 22, 2011 12:54:11 Ulrich Mueller wrote: > > On Tue, 22 Feb 2011, Francesco R wrote: > >>> Build gnuplot with USE="cairo" and you can get PDF output with the > >>> "pdfcairo" terminal. > > > > Last time (many moons ago) I've checked cairo did not generated pdf > > it did generated raster images and wrapped them in a thin pdf layer. > > pdflib is generating vector pdf which is a different thing. > > You should check again. are you saying that because you know cairo has fixed itself, or because you dont know the answer yourself ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> On Tue, 22 Feb 2011, Francesco R wrote: >>> Build gnuplot with USE="cairo" and you can get PDF output with the >>> "pdfcairo" terminal. > Last time (many moons ago) I've checked cairo did not generated pdf > it did generated raster images and wrapped them in a thin pdf layer. > pdflib is generating vector pdf which is a different thing. You should check again. Ulrich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
2011/2/22 Rich Freeman : > On Tue, Feb 22, 2011 at 3:55 AM, Ulrich Mueller wrote: >>> On Tue, 22 Feb 2011, Mike Frysinger wrote: >>> that might disallow it for binaries, but it doesnt disallow it from >>> being used in ebuilds. same situation as binary kernel drivers -- >>> make it the end user's problem. >> >> Why should we impose such trouble on our users, when there's a (IMHO >> superior) replacement? Build gnuplot with USE="cairo" and you can get >> PDF output with the "pdfcairo" terminal. Even with proper utf-8 >> support, which was always broken with pdflib. > > +1 to both - if a free alternative works then we should always prefer > it. However, at worst linking license issues should just force us to > set RESTRICT="bindist" or the like (and mirror as well if we can't > distribute the source). As long as users don't redistribute software > they don't need to worry about licenses if the person sending it to > them had the license to distribute it in the first place. > > Rich > Last time (many moons ago) I've checked cairo did not generated pdf it did generated raster images and wrapped them in a thin pdf layer. pdflib is generating vector pdf which is a different thing.
Re: [gentoo-dev] Make "sound" a global USE flag?
On Tue, Feb 22, 2011 at 12:10 PM, Ulrich Mueller wrote: > There's also a "sounds" local flag which generally means "install > optional sound data". Maybe games-rpg/drascula should use this one > instead? I can vouch that eternal-lands-data uses the sound use flag in the same way - the only difference it makes is whether it fetches and installs a bunch of files. Do we really need two different use flags for code-based sound support vs file-based sound inclusion?
Re: [gentoo-dev] Make "sound" a global USE flag?
Coming back to this. It has been suggested by ssuominen that the "audio" flag should be united with "sound". It's used by the following packages: games-rpg/drascula:audio - Install optional audio files media-libs/libsdl:audio - Control audio support (disable at your own risk) net-libs/opal:audio - Enable audio support net-libs/ptlib:audio - Enable audio support Not sure if sound or audio is the better name. There's also a "sounds" local flag which generally means "install optional sound data". Maybe games-rpg/drascula should use this one instead? Ulrich
[gentoo-dev] Lastrite: media-sound/libifp-module
# Samuli Suominen (22 Feb 2011) # Fails to build with Linux 2.6.31 and up wrt bug 286081. # Unrelated to masking but it also fails to understand # KBUILD_OUTPUT wrt bug 194765. # Needs a maintainer with the hardware. # Removal in 30 days. media-sound/libifp-module
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
On Tue, Feb 22, 2011 at 3:55 AM, Ulrich Mueller wrote: >> On Tue, 22 Feb 2011, Mike Frysinger wrote: >> that might disallow it for binaries, but it doesnt disallow it from >> being used in ebuilds. same situation as binary kernel drivers -- >> make it the end user's problem. > > Why should we impose such trouble on our users, when there's a (IMHO > superior) replacement? Build gnuplot with USE="cairo" and you can get > PDF output with the "pdfcairo" terminal. Even with proper utf-8 > support, which was always broken with pdflib. +1 to both - if a free alternative works then we should always prefer it. However, at worst linking license issues should just force us to set RESTRICT="bindist" or the like (and mirror as well if we can't distribute the source). As long as users don't redistribute software they don't need to worry about licenses if the person sending it to them had the license to distribute it in the first place. Rich
Re: [gentoo-dev] Eclass review: xorg-2 virtualx
really busy with real life, so just a quick comment: we have to make sure the new virtualx eclass works fine with kde4-base, since that one is using it... but I'm sure you know that already :) On Tuesday 22 February 2011 00:18:26 Tomáš Chvátal wrote: > Hello lads, > I would like you to review following patches we kept hidden from you in > x11 overlay up till now. > > xorg-2: > autotools-utils usage > - out of tree build by default > - killing all .la files > added doc dependencies > - it is same for all pkgs and easier to keep it in eclass > (ebuilds will be updated as bumped, live versions in overlay > are already prepared for this) > updated font disable calls > - with new fonts the disable call is much much easier so we > just need to reflect that > > virtualx: > Pretty much add eclass-debug info everywhere and fix formatting. > > migrate from "export maketype" to more reliable VIRTUALX_COMMAND global > variable (can be set anytime). > > deprecate Xmake in favor of Xemake -j1 or VIRTUALX_COMMAND="emake -j1" > > Change the VIRTUALX_REQUIRED and VIRTUALX_USE to be bit saner and merged > into one variable with qa deprecation warnings and fallback in place. > New usage described in eclassdoc pretty well. > > So any comments? suggestions? > > Cheers > > Tom -- Andreas K. Huettel dilfri...@gentoo.org http://www.akhuettel.de/
[gentoo-dev] [warning] the bug queue has 83 bugs
Our bug queue has 83 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click one of the following links: http: http://bit.ly/bsHeJt https: http://bit.ly/8Z4xUU Thanks!
[gentoo-dev] Last rites: sys-apps/inotail
# Christoph Mende (22 Feb 2011) # Masked for removal, inotify support has been in tail -f since coreutils-7.5 sys-apps/inotail
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> On Tue, 22 Feb 2011, Mike Frysinger wrote: >> sci-visualization/gnuplot[pdf] is currently linking against pdflib. >> I'm going to remove that dependency, because in my understanding, >> clause 2.1 of the PDFLite license does not allow such linking. (It >> allows it for programs under an OSI approved license. However, the >> gnuplot license is free, but not OSI approved.) > that might disallow it for binaries, but it doesnt disallow it from > being used in ebuilds. same situation as binary kernel drivers -- > make it the end user's problem. Why should we impose such trouble on our users, when there's a (IMHO superior) replacement? Build gnuplot with USE="cairo" and you can get PDF output with the "pdfcairo" terminal. Even with proper utf-8 support, which was always broken with pdflib. Ulrich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> On Mon, 21 Feb 2011, Jeremy Olexa wrote: > The bugs are stacking up[1] and upstream only offers a paid version of > pdflib-8[2]. It is my understanding that there is no way for us to > package future versions and the bundled libs are vulnerable[3]. > So, should it be removed? For more info, see the tracker bug for its > removal[1], there are a number of rdeps that will require fixing[4]. sci-visualization/gnuplot[pdf] is currently linking against pdflib. I'm going to remove that dependency, because in my understanding, clause 2.1 of the PDFLite license does not allow such linking. (It allows it for programs under an OSI approved license. However, the gnuplot license is free, but not OSI approved.) Ulrich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
On Tuesday, February 22, 2011 02:29:06 Ulrich Mueller wrote: > > On Mon, 21 Feb 2011, Jeremy Olexa wrote: > > The bugs are stacking up[1] and upstream only offers a paid version of > > pdflib-8[2]. It is my understanding that there is no way for us to > > package future versions and the bundled libs are vulnerable[3]. > > > > So, should it be removed? For more info, see the tracker bug for its > > removal[1], there are a number of rdeps that will require fixing[4]. > > sci-visualization/gnuplot[pdf] is currently linking against pdflib. > I'm going to remove that dependency, because in my understanding, > clause 2.1 of the PDFLite license does not allow such linking. > (It allows it for programs under an OSI approved license. However, the > gnuplot license is free, but not OSI approved.) that might disallow it for binaries, but it doesnt disallow it from being used in ebuilds. same situation as binary kernel drivers -- make it the end user's problem. -mike signature.asc Description: This is a digitally signed message part.
