Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tue, 20 Jun 2006 16:14:08 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Mike Owen wrote: From this user's perspective, simple is better. qt3 and qt4 as use flags are completely and utterly obvious as to what they mean, and there is no confusion about them. Adding a plain qt flag in there brings back the gtk/gtk2 mess that we've presumably been trying to avoid in the future. That depends on how it's done. If it's done in a simple and obvious way (USE=qt means use the best available qt, USE=qt# for other weird where available means available in the tree for arch, not already installed on build system (just to be clear - correct me if I'm wrong) stuff that most people don't care about and so can ignore), it shouldn't be that bad. So are you suggesting something like: qt - Add support for QT/include QT GUI qt3 - build for version 3 of QT where dependencies might be something like: qt? ( qt3? ( =dev-libs/qt-3.3.6 dev-libs/qt-4 ) !qt3? ( = dev-libs/qt-4.1 ) ) for a package that can build against either qt3 (3.3.6 or higher) or qt4 (4.1 or higher) but not both simultaneously, and perhaps: qt? ( = dev-libs/qt-4.1 qt3? ( =dev-libs/qt-3.3.6 dev-libs/qt-4 ) ) for packages that can build simultaneously for both (is this situation realistic?). We'd need a qt4 to get just the qt3 package in that case: qt? ( qt4? ( = dev-libs/qt-4.1 ) qt3? ( =dev-libs/qt-3.3.6 dev-libs/qt-4 ) ) Am I making sense? This looks a lot like the gtk/gtk2 flags, but inverted; according to use.desc, gtk builds gtk+-1 unless gtk2 is set, whereas the above builds highest version compatible with the package unless a lower version is specifically requested through USE. Ideally we should be consistent in handling this issue (which presumably isn't limited to just gtk and qt), although it may not be worth the disruption to rework gtk/gtk2 into gtk/gtk1. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
Kevin F. Quinn wrote: On Tue, 20 Jun 2006 16:14:08 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Mike Owen wrote: From this user's perspective, simple is better. qt3 and qt4 as use flags are completely and utterly obvious as to what they mean, and there is no confusion about them. Adding a plain qt flag in there brings back the gtk/gtk2 mess that we've presumably been trying to avoid in the future. That depends on how it's done. If it's done in a simple and obvious way (USE=qt means use the best available qt, USE=qt# for other weird where available means available in the tree for arch, not already installed on build system (just to be clear - correct me if I'm wrong) Yes, but it's more than that. Available will vary on a package-by-package basis. Package A may have qt4 and qt3 available, package B only qt4, package C only qt3. USE=qt would use qt4 on A, qt4 on B, qt3 on C. USE=qt3 would only affect A. stuff that most people don't care about and so can ignore), it shouldn't be that bad. So are you suggesting something like: qt - Add support for QT/include QT GUI qt3 - build for version 3 of QT where dependencies might be something like: qt? ( qt3? ( =dev-libs/qt-3.3.6 dev-libs/qt-4 ) !qt3? ( = dev-libs/qt-4.1 ) ) Well, I'm not sure of the best behavior. If they have USE=qt qt3, they're saying they want both the best available qt and qt3. I'd suggest the natural preference would be best available _over_ qt3, in cases where both are available and mutually exclusive. So more like: qt? ( =qt-4* ) !qt? ( qt3? ( =qt-3* ) ) Your inital dep string may not do what you intend, though. Something more like =qt-3* =qt-4* for the two sections for a package that can build against either qt3 (3.3.6 or higher) or qt4 (4.1 or higher) but not both simultaneously, and perhaps: qt? ( = dev-libs/qt-4.1 qt3? ( =dev-libs/qt-3.3.6 dev-libs/qt-4 ) ) for packages that can build simultaneously for both (is this situation realistic?). Yes, e.g. poppler-bindings We'd need a qt4 to get just the qt3 package in that case: qt? ( qt4? ( = dev-libs/qt-4.1 ) qt3? ( =dev-libs/qt-3.3.6 dev-libs/qt-4 ) ) No, this isn't right. The qt flag is only controlling whether the best interface is built, has nothing to do with older interfaces. qt? ( =qt-4* ) qt3? ( =qt-3* ) The goal is to avoid a double-flag combo to do a single thing. qt always and only affects the _best_ available qt interface for that package. qt# affects only _older_ available qt interfaces for that package. Am I making sense? This looks a lot like the gtk/gtk2 flags, but inverted; according to use.desc, gtk builds gtk+-1 unless gtk2 is set, whereas the above builds highest version compatible with the package unless a lower version is specifically requested through USE. Ideally we should be consistent in handling this issue (which presumably isn't limited to just gtk and qt), although it may not be worth the disruption to rework gtk/gtk2 into gtk/gtk1. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
On Wed, 21 Jun 2006, Kevin F. Quinn wrote: Am I making sense? This looks a lot like the gtk/gtk2 flags, but inverted; according to use.desc, gtk builds gtk+-1 unless gtk2 is set, whereas the above builds highest version compatible with the package unless a lower version is specifically requested through USE. That's not what use.desc says gtk does. You just illustrated how confusing the gtk/gtk2 use flag situation has been. The gtk use flag doesn't specify a version. It just says that the package should build against *a* version of gtk+. The gtk2 flag was a way to prefer the gtk2 interface over the gtk1 interface if a package supported both. Thankfully, we've mostly moved past the gtk/gtk2 use flag mess now. Let's try not to make it quite so hard for people with the qt toolkit. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
Caleb Tennis wrote: I would personally like to stay with just the qt use flag. The use flag will be for support of whichever version of Qt is supported (v3 or v4) for the particular emerge. In the cases where more than one version is supported, it should be for Qt4 only. The Qt3 version should be a separate emerge. For example, in the case of the poppler bindings, there should be a poppler-bindings-qt3 package. The problem here is that a user cannot just say at one point I do not want any more qt3 packages on my system. He will need a big /etc/portage/package.use list to do it. That is the same problem I currently have with gtk1 - I would like to avoid it for qt. Considering we only have 36 packages [1] with a qt useflag it will be fairly easy to convert them to a qt3/qt4 version system that makes sense to everyone and allows easy enabling/disabling of only qt3 or qt4. [1] http://gentoo-portage.com/Search?search=use=qt this scheme also allows some people to disable qt4 just with USE=-qt4 and mask it. Any optional qt4 interfaces wont be built then. With only a qt useflag this would require a package.use list again. Can we think about it again? 36 packages is less than half what currently still uses gtk1 in the tree. Doing it right for the users is better than doing it easy for the package maintainers. Thanks, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
середа, 21. червень 2006 03:46, Diego 'Flameeyes' Pettenò Ви написали: On Wednesday 21 June 2006 03:34, Donnie Berkholz wrote: OK, so we can add qt3 to make.defaults. -* says nothing to you? :) Now I am confused: My understanding of that proposal was that qt3 is meant to mean prefer qt3 over qt4, rather than enable qt3 unconditionally and see what can be done about qt4. So which one is that? If it is former (preference flag) I do not see aproblem there: -qt +qt3 = -qt in such reading. So, basically the question is about interpretation of -qt +qt3 construct.. George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tue, 20 Jun 2006 23:25:42 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Kevin F. Quinn wrote: On Tue, 20 Jun 2006 16:14:08 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: [...] Thanks for the clarification The goal is to avoid a double-flag combo to do a single thing. qt always and only affects the _best_ available qt interface for that package. qt# affects only _older_ available qt interfaces for that package. OK; so with this we're not providing a way to get an only qt3 system or only qt4 via USE flags. Perhaps users can do that with local masking, provided ebuilds that can build against both depend on all the relevant versions: qt? || ( =dev-libs/qt-3.3* =dev-libs/qt-4.1* ) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] 2.6.17 kernel stabilisation plan
* Daniel Drake [EMAIL PROTECTED] [06/06/20 18:12 +0100]: I'm hoping to be able to mark 2.6.17 stable on or around July 11th. I'll give around a weeks notice here when that is to happen. Hopefully we'll use this for the 2006.1 release too. Would be great when ppc can profit from that kernel in the 2006.1-release. Especially the bcm43xx driver is very important for our Laptop users. Testing of 2.6.17 is very much appreciated, please also file bugs against problems you have with the kernel itself :) I had problems with genkernel and 2.6.16 on ppc. I need to test and fix the build of the initramfs. Regards, Lars -- Lars Weiler [EMAIL PROTECTED] +49-171-1963258 Gentoo Linux PowerPC: Strategical Lead and Release Engineer Gentoo Infrastructure : CVS Administrator Gentoo Foundation : Trustee pgpWnHH72CBIS.pgp Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
On Wednesday 21 June 2006 10:58, Kevin F. Quinn wrote: ok; so in gtk-land we have gtk2 to prefer the newer interface whereas the proposal for qt/qt3 is to have a specific flag for the older interface. I do prefer the qt/qt3 approach, even though it's inconsistent with what happens on gtk. I don't suppose changing gtk/gtk2 to gtk/gtk1 would be popular... Please don't talk about interface, Qt is way more than interface as I said, so talking about frontends and interface is misleading. If it was just interface, of course it would be possible to choose the best between Qt4 and Qt3, but this is not an interface problem, it's a bindings problem. As I said, enabling just one between qt3 and qt4 in bindings would be like just having one of pbindings useflag, and every ebuild decides if it will provide python or perl bindings, just because they happen to start with 'P'. Qt3 and Qt4 are different enough to be considered different languages from some POVs, it does not make sense to treat Qt the exact same way of GTK, because it's not only a GUI thing. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp8jAcxCqUux.pgp Description: PGP signature
Re: [gentoo-dev] 2.6.17 kernel stabilisation plan
On Wed, 2006-06-21 at 12:25 +0200, Lars Weiler wrote: * Daniel Drake [EMAIL PROTECTED] [06/06/20 18:12 +0100]: I'm hoping to be able to mark 2.6.17 stable on or around July 11th. I'll give around a weeks notice here when that is to happen. Hopefully we'll use this for the 2006.1 release too. Would be great when ppc can profit from that kernel in the 2006.1-release. Especially the bcm43xx driver is very important for our Laptop users. Start testing 2.6.17 in your builds now, then. Testing of 2.6.17 is very much appreciated, please also file bugs against problems you have with the kernel itself :) I had problems with genkernel and 2.6.16 on ppc. I need to test and fix the build of the initramfs. Umm... Come hang out in #gentoo-releng again and you'll see that we have a (masked) genkernel in the tree that solves all of these headaches. I know, because I've been building on ppc for the past few weeks making sure all of this worked so you wouldn't have trouble once we started the release. Unless you mean Pegasos, which is busted on 2.6.16, genkernel or not, and I've spoken with JoseJX about that one already and he's aware of it. I need to get back with him to see if he (or anyone else) has come up with anything. -- 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] [RFC] Useflags: qt, qt3, qt4?
On Tuesday 20 June 2006 12:40, Stefan Schweizer wrote: Hi, with kde4 approaching and the new Qt-4 being in the tree we suddenly see the same problems that gtk had with the gtk2 flag again. I think there's a lot of good thoughts surrounding how to handle this. There are 2 categories of packages we need to concern ourselves with: 1) A package can optionally add support for Qt3 or Qt4 (such as dbus). Solution: The qt flag represents the latest qt major version for the package. The maintainer can either put in another flag for the older version (qt3?) or provide a separate package (e.g. dbus-qt3 ). 2) A package requires either Qt3 or Qt4 (both not both?...such as x11-libs/qwt-5). Solution: Build against qt4. If you want to provide the same package for the qt3 version, add a new package to portage I suppose. In the end, this is just merely suggestion. I think each maintainer should come up with the best way to handle the situation unless someone is going to GLEP this. I think we should, however, do our best to avoid a situation where we have some ugly combination of USE=qt -qt3 or USE=qt4 -qt qt3... -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
Caleb Tennis wrote: On Tuesday 20 June 2006 12:40, Stefan Schweizer wrote: Hi, with kde4 approaching and the new Qt-4 being in the tree we suddenly see the same problems that gtk had with the gtk2 flag again. I think there's a lot of good thoughts surrounding how to handle this. There are 2 categories of packages we need to concern ourselves with: 1) A package can optionally add support for Qt3 or Qt4 (such as dbus). qt3 and qt4 is being used there already and it is obvious 2) A package requires either Qt3 or Qt4 (both not both?...such as x11-libs/qwt-5). qt3 - enable optional qt3 support qt4 - enable optional qt4 support when both are possible its the maintainers decision, would look something like this: qt4? ( =x11-libs/qt-4* ) !qt4? ( qt3? ( =x11-libs/qt-3* ) Why you ask? Because a user does not care if packageX uses qt3 or qt4, he just wants to use it. But why do we have two useflags then? Because the user should be able to disable optional support for either qt3 or qt4 or both for every package. Disabling all optional qt4 support is only conveniently possible with a qt4 flag. Same for qt3. We need separate flags here, otherwise you can just use one flag for everything, it does not make sense to have two flags when one cannot be used because the other is ambiguous. Solution: Build against qt4. If you want to provide the same package for the qt3 version, add a new package to portage I suppose. This add a new package to portage is not really the gentoo spirit of following upstream tarballing, in my opinion. In the end, this is just merely suggestion. I think each maintainer should come up with the best way to handle the situation unless someone is going to GLEP this. We have 36 qt-use-packages, so we could have 36 different flags in the end ;) Trying to reach a consensus on the mailing list is a better idea imo. I think we should, however, do our best to avoid a situation where we have some ugly combination of USE=qt -qt3 or USE=qt4 -qt qt3... right you are. And since we already have a qt3 and a qt4 useflag in the tree it is a good move to do this right. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
George Shapovalov wrote: середа, 21. червень 2006 03:46, Diego 'Flameeyes' Pettenò Ви написали: On Wednesday 21 June 2006 03:34, Donnie Berkholz wrote: OK, so we can add qt3 to make.defaults. -* says nothing to you? :) Now I am confused: My understanding of that proposal was that qt3 is meant to mean prefer qt3 over qt4, rather than enable qt3 unconditionally and see what can be done about qt4. So which one is that? If it is former (preference flag) I do not see aproblem there: -qt +qt3 = -qt in such reading. So, basically the question is about interpretation of -qt +qt3 construct.. -qt +qt3: This would only be available in 2 cases: - Package supports both qt4 and qt3, and they're mutually exclusive - Package supports both qt4 and qt3, and they can both be enabled at once In case 1, -qt +qt3 would enable qt3. In case 2, -qt +qt3 would enable qt3. In other words, as I've been trying to say all along, there is no such thing as a preference flag here. That creates a 2-flag combination to get a single feature, which is _not_ what we want. There is a qt flag to indicate enabling the best available qt for that package, and there are qt# flags to indicate enabling older qt for that package. The downside to this setup is that it's difficult to avoid installing certain qt versions when it's unknown which version USE=qt will pull in for any given package. This favors an entirely versioned setup instead, and we should get rid of USE=qt altogether in favor of only USE=qt#. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
Kevin F. Quinn wrote: The goal is to avoid a double-flag combo to do a single thing. qt always and only affects the _best_ available qt interface for that package. qt# affects only _older_ available qt interfaces for that package. OK; so with this we're not providing a way to get an only qt3 system or only qt4 via USE flags. Perhaps users can do that with local masking, provided ebuilds that can build against both depend on all the relevant versions: qt? || ( =dev-libs/qt-3.3* =dev-libs/qt-4.1* ) Yes, I just mentioned elsewhere in the thread that this is a downside of this design. Another possibility is getting rid of USE=qt and having only USE=qt#. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Wednesday 21 June 2006 15:21, Caleb Tennis wrote: Solution: The qt flag represents the latest qt major version for the package. The maintainer can either put in another flag for the older version (qt3?) or provide a separate package (e.g. dbus-qt3 ). Although I can see why you suggest this (Qt 4 is what should become mainline asap), right now I think it's going to be a bit of a mess for KDE users, Remember we don't have use-deps and that splitting packages is something that, if done without upstream support, can give very bad headaches (we both know how KDE split is right now). Also, this puts us back again in gtk's system, with different meaning for the same flag (qt can then either be for Qt3 or Qt4, no clear distinction), that might even change on maintainer's decision, becoming a mess to handle in dependent packages. Why you think it's better this way rather than having one meaning every useflag? Another thing that this setup is going to make incredibly difficult to manage is use.mask masking on profiles. If for some reasons Qt3 or Qt4 needs to be masked on a profile, even temporarily, by having qt mean one or the other depending on the package is going to be a mess as we don't have per-package use.mask (and we won't have till portage 2.2 gets the main scene). This is another of the main reasons I don't think it's a good idea to overload useflags with different (albeit slightly) meanings. I agree on the other part tho, pushing Qt4 is indeed a good idea, although it might mess up the lookfeel of a desktop, but that is marginally important. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpUEQgyAF1ov.pgp Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
Stefan Schweizer wrote: Why you ask? Because a user does not care if packageX uses qt3 or qt4, he just wants to use it. But why do we have two useflags then? Because the user should be able to disable optional support for either qt3 or qt4 or both for every package. There's a significant enough use case for wanting only qt3 or only qt4 on your system that it might be worth considering it. I think we should, however, do our best to avoid a situation where we have some ugly combination of USE=qt -qt3 or USE=qt4 -qt qt3... right you are. And since we already have a qt3 and a qt4 useflag in the tree it is a good move to do this right. Agreed on this. So right now, we've got a couple of options. - Use case is user wants program with its best qt. USE=qt is an easy option. The other option is USE=qt3 qt4, and apps should always pick the best of the enabled qt versions if they are mutually exclusive. - Use case is avoiding installing either qt3 or qt4. Impossible with USE=qt, possible with USE=qt3/qt4. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
Caleb Tennis wrote: qt3 - enable optional qt3 support qt4 - enable optional qt4 support Maybe I just need a little time to warm up to this. :) Caleb -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites: net-wireless/bluez-kernel
Hi, The net-wireless/bluez-kernel package is no longer supported by upstream and the current release (from Nov 2002) doesn't build with recent kernels (bug #132600). The replacement for this package is the in-kernel bluetooth drivers. If nobody objects I'll package.mask net-wireless/bluez-kernel in 7 days, pending removal 30 days later. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpvWzRZnvRsZ.pgp Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
On Wednesday 21 June 2006 15:44, Stefan Schweizer wrote: qt3 and qt4 is being used there already and it is obvious It's nice to invent new use flags affecting Qt stuff without contacting those who care for Qt. 2) A package requires either Qt3 or Qt4 (both not both?...such as x11-libs/qwt-5). qt3 - enable optional qt3 support qt4 - enable optional qt4 support That will be a mess to support in the long run. Let's go with that what works better, prefer the latest version and be fine with it. I do agree with Caleb to use the qt use flag for the latest supported version and in cases it is really necessary to have an additional qt3 use flag. Carsten pgpK1ne4gh5sC.pgp Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
On Wed, Jun 21, 2006 at 05:20:47PM +0200, Carsten Lohrke wrote: On Wednesday 21 June 2006 15:44, Stefan Schweizer wrote: qt3 - enable optional qt3 support qt4 - enable optional qt4 support That will be a mess to support in the long run. Why? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2.6.17 kernel stabilisation plan
* Chris Gianelloni [EMAIL PROTECTED] [06/06/21 08:55 -0400]: Start testing 2.6.17 in your builds now, then. I already do. Umm... Come hang out in #gentoo-releng again and you'll see that we have a (masked) genkernel in the tree that solves all of these headaches. Sorry, I had some network-troubles during the last days and no time for IRC as well. But now I'm back with a different setup. Should work. I know, because I've been building on ppc for the past few weeks making sure all of this worked so you wouldn't have trouble once we started the release. Unless you mean Pegasos, which is busted on 2.6.16, genkernel or not, and I've spoken with JoseJX about that one already and he's aware of it. I need to get back with him to see if he (or anyone else) has come up with anything. The Pegasos is the only working PPC-machine I currently own (beside the RS/6000 wherefore I first need to build some install-media). I will also look into the issue. Regards, Lars -- Lars Weiler [EMAIL PROTECTED] +49-171-1963258 Gentoo Linux PowerPC: Strategical Lead and Release Engineer Gentoo Infrastructure : CVS Administrator Gentoo Foundation : Trustee pgpsLEjOZ8Mw2.pgp Description: PGP signature
Re: [gentoo-dev] 2.6.17 kernel stabilisation plan
On Wed, 2006-06-21 at 19:30 +0200, Lars Weiler wrote: I know, because I've been building on ppc for the past few weeks making sure all of this worked so you wouldn't have trouble once we started the release. Unless you mean Pegasos, which is busted on 2.6.16, genkernel or not, and I've spoken with JoseJX about that one already and he's aware of it. I need to get back with him to see if he (or anyone else) has come up with anything. The Pegasos is the only working PPC-machine I currently own (beside the RS/6000 wherefore I first need to build some install-media). I will also look into the issue. Yeah, 2.6.16 works fine on the Macs, using the older kernel configs, but the Pegasos doesn't. Just making sure you're aware. -- 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: Re: [RFC] Useflags: qt, qt3, qt4?
On Wed, 21 Jun 2006, Carsten Lohrke wrote: On Wednesday 21 June 2006 15:44, Stefan Schweizer wrote: qt3 and qt4 is being used there already and it is obvious It's nice to invent new use flags affecting Qt stuff without contacting those who care for Qt. 2) A package requires either Qt3 or Qt4 (both not both?...such as x11-libs/qwt-5). qt3 - enable optional qt3 support qt4 - enable optional qt4 support That will be a mess to support in the long run. Let's go with that what works better, prefer the latest version and be fine with it. I do agree with Caleb to use the qt use flag for the latest supported version and in cases it is really necessary to have an additional qt3 use flag. Sounds like: qt - GLOBAL use flag that causes the package to build against the good version for that package. qt3, qt4... - LOCAL use flags to build against specific versions of qt when it makes sense on a per-package basis and when it's deemed to be reasonable by the package maintainer. Easy to keep track of because they'd all be in use.local.desc. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: [RFC] Useflags: qt, qt3, qt4?
qt - GLOBAL use flag that causes the package to build against the good version for that package. qt3, qt4... - LOCAL use flags to build against specific versions of qt when it makes sense on a per-package basis and when it's deemed to be reasonable by the package maintainer. Easy to keep track of because they'd all be in use.local.desc. This is exactly what I recommend. It requires no end user changes to make it work. The only downside to this is that using qt isn't explicit in which version it pulls in. To that, I say: who cares? That only seemingly becomes valid when someone wants to rid their system of a specific version of Qt, which if they're advanced enough to think they need to do that they can probably hack around enough to figure out that packages depend on the version of Qt they want to nuke. I seriously doubt there will ever be many packages that support both at the same time. For those, we'll handle them in the best way we can at the time, be it a qt3 flag, a separate package instance, or other. Moreso, people will release new packages of existing products that use Qt4 instead of Qt3. This is where it gets interesting: if somelibrary-3.0 depends on Qt3 and somelibrary-4.0 depends on Qt4, do we slot them so they can both be installed at the same time? Seems reasonable to do so, but you run into the issue of how to handle version dependencies across slots of the same package...something portage doesn't do very gracefully at the moment. Oh, the joys. :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tue, Jun 20, 2006 at 02:22:21PM -0700, Donnie Berkholz wrote: That makes for highly irreproduceable builds and particularly screws with building packages on one machine and expecting them to work on another. Same as autodetecting in configure scripts, except worse because now we're doing it too. Oops, didn't think of that. I've fixed this in the newly added net-wireless/wpa_supplicant-0.5.4 ebuild, thanks. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgp9otDnjVXHu.pgp Description: PGP signature
[gentoo-dev] GLEP ?? - Gentoo Knowledge Base
Hi folks I've just sent the GLEP to the GLEP editors so they can give it a nice number, but you'll find the text at http://dev.gentoo.org/~swift/tmp/kbase-glep.html as well. The GLEP covers the requirements I'd like to put on the Knowledge Base (KB). I didn't get much response on it on the gentoo-kbase mailinglist though, hopefully because everybody agrees (instead of laughing at it behind my back ;-) so I now present it to a larger community. I've also mailed the gentoo-kbase mailinglist with the next steps to complete: define an XML format for the KB topics (which is an *intermediate* format - definitely not the final one) and after that start creating lots of topics in that format. This is necessary because, if we want a good KB, we need to be able to test it well, so we need content. At the same time, we should start looking for possible existing technologies that we can use for the KB (we're all lazy). Each time a good candidate is found, we can put the topics in it and test it. For more discussion on this, please use the gentoo-kbase mailinglist. Wkr, Sven Vermeulen PS I've tried to get it on the gmane lists but apparently failed. I'll retry. -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Council Member The Gentoo Projecthttp://www.gentoo.org pgpoiRKiWc1oW.pgp Description: PGP signature
[gentoo-dev] Re: Re: [RFC] Useflags: qt, qt3, qt4?
Caleb Tennis [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 21 Jun 2006 10:03:21 -0400: [Stefan Schweizer wrote...] qt3 - enable optional qt3 support qt4 - enable optional qt4 support Maybe I just need a little time to warm up to this. :) This seems simplest here, too. Deprecate USE=qt. With only 36 packages in the tree using it, it shouldn't be difficult. qt3 for qt3 qt4 for qt4 Thus, if either one is possible, no problem. If both are possible without conflict, no problem. The problems then come if one is required and USE=-qt3 -qt4, or in the exclusive-or situation of USE=qt3 qt4 or USE=-qt3 -qt4, but only one can be supported at once. In both cases, defaulting to the later one (4 at this point) will be the most future proof. make.defaults could include qt3 ATM, which would solve the current KDE support problem for many. There may be a few cases where defaulting to the later one in exclusive support situations may be problematic, and those should be resolved by the package maintainer as they would be on an individual case by case basis just as they would be for any other USE flag conflicts. In some rare cases, a die with a message directing the user to resolve the conflict manually may be necessary, just as can very occasionally be necessary in other situations. In most cases, however, an einfo explaining the situation should be sufficient, just as it normally is with any other USE flag conflicts. This should be the clearest from a user perspective, and should require the minimal amount of package.use magic, yet it remains an option where a user finds it necessary. There will be a bit of disruption when KDE4 ultimately stabilizes, but handled correctly, it shouldn't be any more of a problem than any major version upgrade on a major desktop environment would be -- that is, while some problems should be expected (and well published in GWN and the like before stabilization), they should be resolvable, and temporary. -- 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: Re: [RFC] Useflags: qt, qt3, qt4?
On 6/21/06, Duncan [EMAIL PROTECTED] wrote: Caleb Tennis [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 21 Jun 2006 10:03:21 -0400: [Stefan Schweizer wrote...] qt3 - enable optional qt3 support qt4 - enable optional qt4 support Maybe I just need a little time to warm up to this. :) [snip] This should be the clearest from a user perspective, and should require the minimal amount of package.use magic, yet it remains an option where a user finds it necessary. There will be a bit of disruption when KDE4 ultimately stabilizes, but handled correctly, it shouldn't be any more of a problem than any major version upgrade on a major desktop environment would be -- that is, while some problems should be expected (and well published in GWN and the like before stabilization), they should be resolvable, and temporary. When do you propose qt4 hits make.defaults? When kde4 hits p.mask, when it hits ~arch, or when it hits arch? I think mr_bones__ idea was the most appropriate thus far. -- 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 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [Last Rites: app-admin/scotty]
Scotty has been pmasked due to sandbox violations[1]. I spent about 30 minutes looking at them and solving them is not as simple as I'd first hoped, I asked trelane to double check my logic and he came to a similar conclusion. As such with no maintainer or herd this package is scheduled for removal in 30 days and has been pmasked. If you have any questions please contact the treecleaner[2] project or comment on the bug[1] Thanks, Alec [1] http://bugs.gentoo.org/show_bug.cgi?id=77501 [2] [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [Last Rites: app-admin/scotty]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What no! not scotty. Who's going to beam us all up now and repair the ship in half the time that he says it'll take! Alec Warner wrote: Scotty has been pmasked due to sandbox violations[1]. I spent about 30 minutes looking at them and solving them is not as simple as I'd first hoped, I asked trelane to double check my logic and he came to a similar conclusion. As such with no maintainer or herd this package is scheduled for removal in 30 days and has been pmasked. If you have any questions please contact the treecleaner[2] project or comment on the bug[1] Thanks, Alec [1] http://bugs.gentoo.org/show_bug.cgi?id=77501 [2] [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEmhZ9SENan+PfizARAj6RAJ9RvcK5h7IoKWEDSrEtSr9qKqRE5gCeM02j MQ+D+yzpZ7fxGcVNHmqeN/I= =CLfi -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [Last Rites: app-admin/scotty]
Joshua Jackson wrote: What no! not scotty. Who's going to beam us all up now and repair the ship in half the time that he says it'll take! vapier? Alec Warner wrote: Scotty has been pmasked due to sandbox violations[1]. I spent about 30 minutes looking at them and solving them is not as simple as I'd first hoped, I asked trelane to double check my logic and he came to a similar conclusion. As such with no maintainer or herd this package is scheduled for removal in 30 days and has been pmasked. If you have any questions please contact the treecleaner[2] project or comment on the bug[1] Thanks, Alec [1] http://bugs.gentoo.org/show_bug.cgi?id=77501 [2] [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [Last Rites media-tv/zapping]
media-tv/zapping needs a revbump[1], needs a version that compiles and works, and is currently unmaintained. I have masked it for removal in 30 days. [1] http://bugs.gentoo.org/show_bug.cgi?id=27515 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] VNC packages need your help [pre-emptive last rites]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Specifically net-misc/vnc and net-misc/xf4vnc have 6 and 5 bugs open respectively. These packages need help, I'm sure there are many users and developers who are interested in vnc. The current maintainer is aliz. Part of this mail is trying to convince him to come back and retake his dev quizzes ;) The other part of this mail is to find a new maintainer for these; I don't want to punt them but I will do so if I can't find anyone to fix[1] all[2] of[3] these[4] damn[5] bugs[6]. Oh and here[7] are[8] a[9] few[10] more[11]. [1] http://bugs.gentoo.org/show_bug.cgi?id=64147 [2] http://bugs.gentoo.org/show_bug.cgi?id=68434 [3] http://bugs.gentoo.org/show_bug.cgi?id=77376 [4] http://bugs.gentoo.org/show_bug.cgi?id=81135 [5] http://bugs.gentoo.org/show_bug.cgi?id=86520 [6] http://bugs.gentoo.org/show_bug.cgi?id=91333 [7] http://bugs.gentoo.org/show_bug.cgi?id=106724 [8] http://bugs.gentoo.org/show_bug.cgi?id=125164 [9] http://bugs.gentoo.org/show_bug.cgi?id=133554 [10] http://bugs.gentoo.org/show_bug.cgi?id=133556 [11] http://bugs.gentoo.org/show_bug.cgi?id=136522 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRJoibmzglR5RwbyYAQI3+Q/+P2uD4ez4EEfJOO/eVjoulZqeE5+SO/ZJ zhoAjQa9iwStmqnB/a09hMAFmQCW+n1rCnpNZm/2x5NEF2LD1wVyRXZXcGSfgPNR IfvTsMKAslvb3+VExw2QnFKDCwdKVP9PVHeCQejH2c6lKMTlTh9JxFZckDjaUfF9 tLjoHUtYcVJqIOM2jvYg4Ia3SEdlQib9djP9GChBmFe8FGOmjU3RBSHGySoheRgQ ILN+/M3phKR48SwV1kUZ4APvqcD6gC/05HxxHPMXZGwr3/5PPO77lr00dRjzkNRO TtaClLxdozlFI9mdOjO7eWVXHQIpIGZq/Ri6FvinfVupR4j+cZVsalNPutExBTqY UPJC3Gg5CzOGhDtayp4/Gu3z4SfVSpa602BY/72r6L3KrsLndT0AnBWhHj9wtMwT IFifEmr7JRMNtkErz2RcSqapSiFzH2CoZ+jxoiASdYA0MsZPvipZ8pULnUbrO8ek bNx+Bqcyo2DWphDLVU0g48MFOVugOURkjvrk3zgOPvxV7mYI/I0IDR2zyZjIz6K9 cKjkXx/Rliw5Y1kAo78VDXuqsveGpJ/r59nK/qzNibhFJ9RUIPrnM6c02Za4mVuh Rl8prj9K1Fz198+KsZx21urLpumRWnmpOActQ22QahXOhIFWTTwsCPbd8NCRWbLA W+xLUEk511I= =Uodf -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [Last Rites: net-misc/freenet6]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This packages has no metadata.xml, no herd, and no maintainer. It has many open bugs[1][2][3][4][5] It will be pmasked and then sent out of the tree after 30 days. [1] http://bugs.gentoo.org/show_bug.cgi?id=32779 [2] http://bugs.gentoo.org/show_bug.cgi?id=63710 [3] http://bugs.gentoo.org/show_bug.cgi?id=94283 [4] http://bugs.gentoo.org/show_bug.cgi?id=102497 [5] http://bugs.gentoo.org/show_bug.cgi?id=118942 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRJop+mzglR5RwbyYAQJfcQ/6A4jbhQuShNj0lqzagoOCN0ySerG4QfvA AiOyUlM0x63aYKnJvMrfREZGbtwdgbzUdvcmYFCdno5Hez4Hjx0YNBmBbhrXUNIl M7aMideEqB3+REvA0CK023PLUuD8uFHjsZnXjIB9gjjRsp6TuO0SwJBXd6PB2pob 4I5whknHWL2Srm0SXbBXwNxWOGSXMQ+mcF/3H1gRA3jaF2npXLqyTXmRLQVeKf5d m3WCsoG3amatXDEt4VkSOUIpFHKrp9bfpcyvVbwRoZ0XJoP5M22KHmGctBqt2ArS BOevRnNUOrc0ztQ0/cVxe42+OjwPiSuHU9wcZKbhMAZpblCctvzs0pAHnU+OATdu Rbk8WjJY89TWXhaxnMTukMYn0rHX+leDiewb3fb1QQ0ppqdrkp+v4UStFM8bra4b L+ETThO4W80BhHGk+LbLW/1BomJCFTVDp1NSUyKqof/AgzBZI+R8WVsHu6tvFuv3 r8YPJ5HRG+LWsTQEOj4rJYUw7kys6GdK2Mqb788jvU0b0CcnvQ0sCGB0CZFZKEmN psxvqT7PnRdU8OUKm9p9kDHNJufGXYQJuw626+u1BO2CQG+86KlhiY69GF61q3cQ ehNnQEZpVssoKW3UbdkDMTpBBN8tyUQ95BD/74TccFB5K/8tKmQGe/3JNVJ57YUd +PZ+0ukYeeg= =Vm1a -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [Last Rites: net-misc/freenet6]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: This packages has no metadata.xml, no herd, and no maintainer. It has many open bugs[1][2][3][4][5] It will be pmasked and then sent out of the tree after 30 days. [1] http://bugs.gentoo.org/show_bug.cgi?id=32779 [2] http://bugs.gentoo.org/show_bug.cgi?id=63710 [3] http://bugs.gentoo.org/show_bug.cgi?id=94283 [4] http://bugs.gentoo.org/show_bug.cgi?id=102497 [4] http://bugs.gentoo.org/show_bug.cgi?id=102947 [5] http://bugs.gentoo.org/show_bug.cgi?id=118942 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRJorImzglR5RwbyYAQKr4Q//WqvB0Vmttq4QsxsnFSJBJs6mJdfyIByU HzS7UHPkpBpYDwkBx7eSBxoAIz/imT3nqpT/v4niZsgZ8H2cXavfrnvQqXwvluCX HZPFOcHO6sQmwo41p1Y2karEoLRMgR4JLXe1MwU6gr+kDC+LqPEni6KGONEYEsRH Nq2hDiidG9kUPwpdsKOYoqRvg4rwO4ikn6mjR3VjAlbiwFKNmAcmEFrJrL/1lwp/ 9Q66ZkSaEQXt65IVJhLRyeJbt747Ru2NKP1XnlhHQQpFKL/Uo8EjQZyDrL6RHW00 f7Y3+3QnjpItKwrsLkXytYhr0g3pza9gVmcvgW0rEDs9/Yoin23AtQaT6KZS3VjJ ZnmPrpmN+Rvqa14zrLk631FNoK4CQJO8IC0pX+c1yQC7fEGc2Spe1lxwW5oWNJnk vZjLtjbHIOjMptLajzaikyZU7rDZ0/Lq9qTSGaD7PV1+4Zfeetx7W1EgADMuFKbT Vofsbx7C1lhjoBIV0j4H2YzEgA0HZBEXnBpFpuZcgh7WAdvnO4pJBitA4prYxukp nNhurHZh7eRZjPp0Xr2pewCRn+N30T8bFAM36ertLdZI5QwduJs5+Pr9EPwBAz3Z 7brp3iHoxs2BRiW+x4O748DEVAdCK7U4RWQclZyr3/RAyaEFGhTpsep+pZRu69hf hLPGcvg97yQ= =sPdy -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] VNC packages need your help [pre-emptive last rites]
On Thursday 22 June 2006 00:54, Alec Warner wrote: Specifically net-misc/vnc i'll fix this up if no one else does since it is a pretty friggin critical package for too many people (myself included), but i'd really really prefer someone else to do it -mike pgpR2wJD0OtiQ.pgp Description: PGP signature
