Re: [gentoo-dev] Resurrecting "Project Dolphin"
On Sat, 14 Oct 2006, Benjamin Judas wrote: Hello folks, I took the decision to reanimate "Project Dolphin". Dolphin was an experimental minimal CD similar to Grmbl aimed at semi-professionals and professionals to help repair broken systems or minimize data-loss. Opposites to the official Gentoo-Minimal-CDs it contained more software and also a working gcc (the idea behind that was to provide a quickly available distcc-host by simply bootng any additional machines in a network with the dolphin CD). Hmm.. what about a minimal-media like system which could exploit unionfs and provide similar functionality to DSL (Damn Small Linux)? I came to enjoy the DSL extensibility, yet, as a gentoo user/veteran feel that their packaging system is done, well, not right. If a minimal system provided tools usually expected from Gentoo installation (portage/sandbox), it might be able to merge binary packages outside the core configuration into tmpfs, as well as be able to build new packages to tailor everyone's specific needs. It is well within the spirit of Gentoo, as it will offer the users the ultimate flexibility, and it can be implemented by freezing the portage tree for the release which was used to build the core packages. imagine users just putting binary packages onto "mygentoo/" directory on liveCD/liveUSB, as well as being able to build new packages, limited only in the amount of RAM availiable, as the binaries would be unpacked there. And, equally easily, a user could take the running system and repack new readonly squashfs store from large packages they wish to keep on their media Such specialized livemedia could be useful for advanced users trying to setup gentoo-based multimedia kiosks, demonstrations etc. Tomasz Mloduchowski, MIT Media Lab: Tangible Media Group -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
On Friday 13 October 2006 18:40, Zac Medico wrote: Wow, this thread is pretty huge. Might wanna like.. take it to a council meeting or something in a medium (such as IRC) where message should be going back at forth at this sort of interval. Either that or just duke it out in a parking lot, tickets $50 ringside, $30 midrow, $20 upper level. -- Chris White Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
On Tuesday 17 October 2006 07:30, Luca Barbato wrote: > the IUSE="nocxx" is that different than IUSE="+cxx" ? that is where we want to move to > So it doesn't look to me that problematic, am I missing something? the issue is that Ciaran wants all of the stuff to be in the profile rather than in the ebuild itself -mike pgpjtjTbdbpNB.pgp Description: PGP signature
Re: [gentoo-dev] RFC: per-package default USE flags
Stephen Bennett wrote: On Tue, 17 Oct 2006 09:43:08 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: Placing the default USE flags all in the profiles amounts to profile duplication where-ever you want to use the ebuilds -> this is annoying. This is exactly why we have cascading profiles, no? So that I DON'T need to emerge kde-meta only to find that I needed QT with opengl support. It's a USE dep; it's not as easily representable in a default IUSE format; but it's relatively easy to add opengl to QT's default use in a profile and say "KDE requires qt with openGL support and most of our QT users are KDE users." There exists a qualifier there; that Users exist and provided feedback. So you put opengl in a profile package.use for qt. As soon as you invoke the argument that KDE needs it enabled in Qt, it becomes a repository-level issue, not an ebuild-level one. Er, yes I said that above.. "but it's relatively easy to add opengl to QT's default use in a profile..." Irregardless; Stuart wins ;) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
On 10/17/06, Stephen Bennett <[EMAIL PROTECTED]> wrote: There is no analogy to be made there. Arguing against carrying profile metadata in IUSE is trying to prevent a design decision, not trying to work around one by forcing extra work on people. There seems to be very little support for your position (and Ciaran's) that a package's default USE flags are exclusively profile metadata. The only email I found from anyone else in support of your position was from Danny. My apologies to anyone else who I've missed. The broad concensus of the discussion is that a package's default USE flags (as intended by the package maintainer) belong with the package itself, with profiles being able to override these settings as needed. The different positions appear intractable. I suggest there's no real point carrying on with this discussion. Both the official Portage team, and the external Paludis maintainer, have had plenty of feedback via this thread. I suggest that both teams go forward and implement support how they see fit, and (as always) we leave it up to the external Paludis maintainer to decide whether he wants to make Paludis compatible with Gentoo's official package manager's implemented solution or not. Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
On Tue, 17 Oct 2006 09:43:08 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: > Placing the default USE flags all in the profiles amounts to profile > duplication where-ever you want to use the ebuilds -> this is > annoying. This is exactly why we have cascading profiles, no? > So that I DON'T need to emerge kde-meta only to find that I needed QT > with opengl support. It's a USE dep; it's not as easily > representable in a default IUSE format; but it's relatively easy to > add opengl to QT's default use in a profile and say "KDE requires qt > with openGL support and most of our QT users are KDE users." There > exists a qualifier there; that Users exist and provided feedback. So you put opengl in a profile package.use for qt. As soon as you invoke the argument that KDE needs it enabled in Qt, it becomes a repository-level issue, not an ebuild-level one. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Stephen Bennett wrote: On Tue, 17 Oct 2006 14:23:23 +0200 Sebastian Bergmann <[EMAIL PROTECTED]> wrote: Stephen Bennett wrote: And what the hell does paludis have to do with this anyway? [ ] You get the meaning of "analogy". No, this has nothing to do with "anal". There is no analogy to be made there. Arguing against carrying profile metadata in IUSE is trying to prevent a design decision, not trying to work around one by forcing extra work on people. I don't think anyone is arguing *against* it (at least I'm not!); just that it is not the solution in all cases. Placing the default USE flags all in the profiles amounts to profile duplication where-ever you want to use the ebuilds -> this is annoying. Placing the default USE flags all in the ebuilds (with NO profiles support) means that when I go off and make my own Gentoo; I get to modify thousands of ebuilds to set my defaults properly. Both ways suck. Hence we combine them to get a realistic result. A "naked" ebuild should *just work*; if upstream GCC provides fortran and libstdc++; then the ebuild should provide fortran and libstdc++ *by default* with no profiles. Most other cases are what I would call "distribution tinkering." We (as the primary distributor of our own tree) muck around in our profiles setting certain flags so that stuff works on more systems and in a saner fashion. So that I DON'T need to emerge kde-meta only to find that I needed QT with opengl support. It's a USE dep; it's not as easily representable in a default IUSE format; but it's relatively easy to add opengl to QT's default use in a profile and say "KDE requires qt with openGL support and most of our QT users are KDE users." There exists a qualifier there; that Users exist and provided feedback. -Alec Warner [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
On Tue, 17 Oct 2006 14:23:23 +0200 Sebastian Bergmann <[EMAIL PROTECTED]> wrote: > Stephen Bennett wrote: > > And what the hell does paludis have to do with this anyway? > > [ ] You get the meaning of "analogy". No, this has nothing to do with > "anal". There is no analogy to be made there. Arguing against carrying profile metadata in IUSE is trying to prevent a design decision, not trying to work around one by forcing extra work on people. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
On Tue, 17 Oct 2006 13:07:52 +0100 Stephen Bennett <[EMAIL PROTECTED]> wrote: | On Tue, 17 Oct 2006 13:17:11 +0200 | Paul de Vrieze <[EMAIL PROTECTED]> wrote: | | > That's a nonargument. But let me put it easier. Don't blame us when | > paludis made a design mistake and try to force that mistake on the | > rest of us. Instead fix paludis. | | What design mistake? And what the hell does paludis have to do with | this anyway? Adding either solution to Paludis is trivial. The package manager isn't the issue here; the issue is tree maintainability. I think Paul needs to lay off the crack pipe... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] X.Org 7.1 is Stable
I was running evdev under Xorg 7.0 and 7.1 for my mouse without problems. It works if you use it the way they intend it to use it. Read the man page. Otherwise yea it will crash. I used it under 7.0 fine but when I upgraded to 7.1 it started causing xorg to crash on startup same configuration. I'll try it again, maybe this weekend. I confirmed it was evdev removing it's module from the xorg.conf fixed the issue. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Stephen Bennett wrote: > And what the hell does paludis have to do with this anyway? [ ] You get the meaning of "analogy". No, this has nothing to do with "anal". -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per-package default USE flags
On Tue, 17 Oct 2006 13:17:11 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > That's a nonargument. But let me put it easier. Don't blame us when > paludis made a design mistake and try to force that mistake on the > rest of us. Instead fix paludis. What design mistake? And what the hell does paludis have to do with this anyway? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Ciaran McCreesh wrote: [rants] the IUSE="nocxx" is that different than IUSE="+cxx" ? the per ebuild defaults let you replace the ugly nofoo to +foo, archiving just the same. It is evaluated just only if there isn't anything before it (say make.conf and friends) So it doesn't look to me that problematic, am I missing something? lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Ciaran McCreesh wrote: | It's a stupid statement, not providing any further backing for your | position; please dear god spare us all the waste of time reading | your emails if that's how you're going to push for what you want... Not at all. Your argument could be rephrased like this: There are already lots of people dying in Africa, so it's ok to poison their food supply. That's a nonargument. But let me put it easier. Don't blame us when paludis made a design mistake and try to force that mistake on the rest of us. Instead fix paludis. Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Ciaran McCreesh wrote: On Fri, 13 Oct 2006 20:12:40 +0100 "Stuart Herbert" <[EMAIL PROTECTED]> wrote: | As the default USE flags are metadata about the package (not the | profile), it makes sense to store that data in the ebuild, along with | the rest of the package's metadata. No no on. Default USE flags are a property of the profile. Don't believe me? Go and have a look in an ebuild, and then in a profile. See which one specifies defaults for USE flags. I'm sorry, but Stuart's right. These flags specify what the "recommended" useflag usage is for a particular version of a package. The profile's version is specific to a particular tree, or even architecture. I would indeed argue that a nonempty global package specific use file in the profile is not needed. Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Simon Stelling wrote: Paul de Vrieze wrote: I would go for the EAPI bump. Even then I think it would be smart to wait a short while for packages to use this as we ensure that the supporting portage version is stable. Err, EAPI was designed to assure that a supporting version is actually used, no need to wait then. The waiting time is for a sanity check on the portage that as the new EAPI. One doesn't want to force users to use a portage with bugs and issues just to use newer packages. Paul -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-core] Developer retirement
Jakub Moc <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 16 Oct 2006 23:49:10 +0200: > Ciaran McCreesh napsal(a): >> What's so hard about paying attention when replying? > > What's so hard about making the behaviour consistent? What's so hard about configuring your client to handle it for you, if you don't want to bother with it? If the list doesn't configure it for you, configure your client to do so, and you still won't have to worry about checking each individual reply. kmail among others seems rather rich featured in this regard, as one can set a default reply target based on all sorts of rules (including but not limited to the list headers it would seem you are complaining are missing... of course, I can't check that personally). -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] Developer retirement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jakub Moc wrote: > Harald van Dijk napsal(a): >> It's meant to be used when the user chooses to reply to the list. That >> is not necessarily the function of the "Reply" button. In mutt, and IIRC >> in Thunderbird as well, "reply" is intended to mean "reply to author", >> and there is a separate "reply to list" function which works on >> gentoo-core and gentoo-dev just the same. > > Well, there's no "reply to list" function in Thunderbird [1], and Can be, see https://bugs.gentoo.org/show_bug.cgi?id=151681 - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFNKW1tbrAj05h3oQRArY7AJ4jK0HFmjwmuxSn5vni4e6khkBTbgCfaDSa 9jESMJxKDaWD9FF+9bNPSJ0= =3VIb -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
