Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On Sat, 30 Jun 2012 13:01:52 -0700 Zac Medico wrote: > On 06/30/2012 12:42 PM, Ralph Sennhauser wrote: > > That might be neat, but it would already help if you had to add > > --allow-downgrades or similar to emerge in case Portage wants to > > downgrade one or more packages. > > Besides preventing an accidental downgrade it would raise the > > awareness of the problem. > > I think people would just put it in EMERGE_DEFAULT_OPTS and forget > about it, since downgrades are a fairly common occurrence, due to > changes in version numbering schemes or buggy versions being dropped > from the tree. Maybe a RESTRICT="downgrade" metadata setting would > help to reduce the noise so that people would be less likely to > enable --allow-downgrades by default. Nothing wrong with people putting --allow-downgrades into EMERGE_DEFAULT_OPTS if they choose to do so. At least people who'd like this protection could make use of it. Usually both upstream and maintainer put quite a bit of thought into an upgrade path but hardly the other way around. On a system with mixed keywords it's far more common to see downgrades because the unmasked version was removed before stable did catch up than pseudo downgrades because we have no epochs or alike. signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
Zac Medico wrote: > > I'd suggest a special ebuild phase to check for ABI changes, like > > the pre_pkg_preinst_abi_check phase suggested here: > > > > https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 > > I guess, that phase would detect ABI change and package manager > would know how to handle it by itself? > > > > Yeah, it would be like a warning system, > > > > And once we bump SLOT/ABI_SLOT, package manager would know about > > how to handle that situation and rebuild needed stuff? Is it unrealistic to assume that upstream ABI providers will mark their ABIs by using sonames correctly? Maybe that is at least the common case, then ABI_SLOT could be set automatically. Maybe I'm too far ahead, and baby steps are better. //Peter
[gentoo-dev] About tests needing internet connection to run
After reading: https://bugs.gentoo.org/show_bug.cgi?id=424719 https://bugs.gentoo.org/show_bug.cgi?id=397973 Looks like there is not consensus about how to handle this cases, probably a PROPERTIES variable for this would help :-/ Any ideas on this kind of issue? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Default hash algorithm for Manifest signing
On Fri, Jul 06, 2012 at 05:32:22PM +0200, Ulrich Mueller wrote: > Hi all, > ... > > However, I remember that there used to be some problems with SHA256 > and DSA keys. Before we add "--digest-algo SHA256" to the default > PORTAGE_GPG_SIGNING_COMMAND in make.globals, I'd like to ask for > feedback if it works without problems. So, could some volunteers > please add the following line to their make.conf: > ... > Just committed some stuff with the proposed line in my make.conf. Everything fine here. Regards. pgpkojHZR3I9o.pgp Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/07/12 07:29 AM, Peter Stuge wrote: > Zac Medico wrote: >>> I'd suggest a special ebuild phase to check for ABI >>> changes, like the pre_pkg_preinst_abi_check phase >>> suggested here: >>> >>> https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 >> >> I guess, that phase would detect ABI change and package >> manager would know how to handle it by itself? >>> >>> Yeah, it would be like a warning system, >>> >>> And once we bump SLOT/ABI_SLOT, package manager would know >>> about how to handle that situation and rebuild needed stuff? > > Is it unrealistic to assume that upstream ABI providers will mark > their ABIs by using sonames correctly? > > Maybe that is at least the common case, then ABI_SLOT could be set > automatically. > > Maybe I'm too far ahead, and baby steps are better. > Although we have a lot of this information available (which is why/how @preserved-libs works, for instance), there is no way for portage to know *prior to emerging the update* if abi has changed. This is why it needs to be specified in the ebuild somehow (and sub-slots via 4-slot-abi seem very capable of handling this) That said, while experimenting with 4-slot-abi porting on my overlay, usually I am just specifying the major (or sometimes major.minor) version parts of the sonames, since that seems to make the most sense usually. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/4Q2IACgkQ2ugaI38ACPBzagD/blTq3Dq1K9Yrv2PdxSirxwu7 POUSNlLr59x8jKaE2oYBAIS+mATPRj3vn1W/uB37ipLmbg76gbcr7LTqh6Mb7Unv =VKuj -END PGP SIGNATURE-
Re: [gentoo-dev] About tests needing internet connection to run
On 8 July 2012 00:38, Pacho Ramos wrote: > After reading: > https://bugs.gentoo.org/show_bug.cgi?id=424719 > https://bugs.gentoo.org/show_bug.cgi?id=397973 > > Looks like there is not consensus about how to handle this cases, > probably a PROPERTIES variable for this would help :-/ > > Any ideas on this kind of issue? I've been handling it on the perl-experimental overlay by specifying SRC_TEST="network" SRC_TEST is a perl-module.eclass variable that controls weather or not to run the packages inbuilt tests. Its not anywhere in official capacity, but I think my approach is sane-ish somewhat, just needs better native support in my opinion. https://github.com/kentfredric/perl-experimental/blob/eclass-moretests/eclass/perl-module.eclass#L283 I think it would be nice to mask packages by their test failure expectancy, for instance, mask packages that the tests are known to fail on, or have tests turned on for all packages except packages where failures are expected from tests. ( There are a few packages which will always fail tests apparently, and it would be nice to indicate as such in the ebuild ). This way you can also probably opt for: a) installing only packages which don't require network for their tests b) only testing packages which don't require network for their tests I've also thought it might be nice to have a way to enable testing every time I install a ~amd64 package, instead of having a wide spectrum "all or nothing" approach. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] About tests needing internet connection to run
On Sat, 07 Jul 2012 14:38:59 +0200 Pacho Ramos wrote: > After reading: > https://bugs.gentoo.org/show_bug.cgi?id=424719 > https://bugs.gentoo.org/show_bug.cgi?id=397973 > > Looks like there is not consensus about how to handle this cases, > probably a PROPERTIES variable for this would help :-/ > > Any ideas on this kind of issue? To be honest, I think the first thing to do would be fixing the test suites to skip tests which fail due to internet connection being unavailable. Well, there would still be question how to reliably determine that... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
Ian Stakenvicius wrote: > > Is it unrealistic to assume that upstream ABI providers will mark > > their ABIs by using sonames correctly? > > > > Maybe that is at least the common case, then ABI_SLOT could be set > > automatically. > > Although we have a lot of this information available (which is why/how > @preserved-libs works, for instance), there is no way for portage to > know *prior to emerging the update* if abi has changed. Knowing that a library changes ABI before building is nice, but not relying on a human to encode this is nicer still. After compile, before install, there is an opportunity to show the effects of installing the package. I'm only talking about the context of the developer who is adding the new ebuild. So ABI_SLOT (or / SLOT) would be set automatically just once, in the process of committing the ebuild. No need to repeat the binary analysis - except if one source package has different ABI for different ARCHes. Fun! //Peter
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 07/07/2012 11:54 AM, Peter Stuge wrote: > Ian Stakenvicius wrote: >>> Is it unrealistic to assume that upstream ABI providers will mark >>> their ABIs by using sonames correctly? >>> >>> Maybe that is at least the common case, then ABI_SLOT could be set >>> automatically. >> >> Although we have a lot of this information available (which is why/how >> @preserved-libs works, for instance), there is no way for portage to >> know *prior to emerging the update* if abi has changed. > > Knowing that a library changes ABI before building is nice, but not > relying on a human to encode this is nicer still. > > After compile, before install, there is an opportunity to show the > effects of installing the package. > > I'm only talking about the context of the developer who is adding the > new ebuild. So ABI_SLOT (or / SLOT) would be set automatically just > once, in the process of committing the ebuild. Well, if you're talking about having portage automatically edit the ebuild, I don't think we want to do that. If developers use portage-2.2_alpha with preserve-libs, then they'll know automatically when there's an SONAME change that triggers preserve-libs. Part of the beauty of the approach used in EAPI 4-slot-abi is that that it can be used to trigger rebuilds in cases that don't even involve SONAME dependencies (consider a "pure" perl module that only needs to be rebuilt in order to install its interpreted *.pm files in a different directory for a new version of perl). > No need to repeat the > binary analysis - except if one source package has different ABI for > different ARCHes. Fun! It might be nice to add some binary analysis things beyond preserve-libs in the future. However, EAPI 4-slot-abi should work quite well even without that. It just automates rebuilds [1] that the user was previously required to handle manually, when prompted by elog messages, or by running tools like revdep-rebuild and perl-cleaner. It's being tested in the axs overlay [2], and it seems to be working pretty well. [1] http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/ [2] http://git.overlays.gentoo.org/gitweb/?p=dev/axs.git;a=summary -- Thanks, Zac
Re: [gentoo-dev] About tests needing internet connection to run
On Sat, Jul 7, 2012 at 11:21 AM, Michał Górny wrote: > To be honest, I think the first thing to do would be fixing the test > suites to skip tests which fail due to internet connection being > unavailable. Well, there would still be question how to reliably > determine that... For some packages, e.g. geocode-glib, which is basically a library for calling a particular web service from C code, running the test suite without network access is almost pointless. (Unless, of course, you feel like implementing a clone of that web service just to run the test suite.) I don't like tests that need network access, but in a few cases, they are the only to automatically verify that a package works. -Alexandre.
