Re: linux-libre updates, timeliness

[Yasuaki Kudo]

Hi,

Just out of curiosity, is it the case if only Linux Kernel team itself 
separated the controversial (with GNU folks, at least ) aspect of Linux as 
some build option, we don't have to maintain this  "LinuxLibre" in the first 
place?

Cheers,
Yasu



> On Oct 5, 2020, at 22:53, Ludovic Courtès  wrote:
> 
> Hi Leo,
> 
> Leo Famulari  skribis:
> 
>> I just pushed commit 51eb3e11 [0], bringing our linux-libre kernel
>> packages up to date.
>> 
>> It's September 30 here. The commit is dated September 28, because that's
>> when I made it. These kernels were released upstream on September 26. 
> 
> Of course we can always do better, but I think 4 days is reasonable.
> 
>> Personally, I am okay with the risks implied by this kind of timeframe,
>> but as a distro we should try to do these updates more quickly. Ideally,
>> they should be updated as soon as the sources are available and the
>> packager has tested the changes. I am committed to helping maintain the
>> linux-libre packages, but I won't always update our packages right away.
>> 
>> Everyone can contribute here! Minor linux-libre kernel updates can be
>> relied upon to work. They almost never cause blocking problems, based on
>> the lack of bug reports about them.
> 
> What update, build, and testing recipe would you recommend to someone
> willing to help?
> 
> Thanks for your work, much appreciated!
> 
> Ludo’.
> 

Re: Release v1.2 timetable

[zimoun]

Hi,

On Mon, 5 Oct 2020 at 15:49, Ludovic Courtès  wrote:

> Would be nice!  There’s quite a lot of new material to translate now, so
> better leave people time to work on it.

Do we fix a "deadline"?  I mean a (movable) date as objective for
releasing?  Initially, I thought about Oct. 29th?  WDYT?

Danny told about i686 and arm from #43513 and #43591.
Marius sent in #41863 a comment about GDM.
Ludo did some progress on #39260.
I hope I could send a new version about guix-install.sh #43769
tomorrow, I mean it should be fixed before the end of this week.






Something is missing?

What is the status of the installer?

All the best,
simon

New French PO file for 'guix' (version 1.2.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix' has been submitted
by the French team of translators.  The file is available at:

https://translationproject.org/latest/guix/fr.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: File search progress: database review and question on triggers

[Pierre Neidhardt]

Hi Ludo!

Ludovic Courtès  writes:

> Nice!

Thanks!

> Could you post a summary of what you have done, what’s left to do, and
> how you’d like to integrate it?  (If you’ve already done it, my
> apologies, but you can resend a link.  :-))

What I've done: mostly a database benchmark.

- Textual database: slow and not lighter than SQLite.  Not worth it I believe.

- SQLite without full-text search: fast, supports classic patterns
  (e.g. "foo*bar") but does not support word permutations.

- SQLite with full-text search: fast, supports word permutations but
  does not support suffix-matching (e.g. "bar" won't match "foobar").
  Size is about the same as without full-text search.

- Include synopsis and descriptions.  Maybe we should include all fields
  that are searched by `guix search`.  This incurs a cost on the
  database size but it would fix the `guix search` speed issue.  Size
  increases by some 10 MiB.

I say we go with SQLite full-text search for now with all package
details.  Switching to without full-text search is just a matter of a
minor adjustment, which we can decide later when merging the final
patch.  Same if we decide not to include the description, synopsis, etc.

What's left to do:

- Populate the database on demand, either after a `guix build` or from a
  `guix filesearch...`.  This is important so that `guix filesearch`
  works on packages built locally.  If `guix build`, I need help to know
  where to plug it in.

- Adapt Cuirass so that it builds its file database.
  I need pointers to get started here.

- Sync the databases from the substitute server to the client when
  running `guix filesearch`.  For this I suggest we send the compressed
  database corresponding to a guix generation over the network (around
  10 MiB).  Not sure sending just the delta is worth it.

- Find a way to garbage-collect the database(s).  My intuition is that
  we should have 1 database per Guix checkout and when we `guix gc` a
  Guix checkout we collect the corresponding database.

  I would store the databases in /var/guix/...

Comments and help welcome! :)

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


signature.asc
Description: PGP signature

New Spanish PO file for 'guix' (version 1.2.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix' has been submitted
by the Spanish team of translators.  The file is available at:

https://translationproject.org/latest/guix/es.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Failing CI evaluation for staging branch

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> Guillaume Le Vaillant  skribis:
>
>> Ludovic Courtès  skribis:
>>
>>> Hi Guillaume,
>>>
>>> Guillaume Le Vaillant  skribis:
>>>
 Currently no substitutes are built for the testing branch because the
 evaluation fails. The log at https://ci.guix.gnu.org/eval/16794/log/raw
 ends with:
>>>
>>> You mean the ‘staging’ branch?
>>>
>>
>> Yes, I meant 'staging'. I often type 'testing' instead of 'staging',
>> probably that pesky muscle memory!.
>>
 guix/inferior.scm:247:2: ERROR:
   1. :
 [...]

 If I understand this correctly, there's a '#:builder' keyword somewhere
 that is causing a problem. Does someone know where it can come from, or
 how to fix the issue?
>>>
>>> Right.  I’d look at guix/build-system/asdf.scm:279:2 on that branch (per
>>> the inferior stack trace above).  Does that give useful info?
>>
>> I didn't see any obvious problem in that file; the strange thing is that
>> 'make', 'make as-derivation' and './pre-inst-env guix build ...' all
>> work fine.
>>
>> In a local branch I merged the current master (3699ed6) into staging
>> (de96ed1) and I'm going to try to start a local cuirass daemon to see
>> wether I can reproduce the issue or not.
>>
>> Given that merging master in staging hasn't been done in a while, should
>> I also push my updated staging branch, or maybe someone is already
>> working on it?
>
> Ok, I started a local Cuirass, I reproduced the evaluation failure, and
> I think I found the problem: Cuirass was choking on the definition of
> the ecl-slynk package. I fixed it and know the evaluation has
> been 'In progress...' for 15 minutes.
> Then, if the evaluation completes successfully, and if there are no
> objections, I'll push the updated staging branch.

The evaluation succeeded on my local Cuirass. Fix pushed to staging as
b6c55a723fab94bbf710c331fe62d839fb0bf6ad.


signature.asc
Description: PGP signature

New template for 'guix-manual' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'guix-manual' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/guix-manual-1.2.0-pre1.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://lepiller.eu/files/guix-1.2.0-pre1.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Failing CI evaluation for staging branch

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> Ludovic Courtès  skribis:
>
>> Hi Guillaume,
>>
>> Guillaume Le Vaillant  skribis:
>>
>>> Currently no substitutes are built for the testing branch because the
>>> evaluation fails. The log at https://ci.guix.gnu.org/eval/16794/log/raw
>>> ends with:
>>
>> You mean the ‘staging’ branch?
>>
>
> Yes, I meant 'staging'. I often type 'testing' instead of 'staging',
> probably that pesky muscle memory!.
>
>>> guix/inferior.scm:247:2: ERROR:
>>>   1. :
>>> [...]
>>>
>>> If I understand this correctly, there's a '#:builder' keyword somewhere
>>> that is causing a problem. Does someone know where it can come from, or
>>> how to fix the issue?
>>
>> Right.  I’d look at guix/build-system/asdf.scm:279:2 on that branch (per
>> the inferior stack trace above).  Does that give useful info?
>
> I didn't see any obvious problem in that file; the strange thing is that
> 'make', 'make as-derivation' and './pre-inst-env guix build ...' all
> work fine.
>
> In a local branch I merged the current master (3699ed6) into staging
> (de96ed1) and I'm going to try to start a local cuirass daemon to see
> wether I can reproduce the issue or not.
>
> Given that merging master in staging hasn't been done in a while, should
> I also push my updated staging branch, or maybe someone is already
> working on it?

Ok, I started a local Cuirass, I reproduced the evaluation failure, and
I think I found the problem: Cuirass was choking on the definition of
the ecl-slynk package. I fixed it and know the evaluation has
been 'In progress...' for 15 minutes.
Then, if the evaluation completes successfully, and if there are no
objections, I'll push the updated staging branch.


signature.asc
Description: PGP signature

New template for 'guix-packages' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'guix-packages' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/guix-packages-1.2.0-pre1.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://lepiller.eu/files/guix-1.2.0-pre1.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New template for 'guix' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'guix' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/guix-1.2.0-pre1.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://lepiller.eu/files/guix-1.2.0-pre1.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Rewriting inputs and ’arguments’ after patch #43578

[zimoun]

Hi Ludo,

On Mon, 5 Oct 2020 at 15:46, Ludovic Courtès  wrote:

> > Therefore, it is not possible to rewrite this “inputs“ (using the patch
> > [1]), as the dry-run shows:
> >
> > $ guix build emacs-magit --with-input=emacs-no-x=emacs-next -n
>
> AFAICS, it’s working as expected:
>
> --8<---cut here---start->8---
> $ guix gc --references $(guix build emacs-magit 
> --with-input=emacs-no-x=emacs-next -d --no-grafts) |grep emacs-next
> /gnu/store/8ffjg2961x30171i24pl7j9wafcbli2b-emacs-next-28.0.50.1-0.2ea3466.drv
> $ guix gc --references $(guix build emacs-magit 
> --with-input=emacs-no-x=emacs-next -d --no-grafts) |grep emacs-no-x
> --8<---cut here---end--->8---

Hum?  I believe what I see... I am sure about my previous example and
your example also speaks by itself...  Therefore, the most probable
seems to be a mistake between my keyboard and my chair. :-)
Sorry for the noise.

> Now, there dependencies in the graph that depend on ‘emacs-minimal’
> instead of ‘emacs-no-x’, so you’d probably also need to replace those.

Yep!  That's the point of 'package-with-emacs-next'.

Cheers,
simon

Re: Translating the web site

[Julien Lepiller]

Le 5 octobre 2020 08:15:26 GMT-04:00, "Ludovic Courtès"  a écrit :
>Hi Julien,
>
>Julien Lepiller  skribis:
>
>> I've sent them all an email. Let's see what they say.
>
>I think we’re done, no?

Unless I missed them, I still haven't got an answer from Mario Blättermann and 
Znavko.

I'm a bit worried that my messages ended up being filtered, as my mail server 
is so small. Can you try sending them something?

>
>Thanks,
>Ludo’.

Re: u-boot for beagleboard

[Ludovic Courtès]

Hi,

Miguel Ángel Arruga Vivas  skribis:

> I see two main possibilities for the "translation units" in these cases:
>
> - When the extra data is a "non-localizable string", I'd rather use a
>   format string for the template, and insert the data through the format
>   specifier, possibly with a message to the translators to make clearer
>   the inserted data if it isn't clearly deduced from the message:
> --8<--
> (let ((desc (format #f
> ;; TRANSLATORS: ~a is substituted by the board ids.
> (_ "Description.~{~% - Board: ~a~}~%")
> (list "id1" "id2" ... "idn"
>   ...)
> -->8--
>
> - In any other case, I'd concatenate them as two separate paragraphs[2]
>   and let the translators face them up separately:
>
> --8<--
> (let ((desc (format #f
> "~s~%~%~s" ; Translating this may be an overkill...
> (_ "First paragraph(s).")
> (_ "Other paragraph(s)."
>   ...)
> -->8--

Seconded.

See also the ‘--keyword’ options in po/guix/Makevars for the list of
keywords picked up for translation in Guix.

Ludo’.

Re: linux-libre updates, timeliness

[Ludovic Courtès]

Hi Leo,

Leo Famulari  skribis:

> I just pushed commit 51eb3e11 [0], bringing our linux-libre kernel
> packages up to date.
>
> It's September 30 here. The commit is dated September 28, because that's
> when I made it. These kernels were released upstream on September 26. 

Of course we can always do better, but I think 4 days is reasonable.

> Personally, I am okay with the risks implied by this kind of timeframe,
> but as a distro we should try to do these updates more quickly. Ideally,
> they should be updated as soon as the sources are available and the
> packager has tested the changes. I am committed to helping maintain the
> linux-libre packages, but I won't always update our packages right away.
>
> Everyone can contribute here! Minor linux-libre kernel updates can be
> relied upon to work. They almost never cause blocking problems, based on
> the lack of bug reports about them.

What update, build, and testing recipe would you recommend to someone
willing to help?

Thanks for your work, much appreciated!

Ludo’.

Re: Release v1.2 timetable

[Julien Lepiller]

To be clear, translate guix, guix-packages and guix-manual using the TP. 
Guix-cookbook and guix-website will not be available, so you can translate them 
directly.

Le 5 octobre 2020 08:38:32 GMT-04:00, "Miguel Ángel Arruga Vivas" 
 a écrit :
>Hi Julien,
>
>Julien Lepiller  writes:
>> I'll try sendinq them a tarball for 1.2. They won't accept new pot
>> files, but maybe they'll update existing ones.
>
>Maybe I'm loosing something between all the mail received through this
>list or on the IRC where I almost never connect to, but why wouldn't
>translationproject.org accept a new release of guix, guix-packages and
>guix-manual?  AFAIU it's calling make dist and sending them the
>tarball,
>plus or minus the associated pot files, am I wrong?
>
>On my side I'm working on the translations too, so I hope I have them
>ready for the release.  I'll try the proofread to the whole manual too
>if I have time enough. :-)
>
>Happy hacking!
>Miguel

Re: Release v1.2 timetable

[Ludovic Courtès]

Hi,

Julien Lepiller  skribis:

> I'll try sendinq them a tarball for 1.2.

Would be nice!  There’s quite a lot of new material to translate now, so
better leave people time to work on it.

> They won't accept new pot files, but maybe they'll update existing
> ones.

Sure.  The website POT files were rejected because we said we’d move
them away from the TP anyway, but the other POT files are still welcome
AIUI.

Thanks,
Ludo’.

Re: Rewriting inputs and ’arguments’ after patch #43578

[Ludovic Courtès]

Hi,

zimoun  skribis:

> Let consider the package ’emacs-magit’.  It does not depend on
> ’emacs-minimal’ but instead the argument is replaced by ’emacs-no-x’,
> see: 
>
>   (build-system emacs-build-system)
>   (arguments
>`(#:emacs ,emacs-no-x;module support is required
>  #:tests? #t
>
>
> which is for example confirmed by “guix graph –path”:
>
> $ guix graph --path emacs-magit emacs-minimal
> guix graph: error: no path from 'emacs-magit@2.90.1-6.7f486d4' to 
> 'emacs-minimal@27.1'
>
> $ guix graph --path emacs-magit emacs-no-x
> emacs-magit@2.90.1-6.7f486d4
> emacs-libgit@20200515-1.0ef8b13
> emacs-no-x@27.1
>
>
>
> Therefore, it is not possible to rewrite this “inputs“ (using the patch
> [1]), as the dry-run shows:
>
> $ guix build emacs-magit --with-input=emacs-no-x=emacs-next -n

AFAICS, it’s working as expected:

--8<---cut here---start->8---
$ guix gc --references $(guix build emacs-magit 
--with-input=emacs-no-x=emacs-next -d --no-grafts) |grep emacs-next
/gnu/store/8ffjg2961x30171i24pl7j9wafcbli2b-emacs-next-28.0.50.1-0.2ea3466.drv
$ guix gc --references $(guix build emacs-magit 
--with-input=emacs-no-x=emacs-next -d --no-grafts) |grep emacs-no-x
--8<---cut here---end--->8---

Now, there dependencies in the graph that depend on ‘emacs-minimal’
instead of ‘emacs-no-x’, so you’d probably also need to replace those.

HTH,
Ludo’.

Re: Building a library as both static and dynamic

[Ludovic Courtès]

Hi,

Greg Hogan  skribis:

> Is there a best practice or example for building a library twice, both
> static and dynamic? I submitted patch #43620, and in working on
> another library have the same issue. These are cmake builds with a
> parameter declaration for either a static or dynamic build, not
> both. I would like to create a single package with both “out” and
> “static” outputs, which looks to be standard across Guix.

Yes, a “static” output is the preferred method if you want to keep .a
files around.

> One idea is to run the configure / make / make install phases
> twice. modify-phases does not currently support copying phases (though
> add-after could work with the right function reference from
> cmake-build) and #:configure-flags would need to be set differently.

Build systems from Autoconf/Automake/Libtool and those using CMake can
produce both shared libraries (position-independent code, PIC) and
static libraries at once.  No need to run it twice.

HTH,
Ludo’.

Re: Mailing Lists List

[Ludovic Courtès]

Hi,

Greg Hogan  skribis:

> When I google for “guix mailing lists” I am directed to
>   https://savannah.gnu.org/mail/?group=guix 
> 
> which does not include guix-devel. It is returned as my second google link 
> and also of course listed on the Guix website but would be helpful to include 
> on Savannah.

I don’t know why this is the case; I’ve reported it to the Savannah
hackers, we’ll see.

It would be even nicer if  would show
up first.

Thanks,
Ludo’.

Re: Translating the web site

[Julien Lepiller]

Le 5 octobre 2020 08:17:59 GMT-04:00, "Ludovic Courtès"  a écrit :
>Hi Julien,
>
>Julien Lepiller  skribis:
>
>> Le 24 septembre 2020 03:25:56 GMT-04:00, "Ludovic Courtès"
> a écrit :
>>>Hi,
>>>
>>>Julien Lepiller  skribis:
>>>
 As soon as we can host the translation files on a separate project
>on
 savannah, we can get it running at translate.fedora-project.org
>>>
>>>Sounds good.  Do we need to host POT files on our side?  I naively
>>>though Weblate would host them.
>>
>> No, weblate works with a git repository: it clones a repo and
>presents translation files to the users. Wher a file it translated, it
>commits it locally and remotely.
>>
>>>
>>>A Savannah project would be a sledgehammer; what about having a
>>>sub-directory at guix.gnu.org with all the POT files?  All we’d need
>to
>>>do is add a couple of nginx ‘location’ blocks to the config in
>>>maintenance.git.
>>
>> So, we really need a git repository. I guess it could be hosted on,
>say, git.guix.gnu.org :)
>
>Can we agree on the next steps so that this issue doesn’t stall?
>
>My understanding is that we need:
>
>  1. A public Git repo with all the POT files.  We can file a support
> request at Savannah to get that under the ‘guix’ project.

Done, they're waiting for the copyright fixes.

>
>  2. Registration at fedora-project.org.
Done, but they're waiting for the repo above

>
>  3. Publicity so we actually get translations.
>
>Is that correct?
>
>I can help with #1, that’s my contribution.  :-)
>
>Thanks,
>Ludo’.

Re: Failing CI evaluation for staging branch

[Guillaume Le Vaillant]

Ludovic Courtès  skribis:

> Hi Guillaume,
>
> Guillaume Le Vaillant  skribis:
>
>> Currently no substitutes are built for the testing branch because the
>> evaluation fails. The log at https://ci.guix.gnu.org/eval/16794/log/raw
>> ends with:
>
> You mean the ‘staging’ branch?
>

Yes, I meant 'staging'. I often type 'testing' instead of 'staging',
probably that pesky muscle memory!.

>> guix/inferior.scm:247:2: ERROR:
>>   1. :
>>   arguments: (keyword-argument-error #f "Unrecognized keyword" () 
>> (#:builder))
>>   inferior: #< pid: pipe socket: #> 7f07952ae690> close: # version: (0 1 1) packages: 
>> #> table: 
>> #>>
>>   stack: ((#f ("ice-9/boot-9.scm" 1763 13)) (raise-exception 
>> ("ice-9/boot-9.scm" 1666 16)) (raise-exception ("ice-9/boot-9.scm" 1668 16)) 
>> (#f ("guix/build-system/asdf.scm" 279 2)) (thunk ("guix/packages.scm" 1397 
>> 22)) (package-derivation ("guix/packages.scm" 1079 16)) (job ("gnu/ci.scm" 
>> 383 24)) (filter-map ("srfi/srfi-1.scm" 690 23)) (#f ("gnu/ci.scm" 497 31)) 
>> (map1 ("srfi/srfi-1.scm" 585 17)) (append-map ("srfi/srfi-1.scm" 672 15)) 
>> (hydra-jobs ("gnu/ci.scm" 482 4)) (#f ("ice-9/eval.scm" 158 9)) (#f 
>> ("ice-9/eval.scm" 158 9)) (with-exception-handler ("ice-9/boot-9.scm" 1735 
>> 10)) (call-with-prompt ("ice-9/boot-9.scm" 717 2)) (dynamic-wind 
>> ("ice-9/boot-9.scm" 141 2)) (#f (#f #f #f)) (#f ("guix/repl.scm" 92 21)) 
>> (with-exception-handler ("ice-9/boot-9.scm" 1735 10)) 
>> (with-exception-handler ("ice-9/boot-9.scm" 1730 15)) (#f ("guix/repl.scm" 
>> 119 7)))
>>
>> If I understand this correctly, there's a '#:builder' keyword somewhere
>> that is causing a problem. Does someone know where it can come from, or
>> how to fix the issue?
>
> Right.  I’d look at guix/build-system/asdf.scm:279:2 on that branch (per
> the inferior stack trace above).  Does that give useful info?

I didn't see any obvious problem in that file; the strange thing is that
'make', 'make as-derivation' and './pre-inst-env guix build ...' all
work fine.

In a local branch I merged the current master (3699ed6) into staging
(de96ed1) and I'm going to try to start a local cuirass daemon to see
wether I can reproduce the issue or not.

Given that merging master in staging hasn't been done in a while, should
I also push my updated staging branch, or maybe someone is already
working on it?


signature.asc
Description: PGP signature

Re: Release v1.2 timetable

[Miguel Ángel Arruga Vivas]

Hi Julien,

Julien Lepiller  writes:
> I'll try sendinq them a tarball for 1.2. They won't accept new pot
> files, but maybe they'll update existing ones.

Maybe I'm loosing something between all the mail received through this
list or on the IRC where I almost never connect to, but why wouldn't
translationproject.org accept a new release of guix, guix-packages and
guix-manual?  AFAIU it's calling make dist and sending them the tarball,
plus or minus the associated pot files, am I wrong?

On my side I'm working on the translations too, so I hope I have them
ready for the release.  I'll try the proofread to the whole manual too
if I have time enough. :-)

Happy hacking!
Miguel

Re: File search progress: database review and question on triggers

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

> I've pushed a commit which adds the synopsis and the description to the
> database.
>
> 0127cfa5d089857a716bf7b0a167f31cc6dd
>
> The quite surprising result is that these new details only cost 1 MiB extra!
>
> I can then search packages and it's super fast:
>
>> ,time (search-package "org" "equival") 
> $51 = (("emacs-org-contrib"))
> ;; 0.002930s real time, 0.002925s run time.  0.00s spent in GC.
>
> My local database only includes the store items, that is to say some
> 1800 items, but even with the 15000 packages the search would not be
> impacted by much.  The size might grow by some 10 MiB though, but that's
> reasonable and it compresses very well (down to 6-7 MiB in zstd).

Nice!

Could you post a summary of what you have done, what’s left to do, and
how you’d like to integrate it?  (If you’ve already done it, my
apologies, but you can resend a link.  :-))

Thank you,
Ludo’.

Re: Problems with the test suite

[Ludovic Courtès]

Hi,

Jesse Gibbons  skribis:

> I'm still working on making 43193 ready to apply. I added a test, and
> it looks like my to the build script --with-source option broke
> something. I am getting error messages, but I don't know where in the
> code they are occurring. Is there any way I can get a stack trace when
> errors are raised during tests? I also noticed nearly all of the tests
> assert multiple things simultaneously, compounded by the `and`
> function. When one of those things is found to be false, the test
> fails, but I don't know which part of the assertion is false.

Could you show exactly the output you’re getting?

SRFI-64 ‘test-assert’ & co. report exceptions but they don’t show you
the backtrace.  The trick you can use to see the exception is to “lift”
your test expression outside ‘test-assert’:

  (test-assert "test my stuff
(begin my code …))

  =>

  (begin my code …)

> Are there any advantages to using Guix's custom testing API over other
> testing APIs like SRFI-64? If not, why not transition the test suite
> to use one of them?

Guix uses plain SRFI-64.

HTH,
Ludo’.

Re: branch master updated: gnu: gettext-minimal: Mark "test-raise" test XFAIL on the Hurd.

[Efraim Flashner]

On Mon, Oct 05, 2020 at 02:24:31PM +0200, Jan Nieuwenhuizen wrote:
> 
> Hi!
> 
> > commit 2fc298d19c5256eb5609aae7bd35bada59d91685
> > Author: Jan (janneke) Nieuwenhuizen 
> > AuthorDate: Mon Oct 5 11:58:16 2020 +0200
> >
> > gnu: gettext-minimal: Mark "test-raise" test XFAIL on the Hurd.
> > 
> > * gnu/packages/gettext.scm (gettext-minimal)[arguments]: When compiling 
> > for
> > the Hurd, add "test-raise" to XFAIL_TESTS in make-flags.
> 
> Some more info on this bug, it is this snippet that causes
> the test failure
> 
> --8<---cut here---start->8---
> #include 
> 
> int
> main (void)
> {
>   if (!raise (-1))
> return 1;
>   
>   return 0;
> }
> --8<---cut here---end--->8---
> 
> but only when linked against libpthread:
> 
> --8<---cut here---start->8---
> $ gcc raise.c
> $ ./a.out
> $ echo $?
> 0
> $ gcc raise.c 
> /gnu/store/9vs3gkp6svam82zw7vjlml7iiarcs11c-glibc-2.31/lib/libpthread.so.0.3
> $ ./a.out
> User defined signal 2
> $ echo $?
> 159
> --8<---cut here---end--->8---
> 
> Janneke
> 

I believe this commit also caused the guix data service to not want to
import more derivations.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: branch master updated: gnu: gettext-minimal: Mark "test-raise" test XFAIL on the Hurd.

[Jan Nieuwenhuizen]

Hi!

> commit 2fc298d19c5256eb5609aae7bd35bada59d91685
> Author: Jan (janneke) Nieuwenhuizen 
> AuthorDate: Mon Oct 5 11:58:16 2020 +0200
>
> gnu: gettext-minimal: Mark "test-raise" test XFAIL on the Hurd.
> 
> * gnu/packages/gettext.scm (gettext-minimal)[arguments]: When compiling 
> for
> the Hurd, add "test-raise" to XFAIL_TESTS in make-flags.

Some more info on this bug, it is this snippet that causes
the test failure

--8<---cut here---start->8---
#include 

int
main (void)
{
  if (!raise (-1))
return 1;
  
  return 0;
}
--8<---cut here---end--->8---

but only when linked against libpthread:

--8<---cut here---start->8---
$ gcc raise.c
$ ./a.out
$ echo $?
0
$ gcc raise.c 
/gnu/store/9vs3gkp6svam82zw7vjlml7iiarcs11c-glibc-2.31/lib/libpthread.so.0.3
$ ./a.out
User defined signal 2
$ echo $?
159
--8<---cut here---end--->8---

Janneke

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

Re: Failing CI evaluation for testing branch

[Ludovic Courtès]

Hi Guillaume,

Guillaume Le Vaillant  skribis:

> Currently no substitutes are built for the testing branch because the
> evaluation fails. The log at https://ci.guix.gnu.org/eval/16794/log/raw
> ends with:

You mean the ‘staging’ branch?

> guix/inferior.scm:247:2: ERROR:
>   1. :
>   arguments: (keyword-argument-error #f "Unrecognized keyword" () 
> (#:builder))
>   inferior: #< pid: pipe socket: # 7f07952ae690> close: # version: (0 1 1) packages: 
> #> table: 
> #>>
>   stack: ((#f ("ice-9/boot-9.scm" 1763 13)) (raise-exception 
> ("ice-9/boot-9.scm" 1666 16)) (raise-exception ("ice-9/boot-9.scm" 1668 16)) 
> (#f ("guix/build-system/asdf.scm" 279 2)) (thunk ("guix/packages.scm" 1397 
> 22)) (package-derivation ("guix/packages.scm" 1079 16)) (job ("gnu/ci.scm" 
> 383 24)) (filter-map ("srfi/srfi-1.scm" 690 23)) (#f ("gnu/ci.scm" 497 31)) 
> (map1 ("srfi/srfi-1.scm" 585 17)) (append-map ("srfi/srfi-1.scm" 672 15)) 
> (hydra-jobs ("gnu/ci.scm" 482 4)) (#f ("ice-9/eval.scm" 158 9)) (#f 
> ("ice-9/eval.scm" 158 9)) (with-exception-handler ("ice-9/boot-9.scm" 1735 
> 10)) (call-with-prompt ("ice-9/boot-9.scm" 717 2)) (dynamic-wind 
> ("ice-9/boot-9.scm" 141 2)) (#f (#f #f #f)) (#f ("guix/repl.scm" 92 21)) 
> (with-exception-handler ("ice-9/boot-9.scm" 1735 10)) (with-exception-handler 
> ("ice-9/boot-9.scm" 1730 15)) (#f ("guix/repl.scm" 119 7)))
>
> If I understand this correctly, there's a '#:builder' keyword somewhere
> that is causing a problem. Does someone know where it can come from, or
> how to fix the issue?

Right.  I’d look at guix/build-system/asdf.scm:279:2 on that branch (per
the inferior stack trace above).  Does that give useful info?

Thanks,
Ludo’.

Re: Problem bootstrapping Guix - "make update-guix-package" result: no code for module (gcrypt hash)

[Ludovic Courtès]

Hi,

Danny Milosavljevic  skribis:

> I'm trying to bootstrap current Guix (master) from Guix past (1.1.0 binary
> tarball).
>
> The goal is: I want to have only guix-the-package-manager at a specific guix
> commit (!) available inside a Docker image.

Why build Guix from source?  I guess it’s enough to do:

  guix pull --commit=XYZ

if all you want is Guix at commit XYZ.  Or am I missing something?

Thanks,
Ludo’.

Re: Translating the web site

[Ludovic Courtès]

Hi Julien,

Julien Lepiller  skribis:

> Le 24 septembre 2020 03:25:56 GMT-04:00, "Ludovic Courtès" 
>  a écrit :
>>Hi,
>>
>>Julien Lepiller  skribis:
>>
>>> As soon as we can host the translation files on a separate project on
>>> savannah, we can get it running at translate.fedora-project.org
>>
>>Sounds good.  Do we need to host POT files on our side?  I naively
>>though Weblate would host them.
>
> No, weblate works with a git repository: it clones a repo and presents 
> translation files to the users. Wher a file it translated, it commits it 
> locally and remotely.
>
>>
>>A Savannah project would be a sledgehammer; what about having a
>>sub-directory at guix.gnu.org with all the POT files?  All we’d need to
>>do is add a couple of nginx ‘location’ blocks to the config in
>>maintenance.git.
>
> So, we really need a git repository. I guess it could be hosted on, say, 
> git.guix.gnu.org :)

Can we agree on the next steps so that this issue doesn’t stall?

My understanding is that we need:

  1. A public Git repo with all the POT files.  We can file a support
 request at Savannah to get that under the ‘guix’ project.

  2. Registration at fedora-project.org.

  3. Publicity so we actually get translations.

Is that correct?

I can help with #1, that’s my contribution.  :-)

Thanks,
Ludo’.

Re: Translating the web site

[Ludovic Courtès]

Hi Julien,

Julien Lepiller  skribis:

> I've sent them all an email. Let's see what they say.

I think we’re done, no?

Thanks,
Ludo’.

Re: Release v1.2 timetable

[Julien Lepiller]

I'll try sendinq them a tarball for 1.2. They won't accept new pot files, but 
maybe they'll update existing ones. You can push directly whatever is not on 
the TP.

Le 5 octobre 2020 06:18:36 GMT-04:00, "pelzflorian (Florian Pelz)" 
 a écrit :
>On Tue, Sep 29, 2020 at 02:16:30PM +0200, zimoun wrote:
>> To help the release process, please:
>> […]
>>  d. translate
>
>Julien, shall I just push my translation without going through the TP?
>
>Regards,
>Florian

Re: u-boot for beagleboard

[Miguel Ángel Arruga Vivas]

Hi Vagrant and Danny,

First of all, I cannot start without saying: thank you for you effort
and time.

Danny Milosavljevic  writes:
> On Thu, 01 Oct 2020 10:15:40 -0700
> Vagrant Cascadian  wrote:
>> Maybe make-u-boot-package should be extended to support passing a list
>> of "common" names for boards, which could then be appended to the
>> description?
>
> Translators should say what they think about that.

As a translator I could have a personal say, but the best practices are
already encoded on gettext manual[1].

> (Long ago, I stopped doing string concatenations like this because
> translating that into some languages isn't easy)

Thank you for raising awareness of this.  I've seen plenty of bad
translations because of this anti-pattern, and some of them are
hilarious.

> Other than that, sure, something like that would be nice.
>
> Maybe just make it possible to add any sentence(s) to the description,
> though.  That should be translatable enough... I think.

I see two main possibilities for the "translation units" in these cases:

- When the extra data is a "non-localizable string", I'd rather use a
  format string for the template, and insert the data through the format
  specifier, possibly with a message to the translators to make clearer
  the inserted data if it isn't clearly deduced from the message:
--8<--
(let ((desc (format #f
;; TRANSLATORS: ~a is substituted by the board ids.
(_ "Description.~{~% - Board: ~a~}~%")
(list "id1" "id2" ... "idn"
  ...)
-->8--

- In any other case, I'd concatenate them as two separate paragraphs[2]
  and let the translators face them up separately:

--8<--
(let ((desc (format #f
"~s~%~%~s" ; Translating this may be an overkill...
(_ "First paragraph(s).")
(_ "Other paragraph(s)."
  ...)
-->8--

Happy hacking!
Miguel

[1] https://www.gnu.org/software/gettext/manual/gettext.html#Preparing-Strings

[2] My two cents: As a programmer use as few as possible implicit
references to each other paragraph, please. :-)
They are ok inside the same translation unit, but they can lead to
mismatches if the sentence is common and/or short enough to be used
somewhere else.

Re: Release v1.2 timetable

[pelzflorian (Florian Pelz)]

On Tue, Sep 29, 2020 at 02:16:30PM +0200, zimoun wrote:
> To help the release process, please:
> […]
>  d. translate

Julien, shall I just push my translation without going through the TP?

Regards,
Florian