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
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
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
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
середа, 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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
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,
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
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
-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
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
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
-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
-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]
-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]
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
35 matches
Mail list logo
