Re: [fr] Moment de convivialité Guix@Paris en mai

[Tanguy LE CARROUR]

Quoting Tanguy LE CARROUR (2024-05-15 08:24:18)
> Sans vouloir divulgacher, je vous proposerais bien de rejoindre en direct la
> *Patch review session* pour écouter l’intervention de Ludo’.

Guix@Paris a rejoint la Patch Review Session [1] !

Je ne peux malheureusement pas rejoindre cette conférence et le salon Guix@Paris
habituel. N’hésitez pas à venir dire bonjour à Guix sur 
https://meet.jit.si/london-guix-meetup.

[1]: https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en mai

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Pour rappel, Guix@Paris c'est demain soir ! 
C'est toujours à 19h et c'est toujours au local de l'April… ou chez Easter-eggs,
juste en face.

**Attention**, ce sera sûrement la dernière avant la trêve estivale !

Sans vouloir divulgacher, je vous proposerais bien de rejoindre en direct la
*Patch review session* pour écouter l’intervention de Ludo’.

Au plaisir de vous y rencontrer,


-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en mai

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French… and in person.)

Bonjour Guix,

Le jeudi 16 mai 2024 à 19h, se tiendra la huitième édition de Guix@Paris
ouverte au public.
Comme les fois précédentes, il sera possible de participer à distance
(*cf* ci-dessous).

**Attention**, ce sera sûrement la dernière avant la trêve estivale !


## Programme

Il n'y a pas vraiment de programme… pour le moment ! À vous de proposer
des sujets en avance si vous voulez partager sur des sujets particuliers.
Le but est toujours que les utilisat·rice·eur·s de Guix
—ou futur·e·s utilisat·rice·eur·s !—, dans la région parisienne se
rencontrent et qu'ielles puissent discuter de Guix, Guile ou autres.

L'idée est surtout de passer un moment convivial en mettant des visages
sur des noms. Se rencontrer quoi ! 

Il n'y a pas d'expérience pré-requise et vous êtes tout·e·s les bienvenu·e·s.


## Logistique

Vous pouvez nous dire si vous comptez venir en répondant à ce message,
mais vous serez aussi les bienvenu·e·s au dernier moment ! 

Nous nous occupons des tables, des chaises, des prises électriques et
du vidéo-projecteur. Il y aura aussi de quoi boire et grignoter, mais
vous pouvez apporter ce qui vous ferait plaisir.


## Participation à distance

Sauf annonce contraire, il sera possible de participer à distance
*via* l'instance Jitsi Meet d'Easter-eggs :
.


## Accès

Nous serons accueilli·e·s dans les locaux de l'[April][1], elle même hébergée
par [Easter-eggs][2] :

```
Association April
44/46 rue de l'Ouest (cour intérieure)
Bâtiment 8
75014 Paris

Stations de Métro : Gaîté, Montparnasse, Pernety.

OpenStreetMap : .
```

[1]: https://april.org "April, promouvoir et défendre le logiciel libre"
[2]: https://easter-eggs.com/Presentation-d-Easter-eggs "Easter-eggs"


Au plaisir de vous y rencontrer !

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en avril

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Merci à toutes celles et ceux qui ont bravé… la promiscuité pour venir
discuter de Guix et d’autres sujets hier soir !
Je vais sérieusement envisager de repasser côté April, histoire que
nous puissions avoir un peu plus de place pour… respirer ! 

Je vous souhaite une excellente journée et vous dit au mois prochain !

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en avril

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Pour rappel, Guix@Paris c'est demain soir ! 
C'est toujours à 19h au local de l'April… ou chez Easter-eggs. Et pour
celles et ceux qui ne veulent pas braver la circulation parisienne,
c’est en direct *live* sur .

Au plaisir de vous y rencontrer,

-- 
Tanguy

[fr] Moment de convivialité Guix@Paris en avril

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French… and in person.)

Bonjour Guix,

Le jeudi 11 avril 2024 à 19h, se tiendra la septième édition de Guix@Paris
ouverte au public.
Comme les fois précédentes, il sera possible de participer à distance
(*cf* ci-dessous).


## Programme

Il n'y a pas vraiment de programme… pour le moment ! À vous de proposer
des sujets en avance si vous voulez partager sur des sujets particuliers.
Le but est toujours que les utilisat·rice·eur·s de Guix
—ou futur·e·s utilisat·rice·eur·s !—, dans la région parisienne se
rencontrent et qu'ielles puissent discuter de Guix, Guile ou autres.

L'idée est surtout de passer un moment convivial en mettant des visages
sur des noms. Se rencontrer quoi ! 

Il n'y a pas d'expérience pré-requise et vous êtes tout·e·s les bienvenu·e·s.


## Logistique

Vous pouvez nous dire si vous comptez venir en répondant à ce message,
mais vous serez aussi les bienvenu·e·s au dernier moment ! 

Nous nous occupons des tables, des chaises, des prises électriques et
du vidéo-projecteur. Il y aura aussi de quoi boire et grignoter, mais
vous pouvez apporter ce qui vous ferait plaisir.


## Participation à distance

Sauf annonce contraire, il sera possible de participer à distance
*via* l'instance Jitsi Meet d'Easter-eggs :
.


## Accès

Nous serons accueilli·e·s dans les locaux de l'[April][1], elle même hébergée
par [Easter-eggs][2] :

```
Association April
44/46 rue de l'Ouest (cour intérieure)
Bâtiment 8
75014 Paris

Stations de Métro : Gaîté, Montparnasse, Pernety.

OpenStreetMap : .
```

[1]: https://april.org "April, promouvoir et défendre le logiciel libre"
[2]: https://easter-eggs.com/Presentation-d-Easter-eggs "Easter-eggs"


Au plaisir de vous y rencontrer !

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en mars

[Tanguy LE CARROUR]

Salut Thomas,

Comme convenu, voici le lien pour le réseau Libre Entreprise :
https://libre-entreprise.org/entreprises

Bonnne journée et… bon entretien ! 爛

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en mars

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Merci aux personnes qui ont bravé les transports, ou la circulation
parisienne, pour participer au Guix@Paris d’hier soir !
Merci en particulier à V et T qui m’ont donné la motivation, le code et
le coup de pied au derrière nécessaire pour faire fonctionner Pipewire ! 

Au plaisir de vous retrouver le mois prochain !

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en mars

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Pour rappel, Guix@Paris c'est demain soir ! 
C'est toujours à 19h… et, pas si exceptionnellement que ça,
ce sera chez Easter-eggs ! C'est juste en face de l’April,
à 5 mètres !

Au plaisir de vous y rencontrer,

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en mars

[Tanguy LE CARROUR]

Bonjour Thomas,


Quoting Thomas Ieong (2024-02-29 14:49:36)
> Ca fait un moment que j'ai envie de venir mais les dates s'accordaient
> pas, j'ai enfin du temps ;)

Comme quoi, il ne faut jamais se décourager ! 

À dans 2 semaines alors.

-- 
Tanguy

[fr] Moment de convivialité Guix@Paris en mars

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French… and in person.)

Bonjour Guix,

Le jeudi 14 mars 2024 à 19h, se tiendra la sixième édition de Guix@Paris
ouverte au public.
Comme les fois précédentes, il sera possible de participer à distance
(*cf* ci-dessous).


## Programme

Il n'y a pas vraiment de programme… pour le moment ! À vous de proposer
des sujets en avance si vous voulez partager sur des sujets particuliers.
Le but est toujours que les utilisat·rice·eur·s de Guix
—ou futur·e·s utilisat·rice·eur·s !—, dans la région parisienne se
rencontrent et qu'ielles puissent discuter de Guix, Guile ou autres.

L'idée est surtout de passer un moment convivial en mettant des visages
sur des noms. Se rencontrer quoi ! 

Il n'y a pas d'expérience pré-requise et vous êtes tout·e·s les bienvenu·e·s.


## Logistique

Vous pouvez nous dire si vous comptez venir en répondant à ce message,
mais vous serez aussi les bienvenu·e·s au dernier moment ! 

Nous nous occupons des tables, des chaises, des prises électriques et
du vidéo-projecteur. Il y aura aussi de quoi boire et grignoter, mais
vous pouvez apporter ce qui vous ferait plaisir.


## Participation à distance

Sauf annonce contraire, il sera possible de participer à distance
*via* l'instance Jitsi Meet d'Easter-eggs :
.


## Accès

Nous serons accueilli·e·s dans les locaux de l'[April][1], elle même hébergée
par [Easter-eggs][2] :

```
Association April
44/46 rue de l'Ouest (cour intérieure)
Bâtiment 8
75014 Paris

Stations de Métro : Gaîté, Montparnasse, Pernety.

OpenStreetMap : .
```

[1]: https://april.org "April, promouvoir et défendre le logiciel libre"
[2]: https://easter-eggs.com/Presentation-d-Easter-eggs "Easter-eggs"


Au plaisir de vous y rencontrer !

-- 
Tanguy

Re: On the road to the next release: testing the installer

[Tanguy LE CARROUR]

Hi Romain,


Quoting Romain (2024-02-10 13:35:14)
> On February 10, 2024 11:35:56 AM GMT+01:00, Josselin Poiret 
>  wrote:
> >Tanguy LE CARROUR  writes:
> >
> >> Grub asked me right away my passphrase and… it did not work! 
> >> […]
> >
> >We don't try to embed the required keymap in the GRUB image and load it
> >early on.  It shouldn't be too hard, but would require a bit of
> >refactoring.
> 
> I started looking at this issue as I am also using full encryption with Guix 
> system.
> If someone familiar with the grub-bootloader module would give me a few 
> pointers, I'd be happy to work on fixing it. AFAIR, I couldn't figure out how 
> to access to the grub configuration in the code installing the grub image on 
> disk.

Totally out of my comfort zone, I’m afraid! 

But it would definitively make sense to fix that as it could scare new
comers away.


-- 
Tanguy

Re: On the road to the next release: testing the installer

[Tanguy LE CARROUR]

Hi Vivien,

Quoting Vivien Kraus (2024-02-10 11:43:33)
> Le vendredi 09 février 2024 à 12:24 +0100, Tanguy LE CARROUR a écrit :
> > Grub asked me right away my passphrase and… it did not work! 
> > After several attempts, I figured out that the keyboard layout
> > was apparently set to `qwerty` even though I had selected `bépo
> > AFNOR`
> > during the configuration. When I eventually typed my passphrase
> > in `querty` Grub started and boot my system and… I had to type the
> > passphrase a second time, but, fortunately this time in `bépo`!
> > I checked the `config.scm` and the layout was properly set in the
> > bootloader declaration.
> This is unfortunate, but a known workaround is to boot and log in, then
> run cryptsetup luksAddKey , then enter your passphrase (to
> unlock the drive), then switch your keyboard layout to qwerty, then hit
> the exact same keys, and confirm by hitting the exact same keys. So
> now, you can unlock the drive with either your passphrase in a bépo
> layout or your passphrase in a qwerty layout.

Thanks! Actually, someone suggested exactly the same thing during
the last Guix@Paris. The other options were:

- have a second Qwerty keyboard around when booting; and
- do some voodoo magic with the boot partition.

I’ll definitively give a try to the `luksAddKey` on Monday.

Regards.

-- 
Tanguy

Re: Hurd download image is too small; Was: Re: Guix Hurd at… Guix@Paris! [Was: GNU Hurd at Guix days]

[Tanguy LE CARROUR]

Quoting Pjotr Prins (2024-02-10 13:16:16)
> On Fri, Feb 09, 2024 at 08:27:49AM +0100, Tanguy LE CARROUR wrote:
> > May 2024 be the year of the Hurd! 爛
> BTW the Hurd download image on the Guix website has a really small
> partition. […] Any trick I am missing?

I hope you are not asking *me*!? 

I’m now a childhurd enthusiast and I won’t use the VM image anytime soon.
The default childhurd’s disk is also too small, but it’s really easy to 
increase it.


-- 
Tanguy

Re: QA is back, who wants to review patches?

[Tanguy LE CARROUR]

Quoting Andreas Enge (2024-02-09 15:30:44)
> Am Fri, Feb 09, 2024 at 02:53:59PM +0100 schrieb Tanguy LE CARROUR:
> > Quoting Christopher Baines (2024-02-09 14:44:25)
> > > Tanguy LE CARROUR  writes:
> > > > Can I safely close it?!
> > > 
> > > Yep, this unfortunately looks like a case where there was a duplication
> > > of effort and the original patch got ignored.
> > > 
> > > It looks like the issue has been closed now.
> > Not me! 
> 
> As the old German saying goes, "two idiots, one idea" :-)
> I also immediately jumped to this easy looking patch, came to the same
> conclusion as you and closed it. This is a lot of review work for a patch
> where there is nothing to do...
> 
> Actually the next patch I tried to apply was also already there, and the
> committer had just forgotten to close the issue.

*erf*… people! 

I’m "reviewing" `[bug#68997] gnu: lightning: Update to 2.2.3`… please
find another one! 

-- 
Tanguy

Re: QA is back, who wants to review patches?

[Tanguy LE CARROUR]

Quoting Christopher Baines (2024-02-09 14:44:25)
> Tanguy LE CARROUR  writes:
> > Can I safely close it?!
> 
> Yep, this unfortunately looks like a case where there was a duplication
> of effort and the original patch got ignored.
> 
> It looks like the issue has been closed now.

Not me! 

Regards.

-- 
Tanguy

Re: QA is back, who wants to review patches?

[Tanguy LE CARROUR]

Hi Chris,

First of, thanks (again) for everything that you’ve done with QA!
It looks great!


Quoting Christopher Baines (2024-02-09 11:44:11)
> Let me know if you have any comments or questions!

Unfortunately, I have some (stupid) questions!

I decided to give it a try and I picked at random a patch that
was supposed to be an easy one:

```
[bug#68590] gnu: notmuch: update to version 0.38.2
```

It’s mark as "green" *ie* important checks passing, but…
it does not even apply?! Actually, it’s for a good reason:
the exact same patch has been applied 2 weeks ago by
Nicolas Goaziou as #9b65b60b97.

The patch is still open on Debbugs. I guess it should be closed, right?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68590

I guess it got is "green" status on QA before other patch made it to
master.

Can I safely close it?!

Regards.

-- 
Tanguy

Re: On the road to the next release: testing the installer

[Tanguy LE CARROUR]

Hi Guix,

Here is the report of my first attempt at reinstalling Guix System
in a rally long time!


Quoting Tanguy LE CARROUR (2024-02-06 13:52:31)
> Quoting Tanguy LE CARROUR (2024-02-06 08:31:39)
> > In order to test the latest installer, I went to the "latest download"
> > page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux"
> > and ended up on an error page [2]:
> > […]
> > Is it the ISO that has to be tested? How can I download it?
> 
> I guess that part of the answer to my question is "build it yourself" [1], 
> right?!
> 
> [1]: 
> https://guix.gnu.org/en/manual/devel/en/html_node/Building-the-Installation-Image.html

As I was reinstalling my computer at work and I was in a bit of a hurry,
I had created 2 USB stick installers:
- 1 that I built myself from the latest master; and
- 1 that I downloaded from the website for the previous release.

I went for the full disk encryption everything on one partition!
I selected no Window Manager as I’m a happy Sway user and it’s not in
the list.

The installer completed successfully and I rebooted.

Grub asked me right away my passphrase and… it did not work! 
After several attempts, I figured out that the keyboard layout
was apparently set to `qwerty` even though I had selected `bépo AFNOR`
during the configuration. When I eventually typed my passphrase
in `querty` Grub started and boot my system and… I had to type the
passphrase a second time, but, fortunately this time in `bépo`!
I checked the `config.scm` and the layout was properly set in the
bootloader declaration.

I then reconfigured my `guix home` and logged back and… the script
that runs on first login failed for `XDG_RUNTIME_DIR` was not set!
I checked and `/run/user/1000` was not even present.

I was already 1 hour in and running late on something I had to do for a client
so… I decided to re-install with the installer from the previous release!
So much for testing the latest installer! 

I ran into the same keyboard layout with Grub, so I guess it’s a bug
that is not specific to the new installer.
I than reconfigured my system and my home and… *voilà*, I was back… home!
So, the `XDG_RUNTIME_DIR` error might be related to the current installer!?

I’ll definitively give it another try, but in less… stressful circumstances.
I’ll dedicate a spare disk and use my Thinkpad as I can easily swap the disk
without having to unscrew everything.
If this setup is as convenient as I think it should be, than I can
dedicate some time more often to testing the installer.

That’s all for me for today!

Regards,

-- 
Tanguy

Guix Hurd at… Guix@Paris! [Was: GNU Hurd at Guix days]

[Tanguy LE CARROUR]

Dear Guix,

Yesterday, during the Guix@Paris S02E05 we talked about what happened
during Guix Days 2024 and… about the Hurd session.

I demoed my shiny new ChildHurd offload-able setup and… some one
did the setup live on his laptop, reconfigured and built it’s first
package for `i586-gnu` in less than 5 min! 

Thanks to all those who, over the years, have helped to bring
the entry cost down to such a low level it's almost indecent! 

May 2024 be the year of the Hurd! 爛

Regards.

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en février

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French… and in person.)

Bonjour Guix,

Merci à ceux qui se sont déplacés hier soir pour participer
au Guix@Paris S02E05 ! … et à celui qui a eu le courage et la patience
de participer *via* la vidéo conférence.

… merci d’avoir rendu cette soirée pa-ssio-nnante !
Je ne suis pas sûr d’avoir tout compris, mais c’était vraiment super
intéressant ! 

Au plaisir de recommencer le mois prochain !

Excellent début de journée et fin de semaine !

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en février

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Pour rappel, Guix@Paris c'est demain soir ! 
C'est toujours à l’April et toujours à 19h !

**SPOILER ALERT**… on risque d’un peu parler de ce qui s’est dit pendant
les Guix Days !

D’ici là, je vous souhaite une excellente journée !

-- 
Tanguy

Re: On the road to the next release: testing the installer

[Tanguy LE CARROUR]

Quoting Tanguy LE CARROUR (2024-02-06 08:31:39)
> In order to test the latest installer, I went to the "latest download"
> page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux"
> and ended up on an error page [2]:
> […]
> Is it the ISO that has to be tested? How can I download it?

I guess that part of the answer to my question is "build it yourself" [1], 
right?!

[1]: 
https://guix.gnu.org/en/manual/devel/en/html_node/Building-the-Installation-Image.html

Regards.

-- 
Tanguy

Re: Collecting Guix talks at FOSDEM

[Tanguy LE CARROUR]

Hi Steve,


Quoting Steve George (2024-02-06 11:17:42)
> Ludo said they put them into this repo:
> 
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2024
> 
> Do you have access to this? (I do not).

No. I mean, I can read it, but that’s it.

> We can ask people on the channel / this list to put their notes - or 
> integrate their notes into the existing ones there (as it's a shared 
> endeavour).
> 
> Does that work?

+1!

Mine will require a lot of "integration", though! 

-- 
Tanguy

Re: Collecting Guix talks at FOSDEM

[Tanguy LE CARROUR]

Quoting Pjotr Prins (2024-02-06 09:48:42)
> On Tue, Feb 06, 2024 at 09:19:15AM +0100, Tanguy LE CARROUR wrote:
> > I have notes about what sessions took place during the Guix days.
> […]
> That is great. We can link out to notes hosted elsewhere.

**SPOILER ALERT** … WIP!

```markdown
# Guix Days 2024

ICAB, february 1st and 2nd

## Day 1

33 persons present on the event’s opening, including newbies and Nix people.

Main track:

- [Introduction to Goblins by Christine from Spritely 
institute](day1/introduction_to_goblins.md)
- [Status of Guix by Efraim](day1/status_of_guix.md)
- Guix QA update by Chris

Sessions:

- Gobelin (Christine)
- Infrastructure (Alexis)
- Documentation (Julien)
- [Guix Home](day1/guix_home.md) (Gabor)
- Alt. Arch. (Efraim)
- [Bootstrapping](day1/bootstrapping.md) (Janneke)
- Release (Julien)


## Day 2

Sessions:

- Funding (Christine)
- Governance/Maintainers (Efraim + Chris)
- Patch flow (Steeve)
- CLI (Jonathan)
- Profiling (Adriel)
- Hurd (Janneke)
- L10N (Julien)
- Hoot (Christine)
- Newbie room (Gabor)
- Onboarding (Gabor)


## Ideas that didn’t make it to sessions

- Shepherd
- HPC
```

-- 
Tanguy

Re: GNU Hurd at Guix days

[Tanguy LE CARROUR]

Hi Pjotr,


Quoting pjotr.publi...@thebird.nl (2024-02-06 08:48:56)
> We had a very interesting discussion about the Hurd.

Very interesting, indeed! 10+ persons in a room talking about Hurd!
I guess that hadn’t happened in a long time! 

On my side, I decided to start patching broken packages… again! [1]

[1]: https://www.gnu.org/software//hurd/user/tlecarrour.html

First thing yesterday morning, I set up a ChildHurd and try to offload
build to it and… it worked! 

Unfortunately, the default image seems to be to small to build "real"
packages. I increased it, but… then my real disk was suddenly too small!
This is a problem that came up multiple times while discussing with
Simon… so I decided to upgrade my disk… and I now have to re-install
—I miserably failed my attempt at cross-installing and ended up with a
brick! —, so I thought "why not use the latest installer?" [2].

[2]: https://lists.gnu.org/archive/html/guix-devel/2024-02/msg00068.html

I also have to figure out what’s the proper way to hack with this set up.
Probably a mixture of `build --system`, `build --source`, `diff -purN`,
`--with-patch=`…
So, I guess, you’ll hear from me soon! 

Regards,

-- 
Tanguy

Re: Collecting Guix talks at FOSDEM

[Tanguy LE CARROUR]

Hi Pjotr,


Quoting Pjotr Prins (2024-02-06 08:39:25)
> It would also be nice to write a BLOG about what was discussed at Guix
> days

I have notes about what sessions took place during the Guix days.
I was planning to send (tomorrow?) a patch for the Guix Foundation website
to make it available, like "GNU Guix Days FOSDEM 2023" [1].

[1]: https://foundation.guix.info/events/index.html

I don’t know if it’s the right place to put notes about the content,
though? 樂

-- 
Tanguy

On the road to the next release: testing the installer

[Tanguy LE CARROUR]

Hello Guix,

In order to test the latest installer, I went to the "latest download"
page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux"
and ended up on an error page [2]:

"""
{"error":"Could not find the requested build product."}
"""

[1]: https://guix.gnu.org/en/download/latest/
[2]: https://ci.guix.gnu.org/download/1907

If I follow the link "Build details: x86_64-linux" I end up on Cuirass
where the build output [3] is available for download.

[3]: https://ci.guix.gnu.org/download/1907

When I click, unsurprisingly, I get the same error message.

Is it the ISO that has to be tested? How can I download it?

Regards.

-- 
Tanguy

[fr] Moment de convivialité Guix@Paris en février

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French… and in person.)

Bonjour Guix,

Ce jeudi 8 février 2024 à 19h, se tiendra la cinquième édition de Guix@Paris
ouverte au public.
Comme les fois précédentes, il sera possible de participer à distance
(*cf* ci-dessous).


## Programme

Il n'y a pas vraiment de programme… pour le moment ! À vous de proposer
des sujets en avance si vous voulez partager sur des sujets particuliers.
Le but est toujours que les utilisat·rice·eur·s de Guix
—ou futur·e·s utilisat·rice·eur·s !—, dans la région parisienne se
rencontrent et qu'ielles puissent discuter de Guix, Guile ou autres.

L'idée est surtout de passer un moment convivial en mettant des visages
sur des noms. Se rencontrer quoi ! 

Il n'y a pas d'expérience pré-requise et vous êtes tout·e·s les bienvenu·e·s.


## Logistique

Vous pouvez nous dire si vous comptez venir en répondant à ce message,
mais vous serez aussi les bienvenu·e·s au dernier moment ! 

Nous nous occupons des tables, des chaises, des prises électriques et
du vidéo-projecteur. Il y aura aussi de quoi boire et grignoter, mais
vous pouvez apporter ce qui vous ferait plaisir.


## Participation à distance

Sauf annonce contraire, il sera possible de participer à distance
*via* l'instance Jitsi Meet d'Easter-eggs :
.


## Accès

Nous serons accueilli·e·s dans les locaux de l'[April][1], elle même hébergée
par [Easter-eggs][2] :

```
Association April
44/46 rue de l'Ouest (cour intérieure)
Bâtiment 8
75014 Paris

Stations de Métro : Gaîté, Montparnasse, Pernety.

OpenStreetMap : .
```

[1]: https://april.org "April, promouvoir et défendre le logiciel libre"
[2]: https://easter-eggs.com/Presentation-d-Easter-eggs "Easter-eggs"


Au plaisir de vous y rencontrer !

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en janvier… 2024

[Tanguy LE CARROUR]

Bonjour Guix,


Quoting Tanguy LE CARROUR (2024-01-11 18:10:19)
> Une partie de l'infrastructure d'Easter-eggs est sous le coup d'une attaque
> DOS. Nous avons perdu une partie de notre réseau et, comme nous hébergeons
> l'April, elle aussi.
> […]
> Je resterai quand même sur site pour accueillir, celles et ceux qui n'auraient
> pas eu ce message !

Merci à ceux qui ont bravé le froid et le DDoS pour venir discuter de Guix et
de langages-à-parenthèses™ hier soir !

Et encore désolé pour les conditions précaires.

À très bientôt pour la prochaine édition.

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en janvier… 2024

[Tanguy LE CARROUR]

Attention,

Une partie de l'infrastructure d'Easter-eggs est sous le coup d'une attaque 
DOS. Nous avons perdu une partie de notre réseau et, comme nous hébergeons 
l'April, elle aussi.


Je vais donc être obligé d'annuler le Guix@Paris de ce soir. 

Désolé pour la notification de dernière minute.

Je resterai quand même sur site pour accueillir, celles et ceux qui n'auraient 
pas eu ce message !

Je vous tiendrai au courant de la tenue de la prochaine édition.

Librement,

Tanguy

Re: [fr] Moment de convivialité Guix@Paris en janvier… 2024

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Pour rappel, Guix@Paris c'est demain soir ! 
C'est toujours à 19h au local de l'April et, pour celles et ceux
qui ne veulent pas braver le froid et la neige, en direct *live* sur
.

Au plaisir de vous y rencontrer,

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en janvier… 2024

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix et… meilleurs vœux pour cette nouvelle année !

Pour rappel, le prochain Guix@Paris se tiendra jeudi 11 janvier.
Y a-t-il une meilleure façon de commencer l'année ?! 

Au plaisir de vous y retrouver,

-- 
Tanguy

[fr] Moment de convivialité Guix@Paris en janvier… 2024

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French… and in person.)

Bonjour Guix,

Ce jeudi 11 janvier 2024 à 19h, se tiendra la quatrième édition de Guix@Paris
ouverte au public.
Comme les fois précédentes, il sera possible de participer à distance (*cf* 
ci-dessous).


## Programme

Il n'y a pas vraiment de programme… pour le moment ! À vous de proposer
des sujets en avance si vous voulez partager sur des sujets particuliers.
Le but est toujours que les utilisat·rice·eur·s de Guix
—ou futur·e·s utilisat·rice·eur·s !—, dans la région parisienne se
rencontrent et qu'ielles puissent discuter de Guix, Guile ou autres.

L'idée est surtout de passer un moment convivial en mettant des visages
sur des noms. Se rencontrer quoi ! 

Il n'y a pas d'expérience pré-requise et vous êtes tout·e·s les bienvenu·e·s.


## Logistique

Vous pouvez nous dire si vous comptez venir en répondant à ce message,
mais vous serez aussi les bienvenu·e·s au dernier moment ! 

Nous nous occupons des tables, des chaises, des prises électriques et
du vidéo-projecteur. Il y aura aussi de quoi boire et grignoter, mais
vous pouvez apporter ce qui vous ferait plaisir.


## Participation à distance

Sauf annonce contraire, il sera possible de participer à distance
*via* l'instance Jitsi Meet d'Easter-eggs :
.


## Accès

Nous serons accueilli·e·s dans les locaux de l'[April][1], elle même hébergée
par [Easter-eggs][2] :

```
Association April
44/46 rue de l'Ouest (cour intérieure)
Bâtiment 8
75014 Paris

Stations de Métro : Gaîté, Montparnasse, Pernety.

OpenStreetMap : .
```

[1]: https://april.org "April, promouvoir et défendre le logiciel libre"
[2]: https://easter-eggs.com/Presentation-d-Easter-eggs "Easter-eggs"


Au plaisir de vous y rencontrer !

-- 
Tanguy

Re: Moment de convivialité Guix@Paris en nov… euh… décembre

[Tanguy LE CARROUR]

Bonjour Guix,

Merci à ceux qui ont bravé les intempéries et les transports parisiens
pour venir hier soir ! Et, surtout merci à ceux qui, présents ou à
distance, on partagé leur travail, leurs découvertes ou leurs problèmes,
et ont contribué à faire de cette soirée un moment très… convivial ! 

Rendez-vous début janvier (sûrement le 11, à confirmer) pour la
prochaine !

En attendant, je vous souhaite à tou·tes une excellente journée, fin de
semaine et… fin d'année !

-- 
Tanguy

Re: Moment de convivialité Guix@Paris en nov… euh… décembre

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Pour rappel, Guix@Paris c'est demain soir ! 
C'est toujours à 19h… par contre et exceptionnellement, ce ne sera pas
au local de l'April, mais directement chez Easter-eggs ! C'est juste en
face, à 5 mètres !

Au plaisir de vous y rencontrer,

-- 
Tanguy

Moment de convivialité Guix@Paris en nov… euh… décembre

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Jeudi 7 décembre à 19h, se tiendra la troisième édition de Guix@Paris
ouverte au public.
Comme la dernière fois, il sera possible de participer à distance (*cf* 
ci-dessous).


## Programme

Il n'y a pas vraiment de programme… mais en fait, si ! Cette fois, nous
aurons une présentation ! Mais… pas de *spoiler* ! 
Pour le reste, le but est toujours que les utilisat·rice·eur·s
de Guix —ou futur·e·s utilisat·rice·eur·s !—, dans la région parisienne se
rencontrent et qu'ielles puissent discuter de Guix, Guile ou autres.

L'idée est surtout de passer un moment convivial en mettant des visages
sur des noms. Se rencontrer quoi ! 

Il n'y a pas d'expérience pré-requise et vous êtes tout·e·s les bienvenu·e·s.


## Logistique

Vous pouvez nous dire si vous comptez venir en répondant à ce message,
mais vous serez aussi les bienvenu·e·s au dernier moment ! 

Nous nous occupons des tables, des chaises, des prises électriques et
du vidéo-projecteur. Il y aura aussi de quoi boire et grignoter, mais
vous pouvez apporter ce qui vous ferait plaisir.


## Participation à distance

Sauf annonce contraire, il sera possible de participer à distance
*via* l'instance Jitsi Meet d'Easter-eggs :
.


## Accès

Nous serons accueilli·e·s dans les locaux de l'[April][1], elle même hébergée
par [Easter-eggs][2] :

```
Association April
44/46 rue de l'Ouest (cour intérieure)
Bâtiment 8
75014 Paris

Stations de Métro : Gaîté, Montparnasse, Pernety.

OpenStreetMap : .
```

[1]: https://april.org "April, promouvoir et défendre le logiciel libre"
[2]: https://easter-eggs.com/Presentation-d-Easter-eggs "Easter-eggs"


Au plaisir de vous y rencontrer !

-- 
Tanguy

Re: Moment de convivialité Guix@Paris en octobre

[Tanguy LE CARROUR]

Bonjour Edouard,


Quoting Edouard Klein (2023-11-05 17:03:41)
> Je souhaite venir également :) J'avais raté l'annonce pour octobre.

Cool !


> J'aurais deux trucs à présenter:
> - Du sucre syntaxique pour instancier, étendre, modifier, ou supprimer
> des services,
> - Comment monter des systèmes de fichier 9P au sein d'un guix container.
> 
> C'est pas super formel, ce sont des recherches en cours, mais si je peux
> rétroprojeter mon écran et blablater pendant environ 20 minutes (en
> tout), ça serait super.

C'est une super idée !
Il y a un vidéo projecteur ! La dernière fois, on a fait du partage
d'écran *via* JitsiMeet pour que les personnes à distance puissent
participer.


> Il faut apporter à manger/boire pour partager ?

Tes contributions seront les bienvenues !
La logistique n'est pas encore bien rodée, mais on se dirige vers un
mélange de « chacun·e apporte ce qu'ielle veut » plus « on va chercher
des pizzas ». Des pizzas ou autre chose d'ailleurs. Ce ne sont pas les
resto’ qui manquent dans le coin.

En attendant le prochain Guix@Paris, je te souhaite une excellente
journée.

-- 
Tanguy

Re: Moment de convivialité Guix@Paris en octobre

[Tanguy LE CARROUR]

Quoting Simon Tournier (2023-10-27 11:13:54)
> On Fri, 27 Oct 2023 at 09:04, Tanguy LE CARROUR  wrote:
> > Vu que l'on a passé une bonne soirée, on va remettre ça ! À priori,
> > le jeudi 1er décembre. La date sera confirmée sur ces listes une ou deux
> > semaines avant.
> 
> Jeudi 7 décembre, c’est noté.

Le 7, exactement ! C'est ce que j'ai **TOUJOURS** dis ! 

-- 
Tanguy

Re: Moment de convivialité Guix@Paris en octobre

[Tanguy LE CARROUR]

Pour ce qui sont intéressés par [direnv](https://direnv.net/),
je viens d'apprendre que j'étais **UN PEU** en retard et que
`use guix` utilise `guix shell` depuis le 3 janvier !

Ça fera ça de code en moins dans ma conf’ ! 

Bonne journée,

-- 
Tanguy

Re: Moment de convivialité Guix@Paris en octobre

[Tanguy LE CARROUR]

Quoting Tanguy LE CARROUR (2023-10-27 09:04:26)
> Vu que l'on a passé une bonne soirée, on va remettre ça ! À priori,
> le jeudi 1er décembre. La date sera confirmée sur ces listes une ou deux
> semaines avant.

Erreur ! Il fallait lire « le jeudi 7 décembre ».

Bonne journée,

-- 
Tanguy

Re: Moment de convivialité Guix@Paris en octobre

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Merci à ceux qui ont bravé la pluie pour venir hier soir !
Et merci à ceux qui ont supporté de nous voir manger et boire *via*
la vidéo-conférence. 

Vu que l'on a passé une bonne soirée, on va remettre ça ! À priori,
le jeudi 1er décembre. La date sera confirmée sur ces listes une ou deux
semaines avant.

D'ici là, portez vous bien !

…

Ah, message personnel pour Gaobi : j'ai sûrement la réponse à ta
question ! Pourrais-tu me contacter directement ?

-- 
Tanguy

Re: Moment de convivialité Guix@Paris en octobre

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Pour rappel, Guix@Paris c'est demain soir ! 
C'est toujours à 19h et c'est toujours au local de l'April.

Au plaisir de vous y rencontrer,

-- 
Tanguy

Moment de convivialité Guix@Paris en octobre

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Jeudi 26 octobre à 19h, se tiendra la seconde édition de Guix@Paris
ouverte au public.
La seule différence par rapport à la dernière fois est qu'il sera
possible de participer à distance (*cf* ci-dessous).


## Programme

Il n'y a pas vraiment de programme. Le but est que les utilisat·rice·eur·s
de Guix —ou futur·e·s utilisat·rice·eur·s !—, dans la région parisienne se
rencontrent et qu'ielles puissent discuter de Guix, Guile ou autres.

L'idée est surtout de passer un moment convivial en mettant des visages
sur des noms. Se rencontrer quoi ! 

Il n'y a pas d'expérience pré-requise et vous êtes tout·e·s les bienvenu·e·s.


## Logistique

Vous pouvez nous dire si vous comptez venir en répondant à ce message,
mais vous serez aussi les bienvenu·e·s au dernier moment ! 

Nous nous occupons des tables, des chaises, des prises électriques et
du vidéo-projecteur. Il y aura aussi de quoi boire et grignoter, mais
vous pouvez apporter ce qui vous ferait plaisir.


## Participation à distance

Sauf annonce contraire, il sera possible de participer à distance
*via* l'instance Jitsi Meet d'Easter-eggs :
.


## Accès

Nous serons accueilli·e·s dans les locaux de l'[April][1], elle même hébergée
par [Easter-eggs][2] :

```
Association April
44/46 rue de l'Ouest (cour intérieure)
Bâtiment 8
75014 Paris

Stations de Métro : Gaîté, Montparnasse, Pernety.

OpenStreetMap : .
```

[1]: https://april.org "April, promouvoir et défendre le logiciel libre"
[2]: https://easter-eggs.com/Presentation-d-Easter-eggs "Easter-eggs"


Au plaisir de vous y rencontrer !

-- 
Tanguy

Re: [fr] Moment de convivialité Guix@Paris en septembre

[Tanguy LE CARROUR]

Bonjour à tout·e·s,


On Thu, 14 Sep 2023 at 18:06, Tanguy LE CARROUR  wrote:
> Ce jeudi 28 septembre à 19h, se tiendra la première édition de Guix@Paris
> ouverte au public.

Merci, à ceux qui ont fait le déplacement hier soir !
Même si tout cela manque encore un peu de rodage —et de pizzas !—,
une prochaine rencontre est déjà prévue pour fin octobre. La date sera confirmée
le plus tôt possible.

Nous sommes aussi en train d'essayer d'organiser l'évènement en hybride
en proposant de participer en vidéo-conférence. Si vous êtes intéressé·e,
n'hésitez pas à me le dire !

En attendant de vous retrouver nombr·euses·eux la prochaine fois,
je vous souhaite une excellente journée !

-- 
Tanguy

[fr] Moment de convivialité Guix@Paris en septembre

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French… and in person.)

Bonjour Guix,

Ce jeudi 28 septembre à 19h, se tiendra la première édition de Guix@Paris
ouverte au public.


## Programme

Il n'y a pas vraiment de programme. Le but est que les utilisat·rice·eur·s
de Guix —ou futur·e·s utilisat·rice·eur·s !—, dans la région parisienne se
rencontrent et qu'ielles puissent discuter de Guix, Guile ou autres.

L'idée est surtout de passer un moment convivial en mettant des visages
sur des noms. Se rencontrer quoi ! 

Il n'y a pas d'expérience pré-requise et vous êtes tout·e·s les bienvenu·e·s.


## Logistique

Vous pouvez nous dire si vous comptez venir en répondant à ce message,
mais vous serez aussi les bienvenu·e·s au dernier moment ! 

Nous nous occupons des tables, des chaises, des prises électriques et
du vidéo-projecteur. Il y aura aussi de quoi boire et grignoter, mais
vous pouvez apporter ce qui vous ferait plaisir.


## Accès

Nous serons accueilli·e·s dans les locaux de l'[April][1], elle même hébergée
par [Easter-eggs][2] :

```
Association April
44/46 rue de l'Ouest (cour intérieure)
Bâtiment 8
75014 Paris

Stations de Métro : Gaîté, Montparnasse, Pernety.

OpenStreetMap : .
```

[1]: https://april.org "April, promouvoir et défendre le logiciel libre"
[2]: https://easter-eggs.com/Presentation-d-Easter-eggs "Easter-eggs"


Au plaisir de vous y rencontrer !

-- 
Tanguy

Re: Swineherd: Guix System container manager

[Tanguy LE CARROUR]

Hi Simon,

Quoting Simon Tournier (2023-09-13 14:58:38)
> On Wed, 13 Sep 2023 at 11:06, Ricardo Wurmus  wrote:
> [...]
> >
> > The Swineherd was designed to be used with Shepherd on foreign distros,
> > so it does not assume to be running on top of Guix System (for better or
> > worse).
> 
> Oh!  It is very promising.  Really cool!
> 
> > Of course the Swineherd is also available as a Guix package called
> > “swineherd”.
> 
> Hum, I did (or adding guile):
> 
> guix time-machine -q -- shell swineherd
> 
> Then I do not know what to do.  What are the basic steps for testing it?

I haven't tried it (yet), but I've read this: 
.

Regards,

-- 
Tanguy

Re: Reverting d477018b57 "gnu: poetry: Update to 1.1.12."

[Tanguy LE CARROUR]

Hi John,

Quoting Tanguy LE CARROUR (2023-05-04 17:23:44)
> Quoting John Kehayias (2023-05-04 17:09:14)
> > I didn't emerge in time for the core-updates merge. There might be a better 
> > way
> > than causing a python world rebuild, but this is my current series
> > which does have Poetry building (might as well do the updates I
> > figure): <https://issues.guix.gnu.org/63139>
> […]
> 
> I'll give it a try at the week end!

Days became weeks and… I had no chance (yet) to give it a try! 

Any updates on your side? I've just seen that Lars answered on #63139
few weeks ago.

Cheers,

-- 
Tanguy

Re: Contributing Guix Home services

[Tanguy LE CARROUR]

Hi Ludo’,

Sorry, busy week!  … euh… busy 2 weeks! 


Quoting Ludovic Courtès (2023-05-03 22:42:27)
> Tanguy LE CARROUR  skribis:
> 
> > Quoting Ludovic Courtès (2023-04-17 15:39:02)
> >> Tanguy LE CARROUR  skribis:
> >> > It's been quite a journey on my side! Ups. Downs. Mostly downs, though! 
> >> > Thanks to Simon's unconditional technical and moral support, a **LOT**
> >> > has changed since I sent this message. Hopefully for the better! 爛
> >> 
> >> Heh.  :-)  While it’s fresh on your mind, it would be nice to list the
> >> problems you ran into on your journey and see what we can do about it.
> >
> > Mostly figuring out how to test it!
> >
> > On my machine at home, `guix home reconfigure` can take minutes.
> 
> Did you test with ‘guix home container’ first?  That’s what I do and I
> added this command precisely so one can test without any risk of
> breaking things.
> 
> It’s still too slow though, that’s right.

Yes, when I use my actual home config, it also takes minutes to build
the container, but, if I use a fake home config, limited to the service
I want to test, it's way faster! Still slower than the following…

Append this test code at the end of the service file:

```scheme
(define configuration
  (home-service-configuration
   ; […]
  )

(mixed-text-file "test" (serialize-configuration configuration 
home-service-configuration-fields))
```

Then, from the command line:

```console
$ cat (guix build -f path/to/home/service.scm)
# … the content of the generated file
```


> > I can only test file generation, though.
> 
> The msmtp service does nothing but file generation though, right?
> 
> > Then I painfully discovered that replacing in a string is not as easy as
> > it sounds, or, more precisely, that "python replace in string" yields
> > better results than "scheme replace in string" in DuckDuckGo!
> 
> True!  Perhaps something to add to the Cookbook’s Scheme intro.
> 
> (Fun fact: I’ve never used that (ice-9 string-fun) module that keeps
> popping up in new code.  :-))

Wht?! 勞 How one would you do without it? 


-- 
Tanguy

Re: Reverting d477018b57 "gnu: poetry: Update to 1.1.12."

[Tanguy LE CARROUR]

Hi John,


Quoting John Kehayias (2023-05-04 17:09:14)
> On Wed, May 03, 2023 at 09:49 AM, Tanguy LE CARROUR wrote:
> > I noticed yesterday that Poetry was broken:
> > <https://ci.guix.gnu.org/build/1227911/details>.
> >
> > I might have spotted it earlier if I had spend time testing `core-update`.
> > My bad!
> >
> 
> Yes, I noticed that too but fixing the current version of Poetry sent
> me down quite a rabbit hole of dependencies and updates.

Oh my G…uix! O_o'

I started working on it yesterday, but stop after:

  gnu: Add python-pyproject-hooks.
  gnu: python-virtualenv: Update to 20.22.0.
  gnu: Add python-poetry-plugin-export.

*ERF*! Not even close! :-(


> I didn't emerge in time for the core-updates merge. There might be a better 
> way
> than causing a python world rebuild, but this is my current series
> which does have Poetry building (might as well do the updates I
> figure): <https://issues.guix.gnu.org/63139>
> 
> The proper polishing and bootstrapping updates is WIP, but that series
> will get you Poetry building, after lots of other rebuilding :)

Or, I could write a Poetry v1.1.12 package definition in my channel.
Selfish, but efficient. Selfishient?!


> Right, probably a typo in the commit message.
> 
> > Unfortunately, I have no time to work on this right now. Would it be
> > possible to revert the change? Or should I submit a patch to downgrade it?
> 
> I haven't tried if a simple revert will build given all the other
> changes from core-updates. If that works that would be a good stopgap.
> Do you know if that works and is simple enough? Or can you test?

No, I haven't tried! I don't even know if many packages actually depend
on `poetry`. I'm expecting dependencies on `python-poetry-core`.

I'll give it a try at the week end!

Cheers,

-- 
Tanguy

Re: GNU Shepherd 0.10.0rc1 available for testing!

[Tanguy LE CARROUR]

Quoting pelzflorian (Florian Pelz) (2023-05-03 14:51:41)
> Tanguy LE CARROUR  writes:
> > I did that and… I ended up with the following build error:
> > […]
> > checking if (fibers) is available... no
> > configure: error: Fibers is missing; please install it.
> 
> Could it be that you have not run “guix pull” recently

Oh… this must be it!
As soon as I noticed that `poerty` was broken, I rolled back
and postponed the upgrade.

My bad!

Thanks.

-- 
Tanguy

Re: GNU Shepherd 0.10.0rc1 available for testing!

[Tanguy LE CARROUR]

Hi,


Quoting pelzflorian (Florian Pelz) (2023-04-29 20:29:52)
> Thank you shepherds!  Also the explanations in the news are great.
> Finally I understand why GOOPS is not desirable in shepherd.
> 
> For Guix Home:
> 
> Ludovic Courtès  writes:
> > In your operating system configuration (and similarly for your
> > ‘home-environment’), make the following changes:
> 
> For Guix Home, it works for me to put this in home-environment; no need
> to fiddle with home-environment-essential-services.
> 
> (home-environment
>   …
>   (services
>(list (service home-shepherd-service-type
>   (home-shepherd-configuration
>(shepherd shepherd-next)))
>  …

I did that and… I ended up with the following build error:

```
$ guix home reconfigure tanguy.home.scm
# […]
building /gnu/store/s30bi2zc3m98imlp21ncmzrs3dyi5k3k-shepherd-0.10.0rc1.drv...
| 'configure' phasebuilder for 
`/gnu/store/s30bi2zc3m98imlp21ncmzrs3dyi5k3k-shepherd-0.10.0rc1.drv' failed 
with exit code 1
build of /gnu/store/s30bi2zc3m98imlp21ncmzrs3dyi5k3k-shepherd-0.10.0rc1.drv 
failed
View build log at 
'/var/log/guix/drvs/s3/0bi2zc3m98imlp21ncmzrs3dyi5k3k-shepherd-0.10.0rc1.drv.gz'.
cannot build derivation 
`/gnu/store/78i3qkl8y247w5w9fpjk69vq5jmscha8-activate.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/pv7pfl76i1rnsdzjxsrv1rkqab999nls-on-first-login.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/384414cysz4pfrjdsvbgxl15ki6sah7n-profile.drv': 1 dependencies 
couldn't be built
cannot build derivation `/gnu/store/92ipayml42pmhwmp0x6cwms2fs58xhfq-home.drv': 
1 dependencies couldn't be built
guix home: error: build of 
`/gnu/store/92ipayml42pmhwmp0x6cwms2fs58xhfq-home.drv' failed

$ gunzip -c 
/var/log/guix/drvs/s3/0bi2zc3m98imlp21ncmzrs3dyi5k3k-shepherd-0.10.0rc1.drv.gz
# […]
checking if (fibers) is available... no
configure: error: Fibers is missing; please install it.
error: in phase 'configure': uncaught exception:
%exception #< program: 
"/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash" 
arguments: ("./configure" 
"CONFIG_SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash"
 
"SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash" 
"--prefix=/gnu/store/p4njzm47a1svbfcc845w7sbiwxy5xgm0-shepherd-0.10.0rc1" 
"--enable-fast-install" "--build=x86_64-unknown-linux-gnu" 
"--localstatedir=/var") exit-status: 1 term-signal: #f stop-signal: #f>
phase `configure' failed after 3.7 seconds
command 
"/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash" 
"./configure" 
"CONFIG_SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash"
 
"SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash" 
"--prefix=/gnu/store/p4njzm47a1svbfcc845w7sbiwxy5xgm0-shepherd-0.10.0rc1" 
"--enable-fast-install" "--build=x86_64-unknown-linux-gnu" 
"--localstatedir=/var" failed with status 1
```

Have I missed something?


-- 
Tanguy

Reverting d477018b57 "gnu: poetry: Update to 1.1.12."

[Tanguy LE CARROUR]

Hi Guix,

I noticed yesterday that Poetry was broken:
.

I might have spotted it earlier if I had spend time testing `core-update`.
My bad!

The problematic commit seems to be d477018b57 "gnu: poetry: Update to 1.1.12.".

What also questions me is the fact that the commit message states that
it's an upgrade to `1.1.12` when it's the current version and it's
actually an upgrade to `1.4.2`.

Unfortunately, I have no time to work on this right now. Would it be
possible to revert the change? Or should I submit a patch to downgrade it?

Cheers,

-- 
Tanguy

Re: Contributing Guix Home services

[Tanguy LE CARROUR]

Hi Ludo’,


Quoting Ludovic Courtès (2023-04-17 15:39:02)
> Tanguy LE CARROUR  skribis:
> > It's been quite a journey on my side! Ups. Downs. Mostly downs, though! 
> > Thanks to Simon's unconditional technical and moral support, a **LOT**
> > has changed since I sent this message. Hopefully for the better! 爛
> 
> Heh.  :-)  While it’s fresh on your mind, it would be nice to list the
> problems you ran into on your journey and see what we can do about it.

Mostly figuring out how to test it!

On my machine at home, `guix home reconfigure` can take minutes.
And some errors don't actually show up.
After trying different solutions, I eventually settled on the following:
while developing, I add, at the end of service file, something like:

```scheme
(define configuration
  (home-service-configuration
   ; […]
  )

(mixed-text-file
 "test"
 (serialize-configuration configuration home-service-configuration-fields))
```

And then I run:

```console
> cat (guix build -f path/to/home/service.scm)
# … the content of the generated file
```

I can only test file generation, though.

Then I painfully discovered that replacing in a string is not as easy as
it sounds, or, more precisely, that "python replace in string" yields
better results than "scheme replace in string" in DuckDuckGo!

I've also used `gexp` in places where I'm not sure it makes any sense,
but it works, so… #pragmatic!


> > At least now one of them [1] looks like a decent home service. Except
> > for the problem with `(every khal-calendar? lst)` that I haven't figure
> > out yet.
> >
> > [1]: 
> > https://git.easter-eggs.org/bioneland/guix/-/blob/main/bioneland/home/services/khal.scm
> >
> >
> > The one for MSMTP [2] does not contain all the available options, but all
> > the configurations and serializers are there.
> >
> > [2]: 
> > https://git.easter-eggs.org/bioneland/guix/-/blob/main/bioneland/home/services/msmtp.scm
> 
> I don’t use these two programs, but the services look nice!  The extra
> bit of work you’d have to do is documentation, similar to what is done
> for the other Home services.  Maybe start with msmtp to get a feel of
> what that entails?

`(configuration->documentation 'home-msmtp-configuration)`
`(configuration->documentation 'msmtp-account)`
`(configuration->documentation 'msmtp-configuration)`
… *et voilà !*


> >> There’s no formal rule, but I think that what we’ve been doing so far is 
> >> to ensure basic functionality of
> >> the service is covered, and to provide an “escape hatch” for bits of the
> >> configuration that are not covered.
> >
> > If by "escape hatch" you mean `extra-config`, you're right!
> 
> Yup!

The convention seems to be `extra-content`, but you knew what I meant, right!? 


> > I'll try to submit a patch for one of the two mentioned above soon…ish!
> 
> Excellent, thanks!

Done! <https://issues.guix.gnu.org/62969>
I could have done a **lot** more with the documentation, but I wanted to
be sure to get the basic right first.

-- 
Tanguy

Re: Contributing Guix Home services

[Tanguy LE CARROUR]

Hi Ludo’


Quoting Ludovic Courtès (2023-04-13 22:42:56)
> Tanguy LE CARROUR  skribis:
> 
> > This doesn't answer the question "how complete need a service be to make
> > it to master?", though. But I've a lot of re-write to do before submitting 
> > patches
> > anyway!
> 
> Sorry for not noticing earlier!

No problem!
It's been quite a journey on my side! Ups. Downs. Mostly downs, though! 
Thanks to Simon's unconditional technical and moral support, a **LOT**
has changed since I sent this message. Hopefully for the better! 爛
At least now one of them [1] looks like a decent home service. Except
for the problem with `(every khal-calendar? lst)` that I haven't figure
out yet.

[1]: 
https://git.easter-eggs.org/bioneland/guix/-/blob/main/bioneland/home/services/khal.scm


The one for MSMTP [2] does not contain all the available options, but all
the configurations and serializers are there.

[2]: 
https://git.easter-eggs.org/bioneland/guix/-/blob/main/bioneland/home/services/msmtp.scm


> There’s no formal rule, but I think that what we’ve been doing so far is to 
> ensure basic functionality of
> the service is covered, and to provide an “escape hatch” for bits of the
> configuration that are not covered.

If by "escape hatch" you mean `extra-config`, you're right! I'll try to
add it where ever I can. Does make sense to add on to every
configuration though.


> Contributions in this area are most welcome!

I'll try to submit a patch for one of the two mentioned above soon…ish!

Cheers,

-- 
Tanguy

Re: Contributing Guix Home services

[Tanguy LE CARROUR]

Quoting Tanguy LE CARROUR (2023-03-25 17:53:23)
> My main concern now is to figure out how to implement complexe
> configurations to be able to write things like:
> […]
> I'm not sure how to make `define-configuration` accept complexe structures.
> When I look at `gnu/home/services/ssh.scm`, it seems to be doing the other way
> around and define the configuration with `define-record-type` and "put"
> the "configuration" inside.

Note to self: when in doubt, RTFM! … where the "F" stands for "Fabulous"! 
<https://guix.gnu.org/manual/devel/en/html_node/Complex-Configurations.html>

This doesn't answer the question "how complete need a service be to make
it to master?", though. But I've a lot of re-write to do before submitting 
patches
anyway!

-- 
Tanguy

Contributing Guix Home services

[Tanguy LE CARROUR]

Hi Guix,

For the past few… months (!?) I've been working on migrating from
git+stow to a proper Guix Home setup.

It's been painful, but I've learned a lot along the way. There's still
a lot to be done —and a lot to learn!—, but I wanted to know
what were the requirements for a home service to be accepted in master?

I've written home services for the following programs: afew, bat, beets, dunst,
gnupg, imv, khal, khard, mpd, msmtp, nowty, profanity, swappy, tig, tor,
transmission, user-dirs, vdirsyncer, wofi, zathura. Others are on the way.

For the time being, they are available on my channel:
.

Most of them are about writing configuration files. But I've limited myself
to the configuration options I was actually using. So they are far from
being complete. But it's kind of cool to be able to write:

```scheme
(define move-left "t")
(define move-up "s")
(define move-down "r")
(define move-right "n")

;; […]

(service home-imv-service-type
  (home-imv-configuration
(prev move-left)
(next move-right)
(zoom-in move-up)
(zoom-out move-down)))

(service home-khal-service-type
  (home-khal-configuration
(up move-up)
(down move-down)
(left move-left)
(right move-right)))
```

My main concern now is to figure out how to implement complexe
configurations to be able to write things like:

```scheme
(service home-khal-service-type
  (home-khal-configuration
(calendars
  (list (khal-calendar (name "my_calendar")
   (path "~/.calendars//")
   (color "light gray"))

(service home-khard-service-type
  (home-khard-configuration
(addressbooks
  (list (khard-addresbook (name "my_contact")
  (path "~/.contacts//"))

(service home-msmtp-service-type
  (home-msmtp-configuration
(default-account "t@bl")
(accounts
  (list (msmtp-account (name "t@bl")
   (host "mail.domain.tld")
   (port 587)
   (user "tan...@bioneland.net")
   (from "tan...@bioneland.net"))
```

I'm not sure how to make `define-configuration` accept complexe structures.
When I look at `gnu/home/services/ssh.scm`, it seems to be doing the other way
around and define the configuration with `define-record-type` and "put"
the "configuration" inside.

Any guidance would be highly appreciated!

Best regards,

-- 
Tanguy

Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event

[Tanguy LE CARROUR]

Hi Simon,


Quoting zimoun (2022-10-24 09:34:09)
> On dim., 23 oct. 2022 at 17:40, Tanguy LE CARROUR  
> wrote:
> 
> >> guix package --export-manifest > /tmp/my-pkgs.scm
> >> guix refresh -m /tmp/my-pkgs.scm 2>&1 | ...
> >
> > I'm not using manifest (anymore). I used to, but for the time being, I'm 
> > using
> > `divenv` + `guix shell` and I'm quite happy with that setup.
> 
> Note that the first command above creates the manifest for you.
> Usually, it works well enough. :-)

I guess the "problem" is that I'm a "pipe person". I just don't like
having to create a temp’ file.
But I agree that your solution is more elegant.


> Well, ’direnv’ + ’guix shell’ but you have a manifest, no?  I mean how
> does ’guix shell’ know what to provide inside this new shell?

I used to have a `manifest.scm` file. I even used to (silly me!) commit it
into the repository along side the project's code.
I recently realized that it was easier to only have a git-ignored
`.envrc` file containing:

```
use guix-shell python python-wrapper python-jedi poetry […]
```

The other project's dependencies are (still) managed by Poetry, so the
list passed to Guix shell is quite short.

Not that `guix-shell` is a custom function, for Direnv `guix` function
still uses `guix environment`. But this would also work:

```
use guix --ad-hoc python python-wrapper python-jedi poetry […]
```

For some projects that are not dev project, I sometimes use a
`manifest.scm`. I guess it also depends on the Moon phase. In those rare
cases, my `.envrc` contains the following:

```
use guix-shell -m manifest.scm
```

Which can be abbreviated to `use guix-shell`, because it auto-magically
loads the `manifest.scm` or `guix.scm` file present inside the folder.

Regarding the `guix.scm` file, I recently decided to also move them out
of the code repository of the (personal) projects I needed to package
for Guix, because they don't actually belong with the code. They now live in
a dedicated repository that I added to my Guix channels.


> For what it is worth, I have used similar workflow but I have been bored
> to run “guix pull”, do some stuff unrelated to ’project’, then later be
> back on ’project’ and then have failures.  Instead, my workflow is
> splited into 2 ways depending on my phase of the Moon.  Either, I create
> a profile inside the project directory.  Either, I use channels.scm +
> manifest.scm and often run via ’guixify’ script (see below); e.g.,
> 
> guixify foo # run foo using the Guix environment
> guixify # enter in the environment

Thanks for sharing! I used to have the same kind of setup, but…


> Maybe, ’direnv’ would do a better job.

I wrote a `profile` function for Direnv that was doing the job of
loading the environment.

```
use profile the-profile-for-my-project
```

I also had a `guix-all-profile` command that would executing the same command
on all my profiles. Basically looping over them to `--upgrade` or 
`--delete-generations`.

But I found it easier to use Guix shell.


> The good point is that channels.scm and manifest.scm are included in the Git
> tree of the project. And they can be re-used with ’guix pack -f docker -m
> manifest.scm’ to generate Docker pack that I can share with colleagues.

My colleagues use Debian. We agreed that I would not pollute the repo
with my Guix files if they would not commit their Debian support files. 

Regards,

-- 
Tanguy

Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event

[Tanguy LE CARROUR]

Hi Efraim,


Quoting Efraim Flashner (2022-10-19 21:31:15)
> On Tue, Oct 18, 2022 at 06:19:18PM +0200, Tanguy LE CARROUR wrote:
> > Quoting Tanguy LE CARROUR (2022-10-05 16:01:40)
> > > Quoting Christopher Baines (2022-09-18 17:55:30)
> > […]
> > This is no magic scheme, it's just an alias for:
> >
> > ```console
> > $ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 
> > 2>&1 | ag -v "already" | ag -v "failed" | ag -v "no updater" | ag -v 
> > "warning"
> > ```
>
> I'd like to suggest swapping out the ag options for a grep option:
> grep -v -E '(already|failed|no updater|warning|redirection)'
> _should_ work, but I haven't tested that myself yet.

Right! Those multiple `-v` looked weird!
Thanks to your suggestion, I now have:

```console
$ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 2>&1 \
  | ag -v '(already|failed|no updater|warning|redirection)'
```

Regards,

-- 
Tanguy

Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event

[Tanguy LE CARROUR]

Hi Simon,

Sorry it took me so long to answer, but I've been struggling for the
past week with the upgrade of Poetry!! 
It requires updating `python-virtualenv` and `python-lockfile` and
suddenly a **LOT** of packages needed to be rebuilt/updated. #dependencyHell!
But that will definitively be the topic of a different thread…


Quoting zimoun (2022-10-19 11:57:15)
> On Tue, 18 Oct 2022 at 18:19, Tanguy LE CARROUR  wrote:
> 
> > ```console
> > $ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 
> > 2>&1 | ag -v "already" | ag -v "failed" | ag -v "no updater" | ag -v 
> > "warning"
> > ```
> >
> > Yeah, I know… ugly! But, it does (part of) the job! 
> 
> Well, if you are using a manifest file, you can directly pass it to
> ’guix refresh‘.  Otherwise,
> 
> guix package --export-manifest > /tmp/my-pkgs.scm
> guix refresh -m /tmp/my-pkgs.scm 2>&1 | ...

I'm not using manifest (anymore). I used to, but for the time being, I'm using
`divenv` + `guix shell` and I'm quite happy with that setup.


> And even, being in a checkout of Guix,
> 
> guix refresh -m /tmp/my-pkgs.scm --update
> 
> and then give a look at the script etc/committer.scm.

That would create more patches than I could process I guess. I like the
idea of cherry-picking from the "need to be updated" list.
But `etc/committer.scm` is definitively a tool I was missing! Thanks!

Regards,

-- 
Tanguy

Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event

[Tanguy LE CARROUR]

Hi Chris,

Quoting Tanguy LE CARROUR (2022-10-05 16:01:40)
> Quoting Christopher Baines (2022-09-18 17:55:30)
> > […]
> >  - Maybe script making contributions like updating packages
> >  - Make a similar tool to Debian's how can I help
> >- Try to avoid suggesting updating packages with lots of dependencies
> 
> `guix how-can-i-help` would be amazing! Something that would:
> - list all the packages in my current profile that can be updated,
>   sorted by number of dependent packages; and

Just to let you know that, even if I haven't written `guix
how-can-i-help` (yet), I've just written a `guix-refresh-all` that tells me:

```console
$ guix-refresh-all
gnu/packages/freedesktop.scm:2164:13: udiskie would be upgraded from 2.3.3 to 
2.4.2
gnu/packages/wm.scm:1584:13: sway would be upgraded from 1.6.1 to 1.7
gnu/packages/wireservice.scm:205:13: csvkit would be upgraded from 1.0.5 to 
1.0.7
gnu/packages/mail.scm:610:13: neomutt would be upgraded from 20211029 to 
20220429
gnu/packages/mpd.scm:445:13: cantata would be upgraded from 2.4.2 to 2.5.0
gnu/packages/mail.scm:1326:13: notmuch would be upgraded from 0.36 to 0.37
gnu/packages/rust-apps.scm:190:13: bat would be upgraded from 0.20.0 to 0.22.1
gnu/packages/wm.scm:1704:13: swaybg would be upgraded from 1.0 to 1.1.1
gnu/packages/terminals.scm:1334:13: alacritty would be upgraded from 0.9.0 to 
0.16.0
gnu/packages/gnupg.scm:830:2: pinentry-gtk2 would be upgraded from 1.2.0 to 
1.2.1
gnu/packages/linux.scm:8793:13: wireplumber would be upgraded from 0.4.11 to 
0.4.12
gnu/packages/libreoffice.scm:1059:13: libreoffice would be upgraded from 
7.3.5.2 to 7.4.2.3
gnu/packages/mpd.scm:112:13: mpd would be upgraded from 0.23.8 to 0.23.10
gnu/packages/linphone.scm:801:13: linphone-desktop would be upgraded from 4.2.5 
to 4.4.10
gnu/packages/messaging.scm:2171:13: profanity would be upgraded from 0.13.0 to 
0.13.1
gnu/packages/gnome.scm:3060:13: libnotify would be upgraded from 0.7.9 to 0.8.1
gnu/packages/gnupg.scm:287:13: gnupg would be upgraded from 2.2.32 to 2.3.8
gnu/packages/rust-apps.scm:455:13: fd would be upgraded from 8.1.1 to 8.4.0
gnu/packages/curl.scm:66:12: curl would be upgraded from 7.79.1 to 7.85.0
gnu/packages/terminals.scm:929:13: go-github-com-junegunn-fzf would be upgraded 
from 0.25.0 to 0.34.0
gnu/packages/xorg.scm:1767:13: setxkbmap would be upgraded from 1.3.2 to 1.3.3
gnu/packages/file.scm:65:13: file would be upgraded from 5.41 to 5.43
gnu/packages/ncurses.scm:45:13: ncurses would be upgraded from 6.2.20210619 to 
6.3
```

So now, I know what I'll do tomorrow! 

This is no magic scheme, it's just an alias for:

```console
$ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 2>&1 | 
ag -v "already" | ag -v "failed" | ag -v "no updater" | ag -v "warning"
```

Yeah, I know… ugly! But, it does (part of) the job! 

Happy hacking!

-- 
Tanguy

Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event

[Tanguy LE CARROUR]

Quoting Christopher Baines (2022-10-05 18:51:52)
> Tanguy LE CARROUR  writes:
> 
> >>   - Minimise the burden for submitters
> >> - Lengthy guidance for submitting patches
> >
> > Actually, the `16.4 Packaging Guidelines` and `16.6 Submitting Patches`
> > are everything that I've ever looked for.
> 
> I think the point here is that the Submitting Patches section is quite
> long.

You mean the 17 point list?! 



> > The only problem is `16.5.4 Formatting Code` that makes use of 
> > `./etc/indent-code.el`
> > that was removed back in January.
> 
> The latest version of the manual suggests using guix style, so this is
> maybe a problem limited to old versions of the manual?


I read it there: 
<https://guix.gnu.org/manual/en/html_node/Formatting-Code.html>:

```shell
./etc/indent-code.el gnu/packages/file.scm package
```

If the online manual is considered an old version, where should I look
for the current documentation? Devel?

It seems to be up to date there, indeed:
<https://guix.gnu.org/en/manual/devel/en/guix.html#Formatting-Code>

```shell
./pre-inst-env guix style package
```


> >> - Changelog format
> >
> > "format" and "content".
> >
> > I've heard about a magic trick in Emacs, but as a user of "the other 
> > editor",
> > I have to write everything manually.
> >
> > I guess one could write a command that would detect what has changed and
> > write the changelog. This could also be used on the reviewer/qa side to
> > check if the patch actually does what it says it does.
> 
> I think there's room for improvement here in terms of telling people not
> to worry about it too much, plus providing more guidance on the format
> and common examples.
> 
> There's also tooling like the etc/committer.scm script which I don't
> know anything about really, but it seems to handle writing this message
> in some cases.

```shell
$ ./pre-inst-env guix refresh -u csvkit
# […]
gnu/packages/wireservice.scm:205:13: csvkit: updating from version 1.0.5 to 
version 1.0.7...
# […]

$ guile etc/committer.scm
gnu: csvkit: Update to 1.0.7.

* gnu/packages/wireservice.scm (csvkit): Update to 1.0.7.
[master 715de68b73] gnu: csvkit: Update to 1.0.7.
 1 file changed, 2 insertions(+), 2 deletions(-)
```

Mind=blown™ 勞

Thanks!!!


> >> - Learn how to review more patches
> >
> > Also learn how to review your first patch! Being able to push a "+1"
> > button in the QA interface might be useful?
> > For the time being, I don't know what feedback from me could be useful
> > for a commiter and how to provide it.
> 
> Yep, I think Arun had some useful ideas on this back in February
> [1]. Particuarly including a checklist somewhere (issues.guix.gnu.org or
> maybe qa.guix.gnu.org).
> 
> 1: https://guix.gnu.org/en/blog/2022/online-guix-days-2022-announcement-2/

Added to my "to watch" list.


> Please let me know if I can help with any of this. The QA frontpage in
> particular should have a bunch of easier things to do, and I've got a
> rough list of tasks I put together here [2].
> 
> 2: https://git.cbaines.net/guix/qa-frontpage/about/

First, I'll have to do my homework and read everything that's related to
QA and DataService. I'll let you know as soon as I've found something
useful to bring to the table.


-- 
Tanguy

Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event

[Tanguy LE CARROUR]

Hi Chris,


Quoting Christopher Baines (2022-09-18 17:55:30)
> Here are some notes I took during the discussion on patch review/quality
> assurance at the 10 Years of Guix event.

Thanks for the notes!

After months not contributing, today, I've started contributing patches
again!
Seems like I've forgotten everything, so I can give you a fresh look
at the process…


>   - Minimise the burden for submitters
> - Lengthy guidance for submitting patches

Actually, the `16.4 Packaging Guidelines` and `16.6 Submitting Patches`
are everything that I've ever looked for.

The only problem is `16.5.4 Formatting Code` that makes use of 
`./etc/indent-code.el`
that was removed back in January.


> - Changelog format

"format" and "content".

I've heard about a magic trick in Emacs, but as a user of "the other editor",
I have to write everything manually.

I guess one could write a command that would detect what has changed and
write the changelog. This could also be used on the reviewer/qa side to
check if the patch actually does what it says it does.


> - Sending patches by email (git send-email)

This one is an easy one!… at least, as long a you only have 1 patch.
For a patch set, one has to generate a cover letter, send it, wait for
a bug id to be assigned then send the rest of the patch set.
Looks trivial, but (too) many times I ended up creating multiple bug
reports for the same patch set. And the fear of messing up the bug report system
was something that discouraged me at the beginning. I still do some
mistake from time to time, but… I do not care any more, because I now
know how to fix them.


> - Delay in feedback for first time submitters

It doesn't actually have to be a human feedback. But being able to know
that everything went well (or not) and what's the status of a patch is
would be great.


> - Learn how to review more patches

Also learn how to review your first patch! Being able to push a "+1"
button in the QA interface might be useful?
For the time being, I don't know what feedback from me could be useful
for a commiter and how to provide it.


> - Doing useful things with little time

Go through the list of "Update to X.Y.Z." patches, have a quick glance
and push the "+1" button?


> Actions:
>  - teams thing for finding out about patches, automate this somehow
>  - generate a web page listing the people and teams
>  - Filtered subscription to patches by team

What the status on this? Where can I learn more about how teams work?


>  - Maybe script making contributions like updating packages
>  - Make a similar tool to Debian's how can I help
>- Try to avoid suggesting updating packages with lots of dependencies

`guix how-can-i-help` would be amazing! Something that would:
- list all the packages in my current profile that can be updated,
  sorted by number of dependent packages; and
- list all the packages in my profile that are currently broken.

Actually, for the second point, I guess I'll figure out when upgrading
my profile. Or maybe `guix weather` can help!?

I guess I'll have to dive more into QA, Data Service, Weather to be of
any help. But if you see anything that requires zero-knowledge just let
me know! 

Regards,

-- 
Tanguy

Adopt my patch!

[Tanguy LE CARROUR]

Dear Guix,

I have had much time to contribute recently, but I should be able to
contribute a bit more from now on.

Before sending some new patch, I checked the issue tracker for this that
I might have sent and… totally forgotten about! … again!

So, here is [#53046][]. The v4 still applies and fixes the build
All the dependent packages build successfully, except `gitless` which
seems to be broken for another reason.

[#53046]: https://issues.guix.gnu.org/53046 "[PATCH] gnu: python-args: Patch 
reference to basestring."

I don't actually use `python-args`, but Mamba, which I use on many
projects, unfortunately depends on it!

Any help welcome!

Regards,

-- 
Tanguy

Re: Finding a “good” OpenPGP key server

[Tanguy LE CARROUR]

Hi Ludo’,


Quoting Ludovic Courtès (2022-05-30 17:34:43)
> Maxime Devos  skribis:
> 
> > Ludovic Courtès schreef op ma 18-04-2022 om 22:24 [+0200]:
> >> [... guix refresh -u stuff failing due to not finding the key ...]
> >> I’m not sure what a good solution is (other than looking for the key
> >> manually on Savannah or on some random key server).
> >
> > Alternatively, why use key servers at all?  WDYT of something like
> >
> > (package
> >   (name "gnurl")
> >   [...]
> >   (properties
> > ;; Keys that are considered ‘trustworthy’ for signing releases
> > ;; of gnurl.
> > `((permitted-pgp-signing-keys "CABB A99E ..." "DEAD BEEF ...")
> >   ;; Locations of PGP key (possibly with some of them pointing to
> >   ;; the same key)
> >   (pgp-key-locations
> > ,(savannah-pgp-key USER-ID) ... ; most signers are on 
> > savannah.gnu.org
> > ,(local-file "[...]/someone.pub") ; not easily available from the 
> > Web   
> > "https://rando/key.pub;
> > "ipfs://.../..." "gnunet://..." ; download key via P2P networks
> >
> > The first part (permitted-pgp-signing-keys) has been suggested previously 
> > and
> > seems mostly orthogonal, but the second part is new.  It would reduce
> > the dependency on central infrastructure.  We could consider key servers
> > to be ‘merely’ another fallback.
> 
> We could also have our own key server.  Just like ‘guix lint -c
> archival’ triggers SWH archival, we could have a tool that triggers key
> download on the server so that crypto material never vanishes.

That would be a solution, I guess. But what would be the cost of setting
it up and maintaining it?
Is gnurl the only package with this problem or is it something that happens 
often?!

Regards,

-- 
Tanguy

Re: Let’s meet in person in Paris, Sept. 16–18!

[Tanguy LE CARROUR]

Hi Guix!


Quoting Ludovic Courtès (2022-04-14 16:08:46)
> This year is Guix’s ten year anniversary and also a time when in-person
> meetings are again possible in some regions of the world, so… Simon and
> myself have tentatively scheduled an in-person meeting in Paris, France,
> from September 16th to 18th!  \o/

If everything goes as planned (but life being what it is… who knows!?)
I should be able to attend the 3 days! \o/


> For this to work, we’ll need your help: to define the program (looking
> for speakers, for facilitators for work groups or hacking sessions), for
> the logistics (especially if you live in Paris, but also: setting up
> video capture and publication, live streaming), setting up a web page,
> and so on.

I live in (near) and work in Paris so I can give a hand with logistics!
… depending on what "logistics" means! ^_^'
I can definitively carry stuff and move things around. For the rest, who
knows! :-)


> We have been in contact with IRILL¹, which kindly offers to host the
> event in its offices; we are discussing to confirm the details.
> 
> The way we see it, it would go as follows:
> 
>   1. Friday will be dedicated to uses of Guix for reproducible research
>  workflows, primarily with talks from people with experience in the
>  field.

That might be the perfect time to discuss something that I've wanted to
organise for a looong time: talking about Guix on the French radio in
the April's "Libre à vous" [1][].
Guix as is, is a bit too technical for the audience, but Frédéric Couchet
suggested to talk about a broader subject: "reproductibilité des environnements
logiciels pour la recherche" ("software environment reproducibilité for 
research").
And Guix would be a part of it.
We "just" need to identify potential speakers.

[1]: https://www.libreavous.org/


>   2. Saturday and Sunday will be more informal, with a mixture of talks,
>  tutorials, hacking sessions, install parties, or really whatever
>  you’d like to see happen—including having a birthday cake.  :-)


> We invite y’all to share ideas and suggestions: things you’d like to
> talk about or hear about, hacking sessions you’d like to have with
> others, things you’d like to do to introduce Guix to newcomers.

For what it is worth, here is my top 3:

- Guix System on Olimex Olinuxino
- Guix System GNU/Hurd on Olinuxino… and Viking D8… and Thinkpad T200
- GNUnet on Guix System GNU/Hurd on Olinuxino

Have you spotted the pattern?! :-)

Looking forward to September!

-- 
Tanguy

Re: Finding a “good” OpenPGP key server

[Tanguy LE CARROUR]

Hi Philip,


Quoting Philip McGrath (2022-04-29 21:11:41)
> On 4/18/22 16:24, Ludovic Courtès wrote:
> > Hi,
> > 
> > Tanguy LE CARROUR  skribis:
> > 
> >> gpgv: Signature made Wed 16 Sep 2020 22:30:16 CEST
> >> gpgv:using RSA key 6115012DEA3026F62A98A556D6B570842F7E7F8D
> >> gpgv: Can't check signature: No public key
> >> Would you like to add this key to keyring 
> >> '/home/tanguy/.config/guix/upstream/trustedkeys.kbx'?
> >> yes
> >> gpg: keyserver receive failed: No data
> > 
> > This indicates that ‘guix refresh’ failed to download the relevant GPG
> > key from the default key server, the one that appears in
> > ~/.gnupg/dirmngr.conf (if it exists).
> > 
> > That’s unfortunately often the case these days.  :-/ This key appears to
> > be on keys.openpgp.org, but it lacks a “user ID” packet and so gpg
> > ignores it (for no good reason):
> > 
> > --8<---cut here---start->8---
> > $ gpg --no-default-keyring --keyring 
> > /home/ludo/.config/guix/upstream/trustedkeys.kbx --keyserver 
> > keys.openpgp.org --recv-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
> > gpg: key D6B570842F7E7F8D: no user ID
> > gpg: Total number processed: 1
> > $ gpg --no-default-keyring --keyring 
> > /home/ludo/.config/guix/upstream/trustedkeys.kbx --list-keys 
> > 6115012DEA3026F62A98A556D6B570842F7E7F8D
> > gpg: error reading key: No public key
> > --8<---cut here---end--->8---
> > 
> > I’m not sure what a good solution is (other than looking for the key
> > manually on Savannah or on some random key server).
> > 
> 
> Many distributions of GnuPG include a patch to handle keys without “user 
> ID” packets.[1] In fact, it may well be *most* distributions: Debian, 
> Fedora, Nix, OpenSUSE[2], and at least one commonly-recommended 
> installation option for Mac. Debian packagers have argued [3]:
> 
> > I think GnuPG's inability to receive these
> > kinds of cryptographic updates to OpenPGP certificates that it knows
> > about is at core a security risk (it makes it more likely that users
> > will use a revoked key; or will be unable to use any key at all, and
> > will send plaintext).
> 
> Unfortunately, the upstream GnuPG maintainer has rejected the patch, I 
> guess because strict conformance to the OpenPGP standards requires user 
> ids.[4]
> 
> I am by no means an expert on PGP or GPG issues, but I'd be in favor of 
> Guix adopting this patch.
> 
> -Philip
> 
> [1]: https://keys.openpgp.org/about/faq#older-gnupg
> [2]: https://build.opensuse.org/package/show/openSUSE:Factory/gpg2
> [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930665#10
> [4]: https://dev.gnupg.org/T4393#133689

Oh… thank you so much for your answer! Looks like the proper way to go!
I'll try to update GnuPG package definition to integrate one or several
of those patches.
Or maybe we should first figure out it this is the right thing to do?!

Guix, thoughts!?

Regards,

-- 
Tanguy

Re: PipeWire as a PulseAudio replacement (was Re: The Shepherd on Fibers)

[Tanguy LE CARROUR]

Hi Josselin,


Quoting Josselin Poiret (2022-04-28 14:48:55)
> Tanguy LE CARROUR  writes:
> 
> > I recently switched from Xorg to Wayland and I'm quite happy with my new
> > setup! The only last "little" thing that doesn't work for me is
> > screen-sharing using Icecat and/or Chromium!? :-(
> 
> I know that at least for icecat, it needs to dlopen pipewire for
> screen-sharing to work, but for now it isn't included in the icecat
> package.

Oh! Any roadmap for that?! Is it discussed somewhere else?!


> In the meantime, i've been using the command line
> `LD_LIBRARY_PATH="$(guix build pipewire)/lib" icecat` to get
> screensharing working in icecat.

OK… I'll give it a try.


> Also, you say you've set the env variables, but you need to set them for
> dbus: that means running `update-dbus-activation-environment
> WAYLAND_DISPLAY`, is that what you ended up doing?

If you meant `dbus-update-activation-environment`… this so much what
I have **NOT** done! :-D … I just set ENVVAR. ^_^'

Sorry, but all of this is a bit of voodoo to me! But I'll give it a try.

Thanks for your precious advice!

-- 
Tanguy

Re: PipeWire as a PulseAudio replacement (was Re: The Shepherd on Fibers)

[Tanguy LE CARROUR]

Hi Josselin, hi Brendan, hi Guix,


Quoting Josselin Poiret (2022-03-29 15:22:35)
> Brendan Tildesley  writes:
> > Which environment variables are you talking about? I'm running pipewire on 
> > Guix System
> > and it seems to work fine.
> 
> Right, I think I conflated too many different things, basically my
> use-case was making screensharing work on wlroots-based compositors, but
> the service that need these env variables (at least WAYLAND_DISPLAY I
> think) is xdg-desktop-portal-wlr.  WirePlumber and PipeWire should be
> fine by themselves, since they're started by the session D-Bus and thus
> should have access to it, and shouldn't need anything else.

I recently switched from Xorg to Wayland and I'm quite happy with my new
setup! The only last "little" thing that doesn't work for me is
screen-sharing using Icecat and/or Chromium!? :-(
And, I won't go back to Xorg "just" for that! ^_^'

I would be grateful if someone could tell me how to set up the
PipeWire thingy!?

I've installed `pipewire`, `xdg-desktop-portal-wlr`, and `wireplumber`…
set up the ENV variables `WAYLAND_DISPLAY` and `XDG_CURRENT_DESKTOP`…
set the proper flag in Chromium… but it doesn't seem to work!?

I thought it would be dbus "auto-magic", but apparently not. Event if I
manually start `pipewire` and `wireplumber`, nothing happens when I try
to share my screen, for instance while in a Jitsi Meet meeting.

Any advice welcome! … even a good old RTFM, if it comes with a link to
get the information from! :-)

Regards,

-- 
Tanguy

Re: Finding a “good” OpenPGP key server

[Tanguy LE CARROUR]

Hi Ludo’,

Thanks for updating the topic! :-)


Quoting Ludovic Courtès (2022-04-18 22:24:00)
> Tanguy LE CARROUR  skribis:
> 
> > $ ./pre-inst-env guix refresh -u gnurl
> >
> > Starting download of /tmp/guix-file.NqJa4t
> > From https://ftpmirror.gnu.org/gnu/gnunet/gnurl-7.72.0.tar.gz...
> > following redirection to 
> > `https://mirrors.ocf.berkeley.edu/gnu/gnunet/gnurl-7.72.0.tar.gz'...
> >  …2.0.tar.gz  3.3MiB  3.1MiB/s 00:01 [##] 
> > 100.0%
> >
> > Starting download of /tmp/guix-file.VXn0IS
> > From https://ftpmirror.gnu.org/gnu/gnunet/gnurl-7.72.0.tar.gz.sig...
> > following redirection to 
> > `https://mirrors.ocf.berkeley.edu/gnu/gnunet/gnurl-7.72.0.tar.gz.sig'...
> >  …0.tar.gz.sig  833B  654KiB/s 00:00 [##] 
> > 100.0%
> > gpgv: Signature made Wed 16 Sep 2020 22:30:16 CEST
> > gpgv:using RSA key 6115012DEA3026F62A98A556D6B570842F7E7F8D
> > gpgv: Can't check signature: No public key
> > Would you like to add this key to keyring 
> > '/home/tanguy/.config/guix/upstream/trustedkeys.kbx'?
> > yes
> > gpg: keyserver receive failed: No data
> 
> This indicates that ‘guix refresh’ failed to download the relevant GPG
> key from the default key server, the one that appears in
> ~/.gnupg/dirmngr.conf (if it exists).
> 
> That’s unfortunately often the case these days.  :-/ This key appears to
> be on keys.openpgp.org, but it lacks a “user ID” packet and so gpg
> ignores it (for no good reason):
> 
> --8<---cut here---start->8---
> $ gpg --no-default-keyring --keyring 
> /home/ludo/.config/guix/upstream/trustedkeys.kbx --keyserver keys.openpgp.org 
> --recv-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
> gpg: key D6B570842F7E7F8D: no user ID
> gpg: Total number processed: 1
> $ gpg --no-default-keyring --keyring 
> /home/ludo/.config/guix/upstream/trustedkeys.kbx --list-keys 
> 6115012DEA3026F62A98A556D6B570842F7E7F8D
> gpg: error reading key: No public key
> --8<---cut here---end--->8---
> 
> I’m not sure what a good solution is (other than looking for the key
> manually on Savannah or on some random key server).

Sorry it took me so long to answer!

Actually, Nikita answered this question on a thread on GNUnet's mailing list:

https://lists.gnu.org/archive/html/gnunet-developers/2022-04/msg00030.html

The end of the discussion is off list. The key used to
sign the package is deprecated and not to be used any more/any where.

The proper solution should come from GNUnet, but maybe, we could bypass
the key verification in Guix. Or, I could clone the repo, claim
ownership and sign a new package myself. But that doesn't look like a
good/fair solution to me! Thoughts?!

Regards,

-- 
Tanguy

Error updating gnurl

[Tanguy LE CARROUR]

As mentionned on GNUnet mailing list [1][], gnurl is affected by security 
issues.

[1]: https://lists.gnu.org/archive/html/gnunet-developers/2022-04/msg00021.html

It might not affect GNUnet, but I tried to update the package in Guix anyway, 
and…
I failed! ^_^'

```console
$ ./pre-inst-env guix refresh -u gnurl

Starting download of /tmp/guix-file.NqJa4t
>From https://ftpmirror.gnu.org/gnu/gnunet/gnurl-7.72.0.tar.gz...
following redirection to 
`https://mirrors.ocf.berkeley.edu/gnu/gnunet/gnurl-7.72.0.tar.gz'...
 …2.0.tar.gz  3.3MiB  3.1MiB/s 00:01 [##] 100.0%

Starting download of /tmp/guix-file.VXn0IS
>From https://ftpmirror.gnu.org/gnu/gnunet/gnurl-7.72.0.tar.gz.sig...
following redirection to 
`https://mirrors.ocf.berkeley.edu/gnu/gnunet/gnurl-7.72.0.tar.gz.sig'...
 …0.tar.gz.sig  833B  654KiB/s 00:00 [##] 100.0%
gpgv: Signature made Wed 16 Sep 2020 22:30:16 CEST
gpgv:using RSA key 6115012DEA3026F62A98A556D6B570842F7E7F8D
gpgv: Can't check signature: No public key
Would you like to add this key to keyring 
'/home/tanguy/.config/guix/upstream/trustedkeys.kbx'?
yes
gpg: keyserver receive failed: No data
guix refresh: warning: missing public key 
6115012DEA3026F62A98A556D6B570842F7E7F8D for 
'mirror://gnu/gnunet/gnurl-7.72.0.tar.gz'
guix refresh: warning: gnurl: version 7.72.0 could not be downloaded and 
authenticated; not updating
```

Have I done something wrong?!

Regards,

-- 
Tanguy

Re: Creating subtitles for the Guix Days videos!

[Tanguy LE CARROUR]

Hi Matt,

Quoting Matt (2022-03-02 00:18:42)
> 
>   On Tue, 01 Mar 2022 09:36:19 -0500 Julien Lepiller  
> wrote 
>  > I'm looking for volunteers to create English subtitles for the Guix Days
>  > talks. It would be great for people who are not very good with spoken
>  > English but who can still understand text.
>  > […]
>  
> Aegisub kept crashing when setting hotkeys, but I was able to set some up 
> that make navigation easier.  
> 
> In the "subtitle edit box", I added:
> Alt-P audio/play/line
> Ctrl-N time/next
> Ctrl-P time/prev
> 
> This is allows me to navigate by lines, play the audio for that section, and 
> then press Return to "commit" what I wrote for the subtitle.

Sorry to hear that it was painful for you! :-(

For, what it's worth, here is how it went for me…

I started before someone added the instructions on the pad, so I went
straight to watching a tuto on YT:
« Aegisub tutorial - Timing Subtitles - FAST METHOD »

The guy suggested to first do the transcription and then the video sync'.
This is what I did using the good old Vim. Took me 1h30 for 17min of video.

Once the transcription file was loaded into Aegisub I discovered that the
keybings were right under my right hand fingers! I use a French Bépo
layout, and I can access D-S-G-F with only 2 fingers! 8-)

This allowed me to use my mouse (I use my mouse with my left hand) to
move the start (right click) and end (left click) of a section.

Muscle memory did the rest! s…d…left click…d…g *ad nauseam* :-)

I wouldn't go so far as to say that it was the best evening of my life,
but it was not the most painful 3 hours either! … actually, the fact
that the talk was super interesting and the speaker's English was really good
helped a lot! Thanks Lars-Dominik! :-)

-- 
Tanguy

Re: Creating subtitles for the Guix Days videos!

[Tanguy LE CARROUR]

Hi Julien,


Quoting Julien Lepiller (2022-03-01 15:36:19)
> I'm looking for volunteers to create English subtitles for the Guix Days
> talks. […] Please send me the subtitles once
> they are completed, I'll add them with the videos.

It's my first time, so thank you for your indulgence! :-)

I'm attaching my humble contribution:

- `.txt` the transcription ;
- `.ass` the file created by Aegisub ; and
- `.sub` an attempt to export it to sub format.

I have to admit that is pretty bad "punctuation-wise", because I was not
sure were the sentences started and ended. Sorry!

Just let me know if I have to fix anything.

Regards,

-- 
Tanguyhello everyone
nice to have you here at Guix Days 2022
I would like to talk about Python build system
and why we need to modernize it
python-build-system is the Guix component
that turns the source distribution of any Python package out there
into an installable image
so, basically, a directory under the GNU store
let's have a look at tomli a quite simple Python package
which has no external dependencies
so, if we import it using `guix import`, here
add a few imports to the resulting file
and then try to build it
it should work out of the box, right?
The problem is, it does not!
and instead we see at the bottom
an error message saying "no setup.py found"
and, indeed, if we look at the source distribution
there is no `setup.py` to be found anywhere
So, what is going on?
Fortunately, this package is already available in Guix
as `python-tomli`
so we can have a look at its definition
to see how it is currently built
let's just do that
looking at the build system's arguments
we see the phases `build` here and `install` here
which are usually provided by Python build system
replaced with custom code
I'm only showing the interesting parts here
the actual commands are actually much longer
first the build phase
uses a Python module called `build`
to build the wheel, as we can see here
the wheel is basically a distribution format in the Python world
then in the install phase
we simply use a well known tool called Pip
to install the wheel that we just built
into the output which would be somewhere around the GNU store
so how does the build module knows what to do
what to build?
it follows PEP 517
PEPs are kind of the RFCs of the Python world
and this PEP basically splits building wheels into two parts
a frontend and a backend
the frontend is the user facing part
for example the `build` we just saw here
this is the user facing part of the build process
and then a backend
the frontend is supposed to read a file called `pyproject.toml`
this is what we are seeing here
and in that TOML file, a section called `build-system`
this one here
declares which backend will actually build our wheel
and, in this case, another package called `flit_core`
its requirements a build time dependency of tomli
and its module `flit_core.buildapi`
is providing us with the build entrypoint.
The file also contains standardize metadata
and tool related configuration data
which I'm not showing here
A PEP 517* compatible build backend
provides a standard function entrypoint
called `build_wheel`
in the module I just referenced here in the top
and, if we call it, it will just do its magic
and it will produce a wheel file
and its first argument it's the wheel directory
that wheel is basically a zip file
with a predefined structure
that we can extract into our store
and we are almost done
and this is what Pip does in the install phase here
and that's basically the entire build process
as specified by PEP 517
there is no `setup.py` involved any more
we don't have to call it
we don't have to create it as a package provider
so the reason why the error message I showed, showed up earlier
will keep on poping up more and more
is simple: we are late!
we are really really late, actually
because PEP 517 was originally created in 2015
and that it gained provisional acceptance in 2017
and just last year,
after being basically being the *de facto* successor of `setup.py` for some time
it has been finalized and fully accepted
and more importantly, flit which you remember from the previous slide
is also able to create source distributions
and upload them to PyPI
Python public package repository basically
so far, it has been generating a `setup.py`
and does nobody really noticed
but since version 3.5, which was released in November 2021
flit stop doing that by default
and thus we are seeing more and more packages without `setup.py`
in their source distributions
and so we are basically unable to build this projects right now
or this Python modules
a look at the Guix's repository in late January
and back then only 11 packages actually used Pip
or PyPA build as we've seen
but I think our ecosystem is quite old
about half the packages not being the latest versions available upstream
according to `guix refresh`
so it's possible that more packages actually require support for this 
`pyproject.toml`
and we simply have not updated them yet for 

Fixing python-notmuch2

[Tanguy LE CARROUR]

Hi Guix!

python-notmuch2 is broken [1] since the upgrade of notmuch
to version 0.35 (fb3508bb36).
Looks like a Python file is supposed to be generated by the configure
phase [2], but python-notmuch2 uses the python-build-system which, I
guess, does not run configure.

[1]: https://ci.guix.gnu.org/build/467828/details
[2]: 
https://git.notmuchmail.org/git?p=notmuch;a=commit;h=7b5921877e748338359a25dae578771f768183af

I'm not sure how to fix the problem!? Any advice would be welcome!

Regards,

-- 
Tanguy

Fixing python-notmuch2

[Tanguy LE CARROUR]

Hi Guix!

python-notmuch2 is broken [1] since the upgrade of notmuch
to version 0.35 (fb3508bb36).
Looks like a Python file is supposed to be generated by the configure
phase [2], but python-notmuch2 uses the python-build-system which, I
guess, does not run configure.

[1]: https://ci.guix.gnu.org/build/467828/details
[2]: 
https://git.notmuchmail.org/git?p=notmuch;a=commit;h=7b5921877e748338359a25dae578771f768183af

I'm not sure how to fix the problem!? Any advice would be welcome!

Regards,

-- 
Tanguy

Re: Making `python-next` the next `python`

[Tanguy LE CARROUR]

Hi Guillaume, hi Leo,


Excerpts from Leo Famulari's message of November 8, 2021 4:27 pm:
> On Mon, Nov 08, 2021 at 10:58:40AM +0100, Tanguy LE CARROUR wrote:
>> Just to make sure I don't ask any other stupid questions in the future,
>> where am I supposed to get this information from? I mean, I checked
>> `guix-devel` before posting, but could not find any mention to this topic.
> 
> You have to deduce it based on some knowledge about what kind of
> packages can be updated on the master branch and what kind of packages
> cannot be updated there.
> […]
> Then, you can check out the core-updates branch and see if the update
> has been performed there. As we are in the final stages of the
> core-updates cycle, there is also a core-updates-frozen branch, and even
> a core-updates-frozen-batched-changes branch... to learn about those,
> you'd have to ask on IRC or guix-devel.
> 
> I hope that helps!

Very helpful indeed! Thanks guys for taking the time to answer!

Best regards,

-- 
Tanguy

Re: Making `python-next` the next `python`

[Tanguy LE CARROUR]

Hi Guillaume,

Excerpts from Guillaume Le Vaillant's message of November 8, 2021 10:26 am:
> Tanguy LE CARROUR  skribis:
>> I've just started working on packaging Python 3.10 and realized
>> that Guix's default version for Python is still 3.8.
>>
>> What would be the proper way to make 3.9 the default version?
>> Do I "just" have to submit a patch that rename the related packages?
> 
> Python 3.9 is already the default version on the core-updates-frozen
> branch. After it is merged in master, a python-next package can be added
> for Python 3.10.

Great! Thanks and… sorry for the noise! ^_^'
I'll wait for the release then, and keep on working on 3.10.

Just to make sure I don't ask any other stupid questions in the future,
where am I supposed to get this information from? I mean, I checked
`guix-devel` before posting, but could not find any mention to this topic.

Thanks again,

-- 
Tanguy

Making `python-next` the next `python`

[Tanguy LE CARROUR]

Dear Guix,

I've just started working on packaging Python 3.10 and realized
that Guix's default version for Python is still 3.8.

What would be the proper way to make 3.9 the default version?
Do I "just" have to submit a patch that rename the related packages?

Regards,

--
Tanguy

Re: Questions regarding Python packaging

[Tanguy LE CARROUR]

Hi Lars,


Excerpts from Lars-Dominik Braun's message of May 17, 2021 8:24 am:
> just a quick reminder that an updated version (includes
> python-toolchain) of this proposal is still looking for a code review or
> further discussion. So if you feel confident about touching
> python-build-system, please have a look at
> https://issues.guix.gnu.org/46848#1
> 
> I’d be nice to get this into core-updates before the next merge.
> Otherwise we’ll have to keep adding workarounds (see for example
> python-testpath in master) to Python packages not using setuptools as
> their build system.

Sorry if I'm (very) late, but apprently this hasn't made it to master
yet, so… What the status? Do you still need a willing-but-maybe-not-qualified
person to review or discuss your patch?

Regards,

-- 
Tanguy

Re: Questions regarding Python packaging

[Tanguy LE CARROUR]

Excerpts from Tanguy LE CARROUR's message of January 22, 2021 9:38 am:
> Excerpts from Tanguy LE CARROUR's message of January 6, 2021 4:32 pm:
>> Excerpts from Lars-Dominik Braun's message of January 5, 2021 11:25 am:
 So, I've tried packaging `python-keyring` with those two…
 
 `pep517` keeps on trying to download dependencies, which won't work.
 
 `build` crashes with "ZIP does not support timestamps before 1980",
 which, I guess is related to the fact that everything in the store is
 timestamped to January 1st 1970.
>>> have you been looking into a python-build-system using `build`[1]? I’ve
>>> had the same issue with egg versions set to 0.0.0 and think in the long
>>> run moving to a PEP 517-style build is the way forward.
>> 
>> I agree! Unfortunately, I haven't had much time (so far) to work on it! :-(
>> 
>> I'll revive the thread as soon as I've made progress…
> 
> Done! :-)
> I've eventually succeeded in ("properly") packaging a software managed
> with Poetry. And I've learned quite a lot on the way!

Just for the sake of having it documented somewhere, here is the
relevant part of the `guix.scm` file:

```
(define-public nowty
  (package
(name "nowty")
(version (string-append %pyproject-version "+" %git-commit))
(source (local-file %source-dir #:recursive? #t))
(build-system python-build-system)
(arguments
 `(#:phases
   (modify-phases %standard-phases
(replace 'build
 (lambda* (#:key #:allow-other-keys)
   (substitute* "pyproject.toml"
(((string-append "version = \"" ,%pyproject-version "\"" ))
 (string-append "version = \"" ,version "\"")
(replace 'install
 (lambda* (#:key outputs #:allow-other-keys)
  (let ((out (assoc-ref outputs "out")))
   (invoke "python" "-m" "pip" "install"
   "--no-dependencies" "--no-build-isolation" "--prefix" out 
"."
(replace 'check
 (lambda* (#:key inputs outputs #:allow-other-keys)
  (add-installed-pythonpath inputs outputs)
  (invoke "python" "-m" "invoke" "test.unit"))
(native-inputs
 `(("python-invoke" ,python-invoke-patched)
   ("python-mamba" ,python-mamba)
   ("python-poetry-core" ,python-poetry-core)
   ("python-robber" ,python-robber)
   ("python-termcolor" ,python-termcolor)))
(propagated-inputs
 `(("python-mpd2" ,python-mpd2)
   ("python-typer" ,python-typer)))
(synopsis "Music notification daemon for MPD")
(description "A music notification daemon that monitors songs being played 
by MPD
and displays notifications with the song's details.")
(home-page "http://projects.bioneland.org/nowty;)
(license license:gpl3+)))
```

-- 
Tanguy

Re: Questions regarding Python packaging

[Tanguy LE CARROUR]

Hi Lars,


Excerpts from Lars-Dominik Braun's message of January 23, 2021 1:34 pm:
>> Done! :-)
>> I've eventually succeeded in ("properly") packaging a software managed
>> with Poetry. And I've learned quite a lot on the way!
> oh, I see. I’ve actually been trying to replace python-build-system with
> a python-build based build. Attached is my current work in progress. I
> cannot quite build python-build, ,

?!
My `python-build` seems to work:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45931


> because I’m lacking support for python-flit

I also had a problem with `python-flit`, but it was when I was working
on `python-typer`:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45935

This is why I didn't build it from the source.


> but I think the general idea is clear: Remove pip and
> setuptools from python (saves almost 20MiB from the closure and avoids
> weird conflicts between python’s setuptools and python-setuptools) and
> turn them into (almost) ordinary packages. Then use setuptools to
> bootstrap itself, bootstrap python-build with setuptools and use
> python-build to build evrey other packages using python-build-system.

Wow, the rest is way out of my comfort zone! But I'll read it carefully
and try to help if I can!

Best regards,

-- 
Tanguy

Re: Questions regarding Python packaging

[Tanguy LE CARROUR]

Hi Guix, hi Lars,


Excerpts from Tanguy LE CARROUR's message of January 6, 2021 4:32 pm:
> Excerpts from Lars-Dominik Braun's message of January 5, 2021 11:25 am:
>>> So, I've tried packaging `python-keyring` with those two…
>>> 
>>> `pep517` keeps on trying to download dependencies, which won't work.
>>> 
>>> `build` crashes with "ZIP does not support timestamps before 1980",
>>> which, I guess is related to the fact that everything in the store is
>>> timestamped to January 1st 1970.
>> have you been looking into a python-build-system using `build`[1]? I’ve
>> had the same issue with egg versions set to 0.0.0 and think in the long
>> run moving to a PEP 517-style build is the way forward.
> 
> I agree! Unfortunately, I haven't had much time (so far) to work on it! :-(
> 
> I'll revive the thread as soon as I've made progress…

Done! :-)
I've eventually succeeded in ("properly") packaging a software managed
with Poetry. And I've learned quite a lot on the way!

Following Efraim's presentation on Guix Day, I've added a `guix.scm`
file to one of my pet projects. Any Guix user should be able to build it.

```bash
$ git clone https://gitlab.com/TanguyEE/nowty.git
Cloning into 'nowty'...
[…]

$ cd nowty/
$ guix build --file=guix.scm
[…]
successfully built /gnu/store/[…]-nowty-0.1.0a0+2d656ef.drv
/gnu/store/[…]-nowty-0.1.0a0+2d656ef

$ /gnu/store/[…]-nowty-0.1.0a0+2d656ef/bin/nowty
'High Hopes' from album 'Pray for the Wicked' by 'Panic! at the Disco'.
```

Regarding the package definition:
- the `build` phase updates the package version in `pyproject.toml` ;
- the `install` phase uses `pip` which in turn uses the build system
  from `poetry-core`.

I know that the phase names don't make much sense! … but it's a
work in progress ! :-)

Any comment welcome.

Regards,

-- 
Tanguy

Re: Questions regarding Python packaging

[Tanguy LE CARROUR]

Excerpts from Lars-Dominik Braun's message of January 5, 2021 11:25 am:
> Hi Tanguy,
> 
>> So, I've tried packaging `python-keyring` with those two…
>> 
>> `pep517` keeps on trying to download dependencies, which won't work.
>> 
>> `build` crashes with "ZIP does not support timestamps before 1980",
>> which, I guess is related to the fact that everything in the store is
>> timestamped to January 1st 1970.
> have you been looking into a python-build-system using `build`[1]? I’ve
> had the same issue with egg versions set to 0.0.0 and think in the long
> run moving to a PEP 517-style build is the way forward.

Actually —and I almost forgot!—, Sébastien found a solution to our "0.0.0" 
problem:
https://github.com/jaraco/keyring/issues/469#issuecomment-735695476

-- 
Tanguy

Re: Questions regarding Python packaging

[Tanguy LE CARROUR]

Hi Lars,


Excerpts from Lars-Dominik Braun's message of January 5, 2021 11:25 am:
> Hi Tanguy,
> 
>> So, I've tried packaging `python-keyring` with those two…
>> 
>> `pep517` keeps on trying to download dependencies, which won't work.
>> 
>> `build` crashes with "ZIP does not support timestamps before 1980",
>> which, I guess is related to the fact that everything in the store is
>> timestamped to January 1st 1970.
> have you been looking into a python-build-system using `build`[1]? I’ve
> had the same issue with egg versions set to 0.0.0 and think in the long
> run moving to a PEP 517-style build is the way forward.

I agree! Unfortunately, I haven't had much time (so far) to work on it! :-(

I'll revive the thread as soon as I've made progress…

Regards!

-- 
Tanguy

Re: Poetry upgrade and related packages

[Tanguy LE CARROUR]

Hi,

Excerpts from Marius Bakke's message of December 9, 2020 12:25 am:
> For some practical experience, you can try updating to Python 3.9.1 and
> the latest Pytest (+ dependencies).  This needs to be done soon for the
> 'core-updates' branch anyway.  ;-)

Let's give it a try! 8-)

Regards,

-- 
Tanguy

Re: Poetry upgrade and related packages

[Tanguy LE CARROUR]

Hi Marius,


Excerpts from Marius Bakke's message of December 7, 2020 11:59 pm:
> Tanguy LE CARROUR  skriver:
>> Excerpts from Ludovic Courtès's message of December 5, 2020 4:44 pm:
>>> Tanguy LE CARROUR  skribis:
>>> 
>>>> It's not yet clear to me how to handle (python) package updates:
>>>> - when to update;
>>>> - when not to update;
>>>> - when to introduce "versionned" (`-x.y` suffix) package definitions;
>>>> - when to introduce "next" (`/next` suffix) package definitions;
>>>> - when to remove the two above suffixes;
>>>> - …
>>>>
>>>> So I'm looking forward to reading the answers to this thread! :-)
>>> 
>>> When a change introduces too many rebuilds, the convention is to make
>>> that change on a branch that will be merged “later” rather than on
>>> ‘master’; this is bullet 8 here:
>>> 
>>>   https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html
>>
>> Thanks for pointing at, but this "just" tells me on which branch to put
>> the changeset, not which of the above options should be used when a
>> package needs to be updated.
> 
> There is no "one size fits all" rule.  With rare exceptions, Guix
> "wants" to have only have a single version of each package (mainly to
> ease maintenance).  As you found, that's not always feasible.
> 
> If a package depends on a newer version of something "deep in the graph"
> such as Pytest, it's always OK to add a "/next" or "-x.y" variant
> (though a convention about which to use would probably be a good idea).
>
> If something depends on a *specific* (older) version of Pytest, it's
> better to try and make it work with the newer version; but failing that,
> adding a "-x.y" is fine too.

`-x.y` packages are here to stay.
`/next` are temporary packages.

Is it safe to remove all `-x.y` packages that are not used as inputs?
Is there a (programmatic) way to find those packages?

When `/next` become "current|default|latest", who is in charge of patching
all the package definitions that were using it?!


>>> Yet, sometimes we want to introduce new versions that people can get in
>>> their profile, even if the “default” one remains the older version to
>>> avoid world rebuilds.
>>
>> That's exactly my point! If the default one lags behind, then after some
>> time, nobody will use it any more and we will have introduced one or more
>> `-x.y` package definitions!
>> I would consider it to be a "saner" approach to have the default always
>> "point" to the latest version, but then we would have to "fix" package
>> depending on older versions by introducing `-x.y` package definitions
>> for them.
>>
>> Or am I missing something?!
> 
> You got it right.  It might be saner to make the unversioned variable
> refer to the newest version, but it would often require "pinning"
> hundreds of packages to the old version to avoid rebuilds.  Thus, it's
> typically more practical to use the "/next" variant until the next
> rebuild cycle.

Then, during the rebuild cycle those hundreds of packages get rebuilt
and… some of them fail because they depend on the older version, right?!
But I'm pretty sure it's a problem all distributions have to face.

Wasn't it discussed somewhere else that one should get notified (by email)
when their favourite packages were broken?


> Again there is no hard rule here, I did such a change for 'libcap' in
> 9e1f5a263e4f6df4d075901c9b58a56f80c8b452 because only two packages
> needed to pin the old version.

> Hope this clears things up a little more.  :-)

Yes, thanks! But I guess I need to go through more of those situations
to make sure I understand everything.

-- 
Tanguy

Re: Poetry upgrade and related packages

[Tanguy LE CARROUR]

Hi,


Excerpts from Ludovic Courtès's message of December 5, 2020 4:44 pm:
> Tanguy LE CARROUR  skribis:
> 
>> It's not yet clear to me how to handle (python) package updates:
>> - when to update;
>> - when not to update;
>> - when to introduce "versionned" (`-x.y` suffix) package definitions;
>> - when to introduce "next" (`/next` suffix) package definitions;
>> - when to remove the two above suffixes;
>> - …
>>
>> So I'm looking forward to reading the answers to this thread! :-)
> 
> When a change introduces too many rebuilds, the convention is to make
> that change on a branch that will be merged “later” rather than on
> ‘master’; this is bullet 8 here:
> 
>   https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html

Thanks for pointing at, but this "just" tells me on which branch to put
the changeset, not which of the above options should be used when a
package needs to be updated.


> Yet, sometimes we want to introduce new versions that people can get in
> their profile, even if the “default” one remains the older version to
> avoid world rebuilds.

That's exactly my point! If the default one lags behind, then after some
time, nobody will use it any more and we will have introduced one or more
`-x.y` package definitions!
I would consider it to be a "saner" approach to have the default always
"point" to the latest version, but then we would have to "fix" package
depending on older versions by introducing `-x.y` package definitions
for them.

Or am I missing something?!


> One example is GDB: gdb@8 has 1,671 dependents, but we added gdb@10 on
> the side such that “guix install gdb” gives you version 10.

The difference here is that it's a package added to a profile, not a
dependency, so `gdb` means the latest available version of GDB, right?

As you can see, everything is not yet clear to me! Sorry! ^_^'

-- 
Tanguy

Re: Poetry upgrade and related packages

[Tanguy LE CARROUR]

Hi Sébastien, hi Guix!


Excerpts from Sébastien Lerique's message of December 2, 2020 12:49 pm:
> This thread is an attempt to keep a handle on the various patches 
> involved in upgrading Poetry to 1.1.4, and to ask a couple 
> questions that crop up.
> 
> - Tanguy's original patch http://issues.guix.info/44077 is merged
> - But python-packaging had to be downgraded again because it 
>   generated too much rebuilds 
>   
> - Tanguy submitted another patch for Poetry reducing 
>   python-packaging's required version: 
>   https://issues.guix.info/45003
> 
> Now, there are a couple more hiccups with other packages:
> - poetry actually requires a more recent version of python-keyring 
>   (>=21.2.0 instead of the current 21.0.0),
> - upstream python-keyring is at 21.5.0, which requires 
>   python-setuptools >= 42 (guix now has 41.0.1)
> - as a sidenote, when I locally added setuptools >=42 explicitely 
>   to python-keyring's native-inputs, it solved the version 
>   declaration problem described here 
>   
> 
> 
> Question: upstream setuptools is at 50.3.2, and they have dropped 
> python2 support at v45 (see 
> ). 
> Should we simply upgrade to v44, or rather create alternate 
> python{,2}-setuptools-44 packages? `guix refresh -l 
> python2-setuptools` lists 48 dependent packages.

Thank you for summarising the situation!

It's not yet clear to me how to handle (python) package updates:
- when to update;
- when not to update;
- when to introduce "versionned" (`-x.y` suffix) package definitions;
- when to introduce "next" (`/next` suffix) package definitions;
- when to remove the two above suffixes;
- …

So I'm looking forward to reading the answers to this thread! :-)

-- 
Tanguy

Re: 01/07: gnu: python-packaging: Update to 20.4.

[Tanguy LE CARROUR]

Hi Marius!


Excerpts from Tanguy LE CARROUR's message of December 2, 2020 8:56 am:
> Excerpts from Marius Bakke's message of December 2, 2020 12:10 am:
>> guix-comm...@gnu.org skriver:
>> 
>>> ngz pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit 71b15b4874b7f9ec7001d2916a8ab27dcce6cdc0
>>> Author: Tanguy Le Carrour 
>>> AuthorDate: Mon Nov 30 10:48:57 2020 +0100
>>>
>>> gnu: python-packaging: Update to 20.4.
>>> 
>>> * gnu/packages/python-xyz.scm (python-packaging): Update to 20.4.
>>> [source]: Remove patch that has been merged upstream.
>>> * gnu/packages/patches/python-packaging-test-arch.patch: Remove file.
>>> * gnu/local.mk (dist_patch_DATA): Apply removal.
>>> 
>>> Signed-off-by: Nicolas Goaziou 
>> 
>> I have just reverted this patch on 'master' because it caused 6328
>> rebuilds.
>> […]
>> @Tanguy: do you know if Poetry will still work with the old version?
> 
> Probably not… I'll have to check. But anyway, Sébastien and I might be
> the only persons using it, so… it's no big deal, I guess! :-)

In fact, it does not!
I've just submitted patch #45003 that seems to solve the problem.

-- 
Tanguy

Re: 01/07: gnu: python-packaging: Update to 20.4.

[Tanguy LE CARROUR]

Hi Marius!


Excerpts from Marius Bakke's message of December 2, 2020 12:10 am:
> Hello,
> 
> guix-comm...@gnu.org skriver:
> 
>> ngz pushed a commit to branch master
>> in repository guix.
>>
>> commit 71b15b4874b7f9ec7001d2916a8ab27dcce6cdc0
>> Author: Tanguy Le Carrour 
>> AuthorDate: Mon Nov 30 10:48:57 2020 +0100
>>
>> gnu: python-packaging: Update to 20.4.
>> 
>> * gnu/packages/python-xyz.scm (python-packaging): Update to 20.4.
>> [source]: Remove patch that has been merged upstream.
>> * gnu/packages/patches/python-packaging-test-arch.patch: Remove file.
>> * gnu/local.mk (dist_patch_DATA): Apply removal.
>> 
>> Signed-off-by: Nicolas Goaziou 
> 
> I have just reverted this patch on 'master' because it caused 6328
> rebuilds.

So, this is the situation Nicolas was talking about!
Sorry guys for the inconvenience! :-(


> It's not obvious, because they come via the 'bootstrap'
> variant defined below the main package:
> 
>   $ guix refresh -l -e '(@ (gnu packages python-xyz) 
> python-packaging-bootstrap)'
>   Building the following 2399 packages would ensure 6328 dependent
>   packages are rebuilt: [...]
> 
> Not sure how we can improve on this.  Thoughts?

What about applying the same `/next` trick that you suggested for
`distlib`?


> @Tanguy: do you know if Poetry will still work with the old version?

Probably not… I'll have to check. But anyway, Sébastien and I might be
the only persons using it, so… it's no big deal, I guess! :-)

Thanks for caring!

-- 
Tanguy

Re: Questions regarding Python packaging

[Tanguy Le Carrour]

Hi Hartmut,


Le 11/09, Hartmut Goebel a écrit :
> seems like another messages of mine, regarding the first thread  about a
> poetry build system, did not make it to the list.
> 
> Am 08.11.20 um 15:27 schrieb Tanguy Le Carrour:
> > I've just learned, by accident (working on `python-keyring` [1]), that
> > `python setup.py install` was somehow deprecated
> 
> This statement is not exactly true - well, depending on interpretation of
> "somehow". I've not set seen an official deprecation.

Neither did I! But things are changing (fast) and it seems that I'm
always the last one to know! ^_^'


> It's true that users are encouraged to use pip for installing packages. But
> the official Python Packaging Tutorial [1] is still based on setuptools (not
> even recommending a setup.cfg file). Thus setuptools will be around for
> quite some more time, as will "python setup.py install".
> 
> [1] https://packaging.python.org/tutorials/packaging-projects/
>
> In the future Python world, any build-tool can be specified in
> "pyproject.toml". User will then call "pip install", and pip will (AFAIU)
> call a Python function (aka entry-point) specified in that file. (If this
> file does not exist, setuptools are assumed). For our python-build-system,
> we would use "pip wheel" (for phase build) and "pip install" (for phase
> install).
> 
> So, if we switch to "pip wheel" and "pip install", different python build
> systems could share a common base, just redefining some dependencies
> (setuptools, poetry, build, ...) and some tool-dependent flags. Is this the
> direction you are working towards?

I cannot say that, at the moment, I'm working in any particular direction!
… I'm just trying to make "it" work and learn a bit about Guix packaging
and Python along the way.

Actually, I'm not even yet sure that Poetry needs a dedicated build system,
as it also relies on a build-backend (defined in `pyproject.toml`) which
just happened to be `poetry.core.masonry`, but could be another one… I
guess, I'm not sure yet.

So, definitively a WIP!


> > in favor of tools like`pep517` or `build`.
> 
> Thanks for point to these, both are new to me.
> 
> "build" sounds interesting, esp. for guix: "It is a simple build tool and
> does not perform any dependency management." This would help us spliting
> dependency management and build phase. Anyhow, it's quite new (half an year
> old) and implements a PEP 517 package builder - and PEP 517 (defining the
> build system in pyproject.toml) is not yet adopted widely.
> 
> "pep517" seems o be a library used for "build". Its high-level interface has
> been deprecated in favor for "build".
> 
> I as just about to write "So, while this might be one road to go, this is
> not of much use for us yet.". Anyhow, this might be a good base for pep517
> based packages. On the other hand: Maybe we'd better stick with "pip wheel"
> and "pip install", see above.

+1! I'll try to make those packages who need a special build system
(which might be the case for `keyring`) work and see for a more
general "new" `python-build-system` later! And if I happen to learn
something on the way… great! :-)

Regards

-- 
Tanguy

Re: Questions regarding Python packaging

[Tanguy Le Carrour]

Hi Leo,


Le 11/08, Leo Famulari a écrit :
> On Sun, Nov 08, 2020 at 03:27:17PM +0100, Tanguy Le Carrour wrote:
> > `pep517` keeps on trying to download dependencies, which won't work.
>
> That usually means that the software is missing some dependencies. If
> you think they should be available in the build environment,
> double-check that they are, and then look into how the software is
> looking for them.

I'll check and double check!


> > `build` crashes with "ZIP does not support timestamps before 1980",
> > which, I guess is related to the fact that everything in the store is
> > timestamped to January 1st 1970.
> 
> Are you using the python-build-system? It should handle this problem
> with its 'ensure-no-mtimes-pre-1980' phase.

Good to know, thanks! I'll read more about this 'ensure-no-mtimes-pre-1980'
phase.


> If will help if you share your package definition.

I'll work a bit more on it based on your answers guys and post a WIP to
guix-devel.

Regards

-- 
Tanguy

Re: Questions regarding Python packaging

[Tanguy Le Carrour]

Hi Michael,


Le 11/08, Michael Rohleder a écrit :
> Tanguy Le Carrour  writes:
> > I've just learned, by accident (working on `python-keyring` [1]), that
> > `python setup.py install` was somehow deprecated in favor of tools like
> > `pep517` or `build`.
> >
> > So, I've tried packaging `python-keyring` with those two…
>
> apropos python-keyring:
>
> I also tried to update that package (in order to package "pantalaimon"
> which needs this) [1]
> The problem with this thing is, it wants to install an egginfo with
> version 0.0.0, no matter if build with setup.py or poetry [2]
>
> I tried debugging^Whacking this a while (eg. updateing setuptools, as
> suggested in the ticket), but couldn't make it work.
> If you find a solution, I'd be interested ;)
>
> Footnotes:
> [1] 
> https://rohleder.de/gitweb/?p=guix.git;a=blob;f=mroh/guix/packages/python.scm;h=0c847795375ce08ca878727f15fd1a1b156df6f7;hb=HEAD#l533
> [2] https://github.com/jaraco/keyring/issues/469

Good to know that I'm not alone, thanks. I'll keep you posted!

-- 
Tanguy

Questions regarding Python packaging

[Tanguy Le Carrour]

Hi Guix!

I have some general questions regarding Python packaging, that are not
directly related to the "poetry build system" I'm currently working on.

I've just learned, by accident (working on `python-keyring` [1]), that
`python setup.py install` was somehow deprecated in favor of tools like
`pep517` or `build`.

So, I've tried packaging `python-keyring` with those two…

`pep517` keeps on trying to download dependencies, which won't work.

`build` crashes with "ZIP does not support timestamps before 1980",
which, I guess is related to the fact that everything in the store is
timestamped to January 1st 1970.

Does anyone have a opinion on Python packaging and how it should be done?
Any idea how I can circumvent the timestamps problem? Is this fish too
big for me?!

Any help or advice welcome! Thanks!

-- 
Tanguy

[1]: https://github.com/jaraco/keyring/issues/469
 Keyring package version is set to 0.0.0, this might be related to
 the fact that, upstream, they build it with `python -m pep517.build .`,
 not with `python setup.py install`… but it could also not be
 related at all! But in order to be sure, I have to try!

Re: Packaging Python projects managed with Poetry

[Tanguy Le Carrour]

Hi Christopher,

Thanks for your answer!


Le 10/22, Christopher Baines a écrit :
> Tanguy Le Carrour  writes:
> > I've been happily working with Poetry to manage my Python projects, but
> > now, for the first time, I would like to package one of those projects
> > for Guix.
> >
> > The Python packages I build do not contain any tests or specs, because
> > to me, they don't belong there. But, I need those tests to make sure
> > that my package works with the versions of the dependencies available on
> > Guix.
> >
> > The problem is that the source code that I fetch from the git repository
> > contains the test, but does not contain a `setup.py` file –because Poetry
> > does not use it!—, and the `python-build-system` fails.
> >
> > I haven't wrap my head around this yet and I'm not sure what would be
> > the proper way to do it? Write a `python-poetry-build-system`? I hope not!
> > Just put the d**n tests in the Python package? This would look like a
> > failure to me! :-(
> >
> > Any thought, help, guidance welcome! Thanks! :-)
> 
> My first thought, is what would it require for the existing
> python-build-system to detect and support building the things you
> describe?

Mmmm… I guess it would require fixing some of the phases, like stopping
it from trying to patch `setup.py`.
The tests would have to be run from the source directory, but the command
could be anything: `pytest`, `nosetest`, `invoke test`, `mamba`…

Then, instead of running `python setup.py`, one should run `poetry build`
and `pip install dist/name-of-the-package`.

So I guess Danny is right and a poetry-build-system would make sense.


> I haven't used Poetry myself, have you got a project that can be used as
> an example?

```
$ git clone https://github.com/tlc28/test-poetry.git
$ cd test-poetry/
$ poetry build
$ pip install dist/test_poetry-0.1.0-py3-none-any.whl
```

> It looks like the python-build-system already has some functionality
> that's dependent on the use-setuptools? argument.

I guess I'll have to dig into it! Thanks for pointing out!

-- 
Tanguy

Re: Packaging Python projects managed with Poetry

[Tanguy Le Carrour]

Hi Danny,

Thank you for your answer!


Le 10/22, Danny Milosavljevic a écrit :
> On Thu, 22 Oct 2020 17:15:20 +0200
> Tanguy Le Carrour  wrote:
> 
> > does not contain a `setup.py` file –because Poetry does not use it!—, and
> >the `python-build-system` fails.
> > I haven't wrap my head around this yet and I'm not sure what would be
> > the proper way to do it?
> 
> >Write a `python-poetry-build-system`? I hope not!
> 
> Why not?
> 
> According to https://github.com/python-poetry/poetry they took inspiration
> from existing build systems like cargo, and they just replaced setup.py by
> pyproject.toml.
> 
> So what you could do is create a poetry-build-system that is just like
> python-build-system (probably even inherits from it) but uses "poetry"
> instead of "python setup.py".
> 
> If the author of a package replaces the build system used in his actual
> project, he has to expect to also have to replace the build-system reference
> in the guix package.  Why is that weird?

Oh, when I said "hope", I didn't mean to say "weird", but "out of my
comfort zone"! But I guess it would be a good way to learn more about
Guix's internals. So, wouldn't be so bad after all!

I'll give it a try.


> Or you could try to add it to the existing python-build-system--but the
> poetry website doesn't sound like it's designed like that (it rather sounds
> like they want to replace all other python build systems).

Actually, they don't "replace" all other systems, they build on them.
Internally, it uses `pip` and `virtualenv`. And there is competition out
there! To be faire, I should also package `hatch` [1] and `pipenv` [2].
But first, I have to make it right with `poetry`.

[1]: https://github.com/ofek/hatch
[2]: https://pipenv.pypa.io/en/latest


> > Just put the d**n tests in the Python package? This would look like a
> > failure to me! :-(
> 
> If the end user doesn't need the tests, the tests shouldn't make it into the
> derivation of your package.  But they are there while the package is building
> the derivation--so just run the tests then.

And… this is where the end of my comprehension of Guix is reached! ^_^'
The only thing I want to make sure is that the tests don't end up on the
the end user's system, the one that runs `guix install 
project-managed-with-poetry`.
But I guess the tests (contained in the source) will remain on the builder's 
system.
At least until they run `guix gc`.

Thanks for your help!

-- 
Tanguy

Packaging Python projects managed with Poetry

[Tanguy Le Carrour]

Hi Guix,

I've been happily working with Poetry to manage my Python projects, but
now, for the first time, I would like to package one of those projects
for Guix.

The Python packages I build do not contain any tests or specs, because
to me, they don't belong there. But, I need those tests to make sure
that my package works with the versions of the dependencies available on
Guix.

The problem is that the source code that I fetch from the git repository
contains the test, but does not contain a `setup.py` file –because Poetry
does not use it!—, and the `python-build-system` fails.

I haven't wrap my head around this yet and I'm not sure what would be
the proper way to do it? Write a `python-poetry-build-system`? I hope not!
Just put the d**n tests in the Python package? This would look like a
failure to me! :-(

Any thought, help, guidance welcome! Thanks! :-)

-- 
Tanguy

Re: [BLOG] Childhurds and GNU/Hurd substitutes

[Tanguy Le Carrour]

Le 10/08, Tanguy Le Carrour a écrit :
>Le 10/08, Jan Nieuwenhuizen a écrit :
>> We have just published a blog post on building your own Guix System with
>> GNU/Hurd and running it in a virtual machine; the road we traveled since
>> beginning of April and what is possible right now.  Read it here:
>> 
>> https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes/
>> […]
>
>Thank you guys for all the time and energy you've put into the Hurd!
>Can't wait to run my own childhurd!

```
$ ssh -p 10022 root@localhost


  This is the GNU Hurd.  Welcome.

root@childhurd ~# uname -a
GNU childhurd 0.9 GNU-Mach 1.8/Hurd-0.9 i686-AT386 GNU
```

It's alive! \o/

Thanks!!

-- 
Tanguy

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

Re: [BLOG] Childhurds and GNU/Hurd substitutes

[Tanguy Le Carrour]

Hi Janneke, Hi Guix!

Le 10/08, Jan Nieuwenhuizen a écrit :
> We have just published a blog post on building your own Guix System with
> GNU/Hurd and running it in a virtual machine; the road we traveled since
> beginning of April and what is possible right now.  Read it here:
> 
> https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes/
> 
> Enjoy!
> Janneke, Ludovic & Mathieu

Thank you guys for all the time and energy you've put into the Hurd!
Can't wait to run my own childhurd!

Cheers!

-- 
Tanguy

Re: [PATCH 0/X] gnu: poetry: Fix broken dependency after dependency's version update.

[Tanguy Le Carrour]

Hi Marius,


Le 07/30, Marius Bakke a écrit :
> Tanguy Le Carrour  writes:
> > Few days ago, I submitted a patch to update `python-tomlkit`. It was pushed
> > to master and, after I upgraded my packages today, I realised that `poetry`
> > (and possibly other python packages) was broken!
> >
> > The "problem" is that Poetry depends on `tomlkit = "^0.5.11"`. This
> > translates to `>=0.5.11,<0.6.0`. And I updated `python-tomlkit` to… 0.6.0!
> >
> > In SemVer [1], minor releases are supposed to "add functionality
> > in a backwards compatible manner", so this "<0.6.0" seems, IMHO, wrong.
> > But that's not the point…
> >
> > [1]: https://semver.org/
> >
> > Now, I have to fix Poetry and I have 2 options:
> > - modify poetry `setup.py` and substitute `>=0.5.11,<0.7.0` to 
> > `>=0.5.11,<0.6.0`;
> > - add a new `python-tomlkit-0.5` and use it in the propagated inputs.
> >
> > Any suggestion on the one I should implement?
> 
> I haven't looked into it, but if the tomlkit API really is compatible,
> the first suggestion sounds good to me.  It would be good to notify
> upstream about the unreasonable "pinning" in that case.

Problem reported upstream: 
<https://github.com/python-poetry/poetry/issues/2752>.


> Otherwise the second suggestion sounds good too.  There is plenty of
> precedence for both solutions in Guix and is really something that needs
> to be decided on a case-by-case basis.

I decided to implement the "quick fix": 
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42619>.
I'll implement the `python-tomlkit-0.5` solution if upstream does not
see this as a problem.

Regards

-- 
Tanguy