Re: [gentoo-dev] GLEP 27 Proposal - Feedback Requested
Hello Mike, Am Dienstag, 30. Mai 2006 05:29 schrieb Mike Kelly: I'm Mike Kelly, one of the SoC-ers. I'll be working on GLEP 27 for the summer. Right now I'm looking for some basic feedback on my proposal. In particular, I know that at one point there was a push for the user info files to be XML, but I think it may be easier to implement them as simple shell variable files (like /etc/conf.d/*), since my plan was to write the core of the implementation in shell (e.g. as an eclass). From your proposal: - Add code to the eutils.eclass which will detect if the installed version of portage supports the new system, notifies the operator that the current ebuild is using depreciated code, and properly add the user using the new system's code. This would check for the proper EAPI version to know when to execute the new code instead. As a member of Release Engineering who encountered already a problem with user-management code in eutils.eclass, i beg you: _plase_ don't add it to that eclass. Instead, create a new eclass 'euser' or something similar and add it there. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC Maintainer-Wanted Bugs/Cleaning]
Alec Warner wrote: So we created this awesome alias to put ebuilds that need a maintainer. Good idea at the time, decent idea still. The problem? We have nearly 2000 open bugs assigned to maintainer-wanted[1]. I would like to discuss policy on these. Do we keep them, do we get a group of people to slowly review and discard them? Do we mind having a ton of things open like this (a quasi-ebuild db of sorts). Is bugs the right place for this sort of thing, or can we improve somewhere/how? Discarding them seems not like a good idea to me. I think they are interesting for many users who want to use the software that lacks an ebuild. Also some contributors have invested a lot of time in it. I think those should all be available within an overlay: overlays.gentoo.org There they are downloadable, improveable and we do not turn contributors away by WONTFIX. Additionally we will not get many dupes once we close an ebuild contribution. People who file ebuild requests have not contributed anything, so I think those can easily be marked as WONTFIX :) Probably it makes sense to have such an overlay on gentooexperimental.org for the time being. So that we can start reducing the 2000 bugs in bugzilla Regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 27 Proposal - Feedback Requested
On Tue, May 30, 2006 at 09:14:01AM +0200, Danny van Dyk wrote: Hello Mike, Am Dienstag, 30. Mai 2006 05:29 schrieb Mike Kelly: I'm Mike Kelly, one of the SoC-ers. I'll be working on GLEP 27 for the summer. Right now I'm looking for some basic feedback on my proposal. In particular, I know that at one point there was a push for the user info files to be XML, but I think it may be easier to implement them as simple shell variable files (like /etc/conf.d/*), since my plan was to write the core of the implementation in shell (e.g. as an eclass). From your proposal: - Add code to the eutils.eclass which will detect if the installed version of portage supports the new system, notifies the operator that the current ebuild is using depreciated code, and properly add the user using the new system's code. This would check for the proper EAPI version to know when to execute the new code instead. As a member of Release Engineering who encountered already a problem with user-management code in eutils.eclass, i beg you: _plase_ don't add it to that eclass. Instead, create a new eclass 'euser' or something similar and add it there. Commented in irc re: this, but eclass doesn't really fly- if it's implemented strictly in an eclass, portage has no way of easily reverting the changes (mainly cause it's not aware of 'em) if the build fails, thus the user/group isn't needed. Same for unmerging. Further, if implemented strictly as a trick in one of the ebuild phases, setup is the likely place- means that setup cannot be deprived to non-root for running it (thorn in the side for trying to depriv all phases). So... need it higher up then implemented in one of the ebuild phases. :) ~harring pgpDaQe1Exygv.pgp Description: PGP signature
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
On 30/05/06, Mark Loeser [EMAIL PROTECTED] wrote: Basically, it would be something that allowed you to browse the current tree of submitted ebuilds. This way users that submit something can categorize it for devs to easily look for ebuilds they may be interested in, and we can make it so we could easily grab the ebuilds from this hacked up idea of a tree. Hmm something like a tree, containing ebuilds, that people can check out and browse... :) Comments on this idea are appreciated. I wouldn't mind helping write it and maintain it, but having interest and support in doing something like this is definately going to be needed :) The idea of an unmaintained tree has come up before and been shot down because (paraphrasing) 1. nobody will check the ebuilds 2. nobody will maintain it 3. nobody will bother marking stuff stable and 4.it will be a security nightmare. Personally I think it would be fun to just throw open the gates and have an open git (or other dscms) no-guarantees repository that pulls from the main tree every day, and which anyone with an email address can sign up for and then push their own stuff to. Or maybe some wiki-frontend to a branch of the portage tree. Yeah there would be some security issues and vandalism just like any open content system. Nevertheless, It would be a very interesting experiment in opening ebuild development and maintenance to a larger audience. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
On Mon, May 29, 2006 at 07:30:25PM -0400, Alec Warner wrote: So we created this awesome alias to put ebuilds that need a maintainer. Good idea at the time, decent idea still. The problem? We have nearly 2000 open bugs assigned to maintainer-wanted[1]. I would like to discuss policy on these. Do we keep them, do we get a group of people to slowly review and discard them? Do we mind having a ton of things open like this (a quasi-ebuild db of sorts). Is bugs the right place FOR THIs sort of thing, or can we improve somewhere/how? Could we establish policies for closing them or leaving them to sit open? - Upstream dead, previously submitted URLs no longer functional (yes, there are actually some like this!). - No ebuild included. - Upstream says obsolete in favour of another package. - Dev notes obsolete in favour of another package - suggest it to the submitter, and see what they say. - Major unresolved security issues. - Excessive complexity / unsuitable for ebuild installs (eg apps that are meant to be built and run from the same directory). I'm in favour of leaving stuff sitting there, until a developer with a need comes along (I wouldn't use an untrusted tree even if there was one). At the same time, existing developers and teams should be encouraged to look at those under maintainer-wanted, and consider stuff there. I try to keep an eye out for app-backup and other fields that I'm involved in. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpEHE0qwEgfq.pgp Description: PGP signature
[gentoo-dev] New adresses
Hi, My new IM (Jabber) adress is : [EMAIL PROTECTED] My new email is : [EMAIL PROTECTED] Beber -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
Robin H. Johnson wrote: Could we establish policies for closing them or leaving them to sit open? - Upstream dead, previously submitted URLs no longer functional (yes, there are actually some like this!). - No ebuild included. - Upstream says obsolete in favour of another package. - Dev notes obsolete in favour of another package - suggest it to the submitter, and see what they say. - Major unresolved security issues. - Excessive complexity / unsuitable for ebuild installs (eg apps that are meant to be built and run from the same directory). More or less what I've been doing for past few months... Today, I've also closed all ebuild requests 1+ year old w/ zero activity as CANTFIX, asking the reporter to attach an ebuild. Bugs like I'd like to see foo/bar in portage, ktnxbye don't need to sit in bugzilla for ages if noone is interested, not really useful. (And - as mentioned before, some automation of the process would be nice ;) At the same time, existing developers and teams should be encouraged to look at those under maintainer-wanted, and consider stuff there. I try to keep an eye out for app-backup and other fields that I'm involved in. Also, please really close useless cruft when you come across it (see above). -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] mii-tool single distribution
Hi folks, JFYI: I've made an mii-tool single distribution, which is independent from the rest of the net-tools stuff. http://www.metux.de/articles/oss/mii-tool-1_9_1_1 This is especially interesting for embedded systems with plenty of space. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 27 Proposal - Feedback Requested
On Monday 29 May 2006 23:29, Mike Kelly wrote: In particular, I know that at one point there was a push for the user info files to be XML not really, it was just an idea i had at the time ... ive been over it a few times since with the portage guys and it makes no real sense to do it in xml also, current GLEP 27 should say nothing of xml , but I think it may be easier to implement them as simple shell variable files (like /etc/conf.d/*), using shell variables just leads to quoting problems since my plan was to write the core of the implementation in shell (e.g. as an eclass). i fail to see where eclasses play any role in the scheme of things the point of having all the logic in portage is that ebuilds need not care about anything My proposal is available at: http://www.pioto.org/~pioto/gentoo/soc2006/glep27-proposal.txt. Any feedback would be appreciated; I wanna get things started on the right foot. we shouldnt give a way to add extra custom options since we're back to square one in terms of portability (useradd is only used on GNU systems, not Darwin/BSD) the current format last time i bugged the portage peeps was simple: key: value -mike pgpysvCYSlNeJ.pgp Description: PGP signature
Re: [gentoo-dev] New adresses
On Tuesday 30 May 2006 12:12, Bertrand Jacquin wrote: Hi, My new IM (Jabber) adress is : [EMAIL PROTECTED] My new email is : [EMAIL PROTECTED] So now the whole world knows the email adresses of your contacts. They'll certainly be happy about that. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpkGWh07q5MF.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-embedded] mii-tool single distribution
On Tue, 2006-05-30 at 14:05 +0200, Natanael Copa wrote: On Tue, 2006-05-30 at 13:06 +0200, Enrico Weigelt wrote: Hi folks, JFYI: I've made an mii-tool single distribution, which is independent from the rest of the net-tools stuff. http://www.metux.de/articles/oss/mii-tool-1_9_1_1 This is especially interesting for embedded systems with plenty of space. (embedded with plenty of space? kinda funny) If you had plenty of space then chances are you would be going the net-tools route. Cool! It would be even more interesting if you could get it into busybox and/or get it into portage. busybox absolutely seems the ideal place for cut out utils. mii-tool is a handy one also. -- Natanael Copa -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] net-www/awstats: security issues, revbump (and probably maintainer) needed
CHTEKK does this one, thanks. Hi Gang, net-www/awstats is masked because it has open security issues (including remote code execution), see bug #130487 for details. Version 6.6 was made to fix it, but unfortunately this version is not working at all (see bug #134296), so we are trapped between unusable and vulnerable versions. Jakub made a patch for version 6.5 to fix this vulnerabilities, but that very patch still needs to be incorporated into an ebuild and commited as revbump. So, if anyone volunteers to step up and revbump 6.5 with patch (or fix 6.6 so that it's usable), please don't hesitate. It would be also cool to have a new maintainer for this one, since ka0ttic seems to be missing. Thanks in advance, Stefan 'DerCorny' Cornelius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
Mark Loeser wrote: Basically, it would be something that allowed you to browse the current tree of submitted ebuilds. This way users that submit something can categorize it for devs to easily look for ebuilds they may be interested in, and we can make it so we could easily grab the ebuilds from this hacked up idea of a tree. It would make it a lot easier to do automated checks against submitted ebuilds for QA issues, and we would offload all of those submissions from bugs.g.o to this app. I guess you could think of it as the overlays.g.o idea, but I tend to think overlays are experimental things that aren't necessarily going to be added to the tree. This would be for ebuilds/packages that are ready to be added to the tree, but just lack someone that wants to maintain them. A big advantage of the current system is that people tend to add bug reports to those maintainer-wanted ebuild bugs, so the community can actually iterate through ebuilds for a non-tree package without too much pain. Separating the pending ebuilds from bugs would make that harder. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] xextproto, what to do
Rakotomandimby Mihamina wrote: Hi, I am trying to install qemu and kqemu, and I run into a problem: This is a question for the gentoo-user mailing list. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] xextproto, what to do
Hi, I am trying to install qemu and kqemu, and I run into a problem: localhost ~ # emerge qemu kqemu Calculating dependencies... done! Emerging (1 of 33) x11-proto/xextproto-7.0.2 to / Downloading http://xorg.freedesktop.org/releases/individual/proto/xextproto- 7.0.2.tar.bz2 --01:34:16-- http://xorg.freedesktop.org/releases/individual/proto/xextproto-7. 0.2.tar.bz2 = `/usr/portage/distfiles/xextproto-7.0.2.tar.bz2' Resolving xorg.freedesktop.org... 131.252.208.36 Connecting to xorg.freedesktop.org|131.252.208.36|:80... And then I got a connection timeout. http://xorg.freedesktop.org/ does not respond. there is also a bug in here: http://gentoo-portage.com/x11-proto/xextproto/ChangeLog#ptabs Let's suppose I find a mirror for this software, what's the way to modify the ebuild into /var/... to consider the mirror I found at least until the problem is solved? I am a bit new too Gentoo. Thank you. -- A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source GPL). Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better. http://www.cps-project.org for downloads documentation. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New Developer: Chris Parrott
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All- Chris has move from various AT projects to a developer. cparrot was fist on the amd64 AT project, then he moved on to other arches and some other hards. It's my great pleasure to have him as a gentoo developer. In his own words: Greetings! My name is Chris Parrott, and I am joining the Gentoo developer corps as a member of the Haskell herd, working with Duncan Coutts. I reside near Austin, Texas with my lovely wife and three boys. I have been a user and fan of Gentoo since around the 1.4 release, back in 2003. Before that, I have used various other forms of Linux since around 1994 or so. Prior to joining Gentoo as a developer, I served for over a year as an AT on the amd64 team. I also happen to own a wide variety of machines that have Gentoo installations on them: amd64, ppc64, sparc, alpha, hppa, and mips. (The first four are my primary testbed, but I can fire the others up as needed.) My main interests are programming languages/compilers, high-performance computing -- and to a lesser extent, databases, web applications, and networking. I almost always enjoy learning new things. Outside of Gentoo, I have a pretty cool day job: I work for a prominent U.S. chip manufacturer, doing performance analysis on Linux clusters. I can also speak a little Spanish and German, although I'm not very fluent. I also enjoy grilling, playing with my kids, music, and hiking. I am looking forward to working with all of you and getting to know you better. Anytime you want to chat about something, please feel free to ping me on IRC or drop me an email. - --Mike -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEfG/Z0K3RJaeXx6cRAhvzAJ91l6eVwG8ZYugIpfYgsdHPZVqVwwCePt3p dxwltA0BcuFjvXagPL3sSKQ= =c3yV -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Chris Parrott
On Tue, 2006-05-30 at 11:16 -0500, Mike Doty wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All- Chris has move from various AT projects to a developer. cparrot was fist on the amd64 AT project, then he moved on to other arches and some other hards. It's my great pleasure to have him as a gentoo developer. In his own words: Greetings! My name is Chris Parrott, and I am joining the Gentoo developer corps as a member of the Haskell herd, working with Duncan Coutts. I reside near Austin, Texas with my lovely wife and three boys. I have been a user and fan of Gentoo since around the 1.4 release, back in 2003. Before that, I have used various other forms of Linux since around 1994 or so. Prior to joining Gentoo as a developer, I served for over a year as an AT on the amd64 team. I also happen to own a wide variety of machines that have Gentoo installations on them: amd64, ppc64, sparc, alpha, hppa, and mips. (The first four are my primary testbed, but I can fire the others up as needed.) My main interests are programming languages/compilers, high-performance computing -- and to a lesser extent, databases, web applications, and networking. I almost always enjoy learning new things. Outside of Gentoo, I have a pretty cool day job: I work for a prominent U.S. chip manufacturer, doing performance analysis on Linux clusters. I can also speak a little Spanish and German, although I'm not very fluent. I also enjoy grilling, playing with my kids, music, and hiking. I am looking forward to working with all of you and getting to know you better. Anytime you want to chat about something, please feel free to ping me on IRC or drop me an email. Congrats again Chris... i know you from a long time and i wish you good luck. You have been an AT since a long time and you already know the house so welcome to the team now as a dev :). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Chris Parrott
Mike Doty wrote: I am looking forward to working with all of you and getting to know you better. Anytime you want to chat about something, please feel free to ping me on IRC or drop me an email. I would like to welcome you to the team too, I remember when you first joined as an AT and it is great to see you becoming a dev. I don't have as much time for IRC these days so I haven't spoken to you too much but I am sure you will make a great addition to the team :) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [Last Rites ipkg-utils]
ipkg-utils was maintained by tigger who is no longer a dev. As far as tigger/solar are aware there is no reason to keep it in the tree. It will be pmask'd and punted in 30 days at their request. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] mii-tool single distribution
On Tue, May 30, 2006 at 01:06:33PM +0200, Enrico Weigelt wrote: Hi folks, JFYI: I've made an mii-tool single distribution, which is independent from the rest of the net-tools stuff. http://www.metux.de/articles/oss/mii-tool-1_9_1_1 This is especially interesting for embedded systems with plenty of space. What functionality is there in mii-diag that has not been moved to ethtool's -s option? -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp5ZeGcfpJYS.pgp Description: PGP signature
Re: [gentoo-dev] New Developer: Chris Parrott
On Tue, 2006-05-30 at 11:16 -0500, Mike Doty wrote: Chris has move from various AT projects to a developer. cparrot was fist on the amd64 AT project, then he moved on to other arches and some other hards. It's my great pleasure to have him as a gentoo developer. /me sheds a tear.. Congrats Chris! -- Homer Parker [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] xextproto, what to do
Andrew Gaffney wrote: Rakotomandimby Mihamina wrote: Hi, I am trying to install qemu and kqemu, and I run into a problem: This is a question for the gentoo-user mailing list. Didn't you notice, he cross-posted to there as well as personally emailing me. Not something likely to make anybody real eager to help someone out... Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] [useflag] v4l2 : video4linux2 support
Currently we have already 5 applications supporting v4l2 (6 if I split the support in ffmpeg) what about having it global too? local use flags (searching: v4l2) [+ C ] v4l2 (dev-libs/DirectFB): Enables video4linux2 support [+ C ] v4l2 (dev-libs/pwlib): Enable video4linux2 support [+ C ] v4l2 (media-video/mpeg4ip): Enable video4linux2 support for mp4live [+ C ] v4l2 (media-video/mplayer): Enables video4linux2 support [+ C ] v4l2 (media-video/transcode): Enable video4linux2 support lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [useflag] v4l2 : video4linux2 support
On Tue, May 30, 2006 at 11:57:19PM +0200, Luca Barbato wrote: Currently we have already 5 applications supporting v4l2 (6 if I split the support in ffmpeg) Any reason why we can not use the existing 'v4l' use flag for version 2 as well? Why repeat the gtk/gtk2 mistake? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpP4FP9gZwGa.pgp Description: PGP signature
[gentoo-dev] [useflag] firefox : build against firefox instead of mozilla
While at it: 16 apps w/ firefox local use flag: local use flags (searching: firefox) [+ C ] firefox (app-office/openoffice): Build against Firefox instead of Mozilla [+ C ] firefox (dev-haskell/gtk2hs): Build the Mozilla Embeded Component against firefox rather than mozilla [+ C ] firefox (dev-java/swt): Build the Mozilla Embeded Component against firefox rather than mozilla [+ C ] firefox (dev-python/gnome-python-extras): allow building against firefox libs [+ C ] firefox (dev-ruby/ruby-gtkmozembed): compile against Firefox instead of Mozilla [+ C ] firefox (dev-util/devhelp): Build against firefox rather than mozilla [+ C ] firefox (dev-util/eclipse-sdk): Build against firefox rather than mozilla [+ C ] firefox (gnome-extra/evolution-data-server): Use Firefox's NSS/NSPR libraries if SSL is enabled [+ C ] firefox (gnome-extra/yelp): Build against firefox instead of mozilla [+ C ] firefox (mail-client/evolution): Use Firefox's NSS/NSPR libraries if SSL is enabled [+ C ] firefox (net-news/liferea): Build against Firefox instead of Mozilla [+ C ] firefox (www-client/epiphany-extensions): build against firefox instead of mozilla [+ C ] firefox (www-client/epiphany): build against firefox instead of mozilla [+ C ] firefox (www-client/galeon): build against firefox instead of mozilla [+ C ] firefox (www-client/kazehakase-cvs): Use firefox's Gecko engine. [+ C ] firefox (www-client/kazehakase): Use firefox's Gecko engine. See http://bugs.gentoo.org/show_bug.cgi?id=96473 as well. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [useflag] v4l2 : video4linux2 support
Henrik Brix Andersen wrote: On Tue, May 30, 2006 at 11:57:19PM +0200, Luca Barbato wrote: Currently we have already 5 applications supporting v4l2 (6 if I split the support in ffmpeg) Any reason why we can not use the existing 'v4l' use flag for version 2 as well? Why repeat the gtk/gtk2 mistake? Good point considering I already merged it in ffmpeg long ago. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [useflag] v4l2 : video4linux2 support
On Tuesday 30 May 2006 23:41, Henrik Brix Andersen wrote: Any reason why we can not use the existing 'v4l' use flag for version 2 as well? Why repeat the gtk/gtk2 mistake? Because v4l2 is not available on 2.4 kernel, and if transcode didn't have v4l2 instead of v4l I should have resurrected transcode 0.6 and freaking contined to support that stupid package :P -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpP6dXllHvr4.pgp Description: PGP signature
