Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On 12/02/13 08:21, Ian Whyman wrote: Guys, Can we not just have a developer wide vote or something? This instance clearly not going to resole itself. It is a little bikeshed. Originally the virtual was ordered in a way, then ordered in another and now we are discussing which one is better for the user after we turned it around again. There isn't ANYTHING that is impacting users beside those that they might get the next versions of gst-libav just end up with a runtime error if they use ffmpeg (if the upstream authors follow up with their plan) or those users wanting to use mencoder might get some compile errors if I forgot to update the compatibility patch after somebody bumped w/out testing. It really boils down to decide to be extra careful with mplayer and xbmc or being extra careful with gst-libav and maybe vlc. Sadly this whole discussion turned to discussing who is right or wrong, who is the fork or not and who's an evil bastard oppressing the poor Austrian genius or not. I'm ok discussing technical merits and spend time fixing issues, not so much discussing stuff I'd rather not discuss such as if I'm an evil bastard for not working with somebody that joked about my death. lu
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On Tue, Feb 12, 2013 at 2:21 AM, Ian Whyman thev00...@gentoo.org wrote: Can we not just have a developer wide vote or something? This instance clearly not going to resole itself. I don't think the average developer is really in a good position to resolve this - it will just create a whole lot of fuss and who knows if it will come to the right resolution. If it really doesn't matter than save a lot of fuss and flip a coin. If it does matter then the maintainers of the media-video herd should resolve this That's generally where the affected packages are, but they should of course call for comments from reverse dependencies after suitably framing the issue. If anybody feels that isn't going anywhere or isn't going in the right direction and that something needs to change, they can always ask the council to take it up. They're not really the ideal ones to get involved and will probably want somebody to make a really good case for why they should step in. However, if there really is a need for some kind of democratic vote at least the problem becomes properly informing seven people and not 200. Rich
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask
On 12 February 2013 12:45, Ian Delaney (idella4) idel...@gentoo.org wrote: idella4 13/02/12 12:45:55 Modified: package.mask Log: xen-tools-4.2.1-r2.ebuild masked due to need for further refinement, adding to virtualizarion overlay Revision ChangesPath 1.14465 profiles/package.mask file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?rev=1.14465view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?rev=1.14465content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?r1=1.14464r2=1.14465 Index: package.mask === RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v retrieving revision 1.14464 retrieving revision 1.14465 diff -u -r1.14464 -r1.14465 --- package.mask12 Feb 2013 07:19:29 - 1.14464 +++ package.mask12 Feb 2013 12:45:54 - 1.14465 @@ -1,5 +1,5 @@ -# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.14464 2013/02/12 07:19:29 graaff Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.14465 2013/02/12 12:45:54 idella4 Exp $ # # When you add an entry to the top of this file, add your name, the date, and # an explanation of why something is getting masked. Please be extremely @@ -31,6 +31,12 @@ #--- END OF EXAMPLES --- +# Ian Delaney idel...@gentoo.org (12 Feb 2013) +# This is a work in progress targeting an old bug +# but followed by very keen users. It will be either +# abandonned or implemented down the track pending further support +=app-emulation/xen-tools-4.2.1-r2 + # Samuli Suominen ssuomi...@gentoo.org (11 Feb 2013) # The 3 files from this package are part of the linux-firmware # package now. Removal in 30 days. Please also write an entry in the ChangeLog file as well. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On Tue, 12 Feb 2013 12:16:22 +0100 Luca Barbato lu_z...@gentoo.org wrote: On 12/02/13 08:21, Ian Whyman wrote: Guys, Can we not just have a developer wide vote or something? This instance clearly not going to resole itself. It is a little bikeshed. Originally the virtual was ordered in a way, then ordered in another and now we are discussing which one is better for the user after we turned it around again. That's what he's suggesting to vote about. I consider my concerns important and, as such, will continue to use FFmpeg but e.g. your arguments are valid and important too and in the end it boils down to what one considers more important. So far I have been the only one voicing against libav being the default (besides comments on my blog) so I can live with it without vote since it is clear I am minority. Were there more people favoring FFmpeg I would say a kind of vote is needed, but so far I don't think it's worth it. There isn't ANYTHING that is impacting users beside those that they might get the next versions of gst-libav just end up with a runtime error if they use ffmpeg (if the upstream authors follow up with their plan) or those users wanting to use mencoder might get some compile errors if I forgot to update the compatibility patch after somebody bumped w/out testing. Well, this is important. You, as libav developer, could very well try to convince gst-libav people that it's stupid to ban FFmpeg for no technical reason and that the big fat warning when not using the internal version is more due to historical reasons than anything recent since all decent distributions do not use their bundled libav version. mplayer is not that libav-hater as you may think since I believe some libav-compatibility fixes landed before 1.1 (maybe not all, but at least the PIX_FMT hell was resolved). It really boils down to decide to be extra careful with mplayer and xbmc or being extra careful with gst-libav and maybe vlc. IMHO this has to be done whatever the default is. Sadly this whole discussion turned to discussing who is right or wrong, who is the fork or not and who's an evil bastard oppressing the poor Austrian genius or not. I didn't want to have it go that way. I was mainly pointing out that, personal issues apart, FFmpeg has its technical merits that are completely ignored by libav. I'm ok discussing technical merits and spend time fixing issues, not so much discussing stuff I'd rather not discuss such as if I'm an evil bastard for not working with somebody that joked about my death. +1 Alexis.
Re: [gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass
On 2/11/13 11:14 PM, Michał Górny wrote: My patches introduce a single wrapper with argv-as-parameter syntax. That is, the fore-mentioned example would look like: virtualx run_tests --foo Maybe we can just adapt Ubuntu's (I think) xvfb-run? More standardization == profit. Thank you for working on this! Paweł signature.asc Description: OpenPGP digital signature
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, 10 Feb 2013 20:43:02 +0100 Dirkjan Ochtman d...@gentoo.org wrote: On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani lx...@gentoo.org wrote: +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). This is another problem, namely dependency level problem. I don't see how having kernel sources ebuilds providing /lib/firmware would fix any of the listed issues without causing other side effects. For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? Sorry this is not threaded properly; I accidentally deleted the e-mail I intended to reply to. Please don't make kernel sources RDEPEND on firmware. The kernel DOES NOT depend on firmware to work properly. Well over half my machines prove that: they work perfectly fine (read: 100% of their hardware works) with no firmware at all installed. Don't force me to install a package that provides me with a grand total of zero benefit, just so you can hand-hold people. It's unfortunate that people were caught by the firmware being removed from the kernel and breaking their hardware. This sounds like an application for a news message telling people to install firmware if needed, but IMO it doesn't call for a dependency. Chris
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, 10 Feb 2013 14:49:03 -0800 Alec Warner anta...@gentoo.org wrote: Most external firmware is not needed to boot. If you need it to boot, you will have to stow it in the initramfs. For those of us who prefer monolithic kernels, virtually all firmware is needed to boot. Even if a network interface doesn't need to be operational for boot, the kernel insists that the firmware be available right at boot or else it will fail and the interface will never appear. Chris
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
I am starting to believe that this is yet another good reason for having official ebuilds building binaries off gentoo-sources through genkernel. Pretty much the same I do in Sabayon since 2007. -- Fabio Erculiani
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
El mar, 12-02-2013 a las 19:43 +, Fabio Erculiani escribió: I am starting to believe that this is yet another good reason for having official ebuilds building binaries off gentoo-sources through genkernel. Pretty much the same I do in Sabayon since 2007. I think shouldn't have any problems on providing them also as an alternative, the problem is who would maintain that builds (as I guess Sabayon is using different sources than gentoo and, then, probably not all chosen options for Sabayon will work on Gentoo :/) signature.asc Description: This is a digitally signed message part
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Tue, Feb 12, 2013 at 7:47 PM, Pacho Ramos pa...@gentoo.org wrote: El mar, 12-02-2013 a las 19:43 +, Fabio Erculiani escribió: I am starting to believe that this is yet another good reason for having official ebuilds building binaries off gentoo-sources through genkernel. Pretty much the same I do in Sabayon since 2007. I think shouldn't have any problems on providing them also as an alternative, the problem is who would maintain that builds (as I guess Sabayon is using different sources than gentoo and, then, probably not all chosen options for Sabayon will work on Gentoo :/) If the goal is providing a general purpose kernel that's based on genpatches (plus BFQ and aufs3) and could be used in official live images, the current sabayon kernels could work just fine for Gentoo. They are coming directly from Linus' (or gregkh for stable releases) git repo. Upstreaming sabayon-kernel.eclass and kernel binary ebuilds is something I'd be interested in, as long as other devs here are willing to help me out as well. But I don't want to go off-topic too much. -- Fabio Erculiani
[gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)
Christopher Head posted on Tue, 12 Feb 2013 11:39:57 -0800 as excerpted: On Sun, 10 Feb 2013 14:49:03 -0800 Alec Warner anta...@gentoo.org wrote: Most external firmware is not needed to boot. If you need it to boot, you will have to stow it in the initramfs. For those of us who prefer monolithic kernels, virtually all firmware is needed to boot. Even if a network interface doesn't need to be operational for boot, the kernel insists that the firmware be available right at boot or else it will fail and the interface will never appear. I'm a monolithic kernel guy myself, and I simply build-in the firmware I need (three radeon firmware files, IIRC, used to be tg3 as well until that mobo died). Obviously there can be issues with distribution, but purpose-built monolithic kernels aren't generally practical for distribution anyway, and the GPL has always been clear that it doesn't interfere with end-user rights in terms of build-combining whatever they want, as long as there's no further distribution. And FWIW, I didn't really know about linux-firmware either, but google knew when I asked it about the files the kernel errors spit out. =:^) And I didn't actually install it, either. I simply grabbed the tarball and extracted the files I needed, placing them where the kernel could find them. -- 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] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)
Christopher Head posted on Tue, 12 Feb 2013 11:38:14 -0800 as excerpted: On Sun, 10 Feb 2013 20:43:02 +0100 Dirkjan Ochtman d...@gentoo.org wrote: On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani lx...@gentoo.org wrote: +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? Please don't make kernel sources RDEPEND on firmware. The kernel DOES NOT depend on firmware to work properly. Well over half my machines prove that: they work perfectly fine (read: 100% of their hardware works) with no firmware at all installed. Not a problem as long as the RDEPEND is under USE=firmware or similar. No USE=firmware, no rdepend! =:^) Kernel sources providing /lib/firmware itself shouldn't be a problem either, as that's just a dir, which many packages may own. The individual firmware files would be a problem, but the USE=firmware RDEPEND solution should solve that. -- 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
Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)
On Tue, 12 Feb 2013 20:51:15 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Christopher Head posted on Tue, 12 Feb 2013 11:38:14 -0800 as excerpted: On Sun, 10 Feb 2013 20:43:02 +0100 Dirkjan Ochtman d...@gentoo.org wrote: On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani lx...@gentoo.org wrote: +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? Please don't make kernel sources RDEPEND on firmware. The kernel DOES NOT depend on firmware to work properly. Well over half my machines prove that: they work perfectly fine (read: 100% of their hardware works) with no firmware at all installed. Not a problem as long as the RDEPEND is under USE=firmware or similar. No USE=firmware, no rdepend! =:^) Kernel sources providing /lib/firmware itself shouldn't be a problem either, as that's just a dir, which many packages may own. The individual firmware files would be a problem, but the USE=firmware RDEPEND solution should solve that. Yes, of course, I meant please don’t depend unconditionally. A conditional depend is fine by me, and I don’t care about one random directory being created—I just don’t want a whole package being pulled in for nothing. Chris
[gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2013 10:14 PM, William Hubbs wrote: as preparation for the up-coming cvs-git migration of the portage tree, the council is strongly suggesting that from this point forward all developers sign their manifests with their gpg key as described in the developer's manual [1]. ++ We should all put these data into LDAP, too. on dev.gentoo.org .. perl_ldap -b user -M gpgkey gpg-id user perl_ldap -b user -M gpgfingerprint gpg-fingerprint user At least have some lose binding between tree signing keys and dev identities. Or put the whole public key into the ldap. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEax6cACgkQknrdDGLu8JAHmgD/fMVoUUO5g7iYeFobMy6rWBW8 mVIAoCe2BWZ6XOfPEvEBAI1Ny0ruWaRjI+HEStU3omgNVPUddeLoKJMyK5r0pJiX =37sv -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)
On 02/12/2013 09:43 PM, Duncan wrote: Christopher Head posted on Tue, 12 Feb 2013 11:39:57 -0800 as excerpted: On Sun, 10 Feb 2013 14:49:03 -0800 Alec Warner anta...@gentoo.org wrote: Most external firmware is not needed to boot. If you need it to boot, you will have to stow it in the initramfs. or the kernel itself ... For those of us who prefer monolithic kernels, virtually all firmware is needed to boot. Even if a network interface doesn't need to be operational for boot, the kernel insists that the firmware be available right at boot or else it will fail and the interface will never appear. I'm a monolithic kernel guy myself, and I simply build-in the firmware I need (three radeon firmware files, IIRC, used to be tg3 as well until that mobo died). dito. And FWIW, I didn't really know about linux-firmware either, but google knew when I asked it about the files the kernel errors spit out. =:^) And I didn't actually install it, either. I simply grabbed the tarball and extracted the files I needed, placing them where the kernel could find them. from cross distro source etc. I wonder how that linux-firmware serves it all will handle different versions of one firmware-filename with disjunct sets of supported hardware revisions. Random files in /lib/firmware out of packet manager space it is (form me). -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
[gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2013 10:14 PM, William Hubbs wrote: If you have any questions on this, please feel free to let us know. What is the rotation strategy for (near) outdated keys? Alter the key or create a new one? Sign the new with the old one? IMHO the answer to these questions is not obvious nor given by (our) docu [1]. Maybe, add keep ldap id/fingerprint synchronized there, too. [1] http://devmanual.gentoo.org/general-concepts/manifest/index.html - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEazGMACgkQknrdDGLu8JBXygD8CalxwI4y7kxbqYwyXcyohtbW 7xICGdFgIDA8jH7v4poA/RrtQTxwmmzE4g53Eyg8RBKxEIa0BmAZUaAMIyM9ntdq =XOfU -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On Wed, Feb 13, 2013 at 12:12:35AM +0100, Michael Weber wrote: On 02/12/2013 10:14 PM, William Hubbs wrote: If you have any questions on this, please feel free to let us know. What is the rotation strategy for (near) outdated keys? Alter the key or create a new one? Sign the new with the old one? If your keysize is still good, you should ideally update the expiry on the key and re-upload it to keyservers. IMHO the answer to these questions is not obvious nor given by (our) docu [1]. I'm pretty sure it was in the devrel developer handbook at one point, along with instructions to create your key, but I can't find it now. Maybe, add keep ldap id/fingerprint synchronized there, too. http://www.gentoo.org/proj/en/infrastructure/ldap.xml#doc_chap3 -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On Tue, 12 Feb 2013 15:14:15 -0600 William Hubbs willi...@gentoo.org wrote: All, as preparation for the up-coming cvs-git migration of the portage tree, the council is strongly suggesting that from this point forward all developers sign their manifests with their gpg key as described in the developer's manual [1]. If you have any questions on this, please feel free to let us know. On behalf of the council, William [1] http://devmanual.gentoo.org/general-concepts/manifest/index.html It would help if repoman noticed when you have FEATURES=-sign. :-\ jer
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On Wed, 13 Feb 2013 01:47:34 +0100 Jeroen Roovers j...@gentoo.org wrote: It would help if repoman noticed when you have FEATURES=-sign. :-\ https://bugs.gentoo.org/show_bug.cgi?id=457034 jer
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On Tue, Feb 12, 2013 at 5:05 PM, Jeroen Roovers j...@gentoo.org wrote: On Wed, 13 Feb 2013 01:47:34 +0100 Jeroen Roovers j...@gentoo.org wrote: It would help if repoman noticed when you have FEATURES=-sign. :-\ https://bugs.gentoo.org/show_bug.cgi?id=457034 We can do the opposite, and just complain if we see unsigned manifests fly by. -A jer
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On Tue, 12 Feb 2013 17:07:33 -0800 Alec Warner anta...@gentoo.org wrote: On Tue, Feb 12, 2013 at 5:05 PM, Jeroen Roovers j...@gentoo.org wrote: On Wed, 13 Feb 2013 01:47:34 +0100 Jeroen Roovers j...@gentoo.org wrote: It would help if repoman noticed when you have FEATURES=-sign. :-\ https://bugs.gentoo.org/show_bug.cgi?id=457034 We can do the opposite, and just complain if we see unsigned manifests fly by. The background here is that I set up a new system and forgot to set FEATURES=sign before I went on to do commits from that system. It's not like I set FEATURES=-sign on purpose. :) jer
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On 02/13/2013 12:28 AM, Robin H. Johnson wrote: On Wed, Feb 13, 2013 at 12:12:35AM +0100, Michael Weber wrote: On 02/12/2013 10:14 PM, William Hubbs wrote: If you have any questions on this, please feel free to let us know. What is the rotation strategy for (near) outdated keys? Alter the key or create a new one? Sign the new with the old one? If your keysize is still good, you should ideally update the expiry on the key and re-upload it to keyservers. Can you commit this to the document, please? IMHO the answer to these questions is not obvious nor given by (our) docu [1]. I'm pretty sure it was in the devrel developer handbook at one point, along with instructions to create your key, but I can't find it now. Maybe, add keep ldap id/fingerprint synchronized there, too. http://www.gentoo.org/proj/en/infrastructure/ldap.xml#doc_chap3 That does tell how to update the data, but does not suggest to do so. My main concern is the cross-referencing of our documentation. I'm aware that there is a ton of documentation splattered all over the place and outside our infra. But besides the non-trivial step to become a dev (as mentioned last week) there is a certain non-trivial step to keep one, esp. by gathering the non-routine informations and fast-forward developments. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
