Mike Frysinger wrote:
> 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
Not really
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 s
-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]
-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.
-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 convi
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
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
-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
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 remova
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
"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 simples
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 gento
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
> 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
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
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
* 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 networ
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
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-lib
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
> 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
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 signific
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 th
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 g
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 qt
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.
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 pa
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
> > th
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.
* 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 k
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.
On Wed, 21 Jun 2006 02:39:29 -0400 (EDT)
"Michael Sterrett -Mr. Bones.-" <[EMAIL PROTECTED]> wrote:
> 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, w
George Shapovalov wrote:
> ??, 21. ??? 2006 03:46, Diego 'Flameeyes' Petteno` ?? :
>> 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 q
середа, 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
o
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 ve
35 matches
Mail list logo
