Error: libcrypt-nss conflicts with libcrypt-2.23.90-30.fc25.x86_64 Error: libcrypt conflicts with libcrypt-nss-2.23.90-30.fc25.x86_64 Error: libcrypt conflicts with libcrypt-nss-2.23.90-30.fc25.i686 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Please fix if possible. rawhide!
(In reply to Ali Akcaagac from comment #0) > Error: libcrypt-nss conflicts with libcrypt-2.23.90-30.fc25.x86_64 > Error: libcrypt conflicts with libcrypt-nss-2.23.90-30.fc25.x86_64 > Error: libcrypt conflicts with libcrypt-nss-2.23.90-30.fc25.i686 > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > > Please fix if possible. > > rawhide! What did you run to get this error message? How did you get into this scenario? Could you provide the output of `rpm -qa | grep crypt` please?
sudo yum group install gnome-desktop --releasever=rawhide --disablerepo=* --enablerepo=rawhide --downloaddir /opt/fedora --downloadonly But the issue seem to be gone as I retried this today (just tested). Rather than -30 it now pulls in -29. What I don't understand is, why the i686 packages are also being downloaded. I only have a x86_64 system. Must be triggered by another package... Will investigate and report back. It looks like some package internal test got tested agains the i686 downloaded package and thus caused the error to happen. Btw: I depend on yum because of reasons reported elsewhere... Should change with dnf 2.0 once out...
I think I was able to isolate the *problem*! But first things first! > What did you run to get this error message? One of *our* (work) scripts triggered this issue a few days ago. On the 20th July we changed our infrastructure from Fedora 22 i686 to Fedora 24 x86_64 and continued running our scripts as usual. Early that morning one script triggered the error that I posted above. The scripts basicly does the following: sudo yum group install gnome-desktop --releasever=rawhide --disablerepo=* --enablerepo=rawhide --downloaddir /opt/fedora --downloadonly sudo yum install <other packages> --releasever=rawhide --disablerepo=* --enablerepo=rawhide --downloaddir /opt/fedora --downloadonly So all it does is downloading a set of groups and singular packages and stores them into a different directory. No further processing, no installation nothing. Just downloading. > How did you get into this scenario? I can not clearly answer this. All I can do is giving an explaination what may have caused this. During my last replay (a few hours ago (Comment #2)), I detected that the directory where all packages got downloaded also contained i686 packages. I was quite curious, because none of the packages I had in the list were 32 bit. I believed them to be all x86_64 64 bit. After looking close inside the directory I figured out that something has triggered 129 i686 packages along with nearly 2900+ x86_64 packages. 129 i686 packages that I cleary do not want and never triggered to be downloaded. After going through the list of files (in small groups) I was able to isolate "wine x86_64" to be the cause. Wine (even called a x86_64 package triggered 129 i686 packages to be downloaded as well.. Amongst these packages there were glibc-2.23.90-30.fc25.i686.rpm and before that the group install gnome-desktop pulled glibc-2.23.90-30.fc25.x86_64.rpm package. Now there are two packages of the same core library downloaded in the same directory. Side by side. The first time - this probably (I can't redo the issue anymore because -29 is in the repository now) didn't trigger any issues. But running the two sudo command above again (a 2nd time) might have caused the x86_64 glibc package to trigger the issue with the i686 glibc package. > Could you provide the output of `rpm -qa | grep crypt` please? sure... -bash-4.3$ rpm -qa | grep crypt crypto-policies-20151104-2.gitf1cba5f.fc24.noarch ccrypt-1.10-9.fc24.x86_64 libgcrypt-1.6.5-1.fc24.x86_64 cryptsetup-1.7.2-1.fc24.x86_64 cryptsetup-libs-1.7.2-1.fc24.x86_64 -bash-4.3$ and... -bash-4.3$ rpm -qa | grep "i[0-9]86" -bash-4.3$ No 32 bit packages in the list.
I opened a bug for wine as well. Maybe they could explain why wine requires the x86_64 *and* i686 packages together. Basicly tries to install both versions. https://bugzilla.redhat.com/show_bug.cgi?id=1361643
A simple ... dnf install wine ... causes the same architecture mismatch on my regular Fedora 24 system (Please note that this time dnf is used). Trying to download x86_64 *and* i686 packages ... including glibc ... the most likely possible trigger of above issue ...
(In reply to Ali Akcaagac from comment #5) > A simple ... > > dnf install wine > > ... causes the same architecture mismatch on my regular Fedora 24 system > (Please note that this time dnf is used). Trying to download x86_64 *and* > i686 packages ... including glibc ... the most likely possible trigger of > above issue ... I cannot reproduce this. In any case, this is unrelated to the present bug report, which is about dependency issues related to libcrypt.
(In reply to Florian Weimer from comment #6) > I cannot reproduce this. In any case, this is unrelated to the present bug > report, which is about dependency issues related to libcrypt. I might have been a bit unprecise here. What I meant was this. Something triggered the libcrypt error that I reported in the initial bug report! Now understand the situation that I am in. There was an error and I needed to figure out - the best way possible - to explain why and how this might have happened. I was asked what exactly I did, that triggered this issue. I replied, that we have an infrastructure running here (at work) that downloads groups of packages and individual packages. The two commands that did this were posted above. The initial libcrypt error shows that somehow - and more importantly - why there was a mismatch (or clash or error or issue) between an x86_64 and i686 package. The question here is - where did this i686 package came from ? I believe that the x86_64 glibc package clashed with the i686 package (both downloaded in the same cache (or destdir) directory. The is just theory because I was *not* able to reproduce it again. Please also note that the version that clashed was 2.23.90-30 whereas I only receive 2.23.90-29 from rawhide now. This still leaves the question where on earth the i686 version of glibc came from. It took me a couple of hours going from one package to another package (from the list of packages) to figure out that "wine" x86_64 pulled in 192 i686 packages. This means *theoretically* that wine has triggered the i686 package of glibc and that *who knows* the x86_64 glibc has triggered the i686 glibc package... but as I said this is theory. I tried to be as specific as possible and tried to manually re-do the steps that has been done automatically. I can only offer this information. With glibc 2.23.90-29 (not -30) everything works perfectly. The question why wine requires both packages has been issued in a different bugreport... and of course you are right ... is unrelated here ... but I wanted to mention this anyways.
(In reply to Ali Akcaagac from comment #2) > sudo yum group install gnome-desktop --releasever=rawhide --disablerepo=* > --enablerepo=rawhide --downloaddir /opt/fedora --downloadonly What's the version of yum you use for this? > But the issue seem to be gone as I retried this today (just tested). Rather > than -30 it now pulls in -29. Please try again tomorrow, the rawhide repository should have -30 again.
(In reply to Florian Weimer from comment #8) > What's the version of yum you use for this? -bash-4.3$ yum --version Yum command has been deprecated, use dnf instead. See 'man dnf' and 'man yum2dnf' for more information. 3.4.3 Installed: rpm-4.13.0-0.rc1.27.fc24.x86_64 at 2016-07-25 15:47 Built : Fedora Project at 2016-04-25 13:45 Committed: Lubos Kardos <lkardos> at 2016-04-25 Installed: yum-3.4.3-509.fc24.noarch at 2016-07-26 11:09 Built : Fedora Project at 2016-02-05 12:35 Committed: Fedora Release Engineering <releng> at 2016-02-05 -bash-4.3$ dnf --version 1.1.9 Installed: dnf-0:1.1.9-2.fc24.noarch at 2016-07-25 16:00 Built : Fedora Project at 2016-05-24 15:43 Installed: rpm-0:4.13.0-0.rc1.27.fc24.x86_64 at 2016-07-25 15:47 Built : Fedora Project at 2016-04-25 13:45 -bash-4.3$ > Please try again tomorrow, the rawhide repository should have -30 again. Sure! If the issue happens again, then I will make sure to sent in log. At least something more descriptive.
The problem is reproducable every time, when I enter: sudo yum group install gnome-desktop --disablerepo=* --enablerepo=rawhide --installroot=/opt/fedora ... but .... If I enter a different installroot then the problem won't show up: sudo yum group install gnome-desktop --disablerepo=* --enablerepo=rawhide --installroot=/opt/test So my guess is, that it triggers something when it parses "fedora" as keyword within the installroot parameter. Please find attached a log generated by this command: sudo yum -d 10 -e 10 --rpmverbosity=10 group install gnome-desktop --disablerepo=* --enablerepo=rawhide --installroot=/opt/fedora &> error-log.txt ... and ... sudo strace -f -qq -o error2-log.txt yum -d 10 -e 10 --rpmverbosity=10 group install gnome-desktop --disablerepo=* --enablerepo=rawhide --installroot=/opt/fedora Hope this helps.
Created attachment 1185834 [details] error-log.txt
Created attachment 1185835 [details] error2-log.txt
(In reply to Ali Akcaagac from comment #10) > The problem is reproducable every time, when I enter: > > sudo yum group install gnome-desktop --disablerepo=* --enablerepo=rawhide > --installroot=/opt/fedora Please provide the .repo file this command uses. I can't reproduce on Fedora 23 or 24. “rawhide” is not among the repositories installed by default.
(In reply to Florian Weimer from comment #13) > Please provide the .repo file this command uses. Sure! dnf install fedora-repos-rawhide.noarch fe884c59a4ff1ff301d9828aba8a0074 fedora-repos-rawhide-24-1.noarch.rpm Find it attached: c4002c0dc336b459a47b50d40441c1d4 fedora-rawhide.repo More info: The file /bin/yum-deprecated is being copied over /bin/yum to replace the dnf-wrapper! I will also give you my yum.conf file. I keep the cache (downloaded files) which might be an idea ?
Created attachment 1186121 [details] rawhide repo norarch
Created attachment 1186125 [details] plain rawhide repo file
Created attachment 1186130 [details] my yum.conf file
(In reply to Ali Akcaagac from comment #10) > The problem is reproducable every time, when I enter: > > sudo yum group install gnome-desktop --disablerepo=* --enablerepo=rawhide > --installroot=/opt/fedora > > ... but .... > > If I enter a different installroot then the problem won't show up: > > sudo yum group install gnome-desktop --disablerepo=* --enablerepo=rawhide > --installroot=/opt/test I cannot reproduce the dependency on the directory name of the installation root. I don't see a cross-architecture conflict, either. I can install both i686 and x86_64 packages at the same time (but I have to choose whether I want to libcrypt or libcrypt-nss, I cannot have both). In any case, this works fine with dnf, and libcrypt-nss is chosen as expected. This is a bug in the yum dependency solver.
Created attachment 1189142 [details] Output of fedpkg mockbuild Hi, I encountered the same error message as Ali when I was rebasing cups to newer version on fedora 25 branch. Attaching output, when I ran '$ fedpkg mockbuild'.
'$ fedpkg local' and '$ fedpkg build --scratch --srpm' works fine, but still problem with '$ fedpkg mockbuild'
*** Bug 1366041 has been marked as a duplicate of this bug. ***
I got this problem trying to build a Fedora 25 live image using livecd-creator: Error creating Live CD : Failed to build transaction : libcrypt conflicts with libcrypt-nss-2.24-3.fc25.x86_64 libcrypt-nss conflicts with libcrypt-2.24-3.fc25.x86_64
I have the same problem as Chris Smart above, libcrypt conflicts with libcrypt-nss-2.24-3.fc25.x86_64 libcrypt-nss conflicts with libcrypt-2.24-3.fc25.x86_64 when trying to use livecd-creator
same bug as chris and freebird1to1 when I try every kickwtart with livecd-creator
I hit the same bug... Workaround is described here https://bugzilla.redhat.com/show_bug.cgi?id=1324623#c15 I add the following lines to fedora-live-base.ks -libcrypt libcrypt-nss This solved the issue. However, I ran into another issue that is related to resize2fs. It aborted with error -11 during resizing the FS image. To fix this I rebuilt e2fsprogs-1.43.3-1.fc26.src.rpm for Fedora 25. This is a temporarily fix. I downloaded this package from Fedora build system. Here is the URL: https://kojipkgs.fedoraproject.org//packages/e2fsprogs/1.43.3/1.fc26/src/e2fsprogs-1.43.3-1.fc26.src.rpm Fedora 25 is currently using e2fsprogs-1.43.1-2. After upgrading e2fsprogs, the livecd built succeeded.
Hitting the same issue with mock on fedora25: --> Processing Conflict: libcrypt-2.24-3.fc25.x86_64 conflicts libcrypt-nss --> Finished Dependency Resolution Error: libcrypt conflicts with libcrypt-nss-2.24-3.fc25.x86_64 You could try using --skip-broken to work around the problem Error: libcrypt-nss conflicts with libcrypt-2.24-3.fc25.x86_64 You could try running: rpm -Va --nofiles --nodigest
Some more details, this happend when trying to install @buildsys-build group: EBUG util.py:502: Executing command: ['/usr/bin/yum-deprecated', '--installroot', '/var/lib/mock/fedora-25-x86_64-2474d86945a1de9c6d14549ec2401b9c-8291/root/', '--releasever', '25', 'install', '@buildsys-build', 'git', 'python', 'python-dulwich', 'python-setuptools', 'yum', 'yum-utils', '--setopt=tsflags=nocontexts'] with env {'PS1': '<mock-chroot> \\s-\\v\\$ ', .... DEBUG util.py:421: Yum command has been deprecated, use dnf instead. DEBUG util.py:421: See 'man dnf' and 'man yum2dnf' for more information. DEBUG util.py:421: Error: libcrypt conflicts with libcrypt-nss-2.24-3.fc25.x86_64 DEBUG util.py:421: Error: libcrypt-nss conflicts with libcrypt-2.24-3.fc25.x86_64 DEBUG util.py:421: You could try using --skip-broken to work around the problem DEBUG util.py:421: You could try running: rpm -Va --nofiles --nodigest DEBUG util.py:557: Child return code was: 1 DEBUG util.py:180: kill orphans I tested it also with solely trying to install @buildsys-build group, and getting the same error. A simple workaround is to add the 'libcrypt-nss' package in the same dnf/yum installation command.
(In reply to Nadav Goldin from comment #27) > Some more details, this happend when trying to install @buildsys-build group: > > EBUG util.py:502: Executing command: ['/usr/bin/yum-deprecated', > '--installroot', > '/var/lib/mock/fedora-25-x86_64-2474d86945a1de9c6d14549ec2401b9c-8291/root/', > '--releasever', '25', 'install', '@buildsys-build', 'git', 'python', > 'python-dulwich', 'python-setuptools', 'yum', 'yum-utils', > '--setopt=tsflags=nocontexts'] with env {'PS1': '<mock-chroot> \\s-\\v\\$ ', > .... You need to figure out why yum-deprecated is used. The Fedora 25 package set is only fully compatible with DNF.
(In reply to Florian Weimer from comment #28) > You need to figure out why yum-deprecated is used. The Fedora 25 package > set is only fully compatible with DNF. #27 is using mock which still depends on yum. util.py: line 892 config_opts['yum_command'] = '/usr/bin/yum-deprecated' package_manager.py: line 177 if os.path.exists('/usr/bin/yum-deprecated'):
Same problem here. I build live system: Error creating Live CD : Failed to build transaction : libcrypt conflicts with libcrypt-nss-2.24-3.fc25.i686 libcrypt-nss conflicts with libcrypt-2.24-3.fc25.i686
(In reply to Ali Akcaagac from comment #29) > #27 is using mock which still depends on yum. I was running into the same issue, but using "mock --dnf" works for me.
(In reply to Florian Weimer from comment #28) > (In reply to Nadav Goldin from comment #27) > > Some more details, this happend when trying to install @buildsys-build group: > > > > EBUG util.py:502: Executing command: ['/usr/bin/yum-deprecated', > > '--installroot', > > '/var/lib/mock/fedora-25-x86_64-2474d86945a1de9c6d14549ec2401b9c-8291/root/', > > '--releasever', '25', 'install', '@buildsys-build', 'git', 'python', > > 'python-dulwich', 'python-setuptools', 'yum', 'yum-utils', > > '--setopt=tsflags=nocontexts'] with env {'PS1': '<mock-chroot> \\s-\\v\\$ ', > > .... > > You need to figure out why yum-deprecated is used. The Fedora 25 package > set is only fully compatible with DNF. Thanks, using dnf indeed resolves the issue. Though our infrastructure is built around el7 machines, which trigger various mock chroots (el7/fc23-25) and switching all of those machines to fedora is not an option. Adding this to the fc25 mock configuration allowed me to still use el7 host(with yum) to build fc25 chroots with mock: config_opts['chroot_setup_cmd'] = 'install @buildsys-build libcrypt-nss' I guess it made 'yum' resolve the weak dependency somehow, maybe by coincidence. So I think the subject of this BZ is still relevant, at least until el7(8?) gets dnf.
(In reply to Nadav Goldin from comment #32) > (In reply to Florian Weimer from comment #28) >> You need to figure out why yum-deprecated is used. The Fedora 25 package >> set is only fully compatible with DNF. > > Thanks, using dnf indeed resolves the issue. > Though our infrastructure is built around el7 machines, which trigger > various mock chroots (el7/fc23-25) and switching all of those machines to > fedora is not an option. mock in EPEL is supposed to use dnf if available. This was fixed as bug 1405783.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
Again same error as Ali in comment #0 when using 'fedpkg mockbuild', this time on f26 branch.
(In reply to Zdenek Dohnal from comment #35) > Again same error as Ali in comment #0 when using 'fedpkg mockbuild', this > time on f26 branch. Are you on Fedora? This is most likely a local mock configuration issue. You need to switch to DNF.
(In reply to Florian Weimer from comment #36) > (In reply to Zdenek Dohnal from comment #35) > > Again same error as Ali in comment #0 when using 'fedpkg mockbuild', this > > time on f26 branch. > > Are you on Fedora? This is most likely a local mock configuration issue. > You need to switch to DNF. Yes, I am. I forgot that mock will have some config file, where I can set '--dnf' as comment #31 says. Sorry for meaningless comment.
“fedpkg mockbuild” can trigger such errors due to bug 1428929.
More to come: Please also add `coreutils-single' to the list of excludes as well as some other packages that will follow up (e.g. curl). https://bugzilla.redhat.com/show_bug.cgi?id=1446494 I filled a bugreport for coreutils earlier this day (which got closed). I am not sure whether the owner understood that even Fedora toolchain is affected by this issue (tried to explain this). So in case things break again. Be told which packages need to be excluded.
I am going to abandon this report and mark it as closed. DNF now supports everything required for *our* tasks. If someone feel that this should stay open, then please feel free to reopen.