Re: Removing/replacing “Guix in action” video from the home page?

[Joshua Branson]

I send a ton of time making videos online, so I can probably spare some
time to do this.  I'll have a video posted in a day or two.

Thanks,

Joshua

--
Joshua Branson
Sent from Emacs and Gnus
https://gnucode.me
https://video.hardlimit.com/accounts/joshua_branson/video-channels
"You can have whatever you want, as long as you help enough other people get 
what they want." - Zig Ziglar

Reproductibility, Data Services, guix weather

[zimoun]

Dear,

Recently, we discovered a regression in the Haskell build system:
introducing unreproducible builds.  Well, it was a kind of luck: I was
testing ’git-annex’ with the willing to have ’git-annex-assitant’
building it several times (--check) [1].

Aside this particular issue, ~10% of packages are not reproducible and I
am not convinced that “--check” is done by submitter/committer at each
update or new package.  Otherwise the case of unreproducible Mesa [2]
would raised before than June. :-)  (That’s fine, we need package after
all and we cannot fix the world all in the same time. :-))

The issue is to be able to find them.  I proposed (below) to run cron
task doing ’--check’ on the build farms and then report by email the
failure.  Chris indicated me the work they is doing [3] and instead of a
cron task, they is proposing to parse the JSON.  That’s what the tiny
script attached is doing.

   guix repl -L . -- weather-repro.scm

For example, I run:

   guix repl -L . -- weather-repro.scm | sort | grep ghc

to list (almost) all the unreproducible Haskell packages.  What I would
like is to be able to filter by build system for example.


First, Chris could you add the fields package name and version?  Because
it is hard to automatically reconstruct them by parsing the output-path.

Second, the revision of 
does not match the Guix commit.  Is it possible to have a bridge?  Other
said, how is computed this revision hash?

(A working revision is 6cf35799dec60723f37d83a559429aa8b90482d5 which
does not seems founding in Guix repo.)


Third, this tiny script is better than nothing but *far far away* form
perfect.  The question about tooling is: does it make sense to include
something like that directly in “guix weather”?  For example,

  guix weather --reproducible

or maybe under “guix challenge”?


WDYT?  Feedback and ideas are very welcome. :-)


All the best,
simon

PS: Below my question and the Chris’s answer.  Both deserve to be public
as Chris told me. :-)


1: 
2: 
3: 



 Start of forwarded message 
From: zimoun 
Subject: [guix-sysadmin] whishlist: Hook on the build-farm?
Date: Sun, 11 Oct 2020 17:19:26 +0200

Hi,

Currently, it is hard to catch:

  1. which commit breaks which package
  2. if the package builds reproductibly

Even if the Data services helps, *a lot!*.  There are still a lot of
manual actions to spot one or the other.  And I fully agree that the
work initiated by Chris is The Right Thing©.

However it is not ready and the man power is not extensible.  For the
#1, Danny have started a discussion. 


For the #2, I am proposing to add a cron task on one build-farm.  To be
concrete, let’s *randomly* pick 100 packages once a week, rebuild with
“--check“ and send by email the unreproducible packages.

Even, I am proposing: 1rst week 100 packages of build-system “foo”, 2nd
week 100 packages of build-system “bar”, 3rd week…

It is far from perfect but it seems a good heuristic to catch
regression, spot packages with reproducibility troubles, etc.  Note that
it should not happen since the committer should catch the
reproducibility issue; but as a matter of fact it is not the case.
Somehow, I am proposing a workaround.


I volunteer to be the recipient of these automatic emails, then I can do
some triage (remove false-positive, check what’s going, etc.)  and open
a bug report if there is an issue.

Currently, I do not have the CPU power to do so.  So I am asking if it
possible to put something like that on one of the building machines.  I
totally understand an answer as: « Simon, you are enthusiast and that’s
nice but no and go to hell! » :-)

Cheers,
simon
 End of forwarded message 

 Start of forwarded message 
From: Christopher Baines 
Subject: Re: [guix-sysadmin] whishlist: Hook on the build-farm?
Date: Sun, 11 Oct 2020 17:38:03 +0100

> Currently, I do not have the CPU power to do so.  So I am asking if it
> possible to put something like that on one of the building machines.  I
> totally understand an answer as: « Simon, you are enthusiast and that’s
> nice but no and go to hell! » :-)

I too would really like to be able to identify/prevent regressions,
including with respect to build reproducibility, and although the work
I'm doing on this is going slowly I'm hoping that with the Guix Build
Coordinator now I'll be able to get something sort of working.

I've just made a few tweaks to the Guix Data Service to make the data it
has on this a little easier to use.

This URL [1] should show you package reproducibility stats for each
architecture, computed from 

Re: Release v1.2 and Translation

[Miguel Ángel Arruga Vivas]

Hi,

First of all, thanks.  And second, to leave a clear statement about the
main point: I agree with your proposed time frame for the string freeze,
October 26th (freeze) to 29th (release).

zimoun  writes:
> Maybe I am missing something.

Probably this context helps: I've already uploaded to TP the translation
for the manual, so I can compare the "old" pot (the one uploaded to TP)
with the "new" one (the one I generated today on my machine).

> Now the translation 1.2.0-pre1 is open, so it is almost 3 weeks (even
> if I know it is maybe not enough, well we have to fix some deadlines
> somehow :-)).

Nobody likes deadlines---at least not me, hehe---but I believe they can
be really useful sometimes. :-)

> The last week, we could string freeze for polishing and not run after
> an always moving target.

Yup, that's the main advantage of freezing: you can focus as much as
possible on the little and not so little details, like bug hunting.

> From my point view, a longer freeze would not help to have the work
> done.  I do not know.  What do you think it could be better?

I agree that a longer string freeze wouldn't a big difference, and even
may hurt.  At least the manual is a huge work that probably cannot be
done in weeks from scratch, so I'm not thinking about the string freeze
as "the time frame to perform the translation" but "a time frame to
check the translation already done and fix last minute issues/features".

Besides, sorry if the word 'tight' sounded as a complaint meaning
protest, if so it'd really be a complaint meaning grief for my schedule,
as I'm unable to dedicate much time on working days.

Happy hacking and translation too!
Miguel

Re: Declarative /etc/guix/acl?

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello,

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

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

Janneke

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

Re: Release v1.2 and Translation

[zimoun]

Dear,

On Mon, 12 Oct 2020 at 18:16, Miguel Ángel Arruga Vivas
 wrote:

> > From my point of view, a string freeze starting on Mon. Oct. 26th
> > seems the easiest to synchronize all etc.
> > And unfreeze once the branch is create 
>
> Three days is a tight schedule, but could be enough if the number of
> changes keeps close to the current one (there are already 98 fragments
> without translation on guix-manual, none on guix and I didn't check
> guix-packages).

Maybe I am missing something.  Now the translation 1.2.0-pre1 is open,
so it is almost 3 weeks (even if I know it is maybe not enough, well
we have to fix some deadlines somehow :-)).
The last week, we could string freeze for polishing and not run after
an always moving target.
>From my point view, a longer freeze would not help to have the work
done.  I do not know.  What do you think it could be better?

All the best,
simon

Re: Continuous integration - automatic EMAIL

[zimoun]

Hi,

On Mon, 12 Oct 2020 at 14:06, Ludovic Courtès  wrote:

> >> Please, can we have the build servers send build failures to guix-devel
> >> instead of hoping that people check manually?  I have other things to do
> >> in my life than to poll random servers every few hours.
> >
> > That feature is definitely on my list. Fixing Cuirass and improving the
> > build throughput is already a hard task, but I'm getting there. In the
> > meantime, if people want to join Cuirass debugging party, they are more
> > than welcome!

[...]

> Caveat: my experience with Hydra is that you immediately receive too
> much mail.  Initially Hydra would send one message per failed build,
> which was then changed to one message at each status change (from
> “success” to “failure” and vice versa), but that was still too much.  I
> think eventually it was change to email only the committers of the
> offending commits, which is probably the best option.

If "guix weather -m" is improved, does it fill the gap?  Because it is
exactly doing what is required, isn't?  But it is not suitable for
this purpose because of UI.  I mean:

--8<---cut here---start->8---
$ cat /tmp/spec.scm
(specifications->manifest (list "emacs" "gcc-toolchain" "python-umap-learn"))

$ guix weather -m /tmp/spec.scm
computing 49 package derivations for x86_64-linux...
looking for 66 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
  97.0% substitutes available (64 out of 66)
  at least 340.7 MiB of nars (compressed)
  534.1 MiB on disk (uncompressed)
  0.001 seconds per request (0.0 seconds in total)
  1,768.0 requests per second
  'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
--8<---cut here---end--->8---

The information is here but I do not know which ones are fine and
which ones are failing.  If an option like "--raw" (or "--plain" or
"--exhaustive" or "--name-it" :-)) could display the status of all the
66 packages, then I think it would ease the detection of the
regresion.  For example,

  OK: emacs
  FAIL: python-umap-learn
  [...]

then it is doable to have a shell script parsing this output and I can
feed "git bisect".  Somehow.

WDYT?

All the best,
simon

New Brazilian Portuguese 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 Brazilian Portuguese team of translators.  The file is available at:

https://translationproject.org/latest/guix/pt_BR.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.

New French PO file for 'guix-packages' (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-packages' has been submitted
by the French team of translators.  The file is available at:

https://translationproject.org/latest/guix-packages/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-packages/

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-packages.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: Release v1.2 and Translation

[Miguel Ángel Arruga Vivas]

Hi simon and Ludo,

zimoun  writes:
> On Mon, 12 Oct 2020 at 14:30, Ludovic Courtès  wrote:
>> I agree that a string freeze would be nice… but it’s difficult.  There
>> are still a few patches out there (such as new package transformation
>> options) that will likely be merged soon.  That said, this is non-core
>> functionality, so maybe we can live with that.

Yup, I understand, and of course I don't want to slow the pace of the
project at all.  I guess that everybody understands (even expects) to
wait a bit for certain translation from time to time, specially when the
alternative means waiting for fancy new features. :-)

>> Anyway, if we’re aiming for Oct. 29th, perhaps we can do a last round a
>> week before?
>
> From my point of view, a string freeze starting on Mon. Oct. 26th
> seems the easiest to synchronize all etc.
> And unfreeze once the branch is create 

Three days is a tight schedule, but could be enough if the number of
changes keeps close to the current one (there are already 98 fragments
without translation on guix-manual, none on guix and I didn't check
guix-packages).

Nonetheless, probably after the branch generation, I'd like to remove
the paragraph that says "some fragments may be found in English" from
the release version of the Spanish manual (but keep it with the info
downloaded by guix pull), checking that it's true, obv.

Best regards,
Miguel

Re: Removing/replacing “Guix in action” video from the home page?

[Luis Felipe]

Hi,

‐‐‐ Original Message ‐‐‐
On Monday, October 12, 2020 12:59 PM, Ludovic Courtès  wrote:

> Hello Guix!
>
> The home page has a “Guix in action” video that’s becoming outdated. It
> would be nice to have an updated version of it using in particular the
> short aliases (‘guix search’, ‘guix install’, etc.). Perhaps we could
> use ‘emacs-gif-screencast’ to make it hopefully lightweight non-blurry
> (and with a larger font size).

Or maybe try with asciinema to record video. The problem I see with GIF for 
this is that people don't have playback control.

Re: Outreachy Applicant: An Introduction

[zimoun]

Hi,

On Mon, 12 Oct 2020 at 13:00, Magali Lemes  wrote:

> Guix was fairly easy to install, I used the shell script to do that.

Which distribution do you use?

> I installed emacs using Guix and it worked as expected.

Nice!
Personally, I manage the Emacs packages with Guix via a manifest.scm
file.  And in a separate profile.  My conf [1] is far from perfect but
if you need inspiration. :-)

1: 

> I'll begin by trying to package something. So, I'll go through the links you 
> sent
> and see how that goes.

Cool!
Do not hesitate to ask on help-guix or #guix if you encounter issues
on your path.  And feel free to send your progress, success or
failure.


All the best,
simon

Re: Translating the web site

[Julien Lepiller]

Yes, I think the goal is to translate everything through weblate, right?

Le 12 octobre 2020 08:29:32 GMT-04:00, "Ludovic Courtès"  a écrit 
:
>Hi again,
>
>Julien Lepiller  skribis:
>
>> Le 5 octobre 2020 08:17:59 GMT-04:00, "Ludovic Courtès"
> a écrit :
>
>[...]
>
>>>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.
>
>Something I must have misunderstood: this repo will contain all the POT
>files, not just those for the web site?
>
>Ludo’.

Re: Shipping more installer images?

[Danny Milosavljevic]

Hi Ludo,

On Mon, 12 Oct 2020 13:47:25 +0200
Ludovic Courtès  wrote:

> Mathieu Othacehe  skribis:
> 
> Keep in mind that images use space at ftp.gnu.org and also take time to
> build (having CI up-to-date helps with that, but it doesn’t not
> eliminate build times due to the ‘update-guix-package’ dance that takes
> place during “make release”.)
> 
> Likewise, if we ship more images, we should update the “System
> Installation” section accordingly and be clear about what users can
> expect.
> 
> I guess all I’m saying is that we should not make such decisions lightly
> and be sure to examine all the consequences.

I agree.

IMO there are only very few RYF-worthy ARM devices--and we should support
at least those, if we support any ARM devices at all.  That includes
providing images for those few (at least A20-EOMA68, A?0*Olinuxino*, and
Novena).

(Now that we use genimage in order to create guix images anyway, long term
we can also provide an importer and import essentially all ARM devices
from buildroot--but that can come later)


pgpyRhadDcRdb.pgp
Description: OpenPGP digital signature

Data Services: use cases

[zimoun]

Hi Chris,

Since blog post about Data Services seems floating around, I describe
what I find useful as an end-user of the service.  And if you have not
showed me IRL at FOSDEM (and you showed me several times ;-)), then I
would not be using the service so often.


To me, the entry point is always:

  

and to be exact .

Even, I have this Emacs trivial helper function:

--8<---cut here---start->8---
(defun my/guix-data (package)
  "Add URL of PACKAGE to `kill-ring'.

Yankable result:
`https://data.guix.gnu.org/repository/1/branch/master/package/PACKAGE/output-history'.

With `universal-argument', load URL using `browse-url'."
  (interactive "sPackage: ")
  (let ((url
 (format
  
"https://data.guix.gnu.org/repository/1/branch/master/package/%s/output-history;
 package)))
(kill-new url)
(when current-prefix-arg
  (browse-url url))
(message (format "%s killed." url
--8<---cut here---end--->8---

(This dumb function could be improved using “guix-emacs” with package
completion etc.  But the time to implement such thing is not worth for
me because I generally exactly know which package I look up. :-))


Let’s take the recent example of the package ’python-umap-learn’ [1].
>From the webpage, it is quick and easy to see which version build or
fail.  Then, once I know that:

   Version  Output  Builds  FromTo

“From” means the date of the first commit corresponding to Version ––
specifically at the derivation.  And “To” resp. the last commit.

Then I can click to say the “To” date of the last “Succeeded” build and
it leads to the webpage:

 

which provides the commit hash.  Now, it is easy to use the
time-machine:

   guix time-machine –commit=cac674d99dc4a332e6210c57ec7f1b8164f66642 \
– install python-umap-learn


Time to time, I click to “Failed Dependency” but I do not know how this
information is accurate.


Well, I could describe other use cases, but I think this one is really
useful for the end-user:

 - list all the versions available (since Dec. 2019 I guess)
 - know which build and which not
 - easily find the commit for “guix time-machine”


Cheers,
simon

1: 

Re: Release v1.2 and Translation

[zimoun]

On Mon, 12 Oct 2020 at 14:30, Ludovic Courtès  wrote:
> Miguel Ángel Arruga Vivas  skribis:
>
> > I've open http://issues.guix.gnu.org/issue/43934 with some minor details
> > I've found during translation, but I'd recommend to perform a complete
> > string freeze at some point before of the release to avoid these issues.
>
> I agree that a string freeze would be nice… but it’s difficult.  There
> are still a few patches out there (such as new package transformation
> options) that will likely be merged soon.  That said, this is non-core
> functionality, so maybe we can live with that.
>
> Anyway, if we’re aiming for Oct. 29th, perhaps we can do a last round a
> week before?

>From my point of view, a string freeze starting on Mon. Oct. 26th
seems the easiest to synchronize all etc.
And unfreeze once the branch is create 

Cheers,
simon

Removing/replacing “Guix in action” video from the home page?

[Ludovic Courtès]

Hello Guix!

The home page has a “Guix in action” video that’s becoming outdated.  It
would be nice to have an updated version of it using in particular the
short aliases (‘guix search’, ‘guix install’, etc.).  Perhaps we could
use ‘emacs-gif-screencast’ to make it hopefully lightweight non-blurry
(and with a larger font size).

There’s also some overlap with the “Everyday Guix video”, though it’s
not quite the same either.

Thoughts?  Any volunteers to produce an updated version?  :-)

Ludo’.

Re: Declarative /etc/guix/acl?

[Ludovic Courtès]

Hi,

Jan Nieuwenhuizen  skribis:

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

OK.

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

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

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

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

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

Ludo’.

Re: [BLOG] Running Guix System on a Linode Server

[Ludovic Courtès]

Hi,

Alexandru-Sergiu Marton  skribis:

> Since the post contains an invitation to run websites using Guix System,
> I thought to reply saying I've accepted the challenge (though without
> even knowing it existed!) I've been hosting my personal website [2] on a
> GNU Guix System VPS for the past month, and I have to say it's been an
> amazing experience. However I don't use Linode.

Thanks for sharing your experience!  It’s good to see more uses of Guix
System in this space.  I think it’s an area where one can immediately
reap the benefits of declarative OS configs.

Ludo’.

Localization of language names

[Ludovic Courtès]

Hi,

Brendan Tildesley  skribis:

> Languages listed in the language selection are sometimes in English,
> Rarely in the native language.

We take language names and their translations from the ‘iso-codes’
package, specifically the “iso_639-3” message catalog.  Quoth
(gnu installer newt locale):

(lambda (language)
  (let ((english (language-code->language-name iso639-languages
   language)))
(setenv "LANGUAGE" language)
(let ((native (gettext english "iso_639-3")))
  (unsetenv "LANGUAGE")
  native)))

I think this is the most exhaustive translation out there and what
everybody uses AIUI.

Do you see better translations in, say, the Debian or Ubuntu installers?

If so, that could indicate we’re doing something wrong, such as using
the wrong message catalog.

Thanks,
Ludo’.

Re: Outreachy contribution getting started.

[zimoun]

Hey!

Welcome!
And thank you for your interest in Guix.


Have you currently running Guix?

If no, the easiest is to start with the package manager [1] using the
shell script installer (first Red note in [1] :-)).  The package manager
works on any GNU/linux distribution and is not in conflict with the
distro package manager.  Do not hesitate to ask on help-g...@gnu.org or
#guix if you hit any problem, the Guix folks are prompt for
answering. :-) Once you can run "guix " [2], you can read how
to define a package [3].  BTW, give a look to the Perfect Setup [4] and
here [5] my config files if you need inspiration. ;-)

Well, if you have already used --- or currently using --- you can try
"guix import" or "guix refresh"; i.e., write your first package
contribution.  Therefore, you need to read [6].  Again, do not hesitate
to ask on help-g...@gnu.org or #guix if you hit any problem.

To be concrete, I suggest to read [3, 7, 8, 9, 10, 11, 12] and try to
package something.  Easy and good candidates for first packages are CRAN
or BioConductor packages:

   guix import cran 
   guix import cran -a bioconductor 

You can pick unpackaged one from the list [12].  Do not hesitate to ask
if you do not find an obvious one –– it should a good occasion to show
you “guix repl”. :-)


[1] 
http://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html#Binary-Installation
[2] 
http://guix.gnu.org/manual/devel/en/html_node/Getting-Started.html#Getting-Started
[3] 
http://guix.gnu.org/cookbook/en/html_node/Packaging-Tutorial.html#Packaging-Tutorial
[4] 
http://guix.gnu.org/manual/devel/en/html_node/The-Perfect-Setup.html#The-Perfect-Setup
[5] https://github.com/zimoun/my-conf
[6] http://guix.gnu.org/manual/devel/en/html_node/Contributing.html


7 : https://guix.gnu.org/manual/devel/en/guix.html#Defining-Packages
8 : https://guix.gnu.org/manual/devel/en/guix.html#Packaging-Guidelines
9 : https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-import
10: https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-refresh
11: https://guix.gnu.org/manual/devel/en/guix.html#Building-from-Git
12: https://bioconductor.org/packages/release/bioc/


All the best,
simon

Re: Translating the web site

[Ludovic Courtès]

Hi again,

Julien Lepiller  skribis:

> Le 5 octobre 2020 08:17:59 GMT-04:00, "Ludovic Courtès"  a 
> écrit :

[...]

>>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.

Something I must have misunderstood: this repo will contain all the POT
files, not just those for the web site?

Ludo’.

Re: Release v1.2 and Translation

[Ludovic Courtès]

Hi,

Miguel Ángel Arruga Vivas  skribis:

> I've open http://issues.guix.gnu.org/issue/43934 with some minor details
> I've found during translation, but I'd recommend to perform a complete
> string freeze at some point before of the release to avoid these issues.

I agree that a string freeze would be nice… but it’s difficult.  There
are still a few patches out there (such as new package transformation
options) that will likely be merged soon.  That said, this is non-core
functionality, so maybe we can live with that.

Anyway, if we’re aiming for Oct. 29th, perhaps we can do a last round a
week before?

Thanks!

Ludo’.

Re: Outreachy Applicant: An Introduction

[Magali Lemes]

Hi,
thank you for welcoming me!
Guix was fairly easy to install, I used the shell script to do that.
I installed emacs using Guix and it worked as expected.
I'll begin by trying to package something. So, I'll go through the links
you sent
and see how that goes.
Thanks again for all of your suggestions on how to start contributing.

Magali


Em sex., 9 de out. de 2020 às 17:10, zimoun 
escreveu:

> Hey Magali,
>
> Welcome!
> And thank you for your interest in Guix.
>
> On Fri, 9 Oct 2020 at 20:57, Magali Lemes  wrote:
>
> > I already installed the Guix package manager on Ubuntu and am going
> through some of the commands.
>
> Really cool!
> What is your feedback on the topic?  Easy to install?  Difficulties?
> Still unworking or unexpected behaviour?
>
>
> > Anyhow, I'm excited to know what my next steps could be. I truly
> appreciate an answer.
>
> There are different possible next steps, depending on your interest.
> In random order:
>
>  + See if you want to contribute to the translation effort.  If you
> are native of one of these languages:
>
>
>
> help is welcome!  For example, my first contribution to Guix was to
> read cover-to-cover the Guix manual and proofread the French
> translation.  Doing so is an unusual way to be familiar with the Guix
> ecosystem but really interesting.  Note that it would be part of this
> effort:
>   
>
>   + Try to package something of your interest.  You might read the
> Cookbook and the relevant part of the manual:
>
> <
> https://guix.gnu.org/cookbook/en/html_node/Packaging-Tutorial.html#Packaging-Tutorial
> >
> 
>
> Well, the easiest way is to create a new folder, say /tmp/foo and
> write your new package in the file /tmp/foo/example.scm and then:
>
>   guix show -L /tmp/foo 
>   guix build -L /tmp/foo 
>   guix build -L /tmp/foo  --no-grafts --check
>
> Once it builds reproducibly, you can try to include in master.  Well,
> raise the hand at this moment. :-)
>
>   + Tweak the source of Guix.
>
>   git clone https://git.savannah.gnu.org/git/guix.git
>   cd guix
>   guix environment guix --pure
>   ./bootstrap
>   ./configure --localstatedir=/var/
>make -j 8 # adapt
>make check
>./pre-inst-env guix help # the fresh compiled 'guix' ;-)
>
> You could be interested by
> .
>
> Well, then you can try to fix a bug  and I
> recommend one with the tag easy:
>
> 
>
>
> And in any case, feel free to ask _any_ question on help-g...@gnu.org
> or IRC #guix.
>
> Keep in touch.
> Cheers,
> simon
>

Outreachy contribution getting started.

[Aniket Patil]

Hi everyone,
I am Aniket Patil, an aspiring Outreachy Intern. I am interested in a
project called "
Add a subcommand showing GNU Guix history of all packages". I am
looking forward to working with guix team and mentors.


Aniket Patil.

Re: Hello from new Outreachy applicant

[Ludovic Courtès]

Hi Lulu,

Welcome!  :-)

zimoun  skribis:

> Basically, the key to success is communication.   Raise the hand _as
> soon as possible_.
>
> Then my advice is: everyday log what you are doing.  It may be only
> one or two lines, sometimes more.  Once a week (at least), collect the
> items and send me (privately) maybe with some patches or a branch to
> pull for testing.  The idea is to know your progress and your blocking
> points and then help you.  On a weekly or bi-weekly basis, voice (or
> video) chat with any mean which suits you (especially your timezone).

These sound like great ideas.

I would add that Outreachy is not just about technical contributions but
also about enabling the intern to become part of the group, possibly
serving as a model for contributors-to-be.  So I encourage you to
interact with the wider group in addition to your mentor, I think it can
be beneficial to all of us.

Thanks for joining!

Ludo’.

Re: Weird things found while fixing basic Guix packages

[Ludovic Courtès]

Hi,

Danny Milosavljevic  skribis:

> because I don't have another place to put this,

Please open individual bugs for things that are undoubtedly bugs, and
individual threads on guix-devel for other things.  IME the more focused
the message or bug report, the higher the chances to get useful
feedback!

Ludo’.

Re: 32-bit builds on 64-bit hardware/VMs

[Andreas Enge]

Hello,

On Mon, Oct 12, 2020 at 01:52:18PM +0200, Ludovic Courtès wrote:
> As a start, could you comment out in ‘machines-for-berlin.scm’ the
> machines that need to be removed in order to not run 32-bit builds in
> potentially buggy environments?

already done by Danny in commit 81b5eab1a85196725895502637e2540a1535ce8b
of the maintenance repository. However, that leaves only two machines
for armhf. If we had an image for the Novena board, I could set up one
or two more :)  In any case, it will not be enough to keep up with the
architecture.

Andreas

Re: Continuous integration - automatic EMAIL

[Ludovic Courtès]

Hi!

Mathieu Othacehe  skribis:

>> Please, can we have the build servers send build failures to guix-devel
>> instead of hoping that people check manually?  I have other things to do
>> in my life than to poll random servers every few hours.
>
> That feature is definitely on my list. Fixing Cuirass and improving the
> build throughput is already a hard task, but I'm getting there. In the
> meantime, if people want to join Cuirass debugging party, they are more
> than welcome!

Here’s my contribution: a Guile module using Mailutils to compose and
send messages:

  https://wiki.gnu.tools/git/gnu-tools-wiki/tree/code/modules/email.scm

The only thing that’s missing is a proper setup for outgoing mail from
guix.gnu.org, presumably with OpenSMTPD.  The config is here:

  https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm

If someone would like to help, please send a patch!  :-)  We can also
adjust the MX record for guix.gnu.org at our will:

  
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/dns.scm


Caveat: my experience with Hydra is that you immediately receive too
much mail.  Initially Hydra would send one message per failed build,
which was then changed to one message at each status change (from
“success” to “failure” and vice versa), but that was still too much.  I
think eventually it was change to email only the committers of the
offending commits, which is probably the best option.

Thanks,
Ludo’.

32-bit builds on 64-bit hardware/VMs

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> On Wed, 7 Oct 2020 16:51:46 +0200
> zimoun  wrote:
>
>> I have read Bug #43513 and Patch #43591 [1,2] and the table [3] is not
>> really encouraging. :-(
>
> This bug has serious repercussions for bootstrapping--and thus for the entire
> GNU Guix distribution (not to mention those other distributions which do not
> enable large file support).  If I were glibc I would be recalling their
> last few releases and would be telling everyone not to use those releases.

I think we need less drama and more pragmatism.  :-)

Evidently, we’ve lived with those bugs for years just fine.

So I think we need to focus on the short-term plan for 1.2, which cannot
be a full rebuild.

As a start, could you comment out in ‘machines-for-berlin.scm’ the
machines that need to be removed in order to not run 32-bit builds in
potentially buggy environments?

(I’m sorry that I haven’t been able to contribute more to the discussion
around all the work you’ve done, but I’m really overwhelmed by
information and feel unable to determine the severity of the problem.)

Thanks,
Ludo’.

Shipping more installer images?

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> I'm actually not really sure how one would use the installer on one of
>> the boards. I think the bare-bones disk-images would be best; just
>> download it and flash it onto the board or an SD card and edit
>> /etc/config.scm to add your user and services. Or to boot up into the
>> installer and overwrite itself.
>
> The CI is already building substitutes for two images
> (hurd-barebones-qcow2-image and pine64-barebones-raw-image). We could
> maybe release 1.2 version of those images.

Keep in mind that images use space at ftp.gnu.org and also take time to
build (having CI up-to-date helps with that, but it doesn’t not
eliminate build times due to the ‘update-guix-package’ dance that takes
place during “make release”.)

Likewise, if we ship more images, we should update the “System
Installation” section accordingly and be clear about what users can
expect.

I guess all I’m saying is that we should not make such decisions lightly
and be sure to examine all the consequences.

Thanks,
Ludo’.

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

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi!

> Jan Nieuwenhuizen  skribis:
>
>>> 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
>>
>> #include 
>>
>> int
>> main (void)
>> {
>>   if (!raise (-1))
>> return 1;
>>   
>>   return 0;
>> }
>
> I don’t know if it’s relevant here, but you should always use ‘-pthread’
> both at compile time and link time:
>
>   gcc raise.c -pthread
>
> That typically defines a few macros that may or may not have an effect
> on the code at hand.

Ah...right.  Makes no difference, though:

root@childhurd ~# guix environment --bootstrap --ad-hoc gcc-toolchain@7
root@childhurd ~ [env]# gcc raise.c
root@childhurd ~ [env]# ./a.out
root@childhurd ~ [env]# echo $?
0
root@childhurd ~ [env]# gcc raise.c -pthread
root@childhurd ~ [env]# ./a.out
User defined signal 2
root@childhurd ~ [env]# echo $?
159

Greetings,
Janneke

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

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

[zimoun]

On Mon, 12 Oct 2020 at 12:20, Ludovic Courtès  wrote:

>> - 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.
>
> Oh so this is going beyond file search, right?
>
> Perhaps it would make sense to focus on file search only as a first
> step, and see what can be done with synopses/descriptions (like Arun and
> zimoun did before) later, separately?

Well, the first patch set that Arun sent for improving “guix search” was
the introduction of a SQLite database, replacing the current
’package.cache’.  And I quote your wise advice:

I would rather keep the current package cache as-is instead of
inserting sqlite in here.  I don’t expect it to bring much
compared performance-wise to the current simple cache
(especially if we look at load time), and it does increase
complexity quite a bit.

However, using sqlite for keyword search as you initially
proposed on guix-devel does sound like a great idea to me.

Message-ID: <87sgjhx92g@gnu.org>


Therefore, if Pierre is going to introduce a SQL database where the
addition of the synopses/descriptions is cheap, it seems a good idea to
use it, isn’t it?  Keeping the ’package.cache’ as-is.  And in parallel,
“we“ can try to use this WIP branch for improving the speed of “guix
search” (by “we”, I mean that I plan to work on).

BTW, somehow, it would be really easy to remove these 2 extra fields if
it is not concluding for search, since it is only the function
’add-files’:

--8<---cut here---start->8---
(with-statement
db
(string-append "insert into Info (name, synopsis, description, package)"
   " values (:name, :synopsis, :description, :id)")
stmt
  (sqlite-bind-arguments stmt
 #:name name
 #:synopsis synopsis
 #:description description
 #:id id)
--8<---cut here---end--->8---

and used only once by ’persist-package-files’.



> It would be nice to see whether/how this could be integrated with
> third-party channels.  Of course it’s not a priority, but while
> designing this feature, we should keep in mind that we might want
> third-party channel authors to be able to offer such a database for
> their packages.

If the third-party channels also provides substitutes, then it would be
part of the substitutes, or easy to build from the substitute meta-data.



>> - 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.
>
> If we download a fresh database every time, we might as well simply
> overwrite the one we have?

But you do not want to download it again if you roll-back for example.
>From my point of view, it should be the same mechanism as
’package.cache’.


Cheers,
simon

Re: First impressions from delving into Guix

[Lulu]

> On 2020-10-11 18:36 Julien Lepiller  wrote:
> 
> From what I understand, outreachy has a contribution period during which you
> need to register at least one successful contribution with the project. Out of
> the potential interns who submitted a contribution, we then have to select one
> to work on the project. Well if you can finish the project before it even 
> starts
> it's great, but you'll be left with nothing to do ^^"

Oh, I see! It seems I misunderstood the process then; I thought I was supposed
to do one of the given tasks during this term. ^^;

With this in mind, I'll work on packaging for the time being. Thanks for the
clarification! :-)

--
Lulu

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

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

> Of course, `guix filesearch` hasn't been implemented yet ;)
>
> We still need to decide whether we want to make it part of `guix search'
> or define a separate command.

I would lean towards keeping it separate, so that it’s an optional
feature (given that it relies on downloading an external database).

Thanks,
Ludo’.

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

[Ludovic Courtès]

Hi!

Pierre Neidhardt  skribis:

>> 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.

Oh so this is going beyond file search, right?

Perhaps it would make sense to focus on file search only as a first
step, and see what can be done with synopses/descriptions (like Arun and
zimoun did before) later, separately?

> 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.

It would be nice to see whether/how this could be integrated with
third-party channels.  Of course it’s not a priority, but while
designing this feature, we should keep in mind that we might want
third-party channel authors to be able to offer such a database for
their packages.

> - 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.

If we download a fresh database every time, we might as well simply
overwrite the one we have?

Thanks,
Ludo’.

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

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen  skribis:

>> 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
>
> #include 
>
> int
> main (void)
> {
>   if (!raise (-1))
> return 1;
>   
>   return 0;
> }
>
>
> but only when linked against libpthread:
>
> $ gcc raise.c
> $ ./a.out
> $ echo $?
> 0
> $ gcc raise.c 
> /gnu/store/9vs3gkp6svam82zw7vjlml7iiarcs11c-glibc-2.31/lib/libpthread.so.0.3

I don’t know if it’s relevant here, but you should always use ‘-pthread’
both at compile time and link time:

  gcc raise.c -pthread

That typically defines a few macros that may or may not have an effect
on the code at hand.

Thanks,
Ludo’.

Re: Translating the web site

[Ludovic Courtès]

Hi,

Julien Lepiller  skribis:

> 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?

I’ve pinged them.

Thanks,
Ludo’.

Re: Translating the web site

[Ludovic Courtès]

Hi,

Joshua Branson  skribis:

> I could help for #3.
>
> I've been known to make videos.  If you guys want publicity for this,
> would anyone want to be interviewed by me?  Maybe just a 10 minute
> meet.jit.si interview talking about why guix is so cool, and why
> translation of software is so vital.  I live in U.S., but I'm willing to
> lose a little bit of sleep to get the word out.

That could be nice.  Likewise, I know Florian has already written a blog
post about this, which is “just” waiting for the translation process to
be set up.

Thanks,
Ludo’.

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

[Danny Milosavljevic]

Hi Ludo,

On Mon, 05 Oct 2020 14:20:08 +0200
Ludovic Courtès  wrote:

> 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?

I'm doing a project for Heads where we are trying to switch over their build
system to something that makes their builds more reproducible (for example
Guix).

They are using github and gitlab test runners for a lot of things, so one of
the ways we are trying to do continuous integration is to do the following:

(1) Have guix-the-package-manager be built and published on
repository.gitlab.com.  It eventually does "./pre-inst-env guix pack guix"
and then puts the result into a new docker container.  I can't see how to do 
that
after a guix pull.  Note that I don't want to also carry garbage (this entire
thing has to be verified for security eventually, so...).  Currently, guix
is being bootstrapped from Alpine, and I don't want Alpine to remain in there.

(2) Use the result in order to build boards using tiny Dockerfiles
which would just say

  FROM repository.gitlab.com/guix-on-docker
  RUN guix build heads-kgpe-d16

and throw away the derivation (or publish it, too?)--but keep the log file
and exit status.

Note that (1) should pin a specific Guix commit for a long time since Heads
does not want to build on a moving target since they do hash verification
on bootup, and firmware is hard to keep working (i.e. someone has to
manually verify, on real hardware, whether stuff still works after an
update of the toolchain).  And Heads basically is ONLY security-relevant
stuff.

But you are right--I'll now instead just guix gc and then copy /gnu and
/var/guix and /etc/guix into a "FROM scratch" Docker image.


pgpkeQX5Swr8I.pgp
Description: OpenPGP digital signature

Re: Guix Europe yearly assembly minutes

[Tanguy Le Carrour]

Hi Andeas, Hi Guix,


Le 10/10, Andreas Enge a écrit :
> the minutes of the yearly assembly of Guix Europe, which we held last June,
> are finally online:
>
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/guix-europe/minutes/ga-20200621.txt

Sorry if my question is a bit silly, but… what exactly is "Guix Europe"?

I read the statute [1], but could not find an "official" web page for
the association, only a thread with a dead link [2] and page on a totally 
unrelated
website [3].

[1]: 
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/guix-europe/statuts/
[2]: https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00108.html
[3]: 
https://www.gralon.net/mairies-france/gironde/association-guix-europe-bordeaux_W332019708.htm

Did I miss something?

Regards

-- 
Tanguy