Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tue, Jun 06, 2006 at 01:48:37AM -0400, Mike Frysinger wrote: 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 You can use alsa-driver with 2.6 kernels. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Monday 05 June 2006 23:13, Harald van Dijk wrote: On Tue, Jun 06, 2006 at 01:48:37AM -0400, Mike Frysinger wrote: 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 You can use alsa-driver with 2.6 kernels. I use alsa-driver with 2.6 kernels. I forget exactly why (this was almost two years ago), but I actually switched _away_ from the in-kernel-tree drivers to alsa-driver for some particular reason. I have the oss useflag turned off, and then turned back on for alsa-driver in package.use. -- # # electronerd, the electronerdian from electronerdia # pgpa5PBuL3EH2.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, 05 Jun 2006 21:23:58 -0400, Chris Gianelloni [EMAIL PROTECTED] 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. I think the problem is that the oss flag is used for (at least) two slighlty different things: - in alsa-driver, it adds OSS capabilities. That's something most people want, and should be enable by default. - in most (all?) other packages, it enables optionnal OSS output. That's something most people don't use and don't wan't enabled by default. Imho, when there is no good global value for a flag, it means it shouldn't be a single global flag (at least, until there is some kind of per-package defaults support in Portage). So, what about a local oss-emulation flag instead in alsa-drivers, which would be the only one turned on in profiles? Wouldn't it makes everyone happy? -- TGL. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Chris Gianelloni wrote: 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. I think this is a perfect time to point out the past discussions about trying to be polite to fellow developers and the community at large. There's no reason to try to constantly point out you're an idiot and I'm so great. I wield the power! Stefan made suggestions in good intentions. Lot's of us have the same suggestions, however he actually had the initiative to bring them up and offer to help fix them based on what was decided upon. Every step along the way you've tried to bash him and highlight your greatness. Get down off your pedestal... we're all developers here. All contributing to the greater good. Accept the help and move on. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Mike Frysinger wrote: -fortran - Do we really need this outdated language as a default in gcc? fortran 4 eva -mike Mike, Are you flashing fortran gang signs at us? -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tuesday 06 June 2006 04:45, Andrew Muraco wrote: 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 the gtk use flag. Carsten pgp2dKgmdERfv.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tuesday 06 June 2006 06:07, Mike Frysinger wrote: mikmod is the only one i'd keep ... people generally want mikmod whether or not they know it ;) I'd say 99,9% don't want mikmod. Arguments please, not vague assertions. :) Carsten pgpMnmHuAbjLA.pgp Description: PGP signature
Re: [gentoo-dev] Re: Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tuesday 06 June 2006 04:11, Michael Sterrett -Mr. Bones.- wrote: 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. Time to fix this. And removing the flag would help, as bugs would be filed. Carsten pgpTLPShOXpNw.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tuesday 06 June 2006 11:17, Carsten Lohrke wrote: I'd say 99,9% don't want mikmod. Arguments please, not vague assertions. :) SDL based games requires mikmod quite often. I suppose Mike knows what he's saying. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp5k7lnsFXCV.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tuesday 06 June 2006 08:34, John Myers wrote: I use alsa-driver with 2.6 kernels. I forget exactly why (this was almost two years ago), but I actually switched _away_ from the in-kernel-tree drivers to alsa-driver for some particular reason. There are a few issues with in-kernel driver when they are not in-sync with the userland, ALSA does not assure compatibility between versions. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpg3hG1xnqEh.pgp Description: PGP signature
[gentoo-dev] maybe im wrong here but nsswitch and udev
actually my x86 maschine makes at boot when it starts udev an ldap request and waits 6 ... 8 ...16 sec so at this time ldap is not running so what wants udev at this early stage ? my nsswitch.conf hosts files dns ldap and all users,groups,DNS,DHCP are stored in ldap -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tuesday 06 June 2006 11:25, Diego 'Flameeyes' Pettenò wrote: SDL based games requires mikmod quite often. I suppose Mike knows what he's saying. It's a difference to know that, compared to share ones thoughts, which Mike missed to do. Carsten pgp1iJ8Y6QlGG.pgp Description: PGP signature
[gentoo-dev] Default useflag cleanups - discussion status
Hi, so the thread is getting a bit long, I will just summarize the status -apm -foomaticdb -imlib -motif -xmms Those are more or less without objections -fortran - I am dropping this request, seems fortran is meant to be default -oss - apparently people are fighting this one. Flameeyes also brought up in IRC that this can cause arts being selected as a backend instead of oss, which is certainly not desirable. Also some packages might not give sound at all without the oss useflag. All packages with IUSE=oss need to be checked for this and fixed properly. Although some people think it is USEflagspam I am voting for an ossemu use flag here. If you want to help with this effort, we need to create a tracker bug and check [1] 71 packages :) Also there came up a few more suggestions: -mikmod - This came from wolf31o2 and I do not like it. mikmod is used in many games and I think it gives people less hassle to have it as default. The intention of this request is to make use-setting easier, not harder. Please do not remove this flag. -gtk2 - This has been brought up by carlo. And it makes sense although not in the 2006.1 profile. This needs to happen in all profiles and can only happen once all those flags have been removed from ebuilds. So, sorry, but this needs more work and cannot be put in the same request. If you want to help for this, please have a look at [2] [1] http://gentoo-portage.com/Search?search=use=oss [2] https://bugs.gentoo.org/show_bug.cgi?id=1065602 - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups - discussion status
On Tuesday 06 June 2006 12:13, Stefan Schweizer wrote: If you want to help with this effort, we need to create a tracker bug and check [1] 71 packages :) Add to fix and mark stable, _stable_, them before 2006.1 release. Oh and of course you'll have to take the pieces if something breaks :P Again, I don't think this is much of advantage compared to the disadvantages, especially since I for one don't want to waste time on this if users starts complaining. Sound has enough problems by itself. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpsDIpGVQ46c.pgp Description: PGP signature
Re: [gentoo-dev] QA subproject, TreeCleaners
On Втр, 2006-06-06 at 00:17 +0200, Diego 'Flameeyes' Pettenò wrote: 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 But how can I search for removed ebuild in cvs? Is there any quick way for such things? Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] QA subproject, TreeCleaners
Peter Volkov (pva) wrote: But how can I search for removed ebuild in cvs? Is there any quick way for such things? Use site:sources.gentoo.org package as query, e.g. http://www.google.ch/search?q=site%3Asources.gentoo.org+sonarbtnG=Suchemeta= -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Why are you hijacking tools not written by you, declaring them as 2.0 and breaking the expected behaviors of them? Please don't do that ever again. On Fri, 2006-06-02 at 21:24 -0700, Jeremy Huddleston wrote: I finally had a few free cycles, so I fixed up the eselect-compiler ebuild to better handle the transition from gcc-config and updated toolchain.eclass to better work with multilib. I've had a bunch of help from the amd64 devs/testers/users this past week testing it out, and I think it's ready to be removed from package.mask sometime soon (next week). Before that happens, I'd like to get some feedback from a broader test base, so if you have some time and aren't using eselect-compiler yet, I'd appreciate your testing. All you need to do is add the following to /etc/portage/package.unmask: app-admin/eselect-conmpiler sys-devel/gcc-config then just update gcc-config: $ emerge -uv --oneshot sys-devel/gcc-config gcc-config is just a wrapper which takes the same syntax as the older gcc-configs and makes the appropriate call to eselect-compiler. Please report any bugs you find in bugzilla and assign them directly to me ([EMAIL PROTECTED]). Also, if you've been using eselect-compiler, you may have an issue where your profiles don't get removed from /etc/eselect/compiler when you unmerge gcc. This problem is fixed now for future installs, but you'll have to manually remove the file when you unmerge any gcc that is on your system now. Thanks, Jeremy -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA subproject, TreeCleaners
Peter Volkov (pva) wrote: On Втр, 2006-06-06 at 00:17 +0200, Diego 'Flameeyes' Pettenò wrote: 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 But how can I search for removed ebuild in cvs? Is there any quick way for such things? Peter. I am still thinking about hosting the ebuilds in an overlay somewhere, but yeah the ebuilds will be in the Attic, if/when we migrate to something !CVS, Attic migrates with us. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [snip] Lets keep this friendly. Obviously genstef was mistaken about the oss use flag. He's not trying to break any of your packages. - -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Developer Relations Gentoo Recruitment Lead Gentoo Infrastructure GPG: 0094 7F06 913E 78D6 F1BB 06BA D0AD D125 A797 C7A7 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEhZNK0K3RJaeXx6cRArX2AKCxwhdOFcmVIYxmHReYyi5sn0mfZACgs5/o rQX2TbJi/Am0Rn+fvK+EPtQ= =SXov -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tue, 2006-06-06 at 00:07 -0400, Mike Frysinger 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. 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 ... Only if you use the in-kernel ALSA. If you use the external alsa-driver, then the OSS support is controlled by the USE flag. umm, add back in fortran there bub I never touched it. It's in default-linux, not in my profile. 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 ;) I was wondering if we should keep it. There are quite a few packages that we know of that require it to be built into sdl-mixer, but I think we're currently masking a lot of the bugs in the ebuilds because it is set as default. At any rate, I've added it back to the keep pile. -- 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
On Tue, 2006-06-06 at 08:40 +0200, Thomas de Grenier de Latour wrote: On Mon, 05 Jun 2006 21:23:58 -0400, Chris Gianelloni [EMAIL PROTECTED] 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. I think the problem is that the oss flag is used for (at least) two slighlty different things: - in alsa-driver, it adds OSS capabilities. That's something most people want, and should be enable by default. - in most (all?) other packages, it enables optionnal OSS output. That's something most people don't use and don't wan't enabled by default. Imho, when there is no good global value for a flag, it means it shouldn't be a single global flag (at least, until there is some kind of per-package defaults support in Portage). So, what about a local oss-emulation flag instead in alsa-drivers, which would be the only one turned on in profiles? Wouldn't it makes everyone happy? It would satisfy my requirements/needs. -- 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 - discussion status
On Tue, 2006-06-06 at 12:13 +0200, Stefan Schweizer wrote: -mikmod - This came from wolf31o2 and I do not like it. mikmod is used in many games and I think it gives people less hassle to have it as default. The intention of this request is to make use-setting easier, not harder. Please do not remove this flag. Actually, I didn't bring this one up, someone else did. I just added it to my list. I've since removed it from my list, since it seems that it will cause more damage than good, though I personally run without it and have no problems. This is another of those cases where per-package USE defaults would help, as we could enable it for SDL-mixer and be done with it. -gtk2 - This has been brought up by carlo. And it makes sense although not in the 2006.1 profile. This needs to happen in all profiles and can only happen once all those flags have been removed from ebuilds. So, sorry, but this needs more work and cannot be put in the same request. If you want to help for this, please have a look at [2] Correct. I really would prefer not touch this one until it really is gone from the tree. -- 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] maybe im wrong here but nsswitch and udev
On Tue, Jun 06, 2006 at 10:48:51AM +0100, J?rgen Schinker wrote: actually my x86 maschine makes at boot when it starts udev an ldap request and waits 6 ... 8 ...16 sec so at this time ldap is not running so what wants udev at this early stage ? my nsswitch.conf hosts files dns ldap and all users,groups,DNS,DHCP are stored in ldap Please search for bugs next time. A search string of 'nss udev' to bugzilla, would take you to bug 99564. The udev/nss_ldap thing has been brewing for a while, and we're still trying to get upstream udev to fix the issue. http://bugs.gentoo.org/show_bug.cgi?id=99564#c44 In that comment I list the proper solution that upstream needs to undertake (make udev not lookup nss entries unless it is actually creating device nodes that need the entries), and some other workarounds. There's one additional workaround, that makes the new nss_ldap retry behavior closer to the old behavior (1 retry, 1 second gap, not configurable): For the timeouts, add these three lines to /etc/ldap.conf on affected machines: nss_reconnect_tries 0 nss_reconnect_sleeptime 1 nss_reconnect_maxconntries 4 That won't remove the problem, but it will greatly reduce the waiting. Also FYI, if you have an /etc/ldap.conf line that continues 'ssl on', change it to 'ssl start_tls'. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp6LYaGpeJLb.pgp Description: PGP signature
Re: [gentoo-dev] maybe im wrong here but nsswitch and udev
On Tue, Jun 06, 2006 at 11:05:00AM -0700, Robin H. Johnson wrote: The udev/nss_ldap thing has been brewing for a while, and we're still trying to get upstream udev to fix the issue. http://bugs.gentoo.org/show_bug.cgi?id=99564#c44 In that comment I list the proper solution that upstream needs to undertake (make udev not lookup nss entries unless it is actually creating device nodes that need the entries), and some other workarounds. upstream agrees that this is the proper solution, yet no one has sent a patch to fix this yet. Combine this with a lack of free time to work on things like this by upstream, and we have a stalled bug :) thanks, greg k-h -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Uhm, what is this all about? If you have suggestions, make them, but don't come out of the gate in a huff talking about unsubstantiated breakage. That's about the least constructive way to get heard. The wrapper provided in gcc-config-2.0 provides the exact same interface to the user as gcc-config-1.x, so how is that breaking expected behavior? If anything, it's providing expected behavior to users who want it and don't care about migrating over to eselect. Additionally, If you check through the ChangeLog, you'll see that I did actively worked on gcc-config-1.x last year prior to my starting eselect-compiler. That's how I came to realize its limitations and _need_ for replacement on multilib systems. A similar wrapper is needed for binutils as has been discussed multiple times on toolchain@, and at amd64 and ppc64 dev meetings on IRC. Additionally, eselect-compiler has been discussed multiple times on the toolchain and gentoo-dev lists over the past year (main threads started 2005-08-09, 2005-09-17, 2005.10.02), and you didn't once raise an objection until now. I'd say you missed the 10 month window I gave you, but if you do have suggestions, I'd be more than happy to hear them. Even more so, I left eselect-compiler in package.mask for a _very_ long time as I didn't have much time to devote to its development over the past school year. During that time, very few issues were raised despite it being used by many testers and developers. This past month, I worked out all but one of the known bugs (the one remaining is just specific to the wine package on amd64) and got more testers to give it a final beating before finally unmasking it. If anything, this has been an extremely conservative development process because of the nature of this package. --Jeremy On Jun 6, 2006, at 04:28 , Ned Ludd wrote: Why are you hijacking tools not written by you, declaring them as 2.0 and breaking the expected behaviors of them? Please don't do that ever again. On Fri, 2006-06-02 at 21:24 -0700, Jeremy Huddleston wrote: I finally had a few free cycles, so I fixed up the eselect-compiler ebuild to better handle the transition from gcc-config and updated toolchain.eclass to better work with multilib. I've had a bunch of help from the amd64 devs/testers/users this past week testing it out, and I think it's ready to be removed from package.mask sometime soon (next week). Before that happens, I'd like to get some feedback from a broader test base, so if you have some time and aren't using eselect-compiler yet, I'd appreciate your testing. All you need to do is add the following to /etc/portage/package.unmask: app-admin/eselect-conmpiler sys-devel/gcc-config then just update gcc-config: $ emerge -uv --oneshot sys-devel/gcc-config gcc-config is just a wrapper which takes the same syntax as the older gcc-configs and makes the appropriate call to eselect-compiler. Please report any bugs you find in bugzilla and assign them directly to me ([EMAIL PROTECTED]). Also, if you've been using eselect-compiler, you may have an issue where your profiles don't get removed from /etc/eselect/compiler when you unmerge gcc. This problem is fixed now for future installs, but you'll have to manually remove the file when you unmerge any gcc that is on your system now. Thanks, Jeremy -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Am Montag, 5. Juni 2006 18:03 schrieb Stefan Schweizer: today I would like to propose a few default keywords for removal. keywords? They are outdated and no longer needed on current systems: -fortran - Do we really need this outdated language as a default in gcc? Remove this and you'll break merging of approx. 30% of the ebuild in scientific herd. As long as there is no use-based deps, fortran should stay in default. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Wed, 2006-06-07 at 01:05 +0200, Danny van Dyk wrote: Am Montag, 5. Juni 2006 18:03 schrieb Stefan Schweizer: today I would like to propose a few default keywords for removal. keywords? They are outdated and no longer needed on current systems: -fortran - Do we really need this outdated language as a default in gcc? Remove this and you'll break merging of approx. 30% of the ebuild in scientific herd. As long as there is no use-based deps, fortran should stay in default. I had no intentions of touching anything in the default-linux/make.defaults, as they are all there for a reason. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-portage-dev] [PATCH] Update www-apache/mod_jk to 1.2.15
The following patch upgrades www-apache/mod_jk to 1.2.15 (current latest available version in portage is 1.2.13 which has numerous evil bugs). This is my first submission so I wasn't sure if attached patches are preferred to inline ones (or vice versa). Let me know if there's any other recommended submission techniques. --Paul mod_jk-1.2.15.patch Description: Binary data
Re: [gentoo-portage-dev] [PATCH] Update www-apache/mod_jk to 1.2.15
Paul Dlug wrote: The following patch upgrades www-apache/mod_jk to 1.2.15 (current latest available version in portage is 1.2.13 which has numerous evil bugs). This is my first submission so I wasn't sure if attached patches are preferred to inline ones (or vice versa). Let me know if there's any other recommended submission techniques. Oops, this list is for portage (the package manager) development, not for the portage tree (the ebuilds, eclasses, etcetera found in /usr/portage). Issues with the latter (such as an update to mod_jk) should be filed on bugs.gentoo.org. (I know, it's a patch, not a bug, but we use bugzilla for all of those sorts of things.) Thanks, g2boojum signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] Update www-apache/mod_jk to 1.2.15
On 6/6/06, Grant Goodyear [EMAIL PROTECTED] wrote: Paul Dlug wrote: The following patch upgrades www-apache/mod_jk to 1.2.15 (current latest available version in portage is 1.2.13 which has numerous evil bugs). This is my first submission so I wasn't sure if attached patches are preferred to inline ones (or vice versa). Let me know if there's any other recommended submission techniques.Oops, this list is for portage (the package manager) development, notfor the portage tree (the ebuilds, eclasses, etcetera found in /usr/portage).Issues with the latter (such as an update to mod_jk)should be filed on bugs.gentoo.org.(I know, it's a patch, not a bug,but we use bugzilla for all of those sorts of things.) Thanks for the info, I'll submit it in Bugzilla, someone should really correct the info on the portage page in the Submitting Patches section: http://www.gentoo.org/proj/en/portage/Another newbie question: is there an equivalent of the FreeBSD Porters Handbook for portage? Something that covers how to create ebuild files and general guidelines for USE flags? Thanks,Paul
