Re: [gentoo-dev] eselect-compiler updates and unmasking
Couple of questions: 1) Can it handle non-gcc compilers? If so, how? It is possible, but I'm not sure if icc is installed in a way that makes it convenient. All the binaries will need to be lumped in a directory by themselves (like we do with gcc). You'll have to create your own profile in /etc/eselect/compiler. 2) Can it handle different languages being set to different compilers? For example, use Intel's Fortran compiler but GCC for everything else. No, this isn't something I considered a high priority. I was more interested in tackling the issues road-blocking multilib, but this is something that would be a nice feature down the road. If neither of those are possible now, I would like to look into fixing this. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Well, incidentally I was working on toolchainasing gnat (a gcc based Ada compiler, basically just another frontend) and pestered toolchain people on irc regarding similar matters. Basically it came down to: toolchain.eclass and eselect-compiler are not for stuff not in gcc, so I had to create my own ones (gnatbuild.eclass and eselect-gnat), a bit simpler versions actually :). I could not inherit toolchain.eclass either, only copy the relevant parts of it.. A due notice: this was discussed already like half a year ago (although when I announced progress here on -dev no comments followed), so if the things have chaged since then I will be interested to know too.. Well, I'm not against that support being in eselect-compiler, and in fact I think it'd be nice... It's just not a priority on my list, so if you'd like to contribute changes which allow support for what you want without needlessly complicating things for those who don't want to use these advanced features, then I'm more than willing to incorporate them. --Jeremy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
On Jun 2, 2006, at 21:33 , Donnie Berkholz wrote: Couple of questions: 1) Can it handle non-gcc compilers? If so, how? It is possible, but I'm not sure if icc is installed in a way that makes it convenient. All the binaries will need to be lumped in a directory by themselves (like we do with gcc). You'll have to create your own profile in /etc/eselect/compiler. 2) Can it handle different languages being set to different compilers? For example, use Intel's Fortran compiler but GCC for everything else. No, this isn't something I considered a high priority. I was more interested in tackling the issues road-blocking multilib, but this is something that would be a nice feature down the road. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Addition of a USE_EXPAND-Variable LIRC_DRIVERS and general cleanup of app-misc/lirc
On Sat, Jun 03, 2006 at 09:11:38PM -0600, Ryan Hill wrote: LIRC_DEVICE? most of the USE_EXPAND stuff seems to be named for the device rather than the driver. eg. ALSA_CARDS, VIDEO_CARDS, INPUT_DEVICES. The ones you just mentioned all refer to driver names. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpjawzRzNhBn.pgp Description: PGP signature
[gentoo-dev] Re: Addition of a USE_EXPAND-Variable LIRC_DRIVERS and general cleanup of app-misc/lirc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Brix Andersen wrote: On Sat, Jun 03, 2006 at 09:11:38PM -0600, Ryan Hill wrote: LIRC_DEVICE? most of the USE_EXPAND stuff seems to be named for the device rather than the driver. eg. ALSA_CARDS, VIDEO_CARDS, INPUT_DEVICES. The ones you just mentioned all refer to driver names. The values do, the variable names don't. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEgpdayrvh8ZIy7KURAqotAJ9uCgU2B9zq7zKqRsHF+k/jUEh4SACeOt69 TaUFKnf0Vx1pue2iRmVetmI= =z3Kz -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] UTF-8 encoding and file format of manuals
On Thursday 01 June 2006 14:30, Josh Saddler wrote: Jan Kundrát wrote: Wiktor Wandachowicz wrote: Summing up: * UTF-8 manuals: good or bad? The Only Way To Go (tm), IMHO. Let's let the legacy encodings die in piece. Agreed. I'd like to see much more extensive use of Unicode throughout my system by default. Unicode man pages are a good idea. wrong this is why we have USE=unicode -mike pgpJ8E5Lu85MD.pgp Description: PGP signature
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
On Thursday 01 June 2006 19:37, Matteo Azzali wrote: XMLTV_OPTS isn't accessible anymore through the ebuild (tomorrow it was). So I'll need a TV_GRAB expanded variable to avoid having 200 local flags. how about a better variable name ? TV_GRAB is kind of awful -mike pgp8cjmq5iMBe.pgp Description: PGP signature
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
Well, TV_GRAB is synthetical , but explains what this variable is,however, how about TV_GRABBER or TV_LOCALE or TV_GRABBER_LOC ? Any suggestion is listened -mattepiu Mike Frysinger wrote: On Thursday 01 June 2006 19:37, Matteo Azzali wrote: XMLTV_OPTS isn't accessible anymore through the ebuild (tomorrow it was). So I'll need a TV_GRAB expanded variable to avoid having 200 local flags. how about a better variable name ? TV_GRAB is kind of awful -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
On Sunday 04 June 2006 06:03, Matteo Azzali wrote: Well, TV_GRAB is synthetical , but explains what this variable is,however, how about TV_GRABBER or TV_LOCALE or TV_GRABBER_LOC ? all same quality what about TV_CAPTURE_CARDS -mike pgpJguhwqrXMM.pgp Description: PGP signature
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
On Sunday 04 June 2006 14:56, Mike Frysinger wrote: what about TV_CAPTURE_CARDS You got it quite wrong, it's not about the TV cards :) It's about TV guide grabbers. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpEqyAQhunfd.pgp Description: PGP signature
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
Diego 'Flameeyes' Pettenò wrote: On Sunday 04 June 2006 14:56, Mike Frysinger wrote: what about TV_CAPTURE_CARDS You got it quite wrong, it's not about the TV cards :) It's about TV guide grabbers. TV_GUIDE_GRABBERS see that was easy ;) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
On Sunday 04 June 2006 08:59, Diego 'Flameeyes' Pettenò wrote: On Sunday 04 June 2006 14:56, Mike Frysinger wrote: what about TV_CAPTURE_CARDS You got it quite wrong, it's not about the TV cards :) It's about TV guide grabbers. then i guess Matteo's assumption that 'TV_GRAB' was self-explanatory was a bit off ;) how portable are TV guide grabbers ? in other words, if xmltv is the only one using this stuff, i say force the maintainer to use a lot of local use variables rather than bloat the rest of the tree -mike pgp2NVCysmPcO.pgp Description: PGP signature
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
On Monday 29 May 2006 20:13, Jakub Moc wrote: Otherwise, some review used to be done, but there's been a negative opinion about closing bugs w/ sucky broken ebuilds as WONTFIX/CANTFIX expressed by some of the devs probably because neither of those resolutions are generally correct sucky broken ebuilds get feedback as to what needs to change and a LATER resolution WONTFIX means the package itself is inappropriate for the tree -mike pgpRLRLrtt6gz.pgp Description: PGP signature
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
Repoman considers lots of local variables as an error, I was pointed to expanded vars as a solution. If no developers has something against I'll be happy to use 28 local flags mattepiu Mike Frysinger wrote: On Sunday 04 June 2006 08:59, Diego 'Flameeyes' Pettenò wrote: On Sunday 04 June 2006 14:56, Mike Frysinger wrote: what about TV_CAPTURE_CARDS You got it quite wrong, it's not about the TV cards :) It's about TV guide grabbers. then i guess Matteo's assumption that 'TV_GRAB' was self-explanatory was a bit off ;) how portable are TV guide grabbers ? in other words, if xmltv is the only one using this stuff, i say force the maintainer to use a lot of local use variables rather than bloat the rest of the tree -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
Matteo Azzali wrote: Repoman considers lots of local variables as an error, I was pointed to expanded vars as a solution. If no developers has something against I'll be happy to use 28 local flags mattepiu Well uh, no please Don't create 28 local use flags for one ebuild, use.local.desc is cluttered enough as it is... :) Otherwise, I'd say you've misunderstood the repoman output, you probably didn't put them into use.local.desc when testing your local stuff. -- jakub signature.asc Description: OpenPGP digital signature
[gentoo-dev] new repoman check
Slipping this in before 2.1 goes stable, it's a small check. Basically if your ebuild inherits a VCS eclass ( currently darcs, subversion, cvs ) AND your ebuild has stable keywords on any arches repoman will report an error. One thing to note here: Are there any cases when one inherits a VCS eclass but the ebuild itself is not a live checkout ebuild. I don't see any, looking at the eclasses. This repoman check attempts to enforce policy in the developer handbook[1]. Live cvs.eclass ebuilds are generally only intended for the convenience of developers and should always be masked with a ~[arch] keyword. It is impossible to guarantee the reliability of a live cvs.eclass ebuild since the upstream cvs tree may change at any time, which is why they should always be masked. Whether a live CVS ebuild or a snapshot CVS ebuild, you the developer are responsible for ensuring that the ebuild works correctly. This is particularly difficult to do with live cvs ebuilds for obvious reasons. [1]http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=1#doc_chap4 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Addition of a USE_EXPAND-Variable LIRC_DRIVERS and general cleanup of app-misc/lirc
On Sunday 04 June 2006 05:11, Ryan Hill wrote: Matthias Schwarzott wrote: The --with-driver part will be moved to LIRC_DRIVERS. The name need not to be LIRC_DRIVERS, tell me if you have a better name for it (LIRC_RECEIVERS is another possibility). LIRC_DEVICE? most of the USE_EXPAND stuff seems to be named for the device rather than the driver. eg. ALSA_CARDS, VIDEO_CARDS, INPUT_DEVICES. I think these ones are suitable: LIRC_RECEIVERS LIRC_DEVICES I vote for LIRC_DEVICES if there are no more good suggestions. Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] eutils.class fix for make_desktop_entry
I need to add a desktop entry that call an executable with arguments.
Actually the entry Exec (that could contain the executable with
parameters) and the entry TryExec (used to test if the executable is
installed) are set to the same value.
I wonder if I can fix that with the following patch to the eutils eclass
@@ -900,7 +902,7 @@
Type=Application
Comment=${DESCRIPTION}
Exec=${exec}
-TryExec=${exec}
+TryExec=${exec%% *}
Path=${path}
Icon=${icon}
Categories=Application;${type}; ${desktop}
I meant: is there some ebuild that has space in the executable name, or
is there some way this change can break ebuilds. eutils is used by lot
of them, so I'm scared to break the whole tree.
Going to apply if I get no negative answer in, say, 10 days.
Alfredo
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
Jakub Moc wrote: Matteo Azzali wrote: Repoman considers lots of local variables as an error, I was pointed to expanded vars as a solution. If no developers has something against I'll be happy to use 28 local flags mattepiu Well uh, no please Don't create 28 local use flags for one ebuild, use.local.desc is cluttered enough as it is... :) Otherwise, I'd say you've misunderstood the repoman output, you probably didn't put them into use.local.desc when testing your local stuff. My plan with xmltv was to USE locales since the xmltv grabbers actually use the same locale codes (i.e. de for the German ones). Granted there's some differences (two de grabbers and they're called xmltv_de_something and xmltv_de_something else). However the de locale setting would turn both on. I think that's the best option. But I just haven't had enough time to do it. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Addition of a USE_EXPAND-Variable LIRC_DRIVERS and general cleanup of app-misc/lirc
Matthias Schwarzott wrote: On Sunday 04 June 2006 05:11, Ryan Hill wrote: Matthias Schwarzott wrote: The --with-driver part will be moved to LIRC_DRIVERS. The name need not to be LIRC_DRIVERS, tell me if you have a better name for it (LIRC_RECEIVERS is another possibility). LIRC_DEVICE? most of the USE_EXPAND stuff seems to be named for the device rather than the driver. eg. ALSA_CARDS, VIDEO_CARDS, INPUT_DEVICES. I think these ones are suitable: LIRC_RECEIVERS LIRC_DEVICES I vote for LIRC_DEVICES if there are no more good suggestions. Matthias I swear I had commited something like this to the Portage tree like 2 months ago... -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
On Sunday 04 June 2006 15:43, Jakub Moc wrote: Matteo Azzali wrote: Repoman considers lots of local variables as an error, I was pointed to expanded vars as a solution. you did something wrong then ... there is no such error lots of local variables ... and if there is such an errro, then repoman is broken If no developers has something against I'll be happy to use 28 local flags Well uh, no please Don't create 28 local use flags for one ebuild if it's the correct solution then it's the correct solution a use-expanded variable for one package is a much worse solution basing it off LINGUAS as proposed by cardoe seems like a workable solution -mike pgpz819BrzzN3.pgp Description: PGP signature
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 15551 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 224 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
On Sun, Jun 04, 2006 at 08:36:57PM -0400, Doug Goldstein wrote: Jakub Moc wrote: Matteo Azzali wrote: Repoman considers lots of local variables as an error, I was pointed to expanded vars as a solution. If no developers has something against I'll be happy to use 28 local flags mattepiu Well uh, no please Don't create 28 local use flags for one ebuild, use.local.desc is cluttered enough as it is... :) Otherwise, I'd say you've misunderstood the repoman output, you probably didn't put them into use.local.desc when testing your local stuff. My plan with xmltv was to USE locales since the xmltv grabbers actually use the same locale codes (i.e. de for the German ones). Granted there's some differences (two de grabbers and they're called xmltv_de_something and xmltv_de_something else). However the de locale setting would turn both on. I think that's the best option. But I just haven't had enough time to do it. Please don't do that. LINGUAS is for translations, nothing more, and using it for xmltv grabbers will be a huge pain for everyone using different languages than implied by their locations. -- gentoo-dev@gentoo.org mailing list
