[gentoo-dev] Looking for jack maintainers

2005-12-08 Thread Diego 'Flameeyes' Pettenò
Seems like the jack support in sound team started to be unavailable lately, 
kito is full of other tasks and he's the only one, as far as I can see, who's 
taking are of Jack.

As I have no idea where to start looking for it, nor I have time to spend on 
it, unfortunately, so I can't take care of them. Is some other dev (possibly) 
wanting to take care of that as a main task? :)

-- 
Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpefc1s1XREc.pgp
Description: PGP signature


Re: [gentoo-dev] Looking for DirectFB maintainers

2005-12-08 Thread Chris Gianelloni
On Thu, 2005-12-08 at 14:19 +0100, Diego 'Flameeyes' Pettenò wrote:
 Another series of packages that lies around, this time for media-video team. 
 DirectFB requires some new maintainers to take care of it and its 
 applications. I'm not using it and seems like nobody else on the team is 
 taking care of it, so if someone uses it, it would be good if it stepped 
 up...

Umm...

wolf31o2-work !meta DirectFB
jeeves wolf31o2-work: Package: dev-libs/DirectFB  Herd: games
Maintainer: [EMAIL PROTECTED]

What are you talking about?

-- 
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] Looking for DirectFB maintainers

2005-12-08 Thread Mike Frysinger
On Thu, Dec 08, 2005 at 09:10:28AM -0500, Chris Gianelloni wrote:
 On Thu, 2005-12-08 at 14:19 +0100, Diego 'Flameeyes' Petten?? wrote:
  Another series of packages that lies around, this time for media-video 
  team. 
  DirectFB requires some new maintainers to take care of it and its 
  applications. I'm not using it and seems like nobody else on the team is 
  taking care of it, so if someone uses it, it would be good if it stepped 
  up...
 
 Umm...
 
 wolf31o2-work !meta DirectFB
 jeeves wolf31o2-work: Package: dev-libs/DirectFB  Herd: games
 Maintainer: [EMAIL PROTECTED]
 
 What are you talking about?

yeah, you better not start pawning off my packages or i'll KLL you
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Looking for DirectFB maintainers

2005-12-08 Thread Diego 'Flameeyes' Pettenò
On Thursday 08 December 2005 15:10, Chris Gianelloni wrote:
 What are you talking about?
DFBsee and at least another package is assigned to media-video, and seeing the 
recent assignments, I've supposed the wrong metadata , sorry ^^;

-- 
Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpCAHS4Su2G9.pgp
Description: PGP signature


[gentoo-dev] Last rites for media-video/dvdrip

2005-12-08 Thread Diego 'Flameeyes' Pettenò
Another package is taking a long long way that goes out of portage.
I'm running out of openings for these mails, you know?

Oh well, media-video/dvdrip has many issues reported in bugzilla (some have 
patches, most haven't), and depends on a version of transcode with many 
issues, too (and force us to leave transcode 1 masked).
Nobody in video herd is looking at it right now, last bump was done by morfic, 
and more would be needed.

Alternative dvd-ripping software is present in portage, starting from mencoder 
and its frontends, and they usually works better (look at winki for example).

For this reason, I'm package.masking dvdrip and pending removal 2 weeks from 
now.

-- 
Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpRHBBYB6dla.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites for media-video/dvdrip

2005-12-08 Thread Benoit Boissinot
On 12/8/05, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:
 Another package is taking a long long way that goes out of portage.
 I'm running out of openings for these mails, you know?

 Oh well, media-video/dvdrip has many issues reported in bugzilla (some have
 patches, most haven't), and depends on a version of transcode with many
 issues, too (and force us to leave transcode 1 masked).

Last time i tried, dvdrip worked with transcode 1 (at least the
unstable version of dvdrip),
furthermore there are only 9 bugs against the package:
- 2 are version bumps request
- if you remove the version bump and a dependency fix, there are no
bugs against the latest version (in ~arch)

Moreover the package is still maintained upstream (last release 30
october 2005).

So please consider keeping dvdrip in portage.

 Nobody in video herd is looking at it right now, last bump was done by morfic,
 and more would be needed.

 Alternative dvd-ripping software is present in portage, starting from mencoder
 and its frontends, and they usually works better (look at winki for example).

AFAIK there are no other frontend to dvdrip.

thanks,

Benoit Boissinot

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites for media-video/dvdrip

2005-12-08 Thread Chris Bainbridge
On 08/12/05, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:
 Another package is taking a long long way that goes out of portage.
 I'm running out of openings for these mails, you know?

 Alternative dvd-ripping software is present in portage, starting from mencoder
 and its frontends, and they usually works better (look at winki for example).

Er, isn't dvdrip the most popular ripping software on Linux? I haven't
even heard of winki.. stable version is only 0.3.2 and it's described
on it's homepage as alpha software. It seems a bit premature to remove
dvdrip.

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites for media-video/dvdrip

2005-12-08 Thread Diego 'Flameeyes' Pettenò
On Thursday 08 December 2005 19:12, Chris Bainbridge wrote:
 Er, isn't dvdrip the most popular ripping software on Linux?
Popular, maybe, but there're enough bug to make it a difficult task to 
maintain.
Current versions are tested only on transcode 0.6 (I'm sure that at least the 
versions that upstream consider stable does not run with transcode 1.0) and 
it has to inherit also all the bugs of transcode 0.6 then.
Currently there's no one in Video team that seems to be taking care of dvdrip 
so the bugs will continue stratification on bugzilla.

If a new maintainer is found, fine, it can remain, but currently the resources 
of Video team are limited and we have enough problems to take care of without 
dvdrip.

The new maintainer would anyway have to take care of transcode, too, or at 
least make sure that dvdrip in portage can work with transcode 1.x as that 
has lots less problems than the old 0.6 one.

-- 
Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpkw94AT2mag.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites for media-video/dvdrip

2005-12-08 Thread Mike Frysinger
On Thu, Dec 08, 2005 at 08:46:31PM +0100, Diego 'Flameeyes' Petten? wrote:
 If a new maintainer is found, fine, it can remain, but currently the 
 resources 
 of Video team are limited and we have enough problems to take care of without 
 dvdrip.

so the video herd policy is to remove packages until you're left with
a small enough subset of packages you can handle ?
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites for media-video/dvdrip

2005-12-08 Thread Diego 'Flameeyes' Pettenò
On Thursday 08 December 2005 21:10, Mike Frysinger wrote:
 so the video herd policy is to remove packages until you're left with
 a small enough subset of packages you can handle ?
No, it's to remove the packages that have problems, that requires dependencies 
that are badly broken (transcode 0.6 is a pain to manage, does not work with 
GCC4 and it's not easily fixable, and upstream moved to transcode 1), that 
requires maintenance and nobody can give it, and that might be replaced by 
other programs with way less troubles...

If you want to maintain that, no need for it to be removed... atm it's going 
to be unmaintained in the tree, full of problems, and requires us to not plan 
of dropping transcode 0.6.

-- 
Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpIOAXbLYRuA.pgp
Description: PGP signature


Re: [gentoo-dev] December Council Meeting

2005-12-08 Thread Marius Mauch
On Wed, 7 Dec 2005 23:49:59 +
Mike Frysinger [EMAIL PROTECTED] wrote:

 this is your [belated] reminder of the December council meeting.
 future reminders will not be late anymore ... we've proven that we
 cant remember it so i've gone ahead and crontab-ed future reminders
 to go out on the first :)

Would be nice if you'd inform -dev when you change the meeting date
again in the future, esp. when both the channel and the council project
page still refer to the old date.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] December Council Meeting

2005-12-08 Thread Mike Frysinger
On Thu, Dec 08, 2005 at 09:24:57PM +0100, Marius Mauch wrote:
 On Wed, 7 Dec 2005 23:49:59 +
 Mike Frysinger [EMAIL PROTECTED] wrote:
 
  this is your [belated] reminder of the December council meeting.
  future reminders will not be late anymore ... we've proven that we
  cant remember it so i've gone ahead and crontab-ed future reminders
  to go out on the first :)
 
 Would be nice if you'd inform -dev when you change the meeting date
 again in the future, esp. when both the channel and the council project
 page still refer to the old date.

the upcoming date is supposed to be 'tentative' which the council page
says right above 'Dec 8th'

but in the future we'll label future meetings dates with 'tentative'
so there isnt any confusion
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites for media-video/dvdrip

2005-12-08 Thread Roy Marples
On Thursday 08 December 2005 20:23, Diego 'Flameeyes' Pettenò wrote:
 On Thursday 08 December 2005 21:10, Mike Frysinger wrote:
  so the video herd policy is to remove packages until you're left with
  a small enough subset of packages you can handle ?

 No, it's to remove the packages that have problems, that requires
 dependencies that are badly broken (transcode 0.6 is a pain to manage, does
 not work with GCC4 and it's not easily fixable, and upstream moved to
 transcode 1), that requires maintenance and nobody can give it, and that
 might be replaced by other programs with way less troubles...

To be fair, you can hardly count GCC4 as it's not even in our unstable tree 
yet (and yes, I know it will be soon).

Ya know, dhcpcd was in the same state. Unmaintained, didn't compile with GCC4 
and upstream was dead. Didn't hear any calls to remove it from the tree 
though as it was (and still is I suppose) the default dhcp client even though 
all the others are coded much better.


 If you want to maintain that, no need for it to be removed... atm it's
 going to be unmaintained in the tree, full of problems, and requires us to
 not plan of dropping transcode 0.6.

I have no wish to maintain it, but if it compiles then there is no need to 
remove it. So it's unmaintained - so was openvpn and net-misc/dhcp for pretty 
much a year or so until I stepped up.

So if no-one steps up then let it sit in the tree if people are using it.

Roy

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites for media-video/dvdrip

2005-12-08 Thread Chandler Carruth
I am not a gentoo developer, but a user, but I have submitted several 
fixes for dvdrip in the past, and plan on continuing to use it, and get 
it running and working in gentoo. I would be happy to maintain it, or 
simply try to more responsively post fixes in the future to Bugzilla if 
it would keep this package alive in portage. I think it is a very good 
dvd ripping utility, and it _does_ work w/ transcode-1, the dvdrip 
upstream developer simply still bases his work off of 0.6.x. He is 
currently considering moving to transcode-1, so I doubt this package 
will need to continue to be dependant on the difficult to manage 
transcode version.


As a user currently, what steps could I take to help this package stay 
alive? I will take them as the alternative is to put an unofficial 
ebuild up on a webpage.


-Chandler Carruth

Roy Marples wrote:


On Thursday 08 December 2005 20:23, Diego 'Flameeyes' Pettenò wrote:
 


On Thursday 08 December 2005 21:10, Mike Frysinger wrote:
   


so the video herd policy is to remove packages until you're left with
a small enough subset of packages you can handle ?
 


No, it's to remove the packages that have problems, that requires
dependencies that are badly broken (transcode 0.6 is a pain to manage, does
not work with GCC4 and it's not easily fixable, and upstream moved to
transcode 1), that requires maintenance and nobody can give it, and that
might be replaced by other programs with way less troubles...
   



To be fair, you can hardly count GCC4 as it's not even in our unstable tree 
yet (and yes, I know it will be soon).


Ya know, dhcpcd was in the same state. Unmaintained, didn't compile with GCC4 
and upstream was dead. Didn't hear any calls to remove it from the tree 
though as it was (and still is I suppose) the default dhcp client even though 
all the others are coded much better.


 


If you want to maintain that, no need for it to be removed... atm it's
going to be unmaintained in the tree, full of problems, and requires us to
not plan of dropping transcode 0.6.
   



I have no wish to maintain it, but if it compiles then there is no need to 
remove it. So it's unmaintained - so was openvpn and net-misc/dhcp for pretty 
much a year or so until I stepped up.


So if no-one steps up then let it sit in the tree if people are using it.

Roy

 


--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] DepSet

2005-12-08 Thread Jason Stubbs
On Friday 09 December 2005 04:03, Zac Medico wrote:
 Jason Stubbs wrote:
  On Thursday 08 December 2005 16:44, Zac Medico wrote:
 The middle hunk fixes a problem with block atoms that do not match any
 packages.  Previously, these atoms would not make it into the okay_atoms
  set which caused unresolved dependencies.
 
  Are you sure about this?

 Well, I'm pretty sure. You're analysis seems to be perfectly correct except
 for 2 points that you haven't accounted for:

 1) The atom.key != child.key optimization prevents the atom.match(child) ^
 atom.blocks bit from working in the case that my patch handles (block atom
 that does not match any package).

 2) Without the atom.key != child.key optimization, the original algorithm
 would bail out early, before all packages have been checked.  We need to
 ensure that the atom does not block _any_ of the packages before we add it
 to okay_atoms, otherwise, we risk choosing the wrong atomset/combination. 
 Note that checking all the packages _does_ introduce a performance penalty
 for block atoms.

Damn optimizations. :|

Both points are correct.

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list