Description of problem: The new "mock --new-chroot" default in copr is causing problems for building Haskell packages in Copr, due to errors in root.log from the install scripts: eg https://copr-be.cloud.fedoraproject.org/results/petersen/hlint/fedora-rawhide-x86_64/00571545-hlint/root.log.gz : : DEBUG util.py:450: warning: %post(libffi-devel-3.1-11.fc27.x86_64) scriptlet failed, exit status 1 DEBUG util.py:450: Installing : ghc-compiler-8.0.2-57.fc26.x86_64 96/149 DEBUG util.py:450: Running scriptlet: ghc-compiler-8.0.2-57.fc26.x86_64 96/149 DEBUG util.py:450: Installing : ghc-base-devel-4.9.1.0-57.fc26.x86_64 97/149 DEBUG util.py:450: Running scriptlet: ghc-base-devel-4.9.1.0-57.fc26.x86_64 97/149 DEBUG util.py:450: /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory DEBUG util.py:450: Installing : ghc-transformers-devel-0.5.2.0-57.fc26.x86_64 98/149 DEBUG util.py:450: Running scriptlet: ghc-transformers-devel-0.5.2.0-57.fc26.x86_64 98/149 DEBUG util.py:450: /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory DEBUG util.py:450: Installing : ghc-array-devel-0.5.1.1-57.fc26.x86_64 99/149 DEBUG util.py:450: Running scriptlet: ghc-array-devel-0.5.1.1-57.fc26.x86_64 99/149 DEBUG util.py:450: /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory DEBUG util.py:450: Installing : ghc-deepseq-devel-1.4.2.0-57.fc26.x86_64 100/149 DEBUG util.py:450: Running scriptlet: ghc-deepseq-devel-1.4.2.0-57.fc26.x86_64 100/149 DEBUG util.py:450: /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory DEBUG util.py:450: Installing : ghc-bytestring-devel-0.10.8.1-57.fc26.x86_64 101/149 DEBUG util.py:450: Running scriptlet: ghc-bytestring-devel-0.10.8.1-57.fc26.x86_64 101/149 : : Version-Release number of selected component (if applicable): mock-1.4.2-1 mock-1.3.4-1 How reproducible: 100% Steps to Reproduce: 1. mock --new-chroot -r fedora-rawhide-x86_64 hlint-2.0.9-1.src.rpm Actual results: See above Expected results: No errors Additional info: There is no problem with "mock --old-chroot".
I opened a bug upstream too https://github.com/rpm-software-management/mock/issues/88
The error is because of: ``` DEBUG util.py:450: Running scriptlet: libffi-devel-3.1-11.fc27.x86_64 95/149 DEBUG util.py:450: install-info: No such file or directory for /dev/null DEBUG util.py:450: warning: %post(libffi-devel-3.1-11.fc27.x86_64) scriptlet failed, exit status 1 ``` So libffi-devel calls in %postun /sbin/install-info but `info` is not listed as requires of that package. So the fix is that libffi should add Requires(post): info to its spec file.
It lists: Requires(post): /sbin/install-info though. Is that not sufficient?
That should be enough. It is strange. Why dnf did not installed `info` in #0? I am puzzled.
I just protected the install-info scriplets, but I don't think that is the root problem. http://pkgs.fedoraproject.org/cgit/rpms/libffi.git/commit/?id=e3a78d20c9b8e60087522e235b181644bc05eb0c
libffi-3.1-12.fc27 and libffi-3.1-12.fc26
libffi-3.1-12.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-190ee628d4
libffi-3.1-12.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-190ee628d4
I tested with: mock --new-chroot --enablerepo=local -r fedora-rawhide-x86_64 hlint-2.0.9-1.src.rpm and even with libffi-3.1-12.fc27 and still get the same libHSterminfo-0.4.0.2-ghc8.0.2.so errors.
libffi-3.1-12.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
Minimal reproducer is: mock -r fedora-rawhide-x86_64 init # first install works fine mock -r fedora-rawhide-x86_64 install libffi-devel mock -r fedora-rawhide-x86_64 clean # second install fails with: install-info: No such file or directory for /dev/null mock -r fedora-rawhide-x86_64 install libffi-devel Relevant part of strace: 7414 execve("/sbin/install-info", ["/sbin/install-info", "--delete", "--info-dir=/usr/share/info", "/usr/share/info/libffi.info.gz"], 0x5648d76f2490 /* 24 vars */) = 0 7414 brk(NULL) = 0x55a49bacf000 7414 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb9cc9a7000 7414 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 7414 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 7414 fstat(3, {st_mode=S_IFREG|0644, st_size=13117, ...}) = 0 7414 mmap(NULL, 13117, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb9cc9a3000 7414 close(3) = 0 7414 openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3 7414 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\"\0\0\0\0\0\0"..., 832) = 832 7414 fstat(3, {st_mode=S_IFREG|0755, st_size=94104, ...}) = 0 7414 mmap(NULL, 2187272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb9cc56b000 7414 mprotect(0x7fb9cc581000, 2093056, PROT_NONE) = 0 7414 mmap(0x7fb9cc780000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7fb9cc780000 7414 mmap(0x7fb9cc781000, 8, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb9cc781000 7414 close(3) = 0 7414 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 7414 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\22\2\0\0\0\0\0"..., 832) = 832 7414 fstat(3, {st_mode=S_IFREG|0755, st_size=2261216, ...}) = 0 7414 mmap(NULL, 4090400, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb9cc184000 7414 mprotect(0x7fb9cc361000, 2097152, PROT_NONE) = 0 7414 mmap(0x7fb9cc561000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1dd000) = 0x7fb9cc561000 7414 mmap(0x7fb9cc567000, 14880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb9cc567000 7414 close(3) = 0 7414 mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb9cc9a0000 7414 arch_prctl(ARCH_SET_FS, 0x7fb9cc9a0700) = 0 7414 mprotect(0x7fb9cc561000, 16384, PROT_READ) = 0 7414 mprotect(0x7fb9cc780000, 4096, PROT_READ) = 0 7414 mprotect(0x55a499f76000, 4096, PROT_READ) = 0 7414 mprotect(0x7fb9cc9a9000, 4096, PROT_READ) = 0 7414 munmap(0x7fb9cc9a3000, 13117) = 0 7414 brk(NULL) = 0x55a49bacf000 7414 brk(0x55a49baf0000) = 0x55a49baf0000 7414 brk(NULL) = 0x55a49baf0000 7414 open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 7414 fstat(3, {st_mode=S_IFREG|0644, st_size=113015632, ...}) = 0 7414 mmap(NULL, 113015632, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb9c55bc000 7414 close(3) = 0 7414 openat(AT_FDCWD, "/dev/null", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 close(0) = 0 7414 open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 0 7414 fstat(0, {st_mode=S_IFREG|0644, st_size=2997, ...}) = 0 7414 read(0, "# Locale name alias data base.\n#"..., 4096) = 2997 7414 read(0, "", 4096) = 0 7414 close(0) = 0 7414 open("/usr/share/locale/cs_CZ.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 open("/usr/share/locale/cs_CZ.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 open("/usr/share/locale/cs_CZ/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 open("/usr/share/locale/cs.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 open("/usr/share/locale/cs.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 open("/usr/share/locale/cs/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 open("/usr/share/locale/cs_CZ.UTF-8/LC_MESSAGES/texinfo.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 open("/usr/share/locale/cs_CZ.utf8/LC_MESSAGES/texinfo.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 open("/usr/share/locale/cs_CZ/LC_MESSAGES/texinfo.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 open("/usr/share/locale/cs.UTF-8/LC_MESSAGES/texinfo.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 open("/usr/share/locale/cs.utf8/LC_MESSAGES/texinfo.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 open("/usr/share/locale/cs/LC_MESSAGES/texinfo.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 7414 write(2, "install-info: ", 14) = 14 7414 write(2, "No such file or directory for /d"..., 39) = 39 7414 write(2, "\n", 1) = 1 7414 exit_group(1) = ? 7414 +++ exited with 1 +++
Strange. While Dan was able to reproduce it (I was sitting beside him) I cannot reproduce it. It seems that neither systemd-nspawn nor selinux is the culprint (Dan tried both). According the strace the /dev/null magically disappear for that scriptlet. The strange part is that Dan was able to only reproduce it when running via mock. When he run that command by hand, then it worked flawlessly. I suspect something in rpm. Can someone from rpm team investigate it?
I have a hard time believing that this is caused by rpm. The /dev/null we are talking here is the one from within the mock build root. rpm -qf /dev/null file /dev/null is not owned by any package So rpm should not even touch that file. So to me it looks like mock fails to set up /dev properly in the build root.
> So to me it looks like mock fails to set up /dev properly in the build root. But if you run mock interactively, it exist. Even if you run strace on mock it exists few lines above, but then suddenly disappear.
This /dev/null thing for install-info seems to affect more than just libffi-devel. If you run `mock --new-chroot -r fedora-26-x86_64 --scrub=all` first, then `mock --new-chroot -r fedora-26-x86_64 --init`, there are a few other cases: Installing : readline-7.0-5.fc26.x86_64 31/164 install-info: No such file or directory for /dev/null install-info: No such file or directory for /dev/null Installing : grep-3.1-1.fc26.x86_64 33/164 install-info: No such file or directory for /dev/null Installing : sed-4.4-1.fc26.x86_64 42/164 install-info: No such file or directory for /dev/null
I can't reproduce it at all =( Can someone give me reliable reproducer?
Created attachment 1302424 [details] script output from mock Running mock with hlint or any other haskell package, like in the very first comment, still reproduces this bug. Attaching the output of building the current hlint package with mock-1.4.2-1.fc27.noarch and latest everything from rawhide.
Well, /dev is empty when it is installing package. You should rbind it from host system.
no idea how to debug it, but _setup_devices() is not called.
well, sure: if not util.USE_NSPAWN: self._setup_devices()
Is that sufficient to fix the issue in mock? This issue is breaking all Haskell builds in copr! So it would be nice to have a fix or workaround soon. :)
I have absolutely no idea, I'm not mock developer ;)
> well, sure: Because when using nspawn then /dev is being populated by systemd-nspawn. So mock should not touch it.
Anything I can do to help with this? This issue prevents building any haskell packages in Copr... Any chance of adding a toggle in copr to turn off nspawn until this is fixed?
OK. I found the culprint. This happen with initial population of chroot. I.e the /dev/null initialy exists, but when postscript is run, then because dnf is executed with --installroot and rpm is run inside the chroot. But /dev is not mounted there so /dev/null really does not exists yet. And we cannot rely on nspawn to populate because this is initial command which is not executed within chroot, but from host, because there is no binary installed in chroot yet. So Igor was right in #20. Commit 90e2485
mock-1.4.3-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-53f9c9cb51
mock-1.4.3-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-204acb9aa4
mock-1.4.3-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4ee5b66a4c
mock-1.4.3-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-53f9c9cb51
mock-1.4.3-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4ee5b66a4c
mock-1.4.3-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-204acb9aa4
Great news, thanks a lot!
mock-1.4.3-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
The original bug is still present. Installing the builddeps for haskell packages is full of errors along the lines of: DEBUG util.py:450: /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory and the build ultimately fails when it is unable to open /usr/lib64/ghc-8.0.2/package.conf.d/package.cache.
David is right - I still see the errors in root.log too :-(
How can we reproduce and debug this more?
On up-to-date F26: $ fedpkg clone ghc $ fedpkg mockbuild ... Installing : ghc-terminfo-0.4.0.2-59.fc27.x86_64 31/132 ... Installing : ghc-base-devel-4.9.1.0-59.fc27.x86_64 99/132 Running scriptlet: ghc-base-devel-4.9.1.0-59.fc27.x86_64 99/132 /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory ... $ ldd /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/ghc-8.0.2/bin/ghc-pkg linux-vdso.so.1 (0x00007ffdbf7e2000) libHSterminfo-0.4.0.2-ghc8.0.2.so => /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/ghc-8.0.2/bin/../terminfo-0.4.0.2/libHSterminfo-0.4.0.2-ghc8.0.2.so (0x00007fa6fea87000) ... $ rpm -q mock mock-1.4.3-1.fc26.noarch $ /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/ghc-8.0.2/bin/ghc-pkg ghc-pkg: missing command For usage information see 'ghc-pkg --help'. $ sudo chroot /var/lib/mock/fedora-rawhide-x86_64/root/ # /usr/lib64/ghc-8.0.2/bin/ghc-pkg /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory So the file is there, but it doesn't run from inside the chroot. # strace /usr/lib64/ghc-8.0.2/bin/ghc-pkg execve("/usr/lib64/ghc-8.0.2/bin/ghc-pkg", ["/usr/lib64/ghc-8.0.2/bin/ghc-pkg"], 0x7fff0e2ec2f0 /* 21 vars */) = 0 brk(NULL) = 0x14a9000 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3e1b94d000 readlink("/proc/self/exe", 0x7ffff11744b0, 4096) = -1 ENOENT (No such file or directory) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "tls/libHSterminfo-0.4.0.2-ghc8.0.2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "libHSterminfo-0.4.0.2-ghc8.0.2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=14855, ...}) = 0 mmap(NULL, 14855, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3e1b949000 close(3) = 0 openat(AT_FDCWD, "/lib64/tls/libHSterminfo-0.4.0.2-ghc8.0.2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/tls", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 openat(AT_FDCWD, "/lib64/libHSterminfo-0.4.0.2-ghc8.0.2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64", {st_mode=S_IFDIR|0555, st_size=20480, ...}) = 0 openat(AT_FDCWD, "/usr/lib64/tls/libHSterminfo-0.4.0.2-ghc8.0.2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/tls", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 openat(AT_FDCWD, "/usr/lib64/libHSterminfo-0.4.0.2-ghc8.0.2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64", {st_mode=S_IFDIR|0555, st_size=20480, ...}) = 0 writev(2, [{iov_base="/usr/lib64/ghc-8.0.2/bin/ghc-pkg", iov_len=32}, {iov_base=": ", iov_len=2}, {iov_base="error while loading shared libra... $ readelf -d /usr/lib64/ghc-8.0.2/bin/ghc-pkg|grep RPATH 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/../terminfo-0.4.0.2:$ORIGIN/../ghc-boot-8.0.2:$ORIGIN/../ghc-boot-th-8.0.2:$ORIGIN/../Cabal-1.24.2.0:$ORIGIN/../process-1.4.3.0:$ORIGIN/../pretty-1.1.3.3:$ORIGIN/../directory-1.3.0.0:$ORIGIN/../unix-2.7.2.1:$ORIGIN/../time-1.6.0.1:$ORIGIN/../filepath-1.4.1.1:$ORIGIN/../binary-0.8.3.0:$ORIGIN/../containers-0.5.7.1:$ORIGIN/../bytestring-0.10.8.1:$ORIGIN/../deepseq-1.4.2.0:$ORIGIN/../array-0.5.1.1:$ORIGIN/../base-4.9.1.0:$ORIGIN/../integer-gmp-1.0.0.1:$ORIGIN/../ghc-prim-0.5.0.0:$ORIGIN/../rts] So the observed errors are consistent with /proc not being mounted: ghc-pkg doesn't load because rpath resolution is broken. $ORIGIN cannot be queried without /proc. I see two solutions: 1. change haskell packaging to use an rpath which is absolute and does not use $ORIGIN. 2. change mock to also populate /proc. I guess option 2. is more realistic.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
Any progress on this? It looks like the same kind of thing as /dev, where it's not being populated when using nspawn but nspawn isn't used for setting up the chroot: if not util.USE_NSPAWN: self.managed_mounts = [ FileSystemMountPoint(filetype='proc', device='mock_chroot_proc', path=rootObj.make_chroot_path('/proc')), FileSystemMountPoint(filetype='sysfs', device='mock_chroot_sys', path=rootObj.make_chroot_path('/sys')), ]
mock-1.4.3-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Reopening Thank you, Zbigniew I could patch ghc to not use $ORIGIN as a workaround, but I think it is better to fix mock for this of course.
mock-1.4.3-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
Miroslav, asking again, any chance of an --old-chroot setup option in Copr until this is fixed? Can this be fixed easily in a similar way to /dev/ ?
Is there any update on this?
Yes I'd actually also be interested. Is there anything to help out here to get this working again?
I cannot reproduce it. With mock-1.4.6. fedpkg clone ghc cd ghc fedpkg mockbuild I tried even f26 branch. There are some errors, but none related to /dev or /proc Does it still happen to you?
(In reply to Miroslav Suchý from comment #46) > I cannot reproduce it. With mock-1.4.6. > > fedpkg clone ghc > cd ghc > fedpkg mockbuild No need to build the whole of ghc! :) I suggest building any other Haskell package (ghc-*): eg I have been testing with hlint. > I tried even f26 branch. There are some errors, but none related to /dev or > /proc The errors are indirectly due to missing /proc as explained earlier in comment 37. > Does it still happen to you? Yes $ mock --new-chroot -r fedora-rawhide-x86_64 hlint-2.0.9-1.src.rpm : Installing : ghc-compiler-8.0.2-59.fc27.x86_64 96/149 Running scriptlet: ghc-compiler-8.0.2-59.fc27.x86_64 96/149 Installing : ghc-base-devel-4.9.1.0-59.fc27.x86_64 97/149 Running scriptlet: ghc-base-devel-4.9.1.0-59.fc27.x86_64 97/149 /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory Installing : ghc-transformers-devel-0.5.2.0-59.fc27.x86_64 98/149 Running scriptlet: ghc-transformers-devel-0.5.2.0-59.fc27.x86_64 98/149 /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory : : :
Fixed in commit: * b8b721b (HEAD -> devel) mount /proc and /sys before executing any PM command [RHBZ#1467299]
(In reply to Miroslav Suchý from comment #48) > Fixed in commit: > * b8b721b (HEAD -> devel) mount /proc and /sys before executing any PM > command [RHBZ#1467299] Great, I don't see any errors when installing ghc-*-devel packages now. So the commit seems to fix the issue now. Maybe someone else can confirm too? When can we expect a release and for it to be deployed on Copr? :-)
There must be a release of Mock first (ETA December). Then it must hit Fedora stable (+ 4 days). Then it gets installed on Copr builders.
It seems now many of the copr builders have mock-1.3.4 but some have 1.4.7. Not sure if and when this changed, but I didn't know about.
(In reply to Jens Petersen from comment #51) > It seems now many of the copr builders have mock-1.3.4 but some have 1.4.7. > > Not sure if and when this changed, but I didn't know about. There should be mock-1.3.4, which is the current version in infrastructure repos (1.4.7 was on builders that were spawned before mock-1.3.4 with epoch '2' got into production).
(In reply to Jens Petersen from comment #49) > (In reply to Miroslav Suchý from comment #48) > > Fixed in commit: > > * b8b721b (HEAD -> devel) mount /proc and /sys before executing any PM > > command [RHBZ#1467299] > > Great, I don't see any errors when installing ghc-*-devel packages now. > So the commit seems to fix the issue now. > Maybe someone else can confirm too? > Yes, the latest mock HEAD fixes also this build https://copr.fedorainfracloud.org/coprs/g/weldr/bdcs-haskell-deps/build/682256/. So it is now just matter of releasing it.
mock-1.4.8-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-e954edb1bb
mock-1.4.8-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ac67357aa1
mock-1.4.8-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0c8682fd2a
mock-1.4.8-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e954edb1bb
mock-1.4.8-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ac67357aa1
mock-1.4.8-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0c8682fd2a
mock-1.4.8-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.4.8-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.4.8-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
This or something similar seems to be happening again. I opened bug 2166028.