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 " as query, e.g. http://www.google.ch/search?q=site%3Asources.gentoo.org+sonar&btnG=Suche&meta= -- 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] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 5 Jun 2006, Stefan Schweizer wrote: -xmms - xmms depends on gtk-1 and has been superseeded by audacious/bmpx At least on SPARC (and possibly other arches, but I'll let them speak for themselves), there has yet to be an XMMS compatible replacement that is anywhere near as stable as XMMS is. Until audacious or bmpx or the latest fork of a GTK2 based XMMS derivative is on par with XMMS, I'd like to ask that it stay in the tree (assuming no security issues pop up that we decide not to patch). Cheers, - -- Jason Wever Gentoo/Sparc Team Co-Lead -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEhaw0dKvgdVioq28RArT1AKCokQ0IKHDrgEQ7ugH+6+NlncpvHgCgofV0 K49fS9iBPdiqw0pwGXmzC14= =PCMT -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
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
