bug#24442: gettext: No PO mode for Emacs (or wrong description)
The description for ``gettext@0.19.8`` (current) includes this sentence: It provides translators with the means to create message catalogs, as well as an Emacs mode to work with them, and a runtime library to load translated messages from the catalogs. However, no output of the package includes the files for Emacs. One solution (please note that I'm very new to Guix) may be to provide an output for the Emacs goodies, another one would be removing the reference to the Emacs mode in the description until it's actually there.`;)` Thanks! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#24442: gettext: No PO mode for Emacs (or wrong description)
Alex Kost (2016-09-29 11:03:41 +0300) wrote: > Ivan Vilata i Balaguer (2016-09-15 09:04 +0200) wrote: > > > The description for ``gettext@0.19.8`` (current) includes this sentence: > > > > It provides translators with the means to create message > > catalogs, as well as an Emacs mode to work with them, and a > > runtime library to load translated messages from the catalogs. > > > > However, no output of the package includes the files for Emacs. > > This is fixed in 'core-updates' branch now: > <http://git.savannah.gnu.org/cgit/guix.git/commit/?id=9e01589469abd89e035450d29026f0e14add6801>, > however since the fix is not available for users (until core-updates > will be merged into master) I think it's better to leave this bug > opened. > > Once the fix appears in 'master' (I will let you know when it > happens), a user could do "guix pull" and install (or update) > 'gettext' in his/her profile. Then 'po-mode' will become available by > default (without any additional settings in user's .emacs), it means > that whenever you will open .po file, 'po-mode' will be loaded and > enabled automatically. Impressive, thanks a lot to everyone! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#24442: gettext: No PO mode for Emacs (or wrong description)
Ivan Vilata i Balaguer (2016-09-29 13:15:45 +0200) wrote: > Alex Kost (2016-09-29 11:03:41 +0300) wrote: > > > Ivan Vilata i Balaguer (2016-09-15 09:04 +0200) wrote: > > > > > The description for ``gettext@0.19.8`` (current) includes this sentence: > > > > > > It provides translators with the means to create message > > > catalogs, as well as an Emacs mode to work with them, and a > > > runtime library to load translated messages from the catalogs. > > > > > > However, no output of the package includes the files for Emacs. > > > > This is fixed in 'core-updates' branch now: > > <http://git.savannah.gnu.org/cgit/guix.git/commit/?id=9e01589469abd89e035450d29026f0e14add6801>, > > however since the fix is not available for users (until core-updates > > will be merged into master) I think it's better to leave this bug > > opened. > > > > Once the fix appears in 'master' (I will let you know when it > > happens), a user could do "guix pull" and install (or update) > > 'gettext' in his/her profile. Then 'po-mode' will become available > > by default (without any additional settings in user's .emacs), it > > means that whenever you will open .po file, 'po-mode' will be loaded > > and enabled automatically. > > Impressive, thanks a lot to everyone! Working like a charm since the last upgrade, thank you! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#25457: assword: gui: Namespace Gtk not available
Hi, when running ``assword gui`` from Assword 0.10 I get the following error:
```
Traceback (most recent call last):
File
"/gnu/store/wicbdk90fihvvc2zvbvn1wc7jfv8ypbi-assword-0.10/bin/.assword-real",
line 9, in
load_entry_point('assword==0.10', 'console_scripts', 'assword')()
File
"/gnu/store/wicbdk90fihvvc2zvbvn1wc7jfv8ypbi-assword-0.10/lib/python3.5/site-packages/assword/__main__.py",
line 553, in main
func(args)
File
"/gnu/store/wicbdk90fihvvc2zvbvn1wc7jfv8ypbi-assword-0.10/lib/python3.5/site-packages/assword/__main__.py",
line 327, in gui
from assword.gui import Gui
File
"/gnu/store/wicbdk90fihvvc2zvbvn1wc7jfv8ypbi-assword-0.10/lib/python3.5/site-packages/assword/gui.py",
line 2, in
gi.require_version('Gtk', '3.0')
File
"/gnu/store/hii5dmg5qyawx6a883203dcxhbagmgrd-python-pygobject-3.20.0/lib/python3.5/site-packages/gi/__init__.py",
line 102, in require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Gtk not available
```
Other commands not using the GUI work ok. The error does not show with Assword
0.8.
```
$ guix package -I | grep assword
assword 0.10 out /gnu/store/wicbdk90fihvvc2zvbvn1wc7jfv8ypbi-assword-0.10
```
Thank you!
--
Ivan Vilata i Balaguer -- https://elvil.net/
bug#25457: closed (Re: bug#25457: assword: gui: Namespace Gtk not available)
GNU bug Tracking System (2017-01-28 04:38:02 +) wrote: > Your bug report > > #25457: assword: gui: Namespace Gtk not available > > which was filed against the guix package, has been closed. > > The explanation is attached below, along with your original report. > If you require more details, please reply to 25...@debbugs.gnu.org. > Date: Sat, 28 Jan 2017 12:36:57 +0800 > From: 宋文武 > To: Ivan Vilata i Balaguer > Cc: 25457-d...@debbugs.gnu.org > Subject: Re: bug#25457: assword: gui: Namespace Gtk not available > User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) > > Fixed in commit 0050876bcf, thank you! Checked to work, thanks a lot!`:)` -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#25774: libmicrohttpd: fails to build (test-driver aborted)
libmicrohttpd-0.9.52 fails to build because of a failing test: ``` $ guix package -i libmicrohttpd ... make[4]: Entering directory '/tmp/guix-build-libmicrohttpd-0.9.52.drv-0/libmicrohttpd-0.9.52/src/microhttpd' PASS: test_str_compare PASS: test_str_to_value PASS: test_shutdown_select PASS: test_shutdown_poll PASS: test_daemon PASS: test_upgrade ../../test-driver: line 107: 7381 Aborted "$@" > $log_file 2>&1 FAIL: test_upgrade_ssl PASS: test_postprocessor PASS: test_postprocessor_large PASS: test_postprocessor_amp Testsuite summary for GNU Libmicrohttpd 0.9.52 # TOTAL: 10 # PASS: 9 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See src/microhttpd/test-suite.log Please report to libmicroht...@gnu.org make[4]: *** [Makefile:1289: test-suite.log] Error 1 make[4]: Leaving directory '/tmp/guix-build-libmicrohttpd-0.9.52.drv-0/libmicrohttpd-0.9.52/src/microhttpd' make[3]: *** [Makefile:1397: check-TESTS] Error 2 make[3]: Leaving directory '/tmp/guix-build-libmicrohttpd-0.9.52.drv-0/libmicrohttpd-0.9.52/src/microhttpd' make[2]: *** [Makefile:1531: check-am] Error 2 make[2]: Leaving directory '/tmp/guix-build-libmicrohttpd-0.9.52.drv-0/libmicrohttpd-0.9.52/src/microhttpd' make[1]: *** [Makefile:429: check-recursive] Error 1 make[1]: Leaving directory '/tmp/guix-build-libmicrohttpd-0.9.52.drv-0/libmicrohttpd-0.9.52/src' make: *** [Makefile:552: check-recursive] Error 1 phase `check' failed after 29.6 seconds builder for `/gnu/store/42f3rhpv298bmi6ipd0la6nssx34hk6l-libmicrohttpd-0.9.52.drv' failed with exit code 1 guix package: error: build failed: build of `/gnu/store/42f3rhpv298bmi6ipd0la6nssx34hk6l-libmicrohttpd-0.9.52.drv' failed ``` This breaks transitively dependant packages as GNUnet. Thank you! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#25774: libmicrohttpd: fails to build (test-driver aborted)
ng0 (2017-02-17 16:29:35 +) wrote: > On 17-02-17 16:23:46, ng0 wrote: > > On 17-02-17 16:48:58, Ivan Vilata i Balaguer wrote: > > > libmicrohttpd-0.9.52 fails to build because of a failing test: > > > > > > ``` > > > $ guix package -i libmicrohttpd > > > ... > > > make[4]: Entering directory > > > '/tmp/guix-build-libmicrohttpd-0.9.52.drv-0/libmicrohttpd-0.9.52/src/microhttpd' > > > PASS: test_str_compare > > > PASS: test_str_to_value > > > PASS: test_shutdown_select > > > PASS: test_shutdown_poll > > > PASS: test_daemon > > > PASS: test_upgrade > > > ../../test-driver: line 107: 7381 Aborted "$@" > > > > $log_file 2>&1 > > > FAIL: test_upgrade_ssl > > > PASS: test_postprocessor > > > PASS: test_postprocessor_large > > > PASS: test_postprocessor_amp > > > > > > Testsuite summary for GNU Libmicrohttpd 0.9.52 > > > > > > # TOTAL: 10 > > > # PASS: 9 > > > # SKIP: 0 > > > # XFAIL: 0 > > > # FAIL: 1 > > > # XPASS: 0 > > > # ERROR: 0 > > > > > > See src/microhttpd/test-suite.log > > > Please report to libmicroht...@gnu.org > > Can you repeat the build with > 'guix build --keep-failed --install libmicrohttpd' and append the > 'src/microhttpd/test-suite.log' file? > > This can be useful. Hi ng0, I'm building it on: $ uname -a Linux sax 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux Possibly relevant envvars: $ env | grep guix GUIX_PROFILE=/home/ivan/.guix-profile GIT_SSL_CAINFO=/home/ivan/.guix-profile/etc/ssl/certs/ca-certificates.crt GUILE_LOAD_COMPILED_PATH=/home/ivan/.guix-profile/lib/guile/2.0/site-ccache:/home/ivan/.guix-profile/share/guile/site/2.0 GUIX_LOCPATH=/home/ivan/.guix-profile/lib/locale PURPLE_PLUGIN_PATH=/home/ivan/.guix-profile/lib/purple-2:/home/ivan/.guix-profile/lib/pidgin GUILE_LOAD_PATH=/home/ivan/.guix-profile/share/guile/site/2.0 PATH=/home/ivan/.guix-profile/bin:/home/ivan/.guix-profile/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games INFOPATH=/home/ivan/.guix-profile/share/info The log from ``guix package --keep-failed --install libmicrohttpd``: ``` = GNU Libmicrohttpd 0.9.52: src/microhttpd/test-suite.log = # TOTAL: 10 # PASS: 9 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test_upgrade_ssl == verify depth is 0 depth=0 CN = test_ca_cert verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = test_ca_cert verify error:num=21:unable to verify the first certificate verify return:1 DONE verify depth is 0 depth=0 CN = test_ca_cert verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = test_ca_cert verify error:num=21:unable to verify the first certificate verify return:1 DONE verify depth is 0 depth=0 CN = test_ca_cert verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = test_ca_cert verify error:num=21:unable to verify the first certificate verify return:1 read:errno=0 verify depth is 0 depth=0 CN = test_ca_cert verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = test_ca_cert verify error:num=21:unable to verify the first certificate verify return:1 DONE verify depth is 0 depth=0 CN = test_ca_cert verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = test_ca_cert verify error:num=21:unable to verify the first certificate verify return:1 DONE verify depth is 0 depth=0 CN = test_ca_cert verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = test_ca_cert verify error:num=21:unable to verify the first certificate verify return:1 DONE verify depth is 0 depth=0 CN = test_ca_cert verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = test_ca_cert verify error:num=21:unable to verify the first certificate verify return:1 DONE verify depth is 0 depth=0 CN = test_ca_cert verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = test_ca_cert verify error:num=21:unable to verify the first certificate verify return:1 DONE verify depth is 0 depth=0 CN = test_ca_cert verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = test_ca_cert verify error:num=21:unable to verify the first certificate verify return:1 DONE FAIL test_upgrade_ssl (exit status: 139) ``` Thanks for checking this! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#25774: libmicrohttpd: fails to build (test-driver aborted)
bqday5n2n0n6lh6nmdxi8a45z-diffutils-3.5/bin:/gnu/store/fs49m4pvdf2v7kixf9sls8nmhvh40ajl-patch-2.7.5/bin:/gnu/store/9761yfpvyr1fcpjhry8pgb3f0k6kj8n4-sed-4.2.2/bin:/gnu/store/cz7dl482c1j6j5s4vh1pll4lzdl5sl6b-findutils-4.6.0/bin:/gnu/store/k03y1lfaj1xw0d7j2lxdil8ii5c67fdy-gawk-4.1.4/bin:/gnu/store/hb301wl5s7352vbn1vds85dhy32n0hkw-grep-2.25/bin:/gnu/store/9xfn6q7cxqxaxsv6kgiic9iygl2iv2ci-coreutils-8.25/bin:/gnu/store/c5ihjcdxsm9086323bn2j67v7z34lc1a-make-4.2.1/bin:/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin:/gnu/store/c7lm5innppxm53bf5w7i99d59kjdyx27-ld-wrapper-0/bin:/gnu/store/4xxd00drj8gjcr84xdfna44qak2vhwmf-binutils-2.27/bin:/gnu/store/y1g6991kxvdk4vxhsq07r5saww30v8dq-gcc-4.9.4/bin:/gnu/store/iwgi9001dmmihrjg4rqhd6pa6788prjw-glibc-2.24/bin:/gnu/store/iwgi9001dmmihrjg4rqhd6pa6788prjw-glibc-2.24/sbin:/gnu/store/zl3rh35m8psblbw034l9bvssx5yqn7f5-curl-7.50.3/bin:/gnu/store/pwqygjf0ywvnv96h83k4rghq2x1m3qay-gnutls-3.5.4/bin:/gnu/store/4pnp5scrgmjp21flaihmgbckwrz6z4g3-libgcrypt-1.7.3/bin:/gnu/store/liib5wid6rx9rkss78spc7wcqzwb1g2k-openssl-1.0.2j/bin:/gnu/store/vik632ig65676k0azx25vlcf3457v65p-nettle-3.2/bin:/gnu/store/2gqvbsd3kz1nl2s0kvyxxjc7fm0hf9l9-libidn-1.33/bin:/gnu/store/zqp7lmw6dr31j3frsdjwar6wdrzivnqj-libtasn1-4.9/bin:/gnu/store/vhfgzz0j9ry060qvcbvyhcrj3ikvm1vv-libgpg-error-1.24/bin" export PWD="/tmp/guix-build-libmicrohttpd-0.9.52.drv-0/libmicrohttpd-0.9.52" export SHLVL="1" export SOURCE_DATE_EPOCH="1" export TEMP="/tmp/guix-build-libmicrohttpd-0.9.52.drv-0" export TEMPDIR="/tmp/guix-build-libmicrohttpd-0.9.52.drv-0" export TMP="/tmp/guix-build-libmicrohttpd-0.9.52.drv-0" export TMPDIR="/tmp/guix-build-libmicrohttpd-0.9.52.drv-0" export out="/gnu/store/62vwb4ariyzn6bi29ka63dj9r0sp08f2-libmicrohttpd-0.9.52" ``` > > FAIL: test_upgrade_ssl > > == > > > > verify depth is 0 > > depth=0 CN = test_ca_cert > > verify error:num=20:unable to get local issuer certificate > > verify return:1 > > depth=0 CN = test_ca_cert > > verify error:num=21:unable to verify the first certificate > > verify return:1 > > DONE I think I left out a couple of lines at the end: ``` Fatal error in GNU libmicrohttpd daemon.c:5190: MHD_stop_daemon() called while we have suspended connections. FAIL test_upgrade_ssl (exit status: 134) ``` > The only debugging suggestion I have is to make sure that your clock is > correct. Test suites that do certificate verification should take care > not to break in the future, but perhaps it's less common for test > authors to handle the case of a clock set to the past. Well, it may be some second off, but not much more than that… > Beyond that, did you find anything relevant on the upstream bug tracker? > > https://ng.gnunet.org/bugs/view_all_bug_page.php I can't find anything related there, I also searched the net before sending the report but found nothing that seemed the same error. Do you suggest any other test? Thanks! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#25774: libmicrohttpd: fails to build (test-driver aborted)
Leo Famulari (2017-02-17 19:42:15 -0500) wrote: > On Sat, Feb 18, 2017 at 12:59:49AM +0100, Ivan Vilata i Balaguer wrote: > > I can't find anything related there, I also searched the net before > > sending the report but found nothing that seemed the same error. > > What about this one? > > https://ng.gnunet.org/bugs/view.php?id=4844 > > The report says that it's limited to ppc64le, but the symptoms appear > identical. Looks like I'm too sleepy to check these things!`:D` I see from the ChangeLog that the version I'm building is from last October, before the fix mentioned in the link, so that may be already fixed upstream. Thanks for checking! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#25774: libmicrohttpd: fails to build (test-driver aborted)
ng0 (2017-02-18 09:51:35 +) wrote: > On 17-02-17 19:42:15, Leo Famulari wrote: > > What about this one? > > > > https://ng.gnunet.org/bugs/view.php?id=4844 > > > > The report says that it's limited to ppc64le, but the symptoms > > appear identical. > > I could ask grothoff about if a new release will happen soon, but it > looks like it: > > commit f154b0ef8894185fd6c01888d10280049bed10c6 > Author: Christian Grothoff > Date: Wed Feb 15 13:38:06 2017 +0100 > > bump dates and versions and update ChangeLog > > > This is the HEAD~~ commit. > The one afterwards fixes an android problem. I was able to install ``gnunet`` without issues, so I guess some recent commit included a version fixed upstream and the bug may be closed.`:)` Thanks for your help! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#26367: Please add emacs-adaptive-wrap package
Hi, this is a wishlist request to add the [adaptive-wrap](https://elpa.gnu.org/packages/adaptive-wrap.html) ELPA package to GNU Guix. The following definition, as produced by ``guix import elpa adaptive-wrap`` (except for removing the ``license:`` prefix) seems to work without issues with ``guix install -f FILE``: ``` (use-modules (guix) (guix build-system emacs) (guix licenses)) (package (name "emacs-adaptive-wrap") (version "0.5") (source (origin (method url-fetch) (uri (string-append "http://elpa.gnu.org/packages/adaptive-wrap-"; version ".el")) (sha256 (base32 "0frgmp8vrrml4iykm60j4d6cl9rbcivy9yh24q6kd10bcyx59ypy" (build-system emacs-build-system) (home-page "http://elpa.gnu.org/packages/adaptive-wrap.html";) (synopsis "Smart line-wrapping with wrap-prefix") (description "This package provides the `adaptive-wrap-prefix-mode' minor mode which sets the wrap-prefix property on the fly so that single-long-line paragraphs get word-wrapped in a way similar to what you'd get with M-q using adaptive-fill-mode, but without actually changing the buffer's text.") (license gpl3+)) ``` Thank you very much, -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#26367: Please add emacs-adaptive-wrap package
Alex Kost (2017-04-07 20:33:35 +0300) wrote: > > From be8efedf1710a907db522002c9df1773ab1681ae Mon Sep 17 00:00:00 2001 > > From: humanitiesNerd > > Date: Wed, 5 Apr 2017 12:42:05 +0200 > > Subject: [PATCH] gnu: Add emacs-adaptive-wrap > > > > * gnu/packages/emacs.scm (emacs-adaptive-wrap): New variable. > > --- > > gnu/packages/emacs.scm | 24 > > 1 file changed, 24 insertions(+) > > Thanks to both of you! I mentioned Ivan in the commit message and > applied this patch: > > http://git.savannah.gnu.org/cgit/guix.git/commit/?id=350cfccb069ff6b8fd9625268612ce09be5f66c9 Thanks Catonano and Alex for the very prompt action!`:)` -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#26610: python-gpg broke; python-gpg 1.9.0 does not exist
I think I also got bitten by this: ``` $ guix package --fallback -u warning: failed to install locale: Invalid argument Starting download of /gnu/store/8anrjg1qj2sqij6883v057l86wac2vln-gpg-1.9.0.tar.gz >From https://pypi.io/packages/source/g/gpg/gpg-1.9.0.tar.gz... following redirection to `https://pypi.org/packages/source/g/gpg/gpg-1.9.0.tar.gz'... following redirection to `https://files.pythonhosted.org/packages/source/g/gpg/gpg-1.9.0.tar.gz'... ERROR: download failed "https://files.pythonhosted.org/packages/source/g/gpg/gpg-1.9.0.tar.gz"; 404 "Not Found" Starting download of /gnu/store/8anrjg1qj2sqij6883v057l86wac2vln-gpg-1.9.0.tar.gz >From >http://mirror.hydra.gnu.org/file/gpg-1.9.0.tar.gz/sha256/1x74i6q713c0bckls7rdm8kgsmllf9qvy9x62jghszlhgjkyh9nd... ERROR: download failed "http://mirror.hydra.gnu.org/file/gpg-1.9.0.tar.gz/sha256/1x74i6q713c0bckls7rdm8kgsmllf9qvy9x62jghszlhgjkyh9nd"; 404 "Not Found" Starting download of /gnu/store/8anrjg1qj2sqij6883v057l86wac2vln-gpg-1.9.0.tar.gz >From >http://tarballs.nixos.org/sha256/1x74i6q713c0bckls7rdm8kgsmllf9qvy9x62jghszlhgjkyh9nd... ERROR: download failed "http://tarballs.nixos.org/sha256/1x74i6q713c0bckls7rdm8kgsmllf9qvy9x62jghszlhgjkyh9nd"; 404 "Not Found" failed to download "/gnu/store/8anrjg1qj2sqij6883v057l86wac2vln-gpg-1.9.0.tar.gz" from "https://pypi.io/packages/source/g/gpg/gpg-1.9.0.tar.gz"; builder for `/gnu/store/16rsli2x9sh4fr9fa0yy4mn5pkmqwy3h-gpg-1.9.0.tar.gz.drv' failed to produce output path `/gnu/store/8anrjg1qj2sqij6883v057l86wac2vln-gpg-1.9.0.tar.gz' cannot build derivation `/gnu/store/gvji20dwv204p39ii010sx267kkpjd15-python-gpg-1.9.0.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/8m8whiqpxy5b45x18rvskq523nl7237d-assword-0.10.drv': 1 dependencies couldn't be built guix package: error: build failed: build of `/gnu/store/8m8whiqpxy5b45x18rvskq523nl7237d-assword-0.10.drv' failed ``` I am a user of ``assword``, but pretty much a Guix newbie. Is there any way I can help fix this issue? Thanks, -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#26610: python-gpg broke; python-gpg 1.9.0 does not exist
Leo Famulari (2017-05-27 10:11:46 -0400) wrote: > You can try changing the python-gpg package's version to the last > available upstream version. On PyPi, that's 1.8.0. > > Then, try rebuilding the packages that depend on python-gpg (`guix > refresh -l python-gpg python2-gpg`). > > Hopefully it all works. Then, you can send a patch with your fix :) > > Let us know if you need help! Ok, attaching the patch. These are the steps I followed to test it: 0. Apply the patch. 1. Add ``python-gpg`` at the end of ``gnu/packages/gnupg.scm`` (sorry for my poor Scheme habilities). 2. Run ``guix environment --ad-hoc -l gnu/packages/gnupg.scm python assword coreutils``. 3. Import ``gpg`` in Python and check ``gpg.version.versionstr``, dump ``assword`` program to verify that it uses the same build of ``python-gnupg``. 4. Run ``assword`` and check that everything works. Probably many steps can be done better/more easily, but my knowledge is very limited. Links for improving that are welcome.`;)` Thanks and cheers, -- Ivan Vilata i Balaguer -- https://elvil.net/ >From bef8ccca58150ad4714cfa65472d5f2e9ae7b283 Mon Sep 17 00:00:00 2001 From: Ivan Vilata-i-Balaguer Date: Thu, 1 Jun 2017 10:33:09 +0200 Subject: [PATCH] gnu: python-gpg: Use explicit version 1.8.0 instead of GPGME's. GPGME defines version 1.9.0, which isn't yet available for python-gnupg, whose latest version is 1.8.0, so we use that explicitly instead. Fixes #26610. * gnu/packages/gnupg.scm (python-gpg): Use explicit version 1.8.0 instead of GPGME's. --- gnu/packages/gnupg.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gnu/packages/gnupg.scm b/gnu/packages/gnupg.scm index 440e7d550..c2b02789b 100644 --- a/gnu/packages/gnupg.scm +++ b/gnu/packages/gnupg.scm @@ -410,7 +410,7 @@ and every application benefits from this.") (define-public python-gpg (package (name "python-gpg") -(version (package-version gpgme)) +(version "1.8.0") (source (origin (method url-fetch) (uri (pypi-uri "gpg" version)) -- 2.12.2
bug#31001: Emacs: "User xyz has no home directory"
Hi there, After updating Emacs to 25.3 (now sitting at `/gnu/store/6cflji7h6y0v15dvnccv7paaa7894gdc-emacs-25.3`), on start it doesn't load configuration and it shows this error: Error (initialization): User has no home directory I do have a home directory, it's working and my user is in `/etc/passwd`. I found this link to describe the same issue in Nix, and the same fix that worked for me (i.e. install `nscd`): <https://github.com/NixOS/nixpkgs/issues/12335> I'm running Guix `d4e0ebd016091695adbad8ecdb7de03c0fbd7bf5` under Debian Sid; relevant entries in `/etc/nsswitch.conf` are: passwd: compat systemd group: compat systemd shadow: compat Thanks a lot! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#37967: guix environment -CN: Operation not permitted mounting host's /var/run/nscd
Hi! While using Guix commit `c9fc03a3` on Debian unstable, whenever I run
`guix environment -CN` (either as a normal user or as root) I get an error
like this:
guix environment: error: mount: mount "/var/run/nscd" on
"/tmp/guix-directory.6kBgXe//var/run/nscd": Operation not permitted
nscd is installed and working in my host machine.
This command used to work a while ago. Actually, I pulled the Guix commit
right before `5ccec771` ("file-systems: Add /var/run/nscd to
'%network-file-mappings'.") and the command seems to work again (even if I do
not replace the running daemon).
Maybe the later commit introduced some kind of regression?
Thanks and cheers!
--
Ivan Vilata i Balaguer -- https://elvil.net/
bug#37967: guix environment -CN: Operation not permitted mounting host's /var/run/nscd
Salut Ludovic !
Ludovic Courtès (2019-10-29 23:16:49 +0100) wrote:
> Bon dia Ivan,
>
> Ivan Vilata i Balaguer skribis:
>
> > Hi! While using Guix commit `c9fc03a3` on Debian unstable, whenever I run
> > `guix environment -CN` (either as a normal user or as root) I get an error
> > like this:
> >
> > guix environment: error: mount: mount "/var/run/nscd" on
> > "/tmp/guix-directory.6kBgXe//var/run/nscd": Operation not permitted
> >
> > nscd is installed and working in my host machine.
>
> What does ‘uname -rs’ return?
$ uname -rs
Linux 5.2.0-3-amd64
> What about ‘ls -ld /var/run/nscd’?
$ ls -ld /var/run/nscd
drwxr-xr-x 2 root root 60 Oct 29 15:58 /var/run/nscd
> > This command used to work a while ago. Actually, I pulled the Guix commit
> > right before `5ccec771` ("file-systems: Add /var/run/nscd to
> > '%network-file-mappings'.") and the command seems to work again (even if I
> > do
> > not replace the running daemon).
> >
> > Maybe the later commit introduced some kind of regression?
>
> It definitely has to do with this commit, but I wonder why you’d get
> EPERM when bind-mounting /var/run/nscd to a different place!
>
> Gracies,
> Ludo’.
Yeah, I'm also scratching my head since switching to the previous commit
immediately has it working again, so it's probably not a system config
issue. `O_o`
Cheers!
--
Ivan Vilata i Balaguer -- https://elvil.net/
bug#37967: guix environment -CN: Operation not permitted mounting host's /var/run/nscd
Ludovic Courtès (2019-11-01 15:26:27 +0100) wrote:
> Ivan Vilata i Balaguer skribis:
>
> > Ludovic Courtès (2019-10-29 23:16:49 +0100) wrote:
> >>
> >> Ivan Vilata i Balaguer skribis:
> >>
> >> > Hi! While using Guix commit `c9fc03a3` on Debian unstable, whenever I
> >> > run
> >> > `guix environment -CN` (either as a normal user or as root) I get an
> >> > error
> >> > like this:
> >> >
> >> > guix environment: error: mount: mount "/var/run/nscd" on
> >> > "/tmp/guix-directory.6kBgXe//var/run/nscd": Operation not permitted
> >> >
> >> > nscd is installed and working in my host machine.
> >>
> >> What does ‘uname -rs’ return?
> >
> > $ uname -rs
> > Linux 5.2.0-3-amd64
> >
> >> What about ‘ls -ld /var/run/nscd’?
> >
> > $ ls -ld /var/run/nscd
> > drwxr-xr-x 2 root root 60 Oct 29 15:58 /var/run/nscd
>
> Hmm, what does this command return:
>
> mkdir /tmp/tt
> unshare -mUr mount --bind /var/run/nscd /tmp/tt
>
> ?
$ mkdir /tmp/tt
$ unshare -mUr mount --bind /var/run/nscd /tmp/tt && echo ok
ok
> What about a read-only bind mount like this:
>
> unshare -mUr mount --bind -o ro /var/run/nscd /tmp/tt
>
> ?
This one looks more interesting:
$ unshare -mUr mount --bind -o ro /var/run/nscd /tmp/tt && echo ok
mount: /tmp/tt: filesystem was mounted, but any subsequent operation
failed: Unknown error 5005.
$ echo $?
32
> What if you try bind-mounting a directory owned by your user?
>
> mkdir /tmp/mine
> unshare -mUr mount --bind /tmp/mine /tmp/tt
>
> ?
$ mkdir /tmp/mine
$ unshare -mUr mount --bind /tmp/mine /tmp/tt && echo ok
ok
> Thanks in advance,
> Ludo’.
Thanks to you! Saluton,
--
Ivan Vilata i Balaguer -- https://elvil.net/
bug#37967: guix environment -CN: Operation not permitted mounting host's /var/run/nscd
Ivan Vilata i Balaguer (2019-11-01 11:10:02 -0400) wrote:
> Ludovic Courtès (2019-11-01 15:26:27 +0100) wrote:
>
> > […] What about a read-only bind mount like this:
> >
> > unshare -mUr mount --bind -o ro /var/run/nscd /tmp/tt
> >
> > ?
>
> This one looks more interesting:
>
> $ unshare -mUr mount --bind -o ro /var/run/nscd /tmp/tt && echo ok
> mount: /tmp/tt: filesystem was mounted, but any subsequent operation
> failed: Unknown error 5005.
> $ echo $?
> 32
BTW, I ran that under strace and it looks like the read-only remount fails
after mounting `/var/run/nscd` in the new namespace has succeeded:
$ strace -f unshare -mUr mount --bind -o ro /var/run/nscd /tmp/tt
[…]
access("/run/mount", R_OK|W_OK) = -1 EACCES (Permission denied)
mount("/run/nscd", "/tmp/tt", 0x14c25b0, MS_RDONLY|MS_BIND, NULL) = 0
mount("none", "/tmp/tt", NULL, MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = -1
EPERM (Operation not permitted)
write(2, "mount: ", 7mount: ) = 7
write(2, "/tmp/tt: filesystem was mounted,"..., 89/tmp/tt: filesystem was
mounted, but any subsequent operation failed: Unknown error 5005.) = 89
write(2, "\n", 1
[…]
Cheers!
--
Ivan Vilata i Balaguer -- https://elvil.net/
bug#38054: mumble: "QSslSocket: cannot resolve ", Certificate Expiry, segfault
Hi! I'm using Mumble 1.2.19 from Guix commit 7f81cce3 on Debian Sid. On start, it logs the following messages: QSslSocket: cannot resolve CRYPTO_num_locks QSslSocket: cannot resolve CRYPTO_set_id_callback QSslSocket: cannot resolve CRYPTO_set_locking_callback QSslSocket: cannot resolve sk_free QSslSocket: cannot resolve sk_num QSslSocket: cannot resolve sk_pop_free QSslSocket: cannot resolve sk_value QSslSocket: cannot resolve SSL_library_init QSslSocket: cannot resolve SSL_load_error_strings QSslSocket: cannot resolve SSLv3_client_method QSslSocket: cannot resolve SSLv23_client_method QSslSocket: cannot resolve SSLv3_server_method QSslSocket: cannot resolve SSLv23_server_method QSslSocket: cannot resolve X509_STORE_CTX_get_chain QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf QSslSocket: cannot resolve SSLeay QSslSocket: cannot call unresolved function CRYPTO_num_locks QSslSocket: cannot call unresolved function CRYPTO_set_id_callback QSslSocket: cannot call unresolved function CRYPTO_set_locking_callback QSslSocket: cannot call unresolved function SSL_library_init QSslSocket: cannot call unresolved function SSLv23_client_method QSslSocket: cannot call unresolved function sk_num Then it complains about "Certificate Expiry: Your certificate is about to expire. You need to renew it, or you will no longer be able to connect to servers you are registered on.". If I proceed to connect it goes: OpenSSL Support: 1 (OpenSSL 1.1.1d 10 Sep 2019) Segmentation fault and dies. It is curious that `guix package -s openssl` reports version 1.1.1c instead of 1.1.1d, which matches the Debian system's version of OpenSSL, so Mumble may be trying to load system libraries instead of Guix's. If I revert to a previous profile generation with a build of Mumble linked against glibc 2.28 instead of 2.29, it doesn't print the errors and works without issues. Thank you very much! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#38055: patchelf: Assertion failed when setting interpreter
Hi, I'm using patchelf 0.8 from Guix commit 7f81cce3 on Debian Sid. When trying to patch the `go` binary from <https://dl.google.com/go/go1.12.3.linux-amd64.tar.gz>, I get the following error: ivan@sax /tmp/tmps2Cv6w [env]$ patchelf --print-interpreter $SHELL /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/ld-linux-x86-64.so.2 ivan@sax /tmp/tmps2Cv6w [env]$ patchelf --set-interpreter $(patchelf --print-interpreter $SHELL) /tmp/tmps2Cv6w/golang/bin/go patchelf: patchelf.cc:701: void ElfFile::rewriteSectionsExecutable() \ [with Elf_Ehdr = Elf64_Ehdr; Elf_Phdr = Elf64_Phdr; Elf_Shdr = Elf64_Shdr; Elf_Addr = long unsigned int; Elf_Off = long unsigned int; \ Elf_Dyn = Elf64_Dyn; Elf_Sym = Elf64_Sym]: Assertion `(off_t) rdi(hdr->e_shoff) >= startOffset' failed. Aborted (I know Go is packed for Guix, my need arises from trying to build an unrelated project which relies on binary Go for its build process.) It may be the problem described here regarding Go-produced binaries: <https://github.com/NixOS/patchelf/issues/66>. It seems to be fixed in patchelf 0.10, and indeed trying the same operation with patchelf 0.10 from Debian does succeed to patch the binary. As an aside, I tried to build `--with-source` for 0.10 and it succeeds to compile, but tests fail to pass. Thank you very much! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#37967: guix environment -CN: Operation not permitted mounting host's /var/run/nscd
Ludovic Courtès (2019-11-04 18:07:05 +0100) wrote:
> Ivan Vilata i Balaguer skribis:
>
> > BTW, I ran that under strace and it looks like the read-only remount fails
> > after mounting `/var/run/nscd` in the new namespace has succeeded:
> >
> > $ strace -f unshare -mUr mount --bind -o ro /var/run/nscd /tmp/tt
> > […]
> > access("/run/mount", R_OK|W_OK) = -1 EACCES (Permission denied)
> > mount("/run/nscd", "/tmp/tt", 0x14c25b0, MS_RDONLY|MS_BIND, NULL) = 0
> > mount("none", "/tmp/tt", NULL, MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = -1
> > EPERM (Operation not permitted)
> > write(2, "mount: ", 7mount: ) = 7
> > write(2, "/tmp/tt: filesystem was mounted,"..., 89/tmp/tt: filesystem
> > was mounted, but any subsequent operation failed: Unknown error 5005.) = 89
> > write(2, "\n", 1
> > […]
>
> Weird, why does it remount it?
>
> What does:
>
> mount | grep /run
$ mount | grep /run
tmpfs on /run type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=1641444k,mode=755)
[…]
> returns? I just tried on a Debian 10 image with Linux 4.19.0 and /run
> is a tmpfs, which may be the reason why read-only bind-mounts fail (or
> at least there’s a bug in that area.)
>
> Anyway, below is a patch for you to test. Let me know how it goes. :-)
>
> Thanks,
> Ludo’.
I applied your patch on top of bf7b08c4, pulled Guix and did successfully
start `guix environment -CN`, with network support and all.
Cool! `:)`
> diff --git a/gnu/system/file-systems.scm b/gnu/system/file-systems.scm
> index 6cf6ccc53e..6cdb2b749d 100644
> --- a/gnu/system/file-systems.scm
> +++ b/gnu/system/file-systems.scm
> @@ -507,7 +507,8 @@ a bind mount."
> ;; XXX: On some GNU/Linux systems, /etc/resolv.conf is a
> ;; symlink to a file in a tmpfs which, for an unknown
> reason,
> ;; cannot be bind mounted read-only within the container.
> - (writable? (string=? file "/etc/resolv.conf"
> + (writable? (or (string=? file "/etc/resolv.conf")
> +(string=? file "/var/run/nscd")
>(cons "/var/run/nscd" %network-configuration-files)))
>
> (define (file-system-type-predicate type)
--
Ivan Vilata i Balaguer -- https://elvil.net/
bug#38055: patchelf: Assertion failed when setting interpreter
Efraim Flashner (2019-11-05 18:18:22 +0200) wrote: > On Tue, Nov 05, 2019 at 03:12:23PM +0100, Ludovic Courtès wrote: > > > > Ivan Vilata i Balaguer skribis: > > > > > Hi, I'm using patchelf 0.8 from Guix commit 7f81cce3 on Debian Sid. > > > When trying to patch the `go` binary from > > > <https://dl.google.com/go/go1.12.3.linux-amd64.tar.gz>, I get the > > > following error: > > > > > > ivan@sax /tmp/tmps2Cv6w [env]$ patchelf --print-interpreter $SHELL > > > > > > /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/ld-linux-x86-64.so.2 > > > ivan@sax /tmp/tmps2Cv6w [env]$ patchelf --set-interpreter $(patchelf > > > --print-interpreter $SHELL) /tmp/tmps2Cv6w/golang/bin/go > > > patchelf: patchelf.cc:701: void ElfFile > > Elf_Addr, Elf_Off, Elf_Dyn, Elf_Sym>::rewriteSectionsExecutable() \ > > > [with Elf_Ehdr = Elf64_Ehdr; Elf_Phdr = Elf64_Phdr; Elf_Shdr = > > > Elf64_Shdr; Elf_Addr = long unsigned int; Elf_Off = long unsigned int; \ > > > Elf_Dyn = Elf64_Dyn; Elf_Sym = Elf64_Sym]: Assertion `(off_t) > > > rdi(hdr->e_shoff) >= startOffset' failed. > > > Aborted > > > > I think it’s a bug you should report upstream to the PatchELF > > maintainers; it’s probably not Guix-specific. > > On the other hand, if I were the patchelf maintainers, I'd suggest > upgrading our package from 0.8 to a newer version. Yeah, as I mentioned in the original mail that particular problem does indeed seem to be fixed in 0.10. However when I try to build that source with `guix build patchelf --with-source=…`, tests fail. If I run `guix environment -C --pure patchelf` then unpack and build the source, the only test that actually fails is `no-rpath.sh`. If I run `sh -x no-rpath.sh` I get this: ``` ++ basename no-rpath.sh .sh + SCRATCH=scratch/no-rpath + rm -rf scratch/no-rpath + mkdir -p scratch/no-rpath + cp no-rpath scratch/no-rpath/ ++ ../src/patchelf --print-rpath scratch/no-rpath/no-rpath + oldRPath=/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib:/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib:/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../..:/gnu/store/dcrwf5irwh39knld1wim1qkny659af9g-profile/lib + test -n /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib:/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib:/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../..:/gnu/store/dcrwf5irwh39knld1wim1qkny659af9g-profile/lib + exit 1 ``` To succeed, the output of `…/patchelf --print-rpath …/no-rpath` (i.e. `oldRPath`) should be empty. I'm not that familiar with Guix's GNU build system, but is that at all possible under Guix? I mean, maybe the test is pointless or must be altered in some Guix-specific way for the `no-rpath` binary not to have an rpath. Cheers, -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#38055: none
Efraim Flashner (2019-11-11 11:27:30 +0200) wrote: > Some inline comments added. Patch pushed. Wow, thank you so much for taking care of this! I did prepare a patch on Friday but I didn't have the time to send it, plus it pales in comparison to Efraim's and it also had the `ipfs` binary segfault after patching. I'm still attaching it in case you're curious (of course I don't expect any of it to get merged `;)`). I'll try to find a moment to test your patch and see if the `ipfs` binary doesn't segfault, then report back. Thanks again! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#38055: none
Ivan Vilata i Balaguer (2019-11-11 10:10:10 -0500) wrote:
> […] I'm still attaching it in case you're curious (of course I don't expect
> any of it to get merged `;)`). […]
Forgot the attachment… `:P`
--
Ivan Vilata i Balaguer -- https://elvil.net/
>From 2e4cca87b865dbd26ee417775d543abab7ba4f53 Mon Sep 17 00:00:00 2001
From: Ivan Vilata-i-Balaguer
Date: Fri, 8 Nov 2019 13:59:53 -0500
Subject: [PATCH] gnu: patchelf: Update to 0.10.
Besides the update, the patches for "page size" and "rework for ARM" were
removed since they can no longer be applied to upstream source.
Also, the "no-rpath.sh" test was skipped since it would fail under Guix, see
<https://issues.guix.gnu.org/issue/38055>.
* gnu/packages/elf.scm (patchelf): Update to 0.10.
* gnu/packages/patches/patchelf-page-size.patch: Delete file.
* gnu/packages/patches/patchelf-rework-for-arm.patch: Delete file.
* gnu/packages/patches/patchelf-skip-no-rpath-test.patch: New file.
---
gnu/packages/elf.scm | 25 +-
gnu/packages/patches/patchelf-page-size.patch | 70 ---
.../patches/patchelf-rework-for-arm.patch | 473 --
.../patches/patchelf-skip-no-rpath-test.patch | 18 +
4 files changed, 21 insertions(+), 565 deletions(-)
delete mode 100644 gnu/packages/patches/patchelf-page-size.patch
delete mode 100644 gnu/packages/patches/patchelf-rework-for-arm.patch
create mode 100644 gnu/packages/patches/patchelf-skip-no-rpath-test.patch
diff --git a/gnu/packages/elf.scm b/gnu/packages/elf.scm
index 4f365cf205..28bdcedcd2 100644
--- a/gnu/packages/elf.scm
+++ b/gnu/packages/elf.scm
@@ -198,7 +198,7 @@ static analysis of the ELF binaries at hand.")
(define-public patchelf
(package
(name "patchelf")
-(version "0.8")
+(version "0.10")
(source (origin
(method url-fetch)
(uri (string-append
@@ -207,28 +207,9 @@ static analysis of the ELF binaries at hand.")
"/patchelf-" version ".tar.bz2"))
(sha256
(base32
- "1rqpg84wrd3fa16wa9vqdvasnc05yz49w207cz1l0wrl4k8q97y9"))
- (patches (search-patches "patchelf-page-size.patch"
+ "1wzwvnlyf853hw9zgqq5522bvf8gqadk8icgqa41a5n7593csw7n"))
+ (patches (search-patches "patchelf-skip-no-rpath-test.patch"
(build-system gnu-build-system)
-
-;; XXX: The upstream 'patchelf' doesn't support ARM. The only available
-;; patch makes significant changes to the algorithm, possibly
-;; introducing bugs. So, we apply the patch only on ARM systems.
-(inputs
- (if (target-arm32?)
- `(("patch/rework-for-arm" ,(search-patch
- "patchelf-rework-for-arm.patch")))
- '()))
-(arguments
- (if (target-arm32?)
- `(#:phases
- (modify-phases %standard-phases
- (add-after 'unpack 'patch/rework-for-arm
- (lambda* (#:key inputs #:allow-other-keys)
- (let ((patch-file (assoc-ref inputs "patch/rework-for-arm")))
- (invoke "patch" "--force" "-p1" "--input" patch-file))
- '()))
-
(home-page "https://nixos.org/patchelf.html";)
(synopsis "Modify the dynamic linker and RPATH of ELF executables")
(description
diff --git a/gnu/packages/patches/patchelf-page-size.patch
b/gnu/packages/patches/patchelf-page-size.patch
deleted file mode 100644
index 1c14047512..00
--- a/gnu/packages/patches/patchelf-page-size.patch
+++ /dev/null
@@ -1,70 +0,0 @@
-Improve the determination of pageSize in patchelf.cc.
-
-Patch by Mark H Weaver .
-
patchelf/src/patchelf.cc.orig 1969-12-31 19:00:01.0 -0500
-+++ patchelf/src/patchelf.cc 2014-02-16 20:15:06.283203125 -0500
-@@ -21,11 +21,19 @@
- using namespace std;
-
-
--#ifdef MIPSEL
--/* The lemote fuloong 2f kernel defconfig sets a page size of 16KB */
--const unsigned int pageSize = 4096*4;
--#else
-+/* Note that some platforms support multiple page sizes. Therefore,
-+ it is not enough to query the current page size. 'pageSize' must
-+ be the maximum architectural page size for the platform, which is
-+ typically defined in the corresponding ABI document.
-+
-+ XXX FIXME: This won't work when we're cross-compiling. */
-+
-+#if defined __MIPSEL__ || defined __MIPSEB__ || defined __aarch64__
-+const unsigned int pageSize = 65536;
-+#elif defined __x86_64__ || defined __i386__ || defined __arm__
- const unsigned int pageSize = 4096;
-+#else
-+# error maximum architectural page size unknown for this platform
- #endif
-
-
patchelf/tests/no-rpath.sh.orig2014-01-14 08:17:47.0 -050
bug#38055: none
Ivan Vilata i Balaguer (2019-11-11 10:10:10 -0500) wrote: > Efraim Flashner (2019-11-11 11:27:30 +0200) wrote: > > > Some inline comments added. Patch pushed. > > […] I'll try to find a moment to test your patch and see if the `ipfs` > binary doesn't segfault, then report back. […] I tried your patch, the following command in a pure container environment: $ patchelf --set-interpreter "$(patchelf --print-interpreter /bin/sh)" /path/to/bin/go does not trigger the assertion error (both `--set-interpreter` and `--set-rpath` suffered from the same failure), and the resulting `go` binary can be executed without issues. Thank you very much for fixing this! `:)` -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#38054: mumble: "QSslSocket: cannot resolve ", Certificate Expiry, segfault
Christopher Lemmer Webber (2019-11-19 14:00:20 -0500) wrote: > Efraim Flashner writes: > > > I also noticed that there's a newer version of mumble out, 1,3.0, which > > builds against qt5. We should probably just go ahead and upgrade it. > > I've also gotten this. I have an older version of Mumble installed from > a previous generation and that one does still run. > > I tried updating it here, but looks like it's upset about not finding > the (un)bundled speex... weird because it must not have been bothered by > that before. > > Incomplete patch attached. I'm unsure if switching from qt-4 to qtbase > is the right way to upgrade to QT 5 or not? I'm guessing so? Thanks Christopher! I'm currently working in a complete patch, it's building and running (and it's not suffering from the errors I found!), but I still need to locate the appropriate icons and include them in the package. I'll get back to you real soon! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#38054: mumble: "QSslSocket: cannot resolve ", Certificate Expiry, segfault
Ivan Vilata i Balaguer (2019-11-20 00:30:24 -0500) wrote:
> Thanks Christopher! I'm currently working in a complete patch, it's
> building and running (and it's not suffering from the errors I found!), but
> I still need to locate the appropriate icons and include them in the
> package.
>
> I'll get back to you real soon!
Hi there! I finally completed the update patch and managed to get the icons
working. It seems to work as expected without plugin issues.
It wasn't an easy task but I learnt some good stuff during the way… `:D`
Enjoy the new Mumble!
--
Ivan Vilata i Balaguer -- https://elvil.net/
>From 987f03ca1721c1aa54a078a9be143abbac82bf11 Mon Sep 17 00:00:00 2001
From: Ivan Vilata-i-Balaguer
Date: Fri, 22 Nov 2019 01:15:53 -0500
Subject: [PATCH] gnu: mumble: Update to 1.3.0.
Besides the update in itself, bundled software components are enabled as long
as they are not already implemented in an existing package (in which case the
package is used instead). Some comments were added to indicate why bundled
software components are kept or removed, why features are disabled, and the
reason to include each license.
* gnu/packages/telephony.scm (mumble): Update to 1.3.0.
* gnu/packages/patches/mumble-1.2.19-abs.patch: Remove file.
---
gnu/packages/patches/mumble-1.2.19-abs.patch | 31 -
gnu/packages/telephony.scm | 114 ---
2 files changed, 70 insertions(+), 75 deletions(-)
delete mode 100644 gnu/packages/patches/mumble-1.2.19-abs.patch
diff --git a/gnu/packages/patches/mumble-1.2.19-abs.patch
b/gnu/packages/patches/mumble-1.2.19-abs.patch
deleted file mode 100644
index 683325f4bc..00
--- a/gnu/packages/patches/mumble-1.2.19-abs.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-From ea861fe86743c8402bbad77d8d1dd9de8dce447e Mon Sep 17 00:00:00 2001
-From: Mikkel Krautz
-Date: Fri, 29 Dec 2017 14:47:25 +0100
-Subject: [PATCH] AudioOutput: do not use non-existant template version of
- std::abs.
-
-This change fixes AudioOutput to use the float overload of std::abs:
-
-float std::abs(float);
-
-instead of a non-existant template version (for newer Boost 1.66).
-
-Fixes mumble-voip/mumble#3281
-
- src/mumble/AudioOutput.cpp | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/mumble/AudioOutput.cpp b/src/mumble/AudioOutput.cpp
-index cbe0c0e2b..7a0a5e2ab 100644
a/src/mumble/AudioOutput.cpp
-+++ b/src/mumble/AudioOutput.cpp
-@@ -437,7 +437,7 @@ bool AudioOutput::mix(void *outbuff, unsigned int nsamp) {
- top[2] = 0.0f;
- }
-
-- if (std::abs(front[0] * top[0] +
front[1] * top[1] + front[2] * top[2]) > 0.01f) {
-+ if (std::abs(front[0] * top[0] + front[1] *
top[1] + front[2] * top[2]) > 0.01f) {
- // Not perpendicular. Assume Y up and
rotate 90 degrees.
-
- float azimuth = 0.0f;
diff --git a/gnu/packages/telephony.scm b/gnu/packages/telephony.scm
index abb68f62b2..e1ad2f90f5 100644
--- a/gnu/packages/telephony.scm
+++ b/gnu/packages/telephony.scm
@@ -12,6 +12,7 @@
;;; Copyright © 2018 Jovany Leandro G.C
;;; Copyright © 2018 Tim Gesthuizen
;;; Copyright © 2019 Pierre Neidhardt
+;;; Copyright © 2019 Ivan Vilata i Balaguer
;;;
;;; This file is part of GNU Guix.
;;;
@@ -43,6 +44,7 @@
#:use-module (gnu packages file)
#:use-module (gnu packages protobuf)
#:use-module (gnu packages gettext)
+ #:use-module (gnu packages gl)
#:use-module (gnu packages glib)
#:use-module (gnu packages gnome)
#:use-module (gnu packages gnupg)
@@ -378,30 +380,34 @@ address of one of the participants.")
(define-public mumble
(package
(name "mumble")
-(version "1.2.19")
+(version "1.3.0")
(source (origin
(method url-fetch)
(uri (string-append "https://mumble.info/snapshot/";
name "-" version ".tar.gz"))
(sha256
(base32
-"1s60vaici3v034jzzi20x23hsj6mkjlc0glipjq4hffrg9qgnizh"))
- (patches (search-patches "mumble-1.2.19-abs.patch"))
+"03dqg5yf6d7ilc1wydpshnv1ndssppcbadqcq20jm5j4fdaf53cs"))
(modules '((guix build utils)))
(snippet
`(begin
;; Remove bundled software.
- (for-each delete-file-recursively '("3rdparty"
- "speex"
- "speexbuild"
- "opus-build"
- "opus-src"
-
bug#57352: emacs-guix: Requires GUILE_LOAD_(COMPILED_)PATH env vars (or "guile" package)
Hi! I have `emacs-guix` in a separate Guix profile with all Emacs stuff, running on a foreign distro. I noticed that removing the `guile` package (from all profiles) broke `emacs-guix` after a session restart, and that restoring the `guile` package or just Guile's environment variables fixed the issue: ``` $ nog # a script of mine running a distro shell with no Guix variables $ . ~/env/guix/ivan/emacs/etc/profile # from profile with Emacs stuff $ . ~/.config/guix/current/etc/profile $ command -v guile || echo missing missing $ emacs Running M-x guix then v yields this error: Starting Guix REPL ... [5 times] guix-geiser-eval: Error in evaluating guile expression: ice-9/boot-9.scm:1685:16: In procedure raise-exception: Unbound variable: %max-returned-list-size $ realpath ~/env/guix/ivan/emacs /gnu/store/ahq…-profile $ export GUILE_LOAD_PATH=/gnu/store/ahq…-profile/share/guile/site/3.0 $ export GUILE_LOAD_COMPILED_PATH=/gnu/store/ahq…-profile/lib/guile/3.0/site-ccache:/gnu/store/ahq…-profile/share/guile/site/3.0 $ emacs Running M-x guix works successfully. $ exit ``` I'm no Guix packaging expert, but it looks like `emacs-guix` should either have `guile` as propagated input, or somehow add `GUILE_LOAD_PATH` and `GUILE_LOAD_COMPILED_PATH` to the profile's search paths. Thank you very much! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#53183: python-xdo: Fails to build (failing sanity check)
Hi! When trying to upgrade package `python-xdo 0.3` from Guix commit
`404f6953` to that of commit `4a943cfd`, the build fails with this error:
```
phase `check' succeeded after 0.0 seconds
starting phase `sanity-check'
validating 'xdo'
/gnu/store/2ad74b3s417prg3smyjk7ckxyksa6838-python-xdo-0.3/lib/python3.9/site-packages
...checking requirements: OK
...trying to load module xdo: ERROR:
Traceback (most recent call last):
File "/gnu/store/nwwr89v2vyg1hs48i49m083vhczsgh3m-sanity-check.py", line 69,
in
importlib.import_module(name)
File
"/gnu/store/p5fgysbcnnp8b1d91mrvjvababmczga0-python-3.9.6/lib/python3.9/importlib/__init__.py",
line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 986, in _find_and_load_unlocked
File "", line 680, in _load_unlocked
File "", line 850, in exec_module
File "", line 228, in _call_with_frames_removed
File
"/gnu/store/2ad74b3s417prg3smyjk7ckxyksa6838-python-xdo-0.3/lib/python3.9/site-packages/xdo/__init__.py",
line 8, in
from ._xdo import libxdo as _libxdo
File
"/gnu/store/2ad74b3s417prg3smyjk7ckxyksa6838-python-xdo-0.3/lib/python3.9/site-packages/xdo/_xdo.py",
line 14, in
libc = ctypes.CDLL(ctypes.util.find_library('libc'))
File
"/gnu/store/p5fgysbcnnp8b1d91mrvjvababmczga0-python-3.9.6/lib/python3.9/ctypes/util.py",
line 330, in find_library
_get_soname(_findLib_gcc(name)) or _get_soname(_findLib_ld(name))
File
"/gnu/store/p5fgysbcnnp8b1d91mrvjvababmczga0-python-3.9.6/lib/python3.9/ctypes/util.py",
line 147, in _findLib_gcc
if not _is_elf(file):
File
"/gnu/store/p5fgysbcnnp8b1d91mrvjvababmczga0-python-3.9.6/lib/python3.9/ctypes/util.py",
line 99, in _is_elf
with open(filename, 'br') as thefile:
FileNotFoundError: [Errno 2] No such file or directory: b'liblibc.a'
error: in phase 'sanity-check': uncaught exception:
%exception #<&invoke-error program: "python" arguments:
("/gnu/store/nwwr89v2vyg1hs48i49m083vhczsgh3m-sanity-check.py"
"/gnu/store/2ad74b3s417prg3smyjk7ckxyksa6838-python-xdo-0.3/lib/python3.9/site-packages")
exit-status: 1 term-signal: #f stop-signal: #f>
phase `sanity-check' failed after 0.2 seconds
command "python" "/gnu/store/nwwr89v2vyg1hs48i49m083vhczsgh3m-sanity-check.py"
"/gnu/store/2ad74b3s417prg3smyjk7ckxyksa6838-python-xdo-0.3/lib/python3.9/site-packages"
failed with status 1
```
Attaching the whole
`/var/log/guix/drvs/k6/ndh9y02w2n3f7n98wj0jamfywv3blz-python-xdo-0.3.drv.bz2`.
Thanks, and a happy new year! `:)`
--
Ivan Vilata i Balaguer -- https://elvil.net/
ndh9y02w2n3f7n98wj0jamfywv3blz-python-xdo-0.3.drv.bz2
Description: Binary data
signature.asc
Description: PGP signature
bug#53182: dia: Fails to build (error in Meson build file)
Hi! When trying to upgrade package `dia 0.97.3-2.3cf7ec4` from Guix commit
`404f6953` to that of commit `4a943cfd`, the build fails with this error:
```
[…]
phase `patch-source-shebangs' succeeded after 0.4 seconds
starting phase `configure'
The Meson build system
Version: 0.60.0
Source dir: /tmp/guix-build-dia-0.97.3-2.3cf7ec4.drv-0/source
Build dir: /tmp/guix-build-dia-0.97.3-2.3cf7ec4.drv-0/build
Build type: native build
Project name: dia
Project version: 0.97.3
[…]
Message: wpg_filter
Message: xfig_filter
../source/sheets/meson.build:47:4: ERROR: Function does not take positional
arguments.
A full log can be found at
/tmp/guix-build-dia-0.97.3-2.3cf7ec4.drv-0/build/meson-logs/meson-log.txt
error: in phase 'configure': uncaught exception:
%exception #<&invoke-error program: "meson" arguments:
("--prefix=/gnu/store/ijl7m0cn5xq2sh7n5507j23syrn9sb2x-dia-0.97.3-2.3cf7ec4"
"--buildtype=debugoptimized"
"-Dc_link_args=-Wl,-rpath=/gnu/store/ijl7m0cn5xq2sh7n5507j23syrn9sb2x-dia-0.97.3-2.3cf7ec4/lib"
"-Dcpp_link_args=-Wl,-rpath=/gnu/store/ijl7m0cn5xq2sh7n5507j23syrn9sb2x-dia-0.97.3-2.3cf7ec4/lib"
"/tmp/guix-build-dia-0.97.3-2.3cf7ec4.drv-0/source") exit-status: 1
term-signal: #f stop-signal: #f>
phase `configure' failed after 2.8 seconds
command "meson"
"--prefix=/gnu/store/ijl7m0cn5xq2sh7n5507j23syrn9sb2x-dia-0.97.3-2.3cf7ec4"
"--buildtype=debugoptimized"
"-Dc_link_args=-Wl,-rpath=/gnu/store/ijl7m0cn5xq2sh7n5507j23syrn9sb2x-dia-0.97.3-2.3cf7ec4/lib"
"-Dcpp_link_args=-Wl,-rpath=/gnu/store/ijl7m0cn5xq2sh7n5507j23syrn9sb2x-dia-0.97.3-2.3cf7ec4/lib"
"/tmp/guix-build-dia-0.97.3-2.3cf7ec4.drv-0/source" failed with status 1
```
Attaching the whole
`/var/log/guix/drvs/yh/2fn9w8pmxw5q0bfcs20hhihpp5w6c6-dia-0.97.3-2.3cf7ec4.drv.bz2`.
Thanks, and a happy new year! `:)`
--
Ivan Vilata i Balaguer -- https://elvil.net/
2fn9w8pmxw5q0bfcs20hhihpp5w6c6-dia-0.97.3-2.3cf7ec4.drv.bz2
Description: Binary data
signature.asc
Description: PGP signature
bug#53325: povray: Fails to build (_Pragma errors)
Hi! When trying to upgrade package `povray 3.7.0.8` from Guix commit
`404f6953` to that of commit `4a943cfd`, the build fails showing errors like
these:
```
[…]
depbase=`echo backend/scene/view.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../source/backend -I../source/base
-I../source/frontend -I../unix -I../vfe -I../vfe/unix
-I/gnu/store/l4k60q5jm9g2f3jslnhjsldls0l4vf9q-sdl-1.2.15/include/SDL
-D_GNU_SOURCE=1 -D_REENTRANT -pthread
-I/gnu/store/1wcfmirwkc5lvng6hlqg15v4278fyr96-openexr-2.5.7/include/OpenEXR
-I/gnu/store/s6868fjm48yac4vf2kfdzx7z0kd2ny28-ilmbase-2.5.7/include/OpenEXR
-pthread -I/usr/include -pipe -Wno-multichar -Wno-write-strings
-fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -ffast-math -pthread -MT
backend/scene/view.o -MD -MP -MF $depbase.Tpo -c -o backend/scene/view.o
backend/scene/view.cpp &&\
mv -f $depbase.Tpo $depbase.Po
In file included from
/gnu/store/rwv6khi7hg3hrhij9kimxh53mvg8ksd9-boost-1.77.0/include/boost/math/common_factor.hpp:14,
from backend/scene/view.cpp:34:
/gnu/store/rwv6khi7hg3hrhij9kimxh53mvg8ksd9-boost-1.77.0/include/boost/math/common_factor_ct.hpp:17:68:
error: _Pragma takes a parenthesized string literal
17 | BOOST_MATH_HEADER_DEPRECATED("");
|^
In file included from
/gnu/store/rwv6khi7hg3hrhij9kimxh53mvg8ksd9-boost-1.77.0/include/boost/math/common_factor.hpp:15,
from backend/scene/view.cpp:34:
/gnu/store/rwv6khi7hg3hrhij9kimxh53mvg8ksd9-boost-1.77.0/include/boost/math/common_factor_rt.hpp:14:68:
error: _Pragma takes a parenthesized string literal
14 | BOOST_MATH_HEADER_DEPRECATED("");
|^
In file included from backend/scene/view.cpp:34:
/gnu/store/rwv6khi7hg3hrhij9kimxh53mvg8ksd9-boost-1.77.0/include/boost/math/common_factor.hpp:18:65:
error: _Pragma takes a parenthesized string literal
18 | BOOST_MATH_HEADER_DEPRECATED("");
| ^
[…]
In file included from
/gnu/store/rwv6khi7hg3hrhij9kimxh53mvg8ksd9-boost-1.77.0/include/boost/math/common_factor_ct.hpp:15,
from
/gnu/store/rwv6khi7hg3hrhij9kimxh53mvg8ksd9-boost-1.77.0/include/boost/math/common_factor.hpp:14,
from backend/scene/view.cpp:34:
/gnu/store/rwv6khi7hg3hrhij9kimxh53mvg8ksd9-boost-1.77.0/include/boost/math/common_factor_ct.hpp:17:1:
error: ‘_Pragma’ does not name a type
17 | BOOST_MATH_HEADER_DEPRECATED("");
| ^~~~
/gnu/store/rwv6khi7hg3hrhij9kimxh53mvg8ksd9-boost-1.77.0/include/boost/math/common_factor_rt.hpp:14:1:
error: ‘_Pragma’ does not name a type
14 | BOOST_MATH_HEADER_DEPRECATED("");
| ^~~~
/gnu/store/rwv6khi7hg3hrhij9kimxh53mvg8ksd9-boost-1.77.0/include/boost/math/common_factor.hpp:18:1:
error: ‘_Pragma’ does not name a type
18 | BOOST_MATH_HEADER_DEPRECATED("");
| ^~~~
[…]
make[2]: Leaving directory '/tmp/guix-build-povray-3.7.0.8.drv-0/source/source'
make[1]: *** [Makefile:664: all-recursive] Error 1
make[1]: Leaving directory '/tmp/guix-build-povray-3.7.0.8.drv-0/source'
make: *** [Makefile:457: all] Error 2
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("-j" "4") exit-status: 2
term-signal: #f stop-signal: #f>
phase `build' failed after 168.1 seconds
command "make" "-j" "4" failed with status 2
```
Not completely sure, but the new commit may be using a compiler which isn't
compatible with the version of Boost used by POV-Ray?
Attaching the whole
`/var/log/guix/drvs/ih/kyhpfcn84sg0qbavgaw5rcwxh7cr9w-povray-3.7.0.8.drv.bz2`.
Thanks!
--
Ivan Vilata i Balaguer -- https://elvil.net/
kyhpfcn84sg0qbavgaw5rcwxh7cr9w-povray-3.7.0.8.drv.bz2
Description: Binary data
signature.asc
Description: PGP signature
bug#53326: snap: Fails to build (hash mismatch)
Hi! When trying to upgrade package `snap 6.9.0` from Guix commit `404f6953` to `snap 7.0.3` from commit `4a943cfd`, the build fails with the following output: ``` The following package will be upgraded: snap 6.9.0 -> 7.0.3 The following derivations will be built: /gnu/store/5r399grsmannnm1bxxnk5p35m9hcnvy6-profile.drv /gnu/store/m266r46jhbggn6vp0y6vqj62hb2z3kfs-snap-7.0.3.drv /gnu/store/8sw6g5r83nh2x1pnsqxzz0073q47vrf6-snap-7.0.3-checkout.drv building /gnu/store/8sw6g5r83nh2x1pnsqxzz0073q47vrf6-snap-7.0.3-checkout.drv... \r:sha256 hash mismatch for /gnu/store/6b47h0yqs6c1w2yylwlhzbn9w4kr31cr-snap-7.0.3-checkout: expected hash: 0wqncxqin9g4y15i82qscz0v2fc1br68m6dx47jn4h4kjkmwxccb actual hash: 0l4gws2x9rcgpj9h2wrri3sa4sn3j0q5648jpspyiwlwallp6gbv hash mismatch for store item '/gnu/store/6b47h0yqs6c1w2yylwlhzbn9w4kr31cr-snap-7.0.3-checkout' build of /gnu/store/8sw6g5r83nh2x1pnsqxzz0073q47vrf6-snap-7.0.3-checkout.drv failed View build log at '/var/log/guix/drvs/8s/w6g5r83nh2x1pnsqxzz0073q47vrf6-snap-7.0.3-checkout.drv.bz2'. cannot build derivation `/gnu/store/m266r46jhbggn6vp0y6vqj62hb2z3kfs-snap-7.0.3.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/5r399grsmannnm1bxxnk5p35m9hcnvy6-profile.drv': 1 dependencies couldn't be built guix package: error: build of `/gnu/store/5r399grsmannnm1bxxnk5p35m9hcnvy6-profile.drv' failed ``` The contents of `/var/log/guix/drvs/8s/w6g5r83nh2x1pnsqxzz0073q47vrf6-snap-7.0.3-checkout.drv.bz2` are: ``` guile: warning: failed to install locale environment variable `PATH' set to `/gnu/store/9q9z91mvc1r3h8zmi135msv3j1dgv2js-gzip-1.10/bin:/gnu/store/z3vphwqzvihprnwgb99gra8xnf0hl9yr-tar-1.34/bin' hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: hint: hint: git config --global init.defaultBranch hint: hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and hint: 'development'. The just-created branch can be renamed via this command: hint: hint: git branch -m Initialized empty Git repository in /gnu/store/6b47h0yqs6c1w2yylwlhzbn9w4kr31cr-snap-7.0.3-checkout/.git/ From https://github.com/jmoenig/Snap * tag v7.0.3 -> FETCH_HEAD Note: switching to 'FETCH_HEAD'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false HEAD is now at 14f468c improved arity control for JOIN ``` Maybe the upstream Snap maintainer changed the repo commit where the tag `v7.0.3` points at after the Guix package definition was updated? Thanks! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#53424: tftp-hpa: Fails to build (multiple definition of 'toplevel' when linking)
Hi! When trying to upgrade package `tftp-hpa 5.2` from Guix commit `404f6953`
to that of commit `4a943cfd`, the build fails showing these warnings and
error:
```
starting phase `build'
[…]
gcc -g -O2 -W -Wall -Wpointer-arith -Wbad-function-cast -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline
-Wwrite-strings -Wundef -Wshadow -Wsign-compare -pipe -fno-strict-aliasing
-I/tmp/guix-build-tftp-hpa-5.2.drv-0/tftp-hpa-5.2 -c main.c
tftp.c: In function ‘tftp_sendfile’:
tftp.c:88:5: warning: implicit declaration of function ‘bsd_signal’; did you
mean ‘ssignal’? [-Wimplicit-function-declaration]
88 | bsd_signal(SIGALRM, timer);
| ^~
| ssignal
tftp.c:88:5: warning: nested extern declaration of ‘bsd_signal’
[-Wnested-externs]
main.c: In function ‘main’:
main.c:308:5: warning: implicit declaration of function ‘bsd_signal’; did you
mean ‘ssignal’? [-Wimplicit-function-declaration]
308 | bsd_signal(SIGINT, intr);
| ^~
| ssignal
main.c:308:5: warning: nested extern declaration of ‘bsd_signal’
[-Wnested-externs]
gcc -g -O2 -W -Wall -Wpointer-arith -Wbad-function-cast -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline
-Wwrite-strings -Wundef -Wshadow -Wsign-compare -pipe -fno-strict-aliasing
-I/tmp/guix-build-tftp-hpa-5.2.drv-0/tftp-hpa-5.2 -c misc.c
sed -e 's/@@VERSION@@/5.2/g' < tftp.1.in > tftp.1
gcc -g -O2 -W -Wall -Wpointer-arith -Wbad-function-cast -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline
-Wwrite-strings -Wundef -Wshadow -Wsign-compare -pipe -fno-strict-aliasing
-I/tmp/guix-build-tftp-hpa-5.2.drv-0/tftp-hpa-5.2 -c remap.c
sed -e 's/@@VERSION@@/5.2/g' < tftpd.8.in > tftpd.8
tftpd.c: In function ‘tftp_recvfile’:
tftpd.c:1647:69: warning: argument ‘oap’ might be clobbered by ‘longjmp’ or
‘vfork’ [-Wclobbered]
1647 | static void tftp_recvfile(const struct formats *pf, struct tftphdr
*oap, int oacklen)
| ^~~
main.c:191:20: warning: inlining failed in call to ‘usage’: call is unlikely
and code size would grow [-Winline]
191 | static inline void usage(int errcode)
|^
main.c:244:25: note: called from here
244 | usage(EX_USAGE);
| ^~~
main.c:191:20: warning: inlining failed in call to ‘usage’: call is unlikely
and code size would grow [-Winline]
191 | static inline void usage(int errcode)
|^
main.c:266:25: note: called from here
266 | usage(EX_USAGE);
| ^~~
main.c:191:20: warning: inlining failed in call to ‘usage’: call is unlikely
and code size would grow [-Winline]
191 | static inline void usage(int errcode)
|^
main.c:279:21: note: called from here
279 | usage(*optx == 'h' ? 0 : EX_USAGE);
| ^~
main.c:191:20: warning: inlining failed in call to ‘usage’: call is unlikely
and code size would grow [-Winline]
191 | static inline void usage(int errcode)
|^
main.c:284:17: note: called from here
284 | usage(EX_USAGE);
| ^~~
gcc tftp.o main.o ../common/libcommon.a
/tmp/guix-build-tftp-hpa-5.2.drv-0/tftp-hpa-5.2/lib/libxtra.a -o tftp
ld: main.o:/tmp/guix-build-tftp-hpa-5.2.drv-0/tftp-hpa-5.2/tftp/main.c:98:
multiple definition of `toplevel';
tftp.o:/tmp/guix-build-tftp-hpa-5.2.drv-0/tftp-hpa-5.2/tftp/tftp.c:51: first
defined here
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:12: tftp] Error 1
make[1]: Leaving directory
'/tmp/guix-build-tftp-hpa-5.2.drv-0/tftp-hpa-5.2/tftp'
make: *** [Makefile:7: tftp.build] Error 2
make: *** Waiting for unfinished jobs
gcc tftpd.o recvfrom.o misc.o remap.o ../common/libcommon.a
/tmp/guix-build-tftp-hpa-5.2.drv-0/tftp-hpa-5.2/lib/libxtra.a -o tftpd
make[1]: Leaving directory
'/tmp/guix-build-tftp-hpa-5.2.drv-0/tftp-hpa-5.2/tftpd'
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("-j" "4") exit-status: 2
term-signal: #f stop-signal: #f>
phase `build' failed after 0.8 seconds
command "make" "-j" "4" failed with status 2
```
Maybe something changed with the compiler which causes `toplevel` to be
defined twice, not sure whether the warnings are relevant. Attaching whole
`/var/log/guix/drvs/n7/mi9pqbpgad3gnz97s02zd056qnzcfg-tftp-hpa-5.2.drv.bz2`.
Thanks a lot!
--
Ivan Vilata i Balaguer -- https://elvil.net/
mi9pqbpgad3gnz97s02zd056qnzcfg-tftp-hpa-5.2.drv.bz2
Description: Binary data
signature.asc
Description: PGP signature
bug#53423: nncp: Fails to build (renamed file not found)
Hi! When trying to upgrade package `nncp 7.5.0` from Guix commit `404f6953`
to that of commit `4a943cfd`, the build fails showing this error:
```
phase `unpack' succeeded after 0.1 seconds
starting phase `go-unpack'
i/o error: src: No such file or directory
error: in phase 'go-unpack': uncaught exception:
system-error "rename-file" "~A" ("No such file or directory") (2)
phase `go-unpack' failed after 0.0 seconds
Backtrace:
10 (primitive-load "/gnu/store/lm25qs8vcxx69hn1rj47pjypc9m…")
In guix/build/gnu-build-system.scm:
904:2 9 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
1752:10 8 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9 7 (for-each # …)
In ice-9/boot-9.scm:
1752:10 6 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
925:23 5 (_)
In ice-9/eval.scm:
619:8 4 (_ #(#(#) "/gnu/…"))
In ice-9/boot-9.scm:
260:13 3 (for-each # …)
In unknown file:
2 (rename-file "src/vendor/go.cypherpunks.ru/balloon" "..…")
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure rename-file: No such file or directory
Some deprecated features have been used. Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information. Set it to "no" to suppress
this message.
```
Looks like some bundled dependency is no longer there? Attaching the whole
`/var/log/guix/drvs/rq/p7xarf62882g2n31mgq3z2g616i5hy-nncp-7.5.0.drv.bz2`.
Thanks a lot!
--
Ivan Vilata i Balaguer -- https://elvil.net/
p7xarf62882g2n31mgq3z2g616i5hy-nncp-7.5.0.drv.bz2
Description: Binary data
signature.asc
Description: PGP signature
bug#53425: transfig: Fails to build (issues with libdeps)
Hi! When trying to upgrade package `transfig 3.2.5e` from Guix commit
`404f6953` to that of commit `4a943cfd`, the build fails showing many
instances of warnings like the ones below, and finally the error at the
bottom:
```
starting phase `configure'
[…]
makedepend: warning: genbox.c (reading ../fig2dev.h, line 18): cannot find
include file "stdlib.h"
not in ../stdlib.h
not in ../../stdlib.h
not in
/gnu/store/kz32lsiszh43yi3qxwzzsi434r72i1nk-imake-1.0.8/include/stdlib.h
not in /usr/include/stdlib.h
[…]
phase `configure' succeeded after 0.6 seconds
starting phase `patch-generated-file-shebangs'
patch-shebang: ./doc/MAKEPS: warning: no binary for interpreter `csh' found in
$PATH
patch-shebang: ./fig2dev/fig2ps2tex.script: warning: no binary for interpreter
`csh' found in $PATH
phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
starting phase `build'
[…]
gcc -O2-I.. -I../..
-I/gnu/store/kz32lsiszh43yi3qxwzzsi434r72i1nk-imake-1.0.8/include-Dlinux
-D__amd64__ -D_POSIX_C_SOURCE=199309L
-D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE
-D_SVID_SOURCE -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64
-DFUNCPROTO=15 -DNARROWPROTO -DUSE_PNG -DUSE_XPM -I/usr/include/X11
-I/gnu/store/368cv23ggbgl91bw90hyhkqx5dzq0988-libxpm-3.5.13/include/X11 -DNFSS
-DLATEX2E_GRAPHICS -DDVIPS -DI18N
-DFIG2DEV_LIBDIR=/gnu/store/vxgbyg2kigli0lw59cfb7r64xyf101rq-transfig-3.2.5e/lib
-DFIG2DEV_LIBDIR_STR=\"/gnu/store/vxgbyg2kigli0lw59cfb7r64xyf101rq-transfig-3.2.5e/lib\"
-DBITMAPDIR=\"/gnu/store/vxgbyg2kigli0lw59cfb7r64xyf101rq-transfig-3.2.5e/lib/bitmaps\"
-c -o genbox.o genbox.c
latex_line.c:176:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
176 | latex_endpoint(x1, y1, x2, y2, xout, yout, arrow, magnet)
| ^~
In file included from
/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/include/bits/libc-header-start.h:33,
from
/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/include/stdlib.h:25,
from ../fig2dev.h:18,
from genbox.c:22:
/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/include/features.h:187:3:
warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
_DEFAULT_SOURCE" [-Wcpp]
187 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
_DEFAULT_SOURCE"
| ^~~
[…]
rm -f libtransfig.a
ar clq libtransfig.a genbox.o gencgm.o gendxf.o genepic.o gengbx.o genibmgl.o
genlatex.o genmap.o genmf.o genpic.o genpictex.o genps.o genpdf.o
genpstex.o genpstricks.o gentextyl.o gentk.o genptk.o gentpic.ogenbitmaps.o
genge.o genmp.o genemf.o gensvg.o genshape.o setfigfont.o psencode.o
readpics.o readeps.o readgif.o readpcx.o readppm.o readpng.o readxpm.o
readxbm.o readtif.o readjpg.o asc85ec.o readpng.o readxpm.o
ar: libdeps specified more than once
make[2]: *** [Makefile:1053: libtransfig.a] Error 1
make[2]: Leaving directory
'/tmp/guix-build-transfig-3.2.5e.drv-0/transfig.3.2.5e/fig2dev/dev'
make[1]: *** [Makefile:1192: dev/libtransfig.a] Error 2
make[1]: Leaving directory
'/tmp/guix-build-transfig-3.2.5e.drv-0/transfig.3.2.5e/fig2dev'
make: *** [Makefile:1030: all] Error 2
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("-j" "4") exit-status: 2
term-signal: #f stop-signal: #f>
phase `build' failed after 4.6 seconds
command "make" "-j" "4" failed with status 2
```
Maybe some new version of the compiler got more picky with some deprecations?
I'm attaching the whole
`/var/log/guix/drvs/2x/m0s1604xx2wfzj8swza7jm6s94nz1l-transfig-3.2.5e.drv.bz2`.
Thanks a lot!
--
Ivan Vilata i Balaguer -- https://elvil.net/
m0s1604xx2wfzj8swza7jm6s94nz1l-transfig-3.2.5e.drv.bz2
Description: Binary data
signature.asc
Description: PGP signature
bug#53424: tftp-hpa: Fails to build (multiple definition of 'toplevel' when linking)
Tobias Geerinckx-Rice (2022-01-21 22:20:15 +0100) wrote: > Hullo Ivan, > > At a glance, this *looks* like what is frequently fixed by adding ‘-fcommon’ > to CFLAGS[0]. Worth a try… > > Kind regards, > > T G-R > > [0]: > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ab5d31c53eb06ced0873599a98c74dba80b46b1e (Please note that I know very little about the GNU Build System.) I downloaded the sources with `guix build --source tftp-hpa`, extracted them, ran `guix environment -C --pure tftp-hpa` and in the environment `./configure CFLAGS=-fcommon`, then `make` was able to build everything without error, though warnings were still there. Cheers, -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#53325: povray: Fails to build (_Pragma errors)
Ivan Vilata i Balaguer (2022-01-17 20:58:40 +0100) wrote: > Hi! When trying to upgrade package `povray 3.7.0.8` from Guix commit > `404f6953` to that of commit `4a943cfd`, the build fails showing errors like > these: […] I found what looks like the same issue reported in <https://github.com/POV-Ray/povray/issues/438>. As a commenter suggested, I succeeded to build the package using Boost 1.78, not in the most orthodox way as Guix ships 1.77 and I don't have much knowledge about Guix packaging, following the package definition: $ guix build --source povray /gnu/store/xc4l18mwxzxfvrqmymvkr7yirw1sc6ff-povray-3.7.0.8-checkout $ guix build boost \ --with-source=boost@1.78.0=https://boostorg.jfrog.io/artifactory/main/release/1.78.0/source/boost_1_78_0.tar.bz2 /gnu/store/yiiqd3c7h4f6z0zia5br7wis3wpisgnr-boost-1.78.0 $ cp -r /gnu/store/xc4l18mwxzxfvrqmymvkr7yirw1sc6ff-povray-3.7.0.8-checkout povray-3.7.0.8-checkout $ chmod -R u+w povray-3.7.0.8-checkout; cd povray-3.7.0.8-checkout $ guix environment -C --expose=/gnu/store/yiiqd3c7h4f6z0zia5br7wis3wpisgnr-boost-1.78.0 povray env$ cd unix/ env$ sh prebuild.sh env$ cd .. env$ env COMPILED_BY=Guix ./configure \ --with-boost=/gnu/store/yiiqd3c7h4f6z0zia5br7wis3wpisgnr-boost-1.78.0 \ --with-boost-lib=/gnu/store/yiiqd3c7h4f6z0zia5br7wis3wpisgnr-boost-1.78.0/lib \ --disable-optimiz-arch env$ make # succeeds So one solution would be to upgrade Boost to 1.78, though that may affect many packages. However, given the nature of the error, other packages may eventually get bitten by it. BTW, this is where I think they fixed the Boost issue for 1.78: <https://github.com/boostorg/math/pull/676/files> Cheers! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#53325: povray: Fails to build (_Pragma errors)
Ivan Vilata i Balaguer (2022-01-26 22:57:18 +0100) wrote:
> Ivan Vilata i Balaguer (2022-01-17 20:58:40 +0100) wrote:
>
> > Hi! When trying to upgrade package `povray 3.7.0.8` from Guix commit
> > `404f6953` to that of commit `4a943cfd`, the build fails showing errors like
> > these: […]
>
> I found what looks like the same issue reported in
> <https://github.com/POV-Ray/povray/issues/438>.
>
> As a commenter suggested, I succeeded to build the package using Boost 1.78,
> […] BTW, this is where I think they fixed the Boost issue for 1.78:
> <https://github.com/boostorg/math/pull/676/files>
So I tried to create a patch (attached) which just drops the fixed version of
`header_deprecated.hpp` from Boost 1.78 [1] in Povray's `source` directory,
since that include path has priority over the profile's Boost one during
build. I tried building with:
$ guix build povray
--with-patch=povray=./povray-fix-boost-1.77-math-tools-pragma.patch
[…]
/gnu/store/mp687jry3rb96ff3jbaijibz4klhjicd-povray-3.7.0.8
So it built successfully.
[1]:
https://github.com/boostorg/math/blob/boost-1.78.0/include/boost/math/tools/header_deprecated.hpp
Thus, the patch may be applied until Boost is upgraded to 1.78, at which point
it can be removed.
Thanks!
--
Ivan Vilata i Balaguer -- https://elvil.net/
diff -Nur
povray-3.7.0.8-checkout.orig/source/boost/math/tools/header_deprecated.hpp
povray-3.7.0.8-checkout.new/source/boost/math/tools/header_deprecated.hpp
--- povray-3.7.0.8-checkout.orig/source/boost/math/tools/header_deprecated.hpp
1970-01-01 01:00:00.0 +0100
+++ povray-3.7.0.8-checkout.new/source/boost/math/tools/header_deprecated.hpp
2022-02-07 21:13:43.531100547 +0100
@@ -0,0 +1,27 @@
+// (C) Copyright Matt Borland 2021.
+// Use, modification and distribution are subject to the
+// Boost Software License, Version 1.0. (See accompanying file
+// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+
+#ifndef BOOST_MATH_TOOLS_HEADER_DEPRECATED
+#define BOOST_MATH_TOOLS_HEADER_DEPRECATED
+
+#ifndef BOOST_MATH_STANDALONE
+
+# include
+# define BOOST_MATH_HEADER_DEPRECATED(expr) BOOST_HEADER_DEPRECATED(expr)
+
+#else
+
+# ifdef _MSC_VER
+// Expands to "This header is deprecated; use expr instead."
+# define BOOST_MATH_HEADER_DEPRECATED(expr) __pragma("This header is
deprecated; use " expr " instead.")
+# else // GNU, Clang, Intel, IBM, etc.
+// Expands to "This header is deprecated use expr instead"
+# define BOOST_MATH_HEADER_DEPRECATED_MESSAGE(expr) _Pragma(#expr)
+# define BOOST_MATH_HEADER_DEPRECATED(expr)
BOOST_MATH_HEADER_DEPRECATED_MESSAGE(message "This header is deprecated use "
expr " instead")
+# endif
+
+#endif // BOOST_MATH_STANDALONE
+
+#endif // BOOST_MATH_TOOLS_HEADER_DEPRECATED
signature.asc
Description: PGP signature
bug#38054: [bug#38395] Acknowledgement ([PATCH] gnu: mumble: Update to 1.3.0.)
Efraim Flashner (2019-12-19 15:03:11 +0200) wrote: > I merged the two patches together, made sure all the phases returned #t > and flushed out the commit message some more. Thanks a lot! Comparing your final patch against mine was also very instructive. `:)` -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#38685: emacs-calfw: Fails to build
Hi! After the last package update to commit f2c71f6 I noticed that `emacs-calfw` fails to build. ``` […] starting phase `build' Checking /gnu/store/hv8kyf44mrkag5458cgxc8k6yh6nkcg1-emacs-calfw-1.6/share/emacs/site-lisp/... Compiling /gnu/store/hv8kyf44mrkag5458cgxc8k6yh6nkcg1-emacs-calfw-1.6/share/emacs/site-lisp/calfw-autoloads.el... Compiling /gnu/store/hv8kyf44mrkag5458cgxc8k6yh6nkcg1-emacs-calfw-1.6/share/emacs/site-lisp/calfw-cal.el... Compiling /gnu/store/hv8kyf44mrkag5458cgxc8k6yh6nkcg1-emacs-calfw-1.6/share/emacs/site-lisp/calfw-howm.el... Cannot open load file: No such file or directory, howm command "/gnu/store/wmn02s4a2l5l5zaiv9lwahh808pdlpn4-emacs-minimal-26.3/bin/emacs" "--quick" "--batch" "--eval=(progn (setq byte-compile-debug t) (byte-recompile-directory (file-name-as-directory \"/gnu/store/hv8kyf44mrkag5458cgxc8k6yh6nkcg1-emacs-calfw-1.6/share/emacs/site-lisp\") 0 1))" failed with status 255 builder for `/gnu/store/ykpq20y7a2cars7bsqdg8rfwaxbfmpgc-emacs-calfw-1.6.drv' failed with exit code 1 build of /gnu/store/ykpq20y7a2cars7bsqdg8rfwaxbfmpgc-emacs-calfw-1.6.drv failed View build log at '/var/log/guix/drvs/yk/pq20y7a2cars7bsqdg8rfwaxbfmpgc-emacs-calfw-1.6.drv.bz2'. guix build: error: build of `/gnu/store/ykpq20y7a2cars7bsqdg8rfwaxbfmpgc-emacs-calfw-1.6.drv' failed ``` Attaching the whole `/var/log/guix/drvs/yk/pq20y7a2cars7bsqdg8rfwaxbfmpgc-emacs-calfw-1.6.drv.bz2` file. Thanks and cheers! -- Ivan Vilata i Balaguer -- https://elvil.net/ pq20y7a2cars7bsqdg8rfwaxbfmpgc-emacs-calfw-1.6.drv.bz2 Description: emacs-calfw-1.6.drv.bz2
bug#38054: [bug#38395] Acknowledgement ([PATCH] gnu: mumble: Update to 1.3.0.)
Ivan Vilata i Balaguer (2019-12-19 11:51:55 -0500) wrote: > Efraim Flashner (2019-12-19 15:03:11 +0200) wrote: > > > I merged the two patches together, made sure all the phases returned #t > > and flushed out the commit message some more. > > Thanks a lot! Comparing your final patch against mine was also very > instructive. `:)` Before you close this issue, I upgraded my `mumble` package and many icons are missing. I didn't yet have time to further investigate it, but maybe it's because of a difference I noticed between your patch: (modify-phases %standard-phases and mine: (modify-phases (@ (guix build qt-build-system) %standard-phases) So maybe the problem is that the final, wrapping phase of `qt-build-system` is not being run. Actually I see that `mumble` is a plain binary while in the output from my patch, it was a wrapper script. Thanks! -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#38054: [bug#38395] Acknowledgement ([PATCH] gnu: mumble: Update to 1.3.0.)
Efraim Flashner (2019-12-22 12:56:04 +0200) wrote: > On Fri, Dec 20, 2019 at 11:07:58AM -0500, Ivan Vilata i Balaguer wrote: > > > > Before you close this issue, I upgraded my `mumble` package and many icons > > are > > missing. I didn't yet have time to further investigate it, but maybe it's > > because of a difference I noticed between your patch: > > > > (modify-phases %standard-phases > > > > and mine: > > > > (modify-phases (@ (guix build qt-build-system) %standard-phases) > > > > So maybe the problem is that the final, wrapping phase of `qt-build-system` > > is > > not being run. Actually I see that `mumble` is a plain binary while in the > > output from my patch, it was a wrapper script. > > I'm not sure what happened with the wrapping phase, but I changed it > back and now everything should be working as expected. Works indeed now, than you! `:)` -- Ivan Vilata i Balaguer -- https://elvil.net/
bug#63270: d-feet: Fails to build (Function does not take positional arguments)
Hi! It looks like the Meson build of `d-feet` fails to complete in the
version of Guix shown below:
```
$ guix describe
Generation 56 May 02 2023 11:25:26(current)
guix 3f8c489
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 3f8c4899a9a67bb509a603bd21dcfcfab88c0e8e
```
This is the final part of the build log:
```
starting phase `configure'
The Meson build system
Version: 1.1.0
Source dir: /tmp/guix-build-d-feet-0.3.16.drv-0/d-feet-0.3.16
Build dir: /tmp/guix-build-d-feet-0.3.16.drv-0/build
Build type: native build
Project name: d-feet
Project version: 0.3.16
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program python3 found: YES
(/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/bin/python3)
Found pkg-config:
/gnu/store/jz5dwdxq4di29cd0rjjzkw356dhkzjil-pkg-config-0.29.2/bin/pkg-config
(0.29.2)
Run-time dependency gtk+-3.0 found: YES 3.24.37
Run-time dependency gobject-introspection-1.0 found: YES 1.72.0
Run-time dependency gio-2.0 found: YES 2.72.3
Program msgfmt found: YES
(/gnu/store/5d0fgnmh63yx98s1kfp57rc2x05xqk1d-gettext-minimal-0.21/bin/msgfmt)
Program msginit found: YES
(/gnu/store/5d0fgnmh63yx98s1kfp57rc2x05xqk1d-gettext-minimal-0.21/bin/msginit)
Program msgmerge found: YES
(/gnu/store/5d0fgnmh63yx98s1kfp57rc2x05xqk1d-gettext-minimal-0.21/bin/msgmerge)
Program xgettext found: YES
(/gnu/store/5d0fgnmh63yx98s1kfp57rc2x05xqk1d-gettext-minimal-0.21/bin/xgettext)
Configuring d-feet using configuration
Configuring tests.py using configuration
Program pep8 found: YES
(/gnu/store/09j78kk5zw662qw8y949ndswqp23193b-python-pep8-1.7.0/bin/pep8)
Configuring org.gnome.dfeet.desktop.in using configuration
../d-feet-0.3.16/data/meson.build:15:5: ERROR: Function does not take
positional arguments.
A full log can be found at
/tmp/guix-build-d-feet-0.3.16.drv-0/build/meson-logs/meson-log.txt
error: in phase 'configure': uncaught exception:
%exception #<&invoke-error program: "meson" arguments: ("setup"
"--prefix=/gnu/store/y414lsncri13kn6wz1hzhgzy6lpbivlf-d-feet-0.3.16"
"--buildtype=debugoptimized"
"-Dc_link_args=-Wl,-rpath=/gnu/store/y414lsncri13kn6wz1hzhgzy6lpbivlf-d-feet-0.3.16/lib"
"-Dcpp_link_args=-Wl,-rpath=/gnu/store/y414lsncri13kn6wz1hzhgzy6lpbivlf-d-feet-0.3.16/lib"
"/tmp/guix-build-d-feet-0.3.16.drv-0/d-feet-0.3.16") exit-status: 1
term-signal: #f stop-signal: #f>
phase `configure' failed after 0.7 seconds
command "meson" "setup"
"--prefix=/gnu/store/y414lsncri13kn6wz1hzhgzy6lpbivlf-d-feet-0.3.16"
"--buildtype=debugoptimized"
"-Dc_link_args=-Wl,-rpath=/gnu/store/y414lsncri13kn6wz1hzhgzy6lpbivlf-d-feet-0.3.16/lib"
"-Dcpp_link_args=-Wl,-rpath=/gnu/store/y414lsncri13kn6wz1hzhgzy6lpbivlf-d-feet-0.3.16/lib"
"/tmp/guix-build-d-feet-0.3.16.drv-0/d-feet-0.3.16" failed with status 1
```
Unfortunately I know nothing about Meson, so I can't suggest a way to go…
Thanks and have a nice day!
--
Ivan Vilata i Balaguer -- https://elvil.net/
signature.asc
Description: PGP signature
bug#63274: dia: Fails to build (Meson: Function does not take positional arguments)
Hi! It looks like the Meson build of `dia` fails to complete in the version
of Guix shown below:
```
$ LANG=C guix describe
Generation 56 May 02 2023 11:25:26(current)
guix 3f8c489
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 3f8c4899a9a67bb509a603bd21dcfcfab88c0e8e
```
This is the final part of the build log:
```
starting phase `configure'
The Meson build system
Version: 1.1.0
Source dir: /tmp/guix-build-dia-0.97.3-3.0997887.drv-0/source
Build dir: /tmp/guix-build-dia-0.97.3-3.0997887.drv-0/build
Build type: native build
Project name: dia
Project version: 0.97.3
C compiler for the host machine: gcc (gcc 11.3.0 "gcc (GCC) 11.3.0")
C linker for the host machine: gcc ld.bfd 2.38
C++ compiler for the host machine: c++ (gcc 11.3.0 "c++ (GCC) 11.3.0")
C++ linker for the host machine: c++ ld.bfd 2.38
[…]
Message: wpg_filter
Message: xfig_filter
../source/sheets/meson.build:47:32: ERROR: Function does not take positional
arguments.
A full log can be found at
/tmp/guix-build-dia-0.97.3-3.0997887.drv-0/build/meson-logs/meson-log.txt
error: in phase 'configure': uncaught exception:
%exception #<&invoke-error program: "meson" arguments: ("setup"
"--prefix=/gnu/store/v5syv2awp33lvq0fl1pavvpxv53i0w93-dia-0.97.3-3.0997887"
"--buildtype=debugoptimized"
"-Dc_link_args=-Wl,-rpath=/gnu/store/v5syv2awp33lvq0fl1pavvpxv53i0w93-dia-0.97.3-3.0997887/lib"
"-Dcpp_link_args=-Wl,-rpath=/gnu/store/v5syv2awp33lvq0fl1pavvpxv53i0w93-dia-0.97.3-3.0997887/lib"
"/tmp/guix-build-dia-0.97.3-3.0997887.drv-0/source") exit-status: 1
term-signal: #f stop-signal: #f>
phase `configure' failed after 3.0 seconds
command "meson" "setup"
"--prefix=/gnu/store/v5syv2awp33lvq0fl1pavvpxv53i0w93-dia-0.97.3-3.0997887"
"--buildtype=debugoptimized"
"-Dc_link_args=-Wl,-rpath=/gnu/store/v5syv2awp33lvq0fl1pavvpxv53i0w93-dia-0.97.3-3.0997887/lib"
"-Dcpp_link_args=-Wl,-rpath=/gnu/store/v5syv2awp33lvq0fl1pavvpxv53i0w93-dia-0.97.3-3.0997887/lib"
"/tmp/guix-build-dia-0.97.3-3.0997887.drv-0/source" failed with status 1
```
I know nothing about Meson, but the error reminds me of
<https://issues.guix.gnu.org/53182>, and I see that its fix 3969dc45 added
`(arguments `(#:meson ,meson-0.59))`, which was removed later in f38d8e05.
Thanks and have a nice day!
--
Ivan Vilata i Balaguer -- https://elvil.net/
signature.asc
Description: PGP signature
bug#63280: encfs: Fails to build (test segfaults)
Hi! It looks like one of the tests in package `encfs` consistently segfaults
in the version of Guix shown below:
```
$ LANG=C guix describe
Generation 56 May 02 2023 11:25:26(current)
guix 3f8c489
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 3f8c4899a9a67bb509a603bd21dcfcfab88c0e8e
```
This is the final part of the build log:
```
starting phase `check'
Running tests...
/gnu/store/ygab8v4ci9iklaykapq52bfsshpvi8pw-cmake-minimal-3.24.2/bin/ctest
--force-new-ctest-process
Test project /tmp/guix-build-encfs-1.9.5.drv-0/build
Start 1: unit
1/1 Test #1: unit .***Exception: SegFault 0.01 sec
Running main() from
/tmp/guix-build-encfs-1.9.5.drv-0/encfs-1.9.5/vendor/github.com/google/googletest/googletest/src/gtest_main.cc
[==] Running 16 tests from 2 test suites.
[--] Global test environment set-up.
[--] 1 test from MemoryPool
[ RUN ] MemoryPool.Allocate
[ OK ] MemoryPool.Allocate (0 ms)
[--] 1 test from MemoryPool (0 ms total)
[--] 15 tests from CipherKey/CipherTest
[ RUN ] CipherKey/CipherTest.SaveRestoreKey/0
[ OK ] CipherKey/CipherTest.SaveRestoreKey/0 (5 ms)
[ RUN ] CipherKey/CipherTest.SaveRestoreKey/1
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 0.01 sec
The following tests FAILED:
1 - unit (SEGFAULT)
Errors while running CTest
make: *** [Makefile:94: test] Error 8
Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("test" "-j" "4")
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 0.0 seconds
command "make" "test" "-j" "4" failed with status 2
```
I saw a couple of encfs issues regarding segfaults in tests, but I don't think
they're related: <https://github.com/vgough/encfs/issues/378>
<https://github.com/vgough/encfs/issues/600>
Thanks a lot, and cheers!
--
Ivan Vilata i Balaguer -- https://elvil.net/
signature.asc
Description: PGP signature
bug#63284: proot: Build gets stuck in test-0cf405b0 (and maybe test-25069c13)
Hi! It looks like some tests during the build of `proot` get stuck in the version of Guix shown below: ``` $ LANG=C guix describe Generation 56 May 02 2023 11:25:26(current) guix 3f8c489 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 3f8c4899a9a67bb509a603bd21dcfcfab88c0e8e ``` Since `top` reported a couple of tests getting stuck, I first ran `guix build -c1 proot`; its last lines were: ``` CHECK test- ok CHECK test-proocare skipped CHECK test-ptrace-exec-trap ok CHECK test-python01 ok CHECK test- ok CHECK test-tempdire ok CHECK test- ok CHECK test- ok ``` It got stock there and `top` reported the following test (`test-0cf405b0`) using CPU: ``` 21490 guixbui+ 20 0 10,8m 4,0m 0,0 0,0 0:00.03 S `- make check -C test -j 1 24340 guixbui+ 20 06,4m 2,9m 0,0 0,0 0:00.00 S `- /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh -c if [ -e /tmp/guix-build-proot-5.3.0.drv-0/source/test//rootfs/bin/test-0cf405b0 ]; then /tmp/guix+ 24341 guixbui+ 20 07,1m 3,1m 55,0 0,0 0:42.21 S `- /tmp/guix-build-proot-5.3.0.drv-0/source/test//../src/proot -b /proc -r /tmp/guix-build-proot-5.3.0.drv-0/source/test//rootfs /bin/test-0cf405b0 24342 guixbui+ 20 00,9m 0,4m 45,7 0,0 0:34.71 t `- ``` Then I ran again `guix build -c4 proot` (4 cores is the default on my computer); its last lines were: ``` CHECK test- ok CHECK test-proocare skipped CHECK test-ptrace-exec-trap ok CHECK test-python01 ok CHECK test- ok CHECK test-tempdire ok CHECK test- ok CHECK test- ok CHECK test-gdb-ptrace ok CHECK test-1c68c218 ok CHECK test-305ae31d ok CHECK test- ok CHECK test-3334 ok CHECK test- ok CHECK test-51943658 ok CHECK test- ok CHECK test-79cf6614 ok CHECK test- ok CHECK test-a8e69d6f ok CHECK test-af062114 ok CHECK test-bug-138 ok CHECK test-c10e2073 ok CHECK test-d2175fc4 ok CHECK test-e87b34ae ok CHECK test- ok CHECK test- ok CHECK test-ptrace00 ok CHECK test-ptrace01 ok CHECK test- ok CHECK test- ok ``` It got stock there and `top` reported the following tests (`test-0cf405b0` and `test-25069c12`) taking CPU: ``` 9960 guixbui+ 20 0 11,0m 4,0m 0,0 0,0 0:00.06 S `- make check -C test -j 4 10535 guixbui+ 20 06,4m 2,9m 0,0 0,0 0:00.00 S `- /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh -c if [ -e test-25069c12 ]; then /tmp/guix-build-proot-5.3.0.drv-0/source/test//../src/proot ./test-+ 10536 guixbui+ 20 07,1m 3,1m 66,0 0,0 17:29.84 R `- /tmp/guix-build-proot-5.3.0.drv-0/source/test//../src/proot ./test-25069c12 10537 guixbui+ 20 00,4m 0,1m 32,1 0,0 8:36.58 t `- 10543 guixbui+ 20 06,4m 2,9m 0,0 0,0 0:00.00 S `- /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh -c if [ -e test-25069c13 ]; then /tmp/guix-build-proot-5.3.0.drv-0/source/test//../src/proot ./test-+ 10544 guixbui+ 20 07,1m 3,1m 66,0 0,0 17:29.99 R `- /tmp/guix-build-proot-5.3.0.drv-0/source/test//../src/proot ./test-25069c13 10545 guixbui+ 20 00,4m 0,1m 32,1 0,0 8:36.61 t `- 13202 guixbui+ 20 06,4m 2,9m 0,0 0,0 0:00.00 S `- /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh -c if [ -e /tmp/guix-build-proot-5.3.0.drv-0/source/test//rootfs/bin/test-0cf405b0 ]; then /tmp/guix+ 13203 guixbui+ 20 07,1m 3,1m 52,8 0,0 13:52.96 S `- /tmp/guix-build-proot-5.3.0.drv-0/source/test//../src/proot -b /proc -r /tmp/guix-build-proot-5.3.0.drv-0/source/test//rootfs /bin/test-0cf405b0 13204 guixbui+ 20 00,9m 0,0m 44,0 0,0 11:43.34 R `- ``` Thanks and cheers! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#63313: python-txtorcon: Build failure (Sequence not in collection in Python 3.10)
Hi! Building `python-txtorcon` 19.0.0 fails in the version of Guix shown
below:
```
$ LANG=C guix describe
Generation 56 May 02 2023 11:25:26(current)
guix 3f8c489
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 3f8c4899a9a67bb509a603bd21dcfcfab88c0e8e
```
This is not <https://issues.guix.gnu.org/62924>, but an error caused by Python
3.10 completely removing abstract classes from `collections`. This is the
final part of the build log:
```
starting phase `sanity-check'
validating 'txtorcon'
/gnu/store/082pb14w482w6i175p7dxzwj60wnsqjs-python-txtorcon-19.0.0/lib/python3.10/site-packages
...checking requirements: OK
...trying to load module twisted: OK
...trying to load module txtorcon: ERROR:
Traceback (most recent call last):
File "/gnu/store/iqsjkp55pcx5bfcp2jm9yj5rlx9a0whd-sanity-check.py", line 73,
in
importlib.import_module(name)
File
"/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/importlib/__init__.py",
line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1050, in _gcd_import
File "", line 1027, in _find_and_load
File "", line 1006, in _find_and_load_unlocked
File "", line 688, in _load_unlocked
File "", line 883, in exec_module
File "", line 241, in _call_with_frames_removed
File
"/gnu/store/082pb14w482w6i175p7dxzwj60wnsqjs-python-txtorcon-19.0.0/lib/python3.10/site-packages/txtorcon/__init__.py",
line 16, in
from txtorcon.controller import connect
File
"/gnu/store/082pb14w482w6i175p7dxzwj60wnsqjs-python-txtorcon-19.0.0/lib/python3.10/site-packages/txtorcon/controller.py",
line 14, in
from collections import Sequence
ImportError: cannot import name 'Sequence' from 'collections'
(/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/collections/__init__.py)
error: in phase 'sanity-check': uncaught exception:
%exception #<&invoke-error program: "python" arguments:
("/gnu/store/iqsjkp55pcx5bfcp2jm9yj5rlx9a0whd-sanity-check.py"
"/gnu/store/082pb14w482w6i175p7dxzwj60wnsqjs-python-txtorcon-19.0.0/lib/python3.10/site-packages")
exit-status: 1 term-signal: #f stop-signal: #f>
phase `sanity-check' failed after 0.7 seconds
command "python" "/gnu/store/iqsjkp55pcx5bfcp2jm9yj5rlx9a0whd-sanity-check.py"
"/gnu/store/082pb14w482w6i175p7dxzwj60wnsqjs-python-txtorcon-19.0.0/lib/python3.10/site-packages"
failed with status 1
```
It was reported in <https://github.com/meejah/txtorcon/issues/336> and fixed
in <https://github.com/meejah/txtorcon/commit/cc7ed186>, and incorporated to
version 20.0.0 as noted here:
<https://github.com/meejah/txtorcon/releases/tag/v20.0.0>.
Thanks and good weekend!
--
Ivan Vilata i Balaguer -- https://elvil.net/
signature.asc
Description: PGP signature
bug#63280: encfs: Fails to build (test segfaults)
Ivan Vilata i Balaguer (2023-05-04 18:46:54 +0200) wrote: > Hi! It looks like one of the tests in package `encfs` consistently segfaults > in the version of Guix shown below: > > ``` > […] > commit: 3f8c4899a9a67bb509a603bd21dcfcfab88c0e8e > ``` > > This is the final part of the build log: > > ``` > starting phase `check' > Running tests... > /gnu/store/ygab8v4ci9iklaykapq52bfsshpvi8pw-cmake-minimal-3.24.2/bin/ctest > --force-new-ctest-process > Test project /tmp/guix-build-encfs-1.9.5.drv-0/build > Start 1: unit > 1/1 Test #1: unit .***Exception: SegFault 0.01 > sec > Running main() from > /tmp/guix-build-encfs-1.9.5.drv-0/encfs-1.9.5/vendor/github.com/google/googletest/googletest/src/gtest_main.cc > […] > ``` > > I saw a couple of encfs issues regarding segfaults in tests, but I don't think > they're related: <https://github.com/vgough/encfs/issues/378> > <https://github.com/vgough/encfs/issues/600> I repeated the build with Guix commit 14c03807 and `encfs` tests failed in the same way. I tested the fix in <https://github.com/vgough/encfs/issues/600>, i.e. `guix build encfs --with-input=openssl=openssl@1.1.1q`, and the build succeeded, tests and all. I also tried `--with-graft` instead of `--with-input`, but the issue happened again. I hope that this is useful! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#63280: encfs: Fails to build (test segfaults)
Ivan Vilata i Balaguer (2023-05-19 13:40:27 +0200) wrote: > I repeated the build with Guix commit 14c03807 and `encfs` tests failed in the > same way. I tested the fix in <https://github.com/vgough/encfs/issues/600>, > i.e. `guix build encfs --with-input=openssl=openssl@1.1.1q`, and the build > succeeded, tests and all. I also tried `--with-graft` instead of > `--with-input`, but the issue happened again. I rebuilt `--with-git-url=encfs=https://github.com/vgough/encfs.git` with the same result. However, I copied the definition of the `encfs` package to another file, changed `(inputs (list attr fuse openssl tinyxml2))` to `(inputs (list attr fuse openssl-1.1 tinyxml2))` (i.e. `openssl -> openssl-1.1`), and the built succeeded and tests passed. Please note that <https://github.com/vgough/encfs/issues/600#issuecomment-950026929> points out that, around 3 years after the release of EncFS v1.9.5 (the version used in Guix), OpenSSL v3 was still very recent, so EncFS may have never been thoroughly tested with it anyway. Maybe reverting to its dependency to OpenSSL v1.1 would be a good choice (esp. since v1.1 still receives fixes). Cheers! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#63284: proot: Build gets stuck in test-0cf405b0 (and maybe test-25069c13)
Same for me both building with: guix build proot --with-version=proot=5.4.0 And altering the definition of the package manually to use `(version "5.4.0")` (hash `186qsg4yvisqjgf8w5jxhnlig7x341vpqwcgp8as3r59qmqkpmk7`), plus removing `libarchive` from `inputs` (as v5.3.1 already removed that dependency). Thanks! Blake Shaw (2023-05-07 15:55:04 +0700) wrote: > I'm also dealing with the issue, except for me it gets stuck in > test-kkk, if that info is helpful at all. > > Josselin Poiret via Bug reports for GNU Guix writes: > > > Ivan Vilata i Balaguer writes: > > > >> Hi! It looks like some tests during the build of `proot` get stuck in the > >> version of Guix shown below: > > > > I already provided fixes for two tests upstream [1] but I'm waiting on > > [2] since it seems like an actual regression. > > > [1] https://github.com/proot-me/proot/pull/351 > > [2] https://github.com/proot-me/proot/issues/352 -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#63270: d-feet: Fails to build (Function does not take positional arguments)
Liliana Marie Prikler (2023-05-04 19:48:34 +0200) wrote: > Am Donnerstag, dem 04.05.2023 um 17:13 +0200 schrieb Ivan Vilata i > Balaguer: > > ``` > > ../d-feet-0.3.16/data/meson.build:15:5: ERROR: Function does not take > > positional arguments. > > ``` > Looking at d-feet itself, it appears as though it has been all but > deprecated in the favour of d-spy. Perhaps guix should simply declare > it a deprecated package instead of attempting to patch it – a patch has > already been filed upstream previously, but is not yet merged any > branch as far as I'm aware. Thanks for the info! For reference, this looks like the mentioned patch: <https://gitlab.gnome.org/GNOME/d-feet/-/merge_requests/32> Cheers! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#63274: dia: Fails to build (Meson: Function does not take positional arguments)
Ivan Vilata i Balaguer (2023-05-04 17:26:48 +0200) wrote: > Hi! It looks like the Meson build of `dia` fails to complete in the version > of Guix shown below: > > ``` > […] > commit: 3f8c4899a9a67bb509a603bd21dcfcfab88c0e8e > ``` > > This is the final part of the build log: > > ``` > starting phase `configure' > The Meson build system > […] > ../source/sheets/meson.build:47:32: ERROR: Function does not take positional > arguments. > […] > ``` The latest commit in Dia's Git repo (just 3 after the one use by Guix) states "build: Fix deprecated positional argument for i18n.merge_file": <https://gitlab.gnome.org/GNOME/dia/-/commit/6ef461d8a04ffcd23df26fc4749cebc6322a5322> Building `--with-commit=dia=6ef461d8a04ffcd23df26fc4749cebc6322a5322` is successful. I'll send a patch to fix this. Cheers! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#63274: [PATCH v2] gnu: dia: Update to 0.97.3-4.b903dd8 to fix Meson build.
Fixes <https://issues.guix.gnu.org/63274>. * gnu/packages/gnome.scm (dia): Update to 0.97.3-4.b903dd8 --- gnu/packages/gnome.scm | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm index 754bb668ba..ae891d6cc3 100644 --- a/gnu/packages/gnome.scm +++ b/gnu/packages/gnome.scm @@ -74,6 +74,7 @@ ;;; Copyright © 2022 Alexandros Theodotou ;;; Copyright © 2022 Arjan Adriaanse ;;; Copyright © 2023 Kaelyn Takata +;;; Copyright © 2023 Giovanni Biscuolo ;;; ;;; This file is part of GNU Guix. ;;; @@ -1951,8 +1952,8 @@ (define-public dia ;; recent versions of the build tools. The latest activity on the ;; pre-GNOME version has been in 2014, while GNOME has continued applying ;; fixes since. - (let ((commit "0997887d97f01be28bf3886dfd3e2002de437930") -(revision "3")) + (let ((commit "b903dd83aa5aab1b41c7864dd5027d1b6a0a190c") +(revision "4")) (package (name "dia") (version (git-version "0.97.3" revision commit)) @@ -1964,7 +1965,7 @@ (define-public dia (file-name (git-file-name name version)) (sha256 (base32 - "199b4n1jydg1g9lnz0r8xx67h7s2ac2lfj89zp015lbs0qqfkmsh" + "0j5q7whwpzzfsinjryp3g0xh3cyy88drwyr0w8x0666mj6h70h6a" (build-system meson-build-system) ;; XXX: Parallel builds may cause: [74/566] [...] ;; fatal error: dia-lib-enums.h: No such file or directory base-commit: 0aab24855238cc7c7a31066ab39cd94e534b857f -- 2.39.2 -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#63274: dia: Fails to build (Meson: Function does not take positional arguments)
Giovanni Biscuolo (2023-05-20 10:15:58 +0200) wrote: > Hello Ivan, > > Ivan Vilata i Balaguer writes: > > > The latest commit in Dia's Git repo (just 3 after the one use by Guix) > > states > > "build: Fix deprecated positional argument for i18n.merge_file": > > <https://gitlab.gnome.org/GNOME/dia/-/commit/6ef461d8a04ffcd23df26fc4749cebc6322a5322> > > > > Building `--with-commit=dia=6ef461d8a04ffcd23df26fc4749cebc6322a5322` is > > successful. > > > > I'll send a patch to fix this. > > I sent a patch on May 5th as #63274 [1] using commit > b903dd83aa5aab1b41c7864dd5027d1b6a0a190c, please send a V2 patch if you > think is better > > Thanks! Gio' > > [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63274 Thanks Giovanni! Sorry that I didn't know about your patch, it looks like Guix debbugs doesn't send copies of messages in the bug thread to involved addresses (not even to the original poster 🙁)… I kinda assumed it behaved like Debian's. I'll remember to check the issue page and use "reply to all" next time, just in case. Yesterday I sent patch <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63592> (v2), not knowing about yours. I just checked your patch and it points to a more recent commit than my patch, so I guess it fixes even more stuff, and I see that Guix' version has anyway been quite ahead 1.9.5 for a while. So I guess that your patch makes more sense. However, I see that you forgot to add your copyright entry at the beginning of the file, and you may want to specify that the patch fixes this issue too (you may want to adapt the commit message from my v2 patch). I sent a new version of your patch which just fixes that. I'll ask to close my other patch issue. Thanks again! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#63280: encfs: Fails to build (test segfaults)
Ivan Vilata i Balaguer (2023-05-19 14:11:37 +0200) wrote: > […] I copied the definition of the `encfs` package to another file, > changed `(inputs (list attr fuse openssl tinyxml2))` to `(inputs (list attr > fuse openssl-1.1 tinyxml2))` (i.e. `openssl -> openssl-1.1`), and the built > succeeded and tests passed. > > Please note that > <https://github.com/vgough/encfs/issues/600#issuecomment-950026929> points out > that, around 3 years after the release of EncFS v1.9.5 (the version used in > Guix), OpenSSL v3 was still very recent, so EncFS may have never been > thoroughly tested with it anyway. > > Maybe reverting to its dependency to OpenSSL v1.1 would be a good choice > (esp. since v1.1 still receives fixes). I sent a patch doing that: <https://issues.guix.gnu.org/63593> (Is it better to send the patch as a reply to this thread?) Thanks! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#63649: python-zope-exceptions: Build failure (in test_multiline_exception test) with Python 3.10
Hi! Building `python-zope-exceptions` 4.4 fails in the version of Guix shown
below:
```
$ LANG=C guix describe
Generation 56 May 02 2023 11:25:26(current)
guix 3f8c489
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 3f8c4899a9a67bb509a603bd21dcfcfab88c0e8e
```
It looks like a Python 3.10 issue fixed in a newer upstream version. This is
the final part of the build log:
```
starting phase `check'
Running zope.testrunner.layer.UnitTests tests:
Set up zope.testrunner.layer.UnitTests in 0.000 seconds.
Failure in test test_multiline_exception
(zope.exceptions.tests.test_exceptionformatter.Test_format_exception)
Traceback (most recent call last):
File
"/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/unittest/case.py",
line 59, in testPartExecutor
yield
File
"/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/unittest/case.py",
line 591, in run
self._callTestMethod(testMethod)
File
"/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/unittest/case.py",
line 549, in _callTestMethod
method()
File
"/gnu/store/yflssryyj355226m2nq5m4971s88cmpz-python-zope-exceptions-bootstrap-4.4/lib/python3.10/site-packages/zope/exceptions/tests/test_exceptionformatter.py",
line 670, in test_multiline_exception
self.assertTrue(lines[1].endswith('^'))
File
"/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/unittest/case.py",
line 687, in assertTrue
raise self.failureException(msg)
AssertionError: False is not true
```
Looking at the failing line, it looks like the commit below fixed it for
Python 3.10 compatibility:
<https://github.com/zopefoundation/zope.exceptions/commit/cb2d21400c95b73909b1145674c08fed31b8759a>
Probably version >= 4.5 of the package (which claims "Add official support for
Python 3.9 and 3.10." does work (I've been unable to figure out the proper
`--with-` incantation to assert that).
Thanks!
--
Ivan Vilata i Balaguer -- https://elvil.net/
signature.asc
Description: PGP signature
bug#63649: [PATCH] gnu: python-zope-exceptions: Update to 4.6, Python 3.10 compatible.
Versions 4.5 and 4.6 seem to be backwards-compatible with 4.5, and they add official support for Python 3.9, 3.10 and 3.11. Fixes <https://issues.guix.gnu.org/63649>. * gnu/packages/python-web.scm (python-zope-exceptions): Update to 4.6. --- gnu/packages/python-web.scm | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gnu/packages/python-web.scm b/gnu/packages/python-web.scm index b6ad489626..32c0de3f57 100644 --- a/gnu/packages/python-web.scm +++ b/gnu/packages/python-web.scm @@ -59,6 +59,7 @@ ;;; Copyright © 2022 Michael Rohleder ;;; Copyright © 2022 Baptiste Strazzulla ;;; Copyright © 2023 John Kehayias +;;; Copyright © 2023 Ivan Vilata-i-Balaguer ;;; ;;; This file is part of GNU Guix. ;;; @@ -2493,14 +2494,14 @@ (define-public python-zope-interface (define-public python-zope-exceptions (package (name "python-zope-exceptions") -(version "4.4") +(version "4.6") (source (origin (method url-fetch) (uri (pypi-uri "zope.exceptions" version)) (sha256 (base32 - "1nkgfwawswmyc6i0b8g3ymvja4mb507m8yhid8s4rbxq3dmqhwhd" + "1kc3hql2i35ys5alkj9csiaz2s9bx0rff585vnrrgvavqsj297b1" (build-system python-build-system) (arguments '(#:phases base-commit: dff1689bb37e5303868584d3f1d7a33cbcb7f51e -- 2.39.2 -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#63660: Manual: Example for multiple SLiM instances doesn't work
Hi! Under section "X Window", the Guix Manual provides an example on "how to replace the default GDM service with two SLiM services on tty7 and tty8": ``` (use-modules (gnu services) (gnu services desktop) (gnu services xorg)) (operating-system ;; ... (services (cons* (service slim-service-type (slim-configuration (display ":0") (vt "vt7"))) (service slim-service-type (slim-configuration (display ":1") (vt "vt8"))) (modify-services %desktop-services (delete gdm-service-type) ``` Unfortunately, reconfiguring a system (on commit 14c03807) reports the following error: guix system: error: service 'xorg-server' provided more than once Actually, leaving just the first `service` entry still produces the same error. One needs to also add a second argument to `xorg-configuration`, like this: ``` (set-xorg-configuration (xorg-configuration […]) slim-service-type) ``` And then the `service` entry can actually be removed. To summarize, these are the changes that I needed for actually having *one* operational SLiM instance: ``` (operating-system (packages (cons* (specification->package "slim") %base-packages)) (services (cons* (set-xorg-configuration (xorg-configuration […]) slim-service-type) (modify-services %desktop-services (delete gdm-service-type) ``` For completeness sake, adding the two `service` entries causes the error: guix system: error: more than one target service of type 'slim' as already discussed in <https://issues.guix.gnu.org/55391>. There's a possible workaround explained there which implies duplicating the Xorg server configuration. But maybe I missed some point in the instructions. Otherwise, I wonder whether they should be either fixed, or updated for a single-instance example that does work (which may be ok as that's probably the most common use case). Thanks, and cheers! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
bug#53325: povray: Fails to build (_Pragma errors) [FIXED]
I tried installing the package again under Guix 44bbfc24 and it installed successfully. It was probably working after a59afdc9 (2022-02-03), which updated Boost to 1.78.0. This issue may be closed, thanks! Ivan Vilata i Balaguer (2022-02-07 23:43:18 +0100) wrote: > Ivan Vilata i Balaguer (2022-01-26 22:57:18 +0100) wrote: > > > Ivan Vilata i Balaguer (2022-01-17 20:58:40 +0100) wrote: > > > > > Hi! When trying to upgrade package `povray 3.7.0.8` from Guix commit > > > `404f6953` to that of commit `4a943cfd`, the build fails showing errors > > > like > > > these: […] > > > > I found what looks like the same issue reported in > > <https://github.com/POV-Ray/povray/issues/438>. > > > > As a commenter suggested, I succeeded to build the package using Boost 1.78, > > […] BTW, this is where I think they fixed the Boost issue for 1.78: > > <https://github.com/boostorg/math/pull/676/files> > > So I tried to create a patch (attached) which just drops the fixed version of > `header_deprecated.hpp` from Boost 1.78 [1] in Povray's `source` directory, > since that include path has priority over the profile's Boost one during > build. I tried building with: > > $ guix build povray > --with-patch=povray=./povray-fix-boost-1.77-math-tools-pragma.patch > […] > /gnu/store/mp687jry3rb96ff3jbaijibz4klhjicd-povray-3.7.0.8 > > So it built successfully. > > [1]: > https://github.com/boostorg/math/blob/boost-1.78.0/include/boost/math/tools/header_deprecated.hpp > > Thus, the patch may be applied until Boost is upgraded to 1.78, at which point > it can be removed. > > Thanks! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
