[shepherd] several patches that i deem ready

[Attila Lendvai]

dear Guix, Ludo,

i have prepared the rest of my commits that were needed to hunt down the 
shepherd hanging bug. you can find them at:

https://codeberg.org/attila-lendvai-patches/shepherd/commits/branch/attila

there's some dependency among the commits, so sending them to debbugs would be 
either as one big series of commits, or a hopeless labirinth of patches 
otherwise.

therefore i recommend the following workflow instead (assuming that Ludo is 
pretty much the only one hacking on shepherd):

Ludo, please take a look at my branch, and cherry-pick whatever you are happy 
with. then based on your feedback, and the new main branch, i'll rebase and 
refine my commits and give you a head's up when it's ready for another 
merge/review.

the commits are more or less ordered in least controversial order, modulo 
dependencies.

the main additions are:

- a multi-layered error handler that got employed at various points in
  the codebase. this makes shepherd much more resilient, even in case
  of nested errors, and much more communicative in the log when errors
  end up happening.

- a lightweight logging infrastructure together with plenty of log
  lines throughout the codebase, and some hints in the README on how
  to turn log lines gray in emacs (i.e. easily ignorable).

looking forward to your feedback,

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“What you do speaks so loud I cannot hear what you say.”
— Ralph Waldo Emerson (1803–1882)

Re: 07/07: gnu: Add python-docspec.

[Ricardo Wurmus]

Hi Maxim,

> I'm not in the Python team, but I thought I'd give some feedback on
> recent Python packages added.
>
> guix-comm...@gnu.org writes:
>
>> gnu: Add python-docspec.
>> 
>> * gnu/packages/python-xyz.scm (python-docspec): New variable.
>> 
>> Change-Id: I3103bde3483273a335156b38de742f493fd366f1
>> ---
>>  gnu/packages/python-xyz.scm | 25 +
>>  1 file changed, 25 insertions(+)
>>
>> diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
>> index 61958d5eac..58a1a2b3cd 100644
>> --- a/gnu/packages/python-xyz.scm
>> +++ b/gnu/packages/python-xyz.scm
>> @@ -622,6 +622,31 @@ Python dataclasses.")
>>  from JSON payloads using the @code{databind.core} framework.")
>>  (license license:expat)))
>>  
>> +(define-public python-docspec
>> +  (package
>> +(name "python-docspec")
>> +(version "2.2.1")
>> +(source
>> + (origin
>> +   (method url-fetch)
>> +   (uri (pypi-uri "docspec" version))
>> +   (sha256
>> +(base32 "1zqmdrc6k8pprra8p3wpzq2ml2gph1cfjmsyg07f8b8fvizffm28"
>> +(build-system pyproject-build-system)
>> +(arguments (list #:tests? #false))  ;there are none
>
> This commit and a few others mention there are no tests; perhaps that's
> true of the PyPI archive, but in this case it's worth fetching from Git
> in my opinion to run the tests.  Here for example, there appear to be a
> Pytest test suite:
> https://github.com/NiklasRosenstein/python-docspec/tree/develop/docspec/test
>
> Fetching from git and adding pytest no native-inputs may be enough to
> have it run.
>
> Something to keep in mind for future submissions!

Yes, I agree.  These recent Python additions are a little special in
that they had been misplaced and forgotten in the guix-science channel.
I’ve recently taken some time to clean up the guix-science channel and
move things that don’t belong there to the default Guix channel,
reviving and updating packages as I went along.

It’s true that it would be a good idea to revisit these packages to
check if we could get a test suite from the source repository and run
it.

-- 
Ricardo

Re: Golang check phase skipping some tests?

[Sharlatan Hellseher]

Hi,

There are not too many Golang packages in Guix comparing to other
language spectific modules:

--8<---cut here---start->8---
grep -r "build-system go-build-system" gnu/packages | awk '{print $1}'
| sort | uniq -c | sort -rn
382 gnu/packages/golang.scm:
 47 gnu/packages/golang-web.scm:
 34 gnu/packages/syncthing.scm:
 17 gnu/packages/golang-check.scm:
  9 gnu/packages/web.scm:
  8 gnu/packages/version-control.scm:
  7 gnu/packages/databases.scm:
  5 gnu/packages/ipfs.scm:
  5 gnu/packages/bioinformatics.scm:
  4 gnu/packages/virtualization.scm:
  4 gnu/packages/networking.scm:
  4 gnu/packages/mail.scm:
  4 gnu/packages/games.scm:
  4 gnu/packages/docker.scm:
  4 gnu/packages/check.scm:
  3 gnu/packages/file-systems.scm:
  3 gnu/packages/admin.scm:
  2 gnu/packages/time.scm:
  2 gnu/packages/textutils.scm:
  2 gnu/packages/terminals.scm:
  2 gnu/packages/password-utils.scm:
  2 gnu/packages/messaging.scm:
  2 gnu/packages/irc.scm:
  2 gnu/packages/geo.scm:
  2 gnu/packages/education.scm:
  2 gnu/packages/curl.scm:
  2 gnu/packages/containers.scm:
  2 gnu/packages/backup.scm:
  1 gnu/packages/xdisorg.scm:
  1 gnu/packages/web-browsers.scm:
  1 gnu/packages/weather.scm:
  1 gnu/packages/vpn.scm:
  1 gnu/packages/tls.scm:
  1 gnu/packages/terraform.scm:
  1 gnu/packages/tcl.scm:
  1 gnu/packages/task-runners.scm:
  1 gnu/packages/task-management.scm:
  1 gnu/packages/sync.scm:
  1 gnu/packages/shellutils.scm:
  1 gnu/packages/radio.scm:
  1 gnu/packages/pulseaudio.scm:
  1 gnu/packages/music.scm:
  1 gnu/packages/monitoring.scm:
  1 gnu/packages/linux.scm:
  1 gnu/packages/image-viewers.scm:
  1 gnu/packages/hyperledger.scm:
  1 gnu/packages/high-availability.scm:
  1 gnu/packages/finance.scm:
  1 gnu/packages/disk.scm:
  1 gnu/packages/debug.scm:
  1 gnu/packages/crypto.scm:
  1 gnu/packages/configuration-management.scm:
  1 gnu/packages/compression.scm:
  1 gnu/packages/calendar.scm:
  1 gnu/packages/authentication.scm:
  1 gnu/packages/android.scm:
--8<---cut here---start->8---

We may enable it globally and rebuild each package and pack and place missing in
native inputs/propagated inputs depending on the purpose.

I would love to investigate the count of packages in  `34
gnu/packages/syncthing.scm:` :-)

Thanks,
Oleg

On Thu, 18 Jan 2024 at 21:31, Troy Figiel  wrote:
>
> Hi Oleg and others,
>
> On 2024-01-18 11:25, Sharlatan Hellseher wrote:
> > With small adjustment of the invok line, I could manage to trigger all 
> > tests to
> > be run, but it brings other issue of some not packed modules required for 
> > the
> > check phase.
>
> Thanks for the update! I noticed the same with `go-github-com-kr-text'.
> It was actually missing a propagated-input that has not been packaged
> yet, so I couldn't easily fix it.
>
> On 2024-01-18 11:25, Sharlatan Hellseher wrote:
> > As a quick ad-hoc to run all tests for some new package you may add a custom
> > check phase with the snippet you provided.
> >
> > I'm currently in review and split some packages from (gnu packages golang) 
> > into
> > (gnu packages golang-crypto) to simplify the maintenance. I try to play with
> > that option and see which packages are missed to satisfy passing all tests.
>
> Once the migration is over, what would you recommend for new packages? I
> could see two options here:
>
> 1. Change the default check phase and only replace it back to the
> previous one for packages that fail to build or
>
> 2. Replace the check phase for all packages one-by-one.
>
> I noticed this behaviour when I was packaging gotenberg and as with any
> reasonably sized Golang package, this one also has a gazillion
> dependencies... I would love to start on the right track :-)
>
> Best wishes,
>
> Troy



-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

Re: Golang check phase skipping some tests?

[Troy Figiel]

Hi Oleg and others,

On 2024-01-18 11:25, Sharlatan Hellseher wrote:
> With small adjustment of the invok line, I could manage to trigger all tests 
> to
> be run, but it brings other issue of some not packed modules required for the
> check phase.

Thanks for the update! I noticed the same with `go-github-com-kr-text'.
It was actually missing a propagated-input that has not been packaged
yet, so I couldn't easily fix it.

On 2024-01-18 11:25, Sharlatan Hellseher wrote:
> As a quick ad-hoc to run all tests for some new package you may add a custom
> check phase with the snippet you provided.
> 
> I'm currently in review and split some packages from (gnu packages golang) 
> into
> (gnu packages golang-crypto) to simplify the maintenance. I try to play with
> that option and see which packages are missed to satisfy passing all tests.

Once the migration is over, what would you recommend for new packages? I
could see two options here:

1. Change the default check phase and only replace it back to the
previous one for packages that fail to build or

2. Replace the check phase for all packages one-by-one.

I noticed this behaviour when I was packaging gotenberg and as with any
reasonably sized Golang package, this one also has a gazillion
dependencies... I would love to start on the right track :-)

Best wishes,

Troy

OpenPGP_0xC67C9181B3893FB0.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Feedback of the GNU Guix manual

[Maxim Cournoyer]

Hi Matt!

Matt  writes:

> I care about this.  How can I help?
>
> - Convert the notes into patches?
> - Proofread any patches that derive from Christian's efforts?

That would be a good way to help, yes!  It'll be easier to review if
each distinct problem is fixed in its own commit (patch).

-- 
Thanks,
Maxim

Re: Golang mudules to follow common grouping

[Maxim Cournoyer]

Hi Oleg,

Sharlatan Hellseher  writes:

> Hi Guix,
>
> I'm about to prepare split and aggregation of all golag packages
>  related to cryptography. The process would be the same as for
>  golang-check and golang-web.
>
>
> In progress:
> golang-cryptography
>
> Planned:
> golang-compression
> golang-build

This sounds like a good idea to me!  Thanks for volunteering to do this
laborious task.

-- 
Maxim

Re: Golang check phase skipping some tests?

[Maxim Cournoyer]

Hi Oleg,

Sharlatan Hellseher  writes:

> Hi,
>
> I can't say that I'm an expert in Golang :-), but I've got some experience in
> building and deploying Glang daily for some time.
>
> First things first the default behaviour of `go test ./...` is like this:
>
> find * -type f -name *_test.go | 
>
>
> Internally Golang tries to find any files with _test.go suffix in
> provided module's
> location and evaluate defined tests in them. If the directory of the module 
> does
> not have test files it's just ignored.
>

[...]

> I'm currently in review and split some packages from (gnu packages golang) 
> into
> (gnu packages golang-crypto) to simplify the maintenance. I try to play with
> that option and see which packages are missed to satisfy passing all tests.

A simple thank you for doing this!

-- 
Maxim

Re: 07/07: gnu: Add python-docspec.

[Maxim Cournoyer]

Hi,

I'm not in the Python team, but I thought I'd give some feedback on
recent Python packages added.

guix-comm...@gnu.org writes:

> gnu: Add python-docspec.
> 
> * gnu/packages/python-xyz.scm (python-docspec): New variable.
> 
> Change-Id: I3103bde3483273a335156b38de742f493fd366f1
> ---
>  gnu/packages/python-xyz.scm | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
> index 61958d5eac..58a1a2b3cd 100644
> --- a/gnu/packages/python-xyz.scm
> +++ b/gnu/packages/python-xyz.scm
> @@ -622,6 +622,31 @@ Python dataclasses.")
>  from JSON payloads using the @code{databind.core} framework.")
>  (license license:expat)))
>  
> +(define-public python-docspec
> +  (package
> +(name "python-docspec")
> +(version "2.2.1")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (pypi-uri "docspec" version))
> +   (sha256
> +(base32 "1zqmdrc6k8pprra8p3wpzq2ml2gph1cfjmsyg07f8b8fvizffm28"
> +(build-system pyproject-build-system)
> +(arguments (list #:tests? #false))  ;there are none

This commit and a few others mention there are no tests; perhaps that's
true of the PyPI archive, but in this case it's worth fetching from Git
in my opinion to run the tests.  Here for example, there appear to be a
Pytest test suite:
https://github.com/NiklasRosenstein/python-docspec/tree/develop/docspec/test

Fetching from git and adding pytest no native-inputs may be enough to
have it run.

Something to keep in mind for future submissions!

-- 
Thanks,
Maxim

Re: Guix at 37C3 Chaos Communication Congress in late Dec?

[Fabio Natali]

On 2024-01-18, 14:25 +0100, Andreas Enge  wrote:
> thanks for your report!

Hey Andreas, thank you for getting back to me.

> This is quite amazing. One of the most depressing experiences at a CCC
> was when I went to a Lisp assembly, and there were at most a dozen
> people around a table, none of whom used the same Lisp dialect.

Haha, yes, I can see how this can very well be a risk!

The advantage of a Lisp assembly is the economy of scale. That'd combine
together various projects that were all massively under-represented at
37c3 - I'm primarily thinking of Guix, Guile, and Emacs as those are the
projects I care about, but there are others too.

If we build enough momentum, we should be able to have decently sized
assembly subgroups - in other words, we should be able to avoid the
twelve-people-that-speak-twelve-different-lisps scenario. :)

What's not ideal with a Lisp assembly is that Guix and Emacs are not
programming languages and, despite related to Lisp, their scope and
ideas transcend - or are partly orthogonal to - Lisp itself.

An other option would be to go the "FOSDEM way" and have a "declarative
and minimalist computing" assembly instead - what do you think?

I still have a slight preference for the Lisp assembly idea, but let's
see what the general feeling/preference is here in the ML. 38c3 won't be
happening any time soon anyway. :)

Thanks, best, F.


-- 
Fabio Natali
https://fabionatali.com

Re: Guix CLI, thoughts and suggestions

[Rostislav Svoboda]

I find the discrepancy regarding two dashes '--' is annoying:

$ guix package --list-generations=1d
...
$ guix describe --list-generations=1d
guix system: error: list-generations=1d: unrecognized option
$ guix describe list-generations=1d
...

And more importantly, I'd be happy if the CLI and REPL syntax were
united, so that there's minimal difference between a shell command
call and a Guile function call. E.g. following would do the same:

$ guix :show emacs
scheme@(guix-user)> (guix :show emacs)


This would greatly facilitate the shell-to-Guile script conversion.

(This way, for comp-sci newcomers, it's much easier to see what a
(bash) shell, with its quirky DSL, really is - not an interface making
computers easier to use, but a barrier obstructing you from properly
using computers as programmable stateful machines. See
https://www.gnu.org/software/guile/manual/html_node/Prompts.html )

Unfortunately, the '#' indicates a comment-start in shells and, as
AFAICS in the source code, we prefer the #:keyword syntax over
:keyword. (Here, in the first step, on an experimental branch, we
could try to add (read-set! keywords 'prefix) everywhere, just to see
what breaks ;-)

Cheers Bost

Re: Guix at 37C3 Chaos Communication Congress in late Dec?

[Matt]

  On Thu, 18 Jan 2024 14:25:19 +0100  Andreas Enge  wrote --- 

 > And my (admittedly dated) experience seems to indicate that there is not
 > much point in joining non-existant Lisp forces.

I'm not sure what you mean by this statement.

Re: Guix deploy --keep-going equivalent for machine connection failures

[Attila Lendvai]

> Another option worth considered is adding a `'can-connection-fail?' (default: 
> #f)` to either `machine` or `machine-ssh-configuration`.

i'd call it `ignore-connection-failure?`, or if we want to ignore all problems 
for a machine, then `ignore-failure?`.

--keep-going could set the default value for the session, and the machine 
specific variable would override it.

as for the implementation, i'd use continuable exceptions of a specific type, 
and then from scheme code users could install handlers that ignore the 
situation.

avoiding shell scripts these days is a good idea after all.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Democracy and liberty are not the same. Democracy is little more than mob 
rule, while liberty refers to the sovereignty of the individual.”
— Walter E. Williams (1936–)

Re: Guix at 37C3 Chaos Communication Congress in late Dec?

[Andreas Enge]

Hello Fabio,

Am Mon, Jan 01, 2024 at 01:49:24PM + schrieb Fabio Natali:
> The introductory session on Day 1 wasn't so bad, I think. Given the low
> level of feedback on the Fediverse I was expecting very few people,
> instead I think we were north of 30 participants!

thanks for your report! This is quite amazing. One of the most depressing
experiences at a CCC was when I went to a Lisp assembly, and there were at
most a dozen people around a table, none of whom used the same Lisp
dialect. So gathering so many people around Guix is very encouraging.
And my (admittedly dated) experience seems to indicate that there is not
much point in joining non-existant Lisp forces.

Andreas

Re: [Guix-europe-sac] Shutting down qa.guix?

[Andreas Enge]

Hello,

Am Sat, Dec 09, 2023 at 11:54:59AM +0100 schrieb Ludovic Courtès:
> I think this underlines a collective failure to get our act together.

indeed, and besides what Simon mentioned about the bank situation I think
there was a certain lack of consistency between deciding on the technical
and on the financial questions. And of course the lack of urgency, since
anyway things continued thanks to Chris... So thank you for all you have
done, Chris, and thank you for taking action now to force us to get our act
together! Indeed QA has become a central part of our project infrastructure.

I suggest the following, which resolves the lockstep between technology and
finance:
- Decide that the funds at the FSF pay for the hosting in its current form.
  Ideally move the billing to Guix Foundation, and then, as we use to do
  for bayfront, periodically ask the FSF to reimburse the hosting cost.
  I think we have an informal consensus for this, and just require a formal
  vote at the Guix spending committee and at the Guix Foundation SAC.
- Reimburse Chris for the costs incurred for hosting before this move.
  As Simon has said, we have a vote for this already, but could also
  start over with the exact amount once the first point is handled, so
  that Chris does not pay for future hosting any more.

Then in a separate step, other people can discuss about potential
technical changes to the hosting situation. It would probably be good
to have a small group of people, including Chris at least for a
transitory period, who take care of the sysadmin part.

Any thoughts on this proposal?

Andreas

Re: Collecting Guix talks at FOSDEM

[Simon Tournier]

Hi Steve,

On mer., 17 janv. 2024 at 21:16, Steve George  wrote:

> Hi - initial draft of the post went to Ludo today for review (and commit 
> as I don't have the rights). We'll see what his reaction is to my 
> British English and random punctuation! ;-)

Cool!  Thank you.

For the next time, in order to avoid to put too much on Ludo’s plate, we
have a dedicated email guix-b...@gnu.org.  The emails there are private
and 2-3 people are behind the list.

For example, the recent post [1] had been sent there then a round of
“review“ (mainly typo and links), and published. :-)

1: https://guix.gnu.org/en/blog/2024/building-packages-targeting-psabis/

Cheers,
simon

Re: Unreleased wget

[Andreas Enge]

Am Sat, Dec 09, 2023 at 12:47:32PM +0100 schrieb Ludovic Courtès:
> I’ve now uploaded a copy of that tarball to ftp.gnu.org/gnu/guix/mirror.
> As a rule of thumb, we should always store upstream tarball copies or
> variants thereof on that server.

Thank you for the fix, and sorry again for my mistake.

Andreas

Re: Golang check phase skipping some tests?

[Sharlatan Hellseher]

Hi,

I can't say that I'm an expert in Golang :-), but I've got some experience in
building and deploying Glang daily for some time.

First things first the default behaviour of `go test ./...` is like this:

--8<---cut here---start->8---
find * -type f -name *_test.go | 
--8<---cut here---start->8---

Internally Golang tries to find any files with _test.go suffix in
provided module's
location and evaluate defined tests in them. If the directory of the module does
not have test files it's just ignored.

Now in actions.

If we investigate which test files we have for `go-github-com-stretchr-testify`
we'll see that for the current version packed in Guix there are some:

--8<---cut here---start->8---
guix describe
Generation 503  Jan 16 2024 13:15:09(current)
  guix 8520f00
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 8520f00d6989ff5ab22755a97dfcfd0375f6b5ca

guix time-machine --commit=8520f00d6989ff5ab22755a97dfcfd0375f6b5ca -- \
shell findutils -- \
find $(guix build go-github-com-stretchr-testify  --no-substitutes)
-type f -name "*_test.go"
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/suite/suite_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/suite/stats_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/mock/mock_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/package_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/require/requirements_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/require/forward_requirements_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/assert/http_assertions_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/assert/forward_assertions_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/assert/assertion_order_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/assert/assertion_compare_test.go
/gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/assert/assertions_test.go
--8<---cut here---start->8---

Checking current implementation of the go-build-system.scm I realized that it
only runs test available in `import-path` and does not scan any farther like
the `./...` option does. In our case it is just one file, rest are ignored.

> /gnu/store/jpizwxbhr93wmday0raz0vk0ny5s5jiv-go-github-com-stretchr-testify-1.7.0/src/github.com/stretchr/testify/package_test.go

> guix/guix/build/go-build-system.scm
--8<---cut here---start->8---
;; Can this also install commands???
(define* (check #:key tests? import-path #:allow-other-keys)
  "Run the tests for the package named by IMPORT-PATH."
  (when tests?
(invoke "go" "test" import-path))
  #t)
--8<---cut here---start->8---

With small adjustment of the invok line, I could manage to trigger all tests to
be run, but it brings other issue of some not packed modules required for the
check phase.

--8<---cut here---start->8---
@@ -275,7 +275,7 @@ (define* (build #:key import-path build-flags
#:allow-other-keys)
 (define* (check #:key tests? import-path #:allow-other-keys)
   "Run the tests for the package named by IMPORT-PATH."
   (when tests?
-(invoke "go" "test" import-path))
+(invoke "go" "test" (string-append import-path "/...")))
   #t)

 (define* (install #:key install-source? outputs import-path
unpack-path #:allow-other-keys)
--8<---cut here---start->8---

As a quick ad-hoc to run all tests for some new package you may add a custom
check phase with the snippet you provided.

I'm currently in review and split some packages from (gnu packages golang) into
(gnu packages golang-crypto) to simplify the maintenance. I try to play with
that option and see which packages are missed to satisfy passing all tests.

Thanks,
Oleg

On Wed, 17 Jan 2024 at 20:25, Simon Tournier  wrote:
>
> Hi,
>
> CC:
> $ ./etc/teams.scm list-members go
> Katherine Cox-Buday 
> Sharlatan Hellseher 
>
>
> On Sun, 14 Jan 2024 at 22:12, Troy Figiel  wrote:
>
> > --8<---cut here---start->8---
> > (define* (check #:key tests? import-p

Re: Proposition to streamline our NAR collection to just zstd-compressed ones

[Giovanni Biscuolo]

Hello,

Ludovic Courtès  writes:

[...]

> From experience we know that users on foreign distros rarely, if ever,
> upgrade the daemon (on top of that, upgrading the daemon is non-trivial
> to someone who initially installed the Debian package, from what I’ve
> seen, because one needs to fiddle with the .service file to adjust file
> names and the likes),

The upgrade instructions are in (info "(guix) Upgrading Guix").

I run the daemon on Debian but installed it with the install script, not
with the Debian package: I'm going to test the installation on a VM and
I'll see/document what a user should do to upgrade a daemon installed
that way

My /etc/systemd/system/guix-daemon.service is:

--8<---cut here---start->8---

# This is a "service unit file" for the systemd init system to launch
# 'guix-daemon'.  Drop it in /etc/systemd/system or similar to have
# 'guix-daemon' automatically started.

[Unit]
Description=Build daemon for GNU Guix

[Service]
ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon 
--build-users-group=guixbuild --substitute-urls='https://ci.guix.gnu.org 
https://bordeaux.guix.gnu.org'
Environment=GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale
 LC_ALL=en_US.utf8
Environment=TMPDIR=/home/guix-builder
RemainAfterExit=yes
StandardOutput=syslog
StandardError=syslog

# See .
# Some package builds (for example, go@1.8.1) may require even more than
# 1024 tasks.
TasksMax=8192

[Install]
WantedBy=multi-user.target

--8<---cut here---end--->8---

I tweaked it a little bit to add "--substitute-urls" to ExecStart and
"LC_ALL" to Environment, but the Guix provided one should work.

AFAIU following the official daemon upgrade instructions should do the
job: right?

If this is not the case with the Debian package IMO it's a Debian
package (.service file) bug: we should add a footnote to (info "(guix)
Upgrading Guix") and file a bug upstream if needed, no?

[...]

> In addition to the warning, we should communicate in advance and make
> sure our instructions on how to upgrade the daemon are accurate and
> clear.

IMO the instructions on (info "(guix) Upgrading Guix") are clear; they
are just for a systemd based distro but should be easily "transposed" to
a different init system by the users... or not?

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature