bug#34061: bug: failed to compute derivation

[zimoun]

Hi,

On Fri, 18 Dec 2020 at 17:46, Benjamin Slade  wrote:
> Yes, I think this can be closed, I haven't experienced it 
> recently.

Thank you for the report and your feedback.

So, closing!  Feel free to reopen if you have again the same issue.


All the best,
simon

bug#33106: "make check-system TESTS=basic" fails on master

[zimoun]

Hi Chris,

This bug#33106 is old with last activity 2+ years ago and tagged
’moreinfo’ also 2+ years ago.  Tobias asked [1] if it is possible to
reproduce now?

1: 

On Sat, 20 Oct 2018 at 12:09, Chris Marusich  wrote:

> The system test "basic" fails on commit
> 7d1f21c69aa89e4c7c57ace26af80d168157b243 (master).  To reproduce, check
> out that commit and run:
>
> make check-system TESTS="basic"
>
> For the record, this is on an x86_64-linux GuixSD system using an ext4
> root file system.  Here's the error (I've sanitized the output, which
> apparently contained some unprintable characters, and removed some lines
> for brevity):

[...]

> 1) Where is the "basic.log" file?  I checked the Guix checkout and the
> retained directory of the failed derivation (i.e., the directory
> produced by guix build --keep-failed /gnu/store/...gjmid5-basic.drv),
> but I don't see it anywhere.
>
> 2) The test seems to have failed becuase of the following issue, which
> is mentioned in the output above:
>
> 0 (mount "/dev/vda1" "/real-root" "ext4" 1 #)
> In procedure mount: No such file or directory
>
> The next steps are probably to look into whether /dev/vda1 or /real-root
> exist when that call is made, and if one of them is missing, investigate
> why it doesn't exist.

If no moreinfo, this bug will be closed in the coming days.

All the best,
simon

PS: Chris, I hope that everything is fine on your side because I have
not read something from you since long time.

bug#31977: clone tests fail on CentOS 7

[zimoun]

Hi Paul,

Since the fix 8bc5ca5160db3d82bd5b6b2b7ed80c96f42bd33e breaks
linux-libre kernel on Guix System, because of [1], quote:

Well, it is expected.  And now all is clear.  Explanations starting
there:

   

Quickly said, the initial code was assuming Debian-like kernel patches
as Vagrant reported and this is not in the linux-libre source code with
a wrong Guix error message.

One bug is still there. :-)

1: 


If I understand well your message:

Files:
a) '/proc/self/ns/user' exists
b) '/proc/sys/kernel/unprivileged_userns_clone' does not exist.

from your initial report, it is the same problem as linux-libre:
somehow, the assumption of '/proc/sys/kernel/unprivileged_userns_clone'
is Debian-like and not shared.

So, it could be nice to have a good story for that. :-)


All the best,
simon

bug#45272: [PATCH v3] gnu: gnome-builder: Disable jedi plugin.

[Leo Prikler]

As pointed out in #45272, it is broken.

* gnu/packages/gnome.scm (gnome-builder)[#:configure-flags] Add
-Dplugin_jedi=false.
---
 gnu/packages/gnome.scm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 5a166d1b86..f90c0b92a6 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -11876,6 +11876,9 @@ libraries.  Applications do not need to be 
recompiled--or even restarted.")
"-Dplugin_clang=false"
"-Dplugin_flatpak=false"
"-Dplugin_glade=false"
+   ;; XXX: This one has been shown not to work in
+   ;;  
+   "-Dplugin_jedi=false"
;; ... except this one.
"-Dplugin_update_manager=false")
#:phases
-- 
2.29.2

bug#25327: cargo build-system should be able to filter out target.cfg(windows) dependencies

[Hartmut Goebel]

Am 18.12.20 um 20:56 schrieb zimoun:

Is it still relevant with the recent additions?


I just checked this with sequoia 0.20.0: The package "winapi" is still 
downloaded and compiled - even if obviously not used sicne on Linux.


--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#45193: Wrapper of Qt programs doesn't extend existing environment variable

[Hartmut Goebel]

Zhu Zihao wrote

When building QT program, Guix builder populates qt related 
environmentvariable, and wrap-qt-program just record it into wrapper.


However, the wrap behaviour in qt-build-system is quite different, 
itsearch all inputs and mark them should be included in envvar 
definitionif correspond directory exists.


This will have the same result in must cases:

The environment variables used in qt-utils are defined as 
"native-search-paths" by some package. So these variables will be set 
when creating the build environment, based in the inputs. So if the 
package does not touch these variables, the output should be the same 
(beside perhaps the order).


When using the environment-variables, this would allow the package 
definition to remove unwanted parts. Nevertheless this is cumbersome 
(fetching the input, string-append, manipulating the variable value). 
And AFAIS none of the pacakges using wrap-qt-program does this.


I agree that leaking the environments variables from the build 
environment to the package is not a good idea. Also we might want to add 
some filters to avoid all imports (including cmake) are going into the 
wrapping variables - which is much easier when dealing with inputs nor 
strings.



Another difference is, wrap-qt-program will include the directory 
ofoutput in envvar but qt-build-system won't do.


If I understand the code correctly,  line 103 of qt-build-system also 
handle the output directories


 (append (list directory)
 input-directories

and the qt-build-system should even handle different outputs (while 
qt-tuils does not):


  (for-each handle-output outputs)

(I may be wrong on this, please double check.

--
Regards
Hartmut Goebel

| Hartmut Goebel  |h.goe...@crazy-compilers.com|
|www.crazy-compilers.com  | compilers which you thought are impossible |

bug#34061: bug: failed to compute derivation

[Benjamin Slade]

Yes, I think this can be closed, I haven't experienced it 
recently.

bug#45193: Wrapper of Qt programs doesn't extend existing environment variable

[Zhu Zihao]

Hartmut Goebel writes:

> I agree that leaking the environments variables from the build environment to
> the package is not a good idea. Also we might want to add some filters to 
> avoid
> all imports (including cmake) are going into the wrapping variables - which is
> much easier when dealing with inputs nor strings.

I just check how Nixpkgs do Qt wrapping, it use same strategy like 
wrap-qt-program.
Since our environment variable only contains the path to inputs, capture
the build-time environment can be forgiven (compare with patch-shebang).

I think the main problem is include unwanted directory accidentally and
increase the closure size. But it looks like an impossible job to do it
automatically. My idea is provide a keyword argument
#:qt-wrap-exclude-inputs to prevent qt-build-system to search unwanted inputs.

BTW, would you like to use prefix wrap for wrap-qt-program in qt-utils.scm?

> If I understand the code correctly,  line 103 of qt-build-system also handle 
> the
> output directories
>
>  (append (list directory)
>  input-directories
>
> and the qt-build-system should even handle different outputs (while qt-tuils
> does not):
>
>   (for-each handle-output outputs)
>
> (I may be wrong on this, please double check.

Yes you're right, output was handled. I misunderstood the code before. 

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#45193: Wrapper of Qt programs doesn't extend existing environment variable

[Hartmut Goebel]

Am 19.12.20 um 19:20 schrieb Zhu Zihao:

BTW, would you like to use prefix wrap for wrap-qt-program in qt-utils.scm?


I would support your proposal of unifying both wrappers. (Which way 
round is a matter of closure-size. I assume moving the code to 
qt-util.scm is the smaller solution.)


--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#45294: guix system reconfigure won't run since commit 6a060ff27ff68384d7c90076baa36c349fff689d

[Leo Famulari]

This bug should have been fixed with commit d88ff09ea3138fc85c1
(services: 'references-file' depends on Guile-Gcrypt.):

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d88ff09ea3138fc85c1463b0b345bd6ba71ca568

Have you upgraded your Guix (by using `guix pull`) to include that
commit?

If you still have the bug after upgrading to include the fix, please
share the output of `guix describe`.

bug#45326: Include curl/wget (and git?) to the installation image

[Pierre Neidhardt]

Apologies if this has been asked before, but would it be possible to
include one of curl or wget in the installation image?

It's particularly convenient to fetch authorization keys, channel specs and
the like before installing a system.

Additionally, including git (maybe git minimal?) would be great so
synchronize Git repositories which may contain installation scripts,
Guix configs and other dotfiles.

Thoughts?

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

bug#45326: Include curl/wget (and git?) to the installation image

[Leo Famulari]

On Sat, Dec 19, 2020 at 09:57:08PM +0100, Pierre Neidhardt wrote:
> Apologies if this has been asked before, but would it be possible to
> include one of curl or wget in the installation image?

`guix download` should work here ;)

But it's nice to have something familiar.

> Additionally, including git (maybe git minimal?) would be great so
> synchronize Git repositories which may contain installation scripts,
> Guix configs and other dotfiles.

This one is more pressing...


signature.asc
Description: PGP signature

bug#45294: [clonex...@protonmail.com: bug#45294: guix system reconfigure won't run since commit 6a060ff27ff68384d7c90076baa36c349fff689d]

[Leo Famulari]

- Forwarded message from Noah Evans  -

Date: Sat, 19 Dec 2020 21:27:12 +
From: Noah Evans 
To: "l...@famulari.name" 
Subject: bug#45294: guix system reconfigure won't run since commit 
6a060ff27ff68384d7c90076baa36c349fff689d

I am still getting this error (with a different module-import-compiled hash: 
42ng84hlckw2w626i86f8kiw3a3qswh0-module-import-compiled.drv). Here is my guix 
describe:

guix 66b5bc3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 66b5bc319177f54a65085fbc39ee984d387a3329

- End forwarded message -

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi all,

It's great to see forward motion again!

Efraim Flashner  writes:

> As far as powerpc64 vs powerpc64le, I'll let those with the hardware
> have more of a say, they'll be the ones using it. As far as the
> bootstrap binaries go, I don't remember having this much pushback with
> my binaries for aarch64 (just a request to rebuild with guile-2.0.14
> since it was reproducible), and I'm not sure how much Janneke had with
> the Hurd binaries but I don't think it was this much. The ultimate goal
> anyway is to replace them with artisanally crafted mes binaries, and I
> understand we want to have them as reproducible as possible, but I don't
> think it's fair to keep this architecture out when we've let other ones
> in with similar reproducible problems.

Ludovic Courtès  writes:

> I didn’t follow the whole discussion nor did I try to investigate
> myself, but thanks a lot for going to great lengths trying to identify
> the issue; this is an impressive amount of work, and I can only share
> your disappointment.
>
> Given this effort, I agree that it may be best at this point to move on
> and start with these non-reproducible binaries.  At least, the problem
> is now documented.

I'm glad you agree.  For powerpc64 (big-endian), should we just make the
changes for bootstrapping on the master branch, or should we use a
separate branch?

If we use a separate branch, we could use the name "wip-ppc64", since
there is already a "wip-ppc64le" for powerpc64le.  Is it expected that
commits on these "wip" branches will never be modified (e.g., via
rebasing)?

Leo Le Bouter  writes:

>> Do you have a preference big-endian vs little endian?
>
> I'd like both but little endian has the widest eco-system support
> especially w.r.t. to Linux drivers. Many Linux drivers have endianness
> bugs (lack of endian-safe serialization for DMA..), it's such a plague
> that sticking to little endian is just better right now. One common
> example being mpt3sas and amdgpu drivers required in some
> configurations of the Talos II system.

Ludovic Courtès  writes:

>> At this point, it might even make more sense to try bootstrapping for
>> powerpc64le instead of powerpc64, since the rest of the world seems to
>> be gravitating toward the little-endian variant on POWER9 hardware, and
>> thus various programs out there are more likely to be better tested on
>> powerpc64le than powerpc64.
>
> Yes, my understanding is that other people, in particular Tobias Platen
> and dftxbs3e, were looking at powerpc64le, so perhaps it’s a good idea
> to concentrate on that one?

I agree.  It's probably better to focus on little-endian.  However, it
isn't clear yet which will be ultimately harder for us to bootstrap, so
I also think it's fine to work on both in parallel and see how it goes.

Ludovic Courtès  writes:

> Anyhow, please let me know if/when bootstrap binaries should be uploaded
> to ftp.gnu.org (with a signed message).  When updating bootstrap.scm to
> refer to them, please include the commit ID used to build them in the
> commit message.

Over the last few days, Leo and I coordinated to try cross-compiling the
powerpc64 bootstrap tarballs one more time, using two Guix System VMs.
We did this because we thought that maybe if we took care to keep the
Guix Systems "the same" (e.g., same kernel), it would produce identical
results.  Instead, the result was the same as before: all bootstrap
tarballs except for gcc-static were identical, and gcc-static differed
in ways similar to what has already been described earlier in this bug
report.  In fact, with the exception of gcc-static, the bootstrap
tarballs were identical to the tarballs multiple people built 6 months
ago in June.  This means that (1) with the exception of gcc-static, the
bootstrap tarballs build reproducibly even across systems and after
quite a bit of change has taken place on the master branch, and (2) even
when built from source on two separate, fresh, practically identical
Guix System machines, without using substitutes, the gcc-static binary
still differs.

Now that we have decided to use these powerpc64 bootstrap tarballs, what
are the next steps for uploading them to the GNU FTP server?  I've never
done that before, and I don't think I have access.  For now I've put a
signed copy of the powerpc64-linux (big endian) bootstrap tarballs, with
a SHA-512 hash, here:

https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz
https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.asc
https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.sha512sum

For the record, these bootstrap tarballs were built via the following
steps:

- Use
  https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.x86_64-linux.iso.xz
  to install Guix System 1.2.0 on an x86_64-linux machine.
- Run: guix pull --no-substitutes 
--commit=1ced8379c7641788fa607b19b7a66d18f045362b
- Run: guix bu

bug#42405: r-hdf5array fails to build

[zimoun]

Hi,

>> It is missing the (proprietary) SZIP Compression Library.
>
> Well, it built fine with 63b75c01c2374edc38437215278f50b617a12c08.  And
> now using Guix 02c3c51, I get also fine:
>
> $ guix build r-hdf5array
> /gnu/store/qrxrky9jj0mv96yy1875qfwwig7mgsyd-r-hdf5array-1.16.1
>
> $ guix build r-hdf5array --no-grafts --check

[...]

> /gnu/store/w29frb8jpz0w8xkj7p4rxvs7agzqfpvv-r-hdf5array-1.16.1
>
> Could you confirm it works for you?  If yes, feel free to close the bug?

Since it works also with 69b9826 (2020-12-19), substitute available and
reproducible build, I am closing.

All the best,
simon