Re: [gentoo-user] Re: About procmail and getline
On Sunday 14 June 2009 19:38:42 Harry Putnam wrote: Sebastian Günther sam...@guenther-roetgen.de writes: * Harry Putnam (rea...@newsguy.com) [12.06.09 16:41]: There is a patch offered but still one would think using standard emerge on a package that is outside the `~' daredevil stage and is not masked, it should `just work' [tm]. When I read the bug rightfully, procmail did not build with glibc 2.10.1, which is *not* stable yet, especially because of a lot packages which don't build cleanly with it at the moment. So if you'd use the stable glibc it would build fine. There is no need to mark procmail in any way. ~x86 should be able to apply patches on their own, or wait until the patch arrives in tree. Having run ~x86 since starting to build this install... how big of a problem would it be to return to stable? Much more work than it's worth. It's easier to reinstall. You run into issues like baselayout. Latest unstable is 2.0.1, latest stable is 1.12.11.1. When you emerged baselayout, it either created a whole whack of new files and included openrc, or upgraded the existing baselayout-1 stuff to baselayout-2 spec. Either way, the ebuild does not know how to go back down one version. baselayout affects a huge number of things, not the least of which is how to load lvm and soft raid modules. I've never attempted this change myself, and am not likely too either - it's way too easy to predict the resulting mess. There was a recent thread on this, and the OP eventually decided to write a script that listed every package he had and copy this to package.mask (with in front of course), then just wait for everything in stable to catch up. Your other option is to locate problematic packages individually and put just those into package.mask - pegging them at known working versions. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: About procmail and getline
On 15 Jun 2009, at 08:34, Alan McKinnon wrote: ... Much more work than it's worth. It's easier to reinstall. ... There was a recent thread on this, and the OP eventually decided to write a script that listed every package he had and copy this to package.mask (with in front of course), then just wait for everything in stable to catch up. I considered that to be an easy straight-forward way to undertake the downgrade. I'm not sure if every installed package was marked in this way or merely every package in world? But indeed the poster who suggested this method stated that he had gone from ~x86 to fully x86 in a matter of a few months. Stroller.
Re: [gentoo-user] Re: About procmail and getline
On Monday 15 June 2009 18:50:58 Stroller wrote: On 15 Jun 2009, at 08:34, Alan McKinnon wrote: ... Much more work than it's worth. It's easier to reinstall. ... There was a recent thread on this, and the OP eventually decided to write a script that listed every package he had and copy this to package.mask (with in front of course), then just wait for everything in stable to catch up. I considered that to be an easy straight-forward way to undertake the downgrade. I'm not sure if every installed package was marked in this way or merely every package in world? Mark everything. Otherwise you end up with with 150 packages in world at stable, and the other 850 packages which are DEPs at unstable. And that's where all hell breaks loose. Whether a dep is installed arch or ~arch depends only on ACCEPT_KEYWORDS and explicit directives in /etc/portage/*, and nothing to do with the package that pulled it in (exception: a package that defines a version or range of versions in it's DEPENDS) -- alan dot mckinnon at gmail dot com
[gentoo-user] Re: About procmail and getline
Sebastian Günther sam...@guenther-roetgen.de writes: * Harry Putnam (rea...@newsguy.com) [12.06.09 16:41]: There is a patch offered but still one would think using standard emerge on a package that is outside the `~' daredevil stage and is not masked, it should `just work' [tm]. When I read the bug rightfully, procmail did not build with glibc 2.10.1, which is *not* stable yet, especially because of a lot packages which don't build cleanly with it at the moment. So if you'd use the stable glibc it would build fine. There is no need to mark procmail in any way. ~x86 should be able to apply patches on their own, or wait until the patch arrives in tree. Having run ~x86 since starting to build this install... how big of a problem would it be to return to stable?
[gentoo-user] Re: About procmail and getline
Sebastian Günther sam...@guenther-roetgen.de writes: * Harry Putnam (rea...@newsguy.com) [12.06.09 16:41]: There is a patch offered but still one would think using standard emerge on a package that is outside the `~' daredevil stage and is not masked, it should `just work' [tm]. When I read the bug rightfully, procmail did not build with glibc 2.10.1, which is *not* stable yet, especially because of a lot packages which don't build cleanly with it at the moment. So if you'd use the stable glibc it would build fine. There is no need to mark procmail in any way. ~x86 should be able to apply patches on their own, or wait until the patch arrives in tree. Probably should use only stable but never have in over 5 yrs. Probably much to the dismay of this list. But even then, when a package is known in advance NOT to install with current ~x86 tools, seems there would be some way to let user know that. Since you've said it is because of glibc... and this is a known bug seems there might be a way to flag or mark procmail as incompatible with it. Maybe that would be way to hard to keep up with?
Re: [gentoo-user] Re: About procmail and getline
* Harry Putnam (rea...@newsguy.com) [14.06.09 19:46]: Sebastian Günther sam...@guenther-roetgen.de writes: * Harry Putnam (rea...@newsguy.com) [12.06.09 16:41]: There is a patch offered but still one would think using standard emerge on a package that is outside the `~' daredevil stage and is not masked, it should `just work' [tm]. When I read the bug rightfully, procmail did not build with glibc 2.10.1, which is *not* stable yet, especially because of a lot packages which don't build cleanly with it at the moment. So if you'd use the stable glibc it would build fine. There is no need to mark procmail in any way. ~x86 should be able to apply patches on their own, or wait until the patch arrives in tree. Probably should use only stable but never have in over 5 yrs. Probably much to the dismay of this list. But even then, when a package is known in advance NOT to install with current ~x86 tools, seems there would be some way to let user know that. First of all the bug is fixed, and a working patch was there 1 day after the opening. I call this a fast response... For ~x86 this is a working solution, and if you use ~x86: b.g.o *is* the users information system and applying patches should be no problem. Since you've said it is because of glibc... and this is a known bug seems there might be a way to flag or mark procmail as incompatible with it. The problem with glibc is, that you only find issues when you recompile your whole world, which is not needed in most cases. And most of the errors with glibc-2.10.1 result from wrong castings, which is only a compile time issue not a run issue. And all these problems are upstream, so you can patch for yourself in gentoo, but the cleaner solution is to wait for upstream to include the patch there. And release a new version, when they do too... Sebastian -- Religion ist das Opium des Volkes. | _ ASCII ribbon campaign Karl Marx | ( ) against HTML e-mail s...@sti@N GÜNTHER | X against M$ attachments mailto:sam...@guenther-roetgen.de | / \ www.asciiribbon.org pgpiQPOqv2ETB.pgp Description: PGP signature
[gentoo-user] Re: About procmail and getline
Sebastian Günther sam...@guenther-roetgen.de writes: First of all the bug is fixed, and a working patch was there 1 day after the opening. I call this a fast response... For ~x86 this is a working solution, and if you use ~x86: b.g.o *is* the users information system and applying patches should be no problem. Point taken. The problem with glibc is, that you only find issues when you recompile your whole world, which is not needed in most cases. And most of the errors with glibc-2.10.1 result from wrong castings, which is only a compile time issue not a run issue. And all these problems are upstream, so you can patch for yourself in gentoo, but the cleaner solution is to wait for upstream to include the patch there. And release a new version, when they do too... Thanks for your patience and I learned in an earlier thread one very easy way to get things working... I guess you'd still call it a patch... but not requiring setting up your own local portage and producing a patched version. ebuild /usr/portage/section/pkg/pkg.ebuild configure Do necessary manipulations ebuild /usr/portage/section/pkg/pkg.ebuild merge I realize in some cases that would be a recurring chore but I kind of doubt it this time. procmail will not likely need updating for some time and then like you've suggested portage will have it fixed.
