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

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

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


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

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

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]

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

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: 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 #<&invoke-error 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

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

[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: [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

Re: `guix build hello' now succeeds on the Hurd

[Tanguy Le Carrour]

Hi Jan,

Le 03/06, Jan Nieuwenhuizen a écrit :
> The situation on the Hurd starts to look pretty good
> 
> janneke@debian:~/src/guix$ ./pre-inst-env guix build hello --no-offload
> /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7-hello-2.10
> janneke@debian:~/src/guix$ 
> /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7-hello-2.10/bin/hello
> Hello, world!
> 
> \o/

Congrats'!

I've been a Hurd enthusiast for quite a long time and I thank you for this work!

Cheers!

-- 
Tanguy

Re: [BLOG] On migration to the Hurd

[Tanguy Le Carrour]

Hi Guix!

Le 04/01, Jan Nieuwenhuizen a écrit :
> We are thrilled to have published a post about migrating to the Hurd:
> 
> https://guix.gnu.org/blog/2020/deprecating-support-for-the-linux-kernel/

So, I guess I was not the only one to figure out that it was a joke! A
good one, but still… a joke!

But anyway, I clicked and read the post! And I couldn't help but feel…
mmm… nostalgic for the future!? Is that even possible?!

The question is now: if not yesterday, when!?

Thanks to all the people who will help make it a reality!

-- 
Tanguy

Re: [BLOG] On migration to the Hurd

[Tanguy Le Carrour]

Le 04/02, Ludovic Courtès a écrit :
> Tanguy Le Carrour  skribis:
> > Le 04/01, Jan Nieuwenhuizen a écrit :
> >> We are thrilled to have published a post about migrating to the Hurd:
> >>
> >> 
> >> https://guix.gnu.org/blog/2020/deprecating-support-for-the-linux-kernel/
> > […]
> > The question is now: if not yesterday, when!?
> >
> > Thanks to all the people who will help make it a reality!
>
> Yup, it can actually become a reality!
> […]
>
>   ./pre-inst-env guix build -f gnu/system/hurd.scm
>
> That gives you a QEMU image containing a cross-built GNU/Hurd system,
> which is pretty cool.
>
> Unfortunately, the bootstrap ext2fs.static server currently hangs early
> on for reasons that haven’t been elucidated yet.  For anyone who wants
> to fiddle with the Hurd, here’s a good hacking opportunity!

I'm not (yet) able to do low-level/system contributions, but I did
contribute some patches upstream to make some programs build and work
on GNU/Hurd. I think I'll keep on doing this kind of things in the
future. Better little than none, right?! :-)

Regards

-- 
Tanguy

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

[Tanguy Le Carrour]

Hi Guix!

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?

Regards

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

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: 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]

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

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

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

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

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 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: 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: 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: 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: 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 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 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: 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: 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 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]

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]

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

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

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

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

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

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

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

Introducting myself

[Tanguy Le Carrour]

Dear Guix community,

I've been playing with GuixSD for few weeks now. I was looking for
a distribution recommended by the FSF, but was not pleased with Trisquel
or Parabola, so I ended up trying GuixSD. And I have to admit that
I haven't been disappointed! The documentation looks good, the installation
procedure is straight forward… so I decided to take the plunge and to install it
as my main OS on my [Vikings D8][1].

[1]: https://store.vikings.net/ryf-certified-hardware/d8ryf

As much as I was disappointed by `pacman` package manager, I really enjoy
using `guix` and I don't miss `sudo pacman -Sy some-mess` **at all**!!

And, icing on the cake, I read recently that you guys were
interested in the Hurd [3], a project I've been following for years
and even contributed a bit to.

[3]: http://lists.gnu.org/archive/html/guix-devel/2019-04/msg7.html

The picture is not all bright however, and things started to get complicated
when I tried to customize the system. I've been using Python as my main language
for more than 10 years and Guile is… something that I still have to get used to!
^_^'

As you might expect, I have a ton of questions! I might even have found
one bug or two that I'll post on the mailing list! And in a while, I hope,
I'll be able to contribute some package definitions. But before I do, I just
wanted to tell you that GuixSD really looks like a great project and that
you guys have done a great job! I hope to be able to play a role in the
future of Guix!

Best regards

-- 
Tanguy

Re: Introducting myself

[Tanguy Le Carrour]

Le 04/13, Pierre Neidhardt a écrit :
> Welcome!

Thanks!


> > The picture is not all bright however, and things started to get complicated
> > when I tried to customize the system. I've been using Python as my main 
> > language
> > for more than 10 years and Guile is… something that I still have to get 
> > used to!
> > ^_^'
> 
> Guile, Scheme and Lisp-languages in general can be quite a shock at
> first indeed.  But once you've tamed the psychological bias, the reward
> is really worth it I believe: Guile is a very powerful and expressive
> language which empowers you in ways that very few languages out there can.

Can't wait to see that! :-)

Oh, btw, thanks for the very good [A packaging tutorial for Guix][1].
The manual is quite nice, but contains a **lot** of information, so the
one-page article is really a must read!

[1] https://www.gnu.org/software/guix/blog/2018/a-packaging-tutorial-for-guix/

Regards

-- 
Tanguy

Re: Introducting myself

[Tanguy Le Carrour]

Le 04/16, Chris Marusich a écrit :
> Welcome!

Thanks!


> It's great to hear about your experience so far with Guix System

I haven't done much so far! But after a week, it's still my main OS at
home, and that's already a good thing!

I'm planning to play a bit with the OS config system, for instance to
set the default shell for my user (I've tried, but failed… but this will
be in a email of its own), and I'll try to package my favourite tools that
are currently missing: ack, fd, fzf, udiskie, poetry, pyenv…

The last 2 might lead me to ask some stupid questions like "can Guix
really replace language specific package managers?" as suggested in
Pierre's article "Guix: A most advanced operating system" [1].

[1]: https://ambrevar.xyz/guix-advance/index.html#org726716f


> (we've recently renamed GuixSD to Guix System).

I take note of this! :-)
Is someone in charge of updating Wikipedia? Some pages [2][3] are still
mentioning the old name.

[2]: https://en.wikipedia.org/wiki/GNU_Guix#Guix_System_Distribution
[3]: https://en.wikipedia.org/wiki/Guix_System_Distribution

Regards

-- 
Tanguy

Re: Introducing myself

[Tanguy Le Carrour]

(I've just realised that there was a typo in the subject… shame on me!
… fixed… unfortunately the Internet never forgets!!)


Le 04/17, Pierre Neidhardt a écrit :
> Tanguy Le Carrour  writes:
> > I'll try to package my favourite tools that
> > are currently missing: ack, fd, fzf, udiskie, poetry, pyenv…
> 
> Suggested alternatives:
> 
> - ack -> the-silver-searcher (ag)

Thanks! I came across this one some time ago. This might be the
perfect time to evaluate/adopt it!


> - fzf -> Emacs with Ivy or Helm

arg… this is the much feared moment when I have to confess that I'm…
a faithful Vim user! ^_^'


> - udiskie -> See discussion here:
>   https://lists.gnu.org/archive/html/help-guix/2018-03/msg00331.html.
>   At some point, we could supersede both udiskie or home-baked scripts
>   with Guix/Shepherd user services.

I'm really happy with my Bspwm [1] setup, even if it comes with absolutely no
removable media management! I used to use `udiskctl`, but I have to
admit that one quickly gets attached to `udiskie`.

[1]: https://github.com/baskerville/bspwm


I guess the real struggle will be replacing dependency management
in my Python projects. But that's a totally different topic!

Regards

-- 
Tanguy

Re: Introducing myself

[Tanguy Le Carrour]

Le 04/18, John Soo a écrit :
> I just realized you said you wanted an fzf replacement. I recommend fzy. It’s 
> not quite as full featured as fzf but it gets the job done. 

Thanks for the link! So many tools out there…
But, actually, what I said was "I want to package fzf for Guix". :-)

Fzf has a nice (colorful) UI and integration in Fish [1] is quite nice.
But I guess fzy will do for the time being!

[1]: https://github.com/jethrokuan/fzf


Regards

-- 
Tanguy

Problem with `direnv` package definition

[Tanguy Le Carrour]

Dear Guix

As I'm still in the process of setting up my environment,
I am not (yet) able to write and submit a patch for package `direnv`,
so I'm sending this report instead…

As mentioned on the `direnv` homepage, "direnv is compiled into
a single static executable" [1]. As I understand it, this means that
Go is required to build it, but not to run it.

[1]: https://github.com/direnv/direnv

However, in the package definition [2], 3 Go packages are listed as
"inputs" whereas they should be listed as "native-inputs". Is this
correct?

[2]: gnu/packages/shellutils.scm

As I said, I'm still learning. But I've tried, and here is what I've
done so far…

I've `git clone`d the repo, ran the `guix env… guix` then `bootstrap`
`configure` and `make` and everything seems to be fine.
Just to make sure, I did `./pre-… guix env… direnv` then
ran `./pre-… guix build direnv` and everything went well.
Then I moved the direnv dependencies from inputs to native-inputs and
build it again… and it unsurprisingly failed! The error message [3]
does not say much… at least to me! ^_^'

[3]: output of `./pre-inst-env guix build --keep-failed direnv`
  direnv-2.15.2/version.txt
  direnv-2.15.2/xdg.go
  phase `unpack' succeeded after 0.0 seconds
  starting phase `bootstrap'
  no 'configure.ac' or anything like that, doing nothing
  phase `bootstrap' succeeded after 0.0 seconds
  starting phase `patch-usr-bin-file'
  phase `patch-usr-bin-file' succeeded after 0.0 seconds
  starting phase `patch-source-shebangs'
  phase `patch-source-shebangs' succeeded after 0.0 seconds
  starting phase `patch-generated-file-shebangs'
  phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
  starting phase `build'
  make: *** No targets specified and no makefile found.  Stop.
  Backtrace:
  4 (primitive-load
  "/gnu/store/7rrxdai48si293dihzf55zn3svn…")
  In ice-9/eval.scm:
 191:35  3 (_ #f)
  In srfi/srfi-1.scm:
 863:16  2 (every1 #
  …)
  In
   /gnu/store/i5ip2vy29fqppjb4pq5isq36gqd42d89-module-import/guix/build/gn
   u-build-system.scm:
   799:28  1 (_ _)
  In
   
/gnu/store/i5ip2vy29fqppjb4pq5isq36gqd42d89-module-import/guix/build/utils.scm:
   616:6  0 (invoke _ . _)
   
/gnu/store/i5ip2vy29fqppjb4pq5isq36gqd42d89-module-import/guix/build/utils.scm:616:6:
 In procedure invoke:
  Throw to key `srfi-34' with args `(#)'.


I've tried to read the rest of the package definition, but as I'm still
attending Guile 1-0-1, that didn't help much!

I would very much appreciate it if someone could point out my mistake!

Regards,

-- 
Tanguy

Re: Problem with `direnv` package definition

[Tanguy Le Carrour]

Le 04/20, Christopher Baines a écrit :
> Tanguy Le Carrour  writes:
> > However, in the package definition [2], 3 Go packages are listed as
> > "inputs" whereas they should be listed as "native-inputs". Is this
> > correct?
> That sounds right to me, although there have been issues with binaries
> generated with Go […]
> There's also an important aspect of cross-compilation to these fields,
> which you can read about here:
> 
>   https://www.gnu.org/software/guix/manual/en/html_node/package-Reference.html

Thanks for the link.

I do realize that, so close to the release of Guix System 1.0,
this can sound trivial, but I find it a little annoying to have
`guix size direnv` reporting 594 MiB when the actual binary size is
2.9M. :-(


> > As I said, I'm still learning. But I've tried, and here is what I've
> > done so far […]
> 
> I tried changing the inputs to native-inputs, and the package built for
> me. Could you share the exact changes you made?

I haven't done much:

--- a/gnu/packages/shellutils.scm
+++ b/gnu/packages/shellutils.scm
@@ -129,12 +129,11 @@ are already there.")
  ;; Help the build scripts find the Go language dependencies.
  (add-before 'unpack 'setup-go-environment
(assoc-ref go:%standard-phases 'setup-go-environment)
-(inputs
- `(("go" ,go)
-   ("go-github-com-burntsushi-toml" ,go-github-com-burntsushi-toml)
-   ("go-github-com-direnv-go-dotenv" ,go-github-com-direnv-go-dotenv)))
 (native-inputs
-  `(("which" ,which)))
+  `(("go" ,go)
+("go-github-com-burntsushi-toml" ,go-github-com-burntsushi-toml)
+("go-github-com-direnv-go-dotenv" ,go-github-com-direnv-go-dotenv)
+("which" ,which)))
 (home-page "https://direnv.net/";)
 (synopsis "Environment switcher for the shell")
 (description


Thanks again for your time!


-- 
Tanguy

Re: Problem with `direnv` package definition

[Tanguy Le Carrour]

Le 04/21, Christopher Baines a écrit :
> Tanguy Le Carrour  writes:
> > Le 04/20, Christopher Baines a écrit :
> >> Tanguy Le Carrour  writes:
> >> > However, in the package definition [2], 3 Go packages are listed as
> >> > "inputs" whereas they should be listed as "native-inputs". Is this
> >> > correct?
> >> That sounds right to me, although there have been issues with binaries
> >> generated with Go […]
> […]
> So, in contrast to some other package management systems, the runtime
> dependencies, or references of the output(s) in the case of Guix are not
> explicitly set in the package definition.
> 
> This is still something I have a little difficulty understanding, but
> the inputs/native-inputs distinction is more about architecture than
> runtime references.

Ouch?! If you have difficulty understanding it, imagine for me! ^_^'


> I've just pushed a commit that pulls in the relevant phase, and makes
> the inputs, native-inputs [1]. With that change, the size of the package
> does drop [2].

Thank you so much for that!


> That's not to say that making the inputs, native-inputs in this case is
> wrong, quite the opposite. […] Currently the direnv package is using the
> gnu-build-system, as it's one of the older go packages in Guix, however
> it does now pull in some phases from the go-build-system.
> […]
> Anyway, while the size of direnv should now be improved, there's still
> more improvements to be made to the direnv package if you're interested!
> I think it would be better to switch to using the go build system, and
> the package in Guix is quite a few versions behind.

So this might be something I could be investigating in a near future!
But I guess I'll have to read some Go package definitions first…
Which won't be a waste of time, for `fzf` is also written in Go!


Regards


-- 
Tanguy

Re: User shell: state or config?

[Tanguy Le Carrour]

Hello Guix!


Le 04/25, Ludovic Courtès a écrit :
> We recently discussed handling of the ‘shell’ field of ‘user-account’:
> 
>   https://lists.gnu.org/archive/html/help-guix/2019-04/msg00171.html

Thanks for taking the time to think about it! :-)


> Considering user shells as state seemed like a good idea
> […]
> All in all, I’m in favor of switching back to the previous behavior

I don't yet understand the consequences of this choice, so I don't have an
opinion on this. For instance, I don't yet understand why, on my system, two
shells installed "system wide" with `guix system reconfigure`
(namely bash and fish) don't have the same "type" of path [1]?
I was expecting fish to be in the `/run/current-system/profile/bin/`
folder. And what about the second bash?!

[1]: from `/etc/shells`
 /run/current-system/profile/bin/bash
 /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash
 /gnu/store/9r5z8k0p0ilmg8qfyc82x11ybacawfqa-fish-3.0.2/bin/fish

Best regards


-- 
Tanguy

Re: Guix shepherd user services

[Tanguy Le Carrour]

Hello Guix!

I've just read this thread [1] on the archive and I think it would be a
great feature! Any update on the topic?!

[1]: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00132.html

I would love to have some services started when I log in (tor,
transmission-daemon, mpd, gpg-agent… you name them!) without having to
rely on the root user and system configuration.

One other nice thing would be to have something like systemd timers [2]
to replace cron jobs. I use them to run things like mbsync and vdirsyncer.

[2]: https://wiki.archlinux.org/index.php/Systemd/Timers

I'm not sure that I'm able to write any (good) Guile code, but I can read
some and discuss things, if that helps!

Regards


-- 
Tanguy

Re: Guix shepherd user services

[Tanguy Le Carrour]

Hi Tobias

Thanks for your answers!


Le 04/29, Tobias Geerinckx-Rice a écrit :
> > I would love to have some services started when I log in […]
> Note that this is already possible if you want it:

Reading the Shepherd documentation, I was expecting that something like
this was possible, but, correct me if I'm wrong, it's not really documented,
is it?


>  ~ λ cat /home/nckx/.config/shepherd/init.scm  (load "services.scm")
>  (register-services emacs gpg-agent ibus-daemon jackd)
>  (action 'shepherd 'daemonize) ; send shepherd into background
>  (for-each start (list emacs)) ; services to start automatically
> 
>  ~ λ cat /home/nckx/.config/shepherd/services.scm  (define emacs
>(make 
>  #:provides '(emacs)
>  #:requires '()
>  #:start (make-system-constructor "emacs --daemon")
>  #:stop (make-system-destructor "emacsclient --eval
> \"(kill-emacs)\"")))
>  ;; ...much more snipped...
> 
>  ~ λ grep shepherd /home/nckx/.xsession  shepherd # user service manager

Cool! :-)
Did you write the "much more snipped" by yourself? If yes, is it
available somewhere? Else, is it documented somewhere? Did you
copy/paste it from another Guix file?

Stupid questions: why aren't you using service types? Whose responsibility
should it be to provide the service(-type) definitions (`service.scm`)?
The user?  Guix? Both? To me, it would make more sense to
have the service(-type) definitions come with the packages and
have them instantiated/configured by the user, like in the config file
used by `guix system reconfigure`? This would be in the file used
by `guix user`, wouldn't it?
If things were not clear to me, now they are all messed up in my head! ^_^'


> The discussion is about how to add it (and user stuff in general) to Guix,
> which is a big wriggly bag of tasty worms.

What do you mean by "how to add it"? Is it about having a `guix user`
command?
If I can achieve something without it, it would already be great.

Thanks again for your time!

Regards

-- 
Tanguy

Re: GNU Guix 1.0.0 released

[Tanguy Le Carrour]

Congratulations Guix!

I haven't been around for long, but I've really liked what I've seen so
far!

Cheers!

-- 
Tanguy

Re: Guix shepherd user services

[Tanguy Le Carrour]

Hello!


Le 05/01, Tanguy Le Carrour a écrit :
> Le 04/29, Tobias Geerinckx-Rice a écrit :
> >  ~ λ cat /home/nckx/.config/shepherd/init.scm  (load "services.scm")
> >  (register-services emacs gpg-agent ibus-daemon jackd)
> >  (action 'shepherd 'daemonize) ; send shepherd into background
> >  (for-each start (list emacs)) ; services to start automatically
> > 
> >  ~ λ cat /home/nckx/.config/shepherd/services.scm  (define emacs
> >(make 
> >  #:provides '(emacs)
> >  #:requires '()
> >  #:start (make-system-constructor "emacs --daemon")
> >  #:stop (make-system-destructor "emacsclient --eval
> > \"(kill-emacs)\"")))
> >  ;; ...much more snipped...
> > 
> >  ~ λ grep shepherd /home/nckx/.xsession  shepherd   # user service manager
> 
> Cool! :-)
> Did you write the "much more snipped" by yourself? If yes, is it
> available somewhere? Else, is it documented somewhere? Did you
> copy/paste it from another Guix file?

I've been playing with shepherd and service configurations and it's
actually easier than I thought it would be, at least for "simple"
services. Thanks for showing me the way! :-)

I love it so much that I started/stopped the emacs service (defined with
the snippet above) a few times. It works as expected, except for
the `defunct` processes that hang around. Each time I run `herd stop emacs`,
I get a new one, as if shepherd could not forget about the dead process.
This doesn't prevent me from re-starting the process and using the service,
but it looks… messy!

Am I doing something wrong?!

-- 
Tanguy

Re: Guix shepherd user services

[Tanguy Le Carrour]

Hi Tobias, hi Guix!


Le 05/04, Tobias Geerinckx-Rice a écrit :
> My apologies for not replying sooner.  I fail at managing the scarce free
> time I have these days.

I'm not much better, so no need to apologise! ;-)


> Tanguy Le Carrour wrote:
> No, you're right, I'd simply never checked this before.  Stopping emacs
> gives me… Zombie emacs.  And mu.

Just to make sure, I tried and checked with the "system wide" shepherd.
Everything seem to be OK, no Zombies lurking in the corner. But… I
noticed that `wpa-supplicant` was running and, as I don't need it on my
desktop, I stopped it:

~# herd stop wpa-supplicant
Service ntpd has been stopped.
Service avahi-daemon has been stopped.
Service networking has been stopped.
Service wpa-supplicant has been stopped.

?! I was not expecting `networking` to stop too.

~# herd status
…
Stopped:
 - avahi-daemon
 - networking
 - ntpd
 - term-auto
 - user-homes
 - wpa-supplicant

And event if `network` is listed as "stopped", I still have access
to the network!? This is not clear to me!? Does `networking` mean
something different?!

And if I start `network` again, `wpa-supplicant` comes up with it, but
not `avahi-daemon` and `ntpd`.

# herd start networking
Service wpa-supplicant has been started.
Service networking has been started.

Not quite the behaviour I was expecting! But maybe I didn't understand
correctly how things were supposed to work! :-(

I'll dig a bit in the doc, but any input is welcomed!


-- 
Tanguy

Packaging Grisbi

[Tanguy Le Carrour]

Hello Guix!

This is my first packaging attempt, please be indulgent…

I decided to start small and be a little chauvinistic by packaging
Grisbi "an application written by French developers"! :-)

```
(define-module (gnu packages grisbi)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system glib-or-gtk)
  #:use-module (gnu packages gtk)
  #:use-module (gnu packages glib)
  #:use-module (gnu packages gnome)
  #:use-module (gnu packages pkg-config)
  #:use-module (guix licenses))

(define-public grisbi
  (package
(name "grisbi")
(version "1.2.1")
(source (origin
  (method url-fetch)
  (uri (string-append
 "mirror://sourceforge/projects/grisbi/files/"
 "grisbi stable/1.2.x/" version "/grisbi-" version
 ".tar.bz2/download"))
  (sha256
   (base32
"0j6jq0h4kkhyqhdprhaw4zk6sn89s4a9h0m8i8hh5sc7fbi88nyq"
(build-system glib-or-gtk-build-system)
(arguments
 `(#:configure-flags (list "--without-ofx" "--without-goffice")))
(inputs
  `(("gtk+" ,gtk+)
("libgsf" ,libgsf)))
(native-inputs
  `(("glib" ,glib "bin") ; glib-compile-schemas
("pkg-config" ,pkg-config)
("intltool" ,intltool)))
(synopsis "Personnal accounting application")
(description "Grisbi is an application written by French developers,
so it perfectly respects French accounting rules.  Grisbi can manage
multiple accounts, currencies and users.  It manages third party,
expenditure and receipt categories, budgetary lines, financial years,
budget estimates, bankcard management and other information that make Grisbi
adapted for associations.")
(home-page "http://grisbi.org";)
(license gpl2+)))
```

So far, it builds, it lints, it's installable… and it works!
It still has a small amnesia problem: each time I start it, it's acting like
it's the first time. It seems to be a dconf issue, for I get the following
error message:

```
failed to commit changes to dconf:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown:
The name ca.desrt.dconf was not provided by any .service files
```

Installing dconf does not solve the problem, though.

I also don't know where to put it! In its own `grisbi.scm` file? Or
alongside gnucash in a new `finance.scm` file?

Any comment and piece of advice is welcome!

-- 
Tanguy

Re: Packaging Grisbi

[Tanguy Le Carrour]

Hi Timothy,


Le 05/12, Timothy Sample a écrit :
> Tanguy Le Carrour  writes:
> > I get the following error message:
> >
> > ```
> > failed to commit changes to dconf:
> > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown:
> > The name ca.desrt.dconf was not provided by any .service files
> > ```
> 
> Drat!
> 
> > Installing dconf does not solve the problem, though.
> 
> If you are using GDM, this might be due to the way it (used to) start
> D-Bus.  See commit dcb3a0fe0a086b4762a721e9b1da64826d5160d0.  If you
> have not ran “guix pull” in the last four days, doing so might make this
> problem disappear.

My bad! I'll update my system and try again!


> > I also don't know where to put it! In its own `grisbi.scm` file? Or
> > alongside gnucash in a new `finance.scm` file?
> 
> We already have a “finance.scm”, which seems appropriate to me.

Oups, I did not notice it! I was focused on GnuCash and only saw
`gnucash.scm`. Shouldn't it also be in `finance.scm`?! I guess,
there's a good reason for it not to be, though!


> Hope that helps!

Definitively! Thanks!


-- 
Tanguy

Building vdirsyncer.drv fails randomly (problem with Hypothesis test framework)

[Tanguy Le Carrour]

Dear Guix,

When I run `guix package -i vdirsyncer` or `guix package -u` (if vdirsyncer is
in my profile), it randomly fails. This has happened to me several times 
already.

Here is a part of the log:

= test session starts ==
platform linux -- Python 3.7.0, pytest-3.8.0, py-1.5.4, pluggy-0.7.1
hypothesis profile 'default' -> 
database=DirectoryBasedExampleDatabase('/tmp/guix-build-vdirsyncer-0.16.7.drv-0/vdirs
yncer-0.16.7/.hypothesis/examples')
rootdir: /tmp/guix-build-vdirsyncer-0.16.7.drv-0/vdirsyncer-0.16.7, inifile: 
setup.cfg
plugins: hypothesis-3.70.3, localserver-0.5.0, subtesthack-0.1.1
collected 486 items

tests/storage/test_filesystem.py ... [  8%]
...sss..ss...[ 13%]
tests/storage/test_http.py . [ 14%]
tests/storage/test_http_with_singlefile.py . [ 20%]
.ssss.ss [ 25%]
tests/storage/test_memory.py ..s [ 34%]
sssss...ss   [ 37%]
tests/storage/test_singlefile.py ... [ 45%]
.ss.ss   [ 49%]
tests/storage/dav/test_caldav.py sss [ 57%]
sss  [ 60%]
tests/storage/dav/test_carddav.py ss [ 65%]
tests/storage/dav/test_main.py . [ 72%]
tests/system/cli/test_config.py .[ 74%]
tests/system/cli/test_discover.py .  [ 75%]
tests/system/cli/test_fetchparams.py .   [ 75%]
tests/system/cli/test_repair.py .[ 76%]
tests/system/cli/test_sync.py    [ 80%]
tests/system/cli/test_utils.py ..[ 81%]
tests/system/utils/test_main.py .[ 82%]
tests/unit/test_exceptions.py .  [ 82%]
tests/unit/test_metasync.py F[ 84%]
tests/unit/test_repair.py .. [ 86%]
tests/unit/cli/test_config.py .  [ 86%]
tests/unit/cli/test_discover.py ..   [ 87%]
tests/unit/cli/test_fetchparams.py . [ 89%]
tests/unit/sync/test_status.py . [ 89%]
tests/unit/sync/test_sync.py ... [ 96%]
tests/unit/utils/test_vobject.py ..  [100%]

=== FAILURES ===
_ test_fuzzing _
tests/unit/test_metasync.py:129: in test_fuzzing
a=metadata, b=metadata,
E   hypothesis.errors.FailedHealthCheck: Data generation is extremely slow:
Only produced 9 valid examples in 1.08 seconds (4 invalid ones and
0 exceeded maximum size). Try decreasing size of the data you're generating
(with e.g.max_size or max_leaves parameters).
E   See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for
more information about this. If you want to disable just this health check,
add HealthCheck.too_slow to the suppress_health_check settings for this 
test.


I guess a solution would be to do as they say and deactivate part of the
tests!

What do you guys think?!

-- 
Tanguy

Re: Packaging Grisbi

[Tanguy Le Carrour]

Dear Timothy, dear Guix

Sorry it took me soo long to answer!


Le 05/13, Tanguy Le Carrour a écrit :
> Le 05/12, Timothy Sample a écrit :
> > Tanguy Le Carrour  writes:
> > > I get the following error message:
> > >
> > > ```
> > > failed to commit changes to dconf:
> > > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown:
> > > The name ca.desrt.dconf was not provided by any .service files
> > > ```
> > 
> > Drat!
> > 
> > > Installing dconf does not solve the problem, though.
> > 
> > If you are using GDM, this might be due to the way it (used to) start
> > D-Bus.  See commit dcb3a0fe0a086b4762a721e9b1da64826d5160d0.  If you
> > have not ran “guix pull” in the last four days, doing so might make this
> > problem disappear.
> 
> My bad! I'll update my system and try again!

I've updated my system (a couple of times) since then and I still have the
same problem! Any dconf specialist around?!

Here is my "final" patch…

---
 gnu/packages/finance.scm | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/gnu/packages/finance.scm b/gnu/packages/finance.scm
index e1a1e8ab6f..ae2ebea46e 100644
--- a/gnu/packages/finance.scm
+++ b/gnu/packages/finance.scm
@@ -35,6 +35,7 @@
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system python)
+  #:use-module (guix build-system glib-or-gtk)
   #:use-module (gnu packages)
   #:use-module (gnu packages base)
   #:use-module (gnu packages boost)
@@ -45,9 +46,12 @@
   #:use-module (gnu packages dns)
   #:use-module (gnu packages emacs)
   #:use-module (gnu packages dbm)
+  #:use-module (gnu packages glib)
+  #:use-module (gnu packages gnome)
   #:use-module (gnu packages gnupg)
   #:use-module (gnu packages graphviz)
   #:use-module (gnu packages groff)
+  #:use-module (gnu packages gtk)
   #:use-module (gnu packages libedit)
   #:use-module (gnu packages libevent)
   #:use-module (gnu packages libunwind)
@@ -1028,3 +1032,37 @@ Its features are:
 @item get account amount.
 @end itemize")
 (license license:agpl3+)))
+
+(define-public grisbi
+  (package
+(name "grisbi")
+(version "1.2.2")
+(source
+  (origin
+(method url-fetch)
+(uri (string-append
+   "mirror://sourceforge/grisbi/grisbi%20stable/1.2.x"
+   "/" version "/grisbi-" version ".tar.bz2"))
+(sha256
+  (base32
+"1piiyyxjsjbw9gcqydvknzxmmfgh8kdqal12ywrxyxih2afwnvbw"
+(build-system glib-or-gtk-build-system)
+(arguments
+ `(#:configure-flags (list "--without-ofx")))
+(inputs
+  `(("gtk+" ,gtk+)
+("libgsf" ,libgsf)))
+(native-inputs
+  `(("glib" ,glib "bin") ; glib-compile-schemas
+("pkg-config" ,pkg-config)
+("intltool" ,intltool)))
+(synopsis "Personnal accounting application")
+(description "Grisbi is an application written by French developers,
+so it perfectly respects French accounting rules.  Grisbi can manage
+multiple accounts, currencies and users.  It manages third party,
+expenditure and receipt categories, budgetary lines, financial years,
+budget estimates, bankcard management and other information that make Grisbi
+adapted for associations.")
+(home-page "http://grisbi.org";)
+(license license:gpl2+)))
-- 
2.21.0


-- 
Tanguy

Re: Packaging Grisbi

[Tanguy Le Carrour]

Hi Timothy,


Le 05/30, Timothy Sample a écrit :
> […]
> >> > Tanguy Le Carrour  writes:
> >> > > I get the following error message:
> >> > >
> >> > > ```
> >> > > failed to commit changes to dconf:
> >> > > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown:
> >> > > The name ca.desrt.dconf was not provided by any .service files
> >> > > ```
> […]
> I applied your patch below, and everything works great for me.  It seems
> this is because I am running GNOME, and GNOME puts the dconf service
> file in the system profile.
> 
> What desktop are you running?  How is D-Bus started?

I'm running bspwm [1]. D-Bus seems to be running [2], but I have not clue
how it's been started!? I just select the bspwm session from the login
manager.

[1]: snippet of my OS config
```
;; …
;; This is where we specify system-wide packages.
  (packages (cons* nss-certs ;for HTTPS access
   bspwm sxhkd   ;for desktop env
   fish neovim openssh wget recutils
   %base-packages))
;; …
```

[2]: output of `env | ag DBUS`
```
DBUS_FATAL_WARNINGS=0
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-783FOvFmx6,guid=63be5a9abc13dee04e494f3e5cf3fb36
GDM_DBUS_DAEMON=/gnu/store/bp4zn8kx5p09ddn6dm7lsdlf4l0cj8g3-gdm-dbus-wrapper
```

Any idea?!

-- 
Tanguy

Re: Packaging Grisbi

[Tanguy Le Carrour]

Hi Tim

Sorry it took me so long just to type 1 `cat` and 2 `ls`! ^_^'
…

Le 06/02, Timothy Sample a écrit :
> Tanguy Le Carrour  writes:
> > […]
> > Le 05/30, Timothy Sample a écrit :
> >> […]
> >> >> > Tanguy Le Carrour  writes:
> >> >> > > I get the following error message:
> >> >> > >
> >> >> > > ```
> >> >> > > failed to commit changes to dconf:
> >> >> > > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown:
> >> >> > > The name ca.desrt.dconf was not provided by any .service files
> >> >> > > ```
> >> […]
> >> I applied your patch below, and everything works great for me.  It seems
> >> this is because I am running GNOME, and GNOME puts the dconf service
> >> file in the system profile.
> >> 
> >> What desktop are you running?  How is D-Bus started?
> >> […]
> What are the contents of the “$GDM_DBUS_DAEMON” file above?  It should
> set it up so that D-Bus looks at the system profile and your user
> profile.  Please check that the service file is available either in
> 
>   /run/current-system/profile/share/dbus-1/services/
> or
>   $HOME/.guix-profile/share/dbus-1/services/
> 
> There should be a symlink called “ca.desrt.dconf.service” in one of
> those directories.

… But I eventually did!

```
❯ cat /gnu/store/bp4zn8kx5p09ddn6dm7lsdlf4l0cj8g3-gdm-dbus-wrapper
#!/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile 
--no-auto-compile
!#
(begin (use-modules (srfi srfi-26)) (define system-profile 
"/run/current-system/profile") (define user-profile (and=> (getpw (getuid)) 
(lambda (pw) (string-append (passwd:dir pw) "/.guix-profile" (define 
profiles (if user-profile (list user-profile system-profile) (list 
system-profile))) (setenv "XDG_CONFIG_DIRS" (string-join (map (cut 
string-append <> "/etc/xdg") profiles) ":")) (setenv "XDG_DATA_DIRS" 
(string-join (map (cut string-append <> "/share") profiles) ":")) (apply execl 
(string-append "/gnu/store/s62xzisv3mnl510m5wbf91jzzd392l6f-dbus-1.12.12" 
"/bin/dbus-daemon") (program-arguments)))⏎  
  

❯ ls /run/current-system/profile/share/dbus-1/services/
org.a11y.Bus.service@

❯ ls $HOME/.guix-profile/share/dbus-1/services/
org.gnome.evince.Daemon.service@  org.knopwob.dunst.service@
```

So, apparently the `ca.desrt.dconf.service` is missing, which would
explain the problem. The thing is, I have no clue how it's supposed to
be started? Is it something I missed in the doc? Or is there something
else I need to do because I'm using bspwm?

I checked my guix system config, and the service section looks rather basic:

```
(services (append (list (set-xorg-configuration
   (xorg-configuration
(keyboard-layout keyboard-layout
 %desktop-services))
```

Any help welcome!

-- 
Tanguy

Re: Packaging Grisbi

[Tanguy Le Carrour]

Dear Timothy,

Le 06/12, Timothy Sample a écrit :
> It looks like all you need to do is install “dconf”.  It should work if
> you install it into your user profile either using a manifest file or
> with “guix install dconf”.  (I seem to recall you tried this before, but
> looking at the results above, and given my earlier success with Grisbi,
> and think it’s worth another shot.)

Once again, you were right! I've added `dconf` and everything works
perfectly now! I checked how `dconf` was used in other packages and
added it as `propagated-inputs`. This being done, I submitted the patch
to guix-patc...@gnu.org.

Thanks again for your precious help and your time!

-- 
Tanguy

Re: We need your feedback of the documentation videos!

[Tanguy Le Carrour]

Hi Laura, Hi Guix!

Le 07/16, Laura Lazzati a écrit :
> If you are interested, please, watch them
> https://archive.org/details/guix-videos and give feedback here :)
> We will appreciate it very much, and the idea is to collect the feedback up
> to next Tuesday (July 23rd)

Great videos! Excellent work! I should have watched them (especially
the ones about packaging) before I submitted my first patch! ^_^'

Cheers!

-- 
Tanguy

Cannot install `python-pastel`

[Tanguy Le Carrour]

Hi Guix

Installation of the package `python-pastel` fails on my system.

```
$ guix pull
…

$ guix describe
Generation 4Oct 03 2019 08:01:59(current)
  guix 2b2f7e5
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 2b2f7e5d8cd154c8bbf8d531d2edd6801956d36d

$ guix package -i python-pastel
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
building /gnu/store/87360qr1s7pfa2pgpb2z7zpvd9s09x4c-python-pastel-0.1.0.drv...
\ 'check' phasebuilder for 
`/gnu/store/87360qr1s7pfa2pgpb2z7zpvd9s09x4c-python-pastel-0.1.0.drv' failed 
with exit code 1
build of /gnu/store/87360qr1s7pfa2pgpb2z7zpvd9s09x4c-python-pastel-0.1.0.drv 
failed
View build log at 
'/var/log/guix/drvs/87/360qr1s7pfa2pgpb2z7zpvd9s09x4c-python-pastel-0.1.0.drv.bz2'.
guix package: error: build of 
`/gnu/store/87360qr1s7pfa2pgpb2z7zpvd9s09x4c-python-pastel-0.1.0.drv' failed

$ bzcat 
/var/log/guix/drvs/87/360qr1s7pfa2pgpb2z7zpvd9s09x4c-python-pastel-0.1.0.drv.bz2
…
starting phase `build'
…
TypeError: calling  returned 
, not a test
```
(see attachment)

I guess it must be a problem on my side as all the packages go through
CI!?

-- 
Tanguy


360qr1s7pfa2pgpb2z7zpvd9s09x4c-python-pastel-0.1.0.drv.bz2
Description: Binary data

[PATCH 0/4] gnu: Add Cookiecutter and its inputs

[Tanguy Le Carrour]

Dear Guix

As I'm still a newbie, I'm sending those patches for review before
submitting them to guix-patc...@gnu.org.

Thanks for reviewing!

-- 
Tanguy

[PATCH 2/4] gnu: Add Cookiecutter and its inputs

[Tanguy Le Carrour]

-- 
Tanguy
>From b1a708198ea93c5a6d591d6b4ac864819de432e3 Mon Sep 17 00:00:00 2001
From: "tan...@bioneland.org" 
Date: Thu, 3 Oct 2019 09:13:59 +0200
Subject: [PATCH 2/4] gnu: Add Cookiecutter and its inputs

---
 gnu/packages/python-xyz.scm | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index e041adfdc4..eb326aae6f 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -1552,6 +1552,25 @@ existing ones.")
;; Tests don't work with python2.
#:tests? #f)
 
+(define-public python-poyo
+  (package
+(name "python-poyo")
+(version "0.5.0")
+(source
+  (origin
+(method url-fetch)
+(uri (pypi-uri "poyo" version))
+(sha256
+  (base32
+"1pflivs6j22frz0v3dqxnvc8yb8fb52g11lqr88z0i8cg2m5csg2"
+(build-system python-build-system)
+(home-page "https://github.com/hackebrot/poyo";)
+(synopsis
+  "Lightweight YAML Parser for Python")
+(description
+  "A lightweight YAML Parser for Python.")
+(license license:expat)))
+
 (define-public scons
   (package
 (name "scons")
-- 
2.23.0

[PATCH 3/4] gnu: Add Cookiecutter and its inputs

[Tanguy Le Carrour]

-- 
Tanguy
>From 3d244fab04f6de3dcdd888ce1e1877f8f6b2b0f0 Mon Sep 17 00:00:00 2001
From: "tan...@bioneland.org" 
Date: Thu, 3 Oct 2019 09:17:05 +0200
Subject: [PATCH 3/4] gnu: Add Cookiecutter and its inputs

---
 gnu/packages/python-xyz.scm | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index eb326aae6f..df64e780d8 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -9108,6 +9108,28 @@ server with very acceptable performance.")
 (define-public python2-waitress
   (package-with-python2 python-waitress))
 
+(define-public python-whichcraft
+  (package
+(name "python-whichcraft")
+(version "0.6.1")
+(source
+  (origin
+(method url-fetch)
+(uri (pypi-uri "whichcraft" version))
+(sha256
+  (base32
+"11yfkzyplizdgndy34vyd5qlmr1n5mxis3a3svxmx8fnccdvknxc"
+(build-system python-build-system)
+(native-inputs
+  `(("python-pytest" ,python-pytest)))
+(home-page
+  "https://github.com/pydanny/whichcraft";)
+(synopsis
+  "This package provides cross-platform cross-python shutil.which 
functionality")
+(description
+  "This package provides cross-platform cross-python shutil.which 
functionality.")
+(license license:bsd-3)))
+
 (define-public python-pyquery
   (package
 (name "python-pyquery")
-- 
2.23.0

[PATCH 1/4] gnu: Add Cookiecutter and its inputs

[Tanguy Le Carrour]

-- 
Tanguy
>From dc07c609430e9e63dd4d87b71d84545db87d9f8c Mon Sep 17 00:00:00 2001
From: "tan...@bioneland.org" 
Date: Thu, 3 Oct 2019 09:05:26 +0200
Subject: [PATCH 1/4] gnu: Add Cookiecutter and its inputs

---
 gnu/packages/python-xyz.scm | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index 413d68c258..e041adfdc4 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -66,6 +66,7 @@
 ;;; Copyright © 2019 Jacob MacDonald 
 ;;; Copyright © 2019 Giacomo Leidi 
 ;;; Copyright © 2019 Wiktor Żelazny 
+;;; Copyright © 2019 Tanguy Le Carrour 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -2475,6 +2476,28 @@ written in pure Python.")
 (define-public python2-jinja2
   (package-with-python2 python-jinja2))
 
+(define-public python-jinja2-time
+  (package
+(name "python-jinja2-time")
+(version "0.2.0")
+(source
+  (origin
+(method url-fetch)
+(uri (pypi-uri "jinja2-time" version))
+(sha256
+  (base32
+"0h0dr7cfpjnjj8bgl2vk9063a53649pn37wnlkd8hxjy656slkni"
+(build-system python-build-system)
+(propagated-inputs
+  `(("python-arrow" ,python-arrow)
+("python-jinja2" ,python-jinja2)))
+(home-page
+  "https://github.com/hackebrot/jinja2-time";)
+(synopsis "Jinja2 Extension for Dates and Times")
+(description
+  "Jinja2 Extension for Dates and Times")
+(license license:expat)))
+
 (define-public python-pystache
   (package
 (name "python-pystache")
-- 
2.23.0

[PATCH 4/4] gnu: Add Cookiecutter and its inputs

[Tanguy Le Carrour]

-- 
Tanguy
>From 2d0e7649de9e34fd3dd73f78d00f6b9dde9acc4a Mon Sep 17 00:00:00 2001
From: "tan...@bioneland.org" 
Date: Thu, 3 Oct 2019 09:23:24 +0200
Subject: [PATCH 4/4] gnu: Add Cookiecutter and its inputs

---
 gnu/packages/python-xyz.scm | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index df64e780d8..d2bd1a661d 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -9130,6 +9130,41 @@ server with very acceptable performance.")
   "This package provides cross-platform cross-python shutil.which 
functionality.")
 (license license:bsd-3)))
 
+(define-public python-cookiecutter
+  (package
+(name "python-cookiecutter")
+(version "1.6.0")
+(source
+  (origin
+(method url-fetch)
+(uri (pypi-uri "cookiecutter" version))
+(sha256
+  (base32
+"0glsvaz8igi2wy1hsnhm9fkn6560vdvdixzvkq6dn20z3hpaa5hk"
+(build-system python-build-system)
+(native-inputs
+  `(("python-freezegun" ,python-freezegun)
+("python-pytest" ,python-pytest)
+("python-pytest-catchlog" ,python-pytest-catchlog)
+("python-pytest-cov" ,python-pytest-cov)
+("python-pytest-mock" ,python-pytest-mock)))
+(propagated-inputs
+  `(("python-binaryornot" ,python-binaryornot)
+("python-click" ,python-click)
+("python-future" ,python-future)
+("python-jinja2" ,python-jinja2)
+("python-jinja2-time" ,python-jinja2-time)
+("python-poyo" ,python-poyo)
+("python-requests" ,python-requests)
+("python-whichcraft" ,python-whichcraft)))
+(home-page
+  "https://github.com/audreyr/cookiecutter";)
+(synopsis
+  "Command-line utility that creates projects from project templates")
+(description "A command-line utility that creates projects from project 
templates,
+e.g. creating a Python package project from a Python package project 
template.")
+(license license:bsd-3)))
+
 (define-public python-pyquery
   (package
 (name "python-pyquery")
-- 
2.23.0

Re: [PATCH 0/4] gnu: Add Cookiecutter and its inputs

[Tanguy Le Carrour]

Hi Gábor!

Thanks for your answer.

Le 10/03, Gábor Boskovits a écrit :
> Guix patches is a patch review queue. Feel free to post them there. Please
> post the cover letter first to open a new issue, and post the rest to the
> assigned issue number.

I've just figured out that one could submit the package AND its
dependencies in one patch [1]. Is it easier to review than sending
4 different patchs/emails?!

[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35752

Also, I tried (but failed) to put the packages in alphabetical order,
so they are scattered all over the file. Would it be better to have them
side by side?

Regards,

-- 
Tanguy

Re: Cannot install `python-pastel`

[Tanguy Le Carrour]

Hi Tobias!

Le 10/03, Tobias Geerinckx-Rice a écrit :
> Tanguy Le Carrour 写道：
> > I guess it must be a problem on my side as all the packages go through
> > CI!?
> 
> No and yes but.
> 
> All packages do ‘go through CI’: ci.guix.gnu.org builds each new package,
> and whenever that succeeds, everyone gets a nice substitute for it.
> 
> However: we don't use CI success as a condition for merging commits to
> master (a commit must already be on master for CI to even see it).  There's
> also no ‘stable’ branch that only gets commits that were successfully CI'd.
> Committers or users aren't notified of CI failure in any way.

Thanks for the explanations! This makes things clearer!

Does it mean that I have to submit a patch the usual way to fix it?
Should the subject be something like "[PATCH] gnu: Fix python-pastel"?

Regards,

-- 
Tanguy

Re: [PATCH 0/4] gnu: Add Cookiecutter and its inputs

[Tanguy Le Carrour]

Le 10/03, Gábor Boskovits a écrit :
> Tanguy Le Carrour  ezt írta (időpont: 2019. okt. 3.,
> > I've just figured out that one could submit the package AND its
> > dependencies in one patch [1]. Is it easier to review than sending
> > 4 different patchs/emails?!
> >
> > [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35752
> >
> >
> You can see in the second letter of the thread that keeping the patches
> separate is preferred.

*outch*… I should have seen it!

Thanks!

-- 
Tanguy

Questions about packaging

[Tanguy Le Carrour]

Hi Guix

I'm currently working on packaging python-poetry and, unsurprisingly,
I have questions! :-)
I guess some of them have already been answered somewhere, so don't
hesitate to point me to a previous thread or post…

1) Updating a package
What am I suppose to do when updating a package to a different minor or
major version? This could break depending packages if they have strict
depedencies.

For instance, when I run:
./pre-inst-env guix build python-poetry
I get:
error: Could not find suitable distribution for
Requirement.parse('cachecontrol[filecache]<0.13.0,>=0.12.4')

So I would have to update python-cachecontrol from 0.11.6 to 0.12.5.
Should I create a python-cachecontrol-0.11.6 and fix all the packages
that depend on it? Only the one that would break?

Btw, python-cachecontrol seems to be broken. I'll work on that. But
before I'll have to find an answer to question 3.

2) Getting archive from pypi
This one has been bothering me for a long time, and was confirmed few
days ago by a comment I read in the package definition of python-cachecontrol:
"Pypi does not have tests".
Has I understand it, to make sure that a package works with the
dependencies provided by the distrubution (Guix), tests must pass!
Most of the time, tests are not in the python package downloaded from pypi.
Actually, I think that they should not be. They should be in a `tests/` folder
in the sources. But that's a different topic.
So I guess that one should always make sure that the tests can be
executed from the Pypi download, or use Git to get the sources.
Any thoughts?

3) Deactivating tests on purpose
In my case, python-poetry depends on python-cachecontrol which tests
depend (for some weird reasons) on Cherrypy. Cherrypy is a (large) web framework
and has a lot of dependencies!
In that case, is it OK to disable python-cachecontrol's tests?
Or would it be better to ask one of the project to drop one of the
dependency?! (Poetry dropping CacheControl, or CacheControl dropping
CherryPy)

4) Submitting an incomplete patch series
Having run into those problems, I'm a bit stuck with a pile of patches.
Some of them could be submitted. Should I submit them separatly?

I'm really looking forward to reading your answers!

-- 
Tanguy

Cannot install `python-cachecontrol`

[Tanguy Le Carrour]

Hi Guix,

As mentionned in another thread, python-cachecontrol is broken.

The problem is the following:

Failed: [pytest] section in setup.cfg files is no longer supported,
change to [tool:pytest] instead.

When I fix the package definition, I end up with another problem.
The cachecontrol's test suite relies on a feature of pytest that has
been deprecated and removed.

Is there a way to get around the problem, or do I have to update
python-pytest?… and all its plugins (python-pytest-*)?!

-- 
Tanguy

Re: Questions about packaging

[Tanguy Le Carrour]

Hi Danny !

Thanks for your answer.


Le 10/10, Danny Milosavljevic a écrit :
> > 1) Updating a package
> > So I would have to update python-cachecontrol from 0.11.6 to 0.12.5.
> > Should I create a python-cachecontrol-0.11.6 and fix all the packages
> > that depend on it? Only the one that would break?
> 
> The latter.  That's one of the things we do at Guix but I would not do at 
> work.

OK. I'll do that!
My next question would be "when would someone create a versionned package name?"
Like for instance `openjdk`?


> > Btw, python-cachecontrol seems to be broken. I'll work on that. But
> > before I'll have to find an answer to question 3.
> 
> Then the answer is to update it, and to update everything else that
> depends on it (since it didn't work anyway, what's the harm?  The situation
> can only improve).

"The situation can only improve". Can you believe I didn't think of
that! ^_^'
This makes total sense! Thanks.


> On Wed, 9 Oct 2019 11:56:33 +0200
> Tanguy Le Carrour  wrote:
> 
> > As I understand it, to make sure that a package works with the
> > dependencies provided by the distrubution (Guix), tests must pass!
> 
> Well, it's better if the tests pass, yes.  If the tests fail that's definitely
> bad.  If you absolutely can't get the tests to execute in the first place, 
> let's
> talk about it (with upstream if necessary).

OK. I'll push the discussion upstream.


> > So I guess that one should always make sure that the tests can be
> > executed from the Pypi download, or use Git to get the sources.
> 
> I'd use git (and a tag).  There's no downside that I can see.

Neither can I! I'll do that.


Thanks again for your time and advice !

-- 
Tanguy

Re: Questions about packaging

[Tanguy Le Carrour]

Hi Danny


Le 10/12, Danny Milosavljevic a écrit :
> On Fri, 11 Oct 2019 09:42:00 +0200
> Tanguy Le Carrour  wrote:
> 
> > Le 10/10, Danny Milosavljevic a écrit :
> > > > 1) Updating a package
> > > > So I would have to update python-cachecontrol from 0.11.6 to 0.12.5.
> > > > Should I create a python-cachecontrol-0.11.6 and fix all the packages
> > > > that depend on it? Only the one that would break?  
> > > 
> > > The latter.  That's one of the things we do at Guix but I would not do at 
> > > work.  
> > 
> > OK. I'll do that!
> > My next question would be "when would someone create a versionned package 
> > name?"
> 
> If it's unavoidable.  One of the reasons is that we don't want to increase our
> maintenance and testing burden unduly and thus would not want 453 versions of
> the same package available at the same time (chances are that some combination
> would not have been tested and/or not work).
> 
> But there are professional engineering standards which allow you to specify 
> which versions of thing A can go with which other versions of thing B.
> 
> The most well-known type of that in software is semantic versioning.
> 
> So it depends on what kind of versioning scheme the project/package in 
> question
> uses.  If it does use semantic versioning or similar then packages which have
> changes making it fundamentally incompatible with what came before will 
> increase
> their major version, basically making that an independent package (Debian for
> example has the major version in that sense in their package NAMES for
> libraries).

Shame on me!
I'm perfectly aware of SemVer [1], it's "just" that I mixed up the
problem with python-cachecontrol and the other one with pytest that was
shadowed by python-cachecontrol!
So, yes, there is no version problem going from 0.11.6 to 0.12.5, has
it's only a change of minor version.
The pytest problem that I did not mention was a major change, with deprecation
of some hooks (pytest_namespace).

In Guix, we have Pytest 4.4.2, but the latest release is 5.2.1.
In that case, would it make sense to define a new "versionned" public
variable for python-pytest? Would I create python-pytest5? Or would I
rename python-pytest to python-pytest4 and add python-pytest for Pytest
5? In this later case, would I have to "fix" all the packages that were
using python-pytest?!

[1]: https://semver.org/

> Eventually in some years, there will be no users (other packages) of Python 2
> anymore.  Once that comes to pass we can drop Python 2.  What we can't do is
> replace Python 2 by Python 3 in those user packages--it would break them.

"in some years" will be next year [2]. But I guess Python2 will still be
around for some more years.

[2]: https://www.python.org/dev/peps/pep-0373/


Thanks again for the time you spent clarifying all this for me!


-- 
Tanguy

Re: Questions about packaging

[Tanguy Le Carrour]

Le 10/12, Danny Milosavljevic a écrit :
> Also, in
> 
> (define-public icedtea-6
>   (package
> [...]
> ))
> 
> "icedtea-6" is a variable name (in the programming language Guile).
> 
> The package name is there:
> 
> [...]
> (package
>   (name "icedtea")  <-
> )
> 
> We don't have version numbers in package names--but you can request
> a specific version by 
> 
> $ guix package -i xxx@1.2.3
>   ^^^ ^ package version
>   package name

I'll try to use the vocabulary (variable/package) properly from now on!


-- 
Tanguy

SLiM graphical login manager and keyboard layout

[Tanguy Le Carrour]

Hi Guix!

I'm not a Gnome user and I would like to get rid of GDM and use SLiM
instead.

I'm struggling to set the keyboard layout as, apparently,
slim-service-type is not supposed to be extended as gdm-service-type is.

I guess it's only a matter of copying (and adapting) the `(extend …)` and
`(compose …)` blocks from `gdm-service-type` to `slim-service-type`. But it's
just a guess. I've tried to define `my-slim-service-type` in my system config,
but failed!

Any help will be welcome!

-- 
Tanguy

Re: SLiM graphical login manager and keyboard layout

[Tanguy Le Carrour]

Hi Joshua!


Le 10/18, Joshua Branson a écrit :
> Tanguy Le Carrour  writes:
> > I'm not a Gnome user and I would like to get rid of GDM and use SLiM
> > instead.
> This kind of question is best asked on help-guix mailing list. :)

Yeah, I thought so, but then I figured out that this could be solved by
modifying the code for slim-service-type and posted it on "dev".
If it's just a matter of configuring the service-type, then you're
right, I should have posted it on "help".


> > I'm struggling to set the keyboard layout as, apparently,
> > slim-service-type is not supposed to be extended as gdm-service-type is.
> 
> When I last tried sddm, I was able to swap my layout like so:
> 
> (service sddm-service-type
>  (sddm-configuration
>   (xorg-configuration
>(xorg-configuration
> (keyboard-layout (keyboard-layout "us" "dvorak"))

I tried something a bit different with SLiM:

```
(service slim-service-type
 (slim-configuration
  (xorg-configuration
   (xorg-configuration
(keyboard-layout keyboard-layout)
```

I don't now why, but `(keyboard-layout (keyboard-layout "us" "dvorak"))`
was throwing an error.

It seems to work… actually, it's been building linux-libre for half
an hour now, so I cannot really tell right now! ^_^'

Thanks for the help!
I'll post to "help" if this does not solve my problem!


-- 
Tanguy

Re: SLiM graphical login manager and keyboard layout

[Tanguy Le Carrour]

Hi Alex!


Le 10/18, Alex Griffin a écrit :
> For security reasons, GDM is highly recommended even if you don't use GNOME.
> As far as I know, it's the only currently maintained display manager
> that doesn't run X as root.

That's a very good point. Thanks for raising it to my attention!

The thing is, I've nothing against GDM, but I keep on having problems
with it. It's the second (maybe third) time in 6 months that I run into
some weird problems when I upgrade my system, leaving me unable to login!
So, last time, instead of investigating and fixing the problem…
… I changed for SLiM!

Considering what you've just said… I'll switch back to GDM. But I'll
keep the SLiM+bépo solution at hand!

Regards,

-- 
Tanguy