Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?
Hi, > Since the pkgconfig files for xulrunner-1.9 are renamed to avoid > collisions with current xulrunner-1.8. In general I dont think that is a good idea to do that as you said we'll have to patch all the rev deps of xulrunner. More importantly we'll have to carry on those patches forever because we're doing non "standard" things. > The other approach would be not slotting it, p.mask xulrunner-1.9 and > wait until all the packages work against it and then unmask. I don't know how hard it would be but I think that's the best option. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] LaTeX documentation
Hi,
> There are two methods commonly used to fight against this situation
> in ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The
> second method is, probably, better.
Packages should definitely go for the VARTEXFONTS one as I'll probably
drop forced global writable /var/cache/fonts at some point in the
texmf-update script (not that its a security issue but I really dont
like having it like that); if its not world writable and a package
needs to build some fonts and isn't run as root (default nowadays?) the
addwrite will not allow it to write there afaik and it will fail.
Nice you have such a list, please assign a bug to [EMAIL PROTECTED] for that and
I'll see what I can do to convert them (perhaps adding the maintainers
in case they want to know what's up and are willing to help).
See:
https://bugs.gentoo.org/show_bug.cgi?id=204433
http://groups.google.com/group/linux.gentoo.dev/browse_thread/thread/bf2e58fe200c0676/b72be3596cd2eb31
> Most disturbingly, there are a number of packages which (probably)
> run latex and do neither addwrite nor VARTEXFONTS. An incomplete list
> of such suspect packages is (for now, I only considered packages not
> directly related to TeX/LaTeX, i.e., not in dev-tex or dev-texlive
> and not TeX/LaTeX packages in app-text):
[...]
> These are (potentially) bombs waiting to blow up an unsuspecting
> user. They should be carefully checked.
Yeah or maybe they dont need any unusual fonts; its probably sane to
set VARTEXFONTS regardless. Probably it'd be worth adding a latex
eclass that would just contain:
VARTEXFONTS=${T}/fonts
and inherit it from any package calling latex to avoid code duplication
(like e.g. the mono eclass do).
What do you think ?
> By the way, while investigating this question, I found quite a few
> packages which still depend on virtual/tetex, while, probably,
> virtual/latex-base would be better
Yep, it would be cool to kill virtual/tetex because it does not make
much sense nowadays. Some might be false positives but please also file
a bug for [EMAIL PROTECTED] with that list and cc the maintainers to see what
can
be done.
Regards,
Alexis.
signature.asc
Description: PGP signature
Re: [gentoo-dev] LaTeX documentation
On Tue, 13 May 2008 16:57:02 +0200 Patrick Kursawe <[EMAIL PROTECTED]> wrote: > On Mon, May 12, 2008 at 09:23:29PM +, Andrey Grozin wrote: > [...] > > Most disturbingly, there are a number of packages which (probably) > > run latex and do neither addwrite nor VARTEXFONTS. An incomplete > > list of such suspect packages is (for now, I only considered > > packages not directly related to TeX/LaTeX, i.e., not in dev-tex or > > dev-texlive and not TeX/LaTeX packages in app-text): > [...] > > media-gfx/sane-backends > [...] > > What do you think? > > sane-backends had font generation disabled, but I changed it to the > VARTEXFONTS method for now. Wouldn't it be better to populate this > temporary directory with links to existing cached fonts or something > like this? I don't know much about latex internals, but computing the > fonts always because one _might_ be written sounds like a bad idea. Normally VARTEXFONTS is for writting fonts one needs to generate; however, with the usual default configurations files I've seen, overriding it will make the various apps needing 'em not see the default font cache directory. I've committed a new tl-core ebuild with default configuration files that will let it see the old font cache directory even if VARTEXFONTS is changed, but will of course write to VARTEXFONTS. This should be what you were asking for ;) Regards, Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] LaTeX documentation
On Tue, 13 May 2008 14:20:31 +0200
Ulrich Mueller <[EMAIL PROTECTED]> wrote:
> > On Mon, 12 May 2008, Andrey Grozin wrote:
>
> > There are two methods commonly used to fight against this situation
> > in ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The
> > second method is, probably, better.
>
> Why? This would mean that all fonts must be regenerated each time the
> package is built. And it doesn't even help if they are already present
> in /var/cache/fonts, since the directory is then also ignored for
> reading.
Per my other mail its a non issue now ;)
However, if an ebuild needs some fonts not in the font cache or the
texmf tree(s) it'll generate it in VARTEXFONTS, and since they're not
merged into the filesystem, it will do that each time the package is
built.
My opinion is that it is not so important because merging them will
cause headaches:
- How to detect when some fonts have been generated ?
- Should we merge them in src_install so that it's in the package
contents ? it'll get removed when the package is gone
- In some pkg_ functions so that it doesnt get removed; is this safe
for binpkgs ? that'll leave stray files, but that's more or less the
point of doing it like that.
- Where should we merge them ? hardcoding /var/cache/fonts is a no-no
as, even if for now it's forced to be there by texmf-update, it would
be a good idea not to do so and allow people to change the location. We
can ask for the value with kpsewhich; but is that a good idea to install
files in locations based on user defined config files ?
Regards,
Alexis.
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
> A. Convince the portage developers to put it in > make.conf/make.defaults. By the way, I'm strongly opposed to this: it should be, at best, in the profiles. For instance, as long as bug #192403 isn't fixed, as-needed will cause *a lot* of build failures on fbsd since gcc specs are broken and wont append the -lc for shared libraries and -lpthread when -pthread is used if I remember correctly. Regards, Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Nominations for council
On Thu, 5 Jun 2008 22:41:40 +0300 Samuli Suominen <[EMAIL PROTECTED]> wrote: > Tue, 3 Jun 2008 05:52:35 + > Ferris McCormick <[EMAIL PROTECTED]> kirjoitti: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > > > I think nominations are open. I nominate > > Then I'd like to nominate (mostly same ones again) [..] > aballier Thanks, but I decline. Considering all the nominee, I think there are enough people probably more able than I am to run a council. My habit of not getting involved in endless discussions would have probably not helped to get elected anyway ;) Moreover, with all the recent threads here, I don't think I want to be in the group that will have to take the decisions. Regards, Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 01:42:34 +0200 Bo Ørsted Andresen <[EMAIL PROTECTED]> wrote: > > > - Enable FEATURES=test by default (bug #184812) > > > > Only if >99% of the stable and ~arch tree and all potential "system" > > packages build with it (IOW: no) > > Err.. Maybe this could have been phrased better but then I did expect > you would look at the bug before commenting. The idea is to enable > tests by default in EAPI 2 and beyond and let them stay off by > default in EAPI 0 and 1. This way devs who want to use EAPI 2 will > either have to fix their tests or RESTRICT them. Doing it this way > avoids the issue of having to fix the whole tree all at once. Users > can still choose not to go with the default. I thought tests were already supposed to pass whatever the EAPI is and devs were supposed to run them... Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] A unit-testing prototype
On Thu, 12 Jun 2008 00:48:01 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > On 02:47 Mon 26 May , Donnie Berkholz wrote: > > A while back, vapier added some tests for the toolchain-funcs > > eclass to /usr/portage/eclass/tests/. I really like the idea, and I > > recently discovered an xUnit-style unit-testing framework for shell > > scripts called ShUnit2. I played with it a little and made a couple > > of prototypes. Take a look and see what you think. > > I've heard two positive comments on IRC and nothing else, so I'm > proceeding with this. I'll be adding these to the existing > /usr/portage/eclass/tests/, adding shunit2 to the tree, and beginning > some work looking into unit tests for portage's bash code. Great! Thanks. I didn't try it because I was too lazy to put shunit2 in an overlay but had a look at the code. Tests cannot hurt, esp. for such widely used code that eclasses are. I'll probably use this to write tests for the couple of eclasses I maintain. Alexis. signature.asc Description: PGP signature
[gentoo-dev] tetex maintainance (RFH?)
Dear all, app-text/tetex is currently assigned to tex as maintainer, but, in my opinion, that's a lie. I have not seen any movement on tetex bugs for a while. I have opened a tracker bug (#227443, [1]), if someone feels the courage of picking it up. I don't have neither the time nor the will to do it myself. While it has been stated since more than two years on tetex's homepage that people should use texlive [2], we still cannot really remove it from our tree. What I'm planning to do, if nobody comes to maintain it, is to reassign its bugs to maintainer-needed and update its metadata.xml to reflect that. In case we have someone crazy enough to pick it up, I am of course available to try to answer any question. The other option is to p.mask and last rite it, breaking mips and s390 trees, leaving them without tex support at all. This would also leave arm and sh with only ptex as tex support. Thus that is not really an option yet, but I suppose there is no point in waiting forever on this. Regards, Alexis. [1] https://bugs.gentoo.org/show_bug.cgi?id=227443 [2] http://tug.org/teTeX/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: tetex maintainance (RFH?)
On Mon, 16 Jun 2008 20:45:35 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: > On Mon, 16 Jun 2008 19:57:45 +0200 > Alexis Ballier <[EMAIL PROTECTED]> wrote: > > > The other option is to p.mask and last rite it, breaking mips and > > s390 trees, leaving them without tex support at all. This would also > > leave arm and sh with only ptex as tex support. Thus that is not > > really an option yet, but I suppose there is no point in waiting > > forever on this. > > chutzpah is supposed to be sending me a new O2 so i can ravage its > power supply and get mine running again. hopefully i can get mips up > to speed soon. > > i also left gnome hanging, sorry about that guys. By the way, this was not really a rant; if there is anything I can do to help there, feel free to poke me. TeX is something that isn't that hard to test on a distant machine. It's just that I never heard anything back from those arches. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Removing .la files...
On Sat, 19 Apr 2008 22:18:19 +0200 [EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote: > libogg and popt are now masked, and they'll wait a bit before return > to ~arch that way. 2 months later, any news on this ? I've been using the unmasked versions so long; are we going to wait forever ? It's probably better to unmask it or revert the change at this point. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
Hi, > dev-lang/erlang (lang-misc) -- a version bump now and then (four > times a year), seldomly but then obscure bugs, cooperative upstream I would appreciate if you could take care of my fbsd problem ;p > mail-client/claws-mail and all plugins (net-mail) -- a version bump > is some work, but low rate of bugs, ken69267 is there to maintain, > but he maybe needs a helping hand Never had any problem with it, I'm using it as my mail client on several boxes, if you or Kenneth need any specific help, feel free to poke me/cc me on bugs. > media-sound/cmus -- low maintenance can probably be dropped to sound I hope that doesn't mean you're planning to retire ;p Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for August 7
On Tue, 5 Aug 2008 20:55:02 +0100 David Leverton <[EMAIL PROTECTED]> wrote: > On Tuesday 05 August 2008 20:45:33 Ben de Groot wrote: > > It really baffles me that some developers are forcefully retired for > > anti-social behavior, but are not consequently banned from the > > places where they display this behavior, such as our MLs and IRC > > channels. > > I'm not aware of any ex-developers who were forcefully retired and > who display anti-social behaviour. Please explain, giving concrete > examples of such behaviour and reasons why you think it qualifies as > "anti-social". Somehow I read the sentence differently: it seems pointless to ban competent people for so-called anti-social behavior from easily pushing technical contributions and still let them contribute to other communication medias where such an anti-social behavior is much more obvious. Nowhere have I seen any accusation in Ben's mail, keep cool ;) Alexis. signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-lang/caml-light (Removal due 7 september 2008)
That's a bit sad that I announce this as I learnt caml with it, too many years ago. Reasons: Does not build (bug #206138), unmaintained upstream for years, not very useful nowadays. Use dev-lang/ocaml instead. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] FEATURES=-userpriv and testcases that fail as root or a user
On Thu, 7 Aug 2008 12:00:23 -0700 "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: > More than a year ago, I had my first occurrence of a package that > refused to work when run as root: dev-db/mysql. This lead to the > following block of code in the src_test block: > > if [[ $UID -eq 0 ]]; then > die "Testing with FEATURES=-userpriv is no longer supported > by upstream. Tests MUST be run as non-root." fi I've used that for flac: if [ $UID != 0 ] ; then emake check || die "tests failed" else ewarn "Tests will fail if ran as root, skipping." fi ie, don't die and continue. If someone is interested in the tests they can read the ewarn. Alexis. signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-tex/extsizes and dev-tex/eurosym
Hi, # Masked for removal on 04 Oct 2008 # Provided by tetex-3, ptex and texlive-fontsrecommended or # texlive-latexrecommended, which makes them uninstallable anyway. dev-tex/extsizes dev-tex/eurosym Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Remove global USE flag tetex
On Wed, 3 Sep 2008 01:55:00 +0200 Ulrich Mueller <[EMAIL PROTECTED]> wrote: > > On Wed, 3 Sep 2008, Christian Faulhammer wrote: > > > there should be no more packages in the tree that have USE=tetex, so > > this global USE flag can be removed. Any opinions? > > Go for it! +1 And thanks again for taking the time to finish the migration of the last few remaining packages. Alexis. signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-tex/vntex
Hi, dev-tex/vntex will be removed in 30 days. Reason: Masked since early 2007. Included in tetex-3, ptex and texlive-langvietnamese. If someone wanted to keep the ebuild around for single package updates, he had plenty of time to do it. Now it is old and unmaintained and therefore will be removed on 06 Oct 2008. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Making built_with_use die by default with EAPI 2
Hi, > When EAPI 2 goes live built_with_use should probably die for most > cases. I don't understand here: you mean die like being removed or die like the die call in an ebuild? If I understood correctly the following it should be the latter. > Are there valid use cases for built_with_use that are not > covered by the use deps in EAPI 2? I can think of checks like: - foo is a dep/rdep of bar - foo has a "plugin like" architecture - bar will "work" with minimal foo - most people will expect some features in bar that come with foo's plugins - we might want to display warnings for the most useful features - having useflags in bar for each of foo's useflags doesn't seem wise Ok that's not really a nice example but I can't think of anything better at the moment. By the way, how will the --missing option of built_with_use be handled by eapi 2? Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Making built_with_use die by default with EAPI 2
On Tue, 23 Sep 2008 23:33:44 +0300 Petteri Räty <[EMAIL PROTECTED]> wrote: > Bo Ørsted Andresen kirjoitti: > > On Monday 22 September 2008 22:25:20 Petteri Räty wrote: > >>> If you mean something like > >>> > >>> built_with_use cat/foo coolfeature || ewarn "bar will be more > >>> useful if you rebuild cat/foo with USE=coolfeature" > >>> > >>> then you can use > >>> > >>> has_version 'cat/foo[coolfeature]' || ... > >>> > >>> instead. > >> What does this report if cat/foo does not have coolfeature use > >> flag in some version? Meaning can this support cases which need > >> --missing true. > > > > False. If for instance coolfeature was made optional in >=pv you > > can use logic like: > > > > if has_version '>=cat/foo-pv' && ! has_version > > 'cat/foo[coolfeature]'; then ewarn '...' > > fi > > > > I think this should cover all the current functionality with > built_with_use. This is just an ugly hack. Think about a package that has coolfeature useflag removed and enabled by default for a couple of releases because it wouldn't build without it and once upstream sorted out everything the useflag is coming back. Missing useflags that are assumed to be enabled have nothing to do with the package version being greater than a given number. I would *really* prefer having big warnings when using built_with_use in EAPI 2; that way we can see how things are in practice and then maybe make built_with_use die for a later eapi or once all the tree is converted to eapi 2 remove it. Alexis. signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/audacity: ChangeLog audacity-1.3.5-r1.ebuild
Hi Diego,
> EAPI=2
[...]
> src_compile() {
> WX_GTK_VER="2.8"
> need-wxwidgets unicode
>
> econf \
This causes me a configure failure because I don't have a system
wxwdigets profile set and need-wxwidgets doesn't seem to do anything.
1.3.5 is fine; -r1 fails at configure. I don't understand what's going
on, the only change seems to be the switch to EAPI-2.
Alexis.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/audacity: ChangeLog audacity-1.3.5-r1.ebuild
On Mon, 29 Sep 2008 09:38:41 +0200
Alexis Ballier <[EMAIL PROTECTED]> wrote:
> Hi Diego,
>
>
> > EAPI=2
> [...]
> > src_compile() {
> > WX_GTK_VER="2.8"
> > need-wxwidgets unicode
> >
> > econf \
>
>
> This causes me a configure failure because I don't have a system
> wxwdigets profile set and need-wxwidgets doesn't seem to do anything.
> 1.3.5 is fine; -r1 fails at configure. I don't understand what's going
> on, the only change seems to be the switch to EAPI-2.
Ok, that was a failure at src_configure which obviously was called
before src_compile. Maybe it would be worth adding repoman
warnings/errors for econf calls in eapi2 src_compile.
Alexis.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/audacity: ChangeLog audacity-1.3.5-r1.ebuild
On Mon, 29 Sep 2008 21:24:55 +0200 Bo Ørsted Andresen <[EMAIL PROTECTED]> wrote: > On Monday 29 September 2008 10:27:51 Alexis Ballier wrote: > > Maybe it would be worth adding repoman warnings/errors for econf > > calls in eapi2 src_compile. > > Or make econf warn when run outside src_configure/src_compile > depending upon EAPI. I'd say s/Or/And/ ; if we can catch this pre-commit that's better; unfortunately I don't think repoman will catch exported functions from eclasses :/ Alexis. signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask
On Tue, 30 Sep 2008 15:10:44 + "Daniel Gryniewicz (dang)" <[EMAIL PROTECTED]> wrote: > dang08/09/30 15:10:44 > > Modified: package.mask > Log: > Remove poppler from mask; current evince works fine s/current/only/ I currently have pdftex,luatex & xpdf failing here. It would have been nice if maintainers had been contacted before pushing this to ~arch since it is a very well known api-breaking library. Not that they seem difficult to fix but I'm not really fond of the "let it break, wait for bug reports, fix later" way. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Migrating to EAPI 2 and econf
On Wed, 01 Oct 2008 16:48:05 +0300 Petteri Räty <[EMAIL PROTECTED]> wrote: > Just a reminder to everyone that when you migrate to EAPI 2 in order > to use use dependencies remember to migrate your src_compile function > too or you will be running econf twice if you have a custom > src_compile function. econf will first be run by the default > src_configure function and then by your custom src_compile function. Also don't forget about eclasses that export src_compile; and that's where it becomes more tricky :( Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 15:07:27 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sun, 5 Oct 2008 15:36:30 +0200 > Ulrich Mueller <[EMAIL PROTECTED]> wrote: > > How should exporting of src_configure in eclasses be handled? Should > > it be conditional, depending on the EAPI? Or is it O.K. to export > > src_configure unconditionally, since it doesn't harm for EAPI<2? > > Export it if and only if EAPI is 2. > > Note that this means EAPI really really has to be set as the first > thing in the ebuild (*cough* or in the file extension). By the way, do we really want to special case eapi-2 in every eclass ? That's lot of code duplication and will get even worse when we'll reach eapi-42. That would have been cool to have a pm function that tells "has my eapi foo support" but that sort of bites its tail that way. An eapi.eclass with such functions and lists of eapi & features maintained there could help though. An EXPORT_FUNCTIONS ignoring any function its doesn't know for its eapi would help too. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 15:24:20 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sun, 5 Oct 2008 16:15:46 +0200 > Alexis Ballier <[EMAIL PROTECTED]> wrote: > > An eapi.eclass with such functions and lists of eapi & features > > maintained there could help though. > > The problem is, 'features' change between EAPIs. For example, all > three EAPIs have src_compile, but it does different things for all > three. One can't assume that a feature working for current EAPIs will > carry on working for future EAPIs, and even if it does there can be > other interactions that break. Indeed; different names could be given to different implementations of the same thing, but that might completely kill the point of abstracting it. Maybe eclasses should die on unknown eapi; the fact is I really hate the current way it's done when switching an ebuild to EAPI-2 which uses an eclass that exports src_compile; most eclasses don't special case eapi-2 yet and we end up running econf twice at best. I fear that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll support src_configure too) > > An EXPORT_FUNCTIONS ignoring any function its doesn't know for its > > eapi would help too. > > An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place > checking for eclass screwups... yes; that's just a matter of choice though, but for eclasses it's probably not luxury. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
> I don't quite see how that deals with an eclass calling econf in its > exported src_compile? Seems like EAPI versioning for eclasses (with > implicit 0 only) is more what you're after for that issue (so the PM > could suppress src_configure if src_compile is going to resolve to an > EAPI-0 eclass function, although the inheritance stack might prove > problematic.) I don't know of any way for the pm to detect if the eclass supports given eapi or not, and even less if exported src_compile will be eapi-2 aware or not. > Having to die for an unsupported EAPI seems like the wrong approach; > if it's not going to work the PM shouldn't source it. If it can be > made to work by filtering certain functions, that's doable. I tend to see dying for an unsupported eapi as eclass versioning for the poor people but that's the only thing we can do atm afaik. For now, all eapi are backward compatible wrt to sourcing so that's not really an issue to source an eapi-0 eclass withing an eapi-2 ebuild. I think there has been a discussion on eclasses vs eapi before and the outcome was that eclasses should add hacky checks for eapi; which means to me we'll have to adjust those hacky checks for each new eapi. However, for now, not dying allows workarounds like: http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/ogmrip/ogmrip-0.12.2.ebuild?view=markup but I don't consider it very pretty. > In the worst case, an ebuild switching to EAPI will require eclass > maintenance; this is where the separation of elibs (useful code) and > eclasses (template ebuilds) would be useful, although that needs > versioning too. The problem will remain for this new definition of eclasses; glad to see you're volunteering to fix every single eclass that exports a src_compile/unpack function for eapi-2 :) If by template ebuilds you mean the EXPORT_FUNCTIONS line and some deps, then I dont see the difference between eapi versioning for eclasses and a switch/case for each eapi in the unversioned eclass. Note that "useful code" can differ upon eapi (I'm thinking about has_version checks). Regards, Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
Hi, > media-libs/aalib eradicator added video herd there > media-libs/liboggzzaheerm and sound here Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
Hi, > (I think pulseaudio is fixed, actually.) For what it's worth: removing the .la files from pulseaudio breaks its module loading on freebsd; and it's an elf system. I don't know what you mean by fixed and I didn't investigate this but restoring the .la files in the ebuild allowed me to make it load its plugins. Maybe that's another issue or maybe there's something we have forgotten about the .la files; I think pulseaudio uses libltdl and iirc these was a case where the .la files were needed at runtime. Imho, the only option for punting .la files are the ones that are opt-in, opt-out ones should be discarded. Having it as a feature is opt-out and will break anything that needs it and doesn't have the restrict yet. On the other hand, maybe this could be some property like "la_files_can_be_punted" which is, as i understand it, the opt-in version of restrict. Moreover .la files are good when you want to link statically to some library because they carry the needed information; they should be punted only when said library provides a good alternative (like a .pc file with correct libs.private field). Regards, Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] /usr/share/texmf-site
On Fri, 28 Nov 2008 08:18:47 +0100 Ulrich Mueller <[EMAIL PROTECTED]> wrote: > > On Fri, 28 Nov 2008, Andrey Grozin wrote: > > > Some time ago, some Gentoo TeX guru (don't remember who) advised to > > include the following code to the sci-mathematics/maxima ebuild: > > > [...code...] > > This code calls "kpsewhich" which means that the location of files > installed by the ebuild will depend on the user's configuration. > IMHO this is not a sane situation. (And the configuration may even > change after installation of the package.) Yes; that's why I always hardcode it. I need to write a "latex package packaging guide" some day... Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] prepalldocs is now banned
On Wed, 18 Feb 2009 00:18:06 + Ciaran McCreesh wrote: > On Tue, 17 Feb 2009 19:10:33 -0500 > Michael Sterrett wrote: > > So everybody who emerges gnupg since this change is wasting space > > for no good reason. > > If you care about a couple of hundred kilobytes, relying upon > individual ebuilds to ask the package manager to compress > documentation in some arbitrary manner is the wrong solution. Then, for the nth time, what would be the good solution? How would one convert prepalldocs usage to something allowed? I've failed to find anything about it in the relevant bug and the only answer I've seen is "remove it". You can count on me for marking any prepalldocs removal bug I'll be the assignee as wontfix as long as there won't be any alternative solution. Note that I would consider a viable solution banning prepalldocs and simply removing it if portage was compressing docs by its own or calling prepalldocs after src_install... but then IMHO that's the removal of prepalldocs that would require an EAPI bump not its reintroduction. Regards, Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] prepalldocs is now banned
On Wed, 18 Feb 2009 14:06:46 + Ciaran McCreesh wrote: > On Wed, 18 Feb 2009 08:39:58 +0100 > Alexis Ballier wrote: > > Then, for the nth time, what would be the good solution? > > If you explicitly need compression, do it by hand, since there aren't > any mechanisms for guaranteed compression anyway. Yes of course. > If you don't explicitly need compression, don't do anything. ... and mark relevant stuff as "ok to be compressed with whatever suits you best"... sounds familiar? :) > And if you're trying to make a space-critical distribution, start > looking at the big things, not the 4% things. When I do something space critical I exclude /usr/share/doc and a couple of others... that doesn't mean I do like wasting space on something not space critical when compression algorithms exist. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] prepalldocs is now banned
> If you really, genuinely think you have a case for compression of > docs, backed up with statistics showing that it's a relevant change, I fail to see why you need statistics for something that is clearly a waste of space, but this could be a start: http://archives.gentoo.org/gentoo-dev/msg_9018a9f64cd32ba85494887ffe3edf78.xml > then you should write a proposal for future EAPIs for handling it, I don't understand why something that has been there for ages has to die. For what I've seen, the major (and only) problem with prepalldocs is its definition and I'm sure we can find one that everybody will agree with. > and you should do it in such a way that it works automatically for > all ebuilds, without any developer intervention (but providing some > way for ebuilds to disable it where necessary). This is probably a good start: http://archives.gentoo.org/gentoo-dev/msg_eb1f7952eb2f0fe725bde331a4d9ae30.xml Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] prepalldocs is now banned
On Wed, 18 Feb 2009 18:36:11 + Ciaran McCreesh wrote: > On Wed, 18 Feb 2009 19:28:46 +0100 > Alexis Ballier wrote: > > > If you don't explicitly need compression, don't do anything. > > > > ... and mark relevant stuff as "ok to be compressed with whatever > > suits you best"... sounds familiar? :) > > No. That's entirely the wrong approach, I would call it an "unperfect yet useful approach" that unfortunately we've been using for eapi 0-2. > because it relies upon every > ebuild having support for it, and most don't. That's why it needs to be improved. > The right approach, if > you can demonstrate that there's a genuine benefit to compressing > documentation, is to make a proposal for a future EAPI for compression > by default for certain directories, with an override available for > ebuilds that need specific behaviour. And I agree this is the right solution but yet unimplemented... > > > And if you're trying to make a space-critical distribution, start > > > looking at the big things, not the 4% things. > > > > When I do something space critical I exclude /usr/share/doc and a > > couple of others... that doesn't mean I do like wasting space on > > something not space critical when compression algorithms exist. > > If you care about space, focus on something relevant. [...] You got me wrong there it seems: I do not care about space, however I do care about useless waste of space. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 15:53:20 +
Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 08:43:09 -0700
> Steve Dibb wrote:
> > Plus, I don't really grasp the whole "we have to source the whole
> > ebuild to know the EAPI version" argument. It's one variable, in
> > one line. Can't a simple parser get that and go from there?
>
> Not true. This is entirely legal:
>
> In pkg-1.ebuild:
>
> EAPI="${PV}"
> printf -v EAPI '%s' 4
> inherit foo
> EAPI="2"
Which begs the question: is it really worth allowing it?
If we only allow constant assignments (which is an implicit restriction
in the file extension version) then this can be parsed easily with
grep/tr/awk/etc and can be the magic eapi guessing. Of course the tree
has to be checked before implementing this and we'll have to wait a
good amount of time before breaking the current eapi bash-parsing but
I'm not aware of any eapi proposal that would break the current behavior
and would be usable in the main tree within a reasonable amount of
time such that we can't ignore backward compatibility.
> In foo.eclass:
>
> EAPI="3"
I thought this was prohibited.
Alexis.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 16:19:56 + Ciaran McCreesh wrote: > On Mon, 23 Feb 2009 17:13:16 +0100 > Alexis Ballier wrote: > > Which begs the question: is it really worth allowing it? > > If we only allow constant assignments (which is an implicit > > restriction in the file extension version) then this can be parsed > > easily with grep/tr/awk/etc and can be the magic eapi guessing. Of > > course the tree has to be checked before implementing this and we'll > > have to wait a good amount of time before breaking the current eapi > > bash-parsing but I'm not aware of any eapi proposal that would break > > the current behavior and would be usable in the main tree within a > > reasonable amount of time such that we can't ignore backward > > compatibility. > > ...and then we have to do the whole thing again every time something > new crops up. Please give an example because I fail to see how. > EAPI was supposed to solve this, and profile eapi and > GLEP 55 finish the job. Repeatedly going back and saying "oh, we have > to wait another year or more again" is unacceptable. Had we found a compromise at the beginning of glep55, that extra year would be over by now... Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, 24 Feb 2009 18:24:16 + Ciaran McCreesh wrote: > On Tue, 24 Feb 2009 18:16:54 +0100 > Luca Barbato wrote: > > > You're doubling the number of files that have to be read for an > > > operation that's almost purely i/o bound. On top of that, you're > > > introducing a whole bunch of disk seeks in what's otherwise a nice > > > linear operation. > > > > I see words, not numbers. > > Number: double. That's a '2 times'. That only means you're increasing the constant factor in the complexity of the thing... which may very well be completely negligible unless someone provides real benchmarks. I would be very surprised if that "2 times" factor happens to be true, because finding a string in a file is an order of magnitude simpler than sourcing said file with bash. Moreover this doesn't take into account disk and os cache. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
I have no strong opinion about this. > 2) EAPI in file extension > - Allows changing global scope and the internal format of the ebuild > a) .ebuild- > - ignored by current Portage simple, straightforward but ugly > b) ..ebuild > - current Portage does not work with this this only has disadvantages in front of a) > c) .. > - ignored by current Portage same as a) but maybe less ugly > 3) EAPI in locked down place in the ebuild > - Allows changing global scope > - EAPI can't be changed in an existing ebuild so the PM can trust > the value in the cache This doesn't need a locked down place, just some strict way of setting it, like at most one EAPI="constant_string_without_space" so that grep & friends can catch it. > - Does not allow changing versioning rules unless version becomes a > normal metadata variable I'm not entirely sure about this and would need some real example/argument in order to be convinced > * Needs more accesses to cache as now you don't have to load older > versions if the latest is not masked true but this "more" would need to be measured and opposed to the number of metadata loads in a dep resolution procedure. > a) doesn't have the one year wait drawback and doesn't mess with pm implementation details (eapi) with package names that shall represent upstream ones. > b) new subdirectory like ebuilds/ > - we could drop extension all together so don't have to argue about > it any more > - more directory reads to get the list of ebuilds in a repository I see no advantage there vs 3.a) > c) .ebuild in current directory > - needs one year wait That could have been done one year ago and would be done now; I think it's still fine now because I don't expect major behavior changes in the ebuild format within one year. To summarize, I would retain 3.a as best solution, having the "usable right now" advantage of current glep55 and keeping the ebuild's file names (more or less) consistent with upstream ones. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, 24 Feb 2009 19:37:11 + Ciaran McCreesh wrote: > On Tue, 24 Feb 2009 20:28:43 +0100 > Alexis Ballier wrote: > > On Tue, 24 Feb 2009 18:24:16 + > > Ciaran McCreesh wrote: > > > On Tue, 24 Feb 2009 18:16:54 +0100 > > > Luca Barbato wrote: > > > > > You're doubling the number of files that have to be read for > > > > > an operation that's almost purely i/o bound. On top of that, > > > > > you're introducing a whole bunch of disk seeks in what's > > > > > otherwise a nice linear operation. > > > > > > > > I see words, not numbers. > > > > > > Number: double. That's a '2 times'. > > > > That only means you're increasing the constant factor in the > > complexity of the thing... which may very well be completely > > negligible unless someone provides real benchmarks. > > In the most common case where metadata is valid, around half of the > time it takes Paludis to work out a resolution set is spent grabbing > metadata for ebuilds. That sounds like an implementation detail that you could solve by using something else than a flat file database for metadata if open()/read() calls are the slow part. > > I would be very surprised if that "2 times" factor happens to be > > true, because finding a string in a file is an order of magnitude > > simpler than sourcing said file with bash. Moreover this doesn't > > take into account disk and os cache. > > No no no. *Opening* the file is the slow part, not searching. The file > wouldn't otherwise be opened at all. Thus the only drawback is when you open a file, see there that you can't handle the eapi, then close it and open an older one. So you're doing useless things only in that case which in practice will have a ratio far lower than 2. Moreover Luca's benchs show that searching for file names is a negligible factor faster than grepping them while you're just stating that it isn't. Alexis. signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/transcode: transcode-1.1.1-r1.ebuild ChangeLog
On Sat, 07 Mar 2009 13:31:15 +
"Patrick Lauer (patrick)" wrote:
> patrick 09/03/07 13:31:15
>
> Modified: ChangeLog
> Added:transcode-1.1.1-r1.ebuild
> Log:
> eapi2ifying 1.1.1. No functional changes.
> (Portage version: 2.2_rc23/cvs/Linux x86_64)
[...]
> #pkg_setup() {
> # if use X && ! built_with_use media-libs/libsdl X; then
> # eerror "media-libs/libsdl must be built with the X
> use flag." # die "fix use flags"
> # fi
> #}
[...]
> # emake all || die "emake all failed"
> #}
while I thank you for improving the ebuild please don't leave such mess
in the ebuilds so that people doing the bumps and maintainance won't
have to do the clean up after you...
Alexis.
signature.asc
Description: PGP signature
Re: [gentoo-dev] LC_ALL=C Set by default for portage
Hi, > lately i see that in our bugzilla most of the build reports are > reported with localized build logs which we dont understand. This > leads to us asking the user to run the emerge once more with LC_ALL=C. > > Wont it be nice to have this variable set by default in portage so > users reporting bugs report in English? Since if everything goes fine > they dont even bother about the warnings/errors and if something goes > wrong it ends up on us to solve the mess :] Moreover this would automagically solve the [a-z] & friends regexp failures; though that's still good QA to fix them but we wouldn't encounter them anymore. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] [amd64-fbsd] remove charset.alias
On Wed, 11 Mar 2009 14:16:29 +0100
Timothy Redaelli wrote:
> Hi,
> I'm creating the amd64 porting of Gentoo/FreeBSD (with multilib
> support).
>
> The problem is that some [1] ebuilds removes
> directly "${D}"/usr/lib/charset.alias and
> not "${D}"/usr/$(get_libdir)/charset.alias.
What about a epunt_charset_alias function in eutils? That would for
sure factorize that code.
Alexis.
signature.asc
Description: PGP signature
Re: [gentoo-dev] [amd64-fbsd] remove charset.alias
On Wed, 11 Mar 2009 15:04:52 +0100
Alexis Ballier wrote:
> On Wed, 11 Mar 2009 14:16:29 +0100
> Timothy Redaelli wrote:
>
> > Hi,
> > I'm creating the amd64 porting of Gentoo/FreeBSD (with multilib
> > support).
> >
> > The problem is that some [1] ebuilds removes
> > directly "${D}"/usr/lib/charset.alias and
> > not "${D}"/usr/$(get_libdir)/charset.alias.
>
> What about a epunt_charset_alias function in eutils? That would for
> sure factorize that code.
Forget about this per Mike's comment; imho that's just
default/bsd/fbsd/profile.bashrc that needs fixing.
Alexis.
signature.asc
Description: PGP signature
[gentoo-dev] Last rites: dev-texlive/texlive-langmanju
# Merged in dev-texlive/texlive-langmongolian-2008, use that instead # Masked for removal on 15 June 2009 dev-texlive/texlive-langmanju Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
On Fri, 24 Feb 2012 18:56:44 +0100 ""Paweł Hajdan, Jr."" wrote: > Currently preserve_old_lib functions generate two commands per > preserved lib: > > # revdep-rebuild --library '/usr/lib/libv8.so.3.9.4' > # rm '/usr/lib/libv8.so.3.9.4' > > I'd like to modify eutils.eclass to only generate one command: > > # revdep-rebuild --library '/usr/lib/libv8.so.3.9.4' && \ > rm '/usr/lib/libv8.so.3.9.4' > > What do you think? > +1 moreover the && wont delete the lib if revdep-rebuild failed i think, so it should be even safer to copy/paste :) A.
Re: [gentoo-dev] Ruby keywording
On Wed, 07 Mar 2012 08:00:16 +0100 ""Paweł Hajdan, Jr."" wrote: > > Also the inter-bug dependencies are often not resolved correctly, > > that is the to be keyworded package depends on non-keyworded stuff > > not listed in the bug. > > And this is even worse. Please check things with repoman before filing > bugs. You can even write automated scripts at least for the "check > whether we got all deps right" part. As a maintainer I can tell you that when you drop keywords on B because it needs non keyworded A, then drop keywords on C because it needs latest B then drop keywords on D because it needs latest C, you have completely forgotten that some arches need A, which ones, etc. There are scripts for this, and I hope arch teams that like to have a list use them. As occasionally doing fbsd keywording, I almost never read nor use a list that is provided since the above scenario often occurs (or at least used to). Instead of this, I do a depth-first keywording of packages repoman tells are missing. The deepest package is in the latest tab of my terminal emulator :) I'll run repoman anyway, and this approach allows a double checking. Also, since this means I'll start committing from the leaves of the depgraph, this ensures no package has broken deps between commits (with the exception of circular deps of course). A.
Re: [gentoo-dev] Ruby keywording
On Wed, 7 Mar 2012 15:54:49 +0100 Thomas Kahle wrote: > On 09:25 Wed 07 Mar 2012, Alexis Ballier wrote: > > On Wed, 07 Mar 2012 08:00:16 +0100 > > ""Paweł Hajdan, Jr."" wrote: > > > > Also the inter-bug dependencies are often not resolved > > > > correctly, that is the to be keyworded package depends on > > > > non-keyworded stuff not listed in the bug. > > > > > > And this is even worse. Please check things with repoman before > > > filing bugs. You can even write automated scripts at least for > > > the "check whether we got all deps right" part. > > > > As a maintainer I can tell you that when you drop keywords on B > > because it needs non keyworded A, then drop keywords on C because > > it needs latest B then drop keywords on D because it needs latest > > C, you have completely forgotten that some arches need A, which > > ones, etc. There are scripts for this, and I hope arch teams that > > like to have a list use them. > > What scripts are out there? I just do iterated repoman calls without > much automation (pretty much as described below). Got anything > better? -> please post it! > gnome team posts nice lists afaik: http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=blob;f=scripts/gen_archlist.py
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Wed, 7 Mar 2012 21:41:02 +0100 Ulrich Mueller wrote: > Hi all, > > The way how we currently specify the EAPI in ebuilds has some > problems. For example, there is no sane way to allow usage of features > of a new bash version in a new EAPI. So we are currently stuck with > bash 3.2. Also changes of global scope behaviour, like addition of new > global scope functions (similar to "inherit") are not possible. > > These flaws are outlined in GLEP 55 [1]: > | In order to get the EAPI the package manager needs to source the > | ebuild, which itself needs the EAPI in the first place. Otherwise it > | imposes a serious limitation, namely every ebuild, using any of the > | future EAPIs, will have to be source'able by old package managers > | [...] > > The council has voted down GLEP 55 more than a year ago, but at the > same time requested that a solution for the mentioned issues should be > found. [2] However, there was no progress since then. > > The issue arose again in bug 402167 [3] where several solutions have > been discussed. Below, I try to summarise the possible options > resulting from that discussion. > > > *** Proposal 1: "Parse the EAPI assignment statement" *** > > This first proposal would require that the syntax of the EAPI > assignment statement in ebuilds matches a well defined regular > expression. A scan of the Portage tree shows that the statement only > occurs in the following variations (using EAPI 4 as example): > >EAPI=4 >EAPI="4" >EAPI='4' > > Sometimes this is followed by whitespace or a comment (starting with > a # sign). Also, with very few exceptions the EAPI assignment occurs > within the first few lines of the ebuild. For the vast majority of > ebuilds it is in line 5. > > Written in a more formal way, appropriate for a specification: > - Ebuilds must contain at most one EAPI assignment statement. > - It must occur within the first N lines of the ebuild (N=10 and N=30 > have been suggested). > - The statement must match the following regular expression (extended > regexp syntax): > ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$ > > Note: The first and the third point are already fulfilled by all > ebuilds in the Portage tree. The second point will require very few > ebuilds to be changed (9 packages for N=10, or 2 packages for N=30). > > The package manager would determine the EAPI by parsing the assignment > with above regular expression. A sanity check would be added. Citing > Zac Medico in [3]: "The fact that we can compare the probed EAPI to > the actual EAPI variable after the ebuild is sourced seems like a > perfect sanity check. We could easily detect inconsistencies and flag > such ebuilds as invalid, providing a reliable feedback mechanism to > ebuild developers." > > This proposal comes in two variants: > 1a) The change is applied retroactively for all EAPIs. > 1b) It is only applied for EAPI 5 and later (which means that the > result of the EAPI parsing would be discarded for earlier EAPIs). +1 for the whole proposal, this seems to be solving the problem and is the less intrusive change As i understand it, $PM will need to try the regexp tingy on any ebuild anyway, guess the EAPI then source the ebuild with the right sourcer to get the real EAPI and compare it. So, for me, the proposal is retroactive. The check whether guessed and actual EAPI are the same can be made a warning, or just ignored, in EAPI<5 and fatal in >=5 though. A.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Thu, 8 Mar 2012 20:04:55 +0100
Ulrich Mueller wrote:
> > Err... so what happens if 'new parsing' detects EAPI 4 and 'old
> > parsing' detects EAPI 5?
>
> This cannot happen for a legal ebuild:
> - If the ebuild is EAPI 4, then sourcing it ("old parsing") must
> detect EAPI 4.
the problem here may be when "old parsing" will wrongly parse a
malformed EAPI 42 assignment (so that new parsing doesnt detect an
EAPI and assumes its 0) as EAPI 4.
this is a purely hypothetical scenario that will be easily detected if
it ever happens, though :)
anyway, "new parsing" != "old parsing" should trigger a repoman
warning for old EAPIs.
A.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Thu, 8 Mar 2012 19:31:16 + Ciaran McCreesh wrote: > On Thu, 8 Mar 2012 20:17:41 +0100 > Ulrich Mueller wrote: > > In one of them, removal of the old assignment statement had simply > > been forgotten [1]. For the other two, the EAPI had been assigned by > > an eclass [2], which we consider illegal anyway. > > ...and yet people do it. That and the violations of the HOMEPAGE rule > tell you a lot about what happens when something is made syntactically > valid but supposedly not legal. > ... and this is where repoman helps. broken deps are syntactically valid but not legal either.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Fri, 09 Mar 2012 07:41:09 -0800 Zac Medico wrote: > On 03/09/2012 07:21 AM, Michael Orlitzky wrote: > > The advantage that the eapi function has over a comment is that > > it's not magic -- it's just normal bash syntax. So we've addressed > > that issue at a small performance cost (we're really only sourcing > > the ebuild up to 'exit'). > > Also consider the case where a user syncs after not having updated > for a couple of months, and the tree contains some ebuilds with EAPIs > that are not supported by the currently installed package manager. > > In this case, when resolving dependencies and filtering ebuilds based > on whether or not their EAPI is supported, spawning bash once per > ebuild is much more costly than the alternatives. isnt the whole point of the proposal to get eapi without sourcing ? so that we can use new bash features at local or global scope without risking that people with an old bash get syntax errors trying to get the eapi
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Fri, 9 Mar 2012 18:02:51 + James Broadhead wrote: > On 9 March 2012 17:31, Michael Orlitzky wrote: > > At any rate, I'm now convinced that we all want GLEP 55, but with a > > different name. > > I think that moving the data to the filename is probably a better > approach than semi- or repeat parsing, but I prefer preserving the > .ebuild extension, and think that eapi should be specified similarly > to ebuild revision, as a suffix. for instance: > > app-foo/bar-1.0.0-r1.ebuild # EAPI0 (or the highest EAPI prior to the > new schema) > app-foo/bar-1.0.0-r1-e1.ebuild > app-foo/bar-1.0.0-r1-e99.ebuild > if you want to keep .ebuild you need to keep current naming, afaik package managers fail on invalid names
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/ffmpeg: ffmpeg-0.10.2.ebuild ChangeLog
On Mon, 19 Mar 2012 07:46:40 +0200
Samuli Suominen wrote:
> On 03/19/2012 07:39 AM, Ryan Hill wrote:
> > On Sun, 18 Mar 2012 13:54:03 + (UTC)
> > "Alexis Ballier (aballier)" wrote:
> >
> >> aballier12/03/18 13:54:03
> >>
> >>Modified: ChangeLog
> >>Added:ffmpeg-0.10.2.ebuild
> >>Log:
> >>version bump
> >>
> >>(Portage version: 2.2.0_alpha91/cvs/Linux x86_64)
> >
> >
> >> FFTOOLS="aviocat cws2fws ffeval graph2dot ismindex pktdumper
> >> qt-faststart trasher"
> >>
> >> for i in ${FFTOOLS}; do
> >>IUSE="${IUSE} +$i"
> >> done
> >
> >
> > Is it really useful to have such fine-grained control over these?
> > ffmpeg already has a ton of USE flags. Would you consider just
> > putting these under "tools" or something?
>
> I'd prefer to drop all USE flags which don't have external deps and
> just always install them
>
> (We actually discussed this with beandog on #gentoo-media month ago
> or something, and he suggested same)
>
imho it doesnt hurt anyone to have fine-grained control
what could be discussed is to put these into a use expand variable, to
better distinguish between important useflags and less important ones
is that what you mean by 'putting these under "tools" or something?' ?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/ffmpeg: ffmpeg-0.10.2.ebuild ChangeLog
On Mon, 19 Mar 2012 21:15:45 -0600 Ryan Hill wrote: > On Mon, 19 Mar 2012 15:05:46 -0300 > Alexis Ballier wrote: > > > imho it doesnt hurt anyone to have fine-grained control > > > > what could be discussed is to put these into a use expand variable, > > to better distinguish between important useflags and less important > > ones > > > > is that what you mean by 'putting these under "tools" or > > something?' ? > > No, I meant one USE flag, called "tools", that builds and installs > all or none of them. Unless they have external dependencies, or > extraordinary build times, or licensing issues, then I can't see a > situation where someone would want or need to pick and choose like > this. If you disagree then I suppose an expanded variable is an > improvement, though I don't like them myself. > > Kudos on the USE flag descriptions in any case. Very informative. well, there's no extra dep nor licensing issue, and its not that they are big either, problem is with a merged useflag to rule them all we'll lose all the descriptions; i can imagine: tools - install random extra tools vs. a per tool useflag describing what it is for i clearly prefer the latter, even if it requires me 5 more minutes to decide the fate of the useflags i'll build the package with personally i dont like the tools useflag, the same i dont like the server one or the minimal one. they're too generic and, for this reason, useless if we want to make it a use expand, the only thing we need to agree on is the prefix i think: what about fftools ? ffmpegtools ?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/ffmpeg: ffmpeg-0.10.2.ebuild ChangeLog
On Tue, 20 Mar 2012 12:06:30 +0200 Samuli Suominen wrote: > > if we want to make it a use expand, the only thing we need to agree > > on is the prefix i think: what about fftools ? ffmpegtools ? > > > > Maybe there could be use expand that could be reused by other ebuilds > too? Such as EXTERNAL_TOOLS ? is it really worth it ? these are by design package specific, so i dont see any gain in trying to merge them under an arbitrary common namespace fftools is generic enough to me so that libav ebuilds can adopt it too, if that's what matters
Re: [gentoo-dev] Fix spurious dep to eselect-python
On Tue, 20 Mar 2012 20:35:17 +0100
Arfrever Frehtes Taifersar Arahesis wrote:
> 2012-03-20 17:53:56 Michał Górny napisał(a):
> > On Tue, 20 Mar 2012 17:41:39 +0100
> > Arfrever Frehtes Taifersar Arahesis wrote:
> >
> > > 2012-03-20 05:29:20 Luca Barbato napisał(a):
> > > > Hi, I tried to avoid depending on eselect-python if the useflag
> > > > is disabled.
> > > >
> > > > Please test and review.
> > >
> > > The proper fix is to make python.eclass add dependency on
> > > app-admin/eselect-python only when ${CATEGORY}/${PN} is
> > > dev-lang/python, dev-java/jython or dev-python/pypy. See bug
> > > #341037.
> >
> > Couldn't we just push that dependency to the specific ebuilds?
>
> We want to control required version (>=20091230 in case of
> app-admin/eselect-python) in 1 place.
>
this can be achieved by setting a variable that said ebuilds will append
to (R)DEPEND; no need for complex 'if then else' on CAT/PN in an eclass
for this.
Re: [gentoo-dev] Fix spurious dep to eselect-python
On Tue, 20 Mar 2012 17:57:29 -0300
Alexis Ballier wrote:
> On Tue, 20 Mar 2012 20:35:17 +0100
> Arfrever Frehtes Taifersar Arahesis wrote:
>
> > 2012-03-20 17:53:56 Michał Górny napisał(a):
> > > On Tue, 20 Mar 2012 17:41:39 +0100
> > > Arfrever Frehtes Taifersar Arahesis wrote:
> > >
> > > > 2012-03-20 05:29:20 Luca Barbato napisał(a):
> > > > > Hi, I tried to avoid depending on eselect-python if the
> > > > > useflag is disabled.
> > > > >
> > > > > Please test and review.
> > > >
> > > > The proper fix is to make python.eclass add dependency on
> > > > app-admin/eselect-python only when ${CATEGORY}/${PN} is
> > > > dev-lang/python, dev-java/jython or dev-python/pypy. See bug
> > > > #341037.
> > >
> > > Couldn't we just push that dependency to the specific ebuilds?
> >
> > We want to control required version (>=20091230 in case of
> > app-admin/eselect-python) in 1 place.
> >
>
> this can be achieved by setting a variable that said ebuilds will
> append to (R)DEPEND; no need for complex 'if then else' on CAT/PN in
> an eclass for this.
>
or also by adding a new python-implementation.eclass instead of
polluting an eclass used by hundreds of packages for only 3 special
ones...
Re: [gentoo-dev] Fix spurious dep to eselect-python
On Tue, 20 Mar 2012 17:09:55 -0400
Mike Gilbert wrote:
> On Tue, Mar 20, 2012 at 5:05 PM, Alexis Ballier
> wrote:
> > On Tue, 20 Mar 2012 17:57:29 -0300
> > Alexis Ballier wrote:
> >
> >> On Tue, 20 Mar 2012 20:35:17 +0100
> >> Arfrever Frehtes Taifersar Arahesis wrote:
> >>
> >> > 2012-03-20 17:53:56 Michał Górny napisał(a):
> >> > > On Tue, 20 Mar 2012 17:41:39 +0100
> >> > > Arfrever Frehtes Taifersar Arahesis
> >> > > wrote:
> >> > >
> >> > > > 2012-03-20 05:29:20 Luca Barbato napisał(a):
> >> > > > > Hi, I tried to avoid depending on eselect-python if the
> >> > > > > useflag is disabled.
> >> > > > >
> >> > > > > Please test and review.
> >> > > >
> >> > > > The proper fix is to make python.eclass add dependency on
> >> > > > app-admin/eselect-python only when ${CATEGORY}/${PN} is
> >> > > > dev-lang/python, dev-java/jython or dev-python/pypy. See bug
> >> > > > #341037.
> >> > >
> >> > > Couldn't we just push that dependency to the specific ebuilds?
> >> >
> >> > We want to control required version (>=20091230 in case of
> >> > app-admin/eselect-python) in 1 place.
> >> >
> >>
> >> this can be achieved by setting a variable that said ebuilds will
> >> append to (R)DEPEND; no need for complex 'if then else' on CAT/PN
> >> in an eclass for this.
> >>
> >
> > or also by adding a new python-implementation.eclass instead of
> > polluting an eclass used by hundreds of packages for only 3 special
> > ones...
> >
>
> A four-way if-then statement is not what I would call "complex". This
> was already present in the eclass anyway, so there is no additional
> "pollution".
a four-way if-then with pattern matching / strcmp is slower than a
constant variable assignment; it could matter when this is done
everytime an ebuild inheriting it is sourced. it probably doesnt, but
imho, its good practice to keep global scope code in eclasses as simple
as possible.
[gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
Hi,
Oasis [1] is becoming the de factor standard for ocaml packages. I've
been bored of copy/pasting always the same code from ebuilds to ebuilds
and thus decided to write an eclass simplifying everything.
Attached: said eclass, a diff of a random dev-ml package I've
converted to illustrate and said random ebuild now.
Comments welcome,
Alexis.
[1] http://oasis.forge.ocamlcore.org/
oasis.eclass
Description: Binary data
Index: fieldslib-0.1.2.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/dev-ml/fieldslib/fieldslib-0.1.2.ebuild,v
retrieving revision 1.1
diff -u -B -r1.1 fieldslib-0.1.2.ebuild
--- fieldslib-0.1.2.ebuild 25 Jun 2011 18:56:36 - 1.1
+++ fieldslib-0.1.2.ebuild 23 Mar 2012 08:13:31 -
@@ -3,7 +3,7 @@
# $Header: /var/cvsroot/gentoo-x86/dev-ml/fieldslib/fieldslib-0.1.2.ebuild,v 1.1 2011/06/25 18:56:36 aballier Exp $
EAPI="2"
-inherit findlib multilib
+inherit oasis
DESCRIPTION="Folding over record fields"
HOMEPAGE="http://www.janestreet.com/ocaml";
@@ -12,28 +12,9 @@
LICENSE="LGPL-2.1-linking-exception"
SLOT="0"
KEYWORDS="~amd64"
-IUSE="debug +ocamlopt"
+IUSE=""
-DEPEND=">=dev-lang/ocaml-3.12[ocamlopt?]
- >=dev-ml/type-conv-2.3.0"
+DEPEND=">=dev-ml/type-conv-2.3.0"
RDEPEND="${DEPEND}"
-oasis_use_enable() {
- echo "--override $2 `use $1 && echo \"true\" || echo \"false\"`"
-}
-
-src_configure() {
- ./configure --prefix usr \
- --libdir /usr/$(get_libdir) \
- --destdir "${D}" \
- $(oasis_use_enable debug debug) \
- $(oasis_use_enable ocamlopt is_native) \
- || die
-}
-
-src_install() {
- findlib_src_install
-
- # install documentation
- dodoc README || die
-}
+DOCS=( "README" )
fieldslib-0.1.2.ebuild
Description: Binary data
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, 23 Mar 2012 11:58:47 -0400
Mike Gilbert wrote:
> On Fri, Mar 23, 2012 at 4:15 AM, Alexis Ballier
> wrote:
>
> > DEPEND=">=dev-lang/ocaml-3.12[ocamlopt?]"
> > DEPEND="${RDEPEND}"
>
> That looks like a typo.
yes, thanks for spotting
>
> > oasis_src_compile() {
> > oasis_src_compile_no_doc
> > if has doc ${IUSE} && use doc; then
> > ocaml setup.ml -doc || die
> > fi
> > }
>
> This should probably call use_if_iuse from eutils.eclass, which
> handles IUSE="[+-]doc".
>
hmm, actually, I like the idea of something like OASIS_WANT_DOCS as
suggested by Ciaran, this sounds simpler and, as a side effect, will
allow me to kill the useless oasis_src_compile_no_doc function.
I'll come back with something like this and post an update, most likely
next week, pilling up the reviews :=)
A.
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, 23 Mar 2012 23:11:46 +0300
Sergei Trofimovich wrote:
> > oasis_use_enable() {
> > echo "--override $2 `use $1 && echo \"true\" || echo
> > \"false\"`" }
>
> Mike added 'usex' to 'eutils.eclass' recently, so you might like to
> use it: (UNTESTED)
> echo "--override $2 $(usex $1 true false)"
it needs to print the quotes too, so this wont work
i've been copy/pasting this 'formula' for a while, i know it works, and
i am too lazy to try to rewrite it to usex just for the sake of it :)
>
> > oasis_src_configure() {
> > ocaml setup.ml -configure \
> > --prefix usr \
> > --libdir /usr/$(get_libdir) \
> > --docdir /usr/share/doc/${PF}/html \
> > --destdir "${D}" \
> > $(oasis_use_enable debug debug) \
> > $(oasis_use_enable ocamlopt is_native) \
> > ${oasis_configure_opts} \
> > || die
> > }
>
> This configure hates gentoo prefix, right?
> Might worth sprinkling "${EPREFIX}" around absolute paths.
>
well, this will imply not supporting eapi2, i can live with it
however, usually, i prefer prefix guys that need it to submit patches
instead of trying to support it without testing.
eg: shall it be EPREFIX before the /usr's ? shall it be ED instead of
D? both ?
A.
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Sat, 24 Mar 2012 00:02:15 +0300
Sergei Trofimovich wrote:
> > > > oasis_use_enable() {
> > > > echo "--override $2 `use $1 && echo \"true\" || echo
> > > > \"false\"`" }
> > >
> > > Mike added 'usex' to 'eutils.eclass' recently, so you might like
> > > to use it: (UNTESTED)
> > > echo "--override $2 $(usex $1 true false)"
> >
> > it needs to print the quotes too, so this wont work
>
> It did not print quotes:
> $ echo "--override bazz `true && echo \"true\" || echo \"false\"`"
> --override bazz true
hu? i was pretty sure it was needed, but you're right, i dont know what
i was trying to achieve with those escaped quotes in there... i've
converted to your usex formula which is equivalent, thanks :)
> > > This configure hates gentoo prefix, right?
> > > Might worth sprinkling "${EPREFIX}" around absolute paths.
> > >
> >
> > well, this will imply not supporting eapi2, i can live with it
>
> Oh, right. I've forgot. Each EPREFIX usage would require something
> like the following:
>
> has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
not worth it, ocaml ebuilds are all eapi2 and the eapi2->3 migration is
quite straightforward, so there's no point in supporting
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, 23 Mar 2012 16:41:35 -0400
Alexandre Rostovtsev wrote:
> On Fri, Mar 23, 2012 at 4:24 PM, Alexis Ballier
> wrote:
> > On Fri, 23 Mar 2012 23:11:46 +0300
> > Sergei Trofimovich wrote:
> >> > oasis_src_configure() {
> >> > ocaml setup.ml -configure \
> >> > --prefix usr \
> >> > --libdir /usr/$(get_libdir) \
> >> > --docdir /usr/share/doc/${PF}/html \
> >> > --destdir "${D}" \
> >> > $(oasis_use_enable debug debug) \
> >> > $(oasis_use_enable ocamlopt is_native) \
> >> > ${oasis_configure_opts} \
> >> > || die
> >> > }
> >>
> >> This configure hates gentoo prefix, right?
> >> Might worth sprinkling "${EPREFIX}" around absolute paths.
> >>
> >
> > well, this will imply not supporting eapi2, i can live with it
> >
> > however, usually, i prefer prefix guys that need it to submit
> > patches instead of trying to support it without testing.
> > eg: shall it be EPREFIX before the /usr's?shall it be ED instead of
> > D? both ?
>
> You probably want ${EPREFIX} in front of every /usr passed to
> configure. In other words,
>
> ocaml setup.ml -configure --prefix "${EPREFIX}/usr" --libdir
> "${EPREFIX}/blah" --docdir "${EPREFIX}/blargh" etc.
>
> However, destdir should still be ${D}. That way, in src_install() your
> package's files will be copied to ${D}${EPREFIX}/usr, better known as
> ${ED}usr.
will do that since it doesnt hurt, but it'll require testing anyway.
thanks for the explanations, but then beware of the findlib_src_preinst
call in src_install, which sets a variable so that findlib installs
stuff in $D; if at some point this will be changed to $ED for some
reason then oasis+findlib packages may go in a double prefix...
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
eclass version 2.0, i hope i haven't forgotten any comment I improved some comments/description after a second read also. oasis.eclass Description: Binary data
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Sat, 24 Mar 2012 10:44:03 -0300 Alexis Ballier wrote: > eclass version 2.0, i hope i haven't forgotten any comment > > I improved some comments/description after a second read also. since there were no more comments: eclass committed, thanks all
Re: [gentoo-dev] New License: FreeBSD License
On Wed, 28 Mar 2012 22:00:17 -0400 Richard Yao wrote: > > You are right. I spoke to ulm about this and the disclaimer can be > considered separate from the license. Gentoo/FreeBSD will need to > switch to BSD-2, but aside from that, there is no need for a new > license. > grep shows that a lot of files in freebsd source tree have a 3 clause bsd; if you can identify files with a BSD-2 license, then you can append it to the LICENSE field, but a switch is incorrect A.
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On Fri, 30 Mar 2012 12:34:26 -0400 Richard Yao wrote: > I wrote sys-freebsd/virtio-kmod (bug 410199) while studying > Gentoo/FreeBSD as part of an attempt to port gptzfsloader to Gentoo > Linux. naota wrote an improvement that would be useful to send > upstream. However, the GPL-2 license poses a problem according to > conversations that I had in #gentoo-dev. > if he wrote the improvement, he can send it upstream under whatever license he wants; generally, it is implicit that a patch follows the same license as the code it applies to, esp. when the author himself agrees to share it with upstream. > While I have asked naota for permission to upstream the line he wrote, > this poses a more general issue for collaboration, especially if I > port more kernel modules from FreeBSD Ports. > > Would it be possible to relicense sys-freebsd/* under terms of the > BSD-2 license? > what do you mean by 'relicense' ? for ebuilds, you'll have to ask permission to all contributors to this area, and, afaik, the foundation owns copyrights so it has a word to say too. if you mean the 'LICENSE' field of ebuilds, then this is not the right place to ask. A.
Re: [gentoo-dev] Packages maintained by trapni need a co-maintainer
On Sat, 14 Apr 2012 14:36:48 +0300 Samuli Suominen wrote: > On 04/14/2012 02:31 PM, Pacho Ramos wrote: > > El sáb, 14-04-2012 a las 14:24 +0300, Samuli Suominen escribió: > >> On 04/14/2012 02:16 PM, Pacho Ramos wrote: > >>> Due long devaway, his packages need a co-maintainer, feel free to > >>> add to metadata if you want. Thanks: > >>> dev-util/ciabot-svn > >>> media-sound/teamspeak-client-bin > >>> media-sound/teamspeak-server-bin > >>> sys-apps/newrelic-sysmond > >>> > >> > >> I believe it's time to lastrite teamspeak* because they link > >> against mysql libraries with SONAME we don't ship anymore > >> Therefore rendering the packages useless > >> > >> - Samuli > >> > >> > > > > Fine with me if nobody wants to take care of that package and > > fixing it soon > > I'm not sure if it's possible to fix them because symlinking the old > SONAME to new one doesn't do the trick. > > Rebuilding is not an option because they are binary-only. > > Unless someone grabs a HEX editor or something and edits the binaries > directly ... good luck with that if that's just a soname problem an not an actual abi problem (heh, soname may have changed for a reason), then dev-java/diablo-jdk has been doing this for years and you can probably use the same kind of code. A.
Re: [gentoo-dev] About adding a way to check for bugs referring to no longer existing packages in the tree
On Sat, 14 Apr 2012 13:02:27 +0200 Pacho Ramos wrote: > Hello > > From time to time I see old bug reports that are still wrongly opened > and referring to old packages no longer in the tree. Would be possible > to add a way to periodically check for bugs referring in summary to > obsolete packages and, then, allow us to have a cleaner bug list? -1, you really cant automate this. - for eg, keyword req, the version doesnt really matter and is usually just there to help but should really be read as latest version; closing/ignoring the bug while the latest version still lacks the keywords is just wrong. - for stablereq, that's a different story - for other bugs, some may have been fixed independently upstream, but usually, they dont fix by themselves, so if a bug didnt get attention, chances are its still valid. moreover, doing this, you'll just encourage people not to fill the version IOW: If you want a cleaner bug list, ignore stable/kw reqs, then pay attention to your bugs and fix them :) A.
Re: [gentoo-dev] USE=gui?
On Mon, 16 Apr 2012 11:22:22 +0300 Samuli Suominen wrote: > On 04/16/2012 11:11 AM, Michał Górny wrote: > > On Tue, 10 Apr 2012 09:12:16 +0200 > > ""Paweł Hajdan, Jr."" wrote: > > > >> On 4/10/12 8:58 AM, Pacho Ramos wrote: > >>> Other option would be to enable "wxwidgets" by default for that > >>> profiles. > >> > >> I prefer this. Changing USE flag meaning in a counter-intuitive way > >> (to let "gtk" mean "wxwidgets") would seem frustrating to me. > >> > >> With "wxwidgets" enabled by default people will get the most likely > >> desired result (i.e. GUI) "out of the box", and setting > >> USE="-wxwidgets" will have desired effect. > >> > >> Note that with USE="gtk" really meaning USE="wxwidgets", -wxwidgets > >> would have no effect on such a package, which is the potentially > >> surprising behavior I mentioned earlier. > > > > On the other hand, we should ask ourselves whether the USE flags are > > very intuitive right now. > > > > Say, we have USE=ssl which enables SSL support. We already agreed > > that's the correct meaning of it, and USE=gnutls,openssl,nss are > > just to be used when there's more than one implementation to choose > > from. > > USE=ssl is also meaning OpenSSL and there should be no USE=openssl > > > > Shouldn't we have USE=gui in a similar fashion? Most of the devs > > probably prefer the way 'I want GUI only if it's using my favorite > > toolkit'. But users OTOH may prefer saying 'I want GUI in this app, > > no matter what it uses'. > > > > This would probably handle the wxwidgets case most correct, having > > it under USE=gui or similar. > > > > -1, this would only add inconsistency / complexity to tree with > packages having multiple graphical toolkits to pick from > > should be kept the way it is or maybe adding useflag properties in a future eapi, or meta useflags abusing REQUIRED_USE: gui? ( || ( wxwidgets gtk fltk ) ) and then the PM could support 'I want GUI in this app, no matter what it uses' by automatically adding the first pick to package.use not sure if its desirable though
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Thu, 26 Apr 2012 15:15:34 -0400 Matt Turner wrote: > On Thu, Apr 26, 2012 at 1:01 PM, Christian Ruppert > wrote: > > I haven't followed the prev. conversation but what's wrong with a > > USE flag for SSE2? We already have SSE2 flags, even global.. > > That's not it. The flash binary uses SSE2 instructions without > checking for their presence, which causes bad things on systems > without SSE2. The purpose of the 'sse2check' flag was to die if the > system doesn't have SSE2 and print a message telling the user to use > an older version of flash. > > The relevant bug is https://bugs.gentoo.org/show_bug.cgi?id=410547 > wouldnt adding a sse2 useflag and putting it in REQUIRED_USE solve the problem ? afaik portage wont even try to upgrade if people have -sse2 A.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Thu, 26 Apr 2012 23:19:04 -0600 Ryan Hill wrote: > On Thu, 26 Apr 2012 17:06:45 -0300 > Alexis Ballier wrote: > > > On Thu, 26 Apr 2012 15:15:34 -0400 > > Matt Turner wrote: > > > > > On Thu, Apr 26, 2012 at 1:01 PM, Christian Ruppert > > > wrote: > > > > I haven't followed the prev. conversation but what's wrong with > > > > a USE flag for SSE2? We already have SSE2 flags, even global.. > > > > > > That's not it. The flash binary uses SSE2 instructions without > > > checking for their presence, which causes bad things on systems > > > without SSE2. The purpose of the 'sse2check' flag was to die if > > > the system doesn't have SSE2 and print a message telling the user > > > to use an older version of flash. > > > > > > The relevant bug is https://bugs.gentoo.org/show_bug.cgi?id=410547 > > > > > > > wouldnt adding a sse2 useflag and putting it in REQUIRED_USE solve > > the problem ? > > > > afaik portage wont even try to upgrade if people have -sse2 > > I like that, but it doesn't address building on a host not supporting > SSE2 for a target that does. Why? Enable sse2 when cross-"building" and be done. Note: There's no more check via /proc/cpuinfo that way. A.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/traverso: traverso-0.49.2-r1.ebuild ChangeLog traverso-0.49.2.ebuild traverso-0.49.1.ebuild
> + 07 May 2012; Ben de Groot > + +files/traverso-0.49.2-desktop.patch, > +files/traverso-0.49.2-gold.patch, that patch is not portable, please fix > + +traverso-0.49.2-r1.ebuild, -traverso-0.49.1.ebuild, > -traverso-0.49.2.ebuild: this leaves a stray patch in files, please fix
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/traverso: traverso-0.49.2-r1.ebuild ChangeLog traverso-0.49.2.ebuild traverso-0.49.1.ebuild
On Mon, 7 May 2012 21:00:18 +0800 Ben de Groot wrote: > On 7 May 2012 20:35, Alexis Ballier wrote: > >> + 07 May 2012; Ben de Groot > >> + +files/traverso-0.49.2-desktop.patch, > >> +files/traverso-0.49.2-gold.patch, > > > > that patch is not portable, please fix > > I considered that, but these patches have been sent upstream, > so if all is well, then they can be dropped with the next release. > In case they won't be applied, I'd be happy to make them > more portable at that time. if you know that, please do the right thing... now... if a half-broken patch is applied, that's not because it's good, that's because the person applying it didn't think about the broken case... A. PS: feel free to take maintainership of the package.
[gentoo-dev] amd64-fbsd profile marked 'stable'
Hi, I've just marked the profile 'default/bsd/fbsd/amd64/9.0' as 'stable' in profiles.desc. I've been careful not to keyword anything with broken deps, and its now forbidden. It is the first g/fbsd profile marked as such. Consequences for devs: broken deps are not allowed anymore; people are, like for standard arches, expected to drop keywords and fill a rekeywording bug. Rationale: - x86-fbsd has been a 'dev' profile for so long that the majority of the packages have broken deps, meaning moving it to a 'stable' profile is almost impossible. I do not want to repeat this error for amd64-fbsd - people usually do not run repoman -d, and as such, it is common to get (core or not) packages that are uninstallable on g/fbsd. This wont happen anymore and will make devs and users happier :=) cons: there's no stable amd64-fbsd keyword, i suppose that if we want some day to stabilize it, it'll be hard with a 'stable' profile, but we can temporarily switch it back to 'dev' while doing it, and without preventing broken deps it'll be almost impossible to do this anyway. Regards, A.
[gentoo-dev] The fate of sparc-fbsd: not supported anymore, keywords can be dropped at will.
Hi, Time has passed, nobody has been working on it in the past couple of years and I believe it is now time to make an official announce so that everyone knows: The sparc-fbsd arch is dead. People are free to drop the keywords at will. It has reached a state that it'll probably be simpler to start from scratch. The last development for this arch I can remember was when Monkeh gave me access to a sparc box where I had installed sparc-fbsd, some years ago. When the box died, we decided the pain was not worth the gain, and nothing I can remember has happened since then. Of course, this does not prevent anyone from resurrecting the port, but until further notice, people are free to drop ebuilds even if it is the last keyworded version for the sparc-fbsd arch. Regards, A.
Re: [gentoo-dev] amd64-fbsd profile marked 'stable'
On Tue, 8 May 2012 15:44:09 +0200 Ulrich Mueller wrote: > >>>>> On Tue, 8 May 2012, Alexis Ballier wrote: > > > I've just marked the profile 'default/bsd/fbsd/amd64/9.0' as > > 'stable' in profiles.desc. I've been careful not to keyword > > anything with broken deps, and its now forbidden. It is the first > > g/fbsd profile marked as such. > > > [...] > > > cons: there's no stable amd64-fbsd keyword, i suppose that if we > > want some day to stabilize it, it'll be hard with a 'stable' > > profile, but we can temporarily switch it back to 'dev' while doing > > it, and without preventing broken deps it'll be almost impossible > > to do this anyway. > > This has as another consequence that we cannot extract the state of > keywords from profiles.desc any more. So we need to find a different > solution for bug 304133. > > Any ideas? one of these maybe: 1) check if there's something starting with ~ in ACCEPT_KEYWORDS from make.default (probably slow); 2) generate that list from profile's make.default when building gentoolkit-dev 3) what are the usecases of ekeyword all ? noarch no deps packages ? in that case i dont really mind amd64-fbsd being included 4) make ekeyword all use the union of stable keywords of current package (probably saner as that wont bring in new stable keywords by mistake) 5) create a new profile state meaning 'no stable keyword but broken deps are errors' A.
Re: [gentoo-dev] amd64-fbsd profile marked 'stable'
On Wed, 09 May 2012 19:29:36 +0300 Alexey Shvetsov wrote: > Hi! > > May be you can share stages and install instructions for this? > https://bugs.gentoo.org/show_bug.cgi?id=415229 :) (make sure to read the thread linked from this bug report)
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/ffmpeg: ffmpeg-9999.ebuild ffmpeg-0.10.3-r1.ebuild ChangeLog
On Thu, 17 May 2012 13:58:01 + (UTC) "Tomas Chvatal (scarabeus)" wrote: > scarabeus12/05/17 13:58:01 > > Modified: ffmpeg-.ebuild ChangeLog > Added:ffmpeg-0.10.3-r1.ebuild > Log: > Disable postproc in here and use the common library that will be > used by both libav and ffmpeg (eases dependency writting). > (Portage version: 2.2.0_alpha107/cvs/Linux x86_64) > I'm sorry, but where has this been discussed ? Now that we have regular releases, why are we back at taking snapshots of some random subset of it ? Moreover some random subset that has not yet merged some commits from ffmpeg back from february... if ffmpeg has not removed libpostproc, maybe there's a reason, that reason might be that they still want to maintain it in their own tree... im reverting your commit atm, with a proper temporary solution for the virtual; feel free to write the || dep for the 3 or 4 packages that need postproc if you want to make it optional. A.
Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass
On Mon, 21 May 2012 01:24:13 +0200 hasufell wrote: > I want support for installing icons into the appropriate directories > which are under /usr/share/icons/... and not just pixmaps. > > proposal attached + diff > > This should not break existing ebuilds. Tested a bit and open for > review now. maybe i missed something but cant you just make doicon a newicon wrapper and remove all that code duplication ?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-misc/lightdm: lightdm-1.2.2-r2.ebuild ChangeLog
On Thu, 21 Jun 2012 16:42:11 +0800 Ben de Groot wrote: > > And users might > > still have older gobject-introspection installed, with nothing > > forcing the upgrade now. > > Regular maintenance should take care of that. We are not in the > habit of specifying minimal versions for all dependencies. yes we are, if you are not then you should change this. things like https://bugs.gentoo.org/show_bug.cgi?id=266293 are perfectly valid bugs and annoy users. its not because you hadnt had a bug report that its not worth preventing it. A.
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 17:12:04 +0100 Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 17:20:23 +0300 > Mart Raudsepp wrote: > > > The 'standard' behaviour (which can be changed by the user) for > > > Paludis when doing "complete" resolutions is that whenever there's > > > a slot of something installed, it will try to bring in the newest > > > version of that package, even if it's in a different slot. This is > > > generally a good thing, since newer versions are supposed to be > > > better than older versions. The problem is that now "newer" > > > versions are being used to mean "with a different Ruby > > > implementation" or "built in a different way", which screws up the > > > meaning. > > > > Don't do that if the slotted package in question is not in the > > @world, and all packages depending on it strictly require the older > > SLOT. > > That is an option Paludis provides for users, but doing so leads to > old versions of things lying around when an upgrade is preferred. When exactly ? You took the gcc example, but it does not have a slot specified in the 'packages' file so should be upgraded regardless of slot. > It's also incorrect behaviour when multiple slots are capable of > satisfying a dependency. I suppose that is what Mart meant with 'strictly require'. I do not know about ruby stuff, but the gtk2/gtk3 case seems a non-issue to me. - No slot specified -> best version available, slot independent. - Slot specified -> best version in said slot. - Upgrade to new version in a different slot iff something brings in the new slot. If your heuristic brings in gtk3 when everything depends on gtk2, you should probably rethink your heuristic. A.
Re: [gentoo-dev] freebsd.eclass change
On Sun, 1 Jul 2012 19:48:58 -0400
Richard Yao wrote:
> I want to add freebsd_get_cpuarch() to freebsd.eclass. This will give
> us a platform-independent way of generating MACHINE_CPUARCH, which
> will make building FreeBSD components on other platforms (i.e. Linux
> and Prefix) easier.
>
> --- freebsd.eclass.old 2012-07-01 19:15:56.157277000 -0400
> +++ freebsd.eclass 2012-07-01 19:44:08.093698000 -0400
> @@ -58,6 +58,24 @@ freebsd_get_bmake() {
> echo "${bmake}"
> }
>
> +freebsd_get_cpuarch() {
> + local arch=$(uname -m)
> + case $(uname -m) in
> + x86_64)
> + return 'amd64';;
> + arm*)
> + return 'arm';;
> + i?86)
> + return 'i386';;
> + ppc*)
> + return 'powerpc';;
> + mips*)
> + return 'mips';;
> + sparc*)
> + return 'sparc';;
> + *)
> + return arch;
> + esac
> +}
> +
> freebsd_do_patches() {
> if [[ ${#PATCHES[@]} -gt 1 ]] ; then
> for x in "${PATCHES[@]}"; do
>
> Does anyone have any objections?
>
hu? yes, as already pointed out, uname is not reliable when
cross-compiling. You should use CHOST, and then you get tc-arch-kernel.
See freebsd-lib ebuild for how it is handled.
A.
Re: [gentoo-dev] freebsd.eclass change
On Mon, 02 Jul 2012 14:09:26 -0400
Richard Yao wrote:
> On 07/02/2012 02:02 PM, Mike Frysinger wrote:
> > On Monday 02 July 2012 13:37:53 Richard Yao wrote:
> >> On 07/02/2012 10:54 AM, Alexis Ballier wrote:
> >>> hu? yes, as already pointed out, uname is not reliable when
> >>> cross-compiling. You should use CHOST, and then you get
> >>> tc-arch-kernel. See freebsd-lib ebuild for how it is handled.
> >>
> >> In that case, it should be 'local arch=$(tc-arch-kernel)'. Using
> >> tc-arch-kernel by itself causes problems when building on Linux,
> >> because x86 can be passed, which FreeBSD's build system does not
> >> understand.
> >
> > the function specifically handles freebsd in this case. why isn't
> > that code sufficient ?
> >
> >> Also, this function is not meant for cross compilation.
> >
> > then it doesn't really belong in the tree. native builds are just
> > a special case of cross-compiling.
> > -mike
>
> The idea is to use this to assist in building parts of FreeBSD on
> Linux for Linux (or on Prefix for whatever platform it runs). Anyway,
> I will keep this in ebuilds until it has several ebuilds using it.
> Then we can revisit it.
>
you probably want something like:
tc-arch-kernel "${CHOST%%-*}-gentoo-freebsd9.0"
then
we do not really care about the version suffix in tc-arch functions, so
you can also omit it.
A.
Re: [gentoo-dev] base.eclass
On Sun, 8 Jul 2012 22:10:02 +0200 Michał Górny wrote: > On Sun, 08 Jul 2012 19:49:25 +0200 > René Neumann wrote: > > > Hi all, > > > > I'd like just to receive a short clarification about the 'status' of > > base.eclass: Is this eclass expected to be available everywhere, > > i.e. should each eclass make sure it imports and incorporates it. > > Or is it just an eclass like the others and ebuilds should make > > sure they inherit it if needed? > > No. It is unmaintained, has serious design flaws and it simply should > not be used anywhere. At least in EAPI != [01]. > what is the PATCHES=() replacement in new eapis? (mainly why i use base.eclass more and more these days)
Re: [gentoo-dev] base.eclass
On Mon, 9 Jul 2012 08:39:38 +0200
Michał Górny wrote:
> On Sun, 8 Jul 2012 17:35:08 -0400
> Alexis Ballier wrote:
>
> > On Sun, 8 Jul 2012 22:10:02 +0200
> > Michał Górny wrote:
> >
> > > On Sun, 08 Jul 2012 19:49:25 +0200
> > > René Neumann wrote:
> > >
> > > > Hi all,
> > > >
> > > > I'd like just to receive a short clarification about the
> > > > 'status' of base.eclass: Is this eclass expected to be available
> > > > everywhere, i.e. should each eclass make sure it imports and
> > > > incorporates it. Or is it just an eclass like the others and
> > > > ebuilds should make sure they inherit it if needed?
> > >
> > > No. It is unmaintained, has serious design flaws and it simply
> > > should not be used anywhere. At least in EAPI != [01].
> > >
> >
> > what is the PATCHES=() replacement in new eapis? (mainly why i use
> > base.eclass more and more these days)
>
> That's what I used:
>
> [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
>
and ? thanks, I can read the code :)
are you suggesting people to duplicate the code ? this is in no way a
replacement...
A.
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] rfc: udev-rules.eclass
On Wed, 11 Jul 2012 14:11:42 -0500
William Hubbs wrote:
> All,
> I am about to release udev-186-r1, which will move everything
> currently in /lib/udev to /usr/lib/udev.
>
> For packages that install udev rules in ${FILESDIR}, we need an eclass
> that tests the version of udev installed on the user's system and
> installs the udev rules in the proper place. I'm not sure how many
> packages do this, so if it is a very small number of packages, it may
> not be worth the eclass. It would be good to discuss that as well as
> reviewing the proposed eclass.
How do you plan to handle the following:
- foo installs an udev rule
- install foo with old udev
- upgrade udev
are rules installed by foo used by new udev ?
A.
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, 11 Jul 2012 18:48:08 -0500 William Hubbs wrote: > On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: > > How do you plan to handle the following: > > - foo installs an udev rule > > - install foo with old udev > > - upgrade udev > > > > are rules installed by foo used by new udev ? > > No, they wouldn't be; that is a good reason to question the value of > the eclass itself. Maybe the correct way to do this is to forget the > eclass and just file bugs against packages that break having them > move their rules to the new location and set a dependency on the > newer udev. > > This would have to be a rev bump for the broken packages. this sounds heavy for only changing the location of a file, but that's the only sane solution i can think of :( A.
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, 11 Jul 2012 20:41:04 -0700 Brian Dolbec wrote: > On Wed, 2012-07-11 at 18:48 -0500, William Hubbs wrote: > > On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: > > > How do you plan to handle the following: > > > - foo installs an udev rule > > > - install foo with old udev > > > - upgrade udev > > > > > > are rules installed by foo used by new udev ? > > > > No, they wouldn't be; that is a good reason to question the value > > of the eclass itself. Maybe the correct way to do this is to forget > > the eclass and just file bugs against packages that break having > > them move their rules to the new location and set a dependency on > > the newer udev. > > > > This would have to be a rev bump for the broken packages. > > > > William > > > > > > > > A. > > > > > So, does that mean the rule itself changes or just the location change > is needed? > > If it is just a location change, a fairly simple udev-updater script > would do it. [...] how do you handle the package manager database containing the location of the file ? A.
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, 11 Jul 2012 19:50:42 -0700 Zac Medico wrote: > On 07/11/2012 07:25 PM, Rick "Zero_Chaos" Farina wrote: > > On 07/11/2012 07:48 PM, William Hubbs wrote: > >> On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: > >>> How do you plan to handle the following: > >>> - foo installs an udev rule > >>> - install foo with old udev > >>> - upgrade udev > >>> > >>> are rules installed by foo used by new udev ? > > > >> No, they wouldn't be; that is a good reason to question the value > >> of the eclass itself. Maybe the correct way to do this is to > >> forget the eclass and just file bugs against packages that break > >> having them move their rules to the new location and set a > >> dependency on the newer udev. > > Perhaps a new ebuild helper would be best here? It seems no one > > knows where to install udev rules in the first place (I know I > > didn't till a recent version of portage yelled at me with a QA > > warning). > > > > How about dorule/newrule? > > I guess then we'd need the installed udev to set an environment > variable via /etc/env.d, in order to control the location where the > rules are installed? Having the location of installed files depend on environment variables always sounded bad practices to me. Maybe it is quite common, but I remember specifically hardcoding paths in TeXLive's ebuilds/eclasses to avoid this behavior. A.
Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass
On Fri, 13 Jul 2012 20:02:19 +0800
Ben de Groot wrote:
> --- /usr/portage/eclass/qt4-r2.eclass 2012-04-20
> 07:01:13.0 +0800 +++ qt4-r2.eclass.new2012-07-13
> 19:45:59.259773917 +0800 @@ -19,6 +19,22 @@
>
> export XDG_CONFIG_HOME="${T}"
>
> +# @ECLASS-VARIABLE: DOCS
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# Array containing documents passed to dodoc command.
> +# Paths can be absolute or relative to ${S}.
> +#
> +# Example: DOCS=( ChangeLog README "${WORKDIR}/doc_folder/" )
> +
> +# @ECLASS-VARIABLE: HTML_DOCS
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# Array containing documents passed to dohtml command.
> +# Paths can be absolute or relative to ${S}.
> +#
> +# Example: HTML_DOCS=( "doc/document.html" "${WORKDIR}/html_folder/"
> ) +
> # @ECLASS-VARIABLE: LANGS
> # @DEFAULT_UNSET
> # @DESCRIPTION:
> @@ -44,6 +60,21 @@
> done
> unset x
>
> +# @ECLASS-VARIABLE: PATCHES
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# Array variable containing all the patches to be applied. This
> variable +# is expected to be defined in the global scope of ebuilds.
> Make sure to +# specify the full path. This variable is used in
> src_prepare phase. +#
> +# Example:
> +# @CODE
> +# PATCHES=(
> +# "${FILESDIR}/mypatch.patch"
> +# "${FILESDIR}/mypatch2.patch"
> +# )
> +# @CODE
> +
this sounds like re-ordering and improving comments, no functional
change, right ?
[...]
> + # backward compatibility for non-array variables
> + if [[ -n ${DOCS} ]] && [[ "$(declare -p DOCS 2>/dev/null
> 2>&1)" != "declare -a"* ]]; then
> + dodoc ${DOCS} || die "dodoc failed"
> + fi
> + if [[ -n ${HTML_DOCS} ]] && [[ "$(declare -p HTML_DOCS
> 2>/dev/null 2>&1)" != "declare -a"* ]]; then
> + dohtml -r ${HTML_DOCS} || die "dohtml failed"
> + fi
> }
maybe issue an eqawarn in that case telling people to convert to
arrays; some time later make this an ewarn telling non-array support
will be removed and again later make this a die :)
(if you take that route i would expect you to start converting packages
to use arrays)
+1 for the whole thing btw
A.
Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass
On Fri, 13 Jul 2012 15:26:58 +0200
Davide Pesavento wrote:
> > [...]
> >> + # backward compatibility for non-array variables
> >> + if [[ -n ${DOCS} ]] && [[ "$(declare -p DOCS 2>/dev/null
> >> 2>&1)" != "declare -a"* ]]; then
> >> + dodoc ${DOCS} || die "dodoc failed"
> >> + fi
> >> + if [[ -n ${HTML_DOCS} ]] && [[ "$(declare -p HTML_DOCS
> >> 2>/dev/null 2>&1)" != "declare -a"* ]]; then
> >> + dohtml -r ${HTML_DOCS} || die "dohtml failed"
> >> + fi
> >> }
> >
> > maybe issue an eqawarn in that case telling people to convert to
> > arrays; some time later make this an ewarn telling non-array support
> > will be removed and again later make this a die :)
> > (if you take that route i would expect you to start converting
> > packages to use arrays)
> >
>
> We have no intention of deprecating non-array variables in qt4-r2
> eclass.
why ? having two codepaths for the same thing, one being inferior,
sounds like a good reason to deprecate the inferior one :)
A.
Re: [gentoo-dev] UTF-8 locale by default
On Thu, 02 Aug 2012 11:21:40 -0700 Diego Elio Pettenò wrote: > On 01/08/2012 23:42, Fabian Groffen wrote: > > Honestly, if some asian person has whatever charset that I often > > find in spam messages, but is not UTF-8, are you then going to tell > > that person to switch to UTF-8 to get those python packages > > emerged? I hope not. > > Tell that to the Python team I guess. My tinderbox _has_ utf8 locales > available, but doesn't set in by default -> Python stuff fails to > build or test -> not going to be fixed with "change your locale" > reasoning. not that it is hard to set LC_ALL=sth before running the failing command, or make the pm do it... we already fix regexp bugs with other locales (or workaround them by setting LC_ALL=C), it falls under the same category. you just need to teach people, and maybe mandate an utf8 locale to be present; the same way they do not consider estonian alphabet ordering 'broken' they would not consider not having an utf8 locale 'broken', esp. when said utf8 is far from being optimal in terms of size for asian languages. A.
Re: [gentoo-dev] UTF-8 locale by default
On Fri, 3 Aug 2012 17:47:24 +0200 Michał Górny wrote: > > Python upstream is doing what they think is best in using unicode. > > > > That said, what if we just temporarily set a locale in the ebuild > > for running tests and elsewhere? Is this unreasonable or > > impossible? It might not be a great solution, this method, since > > users' stuff will still break. > > It is impossible because you can't know which locale a particular > system has available. AFAIK there's no 'it-will-always-work' choice; > unless we're going to enforce generating some common locale, or do > very ugly things. I don't think anyone will object to enforcing a given locale to be present, even en_US.UTF-8; people will object if they have to use that locale. Maybe locale-gen can even generate it on-the-fly in $T, I don't know. A.
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On Tue, 14 Aug 2012 20:03:50 +0300 Samuli Suominen wrote: > On 13.08.2012 19:55, Samuli Suominen wrote: > [ ... ] > > I should mention that we have discussed this already, > > https://bugs.gentoo.org/show_bug.cgi?id=364375 > > Which was a result of long gentoo-dev ML thread, unfortunately my > search foo failed and I couldn't find straight link to it > > Why should we threat /usr than / any different in this regard, there > was large consensus /lib/udev should be used instead of /lib64/udev > and udev.pc's udevdir= is the path for "udev helpers", ELFs(!), and > rules among other things > > It's completely fair to say that multilib-strict feature has been > broken ever since, years. well, i dont agree its fair :P it breaks on _pie_ executables, which are not that common if you dont run hardened. what is broken, and has been broken since years is multilib-strict + pie toolchain; a flaw in the multilib-strict detection system that gets confused by 'file' output on pie executables :) A.
Re: [gentoo-dev] [RFC] new vala.eclass
On Sun, 26 Aug 2012 19:43:32 -0400 Alexandre Rostovtsev wrote: > On Sun, 2012-08-26 at 15:45 -0700, Zac Medico wrote: > > Note that pkg_setup is called for binary packages too, which means > > that DEPEND may not necessarily be installed. In EAPI 4 you can > > check the MERGE_TYPE variable which can have a value of binary, > > source, orbuildonly. > > The variables that vala_pkg_setup sets are needed only at build time. so it should be vala_src_prepare / unpack instead ? definitely not anything pkg_* imho
Re: [gentoo-dev] [RFC] new vala.eclass
On Mon, 27 Aug 2012 00:45:45 -0400 Alexandre Rostovtsev wrote: > On Sun, 2012-08-26 at 22:45 -0400, Alexis Ballier wrote: > > On Sun, 26 Aug 2012 19:43:32 -0400 > > Alexandre Rostovtsev wrote: > > > The variables that vala_pkg_setup sets are needed only at build > > > time. > > > > so it should be vala_src_prepare / unpack instead ? > > definitely not anything pkg_* imho > > IMHO src_prepare or src_unpack would be misleading because the > function does not modify the package's source and has nothing to do > with unpacking. it creates files as far as i understood the code; the point of vala.eclass is to prepare the environment for building the package, right ? you can probably get a valid point for a src_setup phase in a future eapi, but so far with current eapi, src_prepare seems the best choice > It's not an unusual idiom to set various environment > variables in pkg_setup even if those variables are relevant only at > build time; gnome-extra/zeitgeist and xfce4-vala/xfce4-vala are > typical examples that already export VALAC in their pkg_setup(). lots of bad examples does not make it good :) this is just wasted cpu cycles for binpkgs, moreover these two examples only set a variable and call type -P; the eclass does set a couple more of variables and writes to $T anyway its your call, but given that the eclass is only useful for building it seems bad practices to put its code in a pkg_ phase.
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On Fri, 31 Aug 2012 12:42:10 +0200 Michał Górny wrote: > On Fri, 31 Aug 2012 10:06:06 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > > > Michał Górny posted on Fri, 31 Aug 2012 10:01:09 +0200 as excerpted: > > > > > On Fri, 31 Aug 2012 00:12:53 + (UTC) > > > Duncan <1i5t5.dun...@cox.net> wrote: > > > > > >> Various people have in fact expressed a desire to REDUCE the > > >> number of packages in @system, for various reasons including both > > >> the parallel merge penalty and the bloat on reduced systems. In > > >> practice, there's not a lot of positive movement on actually > > >> reducing @system, but at minimum, unless there's *NO* other > > >> choice and in this case there clearly is, we shouldn't be ADDING > > >> packages to @system. > > >> > > >> For that reason, while I do see the reason why some would like > > >> pkg-config added to @system, the whole idea's pretty much a > > >> non-starter > > > > > But you're aware that cost of pkgconf is very little? > > > > Not really, when it's a step in the opposite direction from an > > intended goal. The first step toward any goal is to stop going > > backward, and that's exactly what this would be. We need a smaller > > @system, not a larger one, and while the add would be easy, undoing > > it years later when it's yet another bit of the tangled web woven, > > would be *MUCH* more difficult. Just don't do it; don't go > > backward; don't add to the problem instead of reducing it. > > So please introduce virtual/compiler, virtual/linker, > virtual/posix-system, virtual/sratatata and add them to DEPEND of > every single ebuild. > > I believe that the more important direction here is to make > development *easier*, not harder. Adding the same DEPENDs over and > over again to every single package is at least frustrating. Similarly > frustrating would be if those 'reduced systems' had to rebuild gcc > every time they wanted to compile something... oh wait, they would > have to bootstrap it every time. > you would achieve it better by adding pkgconfig to DEPEND in eutils.eclass than putting it in @system since in the latter case it would also be a RDEPEND of everything basically this doesnt really compare to gcc since its a RDEPEND for everything c++ and maybe more (i didnt check when libgcc_s is linked in or not) A.
