trying to write my own herd service

[Adam Kandur]

Hi guix!
I tried to write my own herd service, that's what i did
```
(define (my-daemon-shepherd-service _)
  (list (shepherd-service
 (documentation "")
 (provision '(go-github-com-KefirTheAutomator-daemon))
 (requirement '(networking))
 (start #~(make-forkexec-constructor
   (list
(string-append
#$go-github-com-KefirTheAutomator-daemon "/bin/daemon")
" -pidFile=/var/run/my-daemon.pid"
" -logFile=/var/log/my-daemon.log")))
 (stop #~(make-kill-destructor)

(define my-daemon-service-type
  (service-type (name 'my-daemon)
(extensions
 (list (service-extension shepherd-root-service-type
  my-daemon-shepherd-service)))
(default-value #f)
(description "")))
```
(go-github-com-KefirTheAutomator-daemon is my dummy daemon that just
creates a process and writes to it's log file).

This was pulled from my channel, but when I am trying to start the
services, it turns of and disables
```
user@workstation ~$ sudo herd status go-github-com-KefirTheAutomator-daemon
Status of go-github-com-KefirTheAutomator-daemon:
  It is stopped.
  It is disabled.
  Provides (go-github-com-KefirTheAutomator-daemon).
  Requires (networking).
  Conflicts with ().
  Will be respawned.
  Last respawned on Sat Nov 05 02:14:33+0300 2022.

```

Can anyone help me to find out what is wrong, I didn't find any
recommendations on writing herd services?

test suite/ABI issues building guix on Debian (was Re: Release progress, week 3)

[Vagrant Cascadian]

On 2022-11-03, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
 test-name: channel-news, no news
 ...
 actual-error:
 + (git-error
 +   #< code: -1 message: "invalid version 0 on 
 git_proxy_options" class: 3>)
 result: FAIL
>>>
>>> This looks like an ABI issue with libgit2.  Are you sure the same
>>> version of libgit2 is used on all these platforms?

Well, rebuilding guix with a freshly built guile-git (against the newer
libgit2) seemed to resolve the issue on at least one build, so will
update in Debian and see if that helps in general...


>> My quick and rough archeaology shows that libgit2-dev
>> 1.1.0+dfsg.1-4.1+b1 was used to build guile-git 0.5.2-4, but the current
>> libgit2-dev package in Debian is 1.5.0+ds-6 ... so that seems plausible.
>
> [...]
>
>> Maybe there is a better way I can track the various guile-* packages in
>> Debian, but manually tracking all the relevent dependents seems
>> implausible (or at least, a lot of work)... which may lead to the
>> conclusion that maintaining Guix in Debian implausible. :/
>
> I don’t see how that’s specific to guile-* packages though.  Anytime a
> dependency is upgraded that introduces a different ABI, you need to
> rebuild dependents, right?  That’s what’s happening here.

Well, sure. I just have not personally maintained many packages that
need to worry about those kinds of headaches too much... Debian still
requires manual intervention to handle it in some form and lacks the
elegance of guix in this regard. :)


>> Seems like the most likely ones I would have to keep a close eye on are
>> guile-gcrypt, guile-git, guile-gnutls (although currently part of gnutls
>> this will likely change soonish), guile-lzlib, guile-ssh, guile-sqlite3,
>> guile-zlib, guile-zstd. And there's also keeping an eye on guile itself,
>> which adds another set of packages. Wheee. Hrm.
>
> Heh.  Speaking of which, guile-gnutls is now a thing of its own,
> separate from GnuTLS:
>
>   https://gitlab.com/gnutls/guile/
>
> I believe Andreas Metzler already update Debian’s guile-gnutls package
> accordingly.

Oh wow, it is already in debian experimental. :)

Will have to try building guix with it, now... and mentally prepare for
the possibility of more test-suite failure wrangling.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: guix lint false positives and RFC patch

[Vagrant Cascadian]

On 2022-11-03, Vagrant Cascadian wrote:
> On 2022-11-03, Ludovic Courtès wrote:
>> Vagrant Cascadian  skribis:
>>
>>> --- a/guix/lint.scm
>>> +++ b/guix/lint.scm
>>> @@ -313,7 +313,8 @@ (define (tests-explicitly-enabled?)
>>>'()))
>>>  
>>>  (define (properly-starts-sentence? s)
>>> -  (string-match "^[(\"'`[:upper:][:digit:]]" s))
>>> +  (string-match "^[(\"'`[:upper:][:digit:]]"
>>> +(string-replace-substring s "@code{" "")))
>>
>> An identifier in @code or file name in @file may legitimately start with
>> a lower-case letter so I don’t think we should try to prevent that.
>>
>> However, maybe we could change the regexp above to something that
>> accepts @ or some other non-letter character at the start?
>
> Great suggestion, as it is simpler, easier to read, and actually covers
> more false positives! Updated patch attached!
>
> I think there was only one case fixed by the @code{} check for the
> synopsis length check, and I don't see any obvious other @*{} checks
> that would currently improve anything, though it would be ideal to make
> it more future-proof just in case... though I think my attempt at that
> would be awfully ugly, help from others would be welcome!

Well, ugly is what I have... Found two packages affected by @acronym.

Also realized that it should leave the {} in the length-matching, as
they are typically replaced by other characters when rendered.


> That said, I think this resolves 52 false positives with guix lint (~10%
> of the 536 synopsis/description issues currently).

Think with this applied there are 54 false positives fixed.

live well,
  vagrant
From bfa13fdd3616839883e50efbbc05fb132610ce67 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 2 Nov 2022 19:56:12 -0700
Subject: [PATCH 01/12] guix: lint: Exclude some "@" symbols from various
 checks.

The visual representation of "@code{}" or similar in the description and
synopsis do not include the string, so exclude it from checks to avoid false
positives.

FIXME handle @command, @file, @acronym, etc.

* guix/linx.scm (properly-starts-sentence): Exclude leading "@".
  (check-synopsis-length): Exclude "@code" and "@acronym".
---
 guix/lint.scm | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/guix/lint.scm b/guix/lint.scm
index 8e3976171f..76b17b297d 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -313,7 +313,7 @@ (define (tests-explicitly-enabled?)
   '()))
 
 (define (properly-starts-sentence? s)
-  (string-match "^[(\"'`[:upper:][:digit:]]" s))
+  (string-match "^[@(\"'`[:upper:][:digit:]]" s))
 
 (define (starts-with-abbreviation? s)
   "Return #t if S starts with what looks like an abbreviation or acronym."
@@ -650,7 +650,10 @@ (define check-start-article
   '()
 
   (define (check-synopsis-length synopsis)
-(if (>= (string-length synopsis) 80)
+(if (>= (string-length (string-replace-substring
+(string-replace-substring synopsis "@acronym" "")
+"@code" ""))
+   80)
 (list
  (make-warning package
(G_ "synopsis should be less than 80 characters long")
-- 
2.35.1



signature.asc
Description: PGP signature

Re: Compile skribilo doc containing guix channel references

[Phil]

Hi,

Ludovic Courtès writes:

> We toyed with Skribilo/Guix integration in this paper:
>
>  https://hal.inria.fr/hal-01161771/en
>  
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/reppar-2015/reproducible-hpc.skb
>
> (Note that it starts with ugly ‘%load-path’ hacks.  :-))

Thanks for the reply and the links, good to see another example.

> I would suggest using your own script, executed with ‘guix repl’,
> instead of the ‘skribilo’ executable.  Something like you describe in
> your second message looks good!

I've got the repl approach working without the load path hacks now -
creating an --ad-hoc environment containing both guile and skribilo was
all that was required in the end.  If I can make the approach completely
generic I'll post the code somewhere with an example of use.

What's cool is it is then possible to reference packages without even
having the skribilo document co-located in the same repo as the
packages.  For example if I have a package in guix called "my-package":

(define my-package-str
  (with-output-to-string
(lambda () (pretty-print (package->code my-package)

You can then reference this in skribilo like this:

(prog (source :language scheme my-pacakge-str))

This works great, but I have come-up against one issue I have a proposed
fix for.

package->code uses a function called source->code, to output the
scheme representation of the source.  However source->code assumes that
the source can only be an "origin" record, but it's also valid that
source is a "git-checkout" record.  In particular, if the source repo URL
is an ssh address rather than an https address using git-checkout is the
correct approach - for example:

(source
  (git-checkout
(url "ssh://git@myserver/foo/bar.git")
(commit "abcdef12345")))

We make extensive use of this, combined with an ssh-agent, to automate
authentication on private repositories.

Supporting git-checkout in source->code is easy enough - I've written a
fix in our guix channel and it works well, happy to contribute this to
guix-patches too if it makes sense?

The proposed fix can been see here:
https://github.com/quantiletechnologies/qt-guix/commit/49900405617fdf6a2e4ab6f4004306a2770221e0

Finally, I suspect Guix could also be interestingly combined with Haunt
to produce and serve HTML generated from Guix content too:
https://dthompson.us/manuals/haunt/index.html

Cheers,
Phil.

Re: Permanent URL for GUIX packages

[Pjotr Prins]

On Fri, Nov 04, 2022 at 03:49:15PM +, Luis Felipe via Development of GNU 
Guix and the GNU System distribution. wrote:
> > I'd like to link guix.gnu.org/packages/monolith-2.6.1/ from my project's 
> > README file (https://github.com/Y2Z/monolith), but due to the version 
> > string being part of the URL, I can't easily do that, would have to change 
> > the link for every new release.
> 
> Right, the current paths are not that useful.

Indeed. A page giving installation instruction would be useful the way
Conda does it:

https://anaconda.org/bioconda/vcflib

It invites the user to try.

Pj.

Re: Permanent URL for GUIX packages

[Development of GNU Guix and the GNU System distribution.]

Hello Luis,thank you for letting me know about the badge.  I'll put it in the readme once I have a permanent link to attach to it.Best,SunshineOn Nov 4, 2022, at 11:49, Luis Felipe  wrote:Hello Sunshine,
--- Original Message ---
On Thursday, November 3rd, 2022 at 15:50, Sunshine via "Development of GNU Guix and the GNU System distribution."  wrote:

Hello,I'd like to link guix.gnu.org/packages/monolith-2.6.1/ from my project's README file (https://github.com/Y2Z/monolith), but due to the version string being part of the URL, I can't easily do that, would have to change the link for every new release.Right, the current paths are not that useful.Could you please let me know how to permanently link to a specific package on that website from somewhere else?  If it's currently not possible, could you please mention this issue to someone who could potentially add this enhancement to the website, or point me in the right direction as who to talk to?This is a known issue, see https://issues.guix.gnu.org/32261.I'd like to fix that myself, but haven't had the time to do it. But maybe I'll send a patch soon.By the way, Sunshine, there is a guix badge you can use in code forges to indicate the software is available in Guix:SVG: https://luis-felipe.gitlab.io/media/badges/gnu-guix-packaged.svg(https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/badges)Cheers,


publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: Binary data


signature.asc
Description: Binary data

Re: splitting up and sorting commits?

[Liliana Marie Prikler]

Am Freitag, dem 04.11.2022 um 10:20 +0100 schrieb zimoun:
> Hi Liliana,
> 
> On Thu, 03 Nov 2022 at 21:59, Liliana Marie Prikler
>  wrote:
> 
> >  The pauper's
> > solution would be to keep a separate "scratch pad" file containing
> > a bunch of assorted guix packages, ordered in a way that all
> > packages are defined before they're used as inputs – you can easily
> > maintain this order by insertion sort.
> 
> I did something similar that for some Julia packages, but it can be
> tedious depending on the number of packages.  Well, it could be cool
> to have something like
> 
>     guix graph -m some-packages.scm --sort
> 
> returning the list of packages sorted (topological order).
Sorting packages in files sounds like a good application for guix style
imho.  We might even want different orders like topological or
alphabetical.  Guix graph can aid in that, but it'd return a graph
rather than the raw package code.

Cheers

Re: Permanent URL for GUIX packages

[Development of GNU Guix and the GNU System distribution.]

Hello Sunshine,

--- Original Message ---
On Thursday, November 3rd, 2022 at 15:50, Sunshine via "Development of GNU Guix 
and the GNU System distribution."  wrote:


> Hello,
> 

> I'd like to link guix.gnu.org/packages/monolith-2.6.1/ from my project's 
> README file (https://github.com/Y2Z/monolith), but due to the version string 
> being part of the URL, I can't easily do that, would have to change the link 
> for every new release.



Right, the current paths are not that useful.




> Could you please let me know how to permanently link to a specific package on 
> that website from somewhere else?  If it's currently not possible, could you 
> please mention this issue to someone who could potentially add this 
> enhancement to the website, or point me in the right direction as who to talk 
> to?


This is a known issue, see https://issues.guix.gnu.org/32261.


I'd like to fix that myself, but haven't had the time to do it. But maybe I'll 
send a patch soon.


By the way, Sunshine, there is a guix badge you can use in code forges to 
indicate the software is available in Guix:


SVG: https://luis-felipe.gitlab.io/media/badges/gnu-guix-packaged.svg
(https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/badges)


Cheers,

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Permanent URL for GUIX packages

[Development of GNU Guix and the GNU System distribution.]

Hello Florian,

thank you for your reply.

These variants don't seem to be usable in my case, since line offsets often 
change within those files.  Even the link to web.scm on 
https://guix.gnu.org/packages/monolith-2.6.1/ is wrong, since it links the 
latest version of the file and not the one that was used during the build.

I'm honestly very puzzled by the format of the URLs on that website, I don't 
think I've seen that before on any other site that lists packages.  E.g. 
https://guix.gnu.org/packages/monolith-2.6.1/ should ideally be 
https://guix.gnu.org/packages/monolith/ with perhaps 
https://guix.gnu.org/packages/monolith/2.6.1/ to target specific version.  
Otherwise there's no way to be sure the URL will be available once the new 
release is out.  Even .../monolith-latest/ would work, but currently I see no 
way to link to GUIX's website from my Readme file, and I believe that's the 
only one I can't do out of close to 10 different ways of obtaining the 
pre-built software for various platforms.

Is there any way you could reach out to somebody who maintains the packages 
section of the website for guix, or just let me know who I should talk to to 
propose this improvement?

Kindly,
Sunshine


> On Nov 4, 2022, at 09:22, pelzflorian (Florian Pelz) 
>  wrote:
> 
> Hello Sunshine,
> 
> Sunshine via "Development of GNU Guix and the GNU System distribution."
>  writes:
>> I'd like to link guix.gnu.org/packages/monolith-2.6.1/ […]
> 
> Something similar is possible, see .
> 
> Regards,
> Florian

Re: Permanent URL for GUIX packages

[pelzflorian (Florian Pelz)]

Hello Sunshine,

Sunshine via "Development of GNU Guix and the GNU System distribution."
 writes:
> I'd like to link guix.gnu.org/packages/monolith-2.6.1/ […]

Something similar is possible, see .

Regards,
Florian

Re: guix bisect

[zimoun]

Hi,

On Thu, 03 Nov 2022 at 19:18, jgart  wrote:

> do we have something similar to nix-bisect but for guix?
>
> * https://github.com/timokau/nix-bisect

Nothing I am aware.  I mean nothing using ~/.cache/guix/checkouts.

However, it is easy to run the same thing from the development checkout.
I had (still have?) some Bash script for bisecting.

Well, I do not remember and I have not checked if the returned code of
“guix weather” is specified.  If not, it could make the Bash script more
annoying.

Last, this bisection of build failures is already provided by the Data
Service. For instance, see [1].  It currently only uses the Bordeaux
build farm and probably some work to add Berlin but doable, I guess.

1: 
https://data.guix.gnu.org/repository/1/branch/master/package/freecad/output-history


There is many tools from the Nix ecosystem that could be implemented as
Guix extensions.  That’s where Guix shines: it is continuous from core
Guix to package definition or to scripts.

Cheers,
simon

Re: splitting up and sorting commits?

[zimoun]

Hi Liliana,

On Thu, 03 Nov 2022 at 21:59, Liliana Marie Prikler  
wrote:

>  The pauper's solution
> would be to keep a separate "scratch pad" file containing a bunch of
> assorted guix packages, ordered in a way that all packages are defined
> before they're used as inputs – you can easily maintain this order by
> insertion sort.

I did something similar that for some Julia packages, but it can be
tedious depending on the number of packages.  Well, it could be cool to
have something like

guix graph -m some-packages.scm --sort

returning the list of packages sorted (topological order).


Cheers,
simon