[gentoo-dev] heads up: glibc-2.20 will require =linux-2.6.32
upstream glibc has dropped support for older Linux kernels. your choices: - upgrade your kernel - switch to a different C library - stick with glibc-2.19 for a while be warned though there are no plans atm to backport things to glibc-2.19. this includes security fixes, but more importantly as time moves on, making newer gcc versions sanely compile glibc. we've kept older glibc versions around to be nice, and on a part time basis for cross-compiling, but none of those are given priority. i.e. fixes come as people feel like doing them. certainly once glibc-2.20+ goes stable, there is no expectation let alone requirement that packages in the tree be kept working with older glibc versions. the maintenance cost there is unreasonable. i guess if you're stuck on old crap, now would be a good time to start preparing to unstick your crap. glibc-2.20 will most likely be in ~arch in the next 6 months. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] heads up: glibc-2.20 will require =linux-2.6.32
On 03/08/14 16:16, Mike Frysinger wrote: upstream glibc has dropped support for older Linux kernels. your choices: - upgrade your kernel - switch to a different C library - stick with glibc-2.19 for a while be warned though there are no plans atm to backport things to glibc-2.19. this includes security fixes, but more importantly as time moves on, making newer gcc versions sanely compile glibc. we've kept older glibc versions around to be nice, and on a part time basis for cross-compiling, but none of those are given priority. i.e. fixes come as people feel like doing them. certainly once glibc-2.20+ goes stable, there is no expectation let alone requirement that packages in the tree be kept working with older glibc versions. the maintenance cost there is unreasonable. i guess if you're stuck on old crap, now would be a good time to start preparing to unstick your crap. glibc-2.20 will most likely be in ~arch in the next 6 months. -mike use of 2.6.32 needs ~sys-fs/udev-208 (kept around for late 2.6.32 patchsets) use of current udev needs at least 2.6.39 for CONFIG_FHANDLE so there's more problems with running such a old kernel than just glibc just saying
[gentoo-dev] Re: Avoiding rebuilds
Steven J. Long sl...@rathaus.eclipse.co.uk wrote: collect your thoughts into a forum post You are right: Not everybody on this list is interested in all technical details, so it is perhaps better to shift this discussion to the forums. I have opened the topic https://forums.gentoo.org/viewtopic-p-7593700.html#7593700 with a summary of the various suggestions (and a very rough sketch of their advantages/disadvantages). Sounds like something that repoman could check, once a GLEP and impl are in place. The problem I meant is that repoman is no able to check it: It can be completely reasonable that the value of that metadata variable is unchanged, that is, repoman should not even spit a warning in this case. Unless one adds an artificial mechanism (like encoding the revision into the variable name or variable content) which *forces* the maintainer to change/check that variable. But any such mechanism I can think of is inconvenient and possibly confusing.
[gentoo-dev] The meaning of || ( a:= b:= ) dependencies
Hello, everyone. I would like to hear your opinion on what should be the meaning and use of '|| ( A:= B:= )' dependencies. By the PMS-y definition, any-of dependency can be satisfied by either branch of it, and the provider can be safely switched at runtime. That is: || ( A B ) means that either a or b has to be installed. If you built the package against A, you can install B, uninstall A and everything is supposed to work without rebuilding. That doesn't really happen when linking is involved. With help of subslots and virtuals we were able to partially solve the issue. For example, look at virtual/libudev. It binds subslot of the virtual to matching subslots of provider libraries. This way, you can safely switch providers as long as they have matching ABI; and if you want to upgrade the provider to another ABI version, you need to upgrade the virtual as well, and therefore rebuild the revdeps. Sadly, virtuals like this can only work when you can expect providers to have matching ABIs. This won't happen e.g. in krb5 providers (the two have incompatible ABIs) or libav* providers (ABIs of some of the libraries differ from version to version). At the moment, some developers already started mixing subslot and any-of operator syntax: || ( A:= B:= ) However, this breeds a really weird behavior in Portage. With static dependency model, it's partially understandable. ':=' atoms are expanded into specific subslots when matching package is installed, otherwise left unspecified. 'Unspecified' here means that any subslot satisfies the dependency -- like it was plain 'A' or 'B'. So, if during the build only A was installed, further upgrades to A can cause subslot rebuilds. If only B was installed, rebuilds are caused by B likewise. However, if afterwards the other package is installed, it satisfies the other branch of the dependency without subslot, so package doesn't get rebuild on any upgrades of A or B (since the unspecific dep always matches). This happens until the package is manually rebuild and gets the other subslot written. Even more curious behavior is caused if both A and B are installed at build time. In this case, subslots for both packages are expanded. And since || means that either of the branches must match, the subslots of both packages must change for the package to trigger subslot rebuild. In other words, || ( A:= B:= ) means that subslot rebuilds happen only if you consistently use a single provider. Provider switching or having both providers installed break it. Dynamic deps partially fix it. Since the current := support code is very dumb, it doesn't notice the '||' and respects all expanded subslots found in vardb. The main difference is that installing the other dependency doesn't prevent subslot rebuilds from the first one from happening. For example, if you built the package against A and install B afterwards, upgrade of A will still force rebuild of the package (because dynamic-deps code accidentally moves the A:0/1= dep out of || ()). The code also makes the behavior with both providers installed saner. Since both subslots are expanded, both are copied and rebuild of either would cause the rebuild of package. However, in practice it usually causes emerge to fail with slot conflict :). It should be also noted that the dyndeps behavior makes it impossible to uninstall either A or B when both were installed at the reverse dependency build time (since both are added to depgraph). The question would be -- which behavior is desired? I'm pretty sure Ciaran will say that the static dep behavior is correct per definitions but I don't think it's really useful to have slot operator dependencies which work only randomly. Instead, we may decide to redefine it into something useful in a future EAPI. In particular, I was thinking we could reuse this syntax: || ( A:= B:= ) to express any-of dependencies that do not support runtime switching of providers -- since that is pretty much what := does to slots. This would save us from creating a new syntax like '||= ()' [1]. [1]:https://bugs.gentoo.org/show_bug.cgi?id=489458 If we go this way, we also need to decide whether the order in such block would matter or not. In other words, whether the application can be expected to link to the first installed package in the list, or can link to any of them. If the order would matter, the package would need to be rebuilt when: 1. first satisfied dependency changes subslot, 2. [optionally] package preceding the first currently satisfied dependency is installed, 3. first currently satisfied dependency is uninstalled (but another is installed). If the order wouldn't matter, the package would need to be rebuilt when: 1. any of satisfied dependencies changes subslot (since we don't know which one package links to), 2. [optionally] any of the remaining packages is installed, 3. any of satisfied dependencies is uninstalled. The first option seems more refined, and causes less
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-08-03 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2014-08-03 23h59 UTC. Removals: virtual/perl-Class-ISA 2014-08-02 19:56:52 dilfridge virtual/perl-Filter 2014-08-02 19:58:55 dilfridge Additions: dev-util/objconv2014-07-28 14:29:15 slyfox app-crypt/monkeysign2014-07-29 07:54:13 k_f virtual/bitcoin-leveldb 2014-07-29 16:24:50 blueness dev-db/percona-server 2014-07-29 23:14:33 robbat2 sys-cluster/galera 2014-07-30 06:26:05 robbat2 dev-db/mariadb-galera 2014-07-30 06:26:21 robbat2 net-im/corebird 2014-07-30 14:31:51 dlan dev-libs/libpfm 2014-07-31 11:13:34 slis dev-perl/ExtUtils-Config2014-07-31 11:16:14 civil dev-libs/papi 2014-07-31 11:34:16 slis dev-perl/ExtUtils-Helpers 2014-07-31 11:39:56 civil sys-cluster/hpx 2014-07-31 12:26:11 slis dev-perl/ExtUtils-InstallPaths 2014-07-31 12:48:29 civil dev-perl/Module-Build-Tiny 2014-07-31 13:23:00 civil www-plugins/pipelight 2014-07-31 21:12:29 ryao dev-python/oslotest 2014-08-01 05:21:50 prometheanfire dev-db/tokumx 2014-08-01 13:08:05 chainsaw sys-boot/gummiboot 2014-08-02 07:54:54 mgorny app-admin/supernova 2014-08-03 20:06:30 alunduil dev-db/mysql-cluster2014-08-03 21:42:35 robbat2 -- 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: virtual/perl-Class-ISA,removed,dilfridge,2014-08-02 19:56:52 virtual/perl-Filter,removed,dilfridge,2014-08-02 19:58:55 Added Packages: dev-util/objconv,added,slyfox,2014-07-28 14:29:15 app-crypt/monkeysign,added,k_f,2014-07-29 07:54:13 virtual/bitcoin-leveldb,added,blueness,2014-07-29 16:24:50 dev-db/percona-server,added,robbat2,2014-07-29 23:14:33 sys-cluster/galera,added,robbat2,2014-07-30 06:26:05 dev-db/mariadb-galera,added,robbat2,2014-07-30 06:26:21 net-im/corebird,added,dlan,2014-07-30 14:31:51 dev-libs/libpfm,added,slis,2014-07-31 11:13:34 dev-perl/ExtUtils-Config,added,civil,2014-07-31 11:16:14 dev-libs/papi,added,slis,2014-07-31 11:34:16 dev-perl/ExtUtils-Helpers,added,civil,2014-07-31 11:39:56 sys-cluster/hpx,added,slis,2014-07-31 12:26:11 dev-perl/ExtUtils-InstallPaths,added,civil,2014-07-31 12:48:29 dev-perl/Module-Build-Tiny,added,civil,2014-07-31 13:23:00 www-plugins/pipelight,added,ryao,2014-07-31 21:12:29 dev-python/oslotest,added,prometheanfire,2014-08-01 05:21:50 dev-db/tokumx,added,chainsaw,2014-08-01 13:08:05 sys-boot/gummiboot,added,mgorny,2014-08-02 07:54:54 app-admin/supernova,added,alunduil,2014-08-03 20:06:30 dev-db/mysql-cluster,added,robbat2,2014-08-03 21:42:35 Done.
Re: [gentoo-dev] The meaning of || ( a:= b:= ) dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/08/14 06:44 PM, Michał Górny wrote: Hello, everyone. I would like to hear your opinion on what should be the meaning and use of '|| ( A:= B:= )' dependencies. [ Snip! ] I mentioned this on irc on Friday; as I understand it the following should occur. Preface: A-1.0's SLOT=0/1 A-2.0's SLOT=0/2 B-1.0's SLOT=4 B-2.0's SLOT=5 When the package is built and merged, it's built against SOMETHING that satisfies ||( A:= B:= ); this means A or B or both are installed. In the Portage implementation the slot of dependencies are recorded in VDB, and so whatever is installed on the system at compile/merge time is what gets recorded to VDB. It's not possible for Portage to know which atom in the ||() list, so VDB needs to match the current state. Case 1 - both A and B are installed - if A-1.0 upgrades to A-2.0, or B-1.0 upgrades to B-2.0, then rebuilds need to be triggered. This should be detectable because A:0/1 and B:4 are recorded in VDB. The fact that they are in a ||() block SHOULD NOT allow the not-upgrading B:4 to keep the dep satisfied if A-1.0 upgrades to A-2.0. Likewise, if either A or B are removed, then the package needs to be rebuilt (once again, it is not known which dep might affect how the package is linked). Case 2 - only A is installed - if A-1.0 upgrades to A-2.0 when B isn't installed at all, this should trigger a rebuild. Hopefully this is what is happening now in all cases. If A-1.0 stays around and B is installed, nothing needs to happen because the package is still linked against A-1.0. However, If A is then removed (say it's dropped from @world and then --depclean'ed), THEN a rebuild needs to be triggered so that a proper (slot) dependency is recorded against B. If A is upgraded after B is installed, then a rebuild needs to be triggered and we end up with Case#1. One thing that is a bit unique with case#2 is that, due to the fact that the subslot is recorded in VDB at merge time, we actually know which atom is satisfying the ||() dep, and so the changes and/or state of the other atom doesn't need to have any affect on this package until the atom that we built against is adjusted (upgraded, removed). By the PMS-y definition, any-of dependency can be satisfied by either branch of it, and the provider can be safely switched at runtime. That is: || ( A B ) means that either a or b has to be installed. If you built the package against A, you can install B, uninstall A and everything is supposed to work without rebuilding. That doesn't really happen when linking is involved. Hmm.. that safely switched at runtime language technicality might be something we should just honour, since with that in mind || ( A:= [anything] ) isn't a valid syntax, if it can only be used for runtime-switchable providers. PMS-wise it may be pertinent to use another operator than || (ie ||= as suggested) to specify a run-or-compile-time-switchable set of atoms. Of course, that means we need to wait for a new EAPI and then rewrite all inappropriate uses of || in the tree, since i believe most ||'s are in fact runtime-or-compiletime-switchable, rather than -just- runtime-switchable. [ Snip! ] Remaining issues: a. behavior of || ( A:= B:= C ) -- should C cause complete provider switching rebuilds? As per my cases above, no I don't think C should have any effect when it's installed. However, if A or B are removed then the removal should trigger a rebuild. b. do we need ||= ( A B C ) -- i.e. provider switching rebuilds without subslot rebuilds? Technically, no I don't think we would need provider-switching-rebuilds without subslot-rebuilds, but that only works if everything in the tree migrates to EAPI5 and implements subslots... Since that's unlikely, though, it might be worth considering.. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPe1sYACgkQ2ugaI38ACPAWiQD/TAilNp7CE5hCaoDikX5ZlSrc GBpx29M6zvmICsS2dqsBALce6lWlMlBFkRjNJ29XykevaRJIjVSHpsExnJiT5c8R =UDaD -END PGP SIGNATURE-
Re: [gentoo-portage-dev] New release: 2.2.11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 1 Aug 2014 14:45:11 -0700 Brian Dolbec dol...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 01 Aug 2014 22:08:12 +0200 Alexander Berntsen berna...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Friends, Portage 2.2.11 is now out. Brian is uploading the tarball and bumping the ebuild right now. Release notes: - Remove some broken old style virtual code - Bug # 505428 RO only filesystem check - Bug # 506186 TaskSequence starting bug. - Sort repoman check output - Remove obsolete repoman eclass checks - Bug # 505944 Improve mismatch checking - Bug # 488820 fix @security crash - Bug # 438976 Add DESCRIPTION.punctuation check to repoman - Add ruby18 warning for deprecated ruby target to repoman - Add Python version to Portage version line - Prevent rebuild code from performing unwanted repository changes - Include ::repository more consistently in output - Make the slot conflict handler output more debug information - Bug # 487074 Don't split suggested commands when printing them - Handle 'mkdir -p /etc/portage/make.profile/packages' gracefully -- i.e. produce an error instead of crashing with a traceback - Implement --alert - Bug # 516428 Make repoman warn if non-virtuals depend on perl-core - Prefer install-xattr to install.py as a wrapper to coreutils' /usr/bin/install to preserve file system extended attribute. I am going on a vacation. Due to all the bikeshedding over dynamic dependencies: I'm not taking my laptop! Happy hacking meanwhile, and I'll see you in a week. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander Have fun on your vacation There will be a delay in the release, I am getting 2 test fails in py-3.2 and py-3.3. I'll work on fixing those first, I will also likely have to re-tag the release after any bugfixes are done for those test failures. - -- Brian Dolbec dolsen OK, 2 small commits pushed and re-tagged 2.2.11. You may need to -f pull your checkout or tags Removed the pypy2_0 target from the ebuild and it's now in the tree. Sorry for the delay... - -- Brian Dolbec dolsen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQF8BAEBCgBmBQJT3moOXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4Njg4RkQxQ0M3MUMxQzA0RUFFQTQyMzcy MjE0RDkwQTAxNEYxN0NCAAoJECIU2QoBTxfLlRsIAIwmwLe+nGqYyPFa5S8gE3Yr QaWDK0eN3dKjjKfoB9p/X7JG8iQfp3bMlH5uUFKYb8uoLUFR1/sk4SpMLa4US5Jz U/xdfiu74IKMAr4NRCtLelSnAMsmMXbioWZB1G3VrlelDrBpPGG5/wqC2DmO1OVd gq9BwJYzoMDHMA7szsox5FGgokj6eWAnkh2n2qZHEVwSNAznhPmFiSHTw6ukXUfK LO58Ks7dxoCCTynhimlI+TGQ1nxYA4SEAdQbdhUIRbjfx9VqA8v/cuL/LYTi9do9 OJOUP1GOAz/Cz6WgxrIEOmN6MpdRQheSSEldt9mS8SAP6O0CcQt+IC9MvWXC4FA= =esH0 -END PGP SIGNATURE-
