| Summary: | stabilize sys-libs/e2fsprogs-libs-1.41.2 sys-fs/e2fsprogs-1.41.2 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | aliens.satin0y, angleto, ankh_symbool, antarus, billie, boltomli, chalucha, dan.thorson, dan, esqualante, fmccor, G.Jaekel, Gentoo-bugs, gentoo-bugs, gentoo, gfa, iordonez, jdwieber, jens, jer, kerberos, lsalle, mark.k.finnegan, marten, matthias.grobarek, mercadodiego, mmorgan, mno2go, morris.walton, nlshep, qa, r.wolf.gentoo, rjm40, rmay31, rodrigo, schiotz, spookyghost, v.dijk.bas, xmit, zmedico |
| Priority: | High | Keywords: | STABLEREQ |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 241670, 244707 | ||
| Bug Blocks: | |||
|
Description
SpanKY
2008-10-26 20:13:00 UTC
Maybe bug #242696 should depend on this one. Stable for HPPA. @kerberos: should be fine for us - go on and make it stable ;) amd64/x86 stable Maybe I am wrong there but could somebody take a look at bug #244691. I was able to do the upgrade of the newly stabled e2fsprogs only by putting testing app-crypt/mit-krb5-1.6.3-r2 into package.keywords. This is because the stable version app-crypt/mit-krb5-1.6.3-r1 still depends on sys-libs/com_err and sys-libs/ss exclusively. ppc64 done Daniel Pielmeier right This is from my system with installed mit-krb5 [blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] sys-libs/e2fsprogs-libs (is blocking sys-libs/ss-1.40.9, sys-libs/com_err-1.40.9) (In reply to comment #7) Stabilisation of app-crypt/mit-krb5-1.6.3-r4 is already in the works, so this issue should be solved shortly. See depends of this bug. (In reply to comment #7) > Daniel Pielmeier right > This is from my system with installed mit-krb5 > [blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2) > [blocks B ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2) > [blocks B ] sys-libs/e2fsprogs-libs (is blocking sys-libs/ss-1.40.9, > sys-libs/com_err-1.40.9) In addition: with stabilized app-crypt/mit-krb5-1.6.3-r4 this blockers wont vanish as sys-libs/ss and sys-libs/com_err have been replaced by sys-libs/e2fsprogs-libs. I also got these blockers when trying to "emerge -uDN world" today, and I don't have mit-krb5 installed. What should I do about that? Remove com_err and ss by hand? But IMHO that's a bug -- a world-update should be smart enough to resolve this itself. # emerge -uDN world Calculating world dependencies... done! [ebuild U ] sys-fs/e2fsprogs-1.41.2 [1.40.9] [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 USE="nls" [blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] sys-libs/e2fsprogs-libs (is blocking sys-libs/ss-1.40.9, sys-libs/com_err-1.40.9) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (In reply to comment #0) > it should hopefully be a smooth process now ... so could people take the plunge > and check it out ? It's not very smooth if you're using stable portage. The automatic blocker resolution is only available in >=sys-apps/portage-2.1.5 which hasn't hit stable yet. You can mask the packages locally in /etc/portage/package.mask if you don't want to deal with these updated now: echo =sys-fs/e2fsprogs-1.41.2 >> /etc/portage/package.mask echo =sys-libs/e2fsprogs-libs-1.41.2 >> /etc/portage/package.mask echo =app-crypt/mit-krb5-1.6.3-r4 >> /etc/portage/package.mask (In reply to comment #11) > You can mask the packages locally in /etc/portage/package.mask if > you don't want to deal with these updated now: > > echo =sys-fs/e2fsprogs-1.41.2 >> /etc/portage/package.mask > echo =sys-libs/e2fsprogs-libs-1.41.2 >> /etc/portage/package.mask > echo =app-crypt/mit-krb5-1.6.3-r4 >> /etc/portage/package.mask I needed to add echo =net-fs/nfs-utils-1.1.3 >> /etc/portage/package.mask as this nfs-utils update depends on sys-libs/e2fsprogs-libs > You can mask the packages locally in /etc/portage/package.mask if > you don't want to deal with these updated now: > > echo =sys-fs/e2fsprogs-1.41.2 >> /etc/portage/package.mask > echo =sys-libs/e2fsprogs-libs-1.41.2 >> /etc/portage/package.mask > echo =app-crypt/mit-krb5-1.6.3-r4 >> /etc/portage/package.mask Sorry, I don't get this. Why don't you mask the packages that break stable systems until portage can handle this case? It's insane to offload this problem on the back of tenthousands of users. You are wasting these peoples time! (In reply to comment #13) Unfortunately, I have to agree. I wasted two and a half hours on this problem this morning, and it would have been much longer had it effected more than one server. Stable should be stable. What I don't get is why it is so much of a problem to handle blockers yourself. Since I know gentoo this was the way to go, although with the upcoming portage-2.2 most blockers will be handled automatically. The only problem I see here is that e2fsprogs and e2fsprogs-libs have been marked stable on some arches without marking app-crypt/mit-krb5-1.6.3-r4 stable in advance. This was a mistake and mistakes happen from time to time. Because of this the upgrade of e2fsprogs was blocked because of two reasons. First because stable app-crypt/mit-krb5-1.6.3-r1 depends on sys-libs/com_err and sys-libs/ss exclusively which blocks the upgrade. Second new e2fsprogs-libs replaces sys-libs/com_err and sys-libs/ss thus the second blocker. The quickest solution to the first blocker (if you want to finish the upgrade without masking packages) is to put =app-crypt/mit-krb5-1.6.3-r4 in package.keywords. For the second unmerge sys-libs/com_err and sys-libs/ss then do the e2fsprogs upgrade. This is not the cleanest solution because unmerging critical packages from your system may result in a damaged system but I had no problems by doing so. A better way is probably an "emerge --oneshot --nodeps sys-libs/e2fsprogs-libs sys-fs/e2fsprogs" which I did not try. This will probably result in file collosions while merging as sys-libs/e2fsprogs-libs may contain files which belong to sys-libs/com_err or sys-libs/ss but you don't loose important functionality. I guess this is also the way the new portage takes in this case. I want to add, that app-crypt/heimdal-0.7.2-r3 also seems to be a show stopper. I was wrong, I have mit-krb5 installed, too (as a dependency) -- sorry. Nevertheless, I unmerged com_err and ss and I added "=app-crypt/mit-krb5-1.6.3-r4 ~amd64" to package.keywords as suggested, but I still get a blocker: # emerge -uDN world Calculating world dependencies... done! [ebuild U ] sys-fs/e2fsprogs-1.41.2 [1.40.9] [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 USE="nls" [ebuild U ] app-crypt/mit-krb5-1.6.3-r4 [1.6.3-r1] [blocks B ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.2) Sorry folks, but this is not how a *stable* system should behave. I forgot to mention that sys-fs/e2fsprogs has to be unmerged too but the blocker explains everything. <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.2) You have a version lower then sys-fs/e2fsprogs-1.41 installed or due to be installed and this blocks the new sys-libs/e2fsprogs-libs-1.41.2. (In reply to comment #15) > For the second unmerge sys-libs/com_err and sys-libs/ss then do the e2fsprogs > upgrade. *** This is really not good solution. I did this and the result is: ========================================================================== ~ # em -1v e2fsprogs These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 USE="nls" 479 kB [ebuild N ] sys-fs/e2fsprogs-1.41.2 USE="nls" 4,263 kB Total: 2 packages (2 new), Size of downloads: 4,741 kB >>> Verifying ebuild Manifests... >>> Emerging (1 of 2) sys-libs/e2fsprogs-libs-1.41.2 to / >>> Downloading 'http://gentoo.mirror.solnet.ch/distfiles/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'ftp://ftp.solnet.ch/mirror/Gentoo/distfiles/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/distfiles/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/distfiles/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://surfnet.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://ovh.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://heanet.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://easynews.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://kent.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://switch.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://jaist.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://keihanna.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://nchc.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://osdn.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://mesh.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory >>> Downloading 'http://ufpr.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' wget: error while loading shared libraries: libcom_err.so.2: cannot open shared object file: No such file or directory !!! Couldn't download 'e2fsprogs-libs-1.41.2.tar.gz'. Aborting. * Fetch failed for 'sys-libs/e2fsprogs-libs-1.41.2' !!! can't process invalid log file: merge.ERROR ========================================================================== Maybe this can work for non-system libraries. But if the wget uses the err_com library, it is not good idea to uninstall it. I am very happy, that I made quickpkg for all these unmerged packages. Next time for system libraries, check the all dependencies please. Let's see. I clean everything up and get installed:
sys-libs/e2fsprogs-libs-1.41.2
sys-fs/e2fsprogs-1.41.2
NOW, something wants to pull in:
[ebuild N ] sys-libs/com_err-1.40.9 USE="nls"
[ebuild N ] sys-libs/ss-1.40.9 USE="nls"
===============
So, of course, I get
[blocks B ] sys-libs/com_err ("sys-libs/com_err" is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B ] sys-libs/e2fsprogs-libs ("sys-libs/e2fsprogs-libs" is blocking sys-libs/com_err-1.40.9, sys-libs/ss-1.40.9)
[blocks B ] sys-libs/ss ("sys-libs/ss" is blocking sys-libs/e2fsprogs-libs-1.41.2)
The only sane solution I can see is to mask out the -1.41.2 stuff until someone gets everything stable and in sync.
(In reply to comment #20) > Let's see. I clean everything up and get installed: > sys-libs/e2fsprogs-libs-1.41.2 > sys-fs/e2fsprogs-1.41.2 > > NOW, something wants to pull in: > [ebuild N ] sys-libs/com_err-1.40.9 USE="nls" > [ebuild N ] sys-libs/ss-1.40.9 USE="nls" > > =============== > So, of course, I get > [blocks B ] sys-libs/com_err ("sys-libs/com_err" is blocking > sys-libs/e2fsprogs-libs-1.41.2) > [blocks B ] sys-libs/e2fsprogs-libs ("sys-libs/e2fsprogs-libs" is blocking > sys-libs/com_err-1.40.9, sys-libs/ss-1.40.9) > [blocks B ] sys-libs/ss ("sys-libs/ss" is blocking > sys-libs/e2fsprogs-libs-1.41.2) > > The only sane solution I can see is to mask out the -1.41.2 stuff until someone > gets everything stable and in sync. > Sparc will NOT go stable until these dependencies are sorted out. I do not care to chase down what depends on com_err and ss --- if those are moved to e2fsprogs-libs, then all the dependencies have to reflect that, too. I didn't do quickpkg before unmerging com_err and ss but I were lucky enough that the sources were still on my machine, so reinstalling still worked since there was no need to call wget. *phew* Anyway, I'd strongly suggest to revert these stabilizations ASAP to spare other users of stable Gentoo from these headaches. One thing which I find a bit funny is that wget's ebuild doesn't depend on com_err at all, but apparently it uses that library. Who knows what other such hidden dependencies are out there? As already noted, this has to be sorted out first. (In reply to comment #22) > One thing which I find a bit funny is that wget's ebuild doesn't depend on > com_err at all, but apparently it uses that library. Who knows what other such > hidden dependencies are out there? As already noted, this has to be sorted out > first. > wget doesn't depend on or use com_err. You've built some component that wget uses in a fashion that makes that component depend on com_err. (i.e. wget with ssl support depends on openssl. Which if built with kerberos support depends on mit-krb5. Which depends on com_err) So the dependencies are proper. This is why we have revdep-rebuild and newer Portages have @preserved-rebuild (In reply to comment #20) > Let's see. I clean everything up and get installed: > sys-libs/e2fsprogs-libs-1.41.2 > sys-fs/e2fsprogs-1.41.2 > > NOW, something wants to pull in: > [ebuild N ] sys-libs/com_err-1.40.9 USE="nls" > [ebuild N ] sys-libs/ss-1.40.9 USE="nls" Can you provide an emerge -t that shows what needs this on your system? (In reply to comment #24) > (In reply to comment #20) > > Let's see. I clean everything up and get installed: > > sys-libs/e2fsprogs-libs-1.41.2 > > sys-fs/e2fsprogs-1.41.2 > > > > NOW, something wants to pull in: > > [ebuild N ] sys-libs/com_err-1.40.9 USE="nls" > > [ebuild N ] sys-libs/ss-1.40.9 USE="nls" > > Can you provide an emerge -t that shows what needs this on your system? > That being said, did you follow the dependencies of this bug? It needs something else marked stable before it can move forward and be stabled. I don't see a stable keyword from sparc on #241670 I've swapped the depends in mit-krb5 and heimdal to prefer e2fsprogs-libs if nothing is installed so we don't get a similar situation to Ferris'. However, arch teams still need to stabilize mit-krb5 (and technically heimdal as well) before they can stabilize e2fsprogs-libs. Basically, follow the depends of this bug. (In reply to comment #26) > I've swapped the depends in mit-krb5 and heimdal to prefer e2fsprogs-libs if > nothing is installed so we don't get a similar situation to Ferris'. However, > arch teams still need to stabilize mit-krb5 (and technically heimdal as well) > before they can stabilize e2fsprogs-libs. Basically, follow the depends of this > bug. app-crypt/heimdal would be a problem, since it needs sys-devel/autoconf-2.62, and its tracker bug #217647 was closed just days ago (and indeed depends on bug reports for the packages that need to go stable with autoconf-2.62). I can only say that mit-krb5 and heimdal in both stabilization requests (bug #241670 and bug #244707) are able to run with e2fsprogs-libs. I feel like being in a deadlock - we have to start to stabalize at some point. I can assure that I've updated all my test installation to unstable with heimdal _and_ mit-krb5 running with e2fsprogs-libs and it's working. greets, mueli p.S.: @dependency swaping - I haven't done that until now because until yet ss and com_err were stable. I also don't see the big advantage because if people uninstall ss and com_err to remove the blocker they should be well advised to install e2fsprogs-libs manually _before_ any further merging is done. If that's done correctly comm_err and ss wont be pulled back. (In reply to comment #28) > p.S.: @dependency swaping - I haven't done that until now because until yet ss > and com_err were stable. I also don't see the big advantage because if people > uninstall ss and com_err to remove the blocker they should be well advised to > install e2fsprogs-libs manually _before_ any further merging is done. If that's > done correctly comm_err and ss wont be pulled back. > The point is that we don't want people to have to do this manually. It should happen automatically. The way I swapped them will result in com_err/ss being used until e2fsprogs-libs is marked stable so no harm done. And once it is, it'll handle the un-merge and emerge hints properly so that automatic block resolving in Portage 2.1.5 and Portage 2.2 will just work. *** Bug 244790 has been marked as a duplicate of this bug. *** please mark unstable unless this is fixed: emerge -avuDN world These are the packages that would be merged, in order: Calculating world dependencies... done! [ebuild N ] sys-libs/com_err-1.40.9 USE="nls" 0 kB [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 USE="nls" 0 kB [ebuild N ] sys-fs/e2fsprogs-1.41.2 USE="nls" 0 kB [ebuild N ] sys-libs/ss-1.40.9 USE="nls" 0 kB [blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] sys-libs/e2fsprogs-libs (is blocking sys-libs/ss-1.40.9, sys-libs/com_err-1.40.9) Total: 4 packages (4 new, 3 blocks), Size of downloads: 0 kB !!! Error: The above package list contains packages which cannot be installed !!! at the same time on the same system. For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked The following works for me: echo "=app-crypt/mit-krb5-1.6.3-r4" >> /etc/portage/package.keywords emerge -C ss com_err e2fsprogs e2fsprogs-libs emerge -DNupv system [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 [ebuild U ] app-crypt/mit-krb5-1.6.3-r4 [1.6.3-r1] [ebuild N ] sys-fs/e2fsprogs-1.41.2 It is beyond me how these can go stable as long as there is a direct conflict with the only stable version of heimdal, which is heimdal-0.7.2-r3, and which requies: sys-libs/ss sys-libs/com_err I really think that this process requires quite a few packages to go stable at the same time, and apparently heimdal remains a problem (autoconf?). I've just fixed and tested the issue in heimdal-0.7.2-r3 and shouldn't be a problem after a mirror sync. I did _no_ revision bump because there are no installed files changed - even if it's a bit dangerous. But IMHO it's needed atm to take some risk to get the stable tree back in an usable state. mit-krb5-1.6.3-r4 is also on the way to get stable - of course the problem is fixed in heimdal-1.2.1-r1. greets, mueli Thanks, but there's one thing I still don't get: Why don't you just revert the stabilizations of e2fsprogs and e2fsprogs-libs? Would that cause other problems? It's not my package - ask vapier - but I don't like the suggestion. (I also don't like this situation - but that's not the point) If we downgrade now we only push the problem to later, that's neither a solution. greets, mueli *** Bug 244866 has been marked as a duplicate of this bug. *** I just put >sys-fs/e2fsprogs-1.41 in my package.mask until this is resolved. Question is, will this ever be automatically resolved, or are people going to have to do tricks to get around it? (In reply to comment #38) > Question is, will this ever be automatically resolved, or are people going to > have to do tricks to get around it? The blockers shown in comment #31 are solved automatically by >=sys-apps/portage-2.2.5. Unfortunately, this version of portage is not yet ready to be marked stable. re Comment #36 > If we downgrade now we only push the problem to later, > that's neither a solution. That's precisely the point. The situation today: a stable package depends on unstable packages, either directly, or on the unstable portage that can resolve the dependencies. One or more of these unstable packages is not yet ready to go stable. The situation later: Those packages are ready to go stable, and things can then be done in the sensible order. Kudos to the sparc maintainer at least (Comment #21) for grasping this and acting accordingly. Note that some users have already navigated through the blocks manually, and they would then be presented with a downgrade path that may be just as perilous. That's unavoidable, and those users have already shown the ability to deal with the issue, and are recently familiar with the details. They need do no more than add a couple of ~ keywords to keep the packages they've currently got and avoid the downgrade. The response to this issue otherwise is very disappointing. Mistakes happen, complex dependencies are involved, and it can take some time for the details at the crux of the issue to become clear - that's unfortunate but understandable. We're past that point now, and what matters much more is the response to the issue to prevent further harm. The indecision at this point is doing way more harm - the poor pooch is raw and tired and begging for mercy and still nobody is stopping.. There is no point in sticking with the stable pool if packages that depend upon unstable packages are marked stable. sys-libs/e2fsprogs-libs-1.41.2 sys-fs/e2fsprogs-1.41.2 should be rolled back to unstable until the supporting packages are also marked stable. Yes, accidents happen and development software slips into production, but there is no excuse for leaving it out there for numerous people to choke on. Who will be hurt by rolling back the stabilization of these two packages; the people running ~arch? This situation needs resolution. The quick and proper way is to mark it unstable on x86/amd64. Stop sitting on this issue as its a critical one for ALL gentoo users. I suggest to mark e2fsprogs-1.41 unstable until portage-2.1.5 (which can handle blocking packages automatically) becomes stable. Also, there should be no more packages which strictly depend on com_err in the stable tree. any comments from a developer? (In reply to comment #32) > The following works for me: > echo "=app-crypt/mit-krb5-1.6.3-r4" >> /etc/portage/package.keywords > emerge -C ss com_err e2fsprogs e2fsprogs-libs > emerge -DNupv system > [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 > [ebuild U ] app-crypt/mit-krb5-1.6.3-r4 [1.6.3-r1] > [ebuild N ] sys-fs/e2fsprogs-1.41.2 I can confirm that this works on x86 as well. Want to thank the developers who are working on this. Made a bad remark yesterday out of frustration, but really appreciate all those who spend countless hours working on Gentoo! (In reply to comment #44) > (In reply to comment #32) > > The following works for me: > > echo "=app-crypt/mit-krb5-1.6.3-r4" >> /etc/portage/package.keywords > > emerge -C ss com_err e2fsprogs e2fsprogs-libs > > emerge -DNupv system > > [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 > > [ebuild U ] app-crypt/mit-krb5-1.6.3-r4 [1.6.3-r1] > > [ebuild N ] sys-fs/e2fsprogs-1.41.2 > > I can confirm that this works on x86 as well. Want to thank the developers who > are working on this. Made a bad remark yesterday out of frustration, but > really appreciate all those who spend countless hours working on Gentoo! > This situation shouldn't be necessary with recent rsync's. It appears x86 stabilized the packages in the wrong order but my rsync from this morning has it proper. (In reply to comment #45) > (In reply to comment #44) > > (In reply to comment #32) > > > The following works for me: > > > echo "=app-crypt/mit-krb5-1.6.3-r4" >> /etc/portage/package.keywords > > > emerge -C ss com_err e2fsprogs e2fsprogs-libs > > > emerge -DNupv system > > > [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 > > > [ebuild U ] app-crypt/mit-krb5-1.6.3-r4 [1.6.3-r1] > > > [ebuild N ] sys-fs/e2fsprogs-1.41.2 > > > > I can confirm that this works on x86 as well. Want to thank the developers who > > are working on this. Made a bad remark yesterday out of frustration, but > > really appreciate all those who spend countless hours working on Gentoo! > > > This situation shouldn't be necessary with recent rsync's. It appears x86 > stabilized the packages in the wrong order but my rsync from this morning has > it proper. I rsynced both x86 systems late yesterday and before I posted today that I was having this issue on this morning? still had the same issue? so I followd comment 32 to keep moving. would revdep-rebuild solve this? (In reply to comment #15) > What I don't get is why it is so much of a problem to handle blockers yourself. Because you fucking idiot, those who track stable **expect** that it's stable. Most likely we are running servers who expect that when we update it works. Moron. (In reply to comment #47) > (In reply to comment #15) > > What I don't get is why it is so much of a problem to handle blockers yourself. > > Because you fucking idiot, those who track stable **expect** that it's stable. > Most likely we are running servers who expect that when we update it works. > > Moron. > Hm, I am sure such posts will not help at all. Lets wait for the good solution. (In reply to comment #47) > (In reply to comment #15) > > What I don't get is why it is so much of a problem to handle blockers yourself. > > Because you fucking idiot, those who track stable **expect** that it's stable. > Most likely we are running servers who expect that when we update it works. > > Moron. > Please be sure to follow the Code of Conduct[1] while participating in the Gentoo community. Comments such as the above will not be tolerated. Be nice and helpful or be silent. -Alec Gentoo User Relations. [1] http://www.gentoo.org/proj/en/council/coc.xml (In reply to comment #47) > (In reply to comment #15) > > What I don't get is why it is so much of a problem to handle blockers yourself. > > Because you fucking idiot, those who track stable **expect** that it's stable. > Most likely we are running servers who expect that when we update it works. > > Moron. > First of all, that tone isn,t really appropriate here and I don't think there is a need to call other people names. I will not react on that further and try to stay calm. If you are managing "important" servers and you want something reliable than use a distribution where you can get professional support. There you can demand something that works out of the box. But this is Gentoo, a volunteers project. Those people are working for you _without_ being paid. And as I mentioned above errors happen so deal with this or consider the alternatives. Plus if you are smart you won't update your servers immediately after something goes stable (because stable is relative) as there is always a chance that something will not work immediately. Instead wait some time and if such things happen you know an update is not save at this time. Many companies and universities do the same and let some time pass before they update to the newest software because of the same reasons. This is not a Gentoo problem this applies in general to new software. Before there was a package manager that supports automatic blocker resolution and this means the entire lifetime of Gentoo as there isn't one yet in the stable tree you were always in the need to resolve such issues manual. So an experienced user should get along with this and I expect a server administrator of Gentoo based servers to be such an user. Also there have been proposed many solutions to the update problem even if you did already run into the wget problem. Like downloading the sources through http, using busybox wget to acquire the sources or put the needed sources to your distfiles location by other means. If not you can always put the affected packages into package.mask and wait for a version of portage going stable which is able to handle this blockers. Also a server administrator should always have a backup ready to recover things if something goes wrong. I this case you should know the features buildpkg or buildsyspkg. The problem here is not the blocker because of e2fsprogs-libs replacing ss and com_err as something like this happened many times before. The problem is stabilisation of e2fsprogs without proper checking all dependencies to be prepared for this switch. The only criticism on the developers is that bug #234907 exists and already hit unstable gentoo users about two months before. So this was a known problem and now why does this happen again when marking this packages stable? Like other people already mentioned, instead of complaining what doesn't work in Gentoo please think the other way round to see what is possible with Gentoo. You gain great flexibility by using Gentoo, but given this flexibility you can not expect every aspect of Gentoo to work perfect. (In reply to comment #50) > If you are managing "important" servers and you want something reliable than > use a distribution where you can get professional support. There you can demand > something that works out of the box. But this is Gentoo, a volunteers project. > Those people are working for you _without_ being paid. And as I mentioned above > errors happen so deal with this or consider the alternatives. While I don't agree at all with the way Rich replied, I agree with his point. People who run Gentoo on 'stable' should not have to deal with masking in this way too the extent that such cases are preventable. If this was a mistake, that's fine. I'm certainly not going to throw anyone under the bus for human error, especially considering how hard a lot of people work to make Gentoo such a great platform. That said, I think it should be appropriate for those of us who don't need or can't afford commercial support for Linux to consider Gentoo (stable) to be a reasonable choice, even for "important" stuff. That means that the less manual work required during an upgrade, the better. That's all. (In reply to comment #32) > The following works for me: > > echo "=app-crypt/mit-krb5-1.6.3-r4" >> /etc/portage/package.keywords > emerge -C ss com_err e2fsprogs e2fsprogs-libs > > emerge -DNupv system > [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 > [ebuild U ] app-crypt/mit-krb5-1.6.3-r4 [1.6.3-r1] > [ebuild N ] sys-fs/e2fsprogs-1.41.2 Works here too on amd64. A couple of safety notes though: 1) removing com_err may break sudo, so be sure you have root password or do "sudo su -" first and keep that console open. 2) removing com_err may break lots of other stuff including wget so be sure you have downloaded everything first: emerge --udpate --deep --newuse --fetchonly world 3) just in case you get stuck, make backup packages: quickpkg ss com_err e2fsprogs e2fsprogs-libs and you'll want to run revdep-rebuild afterward of course. (In reply to comment #19) > (In reply to comment #15) > > For the second unmerge sys-libs/com_err and sys-libs/ss then do the e2fsprogs > > upgrade. > > *** This is really not good solution. I did this and the result is: > > ========================================================================== > ~ # em -1v e2fsprogs > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 USE="nls" 479 kB > [ebuild N ] sys-fs/e2fsprogs-1.41.2 USE="nls" 4,263 kB > > Total: 2 packages (2 new), Size of downloads: 4,741 kB > > >>> Verifying ebuild Manifests... > > >>> Emerging (1 of 2) sys-libs/e2fsprogs-libs-1.41.2 to / > >>> Downloading 'http://gentoo.mirror.solnet.ch/distfiles/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'ftp://ftp.solnet.ch/mirror/Gentoo/distfiles/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/distfiles/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/distfiles/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://surfnet.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://ovh.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://heanet.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://easynews.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://kent.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://switch.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://jaist.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://keihanna.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://nchc.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://osdn.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://mesh.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > >>> Downloading 'http://ufpr.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-libs-1.41.2.tar.gz' > wget: error while loading shared libraries: libcom_err.so.2: cannot open shared > object file: No such file or directory > !!! Couldn't download 'e2fsprogs-libs-1.41.2.tar.gz'. Aborting. > * Fetch failed for 'sys-libs/e2fsprogs-libs-1.41.2' > !!! can't process invalid log file: merge.ERROR > ========================================================================== > > Maybe this can work for non-system libraries. But if the wget uses the err_com > library, it is not good idea to uninstall it. I am very happy, that I made > quickpkg for all these unmerged packages. > > Next time for system libraries, check the all dependencies please. > I didn't be so cautelous in making quickpkg's but I found another way for solving it quickly: I just downloaded e2fsprogs-libs-1.41.2.tar.gz into /usr/portage/distfiles/ from a mirror and just emerge it. Isn't nice but at least you avoid that annoying problem of the comm_err dependency and allows you to emerge the rest of the packages *** Bug 245332 has been marked as a duplicate of this bug. *** Can someone please explain to me, why we cannot simply mark e2fsprogs-1.41.2 unstable until no packages in the stable tree depend strictly on com_err and ss and until a stable portage version can handle blocking packages properly? I am not complaining, I am really just curious. Are there some security issues or severe bugs in e2fsprogs 1.40.9? I will "second" Till Korten's comment/question... "Can someone please explain to me, why we cannot simply mark e2fsprogs-1.41.2 unstable...." 1. Why is it that nobody seems to have tested this before since it was known to be a problematic upgrade (http://bugs.gentoo.org/show_bug.cgi?id=234907)? 2. How can it be that a single package suddenly claims and distributes libraries which are otherwise used by completely independent packages? This contradicts all of good software management I ever heard of. 3. Why does did the maintainer of the problematic package not come to senses after more than a week and reverted the stable status to unstable. The traffic in this ticket is obviously a display of the broad user frustration and that a mistake has been made. It is time to step up and correct the mistake and not to sulk. Is there a workaround to this bug? I tried one of the workaround from the discussion comment #32 from Anton Bolshakov to no avail. The machine will no longer emerge any package and would give me "wget: error while loading shared libraries: libcom_err.so.2: cannot open shared" error. The same error as comment #19. echo "=app-crypt/mit-krb5-1.6.3-r4" >> /etc/portage/package.keywords emerge -C ss com_err e2fsprogs e2fsprogs-libs emerge -DNupv system [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 [ebuild U ] app-crypt/mit-krb5-1.6.3-r4 [1.6.3-r1] [ebuild N ] sys-fs/e2fsprogs-1.41.2 Is the new portage ready for release soon? If not, how long should we wait? I would like to know a workaround that will not harm or break our system. I am desperate for answer. Any help is greatly appreciated. emerge -f mit-krb5 e2fsprogs e2fsprogs-libs emerge -C ss com_err e2fsprogs emerge -auDNv world or... if you're not using Kerberos (i.e. no USE=kerberos) emerge -C ss com_err e2fsprogs emerge -auDNv world Note, USE=kerberos is no longer default for the desktop profile. (In reply to comment #59) > emerge -f mit-krb5 e2fsprogs e2fsprogs-libs Uh, how is that going to work without wget? Do what someone else suggested: Go here: http://sourceforge.net/project/showfiles.php?group_id=2406&package_id=2374 and go into the 1.41.2 release Now, download e2fsprogs-libs-1.41.2.tar.gz into /usr/portage/distfiles You should be able to install it, and make sure now to emerge -f <anything you could possibly need> before continuing. > emerge -C ss com_err e2fsprogs > emerge -auDNv world > > or... if you're not using Kerberos (i.e. no USE=kerberos) > > emerge -C ss com_err e2fsprogs > emerge -auDNv world > > Note, USE=kerberos is no longer default for the desktop profile. > Doug, I think I just did what you just suggested and it broke my machine. I can't emerge any package as wget is looking for "libcom_err.so.2" I can't fix wget as I can't connect anywhere, as no command will work, ie links, lynx, or sftp. I think booting from CD is the only way I can get "wget" to work again. Any other workaround that is not harmful to my machine? (In reply to comment #61) > Doug, I think I just did what you just suggested and it broke my machine. I > can't emerge any package as wget is looking for "libcom_err.so.2" I can't fix > wget as I can't connect anywhere, as no command will work, ie links, lynx, or > sftp. I think booting from CD is the only way I can get "wget" to work again. > > Any other workaround that is not harmful to my machine? > Please see Comment 60 --- you can download the sources for the e2fsprogs-libs from their home site and then install them normally. (In reply to comment #59) > emerge -f mit-krb5 e2fsprogs e2fsprogs-libs Better, yet, do an `emerge -vuDNf world' - that will even fetch sources when there are blockers, yes even with the currently stable sys-apps/portage. (In reply to comment #63) > (In reply to comment #59) > > emerge -f mit-krb5 e2fsprogs e2fsprogs-libs > > Better, yet, do an `emerge -vuDNf world' - that will even fetch sources when > there are blockers, yes even with the currently stable sys-apps/portage. > I think the question in Comment 58 was what do you do if you didn't fetch the sources before wget got broken. If you don't have a quickpkg for com_err or the sources for com_err and ss lying around, you will have to load e2fsprogs-libs sources by hand. Unfortunately, unless you have been reading this bug or are naturally paranoid, it's pretty easy in this case to destroy wget in the middle. That's one reason why sparc is on indefinite hold here --- we will not go stable as long as this possibility exists. (Me, I will never do an 'emerge -C <anything-at-all>' unless I have a quickpkg of it, but I am naturally paranoid. :) ) (In reply to comment #60) > (In reply to comment #59) > > emerge -f mit-krb5 e2fsprogs e2fsprogs-libs > > Uh, how is that going to work without wget? Do what someone else suggested: The point is you do that before you unmerge anything, hence the emerge -f coming before the emerge -C, so you'll have the sources already downloaded. Since no dev (especially the one responsible for causing this problem) has answered the question, I'll repeat it: "CAN SOMEONE PLEASE EXPLAIN TO ME, WHY WE CANNOT SIMPLY MARK e2fsprogs-1.41.2 UNSTABLE...."? And yes, the all caps were intentional - yelling sometimes is necessary when an extremely relevant question is being completely ignored. (In reply to comment #66) > Since no dev (especially the one responsible for causing this problem) has > answered the question, I'll repeat it: > > "CAN SOMEONE PLEASE EXPLAIN TO ME, WHY WE CANNOT SIMPLY MARK e2fsprogs-1.41.2 > UNSTABLE...."? > > And yes, the all caps were intentional - yelling sometimes is necessary when an > extremely relevant question is being completely ignored. > Let me add a comment from a long-time Gentoo user: The problem is NOT the blocking packages, the last year or so has taught all gentoo users to resolve that. The problem is that the solution we have all become used to, i.e. just to remove the offending packages before updating, results in a b0rked system, unless you are being extremely careful by searching for and reading this bug before just doing as usual! This, IMHO, means that this package should be masked again, preferably yesterday! :-) /Jakob > The problem is that the solution we have all
> become used to, i.e. just to remove the offending packages before updating,
> results in a b0rked system, unless you are being extremely careful by searching
> for and reading this bug before just doing as usual! This, IMHO, means that
> this package should be masked again, preferably yesterday! :-)
>
> /Jakob
>
I absolutely second that! Anyone? PLEASE?
I agree, removing offending packages is not a problem if the removal doesn't break your system. For the record, even despite this fiasco, I remain a mostly satisfied Gentoo user and very thankful to the developers of the distro that got me into using free software. When I graduate from uni and actually have time, I want to help the project somehow. I do wonder, like many others, why not just mark e2fsprogs-1.41.2 unstable until things can be stabilized in the correct order, and why are the developers not responding to this question when so many people are affected? If you want to call me a n00b then fine, but please can you explain why marking it unstable is not an option? (In reply to comment #58) > Is there a workaround to this bug? I tried one of the workaround from the > discussion comment #32 from Anton Bolshakov to no avail. The machine will no > longer emerge any package and would give me "wget: error while loading shared > libraries: libcom_err.so.2: cannot open shared" error. The same error as > comment #19. > > echo "=app-crypt/mit-krb5-1.6.3-r4" >> /etc/portage/package.keywords > emerge -C ss com_err e2fsprogs e2fsprogs-libs > emerge -DNupv system > [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 > [ebuild U ] app-crypt/mit-krb5-1.6.3-r4 [1.6.3-r1] > [ebuild N ] sys-fs/e2fsprogs-1.41.2 > > Is the new portage ready for release soon? If not, how long should we wait? I > would like to know a workaround that will not harm or break our system. I am > desperate for answer. Any help is greatly appreciated. > If you still have the tar files of the packages you unmerged in your distfiles then you can locally mask the new packages and emerge the packages you originally unmerged. for instance I added these packages to /etc/portage/package.mask: =sys-libs/e2fsprogs-libs-1.41.2 =sys-fs/e2fsprogs-1.41.2 =app-crypt/mit-krb5-1.6.3-r4 =net-fs/nfs-utils-1.1.3 so I can go happily on my way until this MESS is resolved. I too followed comment #32. This is how I resolved it. Luckily I have ample storage and very rarely clean out my distfiles. It currently has 8.5 gigs of packages. Guess I'll clean it out soon. Otherwise you'll have to download the packages on another system and transfer them on thumbdrive or other medium then pick up at comment#60. Hope this helps. Workarounds proposed so far are no good if you use heimdal rather than mit for krb5; there is no way forward in this case, the only option is to mask these packages that should not be stable. I'm not familiar with the gentoo bug tracking process - thankfully, most of the time things work so well I haven't needed to be - how does one request escalation of this issue to get appropriate attention? This cannot continue without accountability and action. (In reply to comment #71) > Workarounds proposed so far are no good if you use heimdal rather than mit for > krb5; there is no way forward in this case, the only option is to mask these > packages that should not be stable. > > I'm not familiar with the gentoo bug tracking process - thankfully, most of the > time things work so well I haven't needed to be - how does one request > escalation of this issue to get appropriate attention? This cannot continue > without accountability and action. > Add qa to the CC list. I'll do it for you. (In reply to comment #71) > Workarounds proposed so far are no good if you use heimdal rather than mit for > krb5; there is no way forward in this case, the only option is to mask these > packages that should not be stable. Why not? I've changed the dependency of stable heimdal-0.7.2-r3 and the unstable one to: || ( ( >sys-libs/e2fsprogs-libs-1.40.11 ) ( sys-libs/com_err sys-libs/ss ) ) Please have a look in your portage tree if the ebuilds are up to date. Especially if your using our old (and really outdated) stable version you have to do a sync - I've made the dependency changes _without_ a revision bump to get the stable version to run with actual stable tree. (there are no installed files affected btw - so it's conform with our policy) greets, mueli p.S.: please respond if you have other problems with heimdal I am able to fix - I am _not_ responsible for e2fsprogs(-libs) itself ;) BTW - I am running test installations in vbox with actual stable configuration without any masking in a heimdal and mit-krb5 constellation. Therefore I can assure that it works! That this blocker is a bit tougher to fix is another thing - but hey - why do we use gentoo? ;) There is really only ONE thing you've to keep in mind - fetch the new e2fsprogs(-libs) _bevore_ unmerging the old ones! mueli (In reply to comment #74) > That this blocker is a bit tougher to fix is another > thing - but hey - why do we use gentoo? ;) > > There is really only ONE thing you've to keep in mind - fetch the new > e2fsprogs(-libs) _bevore_ unmerging the old ones! > > mueli > This is EXACTLY the point, why this package should not be marked stable! There are many people out there who basically reinstalled their system because of this blocker that is "a bit tougher to fix". The problem is that most people do not check for bugs before something is broken, but afterwards. In this case the system gets broken so badly that many users do not know how to fix it except for a reinstallation! This is wasting a lot of peoples time, which is inappropriate for a stable package! And yes, some people use gentoo (especially the stable tree) for a productive system and not because they enjoy working around bugs. That said, I would like to emphasize that I am generally very happy with gentoo and would like to thank all developers for their efforts. Especially, because usually bugs are fixed extremely quick and the documentation and forums are extremely helpful. Let me stamp out the whole argument to get the stable keyword reverted. If we revert the stable keyword, everyone who dealt with this issue in the first place is going to get hit with it AGAIN on the reverse. So, this is a non-starter. It will not happen, it will not be reverted. So let me make it clear, *the stable keyword will not be reverted*. End of discussion. (In reply to comment #76) > Let me stamp out the whole argument to get the stable keyword reverted. If we > revert the stable keyword, everyone who dealt with this issue in the first > place is going to get hit with it AGAIN on the reverse. So, this is a > non-starter. It will not happen, it will not be reverted. > > So let me make it clear, *the stable keyword will not be reverted*. End of > discussion. > I guess we'll have to accept that. However, for the next time that such a bug happens, there is one argument I would still like to bring: everyone who dealt with it before, knows now, how to fix it, while everyone who has not dealt with it yet has to go through the whole hour consuming process of breaking his system, finding out what's wrong, looking for a solution and fixing it. Therefore, I strongly suggest that next time such a thing happens, the offending packet gets marked unstable immediately. (In reply to comment #76) > Let me stamp out the whole argument to get the stable keyword reverted. If we > revert the stable keyword, everyone who dealt with this issue in the first > place is going to get hit with it AGAIN on the reverse. So, this is a > non-starter. It will not happen, it will not be reverted. > > So let me make it clear, *the stable keyword will not be reverted*. End of > discussion. Meaning that the users who do not have plenty time for debugging on their hand have to suffer (a.k.a. reinstall) from the mistakes of a single person/a few persons. That's what I call pure efficiency in software production. Gentoo QA should look into this issue here and change the policy when a package may be marked as stable. This is ridiculous. (In reply to comment #76) > Let me stamp out the whole argument to get the stable keyword reverted. If we > revert the stable keyword, everyone who dealt with this issue in the first > place is going to get hit with it AGAIN on the reverse. So, this is a > non-starter. It will not happen, it will not be reverted. Ok, thankyou; this is at least a clear statement from which we can move forward, rather than leaving this in limbo with no clear response for so long. I happen to disagree with the impact analysis, as stated in Comment #40, but won't debate the point further. QA can have their own discussions about process improvement to prevent similar mistakes in future. I hope someone will take care of warning all the other users this will bite, in some prominent place (like a news item on the home page). (In reply to comment #73) > (In reply to comment #71) > > Workarounds proposed so far are no good if you use heimdal rather than mit for > > krb5; there is no way forward in this case, the only option is to mask these > > packages that should not be stable. > > Why not? I've changed the dependency of stable heimdal-0.7.2-r3 and the > unstable one I may have tried before this change; it was some time ago and I had package.mask'ed out the offending packages here since to let other work proceed. > p.S.: please respond if you have other problems with heimdal I am able to fix I would *dearly* like to know how to make nfs-utils and openssl use heimdal; at the moment I have to package.use -kerberos those two, or they try and pollute my system with mit-krb evil.. I have kerberos for ssh and apache but not these. It has been some time since I last looked into it, and I'm delighted to learn that there is now someone paying attention to heimdal, as well as a series of newer packages in ~ for me to try. I had a very quick look this morning, but didn't get far before I hit the same problem again. However, that discussion does not belong in this bug; can you point me elsewhere for details? ppc stable alpha/ia64 stable Kudos to McCormick for not letting this go stable on sparc before this mess is sorted out... I just wish same went for nixnut (ppc) - this week's emerge -uvaDN world on my ppc-box ended up taking a bit longer than anticipated due to com_err, ss and e2fsprogs blocking. Thankfully I didn't just rush out and removed those blockers w/o doing a bit of googling first.... (In reply to comment #76) > > So let me make it clear, *the stable keyword will not be reverted*. End of > discussion. > Thank you for such a clear statement how to deal with the situation. I'll memorize it for the pool of arguments for management decisions -- it's a very strong candidate to kick out Gentoo completely from all of our servers at the next opportunity. Be proud! (In reply to comment #59) > emerge -f mit-krb5 e2fsprogs e2fsprogs-libs > emerge -C ss com_err e2fsprogs > emerge -auDNv world > > or... if you're not using Kerberos (i.e. no USE=kerberos) > > emerge -C ss com_err e2fsprogs > emerge -auDNv world > > Note, USE=kerberos is no longer default for the desktop profile. > Excellent! If I understand this post correctly, and the few from you that followed, you mean, that for those that are using kerberos, do this: > emerge -f mit-krb5 e2fsprogs e2fsprogs-libs > emerge -C ss com_err e2fsprogs > emerge -auDNv world and for those that aren't (by default, if they don't have kerbios in USE flags), do this: > emerge -f e2fsprogs e2fsprogs-libs > emerge -C ss com_err e2fsprogs > emerge -auDNv world I just did the bottom one and it seems to have worked! Thanks so much for the help! :) (In reply to comment #85) > I just did the bottom one and it seems to have worked! Thanks so much for the > help! :) Yes, um, in fact it was as easy as that all along. :) (In reply to comment #85) After I used this I could not reboot, as /sbin/fsck and /sbin/e2fsck were GONE! After booting from a CD, mounting the hard drive to the CD and creating a /sbin/fsck that did "exit 0", I was able to boot the hard drive and re-emerge e2fsprogs. I've found that the steps in this bug: http://bugs.gentoo.org/show_bug.cgi?id=234907#c7 in comment #7 not only worked for me, but seem to be the most reliable way of doing this. I haven't heard of anyone having problems with doing it that way so I would recommend following those steps. |
