Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
On 12/09/2012 09:15 PM, Brian Dolbec wrote: > No, once they are downloaded, they don't change ever after the quarterly > rollover which starts a new updates file. Nor do they take up > significant storage space. They probably take up a higher percentage of > your fs's inodes than % diskspace. > > But they do take time to process and verify every time emerge initiates > a fixpackages call after every sync. That will save time more than it > will space. It skips the older files if their timestamp hasn't changed since it was recorded in /var/cache/edb/mtimedb. So, there's minimal overhead from keeping them, unless you lose /var/cache/edb/mtimedb somehow. -- Thanks, Zac
Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
On Sun, 09 Dec 2012 21:15:37 -0800 Brian Dolbec wrote: > No, once they are downloaded, they don't change ever after the quarterly > rollover which starts a new updates file. gentoo-x86/profiles/updates $ LANG=C ls -1 --sort=time 4Q-2012 3Q-2012 1Q-2008 2Q-2012 4Q-2011 1Q-2012 3Q-2011 2Q-2011 1Q-2011 2Q-2005 3Q-2008 4Q-2010 1Q-2005 2Q-2008 3Q-2010 2Q-2010 1Q-2010 3Q-2004 4Q-2009 3Q-2009 2Q-2009 1Q-2009 4Q-2008 3Q-2005 3Q-2007 4Q-2007 2Q-2007 1Q-2007 4Q-2006 2Q-2006 3Q-2006 1Q-2006 4Q-2005 4Q-2004 2Q-2004 1Q-2004 old entries are done in different context (comparing to 2012): - some packages change names 2 or 3 times - slots have different meaning moreover: - if you set your PORTDIR to different directory you'll get all that full update. And will break the system. Old profile entries used to break eclass-manpages and latex-base (due to double renaming) Random example: Let's loot at why 2Q-2005 was changed in 2010: https://bugs.gentoo.org/show_bug.cgi?id=351760 Thus the reason for removal is simple: old entries are potentially buggy as nobody verifies them. -- Sergei signature.asc Description: PGP signature
[gentoo-dev] Obsolete package atoms in package.mask files
Some time ago, there was one bugreport[1] about obsolete mask entries in package.mask files in diffirent profiles. Bug is assigned to QA team, but only amd64 no-multilib profile was cleaned up, as i know. Maybe we should add arch teams, whose profiles contains deprecated entries, to CC on this bug? [1] - https://bugs.gentoo.org/show_bug.cgi?id=444181 -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
On Mon, 2012-12-10 at 01:52 +0100, Peter Stuge wrote: > Brian Dolbec wrote: > > > > remove entries in profiles/updates for tree-cleaned packages... > > > > > > What's the advantage of doing that? > > > > None > .. > > FYI... Currently there are updates files in profiles/updates/ > > dating back to 2004 > > Do they take up significant storage space or transfer time, compared > to the rest of the tree? > > If not, I can't think of a reason to remove them. > > > //Peter No, once they are downloaded, they don't change ever after the quarterly rollover which starts a new updates file. Nor do they take up significant storage space. They probably take up a higher percentage of your fs's inodes than % diskspace. But they do take time to process and verify every time emerge initiates a fixpackages call after every sync. That will save time more than it will space. Also, (taking it a bit to extremes ;) ) why would a new user with a 2 month old system and up-to-date tree want 8 year old update cruft lingering about their filesystem...taking time to check they've been processed? Do you? Let's just do an annual tree-cleaning and be done with them. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] borked release media
On Mon, Dec 10, 2012 at 12:21:29AM +0100, Chí-Thanh Christopher Nguyễn wrote: > Greg KH schrieb: > >> No, all we need is to enable EFI stub support in the kernel, and > >> integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in > >> some location where UEFI looks for it (/efi/boot/bootx64.efi). > >> > >> This has the disadvantage of not allowing to pass additional kernel > >> parameters during boot. But it might still be an acceptable stopgap > >> measure if the alternative is to not boot at all. > > > > No, don't do that for an "install" kernel, that way is madness, just use > > a real UEFI bootloader which can handle an initrd and the like properly > > Can you explain what problems you see with that? How does > CONFIG_INITRAMFS_SOURCE handle initrd improperly? Ah, didn't notice that, it might work, have you tried it? greg k-h
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 08:08:01PM -0500, Rich Freeman wrote: > On Sun, Dec 9, 2012 at 7:57 PM, Diego Elio Pettenò > wrote: > > On 10/12/2012 01:52, Rich Freeman wrote: > >> The shim might work, but I'd hardly call it "secure boot" if every > >> motherboard manufacturer and OEM in the world has the ability to sign > >> things, even if MS vouched for them all. Even if I installed Windows > >> I'd want the ability to re-sign it with a key I controlled and tell > >> the firmware to refuse to boot the MS key. > > > > I don't think it's Gentoo's place to do that kind of stuff especially > > since I think you're in dreamland if you think that's achievable in > > _every_ case. It probably works in some cases, though. > > Any Windows-logo-compliant firmware has to support changing the keys. Not necessarily, as I'm finding out with real hardware. My only options on the box I have is to either zero out all keys, or specifically tell the BIOS what binary to run (doesn't need to be signed, and can not be changed after telling the BIOS to use it.) I'm working with others to see if we can programatically add keys, which we should, and if so we will offer the code up to do so (it's published already, we are working on getting it signed by the needed Microsoft keys right now.) thanks, greg k-h
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 07:52:16PM -0500, Rich Freeman wrote: > On Sun, Dec 9, 2012 at 7:24 PM, Diego Elio Pettenò > wrote: > > On 09/12/2012 19:59, Greg KH wrote: > >> The UEFI spec does not allow that mode of operation in secure boot mode, > >> sorry. You will have to disable it in order to boot a Gentoo image, > >> which is fine, but there's no reason why Gentoo can't use the MS-signed > >> shim bootloader like all other distros are using, right? > > I thought I had read something in Google+ posted by somebody who > mentioned that their firmware was doing exactly that. It may very > well be prohibited by the spec though, in which case we shouldn't > count on it. I have not seen that at all, any pointers? Based on my interactions with the UEFI group, and Microsoft, that's either a bug that will be fixed up, or some misinformation. thanks, greg k-h
Re: [gentoo-dev] borked release media
On Mon, Dec 10, 2012 at 01:24:53AM +0100, Diego Elio Pettenò wrote: > On 09/12/2012 19:59, Greg KH wrote: > > The UEFI spec does not allow that mode of operation in secure boot mode, > > sorry. You will have to disable it in order to boot a Gentoo image, > > which is fine, but there's no reason why Gentoo can't use the MS-signed > > shim bootloader like all other distros are using, right? > > I wouldn't say we have any problem with that. Fabio already got Sabayon > to support the shim. The only problem is that we'd have to provide a > shim binary that _is_ signed, rather than building it from source, but I > don't see it as a mayor problem myself. I see the shim is checked into Sabayon, with my recent testing on real hardware, I think there's a bug in the existing shim binary that will keep it from working on most hardware, so it will need to be updated. Some of us are currently working with Microsoft to do that right now... But, if you have access to UEFI secure boot hardware, please test, it might work for you and if so, please let us know. thanks, greg k-h
Re: [gentoo-dev] borked release media
On Sun, Dec 9, 2012 at 7:57 PM, Diego Elio Pettenò wrote: > On 10/12/2012 01:52, Rich Freeman wrote: >> The shim might work, but I'd hardly call it "secure boot" if every >> motherboard manufacturer and OEM in the world has the ability to sign >> things, even if MS vouched for them all. Even if I installed Windows >> I'd want the ability to re-sign it with a key I controlled and tell >> the firmware to refuse to boot the MS key. > > I don't think it's Gentoo's place to do that kind of stuff especially > since I think you're in dreamland if you think that's achievable in > _every_ case. It probably works in some cases, though. Any Windows-logo-compliant firmware has to support changing the keys. I have no idea whether Windows itself supports this, but that really isn't our concern. In any case, nobody is forcing anybody to build in that support - I just think it is a good idea. I doubt it would be difficult to accomplish - it just requires signing the bootloader. But, if nobody wants to do it now I'll just deal with it when I buy something with UEFI firmware in a year or two. :) > >> Oh, and for anybody who is really daring - you can have that kind of >> security even without UEFI. Just use Trusted Grub and enable TPM >> support in Linux, and then encrypt all but the boot partition with a >> key stored in the TPM that it only yields when the boot path is >> validated. > > From the comments I read from Matthew Garrett, this looks like it's > going to be a world full of pain. Again I don't think we have to go there. Wasn't really suggesting that we go there - only that anybody who wants to do it is welcome to do so. There are even howtos floating around. I wasn't suggesting that Gentoo support TPM-based full-disk encryption - just UEFI. Rich
Re: [gentoo-dev] borked release media
Chí-Thanh Christopher Nguyễn wrote: > >> # isohybrid image.ISO > > > > Please send a patch to the gentoo-catalyst@ list which adds this as > > an optional step in the catalyst livecd2 target in a nice way, and > > file a bug with updated ebuilds for catalyst which add the dependency. > > Bug was already reported some time ago > https://bugs.gentoo.org/show_bug.cgi?id=251719 That bug doesn't complete the more important action item. It's nice that the isolinux cdtars include isohybrid, but please do patch livecd2 in a nice way to also use it. (Note, I don't know what would be nice, I haven't used catalyst for livecds.) //Peter
Re: [gentoo-dev] borked release media
On 10/12/2012 01:52, Rich Freeman wrote: > The shim might work, but I'd hardly call it "secure boot" if every > motherboard manufacturer and OEM in the world has the ability to sign > things, even if MS vouched for them all. Even if I installed Windows > I'd want the ability to re-sign it with a key I controlled and tell > the firmware to refuse to boot the MS key. I don't think it's Gentoo's place to do that kind of stuff especially since I think you're in dreamland if you think that's achievable in _every_ case. It probably works in some cases, though. > Oh, and for anybody who is really daring - you can have that kind of > security even without UEFI. Just use Trusted Grub and enable TPM > support in Linux, and then encrypt all but the boot partition with a > key stored in the TPM that it only yields when the boot path is > validated. >From the comments I read from Matthew Garrett, this looks like it's going to be a world full of pain. Again I don't think we have to go there. Also the title of the threads is now completely misleading so let's stop here, k? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] borked release media
On Sun, Dec 9, 2012 at 7:24 PM, Diego Elio Pettenò wrote: > On 09/12/2012 19:59, Greg KH wrote: >> The UEFI spec does not allow that mode of operation in secure boot mode, >> sorry. You will have to disable it in order to boot a Gentoo image, >> which is fine, but there's no reason why Gentoo can't use the MS-signed >> shim bootloader like all other distros are using, right? I thought I had read something in Google+ posted by somebody who mentioned that their firmware was doing exactly that. It may very well be prohibited by the spec though, in which case we shouldn't count on it. > > I wouldn't say we have any problem with that. Fabio already got Sabayon > to support the shim. The only problem is that we'd have to provide a > shim binary that _is_ signed, rather than building it from source, but I > don't see it as a mayor problem myself. Agreed. We don't need to make our own shim either - we can just use one of the ones floating around. It should be open source, though obviously if anybody wants to build their own they'll need to get MS to sign it, or install the key in their firmware. I really would like Gentoo to support a self-signed secure boot framework (obviously this would be for after the system is installed). The shim might work, but I'd hardly call it "secure boot" if every motherboard manufacturer and OEM in the world has the ability to sign things, even if MS vouched for them all. Even if I installed Windows I'd want the ability to re-sign it with a key I controlled and tell the firmware to refuse to boot the MS key. But, we can learn to walk before we learn to run - anything that works with UEFI is a good first step. Oh, and for anybody who is really daring - you can have that kind of security even without UEFI. Just use Trusted Grub and enable TPM support in Linux, and then encrypt all but the boot partition with a key stored in the TPM that it only yields when the boot path is validated. Probably wouldn't hurt to stick a copy of the key on a flash drive or something just in case you update your kernel and forget to update the TPM. Rich
Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
Brian Dolbec wrote: > > > remove entries in profiles/updates for tree-cleaned packages... > > > > What's the advantage of doing that? > > None .. > FYI... Currently there are updates files in profiles/updates/ > dating back to 2004 Do they take up significant storage space or transfer time, compared to the rest of the tree? If not, I can't think of a reason to remove them. //Peter pgpwXGARYACGA.pgp Description: PGP signature
Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
On Sun, 2012-12-09 at 15:10 -0800, "Paweł Hajdan, Jr." wrote: > On 12/9/12 1:17 PM, Brian Dolbec wrote: > > Starting from a question by Markos in #gentoo-portage about whether to > > remove entries in profiles/updates for tree-cleaned packages... > > What's the advantage of doing that? None, it actually could make it more difficult for a user to know why his old installed pkg isn't available. It was just what started the discussion about cleaning the old updates. Zac suggested this thread for opinions... ... [12:46] dol-sen: you should take a poll on the gentoo-dev ml to see how long people think we should keep them ... [12:47] yeah, seems like it's good to end-of-life them at some point > > > I propose that we say, once a year, schedule a tree-cleaning of old > > updates files. These updates files could be added to a tarball made > > available for download. That way if they are needed to update a system > > older than what the main tree has been tree-cleaned to. They can then be > > manually downloaded, extracted to the normal location and then run the > > "fixpackages" command. > > I think that complicates the process. :-/ But maybe the advantages > outweigh that. > It does make updating an ancient system slightly more difficult. But that would be the least of the user's troubles compared to some of the pkg updates, tinderbox downloads and manual unpacks that have been needed to be done. But on the other hand how long should we keep that stale info in the tree? See below :) > > The main question here is what is a reasonable length of time to keep > > the updates actively in-tree? > > > > -- From my experience in the forums, I think any updates older than > > 4 years should be subject to tree-cleaning. > > Yeah, 4 years is ancient and would probably be non-trivial to update anyway. yup, they are > > > -- Most old systems that have been updated tend to be less than that, > > probably about 2 years. > > 2 years seem reasonable. > That works too. FYI... Currently there are updates files in profiles/updates/ dating back to 2004 -- Brian Dolbec signature.asc Description: This is a digitally signed message part
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-12-09 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-12-09 23h59 UTC. Removals: dev-haskell/hdoc2012-12-06 22:57:06 slyfox kde-base/dragonplayer 2012-12-08 12:15:36 dilfridge kde-base/kbattleship2012-12-08 12:16:00 dilfridge kde-base/kdeaccounts-plugin 2012-12-08 12:16:36 dilfridge kde-base/kdemultimedia-kioslaves2012-12-08 12:17:02 dilfridge kde-base/ktron 2012-12-08 12:17:35 dilfridge media-sound/xfi-drivers 2012-12-09 11:07:52 moult Additions: dev-libs/gtx2012-12-03 11:33:17 jlec dev-perl/Roman 2012-12-03 19:52:24 pinkbyte media-plugins/gst-plugins-vpx 2012-12-03 23:57:14 eva sec-policy/selinux-dirsrv 2012-12-04 19:42:05 swift dev-util/kdevelop-python2012-12-04 19:49:44 dastergon dev-libs/bitset 2012-12-05 03:58:24 pinkbyte media-plugins/gst-plugins-libav 2012-12-05 07:57:36 eva media-plugins/gst-plugins-voaacenc 2012-12-05 08:01:10 eva media-plugins/gst-plugins-voamrwbenc2012-12-05 08:04:30 eva sci-mathematics/kodkod 2012-12-05 10:41:32 gienah sci-mathematics/kodkodi 2012-12-05 10:44:14 gienah dev-python/casuarius2012-12-06 18:12:11 bicatali dev-python/encore 2012-12-06 18:24:08 bicatali net-misc/ptunnel2012-12-06 20:05:10 dastergon dev-python/pyml 2012-12-06 20:32:34 bicatali dev-python/enaml2012-12-06 21:42:03 bicatali dev-libs/nanomsg2012-12-07 05:12:49 patrick dev-perl/Text-Format2012-12-07 07:27:40 pinkbyte app-admin/logstalgia2012-12-07 09:08:26 pinkbyte media-libs/jbig2enc 2012-12-07 20:25:44 pinkbyte media-plugins/gst-plugins-libnice 2012-12-08 00:05:50 tetromino sci-mathematics/sha1-polyml 2012-12-08 08:05:32 gienah sys-fs/eudev2012-12-09 03:50:07 ryao media-libs/cimg 2012-12-09 09:31:47 hwoarang media-gfx/photivo 2012-12-09 12:16:37 hwoarang dev-perl/MooX-Types-MooseLike 2012-12-09 17:09:28 tove media-plugins/gst-plugins-opus 2012-12-09 18:21:52 tetromino app-laptop/tpacpi-bat 2012-12-09 21:29:30 ottxor dev-util/cwdiff 2012-12-09 21:42:40 ottxor dev-lang/teyjus 2012-12-09 21:57:06 gienah sci-mathematics/twelf 2012-12-09 23:02:17 gienah net-wireless/b43legacy-firmware 2012-12-09 23:44:47 zerochaos -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-haskell/hdoc,removed,slyfox,2012-12-06 22:57:06 kde-base/dragonplayer,removed,dilfridge,2012-12-08 12:15:36 kde-base/kbattleship,removed,dilfridge,2012-12-08 12:16:00 kde-base/kdeaccounts-plugin,removed,dilfridge,2012-12-08 12:16:36 kde-base/kdemultimedia-kioslaves,removed,dilfridge,2012-12-08 12:17:02 kde-base/ktron,removed,dilfridge,2012-12-08 12:17:35 media-sound/xfi-drivers,removed,moult,2012-12-09 11:07:52 Added Packages: dev-libs/gtx,added,jlec,2012-12-03 11:33:17 dev-perl/Roman,added,pinkbyte,2012-12-03 19:52:24 media-plugins/gst-plugins-vpx,added,eva,2012-12-03 23:57:14 sec-policy/selinux-dirsrv,added,swift,2012-12-04 19:42:05 dev-util/kdevelop-python,added,dastergon,2012-12-04 19:49:44 dev-libs/bitset,added,pinkbyte,2012-12-05 03:58:24 media-plugins/gst-plugins-libav,added,eva,2012-12-05 07:57:36 media-plugins/gst-plugins-voaacenc,added,eva,2012-12-05 08:01:10 media-plugins/gst-plugins-voamrwbenc,added,eva,2012-12-05 08:04:30 sci-mathematics/kodkod,added,gienah,2012-12-05 10:41:32 sci-mathematics/kodkodi,added,gienah,2012-12-05 10:44:14 dev-python/casuarius,added,bicatali,2012-12-06 18:12:11 dev-python/encore,added,bicatali,2012-12-06 18:24:08 net-misc/ptunnel,added,dastergon,2012-12-06 20:05:10 dev-python/pyml,added,bicatali,2012-12-06 20:32:34 dev-python/enaml,added,bicatali,2012-12-06 21:42:03 dev-libs/nanomsg,added,patrick,2012-12-07 05:12:49 dev-perl/Text-Format,added,pinkbyte,2012-12-07 07:27:40 app-admin/logstalgia,added,pinkbyte,2012-12-07 09:08:26 media-libs/jbig2enc,added,pinkbyte,2012-12-07 20:25:44 media-plugins/gst-plugins-libnice,added,tetromino,2012-12-08 00:05:50 sci-mathematics/sha1-polyml,added,gienah,2012-12-08 08:05:32 sys-fs/eudev,added,ryao,2012-12-09 03:50:07 media-libs/cimg,added,hwoarang,2012-12-09 09:31:47 media-gfx/photivo,added,hwoarang,2012-12-09 12:16:37 dev-perl/MooX-Types-MooseLike,added,tove,2012-12-09 17:09:
Re: [gentoo-dev] borked release media
On 09/12/2012 19:59, Greg KH wrote: > The UEFI spec does not allow that mode of operation in secure boot mode, > sorry. You will have to disable it in order to boot a Gentoo image, > which is fine, but there's no reason why Gentoo can't use the MS-signed > shim bootloader like all other distros are using, right? I wouldn't say we have any problem with that. Fabio already got Sabayon to support the shim. The only problem is that we'd have to provide a shim binary that _is_ signed, rather than building it from source, but I don't see it as a mayor problem myself. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] borked release media
likewhoa schrieb: > interesting and probably something we can get away with since not all > users actually touch the kernel line but some do so it might not be a > smart option to disable kernel parameters on UEFI only systems. The kernel parameters are not disabled, they just have to be specified at build time instead of runtime. With a customized kernel you typically set CONFIG_CMDLINE="root=PARTUUID=..." or similar. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] borked release media
Greg KH schrieb: >> No, all we need is to enable EFI stub support in the kernel, and >> integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in >> some location where UEFI looks for it (/efi/boot/bootx64.efi). >> >> This has the disadvantage of not allowing to pass additional kernel >> parameters during boot. But it might still be an acceptable stopgap >> measure if the alternative is to not boot at all. > > No, don't do that for an "install" kernel, that way is madness, just use > a real UEFI bootloader which can handle an initrd and the like properly Can you explain what problems you see with that? How does CONFIG_INITRAMFS_SOURCE handle initrd improperly? > Only boot a kernel directly from UEFI if you build your own and have > customized it for your hardware. I booted genkernel generated non-customized kernels as well as customized hand-configured kernels using that method. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
On 12/9/12 1:17 PM, Brian Dolbec wrote: > Starting from a question by Markos in #gentoo-portage about whether to > remove entries in profiles/updates for tree-cleaned packages... What's the advantage of doing that? > I propose that we say, once a year, schedule a tree-cleaning of old > updates files. These updates files could be added to a tarball made > available for download. That way if they are needed to update a system > older than what the main tree has been tree-cleaned to. They can then be > manually downloaded, extracted to the normal location and then run the > "fixpackages" command. I think that complicates the process. :-/ But maybe the advantages outweigh that. > The main question here is what is a reasonable length of time to keep > the updates actively in-tree? > > -- From my experience in the forums, I think any updates older than > 4 years should be subject to tree-cleaning. Yeah, 4 years is ancient and would probably be non-trivial to update anyway. > -- Most old systems that have been updated tend to be less than that, > probably about 2 years. 2 years seem reasonable. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
Starting from a question by Markos in #gentoo-portage about whether to remove entries in profiles/updates for tree-cleaned packages... I propose that we say, once a year, schedule a tree-cleaning of old updates files. These updates files could be added to a tarball made available for download. That way if they are needed to update a system older than what the main tree has been tree-cleaned to. They can then be manually downloaded, extracted to the normal location and then run the "fixpackages" command. The main question here is what is a reasonable length of time to keep the updates actively in-tree? -- From my experience in the forums, I think any updates older than 4 years should be subject to tree-cleaning. -- Most old systems that have been updated tend to be less than that, probably about 2 years. This should allow a reasonable amount of time for a user to update an old system. Thoughts? -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] borked release media
On 12/09/2012 01:46 PM, Chí-Thanh Christopher Nguyễn wrote: > Fernando Reyes schrieb: >> That's what meant since we use isolinux on the release media and until >> syslinux-6 we are forced to use another bootloader and grub seems out of the >> questions because of licensing issues. I will test new syslinux soon and see >> how isohybrid and isolinux plau together on an EFI bios. > No, all we need is to enable EFI stub support in the kernel, and > integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in > some location where UEFI looks for it (/efi/boot/bootx64.efi). > > This has the disadvantage of not allowing to pass additional kernel > parameters during boot. But it might still be an acceptable stopgap > measure if the alternative is to not boot at all. > > > Best regards, > Chí-Thanh Christopher Nguyễn > > interesting and probably something we can get away with since not all users actually touch the kernel line but some do so it might not be a smart option to disable kernel parameters on UEFI only systems.
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 01:35:57PM -0500, Rich Freeman wrote: > On Sun, Dec 9, 2012 at 1:24 PM, Greg KH wrote: > > > > The FSF has already said that using Grub2 and the GPLv3 is just fine > > with the UEFI method of booting, so there is no problem from that side. > > There's a statement about this somewhere on their site if you are > > curious. > > > > The only one objecting to GPLv3 and UEFI is the current rules for > > getting a shim/bootloader signed by Microsoft, but the current > > implementations we have all have either a GPLv2 or BSD licensed shim > > which then loads GRUB, so all is fine from a licensing and legal > > standpoint from everyone involved. > > Makes sense to me, thanks. > > An MS-signed bootloader isn't nearly as critical for Gentoo as it is > for other distros - we're not really aiming for the > stick-a-CD-in-and-you're-done crowd. If somebody can partition their > drive, build and install a kernel and grub, configure make.conf, and > build a system, then I'm not too concerned that they have to run some > script to generate a key, sign their bootloader, and register that key > with their firmware, or disable secure boot just to boot the install > CD (though it sounds like some firmwares just pop up a warning and let > you proceed, which is what my Chromebook does in dev mode). The UEFI spec does not allow that mode of operation in secure boot mode, sorry. You will have to disable it in order to boot a Gentoo image, which is fine, but there's no reason why Gentoo can't use the MS-signed shim bootloader like all other distros are using, right? thanks, greg k-h
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 07:46:59PM +0100, Chí-Thanh Christopher Nguyễn wrote: > Fernando Reyes schrieb: > > That's what meant since we use isolinux on the release media and until > > syslinux-6 we are forced to use another bootloader and grub seems out of > > the questions because of licensing issues. I will test new syslinux soon > > and see how isohybrid and isolinux plau together on an EFI bios. > > No, all we need is to enable EFI stub support in the kernel, and > integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in > some location where UEFI looks for it (/efi/boot/bootx64.efi). > > This has the disadvantage of not allowing to pass additional kernel > parameters during boot. But it might still be an acceptable stopgap > measure if the alternative is to not boot at all. No, don't do that for an "install" kernel, that way is madness, just use a real UEFI bootloader which can handle an initrd and the like properly (like gummiboot, which arch is using for their UEFI bootloader, and I've been using for months quite successfully.) Only boot a kernel directly from UEFI if you build your own and have customized it for your hardware. Some bioses will let you do this in secure boot mode without having to sign anything, I took a video of this on Friday showing how easy it can be: https://plus.google.com/u/0/111049168280159033135/posts/81V5oyzwK63 thanks, greg k-h
Re: [gentoo-dev] borked release media
Then let's get UEFI support on our release media and out the box usb booting so users don't have to go boot other livecds. likewhoa Greg KH wrote: >On Sun, Dec 09, 2012 at 01:13:38PM -0500, Rich Freeman wrote: >> On Sun, Dec 9, 2012 at 1:07 PM, Fernando Reyes >> wrote: >> > I don't know the details of the issue but I know that I was prevented from >> > using grub on the livedvd. >> >> Well, if some perceived legal constraint is keeping us from doing >> whatever seems to be technically most appropriate we should >> investigate the matter and resolve it. If, on the other hand, it >> simply makes sense to use something else, then no sense belaboring the >> point. >> >> People just seem to be really paranoid about GPLv3 and Grub. We're >> already talking to the FSF about how they handle copyright attribution >> on their own projects, so I suppose we could get their opinion on UEFI >> as well. However, I don't see anything in the language of the license >> that creates a problem when using it with UEFI, unless one wants to >> sell locked-down hardware. Doing that would be a violation of our >> social contract, let alone the GPLv3. > >The FSF has already said that using Grub2 and the GPLv3 is just fine >with the UEFI method of booting, so there is no problem from that side. >There's a statement about this somewhere on their site if you are >curious. > >The only one objecting to GPLv3 and UEFI is the current rules for >getting a shim/bootloader signed by Microsoft, but the current >implementations we have all have either a GPLv2 or BSD licensed shim >which then loads GRUB, so all is fine from a licensing and legal >standpoint from everyone involved. > >Hope this helps, > >greg k-h >
Re: [gentoo-dev] borked release media
Fernando Reyes schrieb: > That's what meant since we use isolinux on the release media and until > syslinux-6 we are forced to use another bootloader and grub seems out of the > questions because of licensing issues. I will test new syslinux soon and see > how isohybrid and isolinux plau together on an EFI bios. No, all we need is to enable EFI stub support in the kernel, and integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in some location where UEFI looks for it (/efi/boot/bootx64.efi). This has the disadvantage of not allowing to pass additional kernel parameters during boot. But it might still be an acceptable stopgap measure if the alternative is to not boot at all. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] borked release media
On Sun, Dec 9, 2012 at 1:24 PM, Greg KH wrote: > > The FSF has already said that using Grub2 and the GPLv3 is just fine > with the UEFI method of booting, so there is no problem from that side. > There's a statement about this somewhere on their site if you are > curious. > > The only one objecting to GPLv3 and UEFI is the current rules for > getting a shim/bootloader signed by Microsoft, but the current > implementations we have all have either a GPLv2 or BSD licensed shim > which then loads GRUB, so all is fine from a licensing and legal > standpoint from everyone involved. Makes sense to me, thanks. An MS-signed bootloader isn't nearly as critical for Gentoo as it is for other distros - we're not really aiming for the stick-a-CD-in-and-you're-done crowd. If somebody can partition their drive, build and install a kernel and grub, configure make.conf, and build a system, then I'm not too concerned that they have to run some script to generate a key, sign their bootloader, and register that key with their firmware, or disable secure boot just to boot the install CD (though it sounds like some firmwares just pop up a warning and let you proceed, which is what my Chromebook does in dev mode). Rich
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 01:13:38PM -0500, Rich Freeman wrote: > On Sun, Dec 9, 2012 at 1:07 PM, Fernando Reyes > wrote: > > I don't know the details of the issue but I know that I was prevented from > > using grub on the livedvd. > > Well, if some perceived legal constraint is keeping us from doing > whatever seems to be technically most appropriate we should > investigate the matter and resolve it. If, on the other hand, it > simply makes sense to use something else, then no sense belaboring the > point. > > People just seem to be really paranoid about GPLv3 and Grub. We're > already talking to the FSF about how they handle copyright attribution > on their own projects, so I suppose we could get their opinion on UEFI > as well. However, I don't see anything in the language of the license > that creates a problem when using it with UEFI, unless one wants to > sell locked-down hardware. Doing that would be a violation of our > social contract, let alone the GPLv3. The FSF has already said that using Grub2 and the GPLv3 is just fine with the UEFI method of booting, so there is no problem from that side. There's a statement about this somewhere on their site if you are curious. The only one objecting to GPLv3 and UEFI is the current rules for getting a shim/bootloader signed by Microsoft, but the current implementations we have all have either a GPLv2 or BSD licensed shim which then loads GRUB, so all is fine from a licensing and legal standpoint from everyone involved. Hope this helps, greg k-h
Re: [gentoo-dev] borked release media
On Sun, Dec 9, 2012 at 1:07 PM, Fernando Reyes wrote: > I don't know the details of the issue but I know that I was prevented from > using grub on the livedvd. Well, if some perceived legal constraint is keeping us from doing whatever seems to be technically most appropriate we should investigate the matter and resolve it. If, on the other hand, it simply makes sense to use something else, then no sense belaboring the point. People just seem to be really paranoid about GPLv3 and Grub. We're already talking to the FSF about how they handle copyright attribution on their own projects, so I suppose we could get their opinion on UEFI as well. However, I don't see anything in the language of the license that creates a problem when using it with UEFI, unless one wants to sell locked-down hardware. Doing that would be a violation of our social contract, let alone the GPLv3. Rich
Re: [gentoo-dev] borked release media
I don't know the details of the issue but I know that I was prevented from using grub on the livedvd. Rich Freeman wrote: >On Sun, Dec 9, 2012 at 12:23 PM, Fernando Reyes > wrote: >> grub seems out of the questions because of licensing issues. > >What licensing issues? Just distribute the source. If the Gentoo >Foundation goes into the hardware business and starts distributing >hardware that only boots Gentoo-signed grub bootloaders then we'll >have to distribute our private key. Or we could just be intelligent >and not distribute hardware that only boots Gentoo-signed grub >bootloaders. > >For some reason everybody goes nuts over UEFI and GPLv3. The license >isn't any more unclear about that than anything else that people go >nuts over the GPL about. > >GPLv3 states: >If you convey an object code work under this section in, or with, or >specifically for use in, a User Product, and the conveying occurs as >part of a transaction in which the right of possession and use of the >User Product is transferred to the recipient in perpetuity or for a >fixed term (regardless of how the transaction is characterized), the >Corresponding Source conveyed under this section must be accompanied >by the Installation Information. > >You only need to provide installation information if "the conveying >occurs as part of a transaction in which the right of possession and >use of the User Product is transferred to the recipient in perpetuity >or for a fixed term." So, as long as Gentoo doesn't distribute >hardware, we aren't bound by that clause. > >If somebody else distributes hardware that only boots Gentoo-signed >GRUB bootloaders then they'll need to distribute the Gentoo private >keys along with them or they can be sued by the Grub copyright >holders. If they ask us for said keys we'll just say no, and they can >fight it out with the FSF. We aren't the ones distributing Grub out >of compliance, so we haven't violated the license. > >If somebody has a specific licensing-related concern we can always >have the Foundation/ licensing team look into it, as we are already >doing with the copyright attribution question. > >Rich >
Re: [gentoo-dev] borked release media
On Sun, Dec 9, 2012 at 12:23 PM, Fernando Reyes wrote: > grub seems out of the questions because of licensing issues. What licensing issues? Just distribute the source. If the Gentoo Foundation goes into the hardware business and starts distributing hardware that only boots Gentoo-signed grub bootloaders then we'll have to distribute our private key. Or we could just be intelligent and not distribute hardware that only boots Gentoo-signed grub bootloaders. For some reason everybody goes nuts over UEFI and GPLv3. The license isn't any more unclear about that than anything else that people go nuts over the GPL about. GPLv3 states: If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. You only need to provide installation information if "the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term." So, as long as Gentoo doesn't distribute hardware, we aren't bound by that clause. If somebody else distributes hardware that only boots Gentoo-signed GRUB bootloaders then they'll need to distribute the Gentoo private keys along with them or they can be sued by the Grub copyright holders. If they ask us for said keys we'll just say no, and they can fight it out with the FSF. We aren't the ones distributing Grub out of compliance, so we haven't violated the license. If somebody has a specific licensing-related concern we can always have the Foundation/ licensing team look into it, as we are already doing with the copyright attribution question. Rich
Re: [gentoo-dev] borked release media
That's what meant since we use isolinux on the release media and until syslinux-6 we are forced to use another bootloader and grub seems out of the questions because of licensing issues. I will test new syslinux soon and see how isohybrid and isolinux plau together on an EFI bios. Chí-Thanh Christopher Nguyễn wrote: >Fernando Reyes schrieb: >> The problem with the isohybrid approach is that it doesn't support UEFI >> booting and this is why I wouldn't recommended as a feature in catalyst. >> However, this should be documented somewhere so that users know its possible >> without having to follow the liveusb guide which is probably outdated by >> today's standards. > >isohybrid works with UEFI by passing --uefi option. This requires a UEFI >bootable image (such as a UEFI capable boot loader or kernel with EFI >stub support) to be present. > >Starting with syslinux-6.00 it will be possible to boot UEFI systems in >EFI mode. Until then, one of the other boot loaders (rEFIt, GRUB 2, >ELILO) might be used. > > >Best regards, >Chí-Thanh Christopher Nguyễn > >
Re: [gentoo-dev] borked release media
Fernando Reyes schrieb: > The problem with the isohybrid approach is that it doesn't support UEFI > booting and this is why I wouldn't recommended as a feature in catalyst. > However, this should be documented somewhere so that users know its possible > without having to follow the liveusb guide which is probably outdated by > today's standards. isohybrid works with UEFI by passing --uefi option. This requires a UEFI bootable image (such as a UEFI capable boot loader or kernel with EFI stub support) to be present. Starting with syslinux-6.00 it will be possible to boot UEFI systems in EFI mode. Until then, one of the other boot loaders (rEFIt, GRUB 2, ELILO) might be used. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] borked release media
Peter Stuge schrieb: > Fernando Reyes wrote: >> iirc the minimal install CD ISO is capable of booting from a USB device or >> any removable media by just running the following commands. >> >> # isohybrid image.ISO > Please send a patch to the gentoo-catalyst@ list which adds this as > an optional step in the catalyst livecd2 target in a nice way, and > file a bug with updated ebuilds for catalyst which add the dependency. Bug was already reported some time ago https://bugs.gentoo.org/show_bug.cgi?id=251719 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On Sat, Dec 08, 2012 at 08:10:32PM -0500, Rich Freeman wrote: > Uh, does emerge-webrsync have some kind of automagical detection of > the fact that you're building a chroot? I would think that it would > sync /usr/portage, and not /mnt/gentoo/usr/portage. Perhaps you > should move that down into the chroot section, and mkdir /usr/portage > if that is needed? Crap. Indeed, section moved towards the place where we optionally recommend "emerge --sync", and put in an mkdir /usr/portage. Wkr, Sven Vermeulen
Re: [gentoo-dev] borked release media
On Sun, Dec 9, 2012 at 11:18 AM, Markos Chandras wrote: > I think it is possible to use the unetbootin utility to make the > minimal iso image boot from a USB flash disk. Just make the real thing… https://github.com/mkdesu/liberte/blob/master/src/root/mkimage -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] borked release media
On 9 December 2012 05:04, Peter Stuge wrote: > Fernando Reyes wrote: >> iirc the minimal install CD ISO is capable of booting from a USB device or >> any removable media by just running the following commands. >> >> # isohybrid image.ISO > > Please send a patch to the gentoo-catalyst@ list which adds this as > an optional step in the catalyst livecd2 target in a nice way, and > file a bug with updated ebuilds for catalyst which add the dependency. > > Many thanks! > > > //Peter > I think it is possible to use the unetbootin utility to make the minimal iso image boot from a USB flash disk. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
[gentoo-dev] [PATCH] Support recursive DOCS in EAPI 4.
Fixes: https://bugs.gentoo.org/show_bug.cgi?id=398147
---
gx86/eclass/autotools-utils.eclass | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gx86/eclass/autotools-utils.eclass
b/gx86/eclass/autotools-utils.eclass
index 7bdc5d6..a03abb5 100644
--- a/gx86/eclass/autotools-utils.eclass
+++ b/gx86/eclass/autotools-utils.eclass
@@ -485,7 +485,11 @@ autotools-utils_src_install() {
# XXX: support installing them from builddir as well?
if [[ ${DOCS} ]]; then
- dodoc "${DOCS[@]}" || die "dodoc failed"
+ if [[ ${EAPI} == [23] ]]; then
+ dodoc "${DOCS[@]}" || die
+ else
+ dodoc -r "${DOCS[@]}" || die
+ fi
else
local f
# same list as in PMS
--
1.8.0
