Re: [gentoo-dev] new repoman check
On Sun, Jun 04, 2006 at 04:09:44PM -0400, Alec Warner wrote: 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. Some gnustep stuff inherits cvs, but uses -D in the cvs options to always download exactly the same thing. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Monday 05 June 2006 02:07, Harald van Dijk wrote: Some gnustep stuff inherits cvs, but uses -D in the cvs options to always download exactly the same thing. then arent you just adding overhead to the poor gnustep cvs servers ? why not roll a cvs snapshot tarball and distro via our mirrors -mike pgpTRHxxBS48w.pgp Description: PGP signature
Re: [gentoo-dev] new repoman check
On Mon, Jun 05, 2006 at 03:45:50AM -0400, Mike Frysinger wrote: On Monday 05 June 2006 02:07, Harald van Dijk wrote: Some gnustep stuff inherits cvs, but uses -D in the cvs options to always download exactly the same thing. then arent you just adding overhead to the poor gnustep cvs servers ? why not roll a cvs snapshot tarball and distro via our mirrors Yeah, that'd probably be a better idea, but even if the current ebuilds are less than perfect, it seems like a valid use of the eclass to me, so making repoman error out is a bad idea, I think. A warning would be useful, though. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Mon, Jun 05, 2006 at 10:19:41AM +0200, Harald van Dijk wrote: On Mon, Jun 05, 2006 at 03:45:50AM -0400, Mike Frysinger wrote: On Monday 05 June 2006 02:07, Harald van Dijk wrote: Some gnustep stuff inherits cvs, but uses -D in the cvs options to always download exactly the same thing. then arent you just adding overhead to the poor gnustep cvs servers ? why not roll a cvs snapshot tarball and distro via our mirrors Yeah, that'd probably be a better idea, but even if the current ebuilds are less than perfect, it seems like a valid use of the eclass to me, so making repoman error out is a bad idea, I think. A warning would be useful, though. 'Cept standards for ebuilds is typically http/https/ftp access for fetching files- forcing pserver means people behind firewalls are screwed... which is why non standard uri that is generally accessible to users must be http/https/ftp, and if they aren't, upload the file to the mirrors. Ebuilds might work, don't think they qualify as valid though- assume initially it was easier to just copy the ebuild and lock the date; doesn't make it valid though. :) Should be an error imo- there isn't any real requirement for a cvs/git/darcs/subversion eclass consumer to be visible really. ~harring pgpzZKoXz572V.pgp Description: PGP signature
Re: [gentoo-dev] new repoman check
On Mon, Jun 05, 2006 at 01:54:08AM -0700, Brian Harring wrote: On Mon, Jun 05, 2006 at 10:19:41AM +0200, Harald van Dijk wrote: On Mon, Jun 05, 2006 at 03:45:50AM -0400, Mike Frysinger wrote: On Monday 05 June 2006 02:07, Harald van Dijk wrote: Some gnustep stuff inherits cvs, but uses -D in the cvs options to always download exactly the same thing. then arent you just adding overhead to the poor gnustep cvs servers ? why not roll a cvs snapshot tarball and distro via our mirrors Yeah, that'd probably be a better idea, but even if the current ebuilds are less than perfect, it seems like a valid use of the eclass to me, so making repoman error out is a bad idea, I think. A warning would be useful, though. 'Cept standards for ebuilds is typically http/https/ftp access for fetching files- forcing pserver means people behind firewalls are screwed... which is why non standard uri that is generally accessible to users must be http/https/ftp, and if they aren't, upload the file to the mirrors. Ebuilds might work, don't think they qualify as valid though- assume initially it was easier to just copy the ebuild and lock the date; doesn't make it valid though. :) I now checked: http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html If it's explained how to do it in the docs, I consider it valid, regardless of how bad an idea it may be. Should be an error imo- there isn't any real requirement for a cvs/git/darcs/subversion eclass consumer to be visible really. ~harring Are you hoping for even ~arch cvs ebuilds to cause a repoman error? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Mon, Jun 05, 2006 at 02:24:24AM -0700, Brian Harring wrote: On Mon, Jun 05, 2006 at 11:14:45AM +0200, Harald van Dijk wrote: On Mon, Jun 05, 2006 at 01:54:08AM -0700, Brian Harring wrote: On Mon, Jun 05, 2006 at 10:19:41AM +0200, Harald van Dijk wrote: On Mon, Jun 05, 2006 at 03:45:50AM -0400, Mike Frysinger wrote: On Monday 05 June 2006 02:07, Harald van Dijk wrote: Some gnustep stuff inherits cvs, but uses -D in the cvs options to always download exactly the same thing. then arent you just adding overhead to the poor gnustep cvs servers ? why not roll a cvs snapshot tarball and distro via our mirrors Yeah, that'd probably be a better idea, but even if the current ebuilds are less than perfect, it seems like a valid use of the eclass to me, so making repoman error out is a bad idea, I think. A warning would be useful, though. 'Cept standards for ebuilds is typically http/https/ftp access for fetching files- forcing pserver means people behind firewalls are screwed... which is why non standard uri that is generally accessible to users must be http/https/ftp, and if they aren't, upload the file to the mirrors. Ebuilds might work, don't think they qualify as valid though- assume initially it was easier to just copy the ebuild and lock the date; doesn't make it valid though. :) I now checked: http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html If it's explained how to do it in the docs, I consider it valid, regardless of how bad an idea it may be. Except the doc specifically states they should be package.mask'd if added; what that doc is talking about is vcs head ebuilds, not an ebuild that's locked down to an exact rev/date. It first lists the disadvantages of CVS sources in general, and then the disadvantages of live CVS sources. If it only applied to live CVS sources, why would it split them up? As mike said, why hammer on their servers? The ebuild isn't changing (it's effectively a locked version), tarball it and upload it. And as I said, I agree that that would be a better idea. Basically, the locked cvs version ebuild referenced above seems like a lazy trick someone did to avoid rewriting it to drop the cvs usage. Should be an error imo- there isn't any real requirement for a cvs/git/darcs/subversion eclass consumer to be visible really. ~harring Are you hoping for even ~arch cvs ebuilds to cause a repoman error? Original rules *were* that no vcs head based ebuild should be visible, that it must be masked. Current devrel docs contradict that (those docs bluntly are wrong- that change I don't think anyone ever agreed to), devmanual states it correctly. The devmanual states that they should not generally be added to the tree softmasked or unmasked. It does not state that they should never be added as such at all. Or, in other words, there can be exceptions. There's nothing wrong with vcs head ebuilds if they're masked; if they're user visible (~arch), there is _no_ way to gurantee they're actually sane (the source can and does change), that's why they're suppossed to be masked. ~harring -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
The options are just : 1) local flags or 2) expanded var. 3) I've also tried to reuse the LINGUAS expanded flag but is something hackish: not enogh control to the ebuild, people in foreign country can do nothing, there are some issues for country with non-exclusive language (think about switzerland, reunion island or south africa.). I happily let you choose which way is the best,please do it fast mattepiu 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
On Monday 05 June 2006 06:01, Matteo Azzali wrote: 1) local flags or 2) expanded var. if xmltv is the only package which would benefit from this, then you should use local flags -mike pgplS49zhZlYF.pgp Description: PGP signature
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
I already did it , check http://pastebin.com/759475 , but truedfx wrote : 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. My solution is 3 use flags, tv_check , tv_pick_cgi and onlinguas. If onlinguas is set, ebuild will emerge based on LINGUAS, if is unset it will emerge the complete XMLTV (deps and grabbers). From what vapier told, the only other viable alternative is local use flag, and if I'll not get a different definitive answer from anyone else before tomorrow, I'll follow vapier instructions (he's Gentoo Base System Project Leader ). mattepiu 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Mon, 5 Jun 2006 11:56:16 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: | The devmanual states that they should not generally be added to the | tree softmasked or unmasked. It does not state that they should never | be added as such at all. Or, in other words, there can be exceptions. It's not a hard ban because when I wrote it I was thinking that maybe some day someone would come up with a legitimate reason for it. You've yet to do that, so you don't get to take the exception clause. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
Harald van Dijk wrote: On Mon, Jun 05, 2006 at 02:24:24AM -0700, Brian Harring wrote: On Mon, Jun 05, 2006 at 11:14:45AM +0200, Harald van Dijk wrote: On Mon, Jun 05, 2006 at 01:54:08AM -0700, Brian Harring wrote: On Mon, Jun 05, 2006 at 10:19:41AM +0200, Harald van Dijk wrote: On Mon, Jun 05, 2006 at 03:45:50AM -0400, Mike Frysinger wrote: On Monday 05 June 2006 02:07, Harald van Dijk wrote: Some gnustep stuff inherits cvs, but uses -D in the cvs options to always download exactly the same thing. then arent you just adding overhead to the poor gnustep cvs servers ? why not roll a cvs snapshot tarball and distro via our mirrors Yeah, that'd probably be a better idea, but even if the current ebuilds are less than perfect, it seems like a valid use of the eclass to me, so making repoman error out is a bad idea, I think. A warning would be useful, though. 'Cept standards for ebuilds is typically http/https/ftp access for fetching files- forcing pserver means people behind firewalls are screwed... which is why non standard uri that is generally accessible to users must be http/https/ftp, and if they aren't, upload the file to the mirrors. Ebuilds might work, don't think they qualify as valid though- assume initially it was easier to just copy the ebuild and lock the date; doesn't make it valid though. :) I now checked: http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html If it's explained how to do it in the docs, I consider it valid, regardless of how bad an idea it may be. Except the doc specifically states they should be package.mask'd if added; what that doc is talking about is vcs head ebuilds, not an ebuild that's locked down to an exact rev/date. It first lists the disadvantages of CVS sources in general, and then the disadvantages of live CVS sources. If it only applied to live CVS sources, why would it split them up? As mike said, why hammer on their servers? The ebuild isn't changing (it's effectively a locked version), tarball it and upload it. And as I said, I agree that that would be a better idea. Basically, the locked cvs version ebuild referenced above seems like a lazy trick someone did to avoid rewriting it to drop the cvs usage. Should be an error imo- there isn't any real requirement for a cvs/git/darcs/subversion eclass consumer to be visible really. ~harring Are you hoping for even ~arch cvs ebuilds to cause a repoman error? Original rules *were* that no vcs head based ebuild should be visible, that it must be masked. Current devrel docs contradict that (those docs bluntly are wrong- that change I don't think anyone ever agreed to), devmanual states it correctly. The devmanual states that they should not generally be added to the tree softmasked or unmasked. It does not state that they should never be added as such at all. Or, in other words, there can be exceptions. The error has been dropped to a warning, repoman will presently complain for any ebuild which has stable keywords and inherits a VCS eclass. Repoman will then list off all the arches that are keyworded stable. *In General* Inheriting a VCS eclass and having stable keywords means you are doing something wrong, there are exceptions; thats why warning is important here (more effective than an error as I think more about it). It's a warning to allow exceptions, expect the QA team to nudge you about ebuilds with odd keywording though. I am attempting to enforce current devrel policy with this change. I will push for policy to be changed later to pmask as I think that is the proper way to go about things. However that is seperate discussion. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Mon, Jun 05, 2006 at 12:57:08PM +0100, Ciaran McCreesh wrote: On Mon, 5 Jun 2006 11:56:16 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: | The devmanual states that they should not generally be added to the | tree softmasked or unmasked. It does not state that they should never | be added as such at all. Or, in other words, there can be exceptions. It's not a hard ban because when I wrote it I was thinking that maybe some day someone would come up with a legitimate reason for it. You've yet to do that, so you don't get to take the exception clause. The proposal was to change it to a hard ban. You say that there could be legitimate reasons for (un)stable CVS ebuilds. What I'm saying is that they're valid from a portage POV even without reasons, that they're currently used, and that the current stable CVS ebuilds are indeed a bad idea. So far, I don't think you disagree, but if you do, please explain. I then said that *you* say there can be legitimate reasons for them. So why do *I* have to come up with examples of it? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Mon, 5 Jun 2006 14:41:43 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: | I then said that *you* say there can be legitimate reasons for them. | So why do *I* have to come up with examples of it? Well that's just it. I didn't say there were legitimate reasons, I just didn't commit myself to saying that there weren't. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eutils.class fix for make_desktop_entry
On Mon, 2006-06-05 at 00:13 +0200, Alfredo Tupone wrote: Going to apply if I get no negative answer in, say, 10 days. Go ahead and do it now. It really shouldn't break anything, as I can't think of a single thing using make_desktop _entry with a space in the executable name. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] new repoman check
On Mon, Jun 05, 2006 at 01:51:31PM +0100, Ciaran McCreesh wrote: On Mon, 5 Jun 2006 14:41:43 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: | I then said that *you* say there can be legitimate reasons for them. | So why do *I* have to come up with examples of it? Well that's just it. I didn't say there were legitimate reasons, I just didn't commit myself to saying that there weren't. Fair enough, but if you read can as could in my posts, they still make sense. Two reasons for CVS ebuilds that aren't hardmasked, by the way: One: see emacs-cvs-22*; it's more reliable than the emacs-22* snapshot. (Something like this is only for ~arch.) Two: when a specific revision is wanted, but snapshots aren't possible for legal reasons. (This could even be marked stable.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Mon, 2006-06-05 at 15:16 +0200, Harald van Dijk wrote: On Mon, Jun 05, 2006 at 01:51:31PM +0100, Ciaran McCreesh wrote: On Mon, 5 Jun 2006 14:41:43 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: | I then said that *you* say there can be legitimate reasons for them. | So why do *I* have to come up with examples of it? Well that's just it. I didn't say there were legitimate reasons, I just didn't commit myself to saying that there weren't. Fair enough, but if you read can as could in my posts, they still make sense. Two reasons for CVS ebuilds that aren't hardmasked, by the way: One: see emacs-cvs-22*; it's more reliable than the emacs-22* snapshot. (Something like this is only for ~arch.) Two: when a specific revision is wanted, but snapshots aren't possible for legal reasons. (This could even be marked stable.) If it can't be checksummed it should never be marked stable. *VCS* ebuilds simply can't be checksumed and there are far to many ways to abuse such things. Think MiM -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA subproject, TreeCleaners
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: [...] Gets my vote. Good idea. :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEhFG6rsJQqN81j74RAsO1AKCybk+IHs6Bta0Jj/ZCoo2UP3YqZACeNLms bJowAD/7a9ukWOzX+qPVcAo= =a6gy -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Hi, today I would like to propose a few default keywords for removal. They are outdated and no longer needed on current systems: -apm - only very old notebooks use apm -foomaticdb - foomaticdb is only used for development foomatic xml files. SInce most of our users do not develop printer drivers I suggest making ppds a default use flag instead. -fortran - Do we really need this outdated language as a default in gcc? -imlib - imlib depends on gtk-1, which imo should not be installed in a default gentoo installation - there should be no legacy depends for a plain emerge kde. -motif - is unmaintained in portage and rather outdated, does not look good. Should not be default for optional interfaces -oss - oss is a legacy audio interface that has been superseeded by alsa in most current installs, a default use flag is no longer needed -xmms - xmms depends on gtk-1 and has been superseeded by audacious/bmpx I would like to make the changes in a new 2006.1 profile, how do I go about that? I think the current profiles should not be touched, since some users may still be using the flags. Any comments/objections - any outdated useflags I forgot? Have a look at /usr/portage/profiles/default-linux/x86/2006.0/make.defaults for the list of current default use flags. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Stefan Schweizer wrote: [Mon Jun 05 2006, 11:03:57AM CDT] -fortran - Do we really need this outdated language as a default in gcc? Although outdated, there are still a lot of applications that use it. More importantly, there are a lot of well-tested numerical libraries that exist in fortran that really aren't worth porting to another language, so a lot of stuff in our tree still requires a fortran compiler. (I don't have good statistics on exactly how much of the tree does, however, so if somebody wants to compile some) Until use-based dependencies arrive, I think it's still required. -motif - is unmaintained in portage and rather outdated, does not look good. Should not be default for optional interfaces I believe that flag is mainly there to reduce the Hey, my xpdf package lacks the xpdf binary bugs. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpvktp4GzQDp.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Stefan Schweizer wrote: -fortran - Do we really need this outdated language as a default in gcc? I am not on the toolchain team, but I _think_ the reason this is on by default is because fortran is considered part of a standard gcc installation (by upstream, etc). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, Jun 05, 2006 at 06:03:57PM +0200, Stefan Schweizer wrote: Hi, today I would like to propose a few default keywords for removal. They are outdated and no longer needed on current systems: -imlib - imlib depends on gtk-1, which imo should not be installed in a default gentoo installation - there should be no legacy depends for a plain emerge kde. I see imlib doesn't forcibly depend on gtk1 in the 1.9.15 version. It's been in the tree for a year, but never unmasked apparently. Maybe that would be a better idea than removing this flag as a default? (Honest question, I'm not sure.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Monday 05 June 2006 18:03, Stefan Schweizer wrote: I would like to make the changes in a new 2006.1 profile, how do I go about that? I think the current profiles should not be touched, since some users may still be using the flags. Yes, 2006.1. Any comments/objections - any outdated useflags I forgot? Have a look at /usr/portage/profiles/default-linux/x86/2006.0/make.defaults for the list of current default use flags. I think gtk2 should be finally removed¹ from all packages and from make.defaults as well, before the 2006.1 release. Maintainers, who explicitly want to allow building against using Gtk 1, should default their ebuilds to Gtk 2 and add a (local) gtk1 use flag instead. Is there a good reason, why mikmod is a enabled by default? [1] https://bugs.gentoo.org/show_bug.cgi?id=106560 Carsten pgp87dCwsaOKF.pgp Description: PGP signature
Re: [gentoo-dev] eutils.class fix for make_desktop_entry
On 6/5/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Go ahead and do it now. It really shouldn't break anything, as I can't think of a single thing using make_desktop _entry with a space in the executable name. What about games-board/gnubg-0.14.3 ? Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, Jun 05, 2006 at 06:59:22PM +0200, Carsten Lohrke wrote: Any comments/objections - any outdated useflags I forgot? Have a look at /usr/portage/profiles/default-linux/x86/2006.0/make.defaults for the list of current default use flags. I think gtk2 should be finally removed¹ from all packages and from make.defaults as well, before the 2006.1 release. Maintainers, who explicitly want to allow building against using Gtk 1, should default their ebuilds to Gtk 2 and add a (local) gtk1 use flag instead. No, the decision with the gtk/gtk2 USE flag mess was to have package maintainers decide for each ebuild whether to support only gtk1 or only gtk2, but not have support for both in a single ebuild. The decision before that (and one with more support, IIRC) was to have one flag for gtk1, and one flag for gtk2. But what you're proposing now is getting back to the old mess, except defaulting to gtk2 instead of gtk1. That not only doesn't fix anything, but even says that gtk1 support was removed from a bunch of ebuilds for no benefit whatsoever. Please don't do that. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Monday, 5. June 2006 18:03, Stefan Schweizer Ви написали: -fortran - Do we really need this outdated language as a default in gcc? Which one, Fortran-99 or Fortran-2006? ;) (Well, Ok, gfortran in gcc does not do 2006 yet, but still..) On the usage side: if you do that (i.e. remove it) you will be amazed by how many packages need it and how many users will cry foul because some dependency of their favorite app requires Fortran and now they have to rebuild gcc (or they even have no idea where to get Fortran from; yea, that happened too). It is for this precise reason that this useflag was *added* to default profiles not so long ago (well, about two years now :)). And this is like the 3rd time somebody wants to rip it off, just because this is some kind of outdated language ;). Can we please leave it alone finally? Pretty please? :). George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] removal of cgi-based gwebcache servers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since no one has shown concern for these poor, frightened packages, they will be humanely removed from portage. - -Jon Jon Hood wrote: If anyone has ever tried to run a gnutella gwebcache, they've probably noticed about 8-10 requests a second. And it increases during high-usage hours. This makes it useless to run cgi-based scripts unless you have a super-powerful database and web server. Since the usefulness of such scripts has gone to practically 0, they are no longer maintained upstream and I recommend the removal of them from portage. The following packages headed for the guillotine are: net-p2p/phpgnucacheii net-p2p/gwebcache net-p2p/perlgcache The recommended package for anyone wanting to support the gnutella network is net-p2p/ghostwhitecrab, which is its own built-in server. Ghostwhitecrab will continue to be maintained both upstream and in portage. If someone would like to save these packages from a gruesome death, speak now. If not, I'll post another message to gentoo-dev right before the massacre, and everyone's welcome to join #gentoo-commits to watch the gore. -Jon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEhHrjEMeNCT59gpcRAss0AKC3HUMp2wfnSCLf89NplZc3fROOJACfWb2C tRQL1vV253OuIaKfrftisME= =hL2s -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for dev-embedded/sdcc-cvs
Denis Dupeyron wrote: dev-embedded/sdcc-cvs will be masked right now, and then removed in a month or so if nobody complains. dev-embedded/sdcc-cvs is now removed. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, 2006-06-05 at 18:03 +0200, Stefan Schweizer wrote: I would like to make the changes in a new 2006.1 profile, how do I go about that? I think the current profiles should not be touched, since some users may still be using the flags. Considering most architectures already have a 2006.1 profile in development, you talk with Release Engineering or the arch teams to get the profile changes made. Any comments/objections - any outdated useflags I forgot? Yeah. Don't touch the x86 2006.1 profiles. Once the merit of removing/adding any flags has been discussed here, I'll make the changes to the development 2006.1 profile for x86. Have a look at /usr/portage/profiles/default-linux/x86/2006.0/make.defaults for the list of current default use flags. No. Have a look at /usr/portage/profiles/default-linux/x86/dev/2006.1/desktop/make.defaults for the list of what will be the default USE flags. Please be sure to actually talk to the teams in question before making such requests as this in the future. It really helps if you work with the teams rather than going all rogue with this stuff. Thanks, -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] eutils.class fix for make_desktop_entry
On Mon, 2006-06-05 at 17:24 +, Denis Dupeyron wrote: On 6/5/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Go ahead and do it now. It really shouldn't break anything, as I can't think of a single thing using make_desktop _entry with a space in the executable name. What about games-board/gnubg-0.14.3 ? There's no space in the executable name. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Please add net-wireless/rtl818x
thus package is a branch of the rtl8180-sa2400http://sourceforge.net/projects/rtl818xonly cvsthanks--aryix
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, Jun 05, 2006 at 07:03:57PM +0200, Stefan Schweizer wrote: today I would like to propose a few default keywords for removal. They are outdated and no longer needed on current systems: What do you want to remove, the use flags themselves or just turn them off in the profiles? -xmms - xmms depends on gtk-1 and has been superseeded by audacious/bmpx xmms is still in the tree? People (ok, at least me ;-) ) still use it? I don't mind if it has to go and there are alternatives, but why would you just want to remove its use flag and not the package itself? If it needs to go, either dump all of it or nothing. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgp55p4VPF3NW.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Monday 05 June 2006 20:08, Harald van Dijk wrote: No, the decision with the gtk/gtk2 USE flag mess was to have package maintainers decide for each ebuild whether to support only gtk1 or only gtk2, but not have support for both in a single ebuild. I know about the decision of the Gnome team, but there also was a thread with maintainers refusing to remove optional gtk1|2 support, if I recall correctly. Personally I couldn't care less, as long as the gtk2 flag is history. Carsten pgpE5mi6hfQyp.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Monday 05 June 2006 20:52, Chris Gianelloni wrote: Have a look at /usr/portage/profiles/default-linux/x86/2006.0/make.defaults for the list of current default use flags. I think it's a bad idea to have win32codecs in make.defaults. There's quite a number of codecs in the package and I'm not so sure, that we even notice, when there are any vulnerable ones. Also the licensening and distribution question is everything else than clear. btw.: We don't even have a avi use flag in the tree anymore. Carsten pgpFldGsBUj3v.pgp Description: PGP signature
[gentoo-dev] evolution of x86 stabling procedures
I maintain very few packages these days, so it was quite a surprise to me today when I discovered that peer review is now effectively a part of the x86 stabilization process. When I wrote GLEP 40, the problem that I was trying to solve was that of devs stabling packages without ever testing the package on an actual stable system (because most devs run ~arch). As such, the language in GLEP 40 essentially suggests that devs could still stable their own packages, but only if they were properly testing the package on a stable system. That policy has evolved over time to one where devs are actively discouraged from stabling their own packages, thereby ensuring that at least one other person examines and tests the ebuild before it becomes stable. (I'm still not quite sure of the actual procedure, so I'm not sure how many people are generally involved in this peer review process.) From a QA perspective, more eyes can only be a good thing, and this idea has been tossed around on-and-off for years. On the other hand, peer review could potentially really slow things down, which is why we'd always rejected that approach in the past. Are other arch's also requiring peer review? Do we have any statistics or anecdotal evidence for what's improving, and whether or not anything is getting worse as a result? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpcIG0ZQQWuA.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, 2006-06-05 at 21:22 +0200, Wernfried Haas wrote: On Mon, Jun 05, 2006 at 07:03:57PM +0200, Stefan Schweizer wrote: today I would like to propose a few default keywords for removal. They are outdated and no longer needed on current systems: What do you want to remove, the use flags themselves or just turn them off in the profiles? -xmms - xmms depends on gtk-1 and has been superseeded by audacious/bmpx xmms is still in the tree? People (ok, at least me ;-) ) still use it? I don't mind if it has to go and there are alternatives, but why would you just want to remove its use flag and not the package itself? If it needs to go, either dump all of it or nothing. Xmms will be removed soon... Lot's of users still use xmms mostly because it has many plugins that others don't. Xmms is still stable but the upstream is dead so it won't take our patchset. In the end of this year i would like to remove xmms and all plugins but before i need to prepare users for this changes and clean some maintainer-wanted bugs for plugins. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] evolution of x86 stabling procedures
Grant Goodyear [EMAIL PROTECTED] said: I maintain very few packages these days, so it was quite a surprise to me today when I discovered that peer review is now effectively a part of the x86 stabilization process. When I wrote GLEP 40, the problem that I was trying to solve was that of devs stabling packages without ever testing the package on an actual stable system (because most devs run ~arch). As such, the language in GLEP 40 essentially suggests that devs could still stable their own packages, but only if they were properly testing the package on a stable system. That policy has evolved over time to one where devs are actively discouraged from stabling their own packages, thereby ensuring that at least one other person examines and tests the ebuild before it becomes stable. (I'm still not quite sure of the actual procedure, so I'm not sure how many people are generally involved in this peer review process.) From a QA perspective, more eyes can only be a good thing, and this idea has been tossed around on-and-off for years. On the other hand, peer review could potentially really slow things down, which is why we'd always rejected that approach in the past. Are other arch's also requiring peer review? Do we have any statistics or anecdotal evidence for what's improving, and whether or not anything is getting worse as a result? Well, since you decided to bring this up on here, I guess we'll just try to address everything. I believe almost everyone has been happy with how the x86 team has turned out. I have only gotten positive feedback from people and users. Despite that, we still have some devs, and *teams*, that don't follow proper keywording procedures. Peer review should be part of any stablization process. The glep that *you* wrote even provides for it: For a package to move to stable, the following guidelines must be met: ... * The relevant arch team must agree to it. Maybe it was not what you intended, but we have not been slowing down any process as far as I'm aware, since we get to our bugs as quickly as we possibly can. And every arch team has their own keywording policy. I don't see why x86 can not have the poilcy that we decided on. If you have MIPS hardware and you mark something ~mips, I'm pretty sure they will be pissed if they didn't give you prior permission. Probably the same for a few archs. The x86 team has been asking for months now that everyone files a bug to have their package stablized, and we allow maintainers to stablize their package when it is impossible for us to do so. I'm trying to figure out why this is a problem all of a sudden, because things seemed to be going just fine. Thanks, -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpOD1VY3Mhq5.pgp Description: PGP signature
Re: [gentoo-dev] evolution of x86 stabling procedures
On Mon, Jun 05, 2006 at 03:00:57PM -0500, Grant Goodyear wrote: I maintain very few packages these days, so it was quite a surprise to me today when I discovered that peer review is now effectively a part of the x86 stabilization process. When I wrote GLEP 40, the problem that I was trying to solve was that of devs stabling packages without ever testing the package on an actual stable system (because most devs run ~arch). As such, the language in GLEP 40 essentially suggests that devs could still stable their own packages, but only if they were properly testing the package on a stable system. That policy has evolved over time to one where devs are actively discouraged from stabling their own packages, thereby ensuring that at least one other person examines and tests the ebuild before it becomes stable. (I'm still not quite sure of the actual procedure, so I'm not sure how many people are generally involved in this peer review process.) From a QA perspective, more eyes can only be a good thing, and this idea has been tossed around on-and-off for years. On the other hand, peer review could potentially really slow things down, which is why we'd always rejected that approach in the past. Are other arch's also requiring peer review? Do we have any statistics or anecdotal evidence for what's improving, and whether or not anything is getting worse as a result? The Alpha team does the exact same thing. Requiring devs to file stable bugs even if they can test on alpha hardware themselves or in some cases devs outside the team are allowed to keyword a few packages. I've never put this into system the way the x86 team has, mostly because it's never been much of a problem with few devs having alpha hardware. It's more been a case of me (or other devs from the alpha team) randomly catching other devs in touching our keywords and asking them to abide by our keywording policy. Also, looking at http://devmanual.gentoo.org/archs/index.html you see similar policies for almost all the archs described there. The big difference I think, being how big a hammer arch teams apply and how much attention they pay to the tree regarding their keywords. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, Jun 05, 2006 at 09:58:46PM +0100, Luis Medinas wrote: xmms is still in the tree? People (ok, at least me ;-) ) still use it? I don't mind if it has to go and there are alternatives, but why would you just want to remove its use flag and not the package itself? If it needs to go, either dump all of it or nothing. Xmms will be removed soon... Lot's of users still use xmms mostly because it has many plugins that others don't. Xmms is still stable but the upstream is dead so it won't take our patchset. In the end of this year i would like to remove xmms and all plugins but before i need to prepare users for this changes and clean some maintainer-wanted bugs for plugins. I see, in that case it does make sense to remove the use flag at some point, too. Thanks for clearing it up. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpEfG8KKV51C.pgp Description: PGP signature
Re: [gentoo-dev] evolution of x86 stabling procedures
Mark Loeser wrote: [Mon Jun 05 2006, 03:25:02PM CDT] Well, since you decided to bring this up on here, I guess we'll just try to address everything. Where else would I have brought this up? Paraphrasing, I noted that the x86 team is now doing peer review, I asked if other arch teams are doing the same thing, and I asked how the new system is working, and whether or not the old fears that peer review would slow things down too much seemed to be valid. If that isn't a question for the Gentoo development list, I don't know what is. Nowhere did I say anything evenly remotely negative about what the x86 team is doing, as far as I can tell. If I did, then I sincerely apologize, as it was definitely not my intention. Peer review should be part of any stablization process. The glep that *you* wrote even provides for it: For a package to move to stable, the following guidelines must be met: ... * The relevant arch team must agree to it. Heh. That'll teach me! Maybe it was not what you intended, but we have not been slowing down any process as far as I'm aware, since we get to our bugs as quickly as we possibly can. And every arch team has their own keywording policy. I don't see why x86 can not have the poilcy that we decided on. If you have MIPS hardware and you mark something ~mips, I'm pretty sure they will be pissed if they didn't give you prior permission. Probably the same for a few archs. I didn't say that the x86 policy was a bad one. I was rather hoping that x86 was doing peer review and at least one other arch team wasn't, since then we could try to make some sort of quantitative comparison. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpVRXLsKvjd5.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, 2006-06-05 at 21:57 +0200, Carsten Lohrke wrote: On Monday 05 June 2006 20:52, Chris Gianelloni wrote: Have a look at /usr/portage/profiles/default-linux/x86/2006.0/make.defaults for the list of current default use flags. I think it's a bad idea to have win32codecs in make.defaults. There's quite a number of codecs in the package and I'm not so sure, that we even notice, when there are any vulnerable ones. Also the licensening and distribution question is everything else than clear. Well, it doesn't affect stages, and GRP stuff is done w/ USE=bindist, so again, this is a non-issue. btw.: We don't even have a avi use flag in the tree anymore. Again, I haven't been in the habit of removing anything I haven't seen a bug about. I'll remove avi now. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] QA subproject, TreeCleaners
On Saturday 03 June 2006 17:43, Alec Warner wrote: I propose a new QA subproject, the TreeCleaners. Great initiative! I'm all for it. For a sidenote, If it is possible, can a unmaintained repo be created for removed packages? If an interested developer comes along the day some time later, and the ebuild is untrivial, it can be a time-saver starting from the last version at some cases - especially if the ebuild was punted because of security issues. -- Eldad Zack [EMAIL PROTECTED] Key/Fingerprint at pgp.mit.edu, ID 0x96EA0A93 pgpl2HUfsggJt.pgp Description: PGP signature
Re: [gentoo-dev] QA subproject, TreeCleaners
On Tuesday 06 June 2006 00:12, Eldad Zack wrote: If an interested developer comes along the day some time later, and the ebuild is untrivial, it can be a time-saver starting from the last version at some cases - especially if the ebuild was punted because of security issues. That's why we use a SCM for managing the ebuilds: the removed ebuilds are still found via cvs commands and on sources.gentoo.org -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpUFZPswYaHp.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Monday 05 June 2006 23:25, Chris Gianelloni wrote: Well, it doesn't affect stages, and GRP stuff is done w/ USE=bindist, so again, this is a non-issue. Well, I didn't mean our binary releases, but being held liable for making property of others available by default, without the permission to do so. Probably not the point, though, since if this argument would be tested, it would already suffice, that the ebuilds are in Portage. My main point is the security status anyways. I don't think we can ensure, that we'll catch known vulnerabilitis for these codecs. I strongly suggest to remove the use flag. Again, I haven't been in the habit of removing anything I haven't seen a bug about. I'll remove avi now. Wasn't a reproach (in case you took it for that). Just noticed it. Carsten pgp2I4M9mOFw6.pgp Description: PGP signature
Re: [gentoo-dev] Please add net-wireless/rtl818x
This list is for development discussions. Please file a request at http://bugs.gentoo.org Carsten pgppRNCcOVLoi.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, 2006-06-05 at 18:03 +0200, Stefan Schweizer wrote: -foomaticdb - foomaticdb is only used for development foomatic xml files. SInce most of our users do not develop printer drivers I suggest making ppds a default use flag instead. Should we have ppds in the 2006.1 profile, or 2006.1/desktop? -oss - oss is a legacy audio interface that has been superseeded by alsa in most current installs, a default use flag is no longer needed There are *many* applications in the tree that do not use ALSA, but work only via the OSS emulation. Removing this is a bad idea and it would definitely be blocked by the games team. Probably half of the packages that I maintain require OSS capabilities. As for the others, they all seem reasonable. I've removed them from the main USE cluster in the x86/dev/2006.1/desktop profile, and into a separate grouping, so they can be easily removed, if that ends up being the decision. So does anyone have any objections to the others being removed? (apm imlib mikmod motif xmms) I won't, of course, do this retroactively, just for the 2006.1 and higher profiles. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Chris Gianelloni wrote: On Mon, 2006-06-05 at 18:03 +0200, Stefan Schweizer wrote: -foomaticdb - foomaticdb is only used for development foomatic xml files. SInce most of our users do not develop printer drivers I suggest making ppds a default use flag instead. Should we have ppds in the 2006.1 profile, or 2006.1/desktop? printers are not only used on desktops, add it in profile please. -oss - oss is a legacy audio interface that has been superseeded by alsa in most current installs, a default use flag is no longer needed There are *many* applications in the tree that do not use ALSA, but work only via the OSS emulation. Removing this is a bad idea and it would definitely be blocked by the games team. Probably half of the packages that I maintain require OSS capabilities. but they do not require an oss use flag. The point of removing this flag is to remove optional oss support. Have a look at http://gentoo-portage.com/Search?search=use=oss for the useage of this flag. And for your games argument. The games ebuilds from the above list I have looked at, provide both the alsa and the oss use flag, as do most really. It is not about removing OSS emulation, it is about removing duplicated backends. So does anyone have any objections to the others being removed? (apm imlib mikmod motif xmms) foomaticdb is missing here, I hope you will not forget it -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, 5 Jun 2006, Chris Gianelloni wrote: So does anyone have any objections to the others being removed? (apm imlib mikmod motif xmms) removing mikmod would probably make things ugly for games as well. A lot of games need mikmod support compiled into sdl-mixer in order to function correctly. Some games fail in pkg_setup if sdl-mixer isn't built with mikmod but I'm not sure if we've added the built_with_use check to all of the games that need it yet. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tue, 2006-06-06 at 04:10 +0200, Stefan Schweizer wrote: There are *many* applications in the tree that do not use ALSA, but work only via the OSS emulation. Removing this is a bad idea and it would definitely be blocked by the games team. Probably half of the packages that I maintain require OSS capabilities. but they do not require an oss use flag. The point of removing this flag is to remove optional oss support. Umm... you don't know what you're talking about. The optional OSS support is in ALSA. The packages have required OSS for sound support. Have a look at http://gentoo-portage.com/Search?search=use=oss for the useage of this flag. I know what the flag is used for, and I'm not removing it. And for your games argument. The games ebuilds from the above list I have looked at, provide both the alsa and the oss use flag, as do most really. Do you even know what you're talking about? Have you tried Quake 3? Enemy Territory? Have you noticed that they don't have sound, at all, without OSS emulation? You do know how OSS emulation is turned on, correct? Please do me a favor and quit wasting my time and yours trying to tell me what the packages that I maintain support. It is not about removing OSS emulation, it is about removing duplicated backends. You're simply wrong. So does anyone have any objections to the others being removed? (apm imlib mikmod motif xmms) foomaticdb is missing here, I hope you will not forget it It isn't the the desktop profile. It was in the 2006.1 profile, which is desktop's parent. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Carsten Lohrke wrote: On Monday 05 June 2006 20:08, Harald van Dijk wrote: No, the decision with the gtk/gtk2 USE flag mess was to have package maintainers decide for each ebuild whether to support only gtk1 or only gtk2, but not have support for both in a single ebuild. I know about the decision of the Gnome team, but there also was a thread with maintainers refusing to remove optional gtk1|2 support, if I recall correctly. Personally I couldn't care less, as long as the gtk2 flag is history. Sorry for the offtopic of this, but what would a user set as the useflags to have GTK-2 used by default, and GTK-1 for apps that only support it? (but not build GTK-2-capable apps with GTK-1) Just wondering, because I know that gmplayer is from the mplayer package's gtk flag.. its gtk-1 so its not the optimal, but since i don't know of a gtk2 version (i do have kmplayer tho.. so its sorta a moot point for me.. i think its time i clean my install..) Anyways, I agree that some of the defaults are a bit more liberal then i would perfer, but hey, i can change anything i want (thats the power of gentoo) Thanks, Andrew -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] evolution of x86 stabling procedures
On Mon, 5 Jun 2006 15:00:57 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: Are other arch's also requiring peer review? On SPARC, we normally keyword everything ourselves and get all up in your hizzouze if you keyword something that you haven't asked us about. We normally will let devs keyword their packages once we have an assurance that they have access to appropriate hardware to test things, and keep track of this via a list on the devwiki SPARC page. We have a couple of scripts that email us keyword info on ebuilds so we can watch and see who may be doing bad things. Cheers, -- Jason Wever Gentoo/Sparc Team Co-Lead signature.asc Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Monday 05 June 2006 12:16, Patrick McLean wrote: Stefan Schweizer wrote: -fortran - Do we really need this outdated language as a default in gcc? I am not on the toolchain team, but I _think_ the reason this is on by default is because fortran is considered part of a standard gcc installation (by upstream, etc). pretty much ... fortran is expected to be part of the default build thus it is i personally disable fortran on all my machines though ;) -mike pgpiBe3mciBTR.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Monday 05 June 2006 12:03, Stefan Schweizer wrote: -apm -imlib -motif kill em ! -fortran - Do we really need this outdated language as a default in gcc? fortran 4 eva -mike pgpZ84k1Z4HDK.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Monday 05 June 2006 21:23, Chris Gianelloni wrote: On Mon, 2006-06-05 at 18:03 +0200, Stefan Schweizer wrote: -oss - oss is a legacy audio interface that has been superseeded by alsa in most current installs, a default use flag is no longer needed There are *many* applications in the tree that do not use ALSA, but work only via the OSS emulation. Removing this is a bad idea and it would definitely be blocked by the games team. Probably half of the packages that I maintain require OSS capabilities. do we really need the USE flag though ? i was under the impression that you need to enable the OSS compat layer in the kernel and that's enough ... and the USE flag doesnt affect kernel build options ... As for the others, they all seem reasonable. I've removed them from the main USE cluster in the x86/dev/2006.1/desktop profile, and into a separate grouping, so they can be easily removed, if that ends up being the decision. umm, add back in fortran there bub So does anyone have any objections to the others being removed? (apm imlib mikmod motif xmms) mikmod is the only one i'd keep ... people generally want mikmod whether or not they know it ;) -mike pgpGgc2ayavrr.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tue, Jun 06, 2006 at 12:07:42AM -0400, Mike Frysinger wrote: On Monday 05 June 2006 21:23, Chris Gianelloni wrote: On Mon, 2006-06-05 at 18:03 +0200, Stefan Schweizer wrote: -oss - oss is a legacy audio interface that has been superseeded by alsa in most current installs, a default use flag is no longer needed There are *many* applications in the tree that do not use ALSA, but work only via the OSS emulation. Removing this is a bad idea and it would definitely be blocked by the games team. Probably half of the packages that I maintain require OSS capabilities. do we really need the USE flag though ? i was under the impression that you need to enable the OSS compat layer in the kernel and that's enough ... and the USE flag doesnt affect kernel build options ... It depends on whether you use the kernel drivers or the alsa-driver package, I think. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tuesday 06 June 2006 01:31, Harald van Dijk wrote: On Tue, Jun 06, 2006 at 12:07:42AM -0400, Mike Frysinger wrote: On Monday 05 June 2006 21:23, Chris Gianelloni wrote: On Mon, 2006-06-05 at 18:03 +0200, Stefan Schweizer wrote: -oss - oss is a legacy audio interface that has been superseeded by alsa in most current installs, a default use flag is no longer needed There are *many* applications in the tree that do not use ALSA, but work only via the OSS emulation. Removing this is a bad idea and it would definitely be blocked by the games team. Probably half of the packages that I maintain require OSS capabilities. do we really need the USE flag though ? i was under the impression that you need to enable the OSS compat layer in the kernel and that's enough ... and the USE flag doesnt affect kernel build options ... It depends on whether you use the kernel drivers or the alsa-driver package, I think. you dont use alsa-driver with 2.6 kernels and the 2006.1 profiles are 2.6 based -mike pgpPVpHq02df6.pgp Description: PGP signature
