[gentoo-dev] Re: Re: Eclasses (Was: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2])
Ciaran McCreesh wrote: On Fri, 28 Dec 2007 05:21:06 + Steve Long [EMAIL PROTECTED] wrote: Whatever. EAPI=2 works fine with current software. Could you tell me why you're so hot on export'ing EAPI? I thought it was only relevant, environment-wise, to the ebuild and subshells. What is the use case for exporting it externally? I'm going to ignore you until you post a lengthy explanation of why what you just said was utter bollocks. You clearly don't have a clue what you're talking about just now, and by continuing to post nonsense like the above to the discussion you're wasting everyone's time. Honestly, that was the single most wrong thing anyone's said in this entire discussion. Er two questions, not statements. The package manager knows the value; so does bash. Why on earth does, say, make need to know it? (Not that it's hard to allow 'export' in the line, just wondering why it keeps getting raised as required.) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Eclasses (Was: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2])
On Sat, 29 Dec 2007 09:48:33 + Steve Long [EMAIL PROTECTED] wrote: The package manager knows the value; so does bash. Why on earth does, say, make need to know it? Don't think 'make'. Think 'emake'. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] sys-apps/diffutils dependency on =sys-apps/man-pages-2.46
Hello, why has sys-apps/diffutils a dependency on =sys-apps/man-pages-2.46? I'm using a embedded uclibc system, and in uclibc man, man-pages and groff are removed from the system target to not require c++. But diffutils depends on man-pages for no obvious reason, and pulls in man and groff with a dependency on c++. Cheers Stefan -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Random items I'd like to discuss
Some items I have in wishlist - LRDEPEND link runtime dep (I need to link against that in order to run) - BDEPEND build dep (I need those tools in order to build) - arch/ctarget support in deps (same way you have use deps) - explicit ctarget support in the package manager emerge --cross=target something. - tools to explicitly manipulate sets long time ideas: - support cross, multiarch, multilib in a saner and seamless way please comment =) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Random items I'd like to discuss
On Sat, 29 Dec 2007 22:12:11 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Some items I have in wishlist - LRDEPEND link runtime dep (I need to link against that in order to run) - BDEPEND build dep (I need those tools in order to build) - arch/ctarget support in deps (same way you have use deps) Have a look at the labels bug (201499). - explicit ctarget support in the package manager emerge --cross=target something. Would need support from every ebuild, which in turn would need support from every upstream. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Random items I'd like to discuss
Ciaran McCreesh wrote: On Sat, 29 Dec 2007 22:12:11 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Some items I have in wishlist - LRDEPEND link runtime dep (I need to link against that in order to run) - BDEPEND build dep (I need those tools in order to build) - arch/ctarget support in deps (same way you have use deps) Have a look at the labels bug (201499). Similar idea, but I don't like the labels that much, having separate vars can make backward compatibility easy DEPEND=$BDEPEND $LRDEPEND RDEPEND=$LRDEPEND $stuff - explicit ctarget support in the package manager emerge --cross=target something. Would need support from every ebuild, which in turn would need support from every upstream. every autostuff ebuild should and that's a start. you can restrict the tree to a specific branch supporting this feature and extend it little by little. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Random items I'd like to discuss
On Sat, 29 Dec 2007 22:47:50 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Have a look at the labels bug (201499). Similar idea, but I don't like the labels that much, having separate vars can make backward compatibility easy You can't sensibly have backwards compatibility across new deps if all the requested options are implemented anyway -- there's no exact mapping between the current three vars and all the new ones. New deps has to be an EAPI change, and it has to be an ebuild change. And the other problem -- we'd be talking hundreds of variables. Multiply number of dep types (build, run, install, compile against, post, probably more) by number of requirement levels (required, suggested, recommended) by number of ABI combinations by number of system combinations by whatever else ends up being useful. - explicit ctarget support in the package manager emerge --cross=target something. Would need support from every ebuild, which in turn would need support from every upstream. every autostuff ebuild should and that's a start. Except that autotools doesn't have any sane way of handling chost / cbuild / ctarget for non-trivial packages. If you want to do something simple like generate a file using a program you make at compile time, you're forced to resort to nicking insane hackery from the gcc build system -- or you can do what most people do and just break non-native compiles. Using autotools does not mean supporting chost / cbuild / ctarget properly... you can restrict the tree to a specific branch supporting this feature and extend it little by little. Tree branching will very quickly become unmanageable. Users will be forced to choose a branch, but useful features will be spread across different branches. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Ciaran McCreesh ha scritto:
On Thu, 27 Dec 2007 18:03:27 +
Roy Marples [EMAIL PROTECTED] wrote:
Using your analogy you should then recognise that there is a strong
dislike for pink and should seek a new colour that allows the building
of said extensions.
And what colour would that be? We've already ruled out purple, brown
and yellow, and no-one has yet found any other colour of paint.
sorry if this has already suggested.
my idea is to use shebang; the advantage in using shebang is that file
doesn't need to be sourced or parsed by complex algorithms in order to
extract the necessary information.
an example:
#!/usr/bin/ebuild eapi=1
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
DESCRIPTION=My EAPI-1 ebuild
HOMEPAGE=http://www.gentoo.org/;
SRC_URI=
LICENSE=GPL-2
...
shebang's synopsis would look something like:
#!interpreter [key=value] [key=value] [...]
pros:
1) it's standard. shell scripts use it. why ebuilds shouldn't?
2) it's easy to parse:
eval `head -n1 $ebuild | cut -d\ -f2-`; echo $eapi
3) in the future, for any other situation analogous to this, you could
add another key=value to the ebuild's shebang
4) easily checked by repoman
cons:
?
just my two Eurocents.
since now you can bite me ;-)
--
#include stdio.h
main(){printf(%x,4275974592);}
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Sun, 30 Dec 2007 00:16:22 +0100 Federico Ferri [EMAIL PROTECTED] wrote: sorry if this has already suggested. It has. It solves nothing. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: sys-apps/diffutils dependency on =sys-apps/man-pages-2.46
Stefan Hellermann [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 29 Dec 2007 21:45:45 +0100: why has sys-apps/diffutils a dependency on =sys-apps/man-pages-2.46? I'm using a embedded uclibc system There are people here who work with embedded and ulibc. I'm not one of them and won't try to answer directly. However, to fix the dependency... Use /etc/portage/profiles/package.provided. See the portage manpage for details. I have a number of unnecessary dependencies listed there, and a few virtuals faked in a virtuals file in the same dir, as well. If you don't like Gentoo's dependencies, they /do/ give you a way to change them yourself without a whole lot of trouble. =8^) BTW, if you aren't yet aware of it, there's the Gentoo-embedded list. Next time I'd suggest trying there, first. =8^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Asterisk 1.4 in Portage
* Doug Klima [EMAIL PROTECTED] [2007-12-26 19:19]: Howdy all, Hey Doug! As some people might have noticed, I've wanted to bring Asterisk 1.4 to the tree proper. ++ on that from me :) The big holdup is the zaptel ebuild, which needs to be revamped and brought in as well for the 1.4.x series. I've already rewritten most of it, the only issue is I don't have hardware to test (nor do I want any). So I'd like if someone out there that used/had zaptel hardware would pick up the ebuild. I do have an asterisk server with 2 HFC (CologneChip) cards, using 1 of them in NT mode (for connecting an ISDN phone to it) and one of them in TE mode (for connecting it to the ISDN of the telco). I used those with the zaphfc driver from the bristuff package. So, I could test your asterisk+zaptel ebuilds with this setup. If you're interested, drop me a line. I'll send you over a 1.4.x ebuild. What's the status of http://overlays.gentoo.org/proj/voip/browser/trunk/net-misc/asterisk/\ asterisk-1.4.12.1.ebuild, does it differ much from the latest one you'd like to commit? What versions of zaptel, bristuff and the florz patch are you going to commit anyway? Thanks :) -- Regards, Wolfram Schlich [EMAIL PROTECTED] Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Sat, 2007-12-29 at 23:20 +, Ciaran McCreesh wrote: On Sun, 30 Dec 2007 00:16:22 +0100 Federico Ferri [EMAIL PROTECTED] wrote: sorry if this has already suggested. It has. It solves nothing. If it solves nothing you should at least post a link to the post you made explaining so, instead of the user posting Why? and another silly debate starting. Thanks Roy -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: x11-themes/openbox-themes
# David Shakaryan [EMAIL PROTECTED] (30 Dec 2007) # Masked pending removal 30 Jan 2008. # Extremely old themes not exhibiting Openbox's newer theming options. # Openbox will be moving to an XML-based theming engine in the future. x11-themes/openbox-themes -- David Shakaryan -- [EMAIL PROTECTED] mailing list
