bug#61967: guix pack error with python packages
Hi Josselin, Josselin Poiret writes: > Hi Maxim, > > Maxim Cournoyer writes: > >> If you send it *after* the core-updates merge (to core-updates)? It's >> going to be quite a while before it lands to master. Perhaps you could >> send it now? core-updates is the right branch for mass rebuilds. > > I think we are trying to move away from the massive core-updates branch > and rather work with feature branches instead, although the pending > core-updates merge is blocking the change for now. I don't want to add > yet more work for people courageously working on core-updates right now. Perhaps I'm out of the loop, but in my book the main branches should never close. If there's a need to freeze the state of one the three main branches new development branches can be created. This was discussed in the past. -- Thanks, Maxim
bug#61955: Code snippets do not show in Firefox reader mode
Hi, Looking at it, it seems that a tag would be more appropriate, and indeed it is not removed by the reader mode. I don't know who should be informed of this though, as I am not well versed in the HTML output of the manual building process :p Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#62055: `guix pull` fails on freshly installed Guix on Debian aarch64
Hi Gabriel, "Wicki Gabriel (wicg)" writes: > failed to compute the derivation for Guix (version: > "6e4b997cdfb12b657f525949409c3b761ab4d901"; system: "aarch64-linux"; > host version: "1.2.0"; pull-version: 1). > Please report the COMPLETE output above by email to . Your Guix version is quite old at this point, mostly because you're using the Debian package. Can you try installing from the binary installer script instead? Note also that `guix pull` requires quite a lot of memory, than a raspberry pi might not have. Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#62051: Early detection of derivations with unreadable builder scripts
Hi Chris, Christopher Baines writes: > This is part of the following builder script: > > (cons "--enable-mpi-java" #) > > from: /gnu/store/yngxnpcs4s6y8acxf4nwx5pcpj0j6q6i-java-openmpi-4.1.4-builder > > And when attempting to build that derivation, you get the following > error. > > ice-9/read.scm:126:4: In procedure read-expr*: > > /gnu/store/yngxnpcs4s6y8acxf4nwx5pcpj0j6q6i-java-openmpi-4.1.4-builder:1:3820: > Unknown # object: "#<" > > > It would be nice if Guix could detect this category of problems and > raise an error at the time the derivation is created, rather than the > error occuring only when you build the derivation. > > This would be helpful particularly for the Guix Data Service since > currently it ends up storing these useless derivations, often many times > since the builder includes some often changing string (7f366e0cd930 in > the example above), so this is a common cause of spurious changes > between revisions (as often noted on qa.guix.gnu.org). We could probably modify sexp->string, or the builder bind in gexp->derivation so that the sexp is sanity-checked for non-printable things (we could even work on a whitelist basis). However, the docstring of sexp->string talks about performance, and indeed "write" is pure C code and very fast. I'd be reluctant to introduce a performance hit that would be too heavy here. This particular example though was caused by non-gexp #:phase arguments, so another option could be to sanity check sexps given to sexp->gexp, but again, the docstring talks about performance, so I'm not sure what we should do here. In general, things written only with G-Exps should work well, because you can't insert random stuff into them, but S-Exps are more dangerous, hence why I think this option would be a better middle ground. Paging Ludo wrt. the performance cost of this (I can write a patch for it adding a whitelist of what is allowed in a sexp->gexp sexp). Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#62021: Failed to Build docker 20.10.17
Hi again, Josselin Poiret writes: > This looks like a Y2038 bug, what architecture and kernel version are > you running on? Specifying your filesystem types would also help, as some are still affected by Y2038. Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#61967: guix pack error with python packages
Hi Maxim, Maxim Cournoyer writes: > If you send it *after* the core-updates merge (to core-updates)? It's > going to be quite a while before it lands to master. Perhaps you could > send it now? core-updates is the right branch for mass rebuilds. I think we are trying to move away from the massive core-updates branch and rather work with feature branches instead, although the pending core-updates merge is blocking the change for now. I don't want to add yet more work for people courageously working on core-updates right now. Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#62021: Failed to Build docker 20.10.17
Hi, Edison Ibáñez writes: > === Failed > === FAIL: pkg/system TestChtimesLinux (0.00s) > chtimes_linux_test.go:87: Expected: 2262-04-11 23:47:16 + UTC, > got: 2038-01-19 03:14:07 + UTC > > === FAIL: pkg/system TestChtimes (0.00s) > chtimes_test.go:92: Expected: 2262-04-11 23:47:16 + UTC, got: > 2038-01-19 03:14:07 + UTC This looks like a Y2038 bug, what architecture and kernel version are you running on? Funnily enough, CI cannot build it on i686 for some other integer overflow error and powerpc because of some weird file too big error. I don't know much about Go though. Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#62071: openjdk@9/10 sources not reproducible
Hi, it looks like the (auto-generated) tarballs for openjdk@9 and openjdk@10 changed their hash, causing a hash mismatch via guix build -S openjdk@9 --no-substitutes --no-grafts I’m not sure why it uses these tarballs in the first place, since we have a hg-download. Lars
