bug#32247: HandBrake shows no icons
Hello, Ben Sturmfels writes: > On Mon, 23 Jul 2018, Andreas Enge wrote: > > I just ran the current version of Handbrake in Guix and can see icons, > so it may be that this has been fixed elsewhere or through upgrades. > Would you mind testing again please to see if this is fixed for you? I just tested and can see the icons as well without doing anything special. Given that this is now a two-year old bug, I'll be closing it; if someone encounters this again, please reopen. Thanks, -- Sarah
bug#47260: Package GNU MediaGoblin as a Guix service
I've now written up all the progress in our MediaGoblin Guix channel README: https://git.sr.ht/~mediagoblin/mediagoblin-guix/tree/master/item/README.md In short MediaGoblin can be installed as a Guix package with no external dependencies or Python virtualenvs. After some slightly clumsy static files configuration the web interface runs successfully based on an SQLite database. The Celery backend run successfully. Images and video can be uploaded and viewed successfully. Video plays via the stock browser player but doesn't allow selection of video quality. Audio is broken pending merge of updated libsndfile from Guix's "core-updates" branch. To try it out, follow the instructions in "Install via load-path", followed by "Run MediaGoblin" from the README mentioned above. Regards, Ben
bug#31991: Packages enki and aseba fail. Organizations behind software restructured
Hi, just following up on this old bug. Björn Höfling writes: > I saw that enki fails due to Qt 5.11. Enki is now building fine. > Note that aseba doesn't have a good build history anyway: > > https://hydra.gnu.org/job/gnu/master/aseba-1.6.0-0.3b35de8.x86_64-linux/all > https://hydra.gnu.org/job/gnu/master/aseba-1.6.0-0.3b35de8.i686-linux/all > https://hydra.gnu.org/job/gnu/master/aseba-1.6.0-0.3b35de8.armhf-linux > > Anyone using it? > > General note: > > As far as I know, this package is here for the Thymio robot, not for > the asaba Framework as such. > > In spring 2018, Mobsya (the organisation behind Thymio) decided to go > their own way, because they don't have the capacity to maintain the > whole aseba framework as such. Maintainer wanted for the old aseba > project. See this announcement for more details: > > https://github.com/aseba-community/aseba#thymio-and-mobsya-fork > https://docs.google.com/document/d/1ijY2dZR2TbSySMqFfbCgG_ifZPGoxrAQaVuZVQZHKlY/edit# > > So, in the long term, we should base the package definition on their > repository: > > https://github.com/Mobsya/aseba > > They don't have a released version yet. And they pull in a lot more > dependencies via git. It looks like they have a released version now (2.2.0, in fact). There is also the Debian-maintained fork of the original: https://salsa.debian.org/science-team/aseba Since aseba continues to fail building, we should either remove it, or switch to one of those two. -- Sarah
bug#31970: epiphany: Strange "XXXXXXXXXXXXX..." entries in library RPATHs
Hi, Mark H Weaver writes: > Since the upgrade from epiphany-3.24.4 to 3.28.1 in commit > fc5c5b92cf7a1f6d65079f3840df502edcf58f50, > > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=fc5c5b92cf7a1f6d65079f3840df502edcf58f50 > > which also changed the build-system from 'glib-or-gtk-build-system' to > 'meson-build-system', warnings started appearing in the build logs for > epiphany complaining about "XX" > appearing in the RPATH of the built libraries. Closing this old issue. (On current master, the build logs no longer show that error, and `readelf -d' reports no such bogus entries.) -- Sarah
bug#31403: Font installed in non-default profile doesn't appear.
Maxim Cournoyer writes: George Clemmer (2018-05-08 20:04 -0400) wrote: > In a "headless" vm-image (sysi29.scm, attached), "font-dejavu" installed > by manifest (attached) into the "empty" default profile ... > > 'guix package -m manifest' > > ... appears in the emacs 'M-x menu-set-font' choice box. But it doesn't > appear with the same manifest installed in the "foo" profile ... > > Assuming you run Emacs in that foo profile and don't see the font, > that's probably because XDG_DATA_DIRS is unset in that other profile. > glib is one of the package setting that variable. > > I'm merging this bug with 22138, which would fix the root cause. Will this be fixed by #50358? If so, could you close this when that is merged? Thanks, -- Sarah
bug#30210: pandoc not reproducible
Hello, Ricardo Wurmus writes: > l...@gnu.org (Ludovic Courtès) writes: > >> Ricardo Wurmus skribis: >> The only file that differs is this: /gnu/store/8ynsssfjjdjbawndmjlnjlqrh027rl9g-ghc-pandoc-1.17.2-check/lib/ghc-7.10.2/ghc-pandoc-1.17.2.conf.d/package.cache /gnu/store/8ynsssfjjdjbawndmjlnjlqrh027rl9g-ghc-pandoc-1.17.2/lib/ghc-7.10.2/ghc-pandoc-1.17.2.conf.d/package.cache >>> >>> At least they seem to contain the same strings albeit in a different >>> order. “diff <(strings a|sort) <(strings b|sort)” shows no >>> differences. (Of course there could be other differences than order, >>> which simply don’t appear to be strings.) >> >> That sounds like code using readdir(2) and not sorting the returned >> entries, as was the case for gtk-update-icon-cache or whatever it’s >> called. > > This package.cache problem has been fixed with commit > 5de93cdba77db3777f8f026c029acadd7b8bdde3. > > Unfortunately it is now bin/pandoc that differs across builds. > > -- > Ricardo I found this old bug. I tested both pandoc and ghc-pandoc and it looks like this is no longer an issue (perhaps fixed partially in #43834), so I'm closing. Please reopen otherwise. Thanks, -- Sarah
bug#50557: Unable to access remote logs
Hello Guix, For whatever reason, it seems build logs are not available from ci.guix.gnu.org and bordeaux.guix.gnu.org. "Invoking guix publish" says that they should be available at /log/store-name, but... --8<---cut here---start->8--- $ guix build hello 0.1 MB will be downloaded: /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 substituting /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10... downloading from https://ci.guix.gnu.org/nar/lzip/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 ... hello-2.10 51KiB 249KiB/s 00:00 [##] 100.0% /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 $ wget https://ci.guix.gnu.org/log/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 --2021-09-12 18:05:39-- https://ci.guix.gnu.org/log/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 Resolving ci.guix.gnu.org (ci.guix.gnu.org)... 141.80.181.40 Connecting to ci.guix.gnu.org (ci.guix.gnu.org)|141.80.181.40|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2021-09-12 18:05:40 ERROR 404: Not Found. $ guix build hello --log-file guix build: error: no build log for '/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10' --8<---cut here---end--->8--- -- Sarah
bug#30591: Vinagre segmentation fault - and gdb cannot find symbols?
Hi Chris, Chris Marusich writes: > The backtrace makes it look like maybe the segfault occurred in gtk-vnc, > not vinagre itself, so I guess I'll need to customize more packages to > build more debug outputs and try again... > > I'll keep poking at this as I get time. If anyone has any tips, I'd > really appreciate it. I can't replicate this, and it's rather old, so I'm closing this. It looks like this may have been an issue with freerdp [0] which was since fixed. Please reopen if this is still an issue. Thanks, [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898448 -- Sarah
bug#30512: phonon-backend-gstreamer has a ./gnu/store subdirectory
Hi, Ricardo Wurmus writes: > The package phonon-backend-gstreamer is configured to install icons in > $out/gnu/store/…-phonon-backend-gstreamer-…/ instead of $out. $ find /gnu/store/79kjp62wsdlrqzjzg920dgz0acjhqdkk-phonon-backend-gstreamer-4.10.0 -name gnu $ This is no longer the case, so closing. -- Sarah
bug#50556: Clang retains extraneous references to GCC (and zlib)
Hello Guix, I recently noticed that Clang has some extra references: --8<---cut here---start->8--- $ guix size clang store item totalself /gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0 979.2 496.0 50.7% /gnu/store/rmc131fpy2hv408a1awd2wm7kiwyf7d7-llvm-12.0.0234.1 162.7 16.6% /gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0 178.5 107.3 11.0% /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2146.2 57.1 5.8% /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31 38.4 36.7 3.8% /gnu/store/f0ca0lf64bw08srv1bj7gkg6ag0sbdb2-gcc-7.5.0-lib 71.0 32.6 3.3% /gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib 71.0 32.6 3.3% /gnu/store/nzfhh1rm85lx2p5plbx45qqj82pcv5hp-clang-runtime-12.0.095.9 24.9 2.5% /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32 88.0 17.0 1.7% /gnu/store/c8w9z48vvx2a3q3k44ch9yn00wk1qwhb-libxml2-2.9.10 81.1 7.9 0.8% /gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16 1.6 1.6 0.2% /gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16 39.4 1.0 0.1% /gnu/store/r7k859hmcnkazf492fasqvk25jflnfk6-xz-5.2.473.0 0.9 0.1% /gnu/store/g2s5jfkfd4k973wb58476b1bbv9zpm6m-zlib-1.2.11 38.6 0.2 0.0% /gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11 71.2 0.2 0.0% /gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3 71.2 0.2 0.0% total: 979.2 MiB --8<---cut here---end--->8--- It retains references two *two* separate gcc-7.5.0-lib outputs, two separate zlib-1.2.11 outputs, and a gcc-7.5.0 output (clang shouldn't need GCC, right?) --8<---cut here---start->8--- $ guix gc --references /gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0 /gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2 /gnu/store/c8w9z48vvx2a3q3k44ch9yn00wk1qwhb-libxml2-2.9.10 /gnu/store/f0ca0lf64bw08srv1bj7gkg6ag0sbdb2-gcc-7.5.0-lib /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31 /gnu/store/nzfhh1rm85lx2p5plbx45qqj82pcv5hp-clang-runtime-12.0.0 /gnu/store/rmc131fpy2hv408a1awd2wm7kiwyf7d7-llvm-12.0.0 /gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0 /gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0 --8<---cut here---end--->8--- Okay, so only the gcc references are direct. Where is the double gcc-7.5.0-lib reference coming from? --8<---cut here---start->8--- $ readelf -d /gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0/bin/clang-12 | grep runpath 0x001d (RUNPATH)Library runpath: [/gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0/lib:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib:/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib:/gnu/store/rmc131fpy2hv408a1awd2wm7kiwyf7d7-llvm-12.0.0/lib:/gnu/store/f0ca0lf64bw08srv1bj7gkg6ag0sbdb2-gcc-7.5.0-lib/lib] $ ldd /gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0/bin/clang-12 | grep -v LLVM linux-vdso.so.1 (0x7ffe55cbb000) libpthread.so.0 => /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 (0x7f0cd9d1b000) libstdc++.so.6 => /gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/libstdc++.so.6 (0x7f0cd6f33000) libm.so.6 => /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libm.so.6 (0x7f0cd6df2000) libgcc_s.so.1 => /gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/libgcc_s.so.1 (0x7f0cd6dd9000) libc.so.6 => /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 (0x7f0cd6c1c000) /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/ld-linux-x86-64.so.2 (0x7f0cdcf19000) librt.so.1 => /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/librt.so.1 (0x7f0cd64ed000) libdl.so.2 => /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libdl.so.2 (0x7f0cd64e8000) libz.so.1 => /gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11/lib/libz.so.1 (0x7f0cd64c8000) --8<---cut here---end--->8--- It has an extra runpath but doesn't use it... Why does it have it? --8<---cut here---start->8--- $ rg "db2-gcc-7.5.0-lib" /gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0 /gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0/include/clang/Config/config.h 58:#define GCC_INSTALL_PREFIX "/gnu/store/f0ca0lf64bw08srv1bj7gkg6ag0sbdb2-gcc-7.5.0-lib" --8<---cut here---end--->8--- So the
bug#49949: [core-updates]: Blender fails to build
Hi, I got a similar issue on core-updates-frozen with opencv. I solved it in 463a47f4d737ad645639ed32a1c97cfc3bf00ff0 with: --8<---cut here---start->8--- -(search-input-directory inputs "include/OpenEXR") +(string-drop-right + (search-input-file inputs "include/OpenEXR/ImathVec.h") + 11) --8<---cut here---end--->8--- It guess this will also work for bender, but I can't test right now because openvdb which bender depends on fails to build. I suspect it happens because there are several inputs with a "include/OpenEXR" directory and 'search-input-directory' doesn't return the one we're looking for. signature.asc Description: PGP signature
bug#50536: Gem import should wrap description lines
Since guix lint has a line-length preference, the generated packages should have their description strings wrapped to conform to this preference. signature.asc Description: PGP signature
