Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
> On Mon, 10 Dec 2012, Sergei Trofimovich wrote: > gentoo-x86/profiles/updates $ LANG=C ls -1 --sort=time > [long list omitted] > 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) It's worse: Bad entries in the old files may go unnoticed for a long time. But if such a file is updated for whatever reason, it will be reprocessed on users' systems, including any bad entries contained in it. > Thus the reason for removal is simple: old entries are potentially > buggy as nobody verifies them. I wouldn't even know how to verify them. Let's remove that cruft. We can be extra conservative and keep five years of backlog (i.e. everything from before 2008 would be removed now). Ulrich
[gentoo-dev] Packages up for grabs
Due to limited time and resources these packages are up for grabs: - app-shells/shish - dev-db/mysqltuner - dev-libs/dietlibc - dev-libs/gecode - net-analyzer/bwm-ng - net-analyzer/nagios-check_mysql_health These packages have been reduced to herd maintainers: - media-libs/libraw - media-libs/gexiv2
Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
On 12/10/2012 12:10 AM, "Paweł Hajdan, Jr." wrote:
>> 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.
For the records:
We do have some Gentoo box serving as VirtualBox host here, installed in early
2010,
not updated since then, with an uptime of 836 days right now. It is subject to
upgrade,
but there may come another year until that to happen ("never change a running
system").
Although I do not expect the update to be trivial, keeping things like pkgmove
for at
least 4 years sounds reasonable.
/haubi/
Re: [gentoo-dev] borked release media
Greg KH schrieb: > 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? Yes, it works here. This is the kernel which I used to boot my development box at work (including genkernel initramfs for mdraid+luks+lvm): http://dev.gentoo.org/~chithanh/efi/boot/bootx64.efi It has hardcoded crypt_root and real_root via CONFIG_CMDLINE, and initramfs executables are built with -march=bdver2 so this particular file will probably not be useful to many people. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] borked release media
On Mon, Dec 10, 2012 at 2:52 AM, Rich Freeman wrote: > I really would like Gentoo to support a self-signed secure boot > framework (obviously this would be for after the system is installed). https://bugs.gentoo.org/show_bug.cgi?id=444830 You can see how such framework works by booting Liberté Linux 2012.3 on a machine with Secure Boot. Just extract the .zip file into USB key root (or burn the .iso to CD), and import EFI/Liberte-SecureBoot-CA.der certificate in UEFI Secure Boot interface: http://dee.su/liberte-install (see “Secure Boot” section). > 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. I think there are some popular misunderstanding about the purpose of shim. What shim essentially allows a user to do is to enroll custom certificates into Secure Boot databases in an interactive, user-friendly fashion (caveat emptor: I didn't try shim yet). It does some clever UEFI API interaction and management of certificates in protected variables, but the effect is identical to enrolling a certificate into DB or KEK (OVMF names) via UEFI interface. Being signed by MS is just a technical way to achieve that user friendliness. So personally, I don't think that rushing to support shim in Gentoo is that critical, since users can be expected to enroll certificates by themselves. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] borked release media
On Sat, Dec 08, 2012 at 11:57:13PM -0500, 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 > # did if=image.ISO of=/dev/sdb bs=8192k > > sdb being your removable device. Also keep in mind that any data on > sdb will be wiped after running the dd command. Thanks. Much easier than the instructions on the Gentoo wiki. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 06:37:56PM -0800, Greg KH wrote > 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.) Howsabout the binary being Matthew Garret's chainloader shim as per http://mjg59.dreamwidth.org/20303.html > 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.) He's already done the heavy lifting. Aren't you re-inventing the wheel? -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] borked release media
On Mon, Dec 10, 2012 at 10:31:25AM -0500, Walter Dnes wrote: > On Sun, Dec 09, 2012 at 06:37:56PM -0800, Greg KH wrote > > > 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.) > > Howsabout the binary being Matthew Garret's chainloader shim as per > http://mjg59.dreamwidth.org/20303.html That's a nice one, but note my previous comment about a bug in it at the moment that prevents it from working on some hardware. It's also a valid solution for some implementations, have you tried it yourself? > > 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.) > > He's already done the heavy lifting. Aren't you re-inventing the > wheel? Not at all, we are sharing the same code base here, just two different frontend implementations that do different things, with the same crypto backend and local (MOK) key checking functionality, which was done by SUSE. Matthew's frontend "shim" code is nice and tiny, but the one I am referring to provides the ability to enroll your own keys in the BIOS, which shim does not. Don't worry, we are all working together here, it's not like there is a ton of people involved :) greg "there is no cabal" k-h
Re: [gentoo-dev] borked release media
On Mon, Dec 10, 2012 at 8:36 PM, Greg KH wrote: > Matthew's frontend "shim" code is nice and tiny, but the one I am > referring to provides the ability to enroll your own keys in the BIOS, > which shim does not. I just tried shim in OVMF, and it provides an interface to enroll keys / signatures. It works as advertised, even after enrolling “Microsoft Corporation UEFI CA 2011” certificate into UEFI (instead of shim.efi hash), which is supposedly trusted by vendors, but the keys and signatures are only visible to shim — as I understand, it keeps them in authenticated variables. I don't think the difference matters much to the user. By the way, shim's interface is not much prettier than the one provided by OVMF — I am a bit disappointed. :) -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
[gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
Hello, I think we're mostly aware what the use and benefits of the *use.stable.mask files are. They would be at least really useful in Python ebuilds, where we have to either: a) forcedly stabilize a particular Python implementation (like pypy), b) don't support it all, c) or just keep two package revisions around, one with 'stable' Python implementations for stabilization and the other with all implementations for testing users. Therefore, having *use.stable.mask would be at least helpful to us. But as far as I can see, the spec says we can use it only in profile dirs with EAPI 5... So far, I doubt anyone would want us to migrate our major profiles to a newer EAPI, like EAPI 4, not to mention fresh 5. And of course, that wouldn't follow our migration path practices. Therefore, I see the following solutions: 1) duplicate most of the major profiles. Make an EAPI 5-enabled wrapper profiles which will provide the *use.stable.mask files. Require users to migrate to those profiles after getting an EAPI 5 capable package manager (how?). Possibly mask the relevant flags completely in other profiles. 2) change the rules. Make *use.stable.mask files not require EAPI 5 profile dirs but apply only to EAPI 5 packages. The outcome is similar -- package managers without the feature ignore the ebuilds. If they have EAPI 5, they should be able to handle stable unmasking as well. Of course, it all falls apart because of package manager strictness. We may want to change that retroactively and quickly release updated package managers before the EAPI 5 support is spread wider (assuming some transitional period before we will start using the files), or defer it into EAPI 6. Either way, I believe that *use.stable.mask would be very helpful if we were able to use it. What are your thoughts? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/12/12 04:27 PM, Michał Górny wrote: > Hello, > > I think we're mostly aware what the use and benefits of the > *use.stable.mask files are. > > They would be at least really useful in Python ebuilds, where we > have to either: > > a) forcedly stabilize a particular Python implementation (like > pypy), > > b) don't support it all, > > c) or just keep two package revisions around, one with 'stable' > Python implementations for stabilization and the other with all > implementations for testing users. > > > Therefore, having *use.stable.mask would be at least helpful to us. > But as far as I can see, the spec says we can use it only in > profile dirs with EAPI 5... > > So far, I doubt anyone would want us to migrate our major profiles > to a newer EAPI, like EAPI 4, not to mention fresh 5. And of > course, that wouldn't follow our migration path practices. > > > Therefore, I see the following solutions: > > 1) duplicate most of the major profiles. Make an EAPI 5-enabled > wrapper profiles which will provide the *use.stable.mask files. > Require users to migrate to those profiles after getting an EAPI 5 > capable package manager (how?). Possibly mask the relevant flags > completely in other profiles. > > > 2) change the rules. Make *use.stable.mask files not require EAPI > 5 profile dirs but apply only to EAPI 5 packages. The outcome is > similar -- package managers without the feature ignore the ebuilds. > If they have EAPI 5, they should be able to handle stable unmasking > as well. > > Of course, it all falls apart because of package manager > strictness. We may want to change that retroactively and quickly > release updated package managers before the EAPI 5 support is > spread wider (assuming some transitional period before we will > start using the files), or defer it into EAPI 6. > > > Either way, I believe that *use.stable.mask would be very helpful > if we were able to use it. What are your thoughts? > I wonder how (2) would really differ from the current situation -- ie, if there's a use.stable.mask file in a profiles dir, and portage is too old to support it, doesn't it just get ignored? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDGk/4ACgkQ2ugaI38ACPBkogEAsqOBZBa1n63+dkd/mz7XzFzy XHoshXhY5kOMTMKz7NgBAI9JODGAp9VGlAZg2w7lOoAFTmvgQyElWY0AA/9Sn6h7 =rHGA -END PGP SIGNATURE-
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
On Mon, 10 Dec 2012 21:01:34 -0500 Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 10/12/12 04:27 PM, Michał Górny wrote: > > Hello, > > > > I think we're mostly aware what the use and benefits of the > > *use.stable.mask files are. > > > > They would be at least really useful in Python ebuilds, where we > > have to either: > > > > a) forcedly stabilize a particular Python implementation (like > > pypy), > > > > b) don't support it all, > > > > c) or just keep two package revisions around, one with 'stable' > > Python implementations for stabilization and the other with all > > implementations for testing users. > > > > > > Therefore, having *use.stable.mask would be at least helpful to us. > > But as far as I can see, the spec says we can use it only in > > profile dirs with EAPI 5... > > > > So far, I doubt anyone would want us to migrate our major profiles > > to a newer EAPI, like EAPI 4, not to mention fresh 5. And of > > course, that wouldn't follow our migration path practices. > > > > > > Therefore, I see the following solutions: > > > > 1) duplicate most of the major profiles. Make an EAPI 5-enabled > > wrapper profiles which will provide the *use.stable.mask files. > > Require users to migrate to those profiles after getting an EAPI 5 > > capable package manager (how?). Possibly mask the relevant flags > > completely in other profiles. > > > > > > 2) change the rules. Make *use.stable.mask files not require EAPI > > 5 profile dirs but apply only to EAPI 5 packages. The outcome is > > similar -- package managers without the feature ignore the ebuilds. > > If they have EAPI 5, they should be able to handle stable unmasking > > as well. > > > > Of course, it all falls apart because of package manager > > strictness. We may want to change that retroactively and quickly > > release updated package managers before the EAPI 5 support is > > spread wider (assuming some transitional period before we will > > start using the files), or defer it into EAPI 6. > > > > > > Either way, I believe that *use.stable.mask would be very helpful > > if we were able to use it. What are your thoughts? > > > > I wonder how (2) would really differ from the current situation -- ie, > if there's a use.stable.mask file in a profiles dir, and portage is > too old to support it, doesn't it just get ignored? Well, assuming the EAPI 5 support is applied at once, that portage version will ignore EAPI 5 packages as well, making the file therefore irrelevant. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
On 12/10/2012 01:27 PM, Michał Górny wrote: > 1) duplicate most of the major profiles. Make an EAPI 5-enabled wrapper > profiles which will provide the *use.stable.mask files. Require users > to migrate to those profiles after getting an EAPI 5 capable package > manager (how?). Possibly mask the relevant flags completely in other > profiles. I think this is the obvious solution. You can make users migrate by adding "deprecated" files to the old profiles. -- Thanks, Zac
