bug#70886: Packaging a gradle application

[Julien Lepiller]

After 1.0.0, I'm able to build one more version, but it is not built properly, 
as it's not able to build ittelf or any other version. There's probably 
something wrong with one of the dependencies, but it's hard to say what and 
which one exactly.

One way to test would be to rebuild with the shipped jar dependencies and see 
if we can get further, then figure out which is responsible for the issue. It's 
very time consumming though.

Le 12 mai 2024 20:57:12 GMT+02:00, Nicolas Graves  a écrit :
>
>Hi Noé,
>
>Regarding Gradle, IIRC, the main hinderance to get that into Guix is the
>extremely costly bootstrap process through which its building blocks (in
>particular recent Kotlin versions) can be built. 
>
>The work on this is mainly done by Julien Lepiller in channel
>guix-android :
>https://framagit.org/tyreunom/guix-android/-/blob/master/android/packages/kotlin.scm
>
>He managed to get kotlin v1.0.0 to work but there was another
>hurdle IIRC, I can't tell you more, but maybe Julien can.
>
>There's still quite some work to do before we're able to write and use a
>gradle-build-system. If you have a lot of computer power, don't hesitate
>to take a look there.
>
>There's also more info disseminated in the mailing list.
>

bug#69996: Broken OCaml packages (e.g. frama-c and binsec)

[Julien Lepiller]

At least for Frama-C, the issue is environment variables. It requires OCAMLPATH 
to work correctly. So this works:

guix shell frama-c ocaml -- frama-c

Even though the compiler is not needed.

It's another example of why we should propagate search paths, although we could 
also redefine the same search path in packages that need it ;)

Le 25 mars 2024 11:29:44 GMT+01:00, pukkamustard  a 
écrit :
>
>As reported by Arnaud (off-list mail) some OCaml packages build fine but
>seem to be broken.
>
>Examples include `frama-c` and `binsec`:
>
>```
>guix shell frama-c -- frama-c
>[kernel] Current source was: :0
>  The full backtrace is:
>  Raised at Dune_site_plugins__Plugins.lookup_and_summarize.loop.(fun) in file 
> "otherlibs/dune-site/src/plugins/plugins.ml", line 237, characters 16-87
>  Called from Dune_site_plugins__Plugins.load_gen in file 
> "otherlibs/dune-site/src/plugins/plugins.ml", line 263, characters 39-69
>  Called from Stdlib__List.iter in file "list.ml", line 110, characters 12-15
>  Called from Stdlib__List.iter in file "list.ml", line 110, characters 12-15
>  Called from Frama_c_kernel__Kernel.bootstrap_loader in file 
> "src/kernel_services/plugin_entry_points/kernel.ml", line 933, characters 
> 35-62
>  Called from Frama_c_kernel__Cmdline.parse_and_boot in file 
> "src/kernel_services/cmdline_parameters/cmdline.ml", line 894, characters 2-22
>  Called from Frama_c_kernel__Cmdline.catch_toplevel_run in file 
> "src/kernel_services/cmdline_parameters/cmdline.ml", line 233, characters 4-8
>  
>  Unexpected error (The library "frama-c-aorai.core" can't be found in the 
> search paths "/gnu/store/psmc4940aa9bj23dddkglv0p2yhi05kn-ocaml-4.14.1/lib".).
>  Please report as 'crash' at https://git.frama-c.com/pub/frama-c/issues
>  Your Frama-C version is 27.1 (Cobalt).
>  Note that a version and a backtrace alone often do not contain enough
>  information to understand the bug. Guidelines for reporting bugs are at:
>  https://git.frama-c.com/pub/frama-c/-/wikis/Guidelines-for-reporting-bugs
>```
>
>```
>guix shell binsec -- binsec -v
>Fatal error: exception The library "binsec.sse.checkct" can't be found in the 
>search paths "/gnu/store/psmc4940aa9bj23dddkglv0p2yhi05kn-ocaml-4.14.1/lib".
>```
>
>
>

bug#69682: [PATCH 1/1] gnu: ocaml-extlib: Build with minimal=1.

[Julien Lepiller]

Ah, you sent this while I was writing to the other bug. Would it be possible to 
convert the recipe to use the dune-build-system instead? It sounds like it 
would be more future-proof, and it's also prefered by opam people.

Le 9 mars 2024 22:03:15 GMT+01:00, Vivien Kraus  a 
écrit :
>* gnu/packages/ocaml.scm (ocaml-extlib) [arguments]: Convert to list of
>G-Expressions.  Add #:make-flags.
>
>Change-Id: I42ee3c21a52788f20ddc3381927ef6ef40b2a354
>---
> gnu/packages/ocaml.scm | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
>diff --git a/gnu/packages/ocaml.scm b/gnu/packages/ocaml.scm
>index 0f4c351141..b911da8e5b 100644
>--- a/gnu/packages/ocaml.scm
>+++ b/gnu/packages/ocaml.scm
>@@ -646,9 +646,11 @@ (define-public ocaml-extlib
> "1jydzw2n84cfiz9y6lk4gih4wbr8jybanmiryfs01svd07g4vpjq"
> (build-system ocaml-build-system)
> (arguments
>- `(#:phases
>-   (modify-phases %standard-phases
>- (delete 'configure
>+ (list
>+  #:make-flags #~'("minimal=1")
>+  #:phases
>+  #~(modify-phases %standard-phases
>+  (delete 'configure
> (native-inputs
>   (list ocaml-cppo))
> (home-page "https://github.com/ygrek/ocaml-extlib";)

bug#68333: Time bomb in icedtea/openjdk

[Julien Lepiller]

Hi Guix!

There seems to be a time bomb in icedtea@2 and openjdk@9. while
building it:

Error: time is more than 10 years from present: 138852720
java.lang.RuntimeException: time is more than 10 years from present:
138852720 at
build.tools.generatecurrencydata.GenerateCurrencyData.makeSpecialCaseEntry(GenerateCurrencyData.java:288)
at
build.tools.generatecurrencydata.GenerateCurrencyData.buildMainAndSpecialCaseTables(GenerateCurrencyData.java:227)
at
build.tools.generatecurrencydata.GenerateCurrencyData.main(GenerateCurrencyData.java:158)

I managed to work around that by setting the date back, but we should
investigate and fix it. icedtea@3 doesn't seem to be affected.

bug#67043: Build java-geronimo-xbean-bundleutils.x86_64-linux on master is broken.

[Julien Lepiller]

It seems to be working on bordeaux:

https://data.qa.guix.gnu.org/gnu/store/yirvdai4a50mv6fqbw44nw9s38agxrzj-java-geronimo-xbean-bundleutils-4.5.drv

Looking at the build log, it's related to a failure of java-testng, which had 
sometimes randomly failed in the past. It's hard to diagnose:

Failures in  :TestNG,  :DataProvider 
test.dataprovider.DataProviderTest.parallelDataProviderSample() StackTrace: 
java.lang.AssertionError: Expected size:<4> but was:<3> in:   at 
test.dataprovider.DataProviderTest.parallelDataProviderSample(Unknown Source) 
... Removed 27 stack frames
error: in phase 'check': uncaught exception

We could try disabling some tests if they fail often.

Le 10 novembre 2023 15:12:21 GMT+01:00, Maxim Cournoyer 
 a écrit :
>Hi,
>
>cuir...@gnu.org (Cuirass) writes:
>
>> The build java-geronimo-xbean-bundleutils.x86_64-linux for 
>> specification
>> master is broken. You can find the detailed information about this 
>> build > href="https://ci.guix.gnu.org/build/2587938/details";>here.
>>
>> https://ci.guix.gnu.org/build/2587938/details
>
>This seems to relate to a series of java updates recently pushed by
>Julien (CC'd).
>

bug#26247: Gettext introduces timestamps in .mo files

[Julien Lepiller]

It's interesting to see that only the generate po files are compiled to 
non-reproducible mo files. All other translations seem fine, right? Could it be 
related to the way these po files are created? It might introduce a timestamp 
at that point, but I can't check right now.

Le 17 octobre 2023 01:48:40 GMT+02:00, Simon Tournier 
 a écrit :
>Hi,
>
>It is about this old bug#26247:
>
>https://issues.guix.gnu.org/issue/26247
>
>On Sat, 08 Oct 2022 at 16:25, zimoun  wrote:
>> On Fri, 11 Dec 2020 at 14:26, Miguel Ángel Arruga Vivas 
>>  wrote:
>>
>>> This bug has already been reported upstream[1] and probably I'll push it
>>> as soon as I have more test cases prepared and receive a brief review,
>>> but I can prepare a patch for previous versions if it's needed too.
>>>
>>> Best regards,
>>> Miguel
>>>
>>> [1] https://savannah.gnu.org/bugs/?59658
>>
>> Are commits 4343ca8ba5b02c8fe09e5bd681abbc0440ab8b08 and following the
>> ones mentioned here?
>>
>> Well, I am not sure to understand if it had been fixed upstream [1].
>
>The issue is still not fixed in Guix.
>
>--8<---cut here---start->8---
>$ guix time-machine --commit=b437896e87a51cc610388d4c462893652dd773e6 -- 
>challenge guix --substitute-urls="https://ci.guix.gnu.org 
>https://bordeaux.guix.gnu.org";
>/gnu/store/0znvqzij8lvf4lv7xxs126wxzgmx0zsw-guix-1.4.0-13.e863274 contents 
>differ:
>  no local build for 
> '/gnu/store/0znvqzij8lvf4lv7xxs126wxzgmx0zsw-guix-1.4.0-13.e863274'
>  
> https://ci.guix.gnu.org/nar/lzip/0znvqzij8lvf4lv7xxs126wxzgmx0zsw-guix-1.4.0-13.e863274:
>  1inv5ri4z35xz6cv9laiaf4nv9v9km7ggvbwcdhxpv5hkabsbjia
>  
> https://bordeaux.guix.gnu.org/nar/lzip/0znvqzij8lvf4lv7xxs126wxzgmx0zsw-guix-1.4.0-13.e863274:
>  13njz5kn402g5larsbmbi25dx4w8azpbffqlkhyagc52hnbpqxaf
>  differing files:
>
>[...]
>
>/share/locale/en@boldquot/LC_MESSAGES/guix-packages.mo
>/share/locale/en@boldquot/LC_MESSAGES/guix.mo
>/share/locale/en@quot/LC_MESSAGES/guix-packages.mo
>/share/locale/en@quot/LC_MESSAGES/guix.mo
>
>1 store items were analyzed:
>  - 0 (0.0%) were identical
>  - 1 (100.0%) differed
>  - 0 (0.0%) were inconclusive
>--8<---cut here---end--->8---
>
>Cheers,
>simon

bug#65541: New fancy progress bars writing new lines instead of updating original

[Julien Lepiller]

Le Sat, 26 Aug 2023 10:25:53 +0900,
elaexuotee--- via Bug reports for GNU Guix  a écrit :

> The new pretty progress bars are quite nice. One issue I am
> ecountering, however, is demonstrated in the snippet below:
> 
> オブジェクトにインデックスを付けています  71%
> ▕▉
> オブジェクトにインデックスを付けています  74%
> ▕█▏
> オブジェクトにインデックスを付けています  77%
> ▕█▍
> オブジェクトにインデックスを付けています  81%
> ▕█▋
> オブジェクトにインデックスを付けています  84%
> ▕█▊
> オブジェクトにインデックスを付けています  87%
> ▕█
> オブジェクトにインデックスを付けています  90%
> ▕█
> 
> When preceeding text contains double-width characters, progress bar
> updates end up printing new lines instead of overwriting the
> original. When the preceeding text is ascii, such as for substitute
> downloads, then the bars work beautifully.
> 
> My guess is that the width-calculation simply forgets to account for
> possible double-width charaters in the text snippet.
> 
> Anyone else seeing this?
> 
> Cheers,
> B. Wilson
> 

I don't think it's specific to the fancy bars, and I was able to
reproduce with "LANG=ja_JP.UTF-8 guix pull".

I sent a patch, now tracked https://issues.guix.gnu.org/65546, which
fixes the issue.

To test it, I did:

msgfmt po/guix/ja.po
cd ../..
mkdir -p ja/LC_MESSAGES
mv messages.mo ja/LC_MESSAGES/guix.mo
./configure --localstatedir=/var --sysconfdir=/etc --localedir=$(pwd)
make
./pre-inst-env guix pull

(if you don't specify a localedir, it'll try to find the translations
in /usr by default)

No more newlines :)

bug#64966: Rockpro64 SBC not booting anymore after "gnu: shepherd@0.10: Use guile-fibers 1.3.1."

[Julien Lepiller]

Le Fri, 25 Aug 2023 20:24:28 +0200,
Denis 'GNUtoo' Carikli  a écrit :

> ./pre-inst-env guix deploy -L
> rockpro64/ rockpro64/rockpro64.scm

If you're doing this on a non aarch64 system, you'll need to add
--system=aarch64-linux.

bug#65424: Guix doesn't use positional arguments in translated formatted messages

[Julien Lepiller]

Le 21 août 2023 14:09:14 GMT+02:00, Maxime Devos  a 
écrit :
>Consider, e.g.,
>
>(format #t (G_ "~0@*~a should be set to ~1@*~a instead of ~2@*~a~%") "CC" 
>"(cc-for-target)" "gcc")
>->
>CC should be set to (cc-for-target) instead of gcc
>
>By using positional arguments like this, translators can reorder the sentence 
>to:
>
>(format #t (G_ "It's not ~2@*~a that ~0@*~a should be set to, but ~1@*~a~%") 
>"CC" (cc-for-target) "gcc"))
>
>~0@*~a should be set to ~1@*~a instead of ~2@*~a~%") "CC" "(cc-for-target)" 
>"gcc")
>->
>It's not gcc that CC should be set to, but (cc-for-target).
>
>CC should be set to (cc-for-target) instead of gcc
>
>Such reorderings are occasionally useful, yet AFAIK nowhere (except 
>po/guix/ta.po, the mcron service and de.po) is this used.
>
>Sure, you could as translator add these ~N@* afterwards, but you need to know 
>that's possible in the first place (and if you know it's possible, you still 
>need to remember or rediscover what exactly to write), and it would be much 
>simpler and more discoverable if they were included from the start.  Also, 
>IIRC, Weblate complains if you add these.
>
>p.s.: I'm writing a new linter, this particular example doesn't occur yet in 
>Guix.

That sounds reasonnabe. The very least we could do is document this syntax in 
the manual. Weblate would complain indeed, sirce it won't find the same formats 
in the source and target strings. It might complain about the order too, but 
that's something we could contribute upstseam if it happens.

bug#63947: Bug when building ocaml-dune-build-info for ocaml5.0

[Julien Lepiller]

Untested yet, but looks fine, thanks

Le 13 juin 2023 07:08:11 GMT+02:00, pukkamustard  a 
écrit :
>
>Hi Benjamin,
>
>Thanks for the report.
>
>"Benjamin"  writes:
>
>> Here is a minimal example to reproduce the bug :
>>
>> ---
>> (use-modules
>>   (gnu packages ocaml)
>>   (guix build-system ocaml))
>>
>> ;ocaml-dune-build-info
>> (package-with-ocaml5.0 ocaml-dune-build-info)
>> ---
>>
>> Building the commented default version will create the expected package
>> in /gnu/store/...ocaml-dune-build-info
>>
>> While building the ocaml5.0 version will build /gnu/store/...ocaml5.0-dune
>
>Yes, this is a bug.
>
>The reason is that the `(inherit dune)` in ocaml-dune-build-info
>incorrectly inherits the package variant properties from dune. The OCaml
>5.0 variant for ocaml-dune-build-info becomes ocaml5.0-dune.
>
>I think the best way to fix this is to clear the package variant
>properties in ocaml-dune-build-info by resetting the properties. Find
>attached a patch that does exactly that. CC: Julien for review.
>
>Your fix to inherit from `dune-bootstrap` has a similar effect as the
>package variants are defined in `dune` but not `dune-bootstrap`. I
>slightly prefer not inheriting from `dune-bootstrap` as it reduces
>things that directly touch bootstrap stuff.
>
>-pukkamustard
>

bug#63516: [PATCH Guile-Netlink 00/11] Add 'wait-for-link' and related code

[Julien Lepiller]

I'll probably tag a release this week-end.

Le 24 mai 2023 16:55:56 GMT+02:00, "Ludovic Courtès"  a écrit :
>Hello,
>
>Julien Lepiller  skribis:
>
>> Thanks, I was able to test it simply by doing something like
>> (wait-for-link "veth0") and from another terminal, "ip l add veth0 type
>> veth peer veth1" (it doesn't have to be veth, it's the first one I
>> thought of that I didn't have to reach the manual for).
>
>Neat (I really need to take modern networking class :-)).
>
>> Pushed to guile-netlink's master :)
>
>That was fast, thanks a lot!
>
>Are you planning to tag a release soonish?  If you do, we could use
>‘wait-for-link’ to fix <https://issues.guix.gnu.org/63516>.
>
>Ludo’.

bug#63516: [PATCH Guile-Netlink 00/11] Add 'wait-for-link' and related code

[Julien Lepiller]

Thanks, I was able to test it simply by doing something like
(wait-for-link "veth0") and from another terminal, "ip l add veth0 type
veth peer veth1" (it doesn't have to be veth, it's the first one I
thought of that I didn't have to reach the manual for).

Pushed to guile-netlink's master :)

Le Tue, 23 May 2023 14:39:40 +0200,
Ludovic Courtès  a écrit :

> Hi Julien,
> 
> As a followup to , here is code
> that lets us wait for a link to show up “the right way”—i.e., without
> polling. It works over SOCK_NONBLOCK sockets, for use in Fibers
> programs.
> 
> I tested it in a VM created with ‘guix system vm’.  If the “ens3”
> device is already there, (wait-for-link "ens3") returns immediately.
> Then I ran “rmmod e1000” to make the device disappear, and made
> another (wait-for-link "ens3") call: that call returns once I’ve run
> “modprobe e1000” in another terminal.  Wonderful.  :-)
> 
> Now, it would be good to have a test suite that can run without
> complicated setups.  We should check the strategy used by libnl,
> systemd, and the likes.
> 
> Thoughts?
> 
> Ludo’.
> 
> Ludovic Courtès (11):
>   connection: Remove unused procedure.
>   connection: Use Guile's 'socket' procedure to open a socket.
>   connection: Throw upon errors in FFI bindings.
>   connection: Add support for suspendable sockets.
>   connection: Allow users to pass extra SOCK_ flags to 'socket'.
>   link: Extract 'new-link-message->link'.
>   addr: Extract 'new-address-message->address'.
>   connection: Add 'add-socket-membership'.
>   error: Add 'sub-type' field to '&netlink-decoder-error' and use it.
>   doc: Add indexes.
>   link: Add 'wait-for-link'.
> 
>  doc/guile-netlink.texi |  51 +++--
>  ip/addr.scm|  46 +++
>  ip/link.scm| 122 ++-
>  ip/route.scm   |   6 +-
>  netlink/connection.scm | 126
> +++-- netlink/constant.scm   |
> 40 + netlink/data.scm   |  13 +++--
>  netlink/error.scm  |   4 +-
>  8 files changed, 303 insertions(+), 105 deletions(-)
> 
> 
> base-commit: beceb4cfea4739954e558411f46e07425891c774

bug#62992: Stray po.go file

[Julien Lepiller]

I don't remember why we did that. The constraints for that file are:

- it's not required to install it
- it must be built before the manuals are generated (it's used for translations)
- it should be built, since otherwise it takes a long time to run
- it has no dependencies
- it's not actually stray

Not sure what the best solution for that is. 

Le 21 avril 2023 15:00:54 GMT+02:00, Andreas Enge  a écrit :
>This is not related to the dancefloor. Someone on IRC mentioned that
>"make clean-go" leaves a stray file guix/build/po.go.
>
>I suppose that it should be added to Makefile.am in the line
>that currently reads:
>GOBJECTS = $(MODULES:%.scm=%.go) guix/config.go $(dist_noinst_DATA:%.scm=%.go)
>
>but would like to leave it to the experts.
>
>Actually further above we have this:
>MODULES_NOT_COMPILED =  \
>  guix/build/po.scm \
>  guix/man-db.scm
>
>So maybe a better fix would be to move guix/build/po.scm to MODULES
>instead, since apparently it is compiled.
>
>Andreas
>
>
>
>

bug#62332: error: java-eclipse-aether-Api: unbound variable

[Julien Lepiller]

How weird, I don't see it spelled like that in the repository (latest master). 
I don't see any recent change in the file either.

Maybe there's an issue with your local checkout.
Guix has a checkout of the repository in one of the directories of 
~/.cache/guix/checkouts. You should be able to locate it from its contents. 
What's the output of "git status" and "git diff"?

If there's tome change, you could try "git checkout ." to reset the repo to its 
original state.

Le 21 mars 2023 14:51:04 GMT+01:00, Matthew James Kraai  a 
écrit :
>Hi,
>
>When I run `guix pull`, it displays the following output:
>
>```
>Updating channel 'guix' from Git repository at 
>'https://git.savannah.gnu.org/git/guix.git'...
>Authenticating channel 'guix', commits 9edb3f6 to 38b64d4 (48 new commits)...
>Building from this channel:
>  guix  https://git.savannah.gnu.org/git/guix.git  38b64d4
>substitute: updating substitutes from 'https://substitutes.nonguix.org'... 
>100.0%
>substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
>substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
>building 
>/gnu/store/qmaxdq9qd8nnyig9qs55bv5ddbqss7d3-compute-guix-derivation.drv...
>Computing Guix derivation for 'x86_64-linux'... |Backtrace:
>In ice-9/boot-9.scm:
>   222:29 19 (map1 (((gnu packages java-compression)) ((gnu packages 
> java-xml)) ((gnu packages libffi)) ((gnu # ?)) ?))
>   222:29 18 (map1 (((gnu packages java-xml)) ((gnu packages libffi)) ((gnu 
> packages linux)) ((gnu packages #)) (#) ?))
>   222:29 17 (map1 (((gnu packages libffi)) ((gnu packages linux)) ((gnu 
> packages maths)) ((gnu packages maven)) # ?))
>   222:29 16 (map1 (((gnu packages linux)) ((gnu packages maths)) ((gnu 
> packages maven)) ((gnu packages #)) ((# ?)) ?))
>   222:29 15 (map1 (((gnu packages maths)) ((gnu packages maven)) ((gnu 
> packages maven-parent-pom)) ((gnu # #)) (#) ?))
>   222:17 14 (map1 (((gnu packages maven)) ((gnu packages maven-parent-pom)) 
> ((gnu packages ncurses)) ((gnu # #)) # ?))
>  3326:17 13 (resolve-interface (gnu packages maven) #:select _ #:hide _ 
> #:prefix _ #:renamer _ #:version _)
>In ice-9/threads.scm:
>390:8 12 (_ _)
>In ice-9/boot-9.scm:
>  3252:13 11 (_)
>In ice-9/threads.scm:
>390:8 10 (_ _)
>In ice-9/boot-9.scm:
>  3536:20  9 (_)
>   2835:4  8 (save-module-excursion # ice-9/boot-9.scm:3537:21 ()>)
>  3556:26  7 (_)
>In unknown file:
>   6 (primitive-load-path "gnu/packages/maven" # 7ff1f4d886e0 at ice-9/boot-9.scm:3543:37 ()>)
>In ice-9/eval.scm:
>619:8  5 (_ #f)
>   626:19  4 (_ #)
>   173:55  3 (_ #(#(#(#(#(# 
> "java-eclipse-aether-test-util") #) #) #) #))
>159:9  2 (_ #(#(#(#(#(# 
> "java-eclipse-aether-test-util") #) #) #) #))
>   223:20  1 (proc #(#(#(#(#(# 
> "java-eclipse-aether-test-?") #) #) #) #))
>In unknown file:
>   0 (%resolve-variable (7 . java-eclipse-aether-Api) # packages maven) 7ff1f888ae60>)
>
>ERROR: In procedure %resolve-variable:
>error: java-eclipse-aether-Api: unbound variable
>guix pull: error: You found a bug: the program 
>'/gnu/store/3ibvvz7wnwxsayssdyb1rbyagx3zd9wh-compute-guix-derivation'
>failed to compute the derivation for Guix (version: 
>"38b64d47ed3dfaeb63b859e7a8834e477ffed3a1"; system: "x86_64-linux";
>host version: "4f4e4abd3ac3552cbf8596a50b5dade8d111571f"; pull-version: 1).
>Please report the COMPLETE output above by email to .
>```
>
>This has been happening for some days.  Is there a way to resolve this?
>

bug#61965: Commands like "guix system search KEYWORD" don't work with locale it_IT.utf8

[Julien Lepiller]

Gettext already checks issues with format strings, and for the manual, I always 
try to build it, so I can catch most issues. Unfortunately, we don't have good 
tools to check texinfo markup in our strings, so this kind of error can stell 
slip in, I hadn't realized.

I'll try to contact the translator who did that and see if they have an idea 
how to make the situation better.

At the very least, I think we should validate strings better before we accept 
translations, and make warnings more visible.

Le 10 mars 2023 10:42:24 GMT+01:00, Tobias Geerinckx-Rice  a 
écrit :
>> I believe Tobias (Cc’d) fixed this and related issues
>> a couple of days ago
>
>Yep.  I also fixed a worrying number of @comando, @opzione, etc. on Weblate 
>(both in the 'guix' and 'packages' sets).
>
>Weblate is pretty unfriendly, so this was tedious and I'm positive there are 
>some I missed.  There's a comment warning translators not to do this, but it's 
>sadly useless since it's tied to *one* package—the odds of seeing it are 
>vanishing.
>
>Julien, is there a way to make this warning more prominent/ubiquitous?
>
>(Also, is there a translation workflow that avoids relying on Weblate or other 
>clunky tools?)
>
>Run-time errors appear to be the only QA available for these strings, but this 
>failure mode is extreme.  How about explicitly reporting the error & 
>continuing in English?
>
>From what I remember, the code won't be elegant (we append to the translation, 
>then convert Texi, so falling back must be done by the caller or a new combo 
>procedure) but the result would be better.
>
>Kind regards,
>
>T G-R
>
>Sent on the go.  Excuse or enjoy my brevity.

bug#61965: Commands like "guix system search KEYWORD" don't work with locale it_IT.utf8

[Julien Lepiller]

OK, fixed on master and on weblate. Hope it works now!

Had to change @esempio to @example (it's Texinfo markup that's not supposed to 
be cranslated) and even found a typo'd @sempio.

Also, if you want to help with translations andqproof-reading, you're very 
welcome to edit on https://translate.fedoraproject.org/projects/guix/guix/it :)

Le 7 mars 2023 21:43:59 GMT+01:00, Luigi Salamone  a 
écrit :
>Hi Ludo!
>Hi Julien!
>
>Now "guix system search KEYWORD" works! But... guix install hello:
>
>hint: Backtrace: 16 (primitive-load
>"/home/anonymous/.config/guix/current/b…") In guix/ui.scm: 2300:7 15
>(run-guix . _) 2263:10 14 (run-guix-command _ . _) In ice-9/boot-9.scm:
>1752:10 13 (with-exception-handler _ _ #:unwind? _ # _) In guix/status.scm:
>851:3 12 (_) 831:4 11 (call-with-status-report _ _) In guix/store.scm:
>1300:8 10 (call-with-build-handler _ _) 1300:8 9 (call-with-build-handler #
>…) In guix/build/syscalls.scm: 1442:3 8 (_) 1408:4 7
>(call-with-file-lock/no-wait "/var/guix/profiles/per-u…" …) In
>guix/scripts/package.scm: 325:7 6 (build-and-use-profile _
>"/var/guix/profiles/per-user/…" …) In guix/ui.scm: 325:5 5 (display-hint _
>#:port _ . _) 1473:24 4 (texi->plain-text _) In texinfo.scm: 1132:22 3
>(parse _) 967:36 2 (loop # (*fragment*) # …) 92:2 1 (command-spec _) In
>ice-9/boot-9.scm: 1685:16 0 (raise-exception _ #:continuable? _)
>ice-9/boot-9.scm:1685:16: In procedure raise-exception: Throw to key
>`parser-error' with args `(#f "Unknown command" esempio)'.
>
>Thanks!
>
>
>On Mon, Mar 6, 2023 at 10:47 PM Ludovic Courtès  wrote:
>
>> Hi Luigi,
>>
>> Luigi Salamone  skribis:
>>
>> > I'm unable to use guix commands like "guix system search KEYWORD".
>> > No problem if I run the commend with LANG=LC_ALL.
>>
>> [...]
>>
>> > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> > Throw to key `parser-error' with args `(#f "Unknown command" dnf)'.
>>
>> I believe Tobias (Cc’d) fixed this and related issues a couple of days
>> ago in 0609ae7897b025f46822779d0c5c36509cb0180f and
>> 4775460ba9a60c3c09966216da10686a70b8fadb.
>>
>> Julien: We’ll have to make sure these changes reach Weblate.  :-)
>>
>> Thanks,
>> Ludo’.
>>

bug#61965: Commands like "guix system search KEYWORD" don't work with locale it_IT.utf8

[Julien Lepiller]

Le Mon, 06 Mar 2023 23:46:57 +0100,
Ludovic Courtès  a écrit :

> Hi Luigi,
> 
> Luigi Salamone  skribis:
> 
> > I'm unable to use guix commands like "guix system search KEYWORD".
> > No problem if I run the commend with LANG=LC_ALL.  
> 
> [...]
> 
> > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> > Throw to key `parser-error' with args `(#f "Unknown command" dnf)'.
> >  
> 
> I believe Tobias (Cc’d) fixed this and related issues a couple of days
> ago in 0609ae7897b025f46822779d0c5c36509cb0180f and
> 4775460ba9a60c3c09966216da10686a70b8fadb.
> 
> Julien: We’ll have to make sure these changes reach Weblate.  :-)
> 
> Thanks,
> Ludo’.

I believe it did already reach Weblate :)

bug#58495: opam import generates wrong check phase

[Julien Lepiller]

Le Sat, 28 Jan 2023 20:28:59 +0100,
Csepp  a écrit :

> Julien Lepiller  writes:
> 
> > Le Thu, 13 Oct 2022 18:16:18 +0200,
> > Csepp  a écrit :
> >  
> >> Julien Lepiller  writes:
> >>   
> >> > Maybe this could be fixed in the dune-build-system?
> >> >
> >> Actually, good call.  I'll look into it, unless you want to take a
> >> stab at it.  
> >
> > With the test-target argument removed, do you consider this fixed?  
> 
> Yup, it's fixed now, thanks for closing these.

Closing, thanks

bug#58495: opam import generates wrong check phase

[Julien Lepiller]

Le Thu, 13 Oct 2022 18:16:18 +0200,
Csepp  a écrit :

> Julien Lepiller  writes:
> 
> > Maybe this could be fixed in the dune-build-system?
> >  
> Actually, good call.  I'll look into it, unless you want to take a
> stab at it.

With the test-target argument removed, do you consider this fixed?

bug#61033: opam importer can't handle list field

[Julien Lepiller]

Le Tue, 24 Jan 2023 03:23:44 +0100,
Csepp  a écrit :

> Truncated stack trace:
> 
> ```
> ...
> In guix/import/opam.scm:
> 287:2  3 (opam->guix-package "mirage-crypto-pk" #:repo _ # _)
> In unknown file:
>2 (filter #
> …) In guix/import/opam.scm:
>290:13  1 (_ ("mirage-no-solo5" "mirage-no-xen"))
> In unknown file:
>0 (string-prefix? "conf-" ("mirage-no-solo5" "mirage-n…")
> …)
> 
> ERROR: In procedure string-prefix?:
> In procedure string-prefix?: Wrong type argument in position 2
> (expecting string): ("mirage-no-solo5" "mirage-no-xen") ```
> 
> 
> 

The issue is related to lines like this in the list of dependencies:

(("mirage-no-solo5" & "mirage-no-xen") | "zarith-freestanding" |
"mirage-runtime" {>= "4.0"})

This reads as a choice between three dependencies:
- mirage-no-solo5 with mirage-no-xen
- zarith-freestanding
- mirage-runtime

The importer infrastructure is not intelligent enough to really be able
to solve constraints in imported packages, so I don't see an easy
solution. It could silently use the first option, or put a comment
instead.

Ideas?

bug#58880: [PATCH v2 2/2] nls: Update translation keys for guix gc

[Julien Lepiller]

Ah this is dangerous. You updated the msgid but not the msgstr. This means the 
translation will keep using the old format string. Could you also update the 
msgstr when a translation exists?

You can also drop all the files with no translation for the affected msgids 
from your patch, though this works too.

Le 23 janvier 2023 14:01:26 GMT+01:00, Remco van 't Veer  a 
écrit :
>* po/*/*.po (guix/scripts/gc.scm): Round MiBs in user feedback.
>---
> po/guix/bn.po| 6 +++---
> po/guix/cs.po| 6 +++---
> po/guix/da.po| 6 +++---
> po/guix/de.po| 6 +++---
> po/guix/eo.po| 6 +++---
> po/guix/es.po| 6 +++---
> po/guix/fa.po| 6 +++---
> po/guix/fi.po| 6 +++---
> po/guix/fr.po| 6 +++---
> po/guix/hu.po| 6 +++---
> po/guix/ja.po| 6 +++---
> po/guix/ka.po| 6 +++---
> po/guix/ko.po| 6 +++---
> po/guix/lt.po| 6 +++---
> po/guix/nl.po| 6 +++---
> po/guix/oc.po| 6 +++---
> po/guix/pl.po| 6 +++---
> po/guix/pt_BR.po | 6 +++---
> po/guix/ru.po| 6 +++---
> po/guix/si.po| 6 +++---
> po/guix/sk.po| 6 +++---
> po/guix/sr.po| 6 +++---
> po/guix/sv.po| 6 +++---
> po/guix/ta.po| 6 +++---
> po/guix/tr.po| 6 +++---
> po/guix/uk.po| 6 +++---
> po/guix/vi.po| 6 +++---
> po/guix/zh_CN.po | 6 +++---
> 28 files changed, 84 insertions(+), 84 deletions(-)
>
>diff --git a/po/guix/bn.po b/po/guix/bn.po
>index 55a2942212..83cf451f8f 100644
>--- a/po/guix/bn.po
>+++ b/po/guix/bn.po
>@@ -4067,11 +4067,11 @@ msgid "invoke the garbage collector"
> msgstr ""
> 
> #: guix/scripts/gc.scm:263
>-msgid "already ~h MiBs available on ~a, nothing to do~%"
>+msgid "already ~,2h MiBs available on ~a, nothing to do~%"
> msgstr ""
> 
> #: guix/scripts/gc.scm:266
>-msgid "freeing ~h MiBs~%"
>+msgid "freeing ~,2h MiBs~%"
> msgstr ""
> 
> #: guix/scripts/gc.scm:306
>@@ -4080,7 +4080,7 @@ msgid "extraneous arguments: ~{~a ~}~%"
> msgstr ""
> 
> #: guix/scripts/gc.scm:330 guix/scripts/gc.scm:333
>-msgid "freed ~h MiBs~%"
>+msgid "freed ~,2h MiBs~%"
> msgstr ""
> 
> #: guix/scripts/git.scm:26
>diff --git a/po/guix/cs.po b/po/guix/cs.po
>index 3b5128f227..b0f1c04ea0 100644
>--- a/po/guix/cs.po
>+++ b/po/guix/cs.po
>@@ -4132,11 +4132,11 @@ msgid "invoke the garbage collector"
> msgstr ""
> 
> #: guix/scripts/gc.scm:263
>-msgid "already ~h MiBs available on ~a, nothing to do~%"
>+msgid "already ~,2h MiBs available on ~a, nothing to do~%"
> msgstr ""
> 
> #: guix/scripts/gc.scm:266
>-msgid "freeing ~h MiBs~%"
>+msgid "freeing ~,2h MiBs~%"
> msgstr ""
> 
> #: guix/scripts/gc.scm:306
>@@ -4145,7 +4145,7 @@ msgid "extraneous arguments: ~{~a ~}~%"
> msgstr "Neplatný argument: ~a~%"
> 
> #: guix/scripts/gc.scm:330 guix/scripts/gc.scm:333
>-msgid "freed ~h MiBs~%"
>+msgid "freed ~,2h MiBs~%"
> msgstr ""
> 
> #: guix/scripts/git.scm:26
>diff --git a/po/guix/da.po b/po/guix/da.po
>index 809f0a6d20..89917a7613 100644
>--- a/po/guix/da.po
>+++ b/po/guix/da.po
>@@ -4507,11 +4507,11 @@ msgid "invoke the garbage collector"
> msgstr ""
> 
> #: guix/scripts/gc.scm:263
>-msgid "already ~h MiBs available on ~a, nothing to do~%"
>+msgid "already ~,2h MiBs available on ~a, nothing to do~%"
> msgstr "der er allerede ~h MiBs tilgængelige på ~a, intet at udføre~%"
> 
> #: guix/scripts/gc.scm:266
>-msgid "freeing ~h MiBs~%"
>+msgid "freeing ~,2h MiBs~%"
> msgstr "frigiver ~h MiBs~%"
> 
> #: guix/scripts/gc.scm:306
>@@ -4520,7 +4520,7 @@ msgid "extraneous arguments: ~{~a ~}~%"
> msgstr "uvedkommende argumenter: ~{~a ~}~%"
> 
> #: guix/scripts/gc.scm:330 guix/scripts/gc.scm:333
>-msgid "freed ~h MiBs~%"
>+msgid "freed ~,2h MiBs~%"
> msgstr "frigav ~h MiBs~%"
> 
> #: guix/scripts/git.scm:26
>diff --git a/po/guix/de.po b/po/guix/de.po
>index 39de45814e..ed4da5fdf9 100644
>--- a/po/guix/de.po
>+++ b/po/guix/de.po
>@@ -4561,11 +4561,11 @@ msgid "invoke the garbage collector"
> msgstr "den Müllsammler aufrufen"
> 
> #: guix/scripts/gc.scm:263
>-msgid "already ~h MiBs available on ~a, nothing to do~%"
>+msgid "already ~,2h MiBs available on ~a, nothing to do~%"
> msgstr "Es sind bereits ~h MiB verfügbar auf ~a, nichts zu tun~%"
> 
> #: guix/scripts/gc.scm:266
>-msgid "freeing ~h MiBs~%"
>+msgid "freeing ~,2h MiBs~%"
> msgstr "~h MiB werden freigegeben~%"
> 
> #: guix/scripts/gc.scm:306
>@@ -4574,7 +4574,7 @@ msgid "extraneous arguments: ~{~a ~}~%"
> msgstr "Zusätzliche Argumente: ~{~a ~}~%"
> 
> #: guix/scripts/gc.scm:330 guix/scripts/gc.scm:333
>-msgid "freed ~h MiBs~%"
>+msgid "freed ~,2h MiBs~%"
> msgstr "~h MiB wurden freigegeben~%"
> 
> #: guix/scripts/git.scm:26
>diff --git a/po/guix/eo.po b/po/guix/eo.po
>index f0e433ed1f..bbd6870f4f 100644
>--- a/po/guix/eo.po
>+++ b/po/guix/eo.po
>@@ -4344,12 +4344,12 @@ msgid "invoke the garbage collector"
> msgstr ""
> 
> #: guix/scripts/gc.scm:263
>-msgid "already ~h MiBs available on ~a, nothing to do~%"
>+msgid "already ~,2h MiBs available on ~a, nothing to do~%"
> msgstr ""
> 
> #: guix/scripts/gc.scm:266
> #, fuzzy
>-msgid "freeing ~h MiBs~%"
>+msgid

bug#58880: Patch impacting translation (was Re: bug#58880: 'guix gc' does not round the amount of disk space freed)

[Julien Lepiller]

Changing the po files in guix repo will work at first, it'll be negated next 
time I push changes from weblate. We could change the po files to ensure 
continuity, but we have to also apply the change to the repo behind weblate. I 
can take care of it after the patch is pushed.

Le 22 janvier 2023 15:49:55 GMT+01:00, zimoun  a 
écrit :
>Hi,
>
>On Sat, 21 Jan 2023 at 17:52, Remco van 't Veer  wrote:
>
 * guix/scripts/gc.scm (guix-gc): Round MiBs in user feedback.
 * po/*/*.po (guix/scripts/gc.scm)a: Round MiBs in user feedback.
>>>
>>> If the way to go with the translation dance?
>>
>> I don't know.  I figured since the translation key was changed this
>> would be the best way to do this but to be honest I don't understand how
>> to do this using "weblate" (from info:guix#Translating Guix).
>
>Julien, WDYT?
>
>
>>> The only change is:
>>>
 diff --git a/guix/scripts/gc.scm b/guix/scripts/gc.scm
 index 5e775c5cdb..2bbfb26d5d 100644
 --- a/guix/scripts/gc.scm
 +++ b/guix/scripts/gc.scm
 @@ -260,10 +260,10 @@ (define-command (guix-gc . args)
  ;; Attempt to have at least SPACE bytes available in STORE.
  (let ((free (free-disk-space (%store-prefix
(if (> free space)
 -  (info (G_ "already ~h MiBs available on ~a, nothing to do~%")
 +  (info (G_ "already ~,2h MiBs available on ~a, nothing to do~%")
  (/ free 1024. 1024.) (%store-prefix))
(let ((to-free (- space free)))
 -(info (G_ "freeing ~h MiBs~%") (/ to-free 1024. 1024.))
 +(info (G_ "freeing ~,2h MiBs~%") (/ to-free 1024. 1024.))
  (collect-garbage store to-free)

(define (delete-generations store pattern)
 @@ -327,10 +327,10 @@ (define-command (guix-gc . args)
   (ensure-free-space store free-space))
  (min-freed
   (let-values (((paths freed) (collect-garbage store 
 min-freed)))
 -  (info (G_ "freed ~h MiBs~%") (/ freed 1024. 1024.
 +  (info (G_ "freed ~,2h MiBs~%") (/ freed 1024. 1024.
  (else
   (let-values (((paths freed) (collect-garbage store)))
 -  (info (G_ "freed ~h MiBs~%") (/ freed 1024. 1024.)))
 +  (info (G_ "freed ~,2h MiBs~%") (/ freed 1024. 1024.)))
  ((list-roots)
   (assert-no-extra-arguments)
   (list-roots))
>>>
>>> and captured by G_ so does this only to be applied and then all the
>>> msgid updated by the translation process?
>>
>> Yes, this is the only change.  The old keys will be orphaned though and
>> remain in the po files.  I'd be happy to drop the po/*/*.po part of the
>> patch if that helps.
>
>Julien, what is the best solution?  Apply a patch touching all PO files
>or apply a patch touching only the messages captured by G_ and then
>update separately the translations?
>
>
>Cheers,
>simon

bug#60861: "Building from GIT" not succeeding

[Julien Lepiller]

Replying to the list and closing then. Glad you found a solution :)

Le 17 janvier 2023 01:49:27 GMT+01:00, Laurence Taylor  
a écrit :
>Explorer Exclude is a vscode plugin that moved repo and I had to install
>manually. Looks like I must have pasted it into the source file without
>realising.
>By the time I took to email, I was up around the chandeliers. Do excuse.
>
>Loz.
>
>On Mon, Jan 16, 2023 at 7:39 PM Julien Lepiller  wrote:
>
>> Le Mon, 16 Jan 2023 13:08:37 +0100,
>> Laurence Taylor  a écrit :
>>
>> > > ice-9/eval.scm:293:34: no code for module (sExplorer Excluderfi
>> > > srfi-35)
>>
>> This looks weird, what is "Explorer Excluder"? It's definitely not in
>> gnu.scm.
>>

bug#60861: "Building from GIT" not succeeding

[Julien Lepiller]

Le Mon, 16 Jan 2023 13:08:37 +0100,
Laurence Taylor  a écrit :

> > ice-9/eval.scm:293:34: no code for module (sExplorer Excluderfi
> > srfi-35)

This looks weird, what is "Explorer Excluder"? It's definitely not in
gnu.scm.

bug#60816: guix pull ("computing Guix derivation") is not reproducible

[Julien Lepiller]

Le Sun, 15 Jan 2023 12:54:45 +0100,
Josselin Poiret  a écrit :

> Hi Julien,
> 
> Julien Lepiller  writes:
> 
> > So, apart from the output filename which obviously changes, it seems
> > that the differences are:
> >
> > - order of dependencies,
> > - source output,
> > - builder (only because it references the source output)
> >
> > Here's the result of diffoscope on the source outputs (ignore
> > modification date, I used touch to make them all the same, not to
> > make them sensible ;)):
> >
> > [...]
> >
> > Could it be that removed files are somehow kept in cache?  
> 
> Does this still happen if you run `git clean -df` in both of your
> local checkouts?
> 
> Best,

Haha!

it seems that on one machine, my .cache/guix/checkouts got polluted by
uncommited files. I have no idea why they're there, but cleaning them
should solve my issue, thanks!

bug#60816: guix pull ("computing Guix derivation") is not reproducible

[Julien Lepiller]

Hi Guix!

I found out today that guix pull does not compute the same derivation
on two machines, with the same architecture (x86_64), using the same
initial Guix revision (4473be9) and pulling to the same commit
(c77978d).

guix-packages-base.drv seems to be the first derivation to differ. I
get:

/gnu/store/185wzzjc6dslrw1avz7cfrafrr0l7bp9-guix-packages-base.drv on
one machine and
/gnu/store/v7jvidnqxdjkhnxi846lsc91ak7ala9k-guix-packages-base.drv on
the other.

Here's the diff (I used a sed to s/,/,\n/g for the diff to be more
meaningful :)):

2c2
< "/gnu/store/866q7lb582jid68alzpd5z0cj88gpm3j-guix-packages-base",
---
> "/gnu/store/kmqhq1fa1ah7x7iz3jqfqcm4p53rln6p-guix-packages-base",
42,44c42,44
<
"/gnu/store/8wdw7l4badagdzs7pay8fj15v50p8by3-guix-packages-base-source",
< "/gnu/store/rybrv6mrbb8yihk4mdhsmnfqlq3i4rq8-module-import",
<
"/gnu/store/svssahra9ahb73knj7jq666jnhrcjk4z-guix-packages-base-builder"],
---
> "/gnu/store/8s93iwfi0kscr5911h8b4312krwywa7q-guix-packages-base-source",
> "/gnu/store/pxwsa9i2sqy96f153jcbs1m4sb8bmqs2-guix-packages-base-builder",
> "/gnu/store/rybrv6mrbb8yihk4mdhsmnfqlq3i4rq8-module-import"],
52c52
<
"/gnu/store/svssahra9ahb73knj7jq666jnhrcjk4z-guix-packages-base-builder"],
---
> "/gnu/store/pxwsa9i2sqy96f153jcbs1m4sb8bmqs2-guix-packages-base-builder"],
58c58
< "/gnu/store/866q7lb582jid68alzpd5z0cj88gpm3j-guix-packages-base")])
\ Pas de fin de ligne à la fin du fichier
---
> "/gnu/store/kmqhq1fa1ah7x7iz3jqfqcm4p53rln6p-guix-packages-base")])
\ Pas de fin de ligne à la fin du fichier


So, apart from the output filename which obviously changes, it seems
that the differences are:

- order of dependencies,
- source output,
- builder (only because it references the source output)

Here's the result of diffoscope on the source outputs (ignore
modification date, I used touch to make them all the same, not to make
them sensible ;)):

--- source1
+++ source2
│   --- source1/gnu
├── +++ source2/gnu
│ │   --- source1/gnu/packages
│ ├── +++ source2/gnu/packages
│ │ │   --- source1/gnu/packages/aux-files
│ │ ├── +++ source2/gnu/packages/aux-files
│ │ │ │   --- source1/gnu/packages/aux-files/linux-libre
│ │ │ ├── +++ source2/gnu/packages/aux-files/linux-libre
│ │ │ │ ├── file list
│ │ │ │ │ @@ -9,18 +9,14 @@
│ │ │ │ │  5.10-arm64.conf
│ │ │ │ │  5.10-i686.conf
│ │ │ │ │  5.10-x86_64.conf
│ │ │ │ │  5.15-arm.conf
│ │ │ │ │  5.15-arm64.conf
│ │ │ │ │  5.15-i686.conf
│ │ │ │ │  5.15-x86_64.conf
│ │ │ │ │ -5.18-arm.conf
│ │ │ │ │ -5.18-arm64.conf
│ │ │ │ │ -5.18-i686.conf
│ │ │ │ │ -5.18-x86_64.conf
│ │ │ │ │  5.4-arm.conf
│ │ │ │ │  5.4-arm64.conf
│ │ │ │ │  5.4-i686.conf
│ │ │ │ │  5.4-x86_64.conf
│ │ │ │ │  6.1-arm.conf
│ │ │ │ │  6.1-arm64.conf
│ │ │ │ │  6.1-i686.conf
│ │ │ │ ├──
/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/stat {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │  
│ │ │ │ │ -  Size: 766  Blocks: 0  IO Block: 4096
 directory
│ │ │ │ │ +  Size: 650  Blocks: 0  IO Block: 4096
 directory
│ │ │ │ │  Links: 1
│ │ │ │ │  Access: (0555/dr-xr-xr-x)  Uid: ( 1000/tyreunom)   Gid: (
998/   users)
│ │ │ │ │  
│ │ │ │ │  Modify: 2019-12-31 23:00:00.0 +
│ │ │ │ ├──
/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/stat {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │  
│ │ │ │ │ +  Size: 650  Blocks: 0  IO Block: 4096
 directory
│ │ │ │ │ -  Size: 766  Blocks: 0  IO Block: 4096
 directory
│ │ │ │ │  Links: 1
│ │ │ │ │  Access: (0555/dr-xr-xr-x)  Uid: ( 1000/tyreunom)   Gid: (
998/   users)
│ │ │ │ │  
│ │ │ │ │  Modify: 2019-12-31 23:00:00.0 +
│ │ │   --- source1/gnu/packages/patches
│ │ ├── +++ source2/gnu/packages/patches
│ │ │ ├── file list
│ │ │ │ @@ -136,15 +136,14 @@
│ │ │ │  classpath-aarch64-support.patch
│ │ │ │  classpath-miscompilation.patch
│ │ │ │  cling-use-shared-library.patch
│ │ │ │  clucene-contribs-lib.patch
│ │ │ │  clucene-pkgconfig.patch
│ │ │ │  cmake-curl-certificates-3.24.patch
│ │ │ │  cmake-curl-certificates.patch
│ │ │ │ -cmh-support-fplll.patch
│ │ │ │  coda-use-system-libs.patch
│ │ │ │  collectd-5.11.0-noinstallvar.patch
│ │ │ │  combinatorial-blas-awpm.patch
│ │ │ │  combinatorial-blas-io-fix.patch
│ │ │ │  connman-CVE-2022-32292.patch
│ │ │ │  connman-CVE-2022-32293-pt1.patch
│ │ │ │  connman-CVE-2022-32293-pt2.patch
│ │ │ │ @@ -216,15 +215,14 @@
│ │ │ │  emacs-source-date-epoch.patch
│ │ │ │  emacs-telega-path-placeholder.patch
│ │ │ │  emacs-telega-test-env.patch
│ │ │ │  emacs-wordnut-require-adaptive-wrap.patch
│ │ │ │  emacs-yasnippet-fix-tests.patch
│ │ │ │  enjarify-setup-py.patch
│ │ │ │  enlightenment-fix-setuid-path.patch
│ │ │ │ -eog-update-libportal-usage.patch
│ │ │ │  erlang-man-path.patch
│ │ │ │  esmtp-add-lesmtp.patch
│ │ │ │  eudev-rules-directory.patch
│ │ │ │  exercism-disable-self-update.patch
│ │ │ │  extempore-unbundle-external-dependencies.patch
│ │ │ │  extundelete-e2fsprogs-1.44.patch
│ │ │ │  fail2ban-0.11.2_CVE-2021-32749.patch
│ 

bug#59940: Report of output

[Julien Lepiller]

Hi Derwin,

The report looks like a network failure, so maybe try again?

Le 10 décembre 2022 09:30:33 GMT+01:00, Derwin McGeary 
 a écrit :
>Hi!
>
>The output of guix pull suggested sending the output here, so here I am.
>
>Context: running guix as user with a foreign distro (Ubuntu 22.10),
>directly previous to running it I had run guix gc. Previously no issues.
>
>Happy to help with any other information but I don't know what else would
>help.
>
>Regards,
>Derwin

bug#59521: package installation fail when home dir contains a @

[Julien Lepiller]

Oh no, do we have a Texi injection vulnerability in Guix? :)

What I understand is that an error occurs when trying to show a hint to the 
user (display-hint in the backtrace). This calls texi->plain-text which 
transforms texinfo markup to text for displaying on a terminal. With your user 
name, it tries to read something like:

/home/~a/.guix-profile/etc/profile

Which is expanded into:

/home/u...@foo.bar/.guix-profile/etc/profile

And the @ is understood as texinfo markup but there is no @foo command in 
texinfo. How do we fix that though?

Le 23 novembre 2022 13:46:30 GMT+01:00, pof...@free.fr a écrit :
>Hello!
>
>I use the guix package manager on ubuntu 22.04.
>
>I have successfully installed fdm and mu packages but I got an error when 
>installing emacs package.
>
>My user is a domain user, the domain name is 'foo.bar' and then sssd use a 
>home directory like '/home/u...@foo.bar' which seems to cause that error.
>
>Installation log:
>$ LANG=C guix install emacs
>The following package will be installed:
>   emacs 28.2
>
>hint: Backtrace:
>  17 (primitive-load "/home/u...@foo.bar/.config/guix?")
>In guix/ui.scm:
>   2275:7 16 (run-guix . _)
>  2238:10 15 (run-guix-command _ . _)
>In ice-9/boot-9.scm:
>  1752:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>In guix/status.scm:
>835:3 13 (_)
>815:4 12 (call-with-status-report _ _)
>In guix/store.scm:
>   1300:8 11 (call-with-build-handler _ _)
>   1300:8 10 (call-with-build-handler # ?)
>In guix/build/syscalls.scm:
>   1435:3  9 (_)
>   1402:4  8 (call-with-file-lock/no-wait _ _ _)
>In guix/scripts/package.scm:
>325:7  7 (build-and-use-profile _ "/var/guix/profiles/per-user/?" ?)
>In guix/ui.scm:
>312:5  6 (display-hint _ _)
>  1448:24  5 (texi->plain-text _)
>In texinfo.scm:
>  1132:22  4 (parse _)
>   980:31  3 (loop # (*fragment*) _ _ _)
>   967:36  2 (loop # #f # ?)
> 92:2  1 (command-spec _)
>In ice-9/boot-9.scm:
>  1685:16  0 (raise-exception _ #:continuable? _)
>
>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>Throw to key `parser-error' with args `(#f "Unknown command" foo)'.
>
>
>

bug#59485: 'guix system list-generations' identifies wrong generation as current

[Julien Lepiller]

Current system generation identifies the one that would boot by default. 
Basically, booted ≠ current. Maybe guix system could show that information.

Le 22 novembre 2022 18:06:19 GMT+01:00, Felix Lechner via Bug reports for GNU 
Guix  a écrit :
>Hi,
>
>On my equipment the command 'guix system list-generations' identifies
>the most recent system generation as "(current)" even though I booted
>a different, past generation via Grub.
>
>The information is most certainly wrong because my latest generation
>does not boot successfully.
>
>I don't know if it matters, but I used 'guix deploy' on my local system.
>
>Kind regards,
>Felix Lechner
>
>
>

bug#59278: how gcc-toolchain can depends a package who doesn't exists?

[Julien Lepiller]

Hi,

This is not a bug. The gcc package exists, but is hidden from CLI on purpose 
because you shouldn't install it and use it directly. You should use 
gcc-toolchain instead.

Le 15 novembre 2022 00:53:32 GMT+01:00, bbb ee  a écrit :
>in version c81457a5883ea43950eb2ecdcbb58a5b144bcd11 of guix, gcc-toolchain
>depends gcc:
>```
>$ DEFAULT_CHANNELS=/tmp/default_channels.scm
>$ echo "%default-channels" > $DEFAULT_CHANNELS
># I force guix to use only %default-channels here
>$ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11  -C
>$DEFAULT_CHANNELS -- search gcc-toolchain
>guile: warning: failed to install locale
>name: gcc-toolchain
>version: 9.3.0
>outputs: out debug static
>systems: x86_64-linux i686-linux
>dependencies: binutils@2.32 gcc@9.3.0 glibc@2.29 ld-wrapper@0
>```
>
>
>However, I can't find gcc package in this version of guix
>```
>$ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11  -C
>$DEFAULT_CHANNELS -- search gcc
># no found gcc
>
># guix install failure message confirm that gcc doesn't exist in commit
>c81457
>$ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11 -C
>$DEFAULT_CHANNELS -- install gcc -p ~/opt/python-dev_3_7
>guile: warning: failed to install locale
>guix install: error: gcc: unknown package
>```
>
>in commit c81457, how gcc-toolchain can depends a package who doesn't
>exists?

bug#59205: ‘guix help’ output is partly untranslated

[Julien Lepiller]

Saluton!

The pot generation process for translations at weblate is separate from
the one for Guix. The pot in Guix is outdated and not updated
automatically.

It seems that the rules for generating the pot changed in Guix, but I
don't use them for generating the pot files in the translation repo.
That is because I don't want to run configure, make and risk something
breaking because of an ABI change, just for translations. I updated the
generation process and ran an update. The pot file in the translation
repo now has the missing strings and they should appear at weblate in a
few hours if all goes well :)

Le Fri, 11 Nov 2022 23:24:56 +0100,
Ludovic Courtès  a écrit :

> Saluton!
> 
> The output of ‘guix help’ is partly untranslated:
> 
> --8<---cut here---start->8---
> $ LC_ALL=fr_FR.utf8 guix help | head -20
> Utilisation : guix OPTION | COMMANDE ARGS...
> Lance la COMMANDE avec les arguments ARGS, le cas échéant.
> 
>   -h, --help afficher de nouveau ce texte d'aide et
> quitter -V, --version  afficher les informations sur la
> version les droits d'auteur et quitter
> 
> COMMANDE doit être une des sous-commandes listées ci-dessous :
> 
>   commandes principales
> deploydeploy operating systems on a set of machines
> describe  describe the channel revisions currently used
> gcinvoke the garbage collector
> home  build and deploy home environments
> install   install packages
> package   manage packages and profiles
> pull  pull the latest revision of Guix
> removeremove installed packages
> searchsearch for packages
> show  show information about packages
> systembuild and deploy full operating systems
> --8<---cut here---end--->8---
> 
> The synopses that appear in ‘define-command’ forms are left
> untranslated.  They are in ‘guix.pot’ but are missing from PO files.
> 
> Any idea?
> 
> Thanks,
> Ludo’.
> 
> 

bug#58783: Strange booting/reproducibility issue

[Julien Lepiller]

continue. GNU Guile 3.0.7
Copyright (C) 1995-2021 Free Software Foundation, Inc.

That sounds weird, I would expect our guile to be more recent than that. The 
manual suggests using "sudo guix system" instead of "sudo -E guix system", 
maybe that's the issue?

Le 26 octobre 2022 00:43:03 GMT+02:00, Denis 'GNUtoo' Carikli 
 a écrit :
>Hi,
>
>On an i686 computer[1], I've a Guix installation on an HDD, and if I do
>> guix pull -M 1 -c 1
>and that I then do
>> sudo -E guix system reconfigure -M 1 -c 1 system.scm
>
>I get the following boot failure[2]:
>> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for
>> main thread GC Warning: Couldn't read /proc/stat
>> Welcome, this is GNU's early boot Guile.
>> Use 'gnu.repl' for an initrd REPL.
>> 
>> loading kernel modules...
>> Enter passphrase for /dev/sda2: 
>> /dev/mapper/cryptroot: recovering journal
>> /dev/mapper/cryptroot: clean, 702176/9773056 files, 8418369/39071232
>> blocks ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> In procedure mkdir: File exists
>> 
>> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to
>> continue. GNU Guile 3.0.7
>> Copyright (C) 1995-2021 Free Software Foundation, Inc.
>> 
>> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>> This program is free software, and you are welcome to redistribute it
>> under certain conditions; type `,show c' for details.
>> 
>> Enter `,help' for help.
>> scheme@(guile-user)> 
>
>If I use the same system.scm (attached) and that I produce an image
>with the build_init.sh script (attached) which setups an encrypted
>partition and uses guix system init, and that I then copy the resulting
>image to an USB drive with ddrescue, It then boots fine.
>
>Since the system ends up not booting anymore when I try to guix pull
>and guix system reconfigure the system on the HDD, to boot I simply
>select a known booting old revision in the grub menu, so I can easily
>test things.
>
>Though I'm not sure where to look. Is there anything I can do to get
>more contexts or logs? Should I try loglevel=8 ?
>
>References:
>---
>[1] The computer is a Thinkpad X60 with only an external display running
>Coreboot with SeaBIOS.
>[2] The boot log was captured by adding console=ttyS0,115200 to the
>command line arguments in grub and by capturing the messages
>through a serial port.
>
>Denis.

bug#58591: Java packages do not appear to keep a reference to their inputs

[Julien Lepiller]

Hi, replying to a few emails at once.

The ant-build-system uses zip -0 to produce an uncompressed archive. By 
default, jar produces a compressed one, so there's a repack phase for that:
 
http://git.savannah.nongnu.org/cgit/guix.git/tree/guix/build/ant-build-system.scm#n226

Embedding the classpath in the manifest is possible but would not have the 
expected effect. That's because a line in the manifest cannot exceed 72 bytes 
(see "line length" in 
https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Notes_on_Manifest_and_Signature_Files),
 so the classpath will look like:

Class-Path: ../../../1234567891011
 1213141516/share/java/foo.jar

Although java would read that fine, the grafter will not see it, nor be able to 
graft foo in a meaningful manner: java would still use the ungrafted version 
even if another file references foo.

Le 18 octobre 2022 16:56:01 GMT+02:00, Maxim Cournoyer 
 a écrit :
>Hello,
>
>Maxim Cournoyer  writes:
>
>> Tobias Geerinckx-Rice  writes:
>
>[...]
>
>>> Groan.  Which package(s) compress .jars?
>>
>> Oh, aren't they all?  I hadn't realized .jar compression was optional.
>
>Actually, reading [0] again, it seems a JAR *is* a zip archive, so
>cannot be either compressed or uncompressed.
>
>[0]  https://docs.oracle.com/en/java/javase/19/docs/specs/jar/jar.html
>
>-- 
>Thanks,
>Maxim

bug#58591: Java packages do not appear to keep a reference to their inputs

[Julien Lepiller]

You're right, java package don't retain references to there input, that's why 
we propagate required dependencies (mh… sometimes). I don't know how they could 
reference dependencies directly.

Le 17 octobre 2022 23:04:47 GMT+02:00, Maxim Cournoyer 
 a écrit :
>Hello,
>
>I'm not a Java expert, but this appears to me problematic:
>
>--8<---cut here---start->8---
>$ guix build java-commons-dbcp
>/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0
>
>$ guix gc -R 
>/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0
>/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0
>--8<---cut here---end--->8---
>
>Digging a bit more, peeking into the .jar file, which is a ZIP archive:
>
>--8<---cut here---start->8---
>$ unzip /gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0/\
>share/java/java-commons-dbcp.jar -d /tmp/java-commons-dbcp.jar
>
>$ grep -rin CLASSPATH /tmp/java-commons-dbcp.jar
>$ grep -rin /gnu/store /tmp/java-commons-dbcp.jar
>/tmp/java-commons-dbcp.jar/META-INF/INDEX.LIST:3:/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0/share/java/java-commons-dbcp.jar
>
>$ cat /tmp/java-commons-dbcp.jar/META-INF/INDEX.LIST
>JarIndex-Version: 1.0
>
>/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0/share/java/java-commons-dbcp.jar
>org
>org/apache
>org/apache/commons
>org/apache/commons/dbcp2
>org/apache/commons/dbcp2/cpdsadapter
>org/apache/commons/dbcp2/datasources
>org/apache/commons/dbcp2/managed
>--8<---cut here---end--->8---
>
>Still, no traces of the other libraries such as 'java-commons-pool'
>which should be referenced.
>
>I assume this means grafts doesn't currently work for Java libraries.
>
>-- 
>Thanks,
>Maxim
>
>
>

bug#58571: translations are incompletely pulled from weblate

[Julien Lepiller]

One thing I suspect is that weblate takes quite a lot of time to pull changes 
from the intermediate repository, so if you provide a translation while the 
repo is being synced, I think they might be reset when the file is finally 
loaded by weblate.

Not sure if this could explain this many ignored translations though…

For anyone in that situation, the translations are not lost. You can always go 
back to them and you'll see they are untranslated, but you'll see a red box on 
the right saying it's already translated. If the text is correct, you can click 
"fix string" to apply the translation.

Le 17 octobre 2022 19:12:24 GMT+02:00, "pelzflorian (Florian Pelz)" 
 a écrit :
>two--- via Bug reports for GNU Guix  writes:
>> hi
>> in https://git.savannah.gnu.org/cgit/guix.git/tree/po/guix/uk.po i see
>> kyrylo's translations are pulled there from weblate, but mine
>> (https://translate.fedoraproject.org/changes/?project=guix&lang=uk&user=two22)
>> are not, these strings stay untranslated or erroneous.
>
>This is strange and I do not yet see what could be the cause.
>
>Weblate is backed not by savannah but by an intermediate repository
>https://framagit.org/tyreunom/guix-translations
>which Julien regularly syncs with Savannah each month.
>
>Perhaps could you try changing a translation on Weblate and see if there
>is a change to ?  It
>will sync faster if after you make the change on Weblate, you use
>Weblate’s File download button.
>
>Regards,
>Florian
>
>
>

bug#58497: opam import doesn't work with ocaml_intrinsics among others

[Julien Lepiller]

(beautify-description #f _)

Seems to be the cause. Yet, there is a description. Maybe parsing ends a bit 
too soon?

Le 13 octobre 2022 18:07:08 GMT+02:00, Csepp  a écrit :
>The error might not be the same for others, I have a slightly patched
>opam->guix-package function.
>
>guix import opam ocaml_intrinsics
>Backtrace:
>In ice-9/boot-9.scm:
>  1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
>In unknown file:
>   9 (apply-smob/0 #)
>In ice-9/boot-9.scm:
>724:2  8 (call-with-prompt _ _ #)
>In ice-9/eval.scm:
>619:8  7 (_ #(#(#)))
>In guix/ui.scm:
>   2263:7  6 (run-guix . _)
>  2226:10  5 (run-guix-command _ . _)
>In guix/scripts/import.scm:
>92:11  4 (guix-import . _)
>In guix/scripts/import/opam.scm:
>   105:24  3 (guix-import-opam . _)
>In guix/import/opam.scm:
>   385:24  2 (opam->guix-package _ #:repo _ #:version _)
>In guix/import/utils.scm:
>   290:27  1 (beautify-description #f _)
>In unknown file:
>   0 (string-trim-both #f # # #)
>
>ERROR: In procedure string-trim-both:
>In procedure string-trim-both: Wrong type argument in position 1 (expecting 
>string): #f
>
>
>

bug#58495: opam import generates wrong check phase

[Julien Lepiller]

Maybe this could be fixed in the dune-build-system?

Le 13 octobre 2022 17:03:43 GMT+02:00, Csepp  a écrit :
>So I'm working on building MirageOS unikernels with Guix, which means
>using the OPAM importer *a lot*, which unearths some very Fun TM bugs.
>Here is the first one:
>
>guix import opam mirage-clock
>
>The correct check phase is this:
>```
>(replace 'check
>   (lambda* (#:key tests? #:allow-other-keys)
> (invoke "dune" "runtest" "--release")))
>```
>
>
>

bug#58483: perl-gtk3 blocking widget

[Julien Lepiller]

Hi Guix!

I was trying to use a perl software that uses gtk3. Its main window
does not show up and it seems to get stuck. I tried to come up with a
reproducer. In guix shell perl perl-gtk3:

```
#!/usr/bin/env perl

use strict;
use warnings;
use diagnostics;
use feature ':5.14';
use Gtk3 '-init';
use Glib qw/TRUE FALSE/;

my $window = Gtk3::Window->new('toplevel');
$window->set_title("Basic Check Boxes");
$window->set_position("mouse");
$window->set_default_size(400, 200);
$window->set_border_width(5);
$window->signal_connect (delete_event => sub { Gtk3->main_quit });

my $vbox = Gtk3::Box->new("vertical", 5);
$window->add($vbox);

say "hello";

my $entry = Gtk3::Entry->new;

say "hello again";

Gtk3->main;
```

says "hello" but gets stuck when creating the entry. I get some error
messages, but it doesn't prevent perl-gtk3 from showing relatively
complex windows: I get the same errors with a script like, but the
window is properly shown:

https://github.com/kevinphilp/Perl-gtk3-Tutorial/blob/master/5a-Fun-with-labels.pl

any perl expert around? :)

bug#58375: Installer does not show what is being downloaded

[Julien Lepiller]

I installed Guix on a new drive, so I tried the installer from the latest 
image. After reviewing the system config, the installer goes to a black screen 
where guix output is shown. Although I can see messages about substitutes being 
updated, and how much will be downloaded, all download lines are replaced with 
a seemingly random number of dots:

substitute: mise à jour des substituts depuis «…»... 100.0 %
4.5 Mo seront téléchargés.
.
...
.
.
..

Maybe this is related to the translation?

bug#58333: Manual PDFs other than en and es fail to build

[Julien Lepiller]

You can push this fix directly to the repo, but please also fix it on weblate 
or it'll break again next time I update translations.

Le 7 octobre 2022 08:34:51 GMT+02:00, Ricardo Wurmus  a 
écrit :
>
>Ricardo Wurmus  writes:
>
>> The error in guix.de.texi is an infinite loop.  The location it points
>> out is wrong syntax:
>>
>> @uref{@uref{https://webssh.huashengdun.org/, WebSSH}}
>>
>> There shouldn’t be a double-wrapping in @uref.
>
>I can confirm that fixing the bad translation in
>po/doc/guix-manual.de.po allows us to build the German version of the
>PDF manual.
>
>-- 
>Ricardo
>
>
>

bug#58112: OPAM importer fails in lookup-node

[Julien Lepiller]

It's probably because other importers are structured that way. I'd be in favor 
of changing that and using the condition system.

Le 27 septembre 2022 13:33:56 GMT+02:00, Csepp  a écrit :
>The specific error is this:
>Wrong number of values returned to continuation (expected 2)
>It is caused by opam->guix-package silencing intermediate errors by
>using and-let* (the poor person's Maybe monad) and returning #f when the
>receiving side expects two return values.
>
>Initial reproducer:
>guix import opam -r mirage
>
>Also happens with opam-monorepo.
>
>Cc-ing Julien whom might know why the code is structured this way?  It's
>not like the calling side can handle a falsy return and the error is not
>detected early either, so the user doesn't even know what is causing it.
>Can I just turn it all into errors?  Or maybe we can use the condition
>system?
>

bug#57749: [patch] maven: fix build with java-slf4j-simple-source expanded

[Julien Lepiller]

Le Thu, 22 Sep 2022 10:19:16 +0200,
Rostislav Svoboda  a écrit :

> It seems like this issue has been resolved by the
> 79897a37012a9bfbcb460cfe0aaaf32aab79dbe5 if so then please close this
> issue.
> 
> Thanks
> 
> 
> 

Ah indeed, a similar patch was sent independently and pushed before
this. I was hoping another commiter would have pushed this patch, but
in the end maven-slf4j-provider was fixed :)

Closing this since it's no longer relevant. Thanks again!

bug#57749: [patch] maven: fix build with java-slf4j-simple-source expanded

[Julien Lepiller]

I don't think checking for file-exists before mkdir-p makes much sense. Doesn't 
mkdir-p make the same checks already?

I thought find-files required two arguments? Also the first argument could be 
simplified to input-folder

Otherwise LGTM, but I can't push myself currently. Thanks!

Le 12 septembre 2022 14:33:04 GMT+02:00, "Dr. Arne Babenhauserheide" 
 a écrit :
>Hi,
>
>Maven failed to build for me, because java-slf4j-simple-source is no
>longer a tarball, but an expanded directory of files.
>
>Copying the files from Scheme makes it build. A patch is attached.
>
>

bug#57581: Failing to build the website

[Julien Lepiller]

Le 7 septembre 2022 19:07:10 GMT+02:00, zimoun  a 
écrit :
>Hi,
>
>Well, the field reads,
>
>+(license (package-home-page qtbase
>
>so why is the compiler accepting that?  Is a warning raised?
>

No warning because the compiler has no way to know you don't want to do that. 
license is a field, and fields don't have a specific type except for convention.

package-home-page will read a field from another object, return a perfectly 
valid Scgeme object (a string) and Scheme is happy to put it in the license 
field. Why would it care? (:

It fails much later when something tries to read the license field and gets a 
string it treats as a license object.

bug#57581: Failing to build the website

[Julien Lepiller]

Quoting my own email I think this is the relevant bit. I don't think it's an 
issue in haunt, but something with qt:

srfi/srfi-1.scm:241:2: In procedure map:
In procedure map: Wrong type argument: "https://www.qt.io/";
building pages in '/tmp/gnu.org/software/guix'...

Le 5 septembre 2022 14:04:10 GMT+02:00, zimoun  a 
écrit :
>Hi,
>
>On lun., 05 sept. 2022 at 12:59, "pelzflorian (Florian Pelz)" 
> wrote:
>> zimoun  writes:
>>> $ LANG=en_US.UTF-8 GUIX_WEB_SITE_LOCAL=yes guix environment -C -m 
>>> manifest.scm \
>>>   -E LANG -E GUIX_WEB_SITE_LOCAL  --share=/tmp  
>>>\
>>>   -- haunt build
>>
>> Yes but `guix build -f .guix.scm` fails for me too, perhaps because it
>> uses latest-guix from %default-channels.  It’s not fixed by using old
>> haunt, so I guess a change in guix makes the difference, but I have not
>> found the commit and will not continue looking for it immediately.
>
>The file manifest.scm contains:
>
>--8<---cut here---start->8---
>(define the-good-guile
>  (car (assoc-ref (package-native-inputs guix) "guile")))
>
>(define haunt-the-ghost
>  (package
>(inherit haunt)
>(name "haunt-for-guix-website")
>(inputs
> `(("guile" ,the-good-guile)
>   ,@(alist-delete "guile" (package-inputs haunt))
>--8<---cut here---end--->8---
>
>and the file .guix.scm contains
>
>--8<---cut here---start->8---
>(define latest-guix
>  ;; The latest Guix.  Using it rather than the 'guix' package ensures we
>  ;; build the latest package list.
>  (latest-channels %default-channels))
>
>(define (inferior-package spec)
>  (first (lookup-inferior-packages
>  (inferior-for-channels
>   (latest-channels-channels latest-guix))
>  spec)))
>
>;; Make sure that Haunt uses the same Guile as the one from
>;; "latest-guix". Otherwise there could be a mismatch between the Guile
>;; revision used by Haunt and the one from the latest Guix modules used by
>;; Haunt.
>(define haunt-with-latest-guile
>  (package
>(inherit haunt)
>(inputs
> `(("guile" ,(inferior-package "guile"))
>   ,@(package-inputs haunt)
>--8<---cut here---end--->8---
>
>so it should be the same Haunt.  I mean, there is no gap between the
>version of Guile of latest-guix and the package guix.  But, I am missing
>something because the failure comes from:
>
>--8<---cut here---start->8---
>(invoke #+(file-append haunt-with-latest-guile
>   "/bin/haunt")
>   "build")
>--8<---cut here---end--->8---
>
>It requires some investigations. :-)
>
>
>Cheers,
>simon

bug#57581: Failing to build the website

[Julien Lepiller]

I used guix build -f .guix.scm. I'm on the latest guix-artwork but an older 
guix from maybe a month ago. GUIX_WEB_SITE_LOCAL doesn't build everything, only 
a subset of packages end up in the generated list. I think my issue is with qt, 
which probably isn't part of that subset.

Le 5 septembre 2022 10:35:43 GMT+02:00, zimoun  a 
écrit :
>Hi Julien
>
>On dim., 04 sept. 2022 at 17:18, Julien Lepiller  wrote:
>
>> I tried to update the po files for the website today, but I was unable
>> to test. Trying to build the website from a clean checkout (without
>> updating translations) gives this error. I think it's related to the
>> code that generate the list of packages:
>
>Which revision of Guix do you use?  And which commit of guix-artwork?
>
>And how do you build the website?  It works for me with this procedure.
>
>--8<---cut here---start->8---
>$ git clone https://git.savannah.gnu.org/git/guix/guix-artwork.git
>Cloning into 'guix-artwork'...
>remote: Counting objects: 7281, done.
>remote: Compressing objects: 100% (2121/2121), done.
>remote: Total 7281 (delta 5043), reused 7273 (delta 5041)
>Receiving objects: 100% (7281/7281), 33.99 MiB | 17.80 MiB/s, done.
>Resolving deltas: 100% (5043/5043), done.
>
>$ builtin cd guix-artwork/website
>
>$ guix describe
>Generation 9   août 31 2022 14:51:40   (current)
>  guix 23152ff
>repository URL: https://git.savannah.gnu.org/git/guix.git
>branch: master
>commit: 23152ff70f0ed4966d8207846f54c793d7cb4f86
>
>$ git log --oneline -1
>ebc4a77 (HEAD -> master, origin/master, origin/HEAD) promotional: New 
>retractable banner designs.
>
>$ LANG=en_US.UTF-8 GUIX_WEB_SITE_LOCAL=yes guix environment -C -m manifest.scm 
>\
>  -E LANG -E GUIX_WEB_SITE_LOCAL  --share=/tmp 
> \
>  -- haunt build
>
>> > building pages in '/tmp/gnu.org/software/guix'...
>fatal: not a git repository (or any parent up to mount point /gnu/store)
>Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
>warning: page objects are deprecated; switch to serialized-artifact
>
>[...]
>
>build completed successfully
>--8<---cut here---end--->8---
>
>
>
>Cheers,
>simon

bug#57585: guix gc removed home config

[Julien Lepiller]

Actually I figured this out:

Generation 16 used an older guix version where guix home added a . at
the end of file names, so my config looked like this:

(simple-service 'xfce4-terminal home-files-service-type   
  `(("config/xfce4/terminal/terminalrc"
,(local-file
  "files/xfce4-terminal/terminalrc"

Then, I updated Guix without changing my home configuration, so on
generation 17, guix home created $HOME/config instead of $HOME/.config.
So $HOME/.config/xfce4/terminal/terminalrc (and all other config files)
kept pointing to generation 16's files. After removing the generation
and "guix gc", these files no longer exist, and I'm in trouble :)

So, guix home and guix gc are working as intended, but the change to no
longer adding a "." at the beginning of file names (which makes total
sense) tripped me up.

Le Sun, 4 Sep 2022 20:32:58 +0200,
Julien Lepiller  a écrit :

> Hi Guix!
> 
> Today I ran "guix home delete-generations" to remove my old home
> generations. It removed generations 0 and 17. I'm on generation 18.
> 
> Then I ran "guix gc" and after I noticed I couldn't run a program from
> my window manager (its menu is managed from guix home), I tried to
> look at what was happening. My config files managed by guix home are
> now symlinks that point to non existent store items. Spooky.
> 
> Please let me know how I can help diagnose the issue
> 
> 
> 

bug#57585: guix gc removed home config

[Julien Lepiller]

Hi Guix!

Today I ran "guix home delete-generations" to remove my old home
generations. It removed generations 0 and 17. I'm on generation 18.

Then I ran "guix gc" and after I noticed I couldn't run a program from
my window manager (its menu is managed from guix home), I tried to look
at what was happening. My config files managed by guix home are now
symlinks that point to non existent store items. Spooky.

Please let me know how I can help diagnose the issue

bug#57581: Failing to build the website

[Julien Lepiller]

Hi Guix!

I tried to update the po files for the website today, but I was unable
to test. Trying to build the website from a clean checkout (without
updating translations) gives this error. I think it's related to the
code that generate the list of packages:

Backtrace:
In ice-9/eval.scm:
   177:49 19 (lp (# …))
   177:49 18 (lp (# …))
   177:49 17 (lp (# …))
   177:49 16 (lp (# …))
   177:49 15 (lp (# …))
   177:49 14 (lp (# …))
   177:49 13 (lp (# …))
   177:49 12 (lp (# …))
   177:32 11 (lp (#))
159:9 10 (_ #(#(#(#(#(#) …) …) …) …))
   174:20  9 (_ #(#(#(#(#(#) …) …) …) …))
   177:49  8 (lp (# …))
   177:32  7 (lp (# …))
   174:20  6 (_ #(#(#(#(#(#) …) …) …) …))
   177:32  5 (lp (# …))
   174:20  4 (_ #(#(#(#(#(#) …) …) …) …))
   177:49  3 (lp (# …))
   177:32  2 (lp (#))
159:9  1 (_ #(#(#) …))
In srfi/srfi-1.scm:
241:2  0 (map _ _)

srfi/srfi-1.scm:241:2: In procedure map:
In procedure map: Wrong type argument: "https://www.qt.io/";
building pages in '/tmp/gnu.org/software/guix'...
Backtrace:
   2 (primitive-load "/gnu/store/qr419pk9hdvg692rkhdlyvr9zh0?")
In ice-9/eval.scm:
619:8  1 (_ #f)
In guix/build/utils.scm:
762:6  0 (invoke "/gnu/store/bgh62naj3w2367h46zv2waq26rs3aspp-h?" ?)

guix/build/utils.scm:762:6: In procedure invoke:
ERROR:
  1. &invoke-error:
  program:
"/gnu/store/bgh62naj3w2367h46zv2waq26rs3aspp-haunt-0.2.6/bin/haunt"
arguments: ("build") exit-status: 1
  term-signal: #f
  stop-signal: #f
builder for
`/gnu/store/sh3ihg22yr1s0cdfjqpsv5hqrfmvg646-guix-web-site-de_DE.drv'
failed with exit code 1 la compilation de
/gnu/store/sh3ihg22yr1s0cdfjqpsv5hqrfmvg646-guix-web-site-de_DE.drv a
échoué

bug#57480: Wrong Type To Apply on Reconfigure

[Julien Lepiller]

I don't know how to fix it, but here is what I think is the issue:

in guix/scripts/system/reconfigure.scm:

#:autoload   (guix describe) (current-channels)
...
(define* (check-forward-update ...
   (current-channels ...))
  (define new (current-channels)) ; this is supposed to be the
 ; autoloaded procedure, but it's the keyword argument
 ; which is a list
  ... ; uses of current-channels, the keyword argument

Le Mon, 29 Aug 2022 23:01:46 -0400,
Christopher Rodriguez  a écrit :

> Hello All,
> 
> A change made in b084398 is preventing both my system and home
> configurations from building with a Wrong Type to Apply error. Did the
> channel spec format change with the changes in that commit?
> 
> Here's my channels.scm: https://paste.debian.net/1252097/
> 
> And here's the error message for any commit after b084398:
> https://paste.debian.net/1252096/
> 
> 
> --
> 
> Christopher Rodriguez

bug#56030: The guix pull profile is too big

[Julien Lepiller]

I must have misunderstood, I thought you wanted to pass it during the build of 
glibc.

Le 21 juillet 2022 17:49:36 GMT+02:00, "("  a écrit :
>On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
>> Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But 
>> it's not 'just use -DSHELL_PATH=', we still need to change 'system' 
>> appropriately.
>Why would we need to change it? The glibc definition already uses that
>macro for the shell path, it's just hard-coded to /bin/sh by default.

bug#56030: The guix pull profile is too big

[Julien Lepiller]

We're trying to avoid hard-coding bash-static in glibc, instead letting the 
build-system fill the value in dependents. So that can't be it, right?

Le 21 juillet 2022 17:11:56 GMT+02:00, "("  a écrit :
>
>And considering the definition of system(3) in glibc:
>
>@ sysdeps/posix/system.c (took me way too long to find this; glibc's
>source code is a maze ;))
>```
>#define SHELL_PATH "/bin/sh"   /* Path of the shell.  */
>#define SHELL_NAME "sh"/* Name to give it.  */
>```
>
>couldn't we just use `-DSHELL_PATH=/gnu/store/...`?
>
>-- (

bug#56582: Installer does not detect or allow detection of other bootable partitions

[Julien Lepiller]

If anything, you also need to chainload to boot on haiku, which is free 
software. So no reason not to implement it.

Le 16 juillet 2022 11:59:29 GMT+02:00, Josselin Poiret  a 
écrit :
>Hello both of you,
>
>Julien Lepiller  writes:
>> Of course this is only a workaround I'm proposing, we should fix the 
>> installer to detect other OSs.
>Just adding that we don't have any Guix bootloader entry field to
>chainload into another bootloader, needed for some non-free system :)
>this would need to be added as well.
>
>I personally don't mind, and use my UEFI boot menu instead if I want to
>boot into said non-free OS.
>
>Best,
>-- 
>Josselin Poiret

bug#56582: Installer does not detect or allow detection of other bootable partitions

[Julien Lepiller]

Hi Peter,

This is indeed not nice. Guix does not provide a useful package that would 
reinstall boot configuratipn because boot configuration is managed together 
with the rest of the system configuration.

You need to update your /etc/config.scm to declare more entries, and 
reconfigure. Here are the relevant chapters in the manual:

https://guix.gnu.org/manual/devel/en/html_node/Bootloader-Configuration.html 
(in particular, see menu-entry)

https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-system.html (see 
reconfigure)

Of course this is only a workaround I'm proposing, we should fix the installer 
to detect other OSs.

HTH!

Le 15 juillet 2022 22:10:46 GMT+02:00, Peter  a écrit :
>Hi,
>
>This is a particularly AWFUL user experience bug. Installing GUIX to a
>partition only lists GUIX in the grub boot menu afterward despite the
>existence of other bootable OSes on the drive.
>
>Ok fine thinks I, I will just need to manually run grub's mkconfig to force
>re-detection. But this command does not exist in GUIX. Installing grub did
>not create grub2-mkconfig. Installing osprober wasn't helpful.
>
>I did not see documentation on how to make GUIX detect and add other
>operating systems to the boot menu from userland. After much time wasted, I
>needed to download another distro, install it so it would repair the boot
>menu, and then be able to boot into my main partition.
>
>Recommendation:
>Installer needs to detect and add to the menu the other OSes.
>Documentation needs to show how to do it manually via a different method if
>GUIX does not include grub2-mkconfig otherwise it needs to warn upfront
>that this distro should not be used on multi-boot PCs.
>
>Best,
>Peter

bug#39813: Running Guix in a Virtual Machine - says 1 GB RAM is enough, but it isn't for guix pull

[Julien Lepiller]

I've heard that theory before. From observation on my late armhf server (two 
cores):

- it takes just below 2GB to build one of the derivations
- It doesn't swap a single byte
- whether with two or a single core, it takes roughly the same amount of memory
- substitution is nice, it doesn't require lots of memory (and then --cores is 
useless)

I think it's because we load all the files in a batch before we build them. The 
biggest amount of memory required is not for running the compiler on a thread, 
but for loading files and keeping them in memory for the whole duration of the 
build. With more threads, we still don't load each file more than once (twice 
to build it), so there's no reason it should take more memory.

Or maybe the process of loading and building is inherently single-threaded? I 
don't think so, but maybe?

Or it doesn't honor --cores.

Le 13 juillet 2022 18:58:58 GMT+02:00, Csepp  a écrit :
>
>Maxim Cournoyer  writes:
>
>> Hi Danny,
>>
>> Danny Milosavljevic  writes:
>>
>>> Hi,
>>>
>>> I just got a report that with Guix in a virtual Machine (like described in 
>>> the
>>> manual in 8.16), guix pull does not actually work[1] with 1 GB of RAM.
>>> It does work fine with 4 GB of RAM.
>>
>> I don't see any reference of 1 GiB being enough in our current version
>> of the manual.  If you do, please let me know.
>>
>> Closing for now.
>>
>> Thanks,
>>
>> Maxim
>
>I think it's enough if you only use a single core.
>If any guix operations goes out of memory, add --cores=1.
>So: guix pull --cores=1
>
>
>

bug#56512: gnu.org does not redirect http to https

[Julien Lepiller]

Hi Ronak,

Guix does not control the infrastructure behind the GNU project. You need to 
contact the GNU sysadmins, though I don't know how :)

Le 12 juillet 2022 02:45:38 GMT+02:00, Ronak B  a écrit :
>Hi, I noticed today when I typed "man cat" and clicked on the "http://";
>link in the man page that it did not redirect my browser from http to https.
>
>$ curl -I http://www.gnu.org/software/coreutils/
>HTTP/1.1 200 OK
>Date: Tue, 12 Jul 2022 00:42:26 GMT
>Server: Apache/2.4.29
>Content-Location: coreutils.html
>Vary: negotiate,Accept-Encoding
>TCN: choice
>Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
>X-Frame-Options: sameorigin
>X-Content-Type-Options: nosniff
>Access-Control-Allow-Origin: (null)
>Accept-Ranges: bytes
>Cache-Control: max-age=0
>Expires: Tue, 12 Jul 2022 00:42:26 GMT
>Content-Type: text/html
>Content-Language: en
>
>I also noticed this previous recent issue where this was resolved using an
>nginx redirect from port 80 to 443 for *.guix.info
>
>https://issues.guix.gnu.org/37348
>
>Could we do this for all *.gnu.org too ?
>
>After the domain and all of its subdomains are on HTTPS, then gnu.org can
>also be added to the HSTS preload list.
>
>https://hstspreload.org/
>
>Best,
>Ronak

bug#56371: Can't remove a package present in profil

[Julien Lepiller]

It's not a bug, because you don't have icedtea in your profile, but 
icedtea:jdk. Guix is picky with outputs. Try "guix remove icedtea:jdk" :)

On July 3, 2022 7:25:46 PM GMT+02:00, bbb ee  wrote:
>Hi,
>
>I have icedtea installed in my current profil, but `guix package remove`
>doesn't find it.
>```
>$ guix package -p ~/.guix-profile -I | grep icedtea
>icedtea 3.19.0   jdk
>/gnu/store/5k7lsz61p8fq37c9x5p9xalryjxk31bs-icedtea-3.19.0-jdk
>$ guix package -p ~/.guix-profile -r icedtea
>guix package: error: package 'icedtea' not found in profile
>```
>
>It is a bug?

bug#56030: The guix pull profile is too big

[Julien Lepiller]

Hi Guix!

I figured out this morning that my guix pull profile ("current") was more than 
1GB. Looking at the closure, I found a few oddities.

There's gcc in there, which is the second most important contributor after 
guix-*-modules (150 MB). It's referenced by gcc-toolchain, itself only 
referenced by the guile-wrapper we build in (guix self). Can we get rid of it?

There are three versions of guile (50 MB each). Can we settle for only one?

Then maybe less important because they're small:

There are two libffi, gzip, zlib, libgc, bash-minimal, xz, pkg-config and 
libunistring.

We have bash-minimal and bash-static. The latter is a bit bigger than the 
former. Maybe we can keep only bash-minimal?

bug#56012: guix pull fails. cannot build guix-package-cache.drv.

[Julien Lepiller]

On June 16, 2022 7:28:45 AM GMT+02:00, vi...@riseup.net wrote:
>hey all.
>
>vidak here.
>
>i cannot get `guix pull` to work for me.
>
>i am having issues getting the package-cache.drv to build.
>
>i was homeless, and unable to update my workstation for about... a
>month?
>
>here are some related issues:
>
>https://issues.guix.gnu.org/52650
>
>https://issues.guix.gnu.org/47949
>
>https://issues.guix.gnu.org/33661
>
>i can trace the output logs to this commit, which seems to be the
>offending one. 
>
>commit -- 3b50b327f7cf3226a0e37bc6afa1e921c9c075f7
>
>```
>~ $ cat
>/var/log/guix/drvs/zk/1hgixlv3gccgbriad7nr2xyla8bbzx-guix-package-cache.drv
>(repl-version 0 1 1)
>Generating package cache for
>'/gnu/store/1mzdd7rf9r34xiibcs1gpjsf7jkh6a0r-profile'...
>(exception unbound-variable (value #f) (value "Unbound variable: ~S")
>(value (libpng-1.2)) (value #f))
>```
>
>i can `guix pull --commit` to before 31-05-2022, but i cannot seem to
>pull to anything later than that date.
>
>can anyone help me?
>
>thanks so much in advance.
>
>~vidak
>
>https://zoinks.one/vidak
>
>
>

This is most likely because one of the channels you're using is still refering 
to libpng-1.2, but it was removed from guix recertly.

bug#53165: "guix import opam coq-of-ocaml" unexpected error

[Julien Lepiller]

Since then, this has been fixed:

guix import opam coq-of-ocaml
...
(description
   "This package lacks a description.  Run \"info '(guix) Synopses and
Descriptions'\" for more information.")
...

So, closing :)

bug#55776: maven-core fails to build

[Julien Lepiller]

Le Sat, 04 Jun 2022 17:00:15 +0200,
"Dr. Arne Babenhauserheide"  a écrit :

> Julien Lepiller  writes:
> > What I did instead is, since jdom wants to set more features than
> > supported in the driver, to add dummy support for all these
> > additional features by just not throwing the exception. It's not
> > very satisfying, but it works and we don't keep a vulnerable jdom
> > around. With the attached patch, I built up to maven.  
> 
> Thank you!
> 
> The patch looks clear enough — will you push it?
> 
> Best wishes,
> Arne

Pushed to master as f0d9248267dabd2feb5c004d6e4610cbdf3e5b87, thanks
for testing it :)

bug#55776: maven-core fails to build

[Julien Lepiller]

Le Sat, 04 Jun 2022 12:25:21 +0200,
Remco van 't Veer  a écrit :

> I did some digging and found this regression is caused by commit:
> 
>  6068b83b82475566acd4162467bcf54270f338f9
>  "gnu: java-jdom: Update to 2.0.6.1 [fixes CVE-2021-33813]."
> 
> Apparently the fix for this issue causes jdom to be very strict;
> 
> > java.io.IOException: Invalid input descriptor for merge:
> > /tmp/plexus-metadata3957336728290309540xml -->
> > http://xml.org/sax/features/external-general-entities feature
> > http://xml.org/sax/features/external-general-entities not supported
> > for SAX driver org.codehaus.plexus.metadata.merge.Driver  
> 
> Which sound familiar when looking at that CVE
> (https://github.com/advisories/GHSA-2363-cqg2-863c):
> 
> > An XXE issue in SAXBuilder in JDOM through 2.0.6 allows attackers to
> > cause a denial of service via a crafted HTTP request. At this time
> > there is not released fixed version of JDOM. As a workaround, to
> > avoid external entities being expanded, one can call
> > builder.setExpandEntities(false) and they won't be expanded.  
> 
> I dunno how to fix this though, I'm just a curious guixer.  Easiest
> path seems to be to make a new java-jdom-2.0.6 var and use that as a
> native-input for maven.  Would that be an acceptable solution?
> 
> Cheers,
> Remco
> 

Like you say, the issue is with the new jdom. Believe it or not, but
between 2.0.6 and 2.0.6.1 there's some breakage (and > 1 year of
changes, too)!

So I figured I could fix java-plexus-component-metadata that we use to
generate some xml files during the build of maven. jdom is one of its
inputs. Adding another jdom to the native inputs would probably not fix
the issue.

What I did instead is, since jdom wants to set more features than
supported in the driver, to add dummy support for all these additional
features by just not throwing the exception. It's not very satisfying,
but it works and we don't keep a vulnerable jdom around. With the
attached patch, I built up to maven.
>From 2523b6c6b3f81f8a86b7c768dfed9dae97978e93 Mon Sep 17 00:00:00 2001
From: Julien Lepiller 
Date: Sat, 4 Jun 2022 15:41:41 +0200
Subject: [PATCH] gnu: java-plexus-component-metadata: Fix package.

* gnu/packages/java.scm (java-plexus-component-metadat): Apply fix for
  newer jdom.
---
 gnu/packages/java.scm | 8 
 1 file changed, 8 insertions(+)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 336e84e3e5..f475f7c270 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -4537,6 +4537,14 @@ (define-public java-plexus-component-metadata-1.7
  (copy-recursively "src/main/resources"
"build/classes/")
  #t))
+ (add-before 'build 'fix-jdom
+   (lambda _
+ ;; The newer version of jdom now sets multiple features by default
+ ;; that are not supported.
+ ;; Skip these features
+ (substitute* "src/main/java/org/codehaus/plexus/metadata/merge/MXParser.java"
+   (("throw new XmlPullParserException\\(\"unsupporte feature \"\\+name\\);")
+"// skip"
  (add-before 'check 'fix-test-location
(lambda _
  (substitute* '("src/test/java/org/codehaus/plexus/metadata/DefaultComponentDescriptorWriterTest.java"
-- 
2.35.1

bug#55552: frama-c should probably be wrapped

[Julien Lepiller]

Le Fri, 20 May 2022 13:36:54 +0200,
raingloom  a écrit :

> Sorry, can't debug this further right now.
> 
> ```
> $(guix build frama-c)/bin/frama-c
> [kernel] User Error: [findlib] package 'ocamlgraph' not found
> (required by `frama-c.kernel') [kernel] User Error: Deferred error
> message was emitted during execution. See above messages for more
> information. [kernel] Frama-C aborted: invalid user input. ```
> 
> Running it with `guix shell frama-c -- frama-c` just makes it exit
> without any output.
> 
> 
> 

Hi, I think it's a duplicate of https://issues.guix.gnu.org/54094 ?
I think it's just a matter of defining OCAMLPATH. Do you think you could
come up with a patch?

bug#55252: Bugtrace error computing guix derivation

[Julien Lepiller]

Thanks for letting me know :)

I'm closing this issue then. Next time, please make sure to reply all so 
everyone can follow what's happening.

Enjoy your up-to-date Guix!

On May 7, 2022 10:01:21 AM GMT+02:00, Pedro Herrero Garcia 
 wrote:
>Hi Julien,
>yes I was able to do guix pull thank you. I made a couple of "guix package
>-- roll-back" because I thought It could be one of the last packages I
>wanted. But If It was the server is good to know.
>Thank you!
>
>El mié., 4 may. 2022 7:25, Julien Lepiller  escribió:
>
>> Hi Pedro,
>>
>> I believe this was caused by a network issue (&nar-error). We lost our
>> main server for a few hours when you tried running guix pull.
>>
>> Could you try again and report success/failure?
>>
>> Thanks for reporting the issue! It's much appreciated :)
>>
>> On May 3, 2022 11:18:16 PM GMT+02:00, Pedro Herrero Garcia <
>> petrust...@gmail.com> wrote:
>>>
>>> Intel® Core™ i7-8550U CPU @ 1.80GHz × 8
>>> Mesa Intel® UHD Graphics 620 (KBL GT2)
>>> Guix System, 64 bits, GNOME 40.4, X11
>>>
>>> After guix pull
>>>
>>> ---
>>> Computing Guix derivation for 'x86_64-linux'... \Backtrace:
>>>   17 (primitive-load
>>> "/gnu/store/9x5ixhawcvbyjcg23m2cwg7ja52x2f6l-compute-guix-derivation")
>>> In ice-9/eval.scm:
>>> 155:9 16 (_ _)
>>> 159:9 15 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?)
>>> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
>>> In ice-9/boot-9.scm:
>>> 152:2 14 (with-fluid* _ _ _)
>>> 152:2 13 (with-fluid* _ _ _)
>>> In ./guix/store.scm:
>>>   2129:24 12 (run-with-store #
>>> # ?)
>>>1966:8 11 (_ #)
>>> In ./guix/gexp.scm:
>>>300:22 10 (_ #)
>>>1181:2  9 (_ #)
>>>1047:2  8 (_ #)
>>> 893:4  7 (_ #)
>>> In ./guix/store.scm:
>>>   2014:12  6 (_ #)
>>>1406:5  5 (map/accumulate-builds #>> 7f5236bf2fa0> # ?)
>>>   1421:15  4 (_ #
>>> ("/gnu/store/gcvv1i5shqmkd6x1pjwjdrvr7z4lb5ss-guile-ssh-?" ?) ?)
>>>   1421:15  3 (loop #f)
>>>733:11  2 (process-stderr # _)
>>> In ./guix/serialization.scm:
>>>102:11  1 (read-int #)
>>>  80:6  0 (get-bytevector-n* # 8)
>>>
>>> ./guix/serialization.scm:80:6: In procedure get-bytevector-n*:
>>> ERROR:
>>>   1. &nar-error:
>>>   file: #f
>>>   port: #
>>> guix pull: error: You found a bug: the program
>>> '/gnu/store/9x5ixhawcvbyjcg23m2cwg7ja52x2f6l-compute-guix-derivation'
>>> failed to compute the derivation for Guix (version:
>>> "b80ca672de936a76368de6e6ea0b28505e74d420"; system: "x86_64-linux";
>>> host version: "0a64b629ae8512790d532158a72a4a25698e8157"; pull-version:
>>> 1).
>>>
>>>

bug#55249: `guix pull` crash

[Julien Lepiller]

Thanks for getting back to us. Closing then. Enjoy your new guix :)

On May 5, 2022 11:54:15 PM GMT+02:00, Nathan Wilcox  
wrote:
>It completed successfully.
>
>On Tue, May 3, 2022 at 10:27 PM Julien Lepiller  wrote:
>
>> Hi Nathan,
>>
>> I believe this was caused by a network issue (&nar-error). We lost our
>> main server for a few hours when you tried running guix pull.
>>
>> Could you try again and report success/failure?
>>
>> Thanks for reporting the issue! It's much appreciated :)
>>
>> On May 3, 2022 9:44:19 PM GMT+02:00, Nathan Wilcox via Bug reports for GNU
>> Guix  wrote:
>>>
>>> Hi,
>>>
>>> I just started using guix and have only used `guix pull` and `guix
>>> search` so far. I used `guix pull` successfully a few days ago, and decided
>>> to rerun it today to see if it takes less time, and it resulted in a
>>> stacktrace (attached).
>>>
>>> This is a foreign-distro install on Debian 10 Buster. It's running inside
>>> a 'crostini' lxc vm built into ChromeOS.
>>>
>>> Also, while I'm here, I read about `guix shell` and it was the primary
>>> motivation for me to install since I wanted to do a project-specific
>>> dependency configuration, but after following the instructions in [1]
>>> running `guix shell` says `guix: shell: command not found`. I have tried
>>> `guix search` with various patterns (`shell`, `guix.*shell`, etc…) but I
>>> haven't been able to find out how to install it. Furthermore [1] introduces
>>> it, so I am confused if I missed some critical setup step, even though I
>>> followed the install section. Any advice?
>>>
>>> links:
>>> [1]  https://guix.gnu.org/manual/devel/en/html_node/Installation.html
>>>
>>> --
>>>
>>> Nathan Wilcox
>>>
>>> Chief Research Officer
>>>
>>> nat...@electriccoin.co | @least_nathan <https://twitter.com/least_nathan>
>>>
>>>
>>>
>
>-- 
>
>Nathan Wilcox
>
>Chief Research Officer
>
>nat...@electriccoin.co | @least_nathan <https://twitter.com/least_nathan>

bug#55251: bug report

[Julien Lepiller]

Thanks for the confirmation. Closing the ticket :)

Make sure to reply all next time, or we might miss the info.

On May 4, 2022 1:35:08 PM GMT+02:00, wilson dennison 
 wrote:
>Hi there,
>
>You were right of course. Everything back to normal.
>
>Thanks for your reply
>Best,
>Wilson
>
>On Wed, 4 May 2022, 07:30 Julien Lepiller,  wrote:
>
>> Hi Wilson,
>>
>> I believe this was caused by a network issue (&nar-error). We lost our
>> main server for a few hours when you tried running guix pull.
>>
>> Could you try again and report success/failure?
>>
>> Thanks for reporting the issue! It's much appreciated :)
>>
>> On May 3, 2022 8:56:51 PM GMT+02:00, surface 
>> wrote:
>>>
>>> With regards
>>>
>>>
>>>
>>> wil@guix ~$ guix pull
>>>
>>> Updating channel 'nonguix' from Git repository at '
>>> https://gitlab.com/nonguix/nonguix'...
>>>
>>> Authenticating channel 'nonguix', commits 897c1a4 to 176f36d (4 new
>>> commits)..
>>>
>>> Updating channel 'flat' from Git repository at '
>>> https://github.com/flatwhatson/guix-channel.git'...
>>>
>>> Updating channel 'guix' from Git repository at '
>>> https://git.savannah.gnu.org/git/guix.git'...
>>>
>>> Authenticating channel 'guix', commits 9edb3f6 to 8b2d266 (164 new
>>> commits)...
>>>
>>> Building from these channels:
>>>
>>>   guix  https://git.savannah.gnu.org/git/guix.git   8b2d266
>>>
>>>   flat  https://github.com/flatwhatson/guix-channel.git f43c67e
>>>
>>>   nonguix   https://gitlab.com/nonguix/nonguix  176f36d
>>>
>>> substitute: updating substitutes from 'https://ci.guix.gnu.org'...
>>> 0.0%guix substitute: warning: ci.guix.gnu.org: connection failed:
>>> Connection refused
>>>
>>> substitute:
>>>
>>> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...
>>> 100.0%
>>>
>>> substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
>>>
>>> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...
>>> 100.0%
>>>
>>> substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
>>>
>>> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'..
>>> 100.0%
>>>
>>> building /gnu/store/j9jhim8y26kvzhll5dnpxdd0fjspls2a-config.scm.drv...
>>>
>>> building /gnu/store/35np5f5gdsl6qayp45d7368bac08hyq3-git.scm.drv...
>>>
>>> building /gnu/store/sywnigcng0jqc1lwcvy7g9aakcdxawy1-hash.scm.drv...
>>>
>>> building /gnu/store/5sjh4grn2g5sypzllcyxcp3qwv8awg0h-module-import.drv...
>>>
>>> building /gnu/store/gzz2xwvr67va9a41rxcj7m56bbdz6fyp-module-import.drv...
>>>
>>> building
>>> /gnu/store/yfig30krw0mnh6kwn1z7z6jkjnph3yr4-module-import-compiled.drv...
>>>
>>> building
>>> /gnu/store/qhhbv3cf74k9rcc6vgcm1n2plm5n5m95-module-import-compiled.drv...
>>>
>>> building
>>> /gnu/store/krv8hq01iqhyfp4vwcaqds1a540rkkzj-compute-guix-derivation.drv...
>>>
>>> Computing Guix derivation for 'x86_64-linux'... /Backtrace:
>>>
>>>   17 (primitive-load
>>> "/gnu/store/cl3rpmsw7ksvqldj4vjamsdfsf5sl3ax-compute-guix-derivation")
>>>
>>> In ice-9/eval.scm:
>>>
>>> 155:9 16 (_ _)
>>>
>>> 159:9 15 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?)
>>> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
>>>
>>> In ice-9/boot-9.scm:
>>>
>>> 152:2 14 (with-fluid* _ _ _)
>>>
>>> 152:2 13 (with-fluid* _ _ _)
>>>
>>> In ./guix/store.scm:
>>>
>>>   2129:24 12 (run-with-store #
>>> # ?)
>>>
>>>1966:8 11 (_ #)
>>>
>>> In ./guix/gexp.scm:
>>>
>>>300:22 10 (_ #)
>>>
>>>   1181:2  9 (_ #)
>>>
>>>1047:2  8 (_ #)
>>>
>>> 893:4  7 (_ #)
>>>
>>> In ./guix/store.scm:
>>>
>>>   2014:12  6 (_ #)
>>>
>>>1406:5  5 (map/accumulate-builds #>> 7f0c0e5778c0> # ?)
>>>
>>>   1421:15  4 (_ #
>>> ("/gnu/store/gcvv1i5shqmkd6x1pjwjdrvr7z4lb5ss-guile-ssh-?" ?) ?)
>>>
>>>   1421:15  3 (loop #f)
>>>
>>>733:11  2 (process-stderr # _)
>>>
>>> In ./guix/serialization.scm:
>>>
>>>102:11  1 (read-int #)
>>>
>>>  80:6  0 (get-bytevector-n* # 8)
>>>
>>>
>>>
>>> ./guix/serialization.scm:80:6: In procedure get-bytevector-n*:
>>>
>>> ERROR:
>>>
>>>   1. &nar-error:
>>>
>>>   file: #f
>>>
>>>   port: #
>>>
>>> guix pull: error: You found a bug: the program
>>> '/gnu/store/cl3rpmsw7ksvqldj4vjamsdfsf5sl3ax-compute-guix-derivation'
>>>
>>> failed to compute the derivation for Guix (version:
>>> "8b2d26660717a0f352da54acd68e0d61a7c697df"; system: "x86_64-linux";
>>>
>>> host version: "882cacc1bb5be0df334dd7ce55b385a3a1678728"; pull-version:
>>> 1).
>>>
>>> Please report the COMPLETE output above by email to .
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>

bug#55251: bug report

[Julien Lepiller]

Hi Wilson,

I believe this was caused by a network issue (&nar-error). We lost our main 
server for a few hours when you tried running guix pull.

Could you try again and report success/failure?

Thanks for reporting the issue! It's much appreciated :)

On May 3, 2022 8:56:51 PM GMT+02:00, surface  wrote:
>With regards
>
>wil@guix ~$ guix pull
>
>Updating channel 'nonguix' from Git repository at 
>'https://gitlab.com/nonguix/nonguix'...
>
>Authenticating channel 'nonguix', commits 897c1a4 to 176f36d (4 new commits)..
>
>Updating channel 'flat' from Git repository at 
>'https://github.com/flatwhatson/guix-channel.git'...
>
>Updating channel 'guix' from Git repository at 
>'https://git.savannah.gnu.org/git/guix.git'...
>
>Authenticating channel 'guix', commits 9edb3f6 to 8b2d266 (164 new commits)...
>
>Building from these channels:
>
> guix https://git.savannah.gnu.org/git/guix.git 8b2d266
>
> flat https://github.com/flatwhatson/guix-channel.git f43c67e
>
> nonguix https://gitlab.com/nonguix/nonguix 176f36d
>
>substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%guix 
>substitute: warning: ci.guix.gnu.org: connection failed: Connection refused
>
>substitute: 
>
>substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
>
>substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%
>
>substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
>
>substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%
>
>substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'.. 100.0%
>
>building /gnu/store/j9jhim8y26kvzhll5dnpxdd0fjspls2a-config.scm.drv...
>
>building /gnu/store/35np5f5gdsl6qayp45d7368bac08hyq3-git.scm.drv...
>
>building /gnu/store/sywnigcng0jqc1lwcvy7g9aakcdxawy1-hash.scm.drv...
>
>building /gnu/store/5sjh4grn2g5sypzllcyxcp3qwv8awg0h-module-import.drv...
>
>building /gnu/store/gzz2xwvr67va9a41rxcj7m56bbdz6fyp-module-import.drv...
>
>building 
>/gnu/store/yfig30krw0mnh6kwn1z7z6jkjnph3yr4-module-import-compiled.drv...
>
>building 
>/gnu/store/qhhbv3cf74k9rcc6vgcm1n2plm5n5m95-module-import-compiled.drv...
>
>building 
>/gnu/store/krv8hq01iqhyfp4vwcaqds1a540rkkzj-compute-guix-derivation.drv...
>
>Computing Guix derivation for 'x86_64-linux'... /Backtrace:
>
> 17 (primitive-load 
> "/gnu/store/cl3rpmsw7ksvqldj4vjamsdfsf5sl3ax-compute-guix-derivation")
>
>In ice-9/eval.scm:
>
> 155:9 16 (_ _)
>
> 159:9 15 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) 
> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
>
>In ice-9/boot-9.scm:
>
> 152:2 14 (with-fluid* _ _ _)
>
> 152:2 13 (with-fluid* _ _ _)
>
>In ./guix/store.scm:
>
> 2129:24 12 (run-with-store # 
> # ?)
>
> 1966:8 11 (_ #)
>
>In ./guix/gexp.scm:
>
> 300:22 10 (_ #)
>
> 1181:2 9 (_ #)
>
> 1047:2 8 (_ #)
>
> 893:4 7 (_ #)
>
>In ./guix/store.scm:
>
> 2014:12 6 (_ #)
>
> 1406:5 5 (map/accumulate-builds # 
> # ?)
>
> 1421:15 4 (_ # 
> ("/gnu/store/gcvv1i5shqmkd6x1pjwjdrvr7z4lb5ss-guile-ssh-?" ?) ?)
>
> 1421:15 3 (loop #f)
>
> 733:11 2 (process-stderr # _)
>
>In ./guix/serialization.scm:
>
> 102:11 1 (read-int #)
>
> 80:6 0 (get-bytevector-n* # 8)
>
>./guix/serialization.scm:80:6: In procedure get-bytevector-n*:
>
>ERROR:
>
> 1. &nar-error:
>
> file: #f
>
> port: #
>
>guix pull: error: You found a bug: the program 
>'/gnu/store/cl3rpmsw7ksvqldj4vjamsdfsf5sl3ax-compute-guix-derivation'
>
>failed to compute the derivation for Guix (version: 
>"8b2d26660717a0f352da54acd68e0d61a7c697df"; system: "x86_64-linux";
>
>host version: "882cacc1bb5be0df334dd7ce55b385a3a1678728"; pull-version: 1).
>
>Please report the COMPLETE output above by email to .

bug#55249: `guix pull` crash

[Julien Lepiller]

Hi Nathan,

I believe this was caused by a network issue (&nar-error). We lost our main 
server for a few hours when you tried running guix pull.

Could you try again and report success/failure?

Thanks for reporting the issue! It's much appreciated :)

On May 3, 2022 9:44:19 PM GMT+02:00, Nathan Wilcox via Bug reports for GNU Guix 
 wrote:
>Hi,
>
>I just started using guix and have only used `guix pull` and `guix search`
>so far. I used `guix pull` successfully a few days ago, and decided to
>rerun it today to see if it takes less time, and it resulted in a
>stacktrace (attached).
>
>This is a foreign-distro install on Debian 10 Buster. It's running inside a
>'crostini' lxc vm built into ChromeOS.
>
>Also, while I'm here, I read about `guix shell` and it was the primary
>motivation for me to install since I wanted to do a project-specific
>dependency configuration, but after following the instructions in [1]
>running `guix shell` says `guix: shell: command not found`. I have tried
>`guix search` with various patterns (`shell`, `guix.*shell`, etc…) but I
>haven't been able to find out how to install it. Furthermore [1] introduces
>it, so I am confused if I missed some critical setup step, even though I
>followed the install section. Any advice?
>
>links:
>[1]  https://guix.gnu.org/manual/devel/en/html_node/Installation.html
>
>-- 
>
>Nathan Wilcox
>
>Chief Research Officer
>
>nat...@electriccoin.co | @least_nathan 

bug#55252: Bugtrace error computing guix derivation

[Julien Lepiller]

Hi Pedro,

I believe this was caused by a network issue (&nar-error). We lost our main 
server for a few hours when you tried running guix pull.

Could you try again and report success/failure?

Thanks for reporting the issue! It's much appreciated :)

On May 3, 2022 11:18:16 PM GMT+02:00, Pedro Herrero Garcia 
 wrote:
>Intel® Core™ i7-8550U CPU @ 1.80GHz × 8
>Mesa Intel® UHD Graphics 620 (KBL GT2)
>Guix System, 64 bits, GNOME 40.4, X11
>
>After guix pull
>---
>Computing Guix derivation for 'x86_64-linux'... \Backtrace:
>  17 (primitive-load
>"/gnu/store/9x5ixhawcvbyjcg23m2cwg7ja52x2f6l-compute-guix-derivation")
>In ice-9/eval.scm:
>155:9 16 (_ _)
>159:9 15 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?)
>?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
>In ice-9/boot-9.scm:
>152:2 14 (with-fluid* _ _ _)
>152:2 13 (with-fluid* _ _ _)
>In ./guix/store.scm:
>  2129:24 12 (run-with-store #
># ?)
>   1966:8 11 (_ #)
>In ./guix/gexp.scm:
>   300:22 10 (_ #)
>   1181:2  9 (_ #)
>   1047:2  8 (_ #)
>893:4  7 (_ #)
>In ./guix/store.scm:
>  2014:12  6 (_ #)
>   1406:5  5 (map/accumulate-builds #
># ?)
>  1421:15  4 (_ #
>("/gnu/store/gcvv1i5shqmkd6x1pjwjdrvr7z4lb5ss-guile-ssh-?" ?) ?)
>  1421:15  3 (loop #f)
>   733:11  2 (process-stderr # _)
>In ./guix/serialization.scm:
>   102:11  1 (read-int #)
> 80:6  0 (get-bytevector-n* # 8)
>
>./guix/serialization.scm:80:6: In procedure get-bytevector-n*:
>ERROR:
>  1. &nar-error:
>  file: #f
>  port: #
>guix pull: error: You found a bug: the program
>'/gnu/store/9x5ixhawcvbyjcg23m2cwg7ja52x2f6l-compute-guix-derivation'
>failed to compute the derivation for Guix (version:
>"b80ca672de936a76368de6e6ea0b28505e74d420"; system: "x86_64-linux";
>host version: "0a64b629ae8512790d532158a72a4a25698e8157"; pull-version: 1).
>
>
>-- 
>Pedro Herrero García

bug#40116: bug#41215: memory leak in gnome-shell

[Julien Lepiller]

On March 23, 2022 4:46:53 PM GMT+01:00, zimoun  wrote:
>Hi Luis,
>
>On Wed, 23 Mar 2022 at 16:13, Luis Felipe  
>wrote:
>
>> So, if Julien and Arne, for example, don't experience the issue anymore, I'm 
>> happy to close the issue.
>
>Let wait 15 days and if no answer, let assume it is not an issue and
>close it. :-)
>
>Thank you for your feedback.
>
>Cheers,
>simon
>
>
>

I haven't had that issue in a while, I tgink we can close.

bug#54094: frama-c doesn't start

[Julien Lepiller]

guix shell ocaml ocaml-findlib frama-c

Should work :)

Ocaml is needed to define OCAMLPATH, ocaml-findlib is what frama-c is missing. 
Should we wrap the binary?

On February 21, 2022 10:13:07 PM GMT+01:00, raingloom  
wrote:
>I was just idly messing around so I'm not super motivated to dig
>deeper.
>
>```
>guix shell frama-c -- frama-c
>[kernel] User Error: [findlib] package 'ocamlgraph' not found (required by 
>`frama-c.kernel')
>[kernel] User Error: Deferred error message was emitted during execution. See 
>above messages for more information.
>[kernel] Frama-C aborted: invalid user input.
>```
>
>
>

bug#53934: OpenJDK doesn't have a doclet

[Julien Lepiller]

Openjdk has two outputs: out and jdk. The default output contains only
what's necessary to *run* a Java application, while the jdk output
contains that *in addition* to what's needed to build Java applications
(javac, ...). I'm not knowledgeable enough to know if javadoc or doclet
need to be in the default output or not. Aren't they used only when
developping or building Java code?

Le Mon, 14 Feb 2022 22:26:27 +0100,
Igor Gajsin  a écrit :

> I narrowed down where the problem arise and found the exact bugreport:
> https://github.com/clojure-emacs/orchard/issues/117#issuecomment-859987280
> 
> Unfortunately, I didn't get the solution 'one has to use ONLY the
> package "openjdk:jdk"'. What does it mean?
> 
> Also, why openjdk removes javadoc, is it a bug or a correct behaviour?
> 
> Michael Rohleder  writes:
> 
> > [[PGP Signed Part:Undecided]]
> > Igor Gajsin  writes:  
> >> There is a problem with openjdk (all versions 10 to 17). When I run
> >> cider (emacs mode for clojure) it complains about:
> >> java.lang.ClassNotFoundException: jdk.javadoc.doclet.Doclet
> >>
> >> when I try to set icedtea there is no such problem. If I
> >> understand well doclet is a part of JDK so it shoulb be part of a
> >> modern openjdk installation.  
> >
> > I haven't tried, but maybe adding a file "module-info.java" with the
> > content "requires jdk.javadoc" to your project might help. [1]
> >
> > [1]
> > https://stackoverflow.com/questions/65683365/why-cant-i-import-the-jdk-javadoc-doclet-package
> >  
> 
> 

bug#52788: static networking: Support pointopoint/peer

[Julien Lepiller]

Le Sun, 30 Jan 2022 18:53:29 +0100,
Ludovic Courtès  a écrit :

> Hi Julien,
> 
> Julien Lepiller  skribis:
> 
> > It was not supported in guile-netlink, so I added support for
> > #:peer and other new arguments in addr-add and addr-del. There's no
> > release yet, but I'd be glad if you could check it works as
> > expected (--with-latest=guile-netlink should work).  
> 
> Perhaps we also need to update  and related code in
> (gnu services base) to expose that?
> 
> Ludo’.

Yes, otherwise we won't be able to use that in static-networking.

bug#52788: static networking: Support pointopoint/peer

[Julien Lepiller]

It was not supported in guile-netlink, so I added support for #:peer and other 
new arguments in addr-add and addr-del. There's no release yet, but I'd be glad 
if you could check it works as expected (--with-latest=guile-netlink should 
work).

Le 25 décembre 2021 08:03:16 GMT-05:00, Jonathan Brielmaier 
 a écrit :
>
>Hi folks,
>
>it would be nice if `static-networking` would support the  pointopoint
>or peer parameter. This one is required to get IPv4 at Hetzner Cloud.
>
>The relevant ip statement is:
>ip address add IPv4/32 dev eth0 peer 172.31.1.1
> ^^^
>
>Is this functionality already implemented by guile-netlink? If yes, I
>could try to add this feature to our static-networking-service-type :)
>
>~Jonathan
>
>
>

bug#52767: Unexpected problem with Guix System installer

[Julien Lepiller]

From the backtrace I can't tell you more than this. The installer tried to run 
"mkfs.btrfs -f /dev/napper/crypt" but the command ended with status 1 (error). 
Unfortunately guix didn't capture the error. Next time you try, could you run 
the failid command (you'll find the exact one at the bottom) from another tty 
and report any error message?

Le 23 décembre 2021 20:46:55 GMT-05:00, Mathieu  a écrit :
>Hey,
>
>Trying to install Guix on a 32GB thum drive, I get the attached backtrace.
>
>The partition table is gpt with 500MB for ESP, 20GB for /, 2GB for swap and 
>remaining space for /home. I have tried btrfs and ext4 for / and /home but got 
>backtraces related to either mkfs.btrfs or mkfs.ext4 in both cases. I also 
>have tried encryption or no encryption, but still got backtraces. The 
>partitions are created to the drive because I can see they are still there 
>when I restart the installer.
>
>This is not the drive that was used to boot the Guix installer in the first 
>place.
>
>Thanks, hope someone can understand what the issue is.

bug#30123: claws-mail plugins not updated

[Julien Lepiller]

The problem seems to be solved now. Thanks for reminding me of my old bugs :). 
Closing.

Le 24 novembre 2021 18:32:20 GMT-05:00, zimoun  a 
écrit :
>Hi Julien,
>
>On Mon, 15 Jan 2018 at 14:52, julien lepiller  wrote:
>
>> claws-mail has a plugin system to add functionnality. For instance, to add 
>> PGP
>> support, one has to load 3 plugins from the claws-mail package. By default,
>> claws-mail looks in its store directory to propose available plugins.
>>
>> When upgrading claws-mail, the configuration doesn't change. Plugins are 
>> still
>> looked for in the old store location, so old plugins are still used. This is
>> bad for security and compatibility. Another issue is when running guix gc
>> afterwards: the old plugins are deleted and claws-mail issues an error 
>> message
>> on startup because it cannot find them anymore.
>
>Reading the recent activity about claws-mail, is it still an issue?
>
>Cheers,
>simon

bug#49827: Error message for missing synopsis in opam importer

[Julien Lepiller]

Hi,

First, today when running guix import opam iter, I get a synopsis, and
#f as the description because the field is missing.

I also pushed a small patch to master, as
24aa7b3c21309b63cc6e8e18d6417d2cddccf6c6, that ensures that, when the
field exists but contains unknown data, we also return #f instead of a
match error that produces the ugly backtrace you saw.

Thanks for the report, closing :)

bug#51866: OCaml4.07: build fail because Dune version

[Julien Lepiller]

I just pushed fixes to master, so now everything listed in "guix
refresh -l ocaml@4.07" builds without issues. Closing :)

bug#36782: Website manual language links

[Julien Lepiller]

Le 19 novembre 2021 10:41:21 GMT-05:00, Julien Lepiller  a 
écrit :
>Closing since the links now seem to be working.

bug#36782: Website manual language links

[Julien Lepiller]

Closing since the links now seem to be working.

bug#36438: git-fetch issue

[Julien Lepiller]

I don't have this issue anymore, so closing. Thanks!

bug#36781: Website manual generation stopped

[Julien Lepiller]

Closing since the website manual is now up to date :)

bug#35296: gdm doesn't always start at boot

[Julien Lepiller]

I haven't been able to reproduce it in a long time, so closing.

bug#32894: Exception in validate-runpath phase

[Julien Lepiller]

Since then, we have openjdk 10, and much more recent versions. I don't remember 
what fixed the issue, but I haven't seen it since then, so closing :)

bug#39370: Dovecot does not build on arm

[Julien Lepiller]

Closing since it now builds again (even got a substitute from bordeaux :D)

bug#51866: OCaml4.07: build fail because Dune version

[Julien Lepiller]

I plan to get rid of ocaml4.07* at some point. For that, I'll need to import a 
bunch of packages (ocaml-core and friends, at least). Will see if I have enough 
time for that.

Le 15 novembre 2021 07:59:53 GMT-05:00, zimoun  a 
écrit :
>Hi,
>
>These OCaml packages fail to build because some issue with Dune
>versions, respectively:
>
>--8<---cut here---start->8---
>ocaml4.07-charinfo-width
>ocaml4.07-core
>ocaml4.07-core-kernel
>ocaml4.07-ezjsonm
>ocaml4.07-lambda-term
>ocaml4.07-merlin
>ocaml4.07-odoc
>ocaml4.07-piqi
>ocaml4.07-piqilib
>ocaml4.07-ppx-expect
>ocaml4.07-ppx-jane
>ocaml4.07-sedlex
>ocaml4.07-spawn
>ocaml4.07-splittable-random
>ocaml4.07-sqlite3
>ocaml4.07-uri
>ocaml4.07-utop
>ocaml4.07-zed
>--8<---cut here---end--->8---
>
>fails because:
>
>--8<---cut here---start->8---
>Error: Version 2.0 of dune is not supported.
>Error: Version 2.0 of dune is not supported.
>Error: Version 2.0 of dune is not supported.
>Error: Version 2.0 of dune is not supported.
>Error: Version 2.7 of dune is not supported.
>Error: Version 2.0 of dune is not supported.
>Error: Version 2.7 of dune is not supported.
>Error: Version 2.7 of dune is not supported.
>Error: Version 2.7 of dune is not supported.
>Error: Version 2.0 of dune is not supported.
>Error: Version 2.0 of dune is not supported.
>Error: Version 2.7 of dune is not supported.
>Error: Version 2.0 of dune is not supported.
>Error: Version 2.0 of dune is not supported.
>Error: Version 2.7 of dune is not supported.
>Error: Version 2.0 of dune is not supported.
>Error: Version 2.7 of dune is not supported.
>Error: Version 2.0 of dune is not supported.
>--8<---cut here---end--->8---
>
>
>From my understanding, more or more cases like this will happen.  The
>question is: do we try to fix?  Or do we plan to remove ’ocaml4.07-’
>packages?
>
>
>Cheers,
>simon
>
>

bug#51693: [patch] Add Java 17

[Julien Lepiller]

Hi, I think you fixed openjdk16 instead of openjdk17, this makes the
patch a bit confusing to read.

Le Sun, 14 Nov 2021 21:59:44 +0100,
"Dr. Arne Babenhauserheide"  a écrit :

> Julien Lepiller  writes:
> 
> > Le Mon, 08 Nov 2021 21:32:16 +0100,
> > "Dr. Arne Babenhauserheide"  a écrit :
> >  
> >> the attached patch adds openjdk@17
> >> 
> >> Take care with updating packages depending on this, because the
> >> changes to the module system can cause runtime failures.  
> 
> > sorry for the delay.  
> 
> No problems — thank you for checking my patch!
> 
> > I tried your patch, but the build fails for me
> > because it goes "out of file descriptors" and "unix resources".
> > Does it work for you?  
> 
> It works for me, yes.
> 
> ./pre-inst-env guix environment --ad-hoc openjdk@17:jdk -- java
> -version …
> openjdk version "17.0.1" 2021-10-19
> OpenJDK Runtime Environment (build 17.0.1+0-adhoc..source)
> OpenJDK 64-Bit Server VM (build 17.0.1+0-adhoc..source, mixed mode,
> sharing)
> 
> > I tried with various levels of parallelism, but it did not
> > change anything.
> >
> > also about your patch, could you replace (invoke "chmod" "u+w" file)
> > with a call to make-writable?  
> 
> Do you mean `make-file-writable` ? I switched to that now.
> 
> > It's available by default in the build
> > environment, it comes from (guix build utils). I wonder also why you
> > inherit arguments from openjdk15 instead of openjdk16?  
> 
> That was a mistake — thank you!
> 
> I attached a new patch.
> 

bug#51693: [patch] Add Java 17

[Julien Lepiller]

Le Mon, 08 Nov 2021 21:32:16 +0100,
"Dr. Arne Babenhauserheide"  a écrit :

> Hi,
> 
> the attached patch adds openjdk@17
> 
> Take care with updating packages depending on this, because the
> changes to the module system can cause runtime failures.
> 

Hi!

sorry for the delay. I tried your patch, but the build fails for me
because it goes "out of file descriptors" and "unix resources". Does it
work for you? I tried with various levels of parallelism, but it did not
change anything.

also about your patch, could you replace (invoke "chmod" "u+w" file)
with a call to make-writable? It's available by default in the build
environment, it comes from (guix build utils). I wonder also why you
inherit arguments from openjdk15 instead of openjdk16?

Thanks!

bug#51443: [patch] openjdk11: update to latest version

[Julien Lepiller]

Le Wed, 27 Oct 2021 20:49:02 +0200,
"Dr. Arne Babenhauserheide"  a écrit :

> "Dr. Arne Babenhauserheide"  writes:
> 
> > The attached patch updates openjdk11 to the latest version. The
> > update includes some important bugfixes for compile errors of
> > classfiles.  
> 
> > +(version "11.0.12-ga")  
> 
> This is from https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
> 
> Best wishes,
> Arne

Thanks for the pach!

I actually just pushed an update to 11.0.13, since 11.0.12 has a bunch
of CVEs now (I was prompted to do the update when seeing an advisory
from debian). Sorry that your patch did not get in, but hopefully you
can now enjoy an updated openjdk11 :)

bug#51348: Solved: Exception on `guix install nss-certs`

[Julien Lepiller]

Le Mon, 25 Oct 2021 21:15:23 +,
Raimundo Martins via Bug reports for GNU Guix  a
écrit :

> Hey!
> 
> Turns out that, since I use the runit init system, GUIX_LOCPATH
> wasn't being set anytime before guix-daemon started, since
> /etc/profile.d/guix.sh was not sourced. As a fix I set that variable
> by hand in my init script. If you want to have runit as a known init
> system in the installer script, I suggest adding to chk_init_sys()
> 
> elif $(runit 2>/dev/null; [ $? = 111 ]); then
> _msg "${INF}init system is: runit"
> INIT_SYS="runit"
> return 0
> 
> and to the case in sys_enable_guix_daemon()
> 
> runit)
> mkdir /etc/sv/guix-daemon
> echo "#!/bin/sh
> GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale
> exec /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon
> --build-users-group=guixbuild" >/etc/sv/guix-daemon/run chmod 755
> /etc/sv/guix-daemon/run ln -sT /etv/sv/guix-daemon
> /var/service/guix-daemon ;;
> 
> Or something like that :P Thanks for your support in IRC #guix !!
> 
> Regards,
> Raimundo

Great news!

I'm closing this bug properly for you :) Note that you can close your
reports by sending to n-d...@debbugs.gnu.org, where n is your
bug number.

I think it would make sense to support runit. I guess I would need a VM
of a distro that uses runit, in order to test an updated installation
script. Which one do you use exactly?

bug#51448: kicad-pcb.org is now controlled by a most likely malicious third party

[Julien Lepiller]

Le Wed, 27 Oct 2021 21:18:35 +0200,
Mikołaj Wielgus  a écrit :

> In 2020 KiCad moved its official website to kicad.org [1].
> 
> Recently, a former member has betrayed the project and sold the
> kicad-pcb.org domain name to an unknown third party. The new owner has
> subsequently set up a fake KiCad website that is very similar to the
> real one, probably for the purpose of serving malware.
> 
> Please change all kicad-pcb.org links to kicad.org in kicad,
> kicad-doc, kicad-footprints, kicad-packages3d, kicad-symbols,
> kicad-templates and all other relevant packages.
> 
> [1]
> https://www.kicad.org/blog/2021/10/Avoid-links-to-former-kicad-domain/
> 
> -Mikolaj
> 
> 
> 

Thanks for the report! I did updated the home-page as soon as I came
back from work thise evening, and this is now pushed to master as
e2ce7fc73d7333003f04f2dd7f7fc989db254721.

bug#51259: Cannot build Guix from source (error messages about the translations)

[Julien Lepiller]

I pushed my patch to master as
c5881ff1f3ea321401b0f040c4e795bcd452ef5d, so tentatively closing this
bug.

Note that, if you encountered the issue, this patch is not enough: you
already have .texi files that contain lots of "??". You'll need to
start from a clean checkout, or at least clean the texi files with
something like:

git pull # to get the patch
rm doc/*.texi# remove texi files
git checkout doc # reinstate those that are commited
./bootstrap  # recreate dummy files for the Makefile to be happy
make # should now be working

Sorry for the inconvenience!

bug#51259: Cannot build Guix from source (error messages about the translations)

[Julien Lepiller]

You might be running with modified files, or the container is doing something 
unexpected. Can you try again from a clean checkout, or after cleaning with 
"git clean -fdx"? This should put the repo back to the last commit, and remove 
any additional files, as if you just pulled it.

Le 20 octobre 2021 11:44:38 GMT-04:00, Denis 'GNUtoo' Carikli 
 a écrit :
>Hi,
>
>I'm on i686, and I've tried all the approaches mentioned:
>- export LC_ALL=en_US.utf8
>- rm doc/contributing.*.texi
>- the patch in doc/local.mk
>
>on top of the following commit:
>19d3cfec72 gnu: python-arrow: Move python-pytz to native-inputs.
>
>I tried building Guix with both:
>- guix environment guix -C guix
>- guix environment --pure guix
>
>And for building I use
>export LC_ALL=en_US.utf8
>rm -f doc/contributing.*.texi && \
>./bootstrap && \
>./configure --localstatedir=/var && \
>make clean && \
>make -j2
>
>And that gives the following compilation error (with guix environment
>guix -C guix):
>> ). Please consider running po4a-updatepo to refresh it.
>> sed -i "s|guix\.info|$(basename "doc/guix.zh_CN.texi" | sed 
>> 's|texi$|info|')|" "doc/guix.zh_CN.texi.tmp"
>>   POXREF doc/guix.zh_CN.texi
>> translated 914 cross-references in 'doc/guix.sk.texi.tmp'
>> mv "doc/guix.sk.texi.tmp" "doc/guix.sk.texi"
>> translated 914 cross-references in 'doc/guix.zh_CN.texi.tmp'
>> mv "doc/guix.zh_CN.texi.tmp" "doc/guix.zh_CN.texi"
>> make  all-recursive
>> make[1]: Entering directory '/home/gnutoo/work/projects/guix/guix'
>> Making all in po/guix
>> make[2]: Entering directory '/home/gnutoo/work/projects/guix/guix/po/guix'
>> make[2]: Nothing to be done for 'all'.
>> make[2]: Leaving directory '/home/gnutoo/work/projects/guix/guix/po/guix'
>> Making all in po/packages
>> make[2]: Entering directory 
>> '/home/gnutoo/work/projects/guix/guix/po/packages'
>> make[2]: Nothing to be done for 'all'.
>> make[2]: Leaving directory '/home/gnutoo/work/projects/guix/guix/po/packages'
>> make[2]: Entering directory '/home/gnutoo/work/projects/guix/guix'
>>   MAKEINFO doc/guix-cookbook.ko.info
>>   MAKEINFO doc/guix-cookbook.zh_Hans.info
>> ./doc/guix-cookbook.zh_Hans.texi:2892: @node `' previously 
>> defined
>> ./doc/guix-cookbook.zh_Hans.texi:1385: here is the previous definition as 
>> @node
>> ./doc/guix-cookbook.zh_Hans.texi:1385: warning: node next `' in 
>> menu `Acknowledgments' and in sectioning `Advanced package management' differ
>> ./doc/guix-cookbook.zh_Hans.texi:1385: warning: node prev `' in 
>> menu `Advanced package management' and in sectioning `??' differ
>> ./doc/guix-cookbook.zh_Hans.texi:2483: warning: node next `Advanced package 
>> management' in menu `' and in sectioning `' differ
>> ./doc/guix-cookbook.zh_Hans.texi:2902: warning: node `' is up for `Guix 
>> environment via direnv' in sectioning but not in menu
>> ./doc/guix-cookbook.zh_Hans.texi:2892: node `' lacks menu item for `Guix 
>> environment via direnv' despite being its Up target
>> ./doc/guix-cookbook.zh_Hans.texi:3014: warning: node prev `Acknowledgments' 
>> in menu `' and in sectioning `' differ
>> make[2]: *** [Makefile:5627: doc/guix-cookbook.zh_Hans.info] Error 1
>> make[2]: *** Waiting for unfinished jobs
>> Use of uninitialized value in hash element at 
>> /gnu/store/0n07srrsfkh6mpzq9m78p18674bci39r-texinfo-6.7/share/texinfo/Texinfo/Structuring.pm
>>  line 639.
>> ./doc/guix-cookbook.ko.texi:565: @node `??' previously defined
>> ./doc/guix-cookbook.ko.texi:319: here is the previous definition as @node
>> ./doc/guix-cookbook.ko.texi:781: @node `? ??' previously defined
>> ./doc/guix-cookbook.ko.texi:333: here is the previous definition as @node
>> ./doc/guix-cookbook.ko.texi:1332: @node `?? ??' previously defined
>> ./doc/guix-cookbook.ko.texi:579: here is the previous definition as @node
>> ./doc/guix-cookbook.ko.texi:1368: @node `??' previously defined
>> ./doc/guix-cookbook.ko.texi:319: here is the previous definition as @node
>> ./doc/guix-cookbook.ko.texi:1387: @node `? ??' previously defined
>> ./doc/guix-cookbook.ko.texi:333: here is the previous definition as @node
>> ./doc/guix-cookbook.ko.texi:2895: @node `?? ??' previously defined
>> ./doc/guix-cookbook.ko.texi:579: here is the previous definition as @node
>> ./doc/guix-cookbook.ko.texi:3048: @node `?? ??' previously defined
>> ./doc/guix-cookbook.ko.texi:579: here is the previous definition as @node
>> ./doc/guix-cookbook.ko.texi:319: warning: node next `??' in menu 
>> `? ??' and in sectioning `' differ
>> ./doc/guix-cookbook.ko.texi:333: warning: node `? ? ??' 
>> is next for `? ??' in menu but not in sectioning
>> ./doc/guix-cookbook.ko.texi:333: warning: node `??' is prev for 
>> `? ??' in menu but not in sectioning
>> ./doc/guix-cookbook.ko.texi:579: warning: node next `?? ??' in menu 
>> `? ???' and in sec

bug#51259: Cannot build Guix from source (error messages about the translations)

[Julien Lepiller]

Le Wed, 20 Oct 2021 12:40:17 +0200,
Raphaël Mélotte  a écrit :

> Hello,
> 
> On 10/20/21 4:06 AM, Julien Lepiller wrote:
> 
> > 
> > Since it seems this is due to the lack of the LC_ALL variable in the
> > pure environment, how about the attached patch?  
> 
> With the attached patch on top of master (c650160abb), the build
> fails with messages similar to this one:
> ./doc/guix.de.texi:158: @ref reference to nonexistent node
> `Translating Guix'
> 
> I attached the build logs.
> 
> I used the following to build, to make sure to start from a clean
> tree: ---
> git clean -ffdx && guix environment guix --pure --ad-hoc help2man git
> strace -- sh -c './bootstrap && ./configure --localstatedir=/var &&
> make' | tee build.log
> 
> ---
> 
> Kind regards,
> 
> Raphaël

So, it looks like my change prevented the xref command from running
altogether, which explains the error. Moving the variable definition
seems to help; I was able to build from a clean checkout in a pure
environment with the attached revised patch.
>From 9cf411955afe9d3cb95d8060bb37ce97fdcbacb0 Mon Sep 17 00:00:00 2001
Message-Id: <9cf411955afe9d3cb95d8060bb37ce97fdcbacb0.1634731604.git.jul...@lepiller.eu>
From: Julien Lepiller 
Date: Wed, 20 Oct 2021 04:02:06 +0200
Subject: [PATCH] doc: Set LC_ALL when translating xref commands.

* doc/local.mk (xref_command): Set LC_ALL.
---
 doc/local.mk | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/local.mk b/doc/local.mk
index fff11f8183..d0cab306a4 100644
--- a/doc/local.mk
+++ b/doc/local.mk
@@ -110,18 +110,18 @@ endef
 $(srcdir)/%D%/guix.%.texi: po/doc/guix-manual.%.po $(srcdir)/%D%/contributing.%.texi guix/build/po.go
 	-$(AM_V_PO4A)$(PO4A_TRANSLATE) $(PO4A_PARAMS) -m "%D%/guix.texi" -p "$<" -l "$@.tmp"
 	-sed -i "s|guix\.info|$$(basename "$@" | sed 's|texi$$|info|')|" "$@.tmp"
-	-$(AM_V_POXREF)$(xref_command)
+	-$(AM_V_POXREF)LC_ALL=en_US.UTF-8 $(xref_command)
 	-mv "$@.tmp" "$@"
 
 $(srcdir)/%D%/guix-cookbook.%.texi: po/doc/guix-cookbook.%.po guix/build/po.go
 	-$(AM_V_PO4A)$(PO4A_TRANSLATE) $(PO4A_PARAMS) -m "%D%/guix-cookbook.texi" -p "$<" -l "$@.tmp"
 	-sed -i "s|guix-cookbook\.info|$$(basename "$@" | sed 's|texi$$|info|')|" "$@.tmp"
-	-$(AM_V_POXREF)$(xref_command)
+	-$(AM_V_POXREF)LC_ALL=en_US.UTF-8 $(xref_command)
 	-mv "$@.tmp" "$@"
 
 $(srcdir)/%D%/contributing.%.texi: po/doc/guix-manual.%.po guix/build/po.go
 	-$(AM_V_PO4A)$(PO4A_TRANSLATE) $(PO4A_PARAMS) -m "%D%/contributing.texi" -p "$<" -l "$@.tmp"
-	-$(AM_V_POXREF)$(xref_command)
+	-$(AM_V_POXREF)LC_ALL=en_US.UTF-8 $(xref_command)
 	-mv "$@.tmp" "$@"
 
 %D%/os-config-%.texi: gnu/system/examples/%.tmpl
-- 
2.33.0

bug#51259: Cannot build Guix from source (error messages about the translations)

[Julien Lepiller]

Arg, I don't get why you get that one… I'll see what I can find. In the 
meantime, you can build the rest of guix locally with "make make-go", which 
doesn't depend on the manuals, although you won't be able to push with the 
prepush hook.

Le 20 octobre 2021 06:40:17 GMT-04:00, "Raphaël Mélotte" 
 a écrit :
>Hello,
>
>On 10/20/21 4:06 AM, Julien Lepiller wrote:
>
>> 
>> Since it seems this is due to the lack of the LC_ALL variable in the
>> pure environment, how about the attached patch?
>
>With the attached patch on top of master (c650160abb), the build fails with 
>messages similar to this one:
>./doc/guix.de.texi:158: @ref reference to nonexistent node `Translating Guix'
>
>I attached the build logs.
>
>I used the following to build, to make sure to start from a clean tree:
>---
>git clean -ffdx && guix environment guix --pure --ad-hoc help2man git strace 
>-- 
>sh -c './bootstrap && ./configure --localstatedir=/var && make' | tee build.log
>
>---
>
>Kind regards,
>
>Raphaël

bug#51294: Error/bug: bootstrapping a new guix source tree

[Julien Lepiller]

Le Wed, 20 Oct 2021 04:04:19 +0200,
Julien Lepiller  a écrit :

> I think this is the same as #35519?
> 
> 
> 

Sorry, I meant #51259

bug#51259: Cannot build Guix from source (error messages about the translations)

[Julien Lepiller]

Le Tue, 19 Oct 2021 12:29:47 +0200,
Raphaël Mélotte  a écrit :

> On 10/19/21 11:59 AM, Simon Streit wrote:
> > Extending my previous message:
> > 
> > I first thought that it had to do with commit
> > 15c91189cb61c579f4289047c79530cefe75215f, but it turns out that
> > commit 0623138ffa5b066afc25547ffdeb97753cb0ee9a creates these
> > errors.
> > 
> > Commit d1b375402f5680b1e5a77dd1fb77e1e9d94625d1 is okay.  
> Building on Debian 10, I was about to report the same.
>  From a git bisect I got:
> "0623138ffa5b066afc25547ffdeb97753cb0ee9a is the first bad commit".
> 
> I can confirm that in the meantime, compiling with $LC_ALL set
> manually (to the value of $LANG outside the environment) also worked
> for me: ---
> guix environment guix --pure --ad-hoc help2man git strace bash -- sh
> -c "export LC_ALL=$LANG && ./bootstrap && ./configure
> --localstatedir=/var && make ---
> 
> 
> Kind regards,
> 
> Raphaël
> 
> 
> 

Since it seems this is due to the lack of the LC_ALL variable in the
pure environment, how about the attached patch?
>From bcabc8a22e8462e9398d09efa1c9eef450fb02c4 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Julien Lepiller 
Date: Wed, 20 Oct 2021 04:02:06 +0200
Subject: [PATCH] doc: Set LC_ALL when translating xref commands.

* doc/local.mk (xref_command): Set LC_ALL.
---
 doc/local.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/local.mk b/doc/local.mk
index fff11f8183..751d0e5f90 100644
--- a/doc/local.mk
+++ b/doc/local.mk
@@ -102,7 +102,7 @@ PO4A_PARAMS += -f texinfo # texinfo format
 # reference is not translated, which means it references a section that does not
 # exist.
 define xref_command
-$(top_srcdir)/pre-inst-env $(GUILE) --no-auto-compile	\
+LC_ALL=en_US.UTF-8 $(top_srcdir)/pre-inst-env $(GUILE) --no-auto-compile	\
   "$(top_srcdir)/build-aux/convert-xref.scm"		\
   $@.tmp $<
 endef
-- 
2.33.0

bug#51294: Error/bug: bootstrapping a new guix source tree

[Julien Lepiller]

I think this is the same as #35519?

bug#51259: Cannot build Guix from source (error messages about the translations)

[Julien Lepiller]

I managed to reproduce the issue on fedora, in a broken pure environmert. In a 
pure environment, fedora gives error messages about software that doesn't 
exist, and asks if I want to install them. If I ^C at that point, I enter the 
environment, but some things are missing.

There are litteral ?? in manuals that don't use ascii, and this is especially 
visible in the korean manual. Po4a works fine in my experimentation, but it 
looks like the po parser or regular expression matching is broken at the POXREF 
phase, and everything is copied as literal ??.

Maybe setting LANG to a UTF-8 locale in the poxref rule would help? It didn't 
hix the issue in my case, but I think that's because I'm missing even more 
variables.

Le 18 octobre 2021 07:54:08 GMT-04:00, Tobias Geerinckx-Rice via Bug reports 
for GNU Guix  a écrit :
>Leo Famulari 写道：
>> ./doc/guix.ko.texi:431: here is the previous definition as @node
>> ./doc/guix.ko.texi:2065: @node `??' previously defined
>
>This seems to hint at a locale error, and indeed it was: when I 
>check out a fresh guix.git and build it in a recent ‘guix 
>environment guix’ on Guix System, I get the same error as you.
>
>When I repeat the exact same steps but first set
>
>   $ export LC_ALL=en_IE.utf8
>
>in the environment, the build goes swimmingly.
>
>I only ran each test once so it could be a coincidence, but I 
>doubt it.
>
>As for the actual error…
>
>> ./doc/guix.ko.texi:431: here is the previous definition as @node
>> ./doc/guix.ko.texi:2065: @node `??' previously defined
>
>At the risk of being naive: could it simply be that the missing 
>locale turns the Korean UTF-8 into a literal ‘??’, which of 
>course matches another mangled @node string of the same length?
>
>Kind regards,
>
>T G-R

bug#51259: Cannot build Guix from source (error messages about the translations)

[Julien Lepiller]

Hi Leo,

Looks like something is wrong with your setup… are you running in "guix 
environment guix"? What's your $LANG?

Le 18 octobre 2021 00:01:28 GMT-04:00, Leo Famulari  a 
écrit :
>I noticed today that I can't build Guix from a fresh Git checkout in the
>usual manner. Something goes wrong while building the Korean language
>info manual. I tested it several times and on two different computers,
>both x86_64.
>
>--
>$ guix describe
>Generation 23   Oct 18 2021 00:23:51(current)
>  guix 473ea16
>repository URL: https://git.savannah.gnu.org/git/guix.git
>branch: master
>commit: 473ea161a15a13e7d5e7e0724693c1931ff8daaa
>$ git describe
>v1.3.0-7022-g473ea161a1
>$ guix environment --pure guix
>$ ./bootstrap  && ./configure --localstatedir=/var && make -j1
>[... bootstrap and configure succeed ...]
>Updating ./doc/version.texi
>  MAKEINFO doc/guix.de.info
>  MAKEINFO doc/guix.es.info
>./doc/guix.es.texi:16554: warning: `.' or `,' must follow @xref, not p
>./doc/guix.es.texi:37439: warning: `.' or `,' must follow @xref, not p
>  MAKEINFO doc/guix.fa.info
>  MAKEINFO doc/guix.fr.info
>./doc/guix.fr.texi:12628: warning: `.' or `,' must follow @xref, not p
>  MAKEINFO doc/guix.it.info
>  MAKEINFO doc/guix.ko.info
>Use of uninitialized value in hash element at 
>/gnu/store/w8k9hcigvhzrlrblv8lgqj77sm3833rs-texinfo-6.7/share/texinfo/Texinfo/Structuring.pm
> line 639.
>Use of uninitialized value in hash element at 
>/gnu/store/w8k9hcigvhzrlrblv8lgqj77sm3833rs-texinfo-6.7/share/texinfo/Texinfo/Structuring.pm
> line 639.
>Use of uninitialized value in hash element at 
>/gnu/store/w8k9hcigvhzrlrblv8lgqj77sm3833rs-texinfo-6.7/share/texinfo/Texinfo/Structuring.pm
> line 639.
>./doc/guix.ko.texi:604: @node `??' previously defined
>./doc/guix.ko.texi:431: here is the previous definition as @node
>./doc/guix.ko.texi:2065: @node `??' previously defined
>./doc/guix.ko.texi:431: here is the previous definition as @node
>./doc/guix.ko.texi:2538: @node `?? ??' previously defined
>./doc/guix.ko.texi:2262: here is the previous definition as @node
>./doc/guix.ko.texi:2739: @node `' previously defined
>./doc/guix.ko.texi:884: here is the previous definition as @node
>./doc/guix.ko.texi:2940: @node `? ??' previously defined
>./doc/guix.ko.texi:2029: here is the previous definition as @node
>./doc/guix.ko.texi:2973: @node `??' previously defined
>./doc/guix.ko.texi:431: here is the previous definition as @node
>./doc/guix.ko.texi:4933: @node `??' previously defined
>./doc/guix.ko.texi:431: here is the previous definition as @node
>./doc/guix.ko.texi:5459: @node `??' previously defined
>./doc/guix.ko.texi:431: here is the previous definition as @node
>./doc/guix.ko.texi:10011: @node `' previously defined
>./doc/guix.ko.texi:884: here is the previous definition as @node
>./doc/guix.ko.texi:13272: @node `? ??' previously defined
>./doc/guix.ko.texi:2029: here is the previous definition as @node
>./doc/guix.ko.texi:14606: @node `' previously defined
>./doc/guix.ko.texi:884: here is the previous definition as @node
>./doc/guix.ko.texi:31230: @node `?? ?' previously defined
>./doc/guix.ko.texi:13804: here is the previous definition as @node
>./doc/guix.ko.texi:35444: @node `??' previously defined
>./doc/guix.ko.texi:431: here is the previous definition as @node
>./doc/guix.ko.texi:35642: @node `?? ?' previously defined
>./doc/guix.ko.texi:13804: here is the previous definition as @node
>doc/contributing.ko.texi:1: @node `??' previously defined
>./doc/guix.ko.texi:431: here is the previous definition as @node
>doc/contributing.ko.texi:31: @node `? ??' previously defined
>./doc/guix.ko.texi:2029: here is the previous definition as @node
>doc/contributing.ko.texi:229: @node `? ??' previously defined
>./doc/guix.ko.texi:2029: here is the previous definition as @node
>doc/contributing.ko.texi:318: @node `? ??' previously defined
>./doc/guix.ko.texi:2029: here is the previous definition as @node
>doc/contributing.ko.texi:423: @node `? ?? ?' previously 
>defined
>./doc/guix.ko.texi:2623: here is the previous definition as @node
>doc/contributing.ko.texi:690: @node `? ??' previously defined
>./doc/guix.ko.texi:2029: here is the previous definition as @node
>doc/contributing.ko.texi:777: @node `?? ?' previously defined
>./doc/guix.ko.texi:13804: here is the previous definition as @node
>doc/contributing.ko.texi:796: @node `??? ??' previously defined
>doc/contributing.ko.texi:762: here is the previous definition as @node
>doc/contributing.ko.texi:833: @node `??' previously defined
>./doc/guix.ko.texi:431: here is the previous definition as @node
>doc/contributing.ko.texi:869: @node `?? ??' previously defined
>./doc/guix.ko.texi:2262: here is the previous definition as @node
>doc/contributing.ko.texi:883: @node `