bug#32773: [PATCH] Fix clang libstdc++ header location search
> I'm not sure what the answer is there though, as we still need to patch > in the full path to the headers... maybe a cmake option and associated > macro to be used in that file? They already have a CMake option to select libc++ or libstdc++, so adding another option to specify the path of the selected C++ library would be really nice. Plus it would benefit Nix and other distros where the path of those libraries cannot be guessed. Mathieu
bug#21803: Bug #21803 Hunting: status?
Hi Ludo, Thank you for the explanations. On Thu, 14 Nov 2019 at 22:09, Ludovic Courtès wrote: > I would probably do “guix build guitarix” (get the substitute) and then > “guix build guitarix --check --no-grafts -K”, possibly several times*, > which builds guitarix alone from source. I confirm what you reported: --8<---cut here---start->8--- $ LC_ALL=C diff -r --no-dereference /gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1 /gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1-check File /gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1/lib/libgxw.so is a symbolic link while file /gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1-check/lib/libgxw.so is a regular file --8<---cut here---end--->8--- As you said, it needs more investigation... :-) > Perhaps there are genuine issues described in the rest of your message > but we’d need to isolate them first. :-) Yes, first things first. :-) And I will open discussion elsewhere because it is not related to this bug. Thanks, simon
bug#37850: Glib documentation is missing
On Fri, Nov 15, 2019 at 12:17:30PM +0100, Pierre Neidhardt wrote: > You are right, something is wrong with substitute-keyword-arguments. > No, I did not say that, I said that despite substitute-keyword-arguments returning the correct arguments – as is visible by enclosing the args with a call to (error …) –, meson builds with the old arguments. However now you say it works when copying the arguments from Glib, which is strange. Regards, Florian
bug#37850: Glib documentation is missing
Pierre Neidhardt writes: > You are right, something is wrong with substitute-keyword-arguments. The problem is that GLib has no configure-flags from before. I'm not sure why we get no error from substitute-keyword-arguments (is it swallowed? never run?), but if you change this part: (substitute-keyword-arguments (package-arguments glib) ((#:configure-flags flags) `(cons "-Dgtk_doc=true" ,flags))) ...to read like this: (substitute-keyword-arguments (package-arguments glib) ((#:configure-flags flags ''()) `(cons "-Dgtk_doc=true" ,flags))) Then it should work. The difference is that "flags" gets initialized as the empty list when not already set. signature.asc Description: PGP signature
bug#37850: Glib documentation is missing
Oh, that makes total sense, thanks for the explanation Marius!
Alright, final patch attached.
Let me know if I should merge on master.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
>From 29d27b64fb7bbf96a2ed59a3e1c4179717770f5c Mon Sep 17 00:00:00 2001
From: Pierre Neidhardt
Date: Mon, 11 Nov 2019 15:38:11 +0100
Subject: [PATCH] gnu: Add glib-with-documentation.
* gnu/packages/glib.scm (glib-with-documentation): New variable.
(glib): Hide package.
---
gnu/packages/glib.scm | 40
1 file changed, 40 insertions(+)
diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index b3e85f8df9..47e4f7006a 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -339,6 +339,7 @@ shared NFS home directories.")
(variable "GIO_EXTRA_MODULES")
(files '("lib/gio/modules")
(search-paths native-search-paths)
+ (properties '((hidden? . #t)) )
(synopsis "Thread-safe general utility library; basis of GTK+ and GNOME")
(description
@@ -348,6 +349,45 @@ dynamic loading, and an object system.")
(home-page "https://developer.gnome.org/glib/";)
(license license:lgpl2.1+)))
+(define-public glib-with-documentation
+ ;; glib's doc must be built in a separate package since it requires gtk-doc,
+ ;; which in turn depends on glib.
+ (package
+(inherit glib)
+(properties '((hidden? . #f)))
+(outputs (cons "doc" (package-outputs glib))) ; 20 MiB of GTK-Doc reference
+(native-inputs
+ `(("gtk-doc" ,gtk-doc) ; for the doc
+ ("docbook-xml" ,docbook-xml)
+ ,@(package-native-inputs glib)))
+(arguments
+ (substitute-keyword-arguments (package-arguments glib)
+ ((#:configure-flags flags ''())
+`(cons "-Dgtk_doc=true" ,flags))
+ ((#:phases phases)
+`(modify-phases ,phases
+ (add-after 'unpack 'make-local-docbook-xml
+ (lambda* (#:key inputs #:allow-other-keys)
+ (let ((replace-http
+ (lambda (file)
+(substitute* file
+ ;; Warning: gio.xml uses docbook 4.2, hence the "4.." pattern.
+ (("http://www.oasis-open.org/docbook/xml/4../docbookx.dtd";)
+ (string-append (assoc-ref inputs "docbook-xml")
+ "/xml/dtd/docbook/docbookx.dtd"))
+ (replace-http "gio/gdbus-2.0/codegen/codegen_docbook.py")
+ (for-each replace-http (find-files "." "\\.xml$"))
+ #t)))
+ (add-after 'install 'move-doc
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out"))
+ (doc (assoc-ref outputs "doc"))
+ (html (string-append "/share/gtk-doc")))
+ (copy-recursively (string-append out html)
+ (string-append doc html))
+ (delete-file-recursively (string-append out html))
+ #t)
+
(define gobject-introspection
(package
(name "gobject-introspection")
--
2.23.0
bug#21803: other waf non reproducible: mpv and ardour
Hi, I do not know if it is related but these 2 packages using the waf build system are not reproducible too. - mpv - ardour --8<---cut here---start->8--- $ diff -r --no-dereference /gnu/store/gb935w89qyyi4ljyaz40brai2z9wg0fr-mpv-0.30.0 /gnu/store/gb935w89qyyi4ljyaz40brai2z9wg0fr-mpv-0.30.0-check Binary files /gnu/store/gb935w89qyyi4ljyaz40brai2z9wg0fr-mpv-0.30.0/bin/mpv and /gnu/store/gb935w89qyyi4ljyaz40brai2z9wg0fr-mpv-0.30.0-check/bin/mpv differ Binary files /gnu/store/gb935w89qyyi4ljyaz40brai2z9wg0fr-mpv-0.30.0/lib/libmpv.so.1.106.0 and /gnu/store/gb935w89qyyi4ljyaz40brai2z9wg0fr-mpv-0.30.0-check/lib/libmpv.so.1.106.0 differ --8<---cut here---end--->8--- --8<---cut here---start->8--- $ diff -r --no-dereference /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12 /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12-check Binary files /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12/lib/ardour5/ardour-5.12.0 and /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12-check/lib/ardour5/ardour-5.12.0 differ Binary files /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12/lib/ardour5/engines/libclearlooks.so and /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12-check/lib/ardour5/engines/libclearlooks.so differ Binary files /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12/lib/ardour5/libardour.so.3.0.0 and /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12-check/lib/ardour5/libardour.so.3.0.0 differ Binary files /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12/lib/ardour5/libevoral.so.0.0.0 and /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12-check/lib/ardour5/libevoral.so.0.0.0 differ Binary files /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12/lib/ardour5/LV2/a-comp.lv2/a-comp.so and /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12-check/lib/ardour5/LV2/a-comp.lv2/a-comp.so differ Binary files /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12/lib/ardour5/LV2/a-eq.lv2/a-eq.so and /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12-check/lib/ardour5/LV2/a-eq.lv2/a-eq.so differ Binary files /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12/lib/ardour5/LV2/a-fluidsynth.lv2/a-fluidsynth.so and /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12-check/lib/ardour5/LV2/a-fluidsynth.lv2/a-fluidsynth.so differ Binary files /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12/lib/ardour5/LV2/reasonablesynth.lv2/reasonablesynth.so and /gnu/store/7l5isavp1db8q5mv3zq7bmk29l6ld9qp-ardour-5.12-check/lib/ardour5/LV2/reasonablesynth.lv2/reasonablesynth.so differ --8<---cut here---end--->8--- All the best, simon
bug#38163: GDK does not return the monitor's refresh rate
Alexandros Theodotou writes: > Hi Ludo, > >> We won’t make this change in ‘master’ because it entails too many >> rebuilds, but it could go on the next branch for massive rebuilds. > > Makes sense. I will be using my local gtk+ version for a while then > until this change goes live. Note that this change is already in the staging branch since commit 52b61e999101724c7e2d341586e9a6150614f208. Unfortunately the branch has gone stale due to some Qt/qmake plugin issues & I haven't had time to work on it. I will try to find a workaround this weekend, if nothing else, as only a handful packages are affected. signature.asc Description: PGP signature
bug#21803: guitarix non-reproducible hard to reproduce
Dear,
Resume:
The command "guix build guitarix" downloads from ci.guix.gnu.org.
Then "guix build guitarix --no-grafts -K --check" rebuilds locally.
The two differ of one symlink.
--8<---cut here---start->8---
diff -r --no-dereference
/gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1
/gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1-check
File /gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1/lib/libgxw.so
is a symbolic link while file
/gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1-check/lib/libgxw.so
is a regular file
--8<---cut here---end--->8---
Inspect:
After more than 10 attempts to reproduce the behaviour where the plain
binary is replaced by the symlink, it never happens locally, so I
conclude that the bug is really hard to track. Kind of bad luck. :-)
My intuition is: the non-determinism comes from the WAF configuration
files (./waf or wscript or wafadmin/).
The process conditionally enters in functions such as "do_install" or
"symlink_as", so maybe something is hidden by Python module "os" or
similar. Moreover, note that wscript:l.990 "add_group()" is used after
"add_subdirs('libgxw/gxw')".
Basically, the output of "--check" is:
--8<---cut here---start->8---
[...]
* installing build/default/libgxw/gxw/libgxw.so as
/gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1/lib/libgxw.so.0.1
* symlink
/gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1/lib/libgxw.so.0
(-> libgxw.so.0.1)
* symlink
/gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1/lib/libgxw.so
(-> libgxw.so.0.1)
* installing build/default/libgxw/gxw/libgxw.so as
/gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1/lib/libgxw.so
* installing build/default/libgxwmm/gxwmm/libgxwmm.so as
/gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1/lib/libgxwmm.so.0.1
[...]
--8<---cut here---end--->8---
Here the step (3rd *) "symlink
/gnu/store/...-guitarix-0.38.1/lib/libgxw.so (-> libgxw.so.0.1)" is
overridden by the next one "installing
build/default/libgxw/gxw/libgxw.so as
/gnu/store/...-guitarix-0.38.1/lib/libgxw.so".
Replaying with "guix environment guitarix" then from
"/tmp/guix-build-guitarix-0.38.1.drv-0", the classical "./waf
configure --prefix=install" and "./waf build" "./waf install". In this
case, one symlink is not done and the other one is overriden by the
next step.
--8<---cut here---start->8---
[...]
* installing build/default/libgxw/gxw/libgxw.so as
/tmp/guix-build-guitarix-0.38.1.drv-0/guitarix-0.38.1/install/lib/libgxw.so.0.1
* symlink
/tmp/guix-build-guitarix-0.38.1.drv-0/guitarix-0.38.1/install/lib/libgxw.so
(-> libgxw.so.0.1)
* installing build/default/libgxw/gxw/libgxw.so as
/tmp/guix-build-guitarix-0.38.1.drv-0/guitarix-0.38.1/install/lib/libgxw.so
* installing build/default/libgxwmm/gxwmm/libgxwmm.so as
/tmp/guix-build-guitarix-0.38.1.drv-0/guitarix-0.38.1/install/lib/libgxwmm.so.0.1
[...]
--8<---cut here---end--->8---
Interestingly, the 3 last-last evaluations by Cuirass is of the kind "--check".
https://ci.guix.gnu.org/build/1818089/details
https://ci.guix.gnu.org/build/1871705/details
https://ci.guix.gnu.org/build/1903552/details
Therefore, if we were comparing on November 3rd, we would conclude
differently. ;-)
However, the last evaluation is creating the symlink without overriding it.
https://ci.guix.gnu.org/build/1920646/details
--8<---cut here---start->8---
[...]
* installing build/default/libgxw/gxw/libgxw.so as
/gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1/lib/libgxw.so.0.1
* symlink
/gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1/lib/libgxw.so.0
(-> libgxw.so.0.1)
* symlink
/gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1/lib/libgxw.so
(-> libgxw.so.0.1)
* installing build/default/libgxwmm/gxwmm/libgxwmm.so as
/gnu/store/16g7l26rpwhza7fm5jm3lz1ycavky9yl-guitarix-0.38.1/lib/libgxwmm.so.0.1
[...]
--8<---cut here---end--->8---
Well, even this bug is annoying speaking about reproducibility --
because it it not the *exact* same installation -- it is mitigated by
the fact that the same binary is symlinked or not. I will revisit this
bug when WAF will fully use Python 3.
All the best,
simon
bug#37939: guix-install.sh: Fails to detect signing key on Debian10.
On Sun, 27 Oct 2019 05:15:17 -0700 Bengt Richter wrote: > Hi again Kai, > > On +2019-10-27 09:59:39 +0100, Kai Mertens wrote: > > Dear GNU Guix developers, > > > > [...] > > > > man sudo ;-) Oops. > > specifically the -i option > > I think if you are a "sudoer" plain sudo switches you to root, > but keeps the environment you were in, with PATH etc, > but sudo -i will set the environment as if you logged in as root. > > try "sudo set" and compare with "sudo -i set" > (or env in place of set) Well, I tried "sudo --preserve-env ./guix-install.sh" on debian10, that seems to work fine and the key in the sudoer’s keyring is detected. On trisquel, I am used to use plain sudo instead. Anyway – it is of course not a bug of the guix script. Maybe a usage hint within the guix documentation in section 2.1 would be nice? Thanks for your help, best regards Kai -- Kai Mertens OpenPGP Key-ID: 0x40B15AB4B05B5BF1 on keys.gnupg.net Key fingerprint = 7C83 0A80 01FF 679C 6E8E AFD3 40B1 5AB4 B05B 5BF1 What is that? Please check: https://emailselfdefense.fsf.org/en/ pgpwbpVpnol34.pgp Description: OpenPGP digital signature
bug#38226: guix pull: error: build failed: [...] ice-9/boot-9.scm:109:20: Syntax error:
Dear Guix Developers, unfortunately, I do not manage to update my outdated GNU Guix version via “sudo -i guix pull -c0”. The command fails with the listed message after being executed for about 16hours. I tried it three times, on different days. The most recent one was yesterday. In difference to a recently posted failure, this time... * my /tmp partition has enough space available (>12GB) * and guix is substituting from https://ci.guix.gnu.org I would very much apreciate if you find the time to investigate this bug. I hope it is one, as I don't want to spoil the mailing list with just personal obstacles in respect to guix usage. What kind of information shall I provide, else? The command “sudo -i guix --version” gives me: guix (GNU Guix) 20170703.13 I would have tried to update guix in smaller steps, but option “pull --commit” is not available. ~~~ [...] grafting '/gnu/store/nk1w9h9998w5vyj6zw3h37idmm8c7xsd-guile-2.0.14-debug' -> '/gnu/store/1xbphq9bpylnv46y1dmax5866nbvxyjm-guile-2.0.14-debug'... grafting '/gnu/store/brn8kcdv4xyjn445540zmpvawyzb4c38-guile-2.0.14' -> '/gnu/store/prq1xm7fp9dzp7whw8742djw4vsrsd4f-guile-2.0.14'... ice-9/boot-9.scm:109:20: In procedure #: ice-9/boot-9.scm:109:20: Syntax error: unknown location: unexpected syntax in form current-imported-modules builder for `/gnu/store/qrsd2qvaj52fqsywdwlcrh6366gasiff-module-import-compiled.drv' failed with exit code 1 cannot build derivation `/gnu/store/agyip2r3ars2yxjxnm3s3jlh4q5fjcpk-compute-guix-derivation.drv': 1 dependencies couldn't be built guix pull: error: build failed: build of `/gnu/store/agyip2r3ars2yxjxnm3s3jlh4q5fjcpk-compute-guix-derivation.drv' failed ~~~ best regards Kai -- Kai Mertens OpenPGP Key-ID: 0x40B15AB4B05B5BF1 on keys.gnupg.net Key fingerprint = 7C83 0A80 01FF 679C 6E8E AFD3 40B1 5AB4 B05B 5BF1 What is that? Please check: https://emailselfdefense.fsf.org/en/ pgpCBs0pBT_V5.pgp Description: OpenPGP digital signature
bug#37865: guix pull: error: You found a bug:
On Sun, 27 Oct 2019 04:52:14 -0700 Bengt Richter wrote: > My bet is you'll revert your workarounds, do a guix pull and maybe guix > update for good measure, > then guix install glibc-utf8-locales (unless you have an exotic locale, in > which case you may need > to do guix install glibc-locales) then reboot, and hopefully the locale > complaints will be gone. Hi Bengt, hmm, yes, this is exactly what I did. I reverted my workarounds, but found some constraints that I was not aware of, see list below. (This applies to guix describe (GNU Guix) 7696af421b9fa05f479cda9c742883a99e6faec3 on top of trisquel or debian.) 1) File ~/.profile is not read by bash in case file ~/.bash_profile is present. As a result, some settings were skipped when I used the latter file to define environment variables. Now I set GUIX_PROFILE and source $GUIX_PROFILE/etc/profile (as suggested by guix) within ~/.profile. This works fine. 2) Additionally, I have to explicitly define more standard content for XDG_DATA_DIRS (as like “/usr/share” and “/usr/local/share”) when sourcing the guix profile environment as with 1). This is essential, otherwise my graphic login won't work. I don't understand why, though. 3) In order to get rid of "guile: warning: failed to set locale" with commands like “guix package -I”, I install matching versions of glibc-locales (or glibc-utf8-locales) *and* glibc. Having only the locales package installed is not sufficient. This might be obvious for experienced users, but I myself was not aware of that ANDed condition. 4) Furthermore, with an old initial version of guix, PATH needs to point to “$HOME/.config/guix/current/bin” to make sure that I am running the latest version of guix. Otherwise the locale complains will be back. This concept of environment variables confused me in the beginning, but now I start to get more familiar. best regards Kai -- Kai Mertens OpenPGP Key-ID: 0x40B15AB4B05B5BF1 on keys.gnupg.net Key fingerprint = 7C83 0A80 01FF 679C 6E8E AFD3 40B1 5AB4 B05B 5BF1 What is that? Please check: https://emailselfdefense.fsf.org/en/ pgpFO_zITpIxQ.pgp Description: OpenPGP digital signature
