Re: gobject-introspection .gir search path
Cyril Roelandt skribis:
> On 05/06/2014 10:07 AM, Ludovic Courtès wrote:
>> Cyril Roelandt skribis:
>>
>>> On 05/06/2014 12:36 AM, Ludovic Courtès wrote:
While trying to package librsvg, I stumbled upon this:
--8<---cut here---start->8---
Couldn't find include 'GdkPixbuf-2.0.gir' (search path: ['.', 'gir-1.0',
'/gnu/store/xdd5ndl01700w23z206nc36nqg96z94v-gobject-introspection-1.38.0/share/gir-1.0',
'/usr/share/gir-1.0',
'/gnu/store/xdd5ndl01700w23z206nc36nqg96z94v-gobject-introspection-1.38.0/share/gir-1.0'])
/gnu/store/xdd5ndl01700w23z206nc36nqg96z94v-gobject-introspection-1.38.0/share/gobject-introspection-1.0/Makefile.introspection:153:
recipe for target 'Rsvg-2.0.gir' failed
make[2]: *** [Rsvg-2.0.gir] Error 1
--8<---cut here---end--->8---
Do you remember if the gobject-introspection “scanner” had a way to
specify a search path, like an env. var.?
Otherwise, how can we make sure that the .girs of inputs are visible?
>>>
>>> Look at the 'gir-directory' function in guix/build/gnome.scm. It's used
>>> in gnu/packages/{gtk,gnome}.scm and does exactly what you need.
>>
>> Oh right, thanks, that does the job.
>>
>> It’d be great to submit a patch upstream so that g-ir-compiler &
>> co. honor a GIR_PATH environment variable or similar. That seems like
>> the right thing to do, and definitely helpful for us.
>>
>
> From 'man g-ir-scanner':
>
> "The g-ir-scanner uses the XDG_DATA_DIRS variable to check for dirs, the
> girs are located in XDG_DATA_DIRS/gir-1.0."
>
> I guess you could also use that; would it solve your problem ? I think
> we might be able to remove the ugly use of '--add-include-path' in
> gnu/packages/{gtk,gnome}.scm if we were to use this variable.
Indeed, adding a search path specification for ‘XDG_DATA_DIRS’ in GLib
solves this problem (I’ll commit shortly.)
Since ‘XDG_DATA_DIRS’ is also used as the search path env. var. for
GLib’s schemas, it seemed best to put it in GLib rather than
gobject-introspection.
Thanks,
Ludo’.
Re: Proposal: prefetch tarballs in a batch
Nikita Karetnikov skribis:
> 1. It doesn’t seem to prefetch all the needed dependencies. ‘guix build
>hello’ (without network access) fails after prefetching the said
>package.
Fails how?
> 2. The substituter fails from time to time. Note that eight tests fail
>on the machine I used: ‘builders.scm’, ‘utils.scm’, ‘packages.scm’,
>‘store.scm’, ‘monads.scm’, ‘gexp.scm’, ‘guix-package.sh’,
>‘guix-register.sh’. Perhaps we ought to fix the mentioned failures
>first. Which log files would you like to see?
The SRFI-64 log files of the failing tests, plus test-suite.log. Test
failures must not remain uncorrected! ;-)
When there are so many failures, it’s likely that there’s a setup issue,
like socket names are too long.
>$ ./pre-inst-env guix prefetch -n icecat
>substitute-binary: guile: hashtab.c:137: vacuum_weak_hash_table: Assertion
> `removed <= len' failed.
What Guile and libgc version is this, and what platform?
>I’ve also seen this one. In case it matters, that was before running
>‘chgrp 1001 /gnu/store; chmod 1775 /gnu/store’.
>
>$ ./pre-inst-env guix prefetch -n gnunet
>Backtrace:
>In ice-9/boot-9.scm:
> 157: 17 [catch #t # ...]
[...]
>In guix/derivations.scm:
> 175: 3 [derivation-prerequisites-to-build # # # ...]
>In guix/store.scm:
> 695: 2 [substitutable-paths # #]
> 392: 1 [process-stderr # #f]
>In guix/serialization.scm:
> 51: 0 [read-int #]
>
>guix/serialization.scm:51:4: In procedure read-int:
>guix/serialization.scm:51:4: In procedure bv-u32-ref: Wrong type argument
> in position 1 (expecting bytevector): #
That seems similar no?
Does the installation seem sane, basically? Do ‘guix build’, ‘guix
package’ etc. work somehow, or not even?
> 3. When using the substituter, the command takes much more time. Do
>we even need it in this case? I seem to recall that the GNUnet
>tarball was served by Hydra, but I forgot the details.
There’s a local cache of substituter hits/failures in
/var/guix/substitute-binary (or similar.) When that cache is empty or
outdated, a lot of HTTP queries are made to hydra.gnu.org, which can
take a bit of time.
When using a recent Guile, these queries are made in parallel. On my
machine, it goes like this:
--8<---cut here---start->8---
$ sudo rm -rf /var/guix/substitute-binary/cache/
$ time guix build emacs -n
real0m30.551s
user0m2.519s
sys 0m0.154s
$ time guix build emacs -n
real0m3.381s
user0m2.039s
sys 0m0.123s
--8<---cut here---end--->8---
The cost is high when starting from an empty cache, but afterwards it’s
small.
> +(define (show-help)
Add call to ‘show-build-options-help’ from (guix scripts build).
> +(define %options
> + ;; Specification of the command-line options.
> + (list (option '("no-substitutes") #f #f
> +(lambda (opt name arg result . rest)
> + (apply values
> + (alist-cons 'substitutes? #f
> + (alist-delete 'substitutes? result))
> + rest)))
Remove this option, and concatenate with ‘%standard-build-options’.
> + (filter-map (match-lambda
> +(('argument . value)
> + (identity ; discard the second value
The extra value gets truncated here, so it’s not strictly needed.
Thanks!
Ludo’.
Re: torify w3m: ERROR: ld.so: object ‘libtorsocks.so’ cannot be preloaded
Mark H Weaver skribis: > FWIW, I've never tried torifying w3m in this way. Instead, I use > privoxy. I configured privoxy to use Tor via SOCKS5, and I set the > http_proxy and https_proxy environment variables so that most web > clients (including w3m and guile 2.0.11) use privoxy. Oh indeed, it actually works fine for HTTPS too. Ludo’.
Re: gobject-introspection .gir search path
On 05/06/2014 10:07 AM, Ludovic Courtès wrote:
> Cyril Roelandt skribis:
>
>> On 05/06/2014 12:36 AM, Ludovic Courtès wrote:
>>> While trying to package librsvg, I stumbled upon this:
>>>
>>> --8<---cut here---start->8---
>>> Couldn't find include 'GdkPixbuf-2.0.gir' (search path: ['.', 'gir-1.0',
>>> '/gnu/store/xdd5ndl01700w23z206nc36nqg96z94v-gobject-introspection-1.38.0/share/gir-1.0',
>>> '/usr/share/gir-1.0',
>>> '/gnu/store/xdd5ndl01700w23z206nc36nqg96z94v-gobject-introspection-1.38.0/share/gir-1.0'])
>>> /gnu/store/xdd5ndl01700w23z206nc36nqg96z94v-gobject-introspection-1.38.0/share/gobject-introspection-1.0/Makefile.introspection:153:
>>> recipe for target 'Rsvg-2.0.gir' failed
>>> make[2]: *** [Rsvg-2.0.gir] Error 1
>>> --8<---cut here---end--->8---
>>>
>>> Do you remember if the gobject-introspection “scanner” had a way to
>>> specify a search path, like an env. var.?
>>>
>>> Otherwise, how can we make sure that the .girs of inputs are visible?
>>>
>>
>> Look at the 'gir-directory' function in guix/build/gnome.scm. It's used
>> in gnu/packages/{gtk,gnome}.scm and does exactly what you need.
>
> Oh right, thanks, that does the job.
>
> It’d be great to submit a patch upstream so that g-ir-compiler &
> co. honor a GIR_PATH environment variable or similar. That seems like
> the right thing to do, and definitely helpful for us.
>
>From 'man g-ir-scanner':
"The g-ir-scanner uses the XDG_DATA_DIRS variable to check for dirs, the
girs are located in XDG_DATA_DIRS/gir-1.0."
I guess you could also use that; would it solve your problem ? I think
we might be able to remove the ugly use of '--add-include-path' in
gnu/packages/{gtk,gnome}.scm if we were to use this variable.
Cyril.
Re: torify w3m: ERROR: ld.so: object ‘libtorsocks.so’ cannot be preloaded
Nikita Karetnikov writes: > ‘torify w3m https://check.torproject.org’ returns the following error > message before showing “Congratulations. This browser is configured to > use Tor.” Is it harmless? > > ERROR: ld.so: object > /gnu/store/2g7lx2qz06vlb241gfr6bpyp6mc5a24z-torsocks-1.2/lib/torsocks/libtorsocks.so' > from LD_PRELOAD cannot be preloaded: ignored. No, this is an important error. I'm reasonably sure it means that w3m is not getting torified at all. One possibility is that torsocks and w3m both link to the same shared library, but they are using different versions of that library. Try rebuilding both w3m and torsocks to make sure they are harmonious. FWIW, I've never tried torifying w3m in this way. Instead, I use privoxy. I configured privoxy to use Tor via SOCKS5, and I set the http_proxy and https_proxy environment variables so that most web clients (including w3m and guile 2.0.11) use privoxy. IIRC, this is recommended over using torify in most cases. Mark
Re: torify w3m: ERROR: ld.so: object ‘libtorsocks.so’ cannot be preloaded
Nikita Karetnikov skribis: > ‘torify w3m https://check.torproject.org’ returns the following error > message before showing “Congratulations. This browser is configured to > use Tor.” Is it harmless? > > ERROR: ld.so: object > '/gnu/store/2g7lx2qz06vlb241gfr6bpyp6mc5a24z-torsocks-1.2/lib/torsocks/libtorsocks.so' > from LD_PRELOAD cannot be preloaded: ignored. It’s a problem, because it means that libtorsocks’ replacements for ‘connect’, ‘sendto’, etc. are not being used. FWIW I use Privoxy instead of torify for web browsing, but that does not support https AFAIK. Ludo’.
torify w3m: ERROR: ld.so: object ‘libtorsocks.so’ cannot be preloaded
‘torify w3m https://check.torproject.org’ returns the following error message before showing “Congratulations. This browser is configured to use Tor.” Is it harmless? ERROR: ld.so: object '/gnu/store/2g7lx2qz06vlb241gfr6bpyp6mc5a24z-torsocks-1.2/lib/torsocks/libtorsocks.so' from LD_PRELOAD cannot be preloaded: ignored. pgpxdE5a2nJEo.pgp Description: PGP signature
Re: Proposal: prefetch tarballs in a batch
I’m attaching the version incorporating your suggestions, which was tested with the empty store. There are a bunch of problems: 1. It doesn’t seem to prefetch all the needed dependencies. ‘guix build hello’ (without network access) fails after prefetching the said package. 2. The substituter fails from time to time. Note that eight tests fail on the machine I used: ‘builders.scm’, ‘utils.scm’, ‘packages.scm’, ‘store.scm’, ‘monads.scm’, ‘gexp.scm’, ‘guix-package.sh’, ‘guix-register.sh’. Perhaps we ought to fix the mentioned failures first. Which log files would you like to see? $ ./pre-inst-env guix prefetch -n icecat substitute-binary: guile: hashtab.c:137: vacuum_weak_hash_table: Assertion `removed <= len' failed. Backtrace: In ice-9/boot-9.scm: 157: 15 [catch #t # ...] In unknown file: ?: 14 [apply-smob/1 #] In ice-9/boot-9.scm: 63: 13 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 432: 12 [eval # #] In ice-9/boot-9.scm: 2320: 11 [save-module-excursion #] 3966: 10 [#] 1645: 9 [%start-stack load-stack ...] 1650: 8 [#] In unknown file: ?: 7 [primitive-load "/home/nikita/guix/guix-savannah/scripts/guix"] In guix/ui.scm: 630: 6 [run-guix-command prefetch "-n" "icecat"] In ice-9/eval.scm: 432: 5 [eval # #] In guix/ui.scm: 265: 4 [show-what-to-build # (# # # ...) ...] In guix/utils.scm: 667: 3 [loop (# # # # ...) () (# # # # ...)] In guix/ui.scm: 267: 2 [# # # ()] In guix/derivations.scm: 175: 1 [derivation-prerequisites-to-build # # # ...] In guix/store.scm: 695: 0 [substitutable-paths # #] guix/store.scm:695:2: In procedure substitutable-paths: guix/store.scm:695:2: Throw to key `srfi-34' with args `(#)'. I’ve also seen this one. In case it matters, that was before running ‘chgrp 1001 /gnu/store; chmod 1775 /gnu/store’. $ ./pre-inst-env guix prefetch -n gnunet Backtrace: In ice-9/boot-9.scm: 157: 17 [catch #t # ...] In unknown file: ?: 16 [apply-smob/1 #] In ice-9/boot-9.scm: 63: 15 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 432: 14 [eval # #] In ice-9/boot-9.scm: 2320: 13 [save-module-excursion #] 3966: 12 [#] 1645: 11 [%start-stack load-stack ...] 1650: 10 [#] In unknown file: ?: 9 [primitive-load "/home/nikita/guix/guix-savannah/scripts/guix"] In guix/ui.scm: 630: 8 [run-guix-command prefetch "-n" "gnunet"] In ice-9/eval.scm: 432: 7 [eval # #] In guix/ui.scm: 265: 6 [show-what-to-build # (# # # ...) ...] In guix/utils.scm: 667: 5 [loop () () ...] In guix/ui.scm: 267: 4 [# # () ()] In guix/derivations.scm: 175: 3 [derivation-prerequisites-to-build # # # ...] In guix/store.scm: 695: 2 [substitutable-paths # #] 392: 1 [process-stderr # #f] In guix/serialization.scm: 51: 0 [read-int #] guix/serialization.scm:51:4: In procedure read-int: guix/serialization.scm:51:4: In procedure bv-u32-ref: Wrong type argument in position 1 (expecting bytevector): # 3. When using the substituter, the command takes much more time. Do we even need it in this case? I seem to recall that the GNUnet tarball was served by Hydra, but I forgot the details. $ time ./pre-inst-env guix prefetch -n icecat The following derivations would be built: […] 101987 operations real 4m7.477s user 0m19.249s sys 0m4.848s $ time ./pre-inst-env guix prefetch -n --no-substitutes icecat The following derivations would be built: […] 101675 operations real 0m22.933s user 0m14.745s sys 0m3.168s diff --git a/guix/scripts/build.scm b/guix/scripts/build.scm index 35b10a0..8937d76 100644 --- a/guix/scripts/build.scm +++ b/guix/scripts/build.scm @@ -37,6 +37,7 @@ #:export (%standard-build-options set-build-options-from-command-line show-build-options-help +specification->package guix-build)) diff --git a/guix/scripts/prefetch.scm b/guix/scripts/prefetch.scm new file mode 100644 index 000..dbcef0f --- /dev/null +++ b/guix/scripts/prefetch.scm @@ -0,0 +1,141 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2014 Nikita Karetnikov +;;; Copyright © 2014 Ludovic Courtès +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not
Re: gobject-introspection .gir search path
Cyril Roelandt skribis:
> On 05/06/2014 12:36 AM, Ludovic Courtès wrote:
>> While trying to package librsvg, I stumbled upon this:
>>
>> --8<---cut here---start->8---
>> Couldn't find include 'GdkPixbuf-2.0.gir' (search path: ['.', 'gir-1.0',
>> '/gnu/store/xdd5ndl01700w23z206nc36nqg96z94v-gobject-introspection-1.38.0/share/gir-1.0',
>> '/usr/share/gir-1.0',
>> '/gnu/store/xdd5ndl01700w23z206nc36nqg96z94v-gobject-introspection-1.38.0/share/gir-1.0'])
>> /gnu/store/xdd5ndl01700w23z206nc36nqg96z94v-gobject-introspection-1.38.0/share/gobject-introspection-1.0/Makefile.introspection:153:
>> recipe for target 'Rsvg-2.0.gir' failed
>> make[2]: *** [Rsvg-2.0.gir] Error 1
>> --8<---cut here---end--->8---
>>
>> Do you remember if the gobject-introspection “scanner” had a way to
>> specify a search path, like an env. var.?
>>
>> Otherwise, how can we make sure that the .girs of inputs are visible?
>>
>
> Look at the 'gir-directory' function in guix/build/gnome.scm. It's used
> in gnu/packages/{gtk,gnome}.scm and does exactly what you need.
Oh right, thanks, that does the job.
It’d be great to submit a patch upstream so that g-ir-compiler &
co. honor a GIR_PATH environment variable or similar. That seems like
the right thing to do, and definitely helpful for us.
Since it’s written in Python, I thought perhaps you could lend a hand?
:-)
Ludo’.
