bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

> It kept spitting the error during the check phase, but I was
> time-machined some months into the past. Maybe with current Guix version
> the issue does not occur. I will check it out this or the next week.

Sure, check it out and let me know.

> Thank you for your work on this issue.

My pleasure! :-)


signature.asc
Description: PGP signature

bug#37867: bug on x86_64-linux AMD box

[Maxim Cournoyer]

Hello Leo,

Leo Barge  writes:

[...]

> Full log written to
> /tmp/guix-build-glib-2.60.6.drv-0/build/meson-logs/testlog.txt
> @ build-log 3297 65
> command "meson" "test" "--no-suite" "flaky" failed with status 1
> builder for
> `/gnu/store/r1vq08xbknz6710yxwzgf0qvca6vyqwg-glib-2.60.6.drv' failed 
> with exit code 1

The CI reports some failures for the current glib version on master
2.62.6 but only for the ARM architecture [0].

Since you've mentioned you are also having freezes, it could well be a
hardware issue.  I've had lots of such problem with the first Ryzen
generation processors, where some power saving features had to be
disabled to get them into stable operation.

As there's nothing actionable for us to do here, I'll close the issue.

Thank you for the report!

Maxim

[0]  http://ci.guix.gnu.org/search?query=glib-2.62.6+status%3Afailed

bug#37969: guix is telling me to report this

[Maxim Cournoyer]

Hello Josh,

Josh Marshall  writes:

[...]
> command "sh" "check.sh" failed with status 1
> builder for 
> `/gnu/store/nvhjn6b5hi4mj7wnjxrmj0dmdigq9m2z-tcc-boot0-0.9.26-6.c004e9a.drv' 
> failed with exit code 1
> @ build-failed 
> /gnu/store/nvhjn6b5hi4mj7wnjxrmj0dmdigq9m2z-tcc-boot0-0.9.26-6.c004e9a.drv - 
> 1 builder for 
> `/gnu/store/nvhjn6b5hi4mj7wnjxrmj0dmdigq9m2z-tcc-boot0-0.9.26-6.c004e9a.drv' 
> failed with exit code 1
[...]

It seems you had a problem building tcc-boot0, which is a component of
the Guix boostrap.

The boostrap binaries have evolved quite a bit since, and I can't
reproduce the issue on current master after having built tc-boot0 5
times with:

--8<---cut here---start->8---
./pre-inst-env guix build -e '(@@ (gnu packages commencement) tcc-boot0)' 
--check --rounds=5
--8<---cut here---end--->8---

Closing.

Thank you for the report!

Maxim

bug#38277: biber 2.12 fails to build

[Maxim Cournoyer]

Hello,

Konrad Hinsen  writes:

> Hi Guix,
>
> There is a build failure with biber 2.12 in current Guix
> (commit 7b40d59114e1462d6d8140f325a66b12e91db667). The build
> log is attached, it shows that several tests fail.
>
> Note that I tried to update to biber 2.13, which builds without
> problems, but I then discovered that it is not compatible with the
> texlive version we currently have.
>
> Cheers,
>   Konrad.

This is no longer an issue on current master.

Closing.

Thanks for the report!

Maxim

bug#38357: Status: babl-0.1.72 build failure (test failure) - dependency for gimp

[Maxim Cournoyer]

Hello,

We're now at babl 0.1.78 and this is no longer an issue.  It was
resolved upstream [0].

Closing.

Thanks,
Maxim

[0]  https://gitlab.gnome.org/GNOME/babl/-/issues/49

bug#38434: QEMU 4.1.1 build is not reproducible

[Maxim Cournoyer]

Hello!

Ludovic Courtès  writes:

> QEMU 4.1.1 does not build reproducibly.  From ‘guix challenge’:
>
> /gnu/store/i347iqh8a5x7h1lgs6wlvk5jk5cwilgi-qemu-4.1.1 contents differ:
>   no local build for '/gnu/store/i347iqh8a5x7h1lgs6wlvk5jk5cwilgi-qemu-4.1.1'
>   
> https://bayfront.guixsd.org/nar/gzip/i347iqh8a5x7h1lgs6wlvk5jk5cwilgi-qemu-4.1.1:
>  09np35221bfpf4spqvnxh6wzb15s1l8vz2vn72kyc41qf02bgq69
>   
> https://ci.guix.gnu.org/nar/gzip/i347iqh8a5x7h1lgs6wlvk5jk5cwilgi-qemu-4.1.1: 
> 0hp5qc6phcrdncs31brcq5wban25fif4y1kihlsc75zzj2cbakx7

Good news!  I cannot reproduce this with QEMU 5.1.0, on linux-x86_64 and
Guix e17b732.

--8<---cut here---start->8---
$ guix challenge qemu
updating substitutes from 'https://ci.guix.gnu.org'... 100.0%

1 store items were analyzed:
  - 1 (100.0%) were identical
  - 0 (0.0%) differed
  - 0 (0.0%) were inconclusive
--8<---cut here---end--->8---

Closing.

Thanks,

Maxim

bug#39670: Cannot mount NFS share as user or root

[Maxim Cournoyer]

Hello Nathan,

Nathan Dehnel  writes:

> You should also setuid mount.nfs4 because the mount command calls that if
> you are using NFSv4.

[...]

I don't think that's necessary, if your program simply calls to the
'mount' command:

sudo strace -f -s200 mount localhost:/pub /tmp/pub

--8<---cut here---start->8---
[...]
[pid 19019] execve("/run/current-system/profile/sbin/mount.nfs", 
["/run/current-system/profile/sbin/mount.nfs", "localhost:/pub", "/tmp/pub", 
"-o", "rw"], 0x7fff431b5038 /* 21 vars */) = 0
[...]
--8<---cut here---end--->8---

You see that mount ends up calling the mount.nfs binary, not mount.nfs4
(even though 'mount' reports this is using NFS v4.2).

If you have some software using mount.nfs4, that could be patched to
mount.nfs, as mount.nfs4 is just a symlink to mount.nfs.

Thanks,

Maxim

bug#43893: [PATCH] maint: update-guix-package: Ensure sources are clean.

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> Ludovic Courtès  writes:
>>
>> [...]
>>
 * build-aux/update-guix-package.scm (git-add-worktree): New procedure.
 (main): Use it to checkout a clean copy of the used commit, and compute the
 hash from it.  Print a user warning after completion.
>>>
>>> I’m not quite enthusiastic about the tool creating a worktree behind my
>>> back.
>>
>> May I ask why?  It's not something you'd (need to) be aware of (it
>> doesn't leave traces in my v2 as 'git worktree prune' clears up the
>> temporary worktree entries), and it's quite cheap to create.
>
> To me, this is all my workspace, and I generally assume I’m the only one
> touching it; it’s more about the mental model, I guess.

I see. I understand your position, but also feel it's not a big deal
here, given you wouldn't be able to notice a new worktree unless you
watch the output of 'git worktree list' in a loop while updating the
guix package ;-).

I think the change brings good guarantees to guard against breaking
'guix pull' with a 'make update-guix-package' as it is, and also
documents the thing.  If it's OK with you I'd like to merge it in the
coming days.

Thanks,

Maxim

bug#41409: “guix pull” should show a progress bar for channel updates

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Ludovic Courtès  skribis:
>
>> Ricardo Wurmus  skribis:
>>
>>> When I run “guix pull” (or “guix time-machine”) I see this message
>>>
>>>Updating channel 'guix' from Git repository at 
>>> 'https://git.savannah.gnu.org/git/guix.git'...
>>>
>>> followed by disconcerting silence.  I can’t tell if it’s doing
>>> something, nor can I see what the progress is.
>>
>> For the record, the main missing piece is in Guile-Git, which does not
>> yet provide bindings to the progress-report thingie for fetch
>> operations.
>
> I’ve added support for the ‘transfer-progress’ callback in Guile-Git:
>
>   
> https://gitlab.com/guile-git/guile-git/-/commit/7a3d97a72e7907213241f62d3bac926361f50f95

And now the Guix side of it:

  https://issues.guix.gnu.org/43968

> However, there’s an (unrelated) issue with libgit2 meaning that
> Guile-Git is not in a releasable state yet:
>
>   https://github.com/libgit2/libgit2/issues/5650

It’s a libgit2 bug but not a showstopper after all.

Ludo’.

bug#39819: Declarative /etc/guix/acl?

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello,

> Jan Nieuwenhuizen  skribis:
>
>> Ludovic Courtès writes:
>
>> However, if you have your own substitute server, you now can run guix
>> archive --authorize < ..., e.g. at bootstrap/install time.  For such
>> cases, IWBN to have a --authorized-key argument to guix build / guix
>> system.
>
> There’s already an ‘authorized-keys’ field in ‘guix-configuration’:
>
>   
> https://guix.gnu.org/manual/devel/en/html_node/Base-Services.html#index-guix_002dconfiguration
>
> So you would just list keys there.  Is that what you have in mind?
>
> The option is already there, it’s just non-authoritative.

I was thinking about the initial installer scenario; when guix-daemon is
already running and you didn't build the guix system yourself.  But
yeah, I guess this is an exceptional or corner case and you can always
build your own installer and add the key there.

Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#43950: lz4 CC=gcc - Why?

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Danny,

Danny Milosavljevic 写道：
It's a dependency of genimage (via squashfs-tools).  Breaking it 
breaks

guix system image generation.

It's a dependency of u-boot.  Breaking it breaks booting on all 
ARM

machines.


Thanks.  Yes, unfortunately it's a dependency of a lot, making it 
a staging package.


I didn't rebuild all dependents before pushing but I did build 
several packages including u-boot-pine64-lts (on x86_64) as a 
smoke test.  I also verified that lz4 with 
--target=aarch64-linux-gnu actually builds for aarch64 now.  I 
think it's safe.


If anything were to break I'd say it must have been broken before, 
but do let me know if it happens.


Ludo said to send extra mails for each--so that's what I am 
doing.


Each package using CC=gcc?  There are currently hundreds; I don't 
think that's what Ludo' meant.  Do hope to have it down to tens 
soon...


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#43960:

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Дмитрий Поляков 写道：

When I type with sudo:
lil@guix ~
$ sudo guix pull


Never run ‘guix pull’ with sudo!

Why is explained in the manual (3.7 After System Installation). 
While guix could detect and warn about it (and I'm sure that's 
already been proposed) you should always read the manual before 
typing commands.


Please run (and post the output of):

 $ type guix
 $ ls -l ~/.config/guix/current
 $ sudo rm ~/.config/guix/current
 $ /run/current-system/profile/bin/guix pull
 $ hash guix
 $ type guix

This should print

 guix is /home/nckx/.config/guix/current/bin/guix

If so, the following command will reconfigure your system using 
your guix, not root's guix:


 $ sudo guix system reconfigure /etc/config.scm

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#43960:

[Дмитрий Поляков]

When I type with sudo:
https://paste.debian.net/1166846

Output from guix system reconfigure /etc/config.scm
https://paste.debian.net/1166847

my env
https://paste.debian.net/1166848

my bashrc
https://github.com/Lenin1917/dotfiles/blob/master/shell/dot-bashrc

bug#43486: guix pull raised a bug in 679d5e6b3d

[Nala Ginrut]

Leo Famulari writes:

> If that's the case, it would be useful to know how much RAM was
> available to the system.

This bug has gone from my system, I've run `guix pull` each day since
then, they're all ok. But I'd like to answer your question: 16G RAM + 18G swap.

Best regargs.


--
GNU Powered it
GPL Protected it
GOD Blessed it
HFG - NalaGinrut
Fingerprint F53B 4C56 95B5 E4D5 6093 4324 8469 6772 846A 0058


signature.asc
Description: PGP signature

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Wiktor Żelazny]

On Mon, Oct 12, 2020 at 03:52:30PM +0530, Arun Isaac wrote:

> I pushed to master, my commit replacing proj.4 with proj.

Hi Arun,

Believe it or not, but on Friday I tried the same thing. First,
replacing proj with proj.4 in GDAL, which declined to compile, demanding
version 6, then replacing proj.4 with proj in r-rgdal.

It kept spitting the error during the check phase, but I was
time-machined some months into the past. Maybe with current Guix version
the issue does not occur. I will check it out this or the next week.

Thank you for your work on this issue.

WŻ


signature.asc
Description: PGP signature

bug#43960: incompatible bytecode version

[zimoun]

Dear,

Could you please provide more information on what you did?  Or how can
I reproduce your report?

Thank you in advance.

All the best,
simon

bug#43960: incompatible bytecode version

[Дмитрий Поляков]

;;; In procedure load-thunk-from-memory: incompatible bytecode version

;;; WARNING: loading compiled file
/run/current-system/profile/lib/guile/3.0/site-ccache/gnu/packages/mtools.go
failed:

;;; In procedure load-thunk-from-memory: incompatible bytecode version

;;; WARNING: loading compiled file
/gnu/store/kn4sqrhnbklqii9ac0xbljkhwg3p2g1m-guix-module-union/lib/guile/3.0/site-ccache/guix.go
failed:

;;; In procedure load-thunk-from-memory: incompatible bytecode version

;;; WARNING: loading compiled file
/run/current-system/profile/lib/guile/3.0/site-ccache/guix.go failed:

;;; In procedure load-thunk-from-memory: incompatible bytecode version

;;; WARNING: loading compiled file
/gnu/store/kn4sqrhnbklqii9ac0xbljkhwg3p2g1m-guix-module-union/lib/guile/3.0/site-ccache/guix/monad-repl.go
failed:

;;; In procedure load-thunk-from-memory: incompatible bytecode version

;;; WARNING: loading compiled file
/run/current-system/profile/lib/guile/3.0/site-ccache/guix/monad-repl.go
failed:

;;; In procedure load-thunk-from-memory: incompatible bytecode version

Backtrace:

  19 (_ # …)

  18 (_ # …)

In ice-9/eval.scm:

   191:27 17 (_ #(#(# #) …))

   196:35 16 (_ #(#(#(# …) #) #))

   298:34 15 (_ #(#(#(#) …) …))

In ice-9/boot-9.scm:

   2806:4 14 (save-module-excursion _)

152:2 13 (with-fluid* _ _ _)

In unknown file:

  12 (primitive-load "/gnu/store/72dq02lisz4w74iphp4a8agjsp0…")

In ice-9/eval.scm:

   626:19 11 (_ #)

   293:34 10 (_ #)

   293:34  9 (_ #(#(#) "gu…" …))

619:8  8 (_ #(#(#(#) …) #))

   626:19  7 (_ #(#(#(#) …) #))

   293:34  6 (_ #(#(#(# …) …) …))

In ice-9/boot-9.scm:

  1731:15  5 (with-exception-handler # …)

In ice-9/eval.scm:

619:8  4 (_ #(#(#(# #)) #))

   626:19  3 (_ #(#(#(# #)) #))

In unknown file:

   2 (load-compiled/vm "/home/lil/.config/guix/current/lib/g…")

In ice-9/boot-9.scm:

  1669:16  1 (raise-exception _ #:continuable? _)

  1669:16  0 (raise-exception _ #:continuable? _)


ice-9/boot-9.scm:1669:16: In procedure raise-exception:

In procedure load-thunk-from-memory: incompatible bytecode version

bug#43963: webssh missing source files

[Jack Hill]

Hi Guix,

Using guix fb0037af8cecc0ebaa330392b0c54a35b7b8a424, webssh source 
contains obfuscated javacript in webssh/static/js, without corresponding 
source files. I would like for these to generated from source javascript 
as part of the build process.


As a bonus they should probably be de-bundled :)

Best,
Jack

bug#43893: [PATCH] maint: update-guix-package: Ensure sources are clean.

[Danny Milosavljevic]

Hi Ludo,

On Mon, 12 Oct 2020 11:40:56 +0200
Ludovic Courtès  wrote:

> Danny Milosavljevic  skribis:
> 
> > Doesn't work for me on x86_64, using a checkout of guix at commit 
> > 93d3cfec32bbbe1dfbe0be686b371973545b35b8.  
> 
> Oh I see, you’re hitting a test failure; I thought you were saying that
> ‘--with-git-url’ didn’t work.

I wasn't saying the latter.  That was Maxim.

It just happened that I also had a similar problem, and provided more detail.
But whether it was the same I don't know (it probably was, though).

(also, it was not possible to distinguish whether the test failure was caused
by "--with-git-url")


pgp0D5qbYeqW1.pgp
Description: OpenPGP digital signature

bug#43950: lz4 CC=gcc - Why?

[Danny Milosavljevic]

Hi,

On Mon, 12 Oct 2020 15:18:26 +0200
Tobias Geerinckx-Rice  wrote:

> For the same reason as the *hundreds* of other ‘CC=gcc’ 
> occurrences in the tree: CC-FOR-TARGET is new.  Out of all of 
> them, why are you so interested in LZ4

It's a dependency of genimage (via squashfs-tools).  Breaking it breaks
guix system image generation.

It's a dependency of u-boot.  Breaking it breaks booting on all ARM
machines.

So I rather didn't want to touch it without confirmation...

> (I think this is your  second mail on it :-)?

Ludo said to send extra mails for each--so that's what I am doing.

> LZ4 tweaked in 2b6ecdf41a09ab9ecae06d7c537583a2f0f28efc,

Thanks!


pgpYQM_qfzvwT.pgp
Description: OpenPGP digital signature

bug#43950: lz4 CC=gcc - Why?

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Danny,

Danny Milosavljevic 写道：

lz4 CC=gcc - Why?


For the same reason as the *hundreds* of other ‘CC=gcc’ 
occurrences in the tree: CC-FOR-TARGET is new.  Out of all of 
them, why are you so interested in LZ4 (I think this is your 
second mail on it :-)?


I'm currently slogging through the "CC=gcc"s & removing as many as 
possible; not fun work but can be done completely off-line.


LZ4 tweaked in 2b6ecdf41a09ab9ecae06d7c537583a2f0f28efc,

T G-R


signature.asc
Description: PGP signature

bug#43940: The "channel-instances->manifest" test fails

[Maxim Cournoyer]

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> The error has to do with channel-instances->manifest now trying to
>> url-fetch something, which pulls in guile-final which fails to be
>> resolved.
>>
>> I've git bisected it and it points to commit
>> 1d4ab335b22a93e01c2eb1eb3e93fc6534157040.
>
> Fixed in 6c46e477eb50c6ee7c9b7c8199bdfb3708dc32b5, thanks for the
> heads-up!
>
> Ludo’.

And thank you for the prompt resolution!  I couldn't figure it out
myself with the time I had :-).

Maxim

bug#39819: Declarative /etc/guix/acl?

[Ludovic Courtès]

Hi,

Jan Nieuwenhuizen  skribis:

> Ludovic Courtès writes:
>
> Hello!
>
>> For some reason, /etc/guix/acl is not declarative on Guix System: we let
>> users modify it and assume it’s stateful, which can surprise users as in
>> .
>>
>> Should we make it declarative, just like most of /etc?  I think so.
>
> Yes, I think so too.

OK.

> However, if you have your own substitute server, you now can run guix
> archive --authorize < ..., e.g. at bootstrap/install time.  For such
> cases, IWBN to have a --authorized-key argument to guix build / guix
> system.

There’s already an ‘authorized-keys’ field in ‘guix-configuration’:

  
https://guix.gnu.org/manual/devel/en/html_node/Base-Services.html#index-guix_002dconfiguration

So you would just list keys there.  Is that what you have in mind?

The option is already there, it’s just non-authoritative.

Ludo’.

bug#43950: lz4 CC=gcc - Why?

[Danny Milosavljevic]

* lz4 has "CC=gcc".  Shouldn't that be (string-append "CC=" (cc-for-target)) ?


pgpssEb5rFja0.pgp
Description: OpenPGP digital signature

bug#43859: Test Suite Failures

[Ludovic Courtès]

Hi,

Raphael Gosselin  skribis:

> Guix: 1.1.0
> Guile: 3.0.4
> Guile-Gcrypt: 0.3.0
> GnuTLS: 3.6.12
> Guile-SQLite3: 0.1.3
> Guile-Git: 0.3.0
> Guile-JSON: 4.3.2
> zlib: 1.2.11
> Make: 4.3
> Guile-SSH: 0.13.1
> libgcrypt: 1.8.5
> sqlite3: 3.31.1
> g++: 9.3.0

Was it on a “foreign distro”?  Are Guile-Gcrypt, Guile-JSON, etc. coming
from packages of the host distro?

Or are you running “make checking” within “guix environment guix”, or
perhaps with the ‘--container’ option?

> location: /home/raph/guix-1.1.0/tests/builders.scm:50
> source:
> + (test-assert
> +   "url-fetch"
> +   (let* ((url '("http://ftp.gnu.org/gnu/hello/hello-2.8.tar.gz;
> + "ftp://ftp.gnu.org/gnu/hello/hello-2.8.tar.gz;))
> +  (hash (nix-base32-string->bytevector
> +  "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"))
> +  (drv (url-fetch*
> + %store
> + url
> + 'sha256
> + hash
> + #:guile
> + %bootstrap-guile))
> +  (out-path (derivation->output-path drv)))
> + (and (build-derivations %store (list drv))
> +  (file-exists? out-path)
> +  (valid-path? %store out-path
> actual-value: #f
> actual-error:
> + (wrong-type-arg
> +   "struct-vtable"
> +   "Wrong type argument in position 1 (expecting struct): ~S"
> +   (#f)
> +   (#f))
> result: FAIL

It looks as if guix-daemon was not running, although “make check”
automatically starts an instance.

> test-name: crate->guix-package
> location: /home/raph/guix-1.1.0/tests/crate.scm:246
> source:
> + (test-assert
> +   "crate->guix-package"
> +   (mock ((guix http-client)
> +  http-fetch
> +  (lambda (url . rest)
> +(match url
> +   ("https://crates.io/api/v1/crates/foo;
> +(open-input-string test-foo-crate))
> +   ("https://crates.io/api/v1/crates/foo/1.0.0/download;
> +(set! test-source-hash
> +  (bytevector->nix-base32-string
> +(sha256
> +  (string->bytevector "empty file\n" "utf-8"
> +(open-input-string "empty file\n"))
> +   ("https://crates.io/api/v1/crates/foo/1.0.0/dependencies;
> +(open-input-string test-foo-dependencies))
> +   (_ (error "Unexpected URL: " url)
> + (match (crate->guix-package "foo")
> +(('package
> +  ('name "rust-foo")
> +  ('version "1.0.0")
> +  ('source
> +   ('origin
> +('method 'url-fetch)
> +('uri ('crate-uri "foo" 'version))
> +('file-name
> + ('string-append 'name "-" 'version ".tar.gz"))
> +('sha256 ('base32 (? string? hash)
> +  ('build-system 'cargo-build-system)
> +  ('arguments
> +   ('quasiquote
> +('#:cargo-inputs
> + (("rust-bar" ('unquote rust-bar))
> +  ('home-page "http://example.com;)
> +  ('synopsis "summary")
> +  ('description "summary")
> +  ('license ('list 'license:expat 'license:asl2.0)))
> + (string=? test-source-hash hash))
> +(x (pk 'fail x #f)
> actual-value: #f
> actual-error:
> + (json-invalid #)
> result: FAIL

Guix 1.1.0 requires Guile-JSON 3.x:

  https://guix.gnu.org/manual/en/html_node/Requirements.html

At the time Guile-JSON 4.x was not released yet, and as it turns out 4.x
introduced incompatible changes.

Could you try again with Guile-JSON 3.x?

> test-name: channel-news, one entry
> location: /home/raph/guix-1.1.0/tests/channels.scm:266
> source:
> + (test-assert
> +   "channel-news, one entry"

[...]

> Initialized empty Git repository in /tmp/guix-directory.mTNwTv/.git/
> [master (root-commit) 24901ba] first commit
>  1 file changed, 1 insertion(+)
>  create mode 100644 .guix-channel
> [master 47ae9bd] second commit
>  1 file changed, 1 insertion(+)
>  create mode 100644 src/a.txt
> [master 17750b4] third commit
>  1 file changed, 1 insertion(+)
>  create mode 100644 news.scm
> [master 938b414] fourth commit
>  1 file changed, 1 insertion(+)
>  create mode 100644 src/b.txt
> [master ad7e153] fifth commit
>  1 file changed, 1 insertion(+), 1 deletion(-)
> actual-value: #f
> result: FAIL

I suspect this is because your ~/.gitconfig is being used, which was
fixed in commit 3c91f003416c9fb79af2dc8766a7f449aa03f839 (see
).

> @ build-started 
> /home/raph/guix-1.1.0/test-tmp/store/z2hbf42p0rilqacllrlwr8n7p6nd8k1k-guile-bootstrap-2.0.drv
>  - x86_64-linux 
> /home/raph/guix-1.1.0/test-tmp/var/log/guix/drvs/z2//hbf42p0rilqacllrlwr8n7p6nd8k1k-guile-bootstrap-2.0.drv.bz2
>  10429
> while setting 

bug#43843: git-annex is not Reproducible

[zimoun]

On Mon, 12 Oct 2020 at 12:34, Ricardo Wurmus  wrote:

> > Does the parallel build save a lot of time and CPU?  If yes, maybe we
> > could to provide a transformation for the expert, something like
> > "haskell-build-system-with-parellel-build" which tweaks
> > "PARALLEL-BUILD?", similarly to the recent "no tests".  WDYT?
>
> We shouldn’t compromise reproducibility for parallel builds.  Ideally we
> would figure out what exactly causes the differences and fix that
> instead of disabling parallel builds, but if that turns out to be too
> difficult I think we should just revert this until we have a good fix.
>
> Perhaps something can be done by fixing the order of files somewhere.

My proposal is for the expert and not at the CLI level.  Something
like "(funky-name ghc-foo)" which returns a new package with
PARALLEL-BUILD? turned to #t.  And the default should be #f.  WDYT?


Well, I am going to try to rebuild the packages with #f and see if it
fixes the ~300 unreproducible packages.


Cheers,
simon

bug#43843: git-annex is not Reproducible

[Ricardo Wurmus]

zimoun  writes:

> On Sat, 10 Oct 2020 at 11:34, Ricardo Wurmus  wrote:
>
>> > --8<---cut here---start->8---
>> > 67cb9fa2357026ee42ec5bb0923ec4dc4a43abe2 is the first bad commit
>> > commit 67cb9fa2357026ee42ec5bb0923ec4dc4a43abe2
>> > Author: Ricardo Wurmus 
>> > Date:   Tue Jun 16 22:25:48 2020 +0200
>> >
>> > build-system/haskell: Support parallel builds.
>> >
>> > * guix/build-system/haskell.scm (haskell-build): Add keyword
>> >   PARALLEL-BUILD?
>> > and pass it on to the builder.
>> > * guix/build/haskell-build-system.scm (build): Accept keyword
>> >   PARALLEL-BUILD?
>> > and pass the number of parallel jobs to GHC.
>> >
>> >  guix/build-system/haskell.scm   | 2 ++
>> >  guix/build/haskell-build-system.scm | 7 +--
>> >  2 files changed, 7 insertions(+), 2 deletions(-)
>> > bisect run success
>> > --8<---cut here---end--->8---
>>
>> Shall we revert it?  Previously the build system also supported parallel
>> builds, but didn’t seem to pass the right arguments to actually make it
>> happen.
>
> What do the Haskellers think about that?

Let me answer as an ex-Haskeller :)

> Does the parallel build save a lot of time and CPU?  If yes, maybe we
> could to provide a transformation for the expert, something like
> "haskell-build-system-with-parellel-build" which tweaks
> "PARALLEL-BUILD?", similarly to the recent "no tests".  WDYT?

We shouldn’t compromise reproducibility for parallel builds.  Ideally we
would figure out what exactly causes the differences and fix that
instead of disabling parallel builds, but if that turns out to be too
difficult I think we should just revert this until we have a good fix.

Perhaps something can be done by fixing the order of files somewhere.

-- 
Ricardo

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

Hi,

I pushed to master, my commit replacing proj.4 with proj. This fixes the
segfault issue. I also updated the package. If the issue with the check
phase still persists, please open a separate issue.

Cheers!

bug#43893: [PATCH] maint: update-guix-package: Ensure sources are clean.

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:
>
> [...]
>
>>> * build-aux/update-guix-package.scm (git-add-worktree): New procedure.
>>> (main): Use it to checkout a clean copy of the used commit, and compute the
>>> hash from it.  Print a user warning after completion.
>>
>> I’m not quite enthusiastic about the tool creating a worktree behind my
>> back.
>
> May I ask why?  It's not something you'd (need to) be aware of (it
> doesn't leave traces in my v2 as 'git worktree prune' clears up the
> temporary worktree entries), and it's quite cheap to create.

To me, this is all my workspace, and I generally assume I’m the only one
touching it; it’s more about the mental model, I guess.

Thanks,
Ludo’.

bug#43893: [PATCH] maint: update-guix-package: Ensure sources are clean.

[Ludovic Courtès]

Danny Milosavljevic  skribis:

> Doesn't work for me on x86_64, using a checkout of guix at commit 
> 93d3cfec32bbbe1dfbe0be686b371973545b35b8.

Oh I see, you’re hitting a test failure; I thought you were saying that
‘--with-git-url’ didn’t work.

Ludo’.

bug#43843: git-annex is not Reproducible

[zimoun]

On Sat, 10 Oct 2020 at 11:34, Ricardo Wurmus  wrote:

> > --8<---cut here---start->8---
> > 67cb9fa2357026ee42ec5bb0923ec4dc4a43abe2 is the first bad commit
> > commit 67cb9fa2357026ee42ec5bb0923ec4dc4a43abe2
> > Author: Ricardo Wurmus 
> > Date:   Tue Jun 16 22:25:48 2020 +0200
> >
> > build-system/haskell: Support parallel builds.
> >
> > * guix/build-system/haskell.scm (haskell-build): Add keyword
> >   PARALLEL-BUILD?
> > and pass it on to the builder.
> > * guix/build/haskell-build-system.scm (build): Accept keyword
> >   PARALLEL-BUILD?
> > and pass the number of parallel jobs to GHC.
> >
> >  guix/build-system/haskell.scm   | 2 ++
> >  guix/build/haskell-build-system.scm | 7 +--
> >  2 files changed, 7 insertions(+), 2 deletions(-)
> > bisect run success
> > --8<---cut here---end--->8---
>
> Shall we revert it?  Previously the build system also supported parallel
> builds, but didn’t seem to pass the right arguments to actually make it
> happen.

What do the Haskellers think about that?
Does the parallel build save a lot of time and CPU?  If yes, maybe we
could to provide a transformation for the expert, something like
"haskell-build-system-with-parellel-build" which tweaks
"PARALLEL-BUILD?", similarly to the recent "no tests".  WDYT?


All the best,
simon

bug#43940: The "channel-instances->manifest" test fails

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> The error has to do with channel-instances->manifest now trying to
> url-fetch something, which pulls in guile-final which fails to be
> resolved.
>
> I've git bisected it and it points to commit
> 1d4ab335b22a93e01c2eb1eb3e93fc6534157040.

Fixed in 6c46e477eb50c6ee7c9b7c8199bdfb3708dc32b5, thanks for the
heads-up!

Ludo’.

bug#31108: Julia: ‘objconv.zip’ modified in place on www.agner.org

[zimoun]

Hi Ludo,

On Thu, 08 Oct 2020 at 09:20, Ludovic Courtès  wrote:
> zimoun  skribis:
>
>> Does it make sense to keep the bug open?  If yes, could you please
>> provide a bit more information about the context?
>
> If the current Julia package doesn’t have a similar problem, I think we
> can close this bug.

Maybe I miss the bug at the time “09 Apr 2018”, where it was an upstream
mismatch.  It seems fixed by these 2 commits:

--8<---cut here---start->8---
commit 2930a39b165ce9e13e899fe66b82c03932e0e86b
Author: Tobias Geerinckx-Rice 
Date:   Wed Oct 31 15:54:38 2018 +0100

gnu: julia: Update objconv input to 2018-10-07.

* gnu/packages/julia.scm (julia)[input]: Update objconf to 2018-10-07.

commit 81bf0fd0d4a7e78febb394576ea849285fc2d329
Author: Marius Bakke 
Date:   Tue Sep 4 18:53:13 2018 +0200

gnu: julia: Update objconv input.

* gnu/packages/julia.scm (julia)[inputs]: Update the hash of "objconv", 
which
does not have a stable URL.  Add a file name and use HTTPS while at it.
--8<---cut here---end--->8---

So closing! :-)


BTW, at the time (2018), the inputs were:

--8<---cut here---start->8---
   ("objconv"
,(origin
   (method url-fetch)
   ;; No versioned URL, see  for 
updates.
   (uri "https://www.agner.org/optimize/objconv.zip;)
   (file-name "objconv-2018-08-15.zip")
   (sha256
(base32
 "09y4pwxfs6fl47cyingbf95i2rxx74wmycl9fd4ldcgvpx9bzdrx"
--8<---cut here---end--->8---

and now, AFAICT, it is not the case.  This ’objconv’ had been removed
from the inputs list.  See commit (with the not so talkative commit
message :-))
5ef30f2a1f89397bc78af94b6ee95e9fce2f646e updating to 1.4.1.

However, on one hand this dependency seems now bundled with Julia.  See
upstream ’deps/objconv.mk’:

--8<---cut here---start->8---
$(SRCCACHE)/objconv.zip: | $(SRCCACHE)
$(JLDOWNLOAD) $@ http://www.agner.org/optimize/objconv.zip
--8<---cut here---end--->8---

On the other hand, maybe ’#:make-flags’ deactivates this; I do not know,
nothing obvious.  Julia needs some love and I will not have enough time
to dedicated to them. :-)


Cheers,
simon

bug#43905: Acknowledgement (cuirass: uncaught exception 'read-error' in 'metrics' fiber)

[Mathieu Othacehe]

Hello Jonathan,

> It happens when scamping around in the database:
> update Specifications set proc_args='((subset "htop" "icedove") (systems
> "x86_64-linux))';

You mean it happens only when modifying 'proc_args' while Cuirass is
running? Could you share your specifications so that I can try to
reproduce it?

Thanks,

Mathieu