Issues preventing 2.0.53 going stable.
2.0.53 is ready to go stable. Rather than marking it stable, please note here if you're happy with it. When everybody's happy, I'll drop the _rc5 and repackage it. If any bugs to crop up, please open new ones and mark them as blocking this one. And.. While I'm not urging anyone to not do adequate testing, please don't forget about this bug as commits are presently limited to regressions in this release to ensure no further regressions slip in. Thanks in advance.
With the exception of 108744, which appears to be unresolved still, it works fine for me here (x86).
2.0.53_rc6 released. The two or three issues that cropped up with _rc5 are now fixed. Yay or nay when your ready. :) Note that most of the bugs this one depends on are not regressions despite the opening comment.
Only 2 regressions were reported in the last month, the last of which was 2 weeks ago. How are people's confidence levels? The first 2.0.54 pre-release will be done tomorrow...
I've been using it on x86/amd64 and found no issues with it. I haven't tried building a release with it yet or anything, but we don't do anything too extraordinary there, so it wouldn't test any functionality that I have not already tested manually.
I've been running it on my stable x86 systems and have not seen any issues with everyday usage.
I also haven't seen any issues recently. One thing that I would like to see before marking 2.0.53 is improving the documentation. Looking at the installed files there is at least a new program called emaint but it does not have a man page. emaint --help also does not give any clue on what the program is supposed to do. But this is ok if the user is not supposed to use the program directly. Just some official Gentoo page about Portage 2.0.53 would not hurt. Sorry about the noise if one already exists.
2.0.53_rc7 running nicely on a stable x86 server for over a week now. I agree with the emaint documentation thingy - users shouldn't think this is some kind of black portage magic - atleast a simple manpage should be supplied.
usage: emaint [options] all | world options: -h, --help show this help message and exit -c, --check check for problems -f, --fix attempt to fix problems ^^ Current emaint --help output. If this isn't self-explanatory, are there any suggestions on what could be changed? Currently emaint can only check and fix problems with one's world file. It is planned to make this tool's checks pluggable in 2.0.54. This will allow the current slew of fix* tools (fixpackages, fix-db.py, fixentries) to be integrated as well as allowing external tools such as revdep-rebuild as well. As such, there's nothing that can really be said in a man page...
(In reply to comment #9) > Currently emaint can only check and fix problems with one's world file. This should be said in the --help. For me the current --help just tells that it checks and fixes something for all and world, but it does not give any clue on when the tool could be actually useful to me.
usage: emaint [options] all | world Currently emaint can only check and fix problems with one's world file. Future versions will integrate other portage check-and-fix tools and provide a single interface to system health checks. options: -h, --help show this help message and exit -c, --check check for problems -f, --fix attempt to fix problems ^^^ How's that?
Looks great to me.
If it's possible bug 109496 could also be added before going stable.
Done.
Is there anything else? If not, which archs are happy with 2.0.53 going stable? There's a nasty bug (#112082) which affects the current stable as well, but I'd really like to have the patch run through ~arch for a little while. The bug only hits users that are running one of the masked glibc-2.3.6 snapshots and are now trying to upgrade to the masked glibc-2.3.6 so getting it into ~arch is enough for the time being. However, pushing it into 2.0.53 will delay the many bugs fixed above (and a few more not listed)...
Make sure you get #109496... :P I'd say it looks good. I can understand your reasoning for not wanting to hold up the release for a masked package set, so I'm in agreement for stabilization on x86. If any of the other x86 devs feel differently, they better speak now. ;]
Looks good to me, running it on multiple amd64 systems with no problems (headless stable server, ~amd64 laptop, stable desktop and mixed desktop).
sparc looks good on a mostly stable system, old-style and new-style.
What is the status of stuff like porthole that uses portage? I just saw a report on gentoo-portage-dev about problems with porthole and 2.0.53_rc7. If this new version breaks external tools, we should take care of stabling newer versions of those at the same time.
(In reply to comment #19) > What is the status of stuff like porthole that uses portage? I just saw a report > on gentoo-portage-dev about problems with porthole and 2.0.53_rc7. If this new > version breaks external tools, we should take care of stabling newer versions of > those at the same time. I really doubt that that is a regression, looking at the reply it's more a user error. Btw, we really should get this out, We're already sitting on several new things that should get out soon and not wait for 2.2 (multi hashes or the nasty ldconfig bug for example).
(In reply to comment #20) > Btw, we really should get this out, We're already sitting on several new things > that should get out soon and not wait for 2.2 (multi hashes or the nasty > ldconfig bug for example). Maybe we should get the final version to the tree then or have the documentation fixes been put to rc7 without a version bump?
Additional bump on this, we've got a lot of fixes and improvements to get out in this version, and that's not commenting on what's sitting in svn for the next release. Arches, issues? What's going on here- don't see _any_ arch stabled yet.
(In reply to comment #22) > Arches, issues? What's going on here- don't see _any_ arch stabled yet. We are not going to mark rc7 stable. It missing documentation and is not the final version. Please get the final version to the tree and we can start marking it.
Lark intervened. I'll be doing it in the next couple of hours.
Any chance of seeing bug #104705 resolved before we push this stable? I have a box where numerous packages are affected by this.
Pretty much any box that is fast is affected by it. However, that's one of the fixes waiting in the next version which needs its own round of testing. A regression seems to have appeared on the -portage-dev ml specifically related to that one actually...
Fast as in CPU speeds? The box I'm seeing it on defintiely does not fall into that category. It's an UltraSPARC IIe 500MHz, and the faster SPARC box I have (dual UltraSPARC III 750 MHz) does not suffer from this at all. However they are also running different major versions of gcc (3.4 vs 3.3 respectively) so I don't know if that possibly contributes at all.
I don't mean to be rude or tell you how to manage portage, but how does something that keeps multiple packages (and in the case of my system, double digit numbers of packages) fall into the category of stuff to be fixed in the next release?
Because it's broken in both the stable and unstable releases of portage. There is already a bunch that is fixed in the unstable version that is not fixed in the stable version with no known regressions. What logic is there in pushing out something that seems to be fixed but is barely tested?! Alternately, where's the logic in delaying the (less buggy) unstable version until every bug is fixed!?
Last time I looked at the ticket in question, it looked like it still bared further investigation a/dor a consensus on which way to fix the issue. As I said earlier, I'm not telling you how to do anything or trying to raise your hackles. I was just trying to understand how what appears to be a bug introduced in or related to the new portage version that causes packages to fail to emerge wasn't deemed a critical enough bug to be included in the release that just came out.
Assuming that #104705 will be addressed for .54 can we begin the process of marking portage-2.0.53 stable?
(In reply to comment #31) > Assuming that #104705 will be addressed for .54 can we begin the process of > marking portage-2.0.53 stable? portage team: Could you provide some commentary to this bug on what is the plan in regards to 2.0.53?
Yeah, apologies for not getting back sooner. So many mails so little time, this and that... Mark stable whenever you're ready. With upcoming releases, the process will change a little. Trunk will be released by the weekend and will go straight ~arch rather than being masked. It's pretty stable and the goal is to keep it that way (that is to say, any possibility of major breakage will be done on a different branch). Releases of trunk will happen regularly and give fixes and new features a chance to get quick widespread testing. There isn't one ready yet, but I'll create a metabug to track what bugs are fixed in trunk. There's already a metabug created for 2.0.54 (#108262) but it's currently got bugs marked against it which won't necessarily go in. I'll clean that up after putting out trunk. From then on, mark any fixes/features in the ~arch version of portage (trunk) that you want in the arch version of portage against the 2.0.54 metabug. We'll then backport whatever's possible and roll a release specifically tailored for stable. If it works well, 2.0.55 and on will follow the same path until trunk's feature set settles and/or the gap between stable and trunk becomes to big for backporting to be feasible.
I did notice one problem, at the bottom of man pages it shows Portage 2.0.51 as the version. I don't think this prevents the current version from going stable but I am going to wait until I hear what you have to say. I suggest you make this version generation automatic in the future. qlist -e portage | grep -e "\.gz$" | xargs gzcat | grep 2.0.51
Automation sounds good to me. :)
Well, not really. The version in the docs should state the portage version they have been written for, this doesn't technically have to match the version they are shipped with. So the version should only be updated when the docs are updated.
(In reply to comment #36) > Well, not really. > The version in the docs should state the portage version they have been written > for, this doesn't technically have to match the version they are shipped with. > So the version should only be updated when the docs are updated. > Well at least man emerge was modified to add emerge --config? http://dev.gentoo.org/~betelgeuse/man.diff Yes, not all files are modified and they could be left with the old version.
Filed a separate bug about the version strings as I should have done in the first place bug 116271.
x86 marked stable.
being in CC would have been nice. ;-) anyway: it runs just fine here, so 2.0.53 is stable on ppc64 now!
amd64 stable too
sparc stable.
alpha stable
2.0.54 instead.
