Re: seatd-service-type

[Declan]

I am running patch-set from that link on my machine and it's working
without any modifications. I'd like to see it got merged.

FYI, I just switch to Guix recently. Also I am not very familar this
email workflow yet.

> There already exists a patch-set to add seatd and greetd to Guix [1],
> maybe you could try testing the patch-set and see if it works for you?
>
> [1] https://issues.guix.gnu.org/49969
>
> Best,
--


signature.asc
Description: PGP signature

better error messages through assertions

[Ricardo Wurmus]

Hi Guix,

today on IRC someone reported an ugly error message when reconfiguring
their system:

--8<---cut here---start->8---
Backtrace:
  18 (primitive-load "/home/me/.config/guix/current/bin/…")
In guix/ui.scm:
   2209:7 17 (run-guix . _)
  2172:10 16 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
In guix/status.scm:
822:3 14 (_)
802:4 13 (call-with-status-report _ _)
In guix/scripts/system.scm:
   1256:4 12 (_)
In ice-9/boot-9.scm:
  1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   658:37 10 (thunk)
   1320:8  9 (call-with-build-handler # …)
  2123:24  8 (run-with-store # …)
In guix/scripts/system.scm:
827:2  7 (_ _)
703:7  6 (_ #)
In gnu/system.scm:
  1227:19  5 (operating-system-derivation _)
In gnu/services.scm:
   1091:6  4 (instantiate-missing-services _)
In srfi/srfi-1.scm:
   460:18  3 (fold # …)
In gnu/services.scm:
  1092:27  2 (_ (#< type: # …) …)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting 
struct):
--8<---cut here---end--->8---

As you can probably tell easily by looking at this message, the
“service” field of the operating system configuration looked something
like this:

  (services (append (list a b c %desktop-services) #;oops))

instead of this

  (services (append (list a b c) %desktop-services))

This is because INSTANTIATE-MISSING-SERVICES — and FOLD-SERVICES, and
many more — assumes that it is only passed a plain list of services.  It
then proceeds to call SERVICE-KIND on what may or may not be a service.

I think we should add simple type checks, something like this:

  (define (listof pred)
(lambda (thing)
 (and (list? thing) (every pred thing
  …
  (define (assert-type type-check thing message)
(or (false-if-exception (type-check thing))
(report-error (G_ "type error: …\n" message

  ;; Use ASSERT-TYPE in an example procedure.
  (define (do-something-with-services services)
(assert-type (listof service?) services
 "SERVICES must be a list of  values.")

;; Do things…
(map service-kind services))

What do you think?  There are many different ways of implementing this
(a new variant of DEFINE that also accepts a type declaration, an assert
like above, a fancier assert that composes a helpful error message by
itself, a separate type declaration that is looked up only when the
corresponding procedure is called in a certain context, etc), but I’d
first like to know if there is consensus that we want something like
this.

-- 
Ricardo

Re: Changing permissions of files created with simple-service etc-service-type

[Ludovic Courtès]

Josua Stingelin  skribis:

> I'm using the etc-service-type of the simple-service to copy the file. Which
> works great. But sadly grants read-access to everyone. I'd prefer it only be
> readable by root.
>
>   (simple-service 'wpasupplicantconf-service
>   etc-service-type
>   `(("wpa_supplicant.conf",
>  (local-file "wpa_supplicant.conf"
>
>   $ ls -l /etc/wpa_supplicant.conf
>   -r--r--r-- 1 root root 2.3K Feb 11 11:39 /etc/wpa_supplicant.conf
>
> How can I achieve that?

Currently ‘etc-service-type’ does not let you specify permissions.  All
the files that end up in /etc first go through the store though, so
changing the permission of those files once copied under /etc wouldn’t
buy you much in terms of confidentiality.  For example, there’s a copy
of ‘wpa_supplicant.conf’ above in your store.  For that reason, files
containing secrets must be handled “out of band”, without Guix support.

I guess changing permissions for /etc could still be useful for those
programs that verify permission bits and refuse to start if the config
file is readable by all.  However, those programs may have a good reason
to verify that, so…

Thoughts?

Ludo’.

Re: unbound-service-type

[Ludovic Courtès]

Hi,

Josua Stingelin  skribis:

>   (define unbound-shepherd-service
> (match-lambda
>   (($  package pid-file)
>(list (shepherd-service
>(provision '(unbound))
>(documentation "Run the unbound DNS server.")
>(requirement '(networking))
>(start #~(make-forkexec-constructor
>   '(#$(file-append package "/sbin/unbound")
> "-d"
> "-c" "/etc/unbound/unbound.conf")

I’d recommend passing the config file directly, as in:

  "-c" #$(local-file "unbound.conf")

instead of storing it in /etc.  It’s “cleaner” in that you can tell
precisely which config file unbound loaded.

> However when I add these to my operating-system configuration, and copy the
> configuration file using the etc-service-type it doesn't run on start.

Do you have additional info as to why it doesn’t start?  Perhaps error
messages in /var/log/messages or something?

Thanks,
Ludo’.

Re: Unable to bootstrap Guix without substitutes

[Ludovic Courtès]

Hi,

Timothy Sample  skribis:

> Greg Hogan  writes:
>
>> When installing the Guix binary distribution (both the 1.3.0 release
>> and most recent guix-binary on ci.guix.gnu.org) on a new system
>> without enabling substitutes the guix pull or install commands fail
>> when building bash-mesboot0.
>>
>> [...]
>>
>> The error from the log:
>>
>> --8<---cut here---start->8---
>> checking whether #! works in shell scripts... [snip scary backtrace] yes
>> --8<---cut here---end--->8---
>
> I can perform the build successfully using
>
> $ guix build --check \
> -e '(@@ (gnu packages commencement) bash-masboot0)'
>
> That scary backtrace happens even for the successful build, so I’m
> pretty sure it is not the issue.  (Note that the configure test succeeds
> in the end with a “yes”.)

Could it be ?

Specifically, the problem occurs when building on NVMe disks.

Ludo’.

Re: Dropping gzip-compressed substitutes

[Attila Lendvai]

> building. If we want to keep nars long enough so that ‘time-machine’ is
> usable, then storage requirements will keep growing.
>
> Perhaps that means we can regularly copy nars “elsewhere” for long-term
> storage, using nar-herder, rsync, or whatever. The machine that stores
> nars long-term has low requirements compared to the build farm because
> we don’t need to trust it for anything other than storage. If that
> makes things easier (and financially viable), a VPS is good enough.


if the ERIS project proceeds with a reasonable pace (and the Swarm backend,
too), then it would be a perfect opportunity to start stress testing the various
distributed storage backends.

unfortunately, for now Swarm only works through my custom channel that downloads
the release binaries, but that can be fixed, too.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“And remember, where you have a concentration of power in a few hands, all too 
frequently men with the mentality of gangsters get control. History has proven 
that.”
— Lord Acton (1834–1902)

Re: License of your contributions to the blog at guix.gnu.org

[Andreas Enge]

Hello all,

Am Mon, Feb 14, 2022 at 06:36:16PM +0100 schrieb Ludovic Courtès:
> I hope this message finds you well.

it does, thanks for the wishes!

> > With a few exceptions, these articles do not have a clear license, which
> > we would like to fix.  We propose to dual-license all the articles under
> > CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant Sections,
> > no Front-Cover Texts, and no Back-Cover Texts.
> > Do you agree with the proposed licensing terms for your contributions to
> > the blog?

I was not even aware that I had written a blog post, these are nice news
from the past! :-)  I am fine with the licenses.

Andreas

Re: Missing dependency for emacs-magit

[Liliana Marie Prikler]

Hi Zelphir,

Am Montag, dem 14.02.2022 um 18:41 + schrieb Zelphir Kaltstahl:
> Hi Michael!
> What I mean by that is the following in `init.el`:
> 
> (setq guix-package-enable-at-startup t)
> (require 'guix-init nil t)
> 
> I have a separate profile, which I created for Emacs and Emacs packages
> from Guix:
> 
> $ guix package --manifest="${GUIX_EXTRA_PROFILES}"/emacs-test-profile-
> manifest.scm --profile="${GUIX_EXTRA_PROFILES}"/emacs-test-profile
> $ GUIX_PROFILE="${GUIX_EXTRA_PROFILES}/emacs-test-profile"; source
> "${GUIX_PROFILE}/etc/profile"
> $ emacs
> 
> Where the `manifest.scm` contains:
> 
> [...]
> 
> The channel is currently:
> 
> [...]
> 
> When I run `emacs` with that profile, I get the error I described
> earlier.
I think we need some multi-level printf debugging here.  

First, after  `source "${GUIX_PROFILE}/etc/profile"`, is EMACSLOADPATH
correctly pointing to the share/emacs/site-lisp of
${GUIX_EXTRA_PROFILES}/emacs-test-profile?

Second, before and after executing your init.el snippet, what are the
contents of load-path?  
Do they contain /gnu/store/SOME_LONG_HASH-magit-MAGIT_VERSION?

Cheers

Re: Missing dependency for emacs-magit

[Zelphir Kaltstahl]

On 2/14/22 03:50, Michael Rohleder wrote:

Zelphir Kaltstahl  writes:

I noticed, that the emacs-magit package does not seem to work. When I
install it via guix and load it via guix-init in my init.el file, I
get the following error in my *Messages* buffer:

What do you mean with "load it via guix-init in my init.el"?

with e.g.
`guix shell -C -E TERM emacs-no-x emacs-magit -- emacs`
magit seems to work.


Hi Michael!

What I mean by that is the following in `init.el`:


(setq guix-package-enable-at-startup t)
(require 'guix-init nil t)


I have a separate profile, which I created for Emacs and Emacs packages from 
Guix:


$ guix package --manifest="${GUIX_EXTRA_PROFILES}"/emacs-test-profile-manifest.scm 
--profile="${GUIX_EXTRA_PROFILES}"/emacs-test-profile
$ GUIX_PROFILE="${GUIX_EXTRA_PROFILES}/emacs-test-profile"; source 
"${GUIX_PROFILE}/etc/profile"
$ emacs


Where the `manifest.scm` contains:


(specifications->manifest
 '("emacs"
   "emacs-auto-complete"
   "emacs-company"
   "emacs-dockerfile-mode"
   "emacs-editorconfig"
   "emacs-erlang"
   "emacs-exec-path-from-shell"
   "emacs-flycheck"
   "emacs-geiser"
   "emacs-geiser-guile"
   "emacs-geiser-racket"
   "emacs-goto-chg"
   "emacs-jinja2-mode"
   "emacs-json-mode"
   "emacs-magit"
   "emacs-markdown-mode"
   "emacs-moe-theme-el"
   "emacs-monokai-theme"
   "emacs-multiple-cursors"
   "emacs-neotree"
   "emacs-ob-async"
   "emacs-org"
   "emacs-ox-gfm"
   "emacs-pkg-info"
   "emacs-python-environment"
   "emacs-racket-mode"
   "emacs-sml-mode"
   "emacs-toml-mode"
   "emacs-typescript-mode"
   "emacs-undo-tree"
   "emacs-web-mode"
   "emacs-yaml-mode"
   "emacs-yasnippet"
   "guile"
   "guile-colorized"
   "guile-fslib"
   "guile-json"
   "guile-readline"
   "racket"))


The channel is currently:


$ guix describe --format=channels
(list (channel
(name 'guix)
(url"https://git.savannah.gnu.org/git/guix.git;)
(branch "master")
(commit
  "74afcc0f555699d9d6a040fded04a1a379c0b1de")
(introduction
  (make-channel-introduction
"9edb3f66fd807b096b48283debdcddccfea34bad"
(openpgp-fingerprint
  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")


When I run `emacs` with that profile, I get the error I described earlier.

Regards,
Zelphir

--
repositories:https://notabug.org/ZelphirKaltstahl

Re: Dropping gzip-compressed substitutes

[Ludovic Courtès]

Hi!

Thumbs up for the progress made!

Maxim Cournoyer  skribis:

> 3. Come up with a Guile script that is able to
>
>   a) Strip gzip-related metadata from the .narinfo guix-publish metadata
>   files
>   b) recompute and update their 'Signature' field.
>
> 4. Finally, 'rm -r /var/guix/publish/gzip' and free about 6.5 TiB of data.

As discussed on IRC, I’m skeptical about this because:

  1. It requires the development and testing of a custom tool that’s
 easy to get wrong—e.g., it removes a gzipped nar for something that
 had nothing but gzip available, etc.

  2. That code would have to run with privileges that give it access to
 the signing key on berlin.

  3. Those 6.5 TB are an initial constant factor; growth of the storage
 requirements going forward probably matters more and
  will give us more flexibility
 on that.

I like Chris Baines’ idea of decoupling nar distribution from nar
building.  If we want to keep nars long enough so that ‘time-machine’ is
usable, then storage requirements will keep growing.

Perhaps that means we can regularly copy nars “elsewhere” for long-term
storage, using nar-herder, rsync, or whatever.  The machine that stores
nars long-term has low requirements compared to the build farm because
we don’t need to trust it for anything other than storage.  If that
makes things easier (and financially viable), a VPS is good enough.

Thoughts?

Ludo’.

Re: Dropping gzip-compressed substitutes?

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:

[...]

>> It was too early back then but I think we could consider dropping it
>> after 1.4.0 is out, announcing it in advance.
>
> Sounds good to me.

The maintainers went ahead and announced it, thumbs up!  It might also
be worth emailing info-guix?

>> To those users still running a pre-1.1.0 daemon lacking lzip support¹,
>> things will just break, or at least they won’t get newer substitutes.
>> It’s been almost 2 years since 1.1.0 was released though.
>
> I’ll admit that back then I had neglected to upgrade the shared daemon
> at the MDC, missing the change to different compression types.  A
> considerable chunk of the demand for gzip substitutes then could have
> been due to the MDC.

I think it’s understandable; it’s an invisible component, after all.  A
few weeks ago I discovered that a colleague of mine was running
guix-daemon from 0.15.0…

> Printing a warning is a good way to get people’s attention, so I’m all
> for it to prepare for the big break.

Mathieu did that in f9c62b23cc88541756656b3ec602ce987828d906, which
should help!

Ludo’.

Re: License of your contributions to the blog at guix.gnu.org

[Ludovic Courtès]

Hello Andreas, Danjela, Danny, David, Laura, and Roel!

I hope this message finds you well.

If I’m not mistaken, you have not yet replied to my message below, also
visible at
.

Could you take a look?

Replying today is a good way to show your love for free software.  :-)
#ilovefs 

Thanks in advance!

Ludo’.

Ludovic Courtès  skribis:

> Hello,
>
> I am emailing you on behalf of the GNU Guix project because you are the
> author or coauthor of one or more articles to the blog at
> .
>
> With a few exceptions, these articles do not have a clear license, which
> we would like to fix.  We propose to dual-license all the articles under
> CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant Sections,
> no Front-Cover Texts, and no Back-Cover Texts.
>
> Do you agree with the proposed licensing terms for your contributions to
> the blog?
>
> If you do, please reply to this message to say so, keeping
> guix-devel@gnu.org Cc’d (if you already replied in the previous thread,
> you do not need to reply again).
>
> If you would prefer different licensing terms, or if you have any
> questions, feel free to ask them publicly on guix-devel@gnu.org or
> privately with guix-maintain...@gnu.org.
>
> The clarified license will allow us and others to reuse material in the
> manual, cookbook, and in other free cultural works.  See
> 
> for the initial discussion.
>
> Thanks in advance!
>
> Ludo’.


signature.asc
Description: PGP signature

Re: The way to promote GUIX package manager

[Ludovic Courtès]

Hallo!

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>> Hi!
>>
>> Vagrant Cascadian  skribis:
>>
>>> The main two issues I'm aware of are...
>>>
>>> Issue with "guix pull" from the guix 1.2 version:
>>>
>>>   https://bugs.debian.org/1001833
>>
>> I believe this was fixed:
>>
>>   https://issues.guix.gnu.org/52694
>
> Last week (or maybe two weeks ago, but no sooner than that) I ran “sudo
> apt install guix” on a laptop with Debian and I followed the advice to
> pull to the commit corresponding to 1.3.0.

It should no longer be needed.

> Every time at the end I got this git error: “the requested type does not
> match the type in the ODB”.

I think this bug was present in 1.3.0 and was since fixed:

  commit efa578ecaece67366b4b0e2266de7c2faaa4ae54
  https://issues.guix.gnu.org/40377

No workaround for this one, other than passing the actual commit ID
instead of the tag name to ‘guix pull --commit’.

Ludo’.

Recording of FOSDEM 2022 videos are now available to view online

[Oliver Propst]

Here is just a brief note about that most of the FOSDEM 2022 videos are 
now available online to view here [0] for those who is interested to 
have a look at them (something which I think you absolutely should be if 
you are interested and have a passion for Guix and open source 
computing).


FOSDEM 2022 which despite taken place entirely online this year can 
properly be considered as a great success for the Guix project and the 
Declarative and Minimalistic Computing devroom as we had so many cool 
people both attending and presenting at the event.


I think further that the videos from FOSDEM 2022 are a true testament to 
the love and care the people who took time to present at FOSDEM 2022 
feel for free and open source computing and the Guix project in general 
for that matter in this for many people difficult and *challenging times 
we live in.


Anyways here's to hopefully many more years of love and passion for the 
advancement of Guix [1] and free and open source computing.


*which for me and maybe others can work as a motivating factor to work 
for and push for doing the right thing and pushing technology in the 
"right" proper direction (which it feels like the Guix project is all to 
me basically).


*I can mention that I almost got tears in my eyes when I this weekend 
read about Tobias Platens efforts of including Veloren, a game written 
in Rust for Guix (how cool is not that?). See this mail [2] for more 
details about Tobias work and efforts.


0. 
https://fosdem.org/2022/schedule/track/declarative_and_minimalistic_computing/

1. https://guix.gnu.org/
2. https://lists.gnu.org/archive/html/guix-devel/2022-02/msg00118.html

*If the situation with regards to Covid the pandemic improves I think 
there is a a decent possibility about that FOSDEM 2023 could be an 
in-person event and that people are allowed to meet physically in larger 
groups again.


--
Kinds regards Oliver Propst
https://twitter.com/Opropst