Re: Antioxidant (new rust build system) update - 100% builds

[Maxime Devos]

On 03-11-2022 16:16, Ludovic Courtès wrote:

Hi,

[...]
Perhaps we could temporarily support the “old style”, using the run-time
transformation currently in your repo?  That would allow third-party
channels to migrate peacefully, and it would also reduce the likely hood
of breakage during transition in Guix (e.g., if an old-style package is
merged while the new branch is being built.)


That would be possible (some copy-pasting, and replacing
(define-public application/c-library/whatever ...)
with (define-public application/c-library/whatever (vitaminate/auto 
...)), but "guix refresh -l rust-..." won't be fixed until the source 
code changes are done.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [Guix Website] A Search Page for Packages

[Luis Felipe]

--- Original Message ---
On Saturday, November 5th, 2022 at 18:53, Christopher Baines  
wrote:

> So, personally I think the simplist path forward is to create
> packages.guix.gnu.org as the domain, and do stuff there. That will help
> avoid getting stuck up on how to integrate with the main website.

I like that.


> I'm more than happy to try and help others get this done, I just don't
> have enough time at the moment to commit to it myself.

I understand.


> What Danjela produced in terms of the search is probably fine as
> something to go with, maybe the additional thing that needs writing is
> pages for the individual packages that the search can link to (they can
> just be very simple initially).
> 

> But yeah, are you (or anyone else who's reading) up for hacking on this?

Yeah, I'm willing to work on that. I'll start by adding support for handling 
requests for package detail pages.

I'll report any progress (or lack of it).

Cheers,

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


signature.asc
Description: OpenPGP digital signature

Re: [Guix Website] A Search Page for Packages

[Christopher Baines]

Luis Felipe  writes:

> Hello Guix,
>
> This message is in reply to an old one
> (https://lists.gnu.org/archive/html/guix-devel/2020-07/msg00050.html),
> where Danjela shared the work done during the internship. Danjela
> said:
>
>> I'd like to know if you find the page useful so that I can hopefully
>> start working on incorporating the search functionality into this
>> page: https://guix.gnu.org/packages/.
>
> I'd like to have Danjela's project integrated as soon as
> possible. People have been asking for this feature for a long
> time. And we could take the oportunity to update URL paths to packages
> so that they work as permalinks, which is another change people have
> been asking for for a long time.
>
> What was the integration plan for Danjela's work, specifically? How can I 
> help?
>
> I have a copy of the "guix-packages-search.scm" script (don't remember
> where I got it from), and tried it out locally already.

So, personally I think the simplist path forward is to create
packages.guix.gnu.org as the domain, and do stuff there. That will help
avoid getting stuck up on how to integrate with the main website.

I'm more than happy to try and help others get this done, I just don't
have enough time at the moment to commit to it myself.

What Danjela produced in terms of the search is probably fine as
something to go with, maybe the additional thing that needs writing is
pages for the individual packages that the search can link to (they can
just be very simple initially).

But yeah, are you (or anyone else who's reading) up for hacking on this?

Chris


signature.asc
Description: PGP signature

i586-gnu builds on ci.guix

[Ludovic Courtès]

Hi!

Ludovic Courtès  skribis:

>  - i586-gnu: Chris and I fixed core packages (test failures;
>bordeaux.guix is building them and I’ll enable it on ci.guix real
>soon now.

I was blissfully optimistic: to do that, we first need to run
‘cuirass-remote-worker’ in the childhurds (which are cross-compiled).

Alas Cuirass depends on Fibers, which is currently Linux-only¹, so we
cannot {cross-,}build it for GNU/Hurd.  The good news is that
‘remote-worker.scm’ itself doesn’t seem to use Fibers.  So I wonder if
we could arrange to build a stripped-down package that contains nothing
but ‘cuirass-remote-worker’.  WDYT?

Cuirass also depends on Avahi, which is currently not buildable for
GNU/Hurd due to libcap requiring on Linux-specific headers, and it seems
to be a hard requirement².  Unfortunately ‘remote-worker.scm’ requires
it.

Thoughts?

Ludo’.

¹ There’s preliminary work to address that:
  

² AFAICS Debian doesn’t have it on GNU/Hurd either:
  

Re: [RESEND] Expose #:pre-mount argument of boot-system to raw-initrd.

[Ludovic Courtès]

Hi,

Hilton Chain  skribis:

> The patch adds a #:pre-mount argument to raw-initrd, to be used in the later
> boot-system invocation. This enables more customization space while avoiding
> raw-initrd definition duplicates.

Great.

> My main goal is to unlock LUKS root partition remotely via SSH, as in the
> NixOS module linked below:
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/luksroot.nix

Sounds like a useful improvement; let us know how it goes.

>   linux-initrd: raw-initrd: Add keyword argument #:pre-mount.

Looks like you forgot to send the actual patch, but you might want to
send it to guix-patc...@gnu.org if you think it’s ready for review:

  https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html

Thanks,
Ludo’.

Re: Reproducible Builds Summit 2022, nar support in diffoscope

[Ludovic Courtès]

Christopher Baines  skribis:

> One thing I forgot to tell Efraim about is that I got around to looking
> at nar support in diffoscope. I know this isn't essential as you can
> just unpack the nars, then compare (as I think guix challenge does), but
> I've been thinking this could make it easier to compare nars.
>
> Anyway, as part of this I proposed adding lzip support, since nars can
> be lzipped, that turned out to be quite easy:
>
>   https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/106
>
> I'm finding nar support a bit harder though, I've raised a merge request
> anyway to see if I can get any feedback:
>
>   https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/107

Nice!  It’s good if that eventually allows ‘guix challenge’ to delegate
that to diffoscope.

Ludo’.

Re: Compile skribilo doc containing guix channel references

[Ludovic Courtès]

Phil  skribis:

> At the risk of cross-posting from skribilo list, whilst our internal
> documentation has to remain private, we also have a public fork of guix
> which would benefit from some documentation explaining the changes we've made
> to guix core code that we hope one day to push upstream - so I've taken
> the same technique and applied it here - so people can see a working example:
>
> This generates the docs with guix imports - see compile-command in the header:
> https://github.com/quantiletechnologies/qt-guix/blob/feature/EA-133/compile-docs.scm
>
> This is the document - it's less ambitious than my internal version in
> terms of generating content from guix - but has a few examples of
> generating content from channels:
> https://github.com/quantiletechnologies/qt-guix/blob/feature/EA-133/qtdocs/qt-guix.skb

Nice!  Including channel info in the document like you do here is
probably a major use case; it also makes a lot of sense in the context
of reproducible research workflows.

Looking forward to discussing the ‘qt-guix’ improvements too.  :-)

Ludo’.

Re: Compile skribilo doc containing guix channel references

[Ludovic Courtès]

Hi,

Phil  skribis:

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

Sure, that makes sense; you can send it to guix-patches.

I’d suggest using #:autoload for (guix git) and adding a test case in
‘tests/print.scm’.

Thanks,
Ludo’.

Re: guix pypi-ls

[jgart]

On Sat, 05 Nov 2022 12:47:19 -0500 jgart  wrote:
> $ pypi-ls  
> https://files.pythonhosted.org/packages/e4/f9/c888a9cb6e959e7619262e21c17bf7d9afcba31a29120a8bc2de4242a488/pygls-0.13.0.tar.gz

Ideally, I'd just give it the PyPi canoncial name as argument instead
of that long path to the tar file.

Re: guix lint false positives and RFC patch

[Ludovic Courtès]

Hi,

Vagrant Cascadian  skribis:

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

LGTM!  Bonus points for a test in ‘tests/lint.scm’.  :-)

Ludo’.

guix pypi-ls

[jgart]

hi,

I have this one off script I call `pypi-ls` for listing tar files on
standard output from pypi to see if they contain tests:

#!/bin/env sh

exec wget -qO- $1 | tar xvz

Would this feature/idea be useful to be integrated into the guix cli somehow?

Maybe integrated into the pypi importer?

Should the pypi importer eventually warn if tests are missing automatically?

This is how I currently use `pypi-ls`

$ pypi-ls  
https://files.pythonhosted.org/packages/e4/f9/c888a9cb6e959e7619262e21c17bf7d9afcba31a29120a8bc2de4242a488/pygls-0.13.0.tar.gz

pygls-0.13.0/
pygls-0.13.0/.editorconfig
pygls-0.13.0/.gitattributes
pygls-0.13.0/.github/
pygls-0.13.0/.github/FUNDING.yml
pygls-0.13.0/.github/workflows/
pygls-0.13.0/.github/workflows/ci.yml
pygls-0.13.0/.github/workflows/json-extension.yml
pygls-0.13.0/.gitignore
pygls-0.13.0/CHANGELOG.md
pygls-0.13.0/CODE_OF_CONDUCT.md
pygls-0.13.0/CONTRIBUTING.md
pygls-0.13.0/CONTRIBUTORS.md
pygls-0.13.0/Implementations.md
pygls-0.13.0/LICENSE.txt
pygls-0.13.0/MANIFEST.in
pygls-0.13.0/PKG-INFO
pygls-0.13.0/PULL_REQUEST_TEMPLATE.md
pygls-0.13.0/README.md
pygls-0.13.0/RELEASING.md
pygls-0.13.0/ThirdPartyNotices.txt
pygls-0.13.0/assets/
pygls-0.13.0/assets/img/
pygls-0.13.0/assets/img/readme/
pygls-0.13.0/assets/img/readme/completion-list.png
pygls-0.13.0/docs/
pygls-0.13.0/docs/Makefile
pygls-0.13.0/docs/make.bat
pygls-0.13.0/docs/source/
pygls-0.13.0/docs/source/conf.py
pygls-0.13.0/docs/source/index.rst
pygls-0.13.0/docs/source/pages/
pygls-0.13.0/docs/source/pages/advanced_usage.rst
pygls-0.13.0/docs/source/pages/getting_started.rst
pygls-0.13.0/docs/source/pages/testing.rst
pygls-0.13.0/docs/source/pages/tutorial.rst
pygls-0.13.0/examples/
pygls-0.13.0/examples/README.md
pygls-0.13.0/examples/fountain-extension/
pygls-0.13.0/examples/fountain-extension/.gitignore
pygls-0.13.0/examples/fountain-extension/README.md
pygls-0.13.0/examples/fountain-extension/demo.png
pygls-0.13.0/examples/fountain-extension/fountain-language-configuration.json
pygls-0.13.0/examples/fountain-extension/package-lock.json
pygls-0.13.0/examples/fountain-extension/package.json
pygls-0.13.0/examples/fountain-extension/src/
pygls-0.13.0/examples/fountain-extension/src/client.ts
pygls-0.13.0/examples/fountain-extension/src/server.py
pygls-0.13.0/examples/fountain-extension/src/server.ts
pygls-0.13.0/examples/fountain-extension/tsconfig.json
pygls-0.13.0/examples/fountain-extension/tunnel.png
pygls-0.13.0/examples/fountain-extension/webpack.config.js
pygls-0.13.0/examples/json-extension/
pygls-0.13.0/examples/json-extension/.eslintrc.yml
pygls-0.13.0/examples/json-extension/.gitignore
pygls-0.13.0/examples/json-extension/.vscode/
pygls-0.13.0/examples/json-extension/.vscode/launch.json
pygls-0.13.0/examples/json-extension/.vscode/tasks.json
pygls-0.13.0/examples/json-extension/.vscodeignore
pygls-0.13.0/examples/json-extension/LICENSE.txt
pygls-0.13.0/examples/json-extension/README.md
pygls-0.13.0/examples/json-extension/client/
pygls-0.13.0/examples/json-extension/client/src/
pygls-0.13.0/examples/json-extension/client/src/extension.ts
pygls-0.13.0/examples/json-extension/package-lock.json
pygls-0.13.0/examples/json-extension/package.json
pygls-0.13.0/examples/json-extension/server/
pygls-0.13.0/examples/json-extension/server/__init__.py
pygls-0.13.0/examples/json-extension/server/__main__.py
pygls-0.13.0/examples/json-extension/server/server.py
pygls-0.13.0/examples/json-extension/server/tests/
pygls-0.13.0/examples/json-extension/server/tests/__init__.py
pygls-0.13.0/examples/json-extension/server/tests/unit/
pygls-0.13.0/examples/json-extension/server/tests/unit/__init__.py
pygls-0.13.0/examples/json-extension/server/tests/unit/test_features.py
pygls-0.13.0/examples/json-extension/tsconfig.json
pygls-0.13.0/pygls/
pygls-0.13.0/pygls/__init__.py
pygls-0.13.0/pygls/capabilities.py
pygls-0.13.0/pygls/constants.py
pygls-0.13.0/pygls/exceptions.py
pygls-0.13.0/pygls/feature_manager.py
pygls-0.13.0/pygls/lsp/
pygls-0.13.0/pygls/lsp/__init__.py
pygls-0.13.0/pygls/lsp/methods.py
pygls-0.13.0/pygls/lsp/types/
pygls-0.13.0/pygls/lsp/types/__init__.py
pygls-0.13.0/pygls/lsp/types/basic_structures.py
pygls-0.13.0/pygls/lsp/types/client.py
pygls-0.13.0/pygls/lsp/types/diagnostics.py
pygls-0.13.0/pygls/lsp/types/file_operations.py
pygls-0.13.0/pygls/lsp/types/general_messages.py
pygls-0.13.0/pygls/lsp/types/language_features/
pygls-0.13.0/pygls/lsp/types/language_features/__init__.py
pygls-0.13.0/pygls/lsp/types/language_features/call_hierarchy.py
pygls-0.13.0/pygls/lsp/types/language_features/code_action.py
pygls-0.13.0/pygls/lsp/types/language_features/code_lens.py
pygls-0.13.0/pygls/lsp/types/language_features/color_presentation.py
pygls-0.13.0/pygls/lsp/types/language_features/completion.py
pygls-0.13.0/pygls/lsp/types/language_features/declaration.py
pygls-0.13.0/pygls/lsp/types/language_features/definition.py
pygls-0.13.0/pygls/lsp/types/language_features/document_color.py
pygls-0.13.0/pygls/lsp/types/langua

[Guix Website] A Search Page for Packages

[Luis Felipe]

Hello Guix,

This message is in reply to an old one 
(https://lists.gnu.org/archive/html/guix-devel/2020-07/msg00050.html), where 
Danjela shared the work done during the internship. Danjela said:

> I'd like to know if you find the page useful so that I can hopefully start 
> working on incorporating the search functionality into this page: 
> https://guix.gnu.org/packages/.

I'd like to have Danjela's project integrated as soon as possible. People have 
been asking for this feature for a long time. And we could take the oportunity 
to update URL paths to packages so that they work as permalinks, which is 
another change people have been asking for for a long time.

What was the integration plan for Danjela's work, specifically? How can I help?

I have a copy of the "guix-packages-search.scm" script (don't remember where I 
got it from), and tried it out locally already.


---
Luis Felipe López Acevedo
https://luis-felipe.gitlab.io/

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


signature.asc
Description: OpenPGP digital signature

Re: Compile skribilo doc containing guix channel references

[Phil]

Hi,

Phil writes:

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

At the risk of cross-posting from skribilo list, whilst our internal
documentation has to remain private, we also have a public fork of guix
which would benefit from some documentation explaining the changes we've made
to guix core code that we hope one day to push upstream - so I've taken
the same technique and applied it here - so people can see a working example:

This generates the docs with guix imports - see compile-command in the header:
https://github.com/quantiletechnologies/qt-guix/blob/feature/EA-133/compile-docs.scm

This is the document - it's less ambitious than my internal version in
terms of generating content from guix - but has a few examples of
generating content from channels:
https://github.com/quantiletechnologies/qt-guix/blob/feature/EA-133/qtdocs/qt-guix.skb

Re: Permanent URL for GUIX packages

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

Hi Zimon,

thank you, that should work for the time being.  I'd love to link the official 
site on .gnu.org though, please make it possible guys 🥹

> On Nov 5, 2022, at 09:19, zimoun  wrote:
> 
> Hi,
> 
>> On Thu, 03 Nov 2022 at 11:50, Sunshine via "Development of GNU Guix and the 
>> GNU System distribution."  wrote:
>> 
>>  guix.gnu.org/packages/monolith-2.6.1/ 
> 
> Indeed.  Note this alternative:
> 
>https://hpc.guix.info/package/monolith
> 
> 
> Cheers,
> simon

Re: Reproducible Builds Summit 2022

[Christopher Baines]

zimoun  writes:

> Really cool!  Thank you for the heads-up.
>
> On Thu, 03 Nov 2022 at 15:44, Efraim Flashner  wrote:
>
>>  We should also continue working on implementing a
>> change in the ACL to allow requiring a K of N agreement between
>> different substitute servers that a build is correct^2.
>
> I am not a specialist about consensus algorithm so maybe I am totally
> out of topic.  This K-of-N agreement looks like a Proof of Stake [1].

I think it's useful to keep this simple.

Going back to [1], currently we only support users trusting substitutes
if they're signed by any key they trust.

I'd like to see support for more complex policies, like only trusting
substitutes if there's a valid signature from two substitute servers
(two different keys). So trusting substitutes that have been built by
two substitute servers, and they've come to the same result.


1: https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00179.html


signature.asc
Description: PGP signature

Re: trying to write my own herd service

[EuAndreh]

> >  (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")))

[...]

> Your process probably dies too often, thus causing shepherd to disable
> it.

I'd guess that it is dying too often because it is failing to be launched.  The
extra spaces before the "-pidFile" and "-logFile" arguments aren't ignored, like
when in a shell, but are included explicitly.  A contrived equivalent example
is:

$ ls -l
total 36
drwxr-xr-x  6 andreh users 4096 Nov  4 19:42 Desktop
drwxr-xr-x  7 andreh users 4096 Oct 31 21:07 Documents
...
$ ls '-l'
total 36
drwxr-xr-x  6 andreh users 4096 Nov  4 19:42 Desktop
drwxr-xr-x  7 andreh users 4096 Oct 31 21:07 Documents
...
$ ls ' -l'
ls: cannot access ' -l': No such file or directory

I believe that a similar thing is happening to the options to your program, and
it is failing to execute because of that.  You could confirm it by looking that
the logs.

Re: Reproducible Builds Summit 2022

[zimoun]

Hi,

Really cool!  Thank you for the heads-up.

On Thu, 03 Nov 2022 at 15:44, Efraim Flashner  wrote:

>  We should also continue working on implementing a
> change in the ACL to allow requiring a K of N agreement between
> different substitute servers that a build is correct^2.

I am not a specialist about consensus algorithm so maybe I am totally
out of topic.  This K-of-N agreement looks like a Proof of Stake [1].

Well, the problem looks like «Byzantine generals problem» [2] and I do
not know what is the state of the art.  Somehow Paxos [3] algorithm and
variants are often implemented to keep consistent a distributed database
(which is another way to see “different substitute servers”).

Maybe, it could be worth to compare the various approaches… well, if it
has not already been done. :-)

1: 
2: 
3: 


Cheers,
simon

Re: Permanent URL for GUIX packages

[zimoun]

Hi,

On Thu, 03 Nov 2022 at 11:50, Sunshine via "Development of GNU Guix and the GNU 
System distribution."  wrote:

>  guix.gnu.org/packages/monolith-2.6.1/ 

Indeed.  Note this alternative:

https://hpc.guix.info/package/monolith


Cheers,
simon

Update on automating testing of patches and qa.guix.gnu.org

[Christopher Baines]

Hey!

I last emailed guix-devel on this topic back in September:

  https://lists.gnu.org/archive/html/guix-devel/2022-09/msg00054.html
  https://lists.gnu.org/archive/html/guix-devel/2022-09/msg00159.html

Along with some general improvements and fixes, the following things
might be interesting:

 - There are now some bigger badges for the overall status of patch
   issues, thanks Arun!

 - The sort order for the patches page should now be more useful

 - The creation of the patch branches is now handled here (rather than
   through scripts run by Laminar)

 - There is a mailto link on the issue page to toggle the moreinfo
   status, thanks Efraim for the idea!

 - The issue page has a "review checklist". I based this off of
   something Arun suggested for Mumi. The form doesn't do anything, I'm
   just using it as a reminder of things to check when reviewing
   patches.

In terms of next steps:

 - I'm still looking to move this repository on to Savannah, my initial
   attempt failed, so I'm not sure how to do this.

 - Currently it's hard to distinguish "Unknown" builds in to builds
   where some dependency has failed, and builds which just haven't
   happened yet. I'm going to try and change the Guix Data Service to
   provide information on blocking builds in the comparison.

 - For more things, see the README
   https://git.cbaines.net/guix/qa-frontpage/about/


I'm finding this really useful to highlight simple patches which have
had some testing done automatically. I'd encourage others who are
interested in merging patches to try looking at the patches showing up
as green, as hopefully they're in a good state. If there's any which
aren't (e.g. needs some changes or more discussion), you can mark it as
moreinfo to push it down the list (there's a link on the right to do
this).

Do let me know if you have any comments or questions! This should be
easy to hack on as well, and I'm happy to try and help.

Thanks,

Chris


signature.asc
Description: PGP signature

[RESEND] Expose #:pre-mount argument of boot-system to raw-initrd.

[Hilton Chain]

Hi Guix,

The patch adds a #:pre-mount argument to raw-initrd, to be used in the later
boot-system invocation. This enables more customization space while avoiding
raw-initrd definition duplicates.

My main goal is to unlock LUKS root partition remotely via SSH, as in the
NixOS module linked below:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/luksroot.nix

I'm stilling experimenting with that, further progress would come as replies.

Thanks!

Hilton Chain (1):
  linux-initrd: raw-initrd: Add keyword argument #:pre-mount.

 gnu/system/linux-initrd.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


base-commit: 64e53112c2191378cf5dd543e291bec4c6f57b53
--
2.38.0

Expose #:pre-mount argument of boot-system to raw-initrd.

[Hilton Chain]

Hi Guix,

This patch adds a #:pre-mount argument to raw-initrd, to be used in the later
boot-system invocation. This enables more customization space while avoiding
raw-initrd definition duplicates.

My main goal is to unlock LUKS root partition remotely via SSH, as in the
NixOS module linked below:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/luksroot.nix

I'm stilling experimenting with that, further progress would come as replies.

Thanks!

Hilton Chain (1):
  linux-initrd: raw-initrd: Add keyword argument #:pre-mount.

 gnu/system/linux-initrd.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


base-commit: 64e53112c2191378cf5dd543e291bec4c6f57b53
--
2.38.0

Re: Reproducible Builds Summit 2022, nar support in diffoscope

[Christopher Baines]

Efraim Flashner  writes:

> Chris and I are here at the reproducible builds summit in Venice, we're
> winding down now but it's been a great time meeting everyone and
> planning out upcoming tasks.

One thing I forgot to tell Efraim about is that I got around to looking
at nar support in diffoscope. I know this isn't essential as you can
just unpack the nars, then compare (as I think guix challenge does), but
I've been thinking this could make it easier to compare nars.

Anyway, as part of this I proposed adding lzip support, since nars can
be lzipped, that turned out to be quite easy:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/106

I'm finding nar support a bit harder though, I've raised a merge request
anyway to see if I can get any feedback:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/107

Chris


signature.asc
Description: PGP signature

Re: trying to write my own herd service

[Liliana Marie Prikler]

Am Samstag, dem 05.11.2022 um 02:21 +0300 schrieb 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 "")))
> ```
First things first, writing your own shepherd service from Guix adds a
layer of difficulty: Not only do you need to understand shepherd, you
also need to understand how Guix glues things together.  I would
recommend starting with a simple hand-written service, because that
makes it easier to invoke shepherd as a user and inspect its output.

> (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?
Your process probably dies too often, thus causing shepherd to disable
it.  If it is intended to be a one-shot service, mark it as such.  If
not, check there are unfulfilled requirements.

Cheers