‘staging’ branch is open!

[Ludovic Courtès]

Hi!

The ‘staging’ branch is open!  Which means that changes with “between
300 and 1,800 rebuilds” (info "(guix) Submitting Patches") can go there;
now’s the time to (re)send package updates in that ballpark.

Incidentally, I was considering ungrafting things on that branch, even
those that go beyond the 1,800 dependents limit, since this is almost
always a safe change and ci.guix now has the capacity and stability
needed for that.

What do people think?

I think we should aim for a freeze in one or two weeks, merging in three
weeks, and resume work on the new release to be done sometime after the
merge.

Thoughts?

Ludo’.

Re: Finding a “good” OpenPGP key server

[Philip McGrath]

Hi,

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

Re: The case for moving raw binaries

[Liliana Marie Prikler]

Am Freitag, dem 29.04.2022 um 11:27 +0200 schrieb Maxime Devos:
> [...]
> 
> I thought that
> 
>   (if already-wrapped?
>   ;; PROG is already a wrapper: add the new "export VAR=VALUE"
>   ;; lines just before the last line.
>   [...])
> 
> in 'wrap-program' would avoid creating ..foo-real-real?
You are correct, I was going on old info that I haven't checked since.

This leaves us with
> That said, the proposed new behaviour seems reasonable to me --
> "pidof emacs" would then actually find Emacs.
and the annoyance that "." shell-completes to all the wrapped binaries.
For the former, there is IIRC still a bug in tramp (and I'm sure other
emacs packages), because a process name doesn't match the expected
regexp.

As for where to move things, I'm starting to lean a little closer
towards having an own output.  That way, we don't need to worry about
stuff from different directories (e.g. bin and sbin) shadowing each
other (even though that shouldn't occur), but more importantly, if we
need to copy data into rawbin so that it's correctly resolved, we can
do that.  The only thing that doesn't quite work is relative resolution
of commands, which would go through the wrapper-less binaries instead.
However, given that the wrapperless binary is invoked from a wrapped
binary, I am 73.69% certain, that this ought not to create too much of
a problem w.r.t. the set environment variables.

WDYT?

Re: Hardened toolchain

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

Apr 29, 2022, 10:31 by zimon.touto...@gmail.com:

> Hi,
>
> On Tue, 29 Mar 2022 at 12:15, Ludovic Courtès  wrote:
>
>> Stack smashing protection (SSP) may incur measurable run-time overhead
>> though so enabling that one by default may be less consensual.
>>
>
> That’s true and it could be an issue for HPC practitioners.  However,
> quoting Wikipedia [1], for what it is worth:
>
> --8<---cut here---start->8---
> All Fedora packages are compiled with -fstack-protector since Fedora
> Core 5, and -fstack-protector-strong since Fedora 20.[19][20] Most
> packages in Ubuntu are compiled with -fstack-protector since 6.10.[21]
> Every Arch Linux package is compiled with -fstack-protector since
> 2011.[22] All Arch Linux packages built since 4 May 2014 use
> -fstack-protector-strong.[23] Stack protection is only used for some
> packages in Debian,[24] and only for the FreeBSD base system since
> 8.0.[25] Stack protection is standard in certain operating systems,
> including OpenBSD,[26] Hardened Gentoo[27] and DragonFly BSD.
> --8<---cut here---end--->8---
>
>
Anaconda (science package distribution) compiles their packages with a variety 
of security flags. These include PIE, SSP, fortify, RELRO, NOW. 
https://www.anaconda.com/blog/improved-security-performance-in-anaconda-distribution-5


> Well, I miss if Guix is built using this ’-fstack-protector’ flag; or
> whether it is included by default.
>

Are /any/ build flags used by default? I  think right now only an empty list is 
used for makeflags by default. It also depends on the configuration for gcc and 
binutils, they can be set to enforce SSP and others by default.


> Cheers,
> simon
>
>
>
> 1: 
> 
>

Re: gnu: shepherd: patch, snippet or phase

[zimoun]

Hi Maxime,

On Sat, 05 Mar 2022 at 22:49, Maxime Devos  wrote:
> (as implied per zimoun's previous mail (‘FWIW, it would be unfair for
> the patch to have the discussion here’), moved to guix-devel)

Thanks. :-)

> Leo Famulari schreef op za 05-03-2022 om 16:13 [-0500]:
>> On Thu, Mar 03, 2022 at 07:25:22AM +0100, Maxime Devos wrote:
>> > Leo Famulari schreef op wo 02-03-2022 om 18:50 [-0500]:
>> > > Origin snippets should only be used to remove nonfree things
>> > > from the upstream source code. All other changes should use
>> > > patch files or a build phase.
>> > 
>> > Why?  If it's a source code change and it fits an origin snippet,
>> > why not an origin snippet?  Why would the source in Guix need to
>> match
>> > the source upstream?
>> 
>> `guix build --source` is a tool to provide freely licensed source
>> code
>> to be used for any purpose, including building on systems besides
>> Guix.
>> 
>> Using the Guix tools, there is no way to access the upstream source
>> code
>> without applying the snippets. The reason for that is that the origin
>> snippet mechanism was introduced specifically to remove non-free
>> components without making it easy to reverse the transformation.
>
> It might be introduced for removing non-free components, that doesn't
> mean it cannot be used for more.  Also, I don't see the point of ease
> of reversing here. It's trivial to reverse the transformation induced
> by the snippet: just delete the snippet in a git checkout.

Well, the point is the FSDG [1] frame, I guess.  From my understanding,
when --source had been introduced, it was a countermeasure to be able to
use hybrid source and still be compliant with an interpretation of: «A
free system distribution must not steer users towards obtaining any
nonfree information for practical use, or encourage them to do so.»

Therefore, using Guix tools, e.g., guix build --source, it is not easy
to reverse what ’snippet’ does.

I would not say it is trivial to reverse the transformation because the
user needs to run “guix edit”, then reassemble the URL, then fetch.
Otherwise, yes the user could go to the Guix repo, remove the snippet,
then run “guix shell -D guix”, do somehow “./pre-inst-env guix …”.

Well, I do not consider these steps “trivial”.  And if one user does
that, somehow they really want to obtain nonfree information. :-)



1: 

>> Compare that to patch files, which are easily reversed,
>
> Removing a patch file by removing it from the 'patches' field is easy,
> as easy as removing a snippet.  I assume you meant the additional
> condition ‘... using only CLI tools’?

Yes, somehow.


> I am aware of the guideline of keeping the source usable outside Guix
> systems.  AFAICT, in this case, the snippet modifying
> Makefile.am/Makefile.in keeps the source usable on non-Guix systems.
> In fact, it makes the source _more_ usable, both on Guix and non-Guix,
> by working-around a Guile 3.0.5 compiler bug.  So I don't see any
> problems here.

Well, the question without consensus is what “guix build --source”
should return?

  a) The source of what “guix build” concretely builds?
  b) The source of upstream (modulo the removal of nonfree part)?

The aim is to be as close as possible as b), IMHO.  The exception of
patches could be discussed. :-)


Back to Shepherd, because the question is originally from patch#54216
[2], the initial snippet was turning a flag:

--8<---cut here---start->8---
+ (snippet
+  '(begin
+ ;; Build with -O1 to work around .
+ (substitute* "Makefile.am"
+   (("compile --target")
+"compile -O1 --target"))
--8<---cut here---end--->8---

Somehow, the snippet could be considered as a “patch“.  And, in the same
time, the upstream source will not compile without this ’-O1’, IIUC.

However, since “we“ are in the same time upstream and downstream, we
could fix that without introducing this kind of snippet.

Last, because the package is for building with Guix, then it seems more
appropriate to have the substitution in the ’arguments’, as v3 [3] is
doing.


2: 
3: 



Cheers,
simon

RFC: Configurable placing of the ~/.guix-home symlink

[EuAndreh]

Hi Guix!

When trying to get a clean $HOME, I see that the ~/.guix-home path is fixed in
the code under gnu/home/*,
usually via (string-append (GETENV "HOME") "/.guix-home").

I want to propose a configurable path to ~/.guix-home, and allow this to be
chosen in the (home-environment ...) declaration.  It would expose a
GUIX_HOME_PATH_ENVIRONMENT variable[0] so that one could dynamically retrieve
the path to it, if needed in scripts or similar.  The implementation would also
need to be able to handle changes in the (home-environment ...) declaration,
and know when to remove the old symlink from ~/.guix-home to the new path,
similar to what the gnu/home/services/symlink-manager.scm does nowadays.

How do you feel about this?  What do you think?  Is there a shortcoming,
pitfalls, limitations that this approach entails?

I'm willing do work on the implementation and on tests where applicable, and
send the patches (eventually when I get this done =p).  I wanted to raise a
discussion before jumping into the code, even to get input and see how the
community feels about this.

WDYT?


[0]: I'm not picking this name, I just made up to make this more concrete.  I'd
 look at the existing variable declarations, such as those exposed by
 `guix shell` to make it consistent with them.

see which X11 config is being used

[Théo Maxime Tyburn]

Hi,

I would like to look at the final config file for xorg that was generated in
the system definition. I looked into
/var/guix/profiles/system/profile/share/X11/ with no success. Where
could I find it ? Could it also be possible to generate it directly in
scheme in the guix repl ?

Best,

Théo

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[zimoun]

Hi,

On Thu, 28 Apr 2022 at 10:08, Ludovic Courtès  wrote:

> I’m not sure what “personal” means in this case.

Quoting [1]:

From: Alex Kost 
To: John Soo 
Cc: Guix-Devel 
Subject: Re: New emacs-guix location
Date: Tue, 22 Dec 2020 13:20:59 +0300

John Soo (2020-11-24 11:23 -0800) wrote:

> Hello Alex and Guix,
> Hope you are well.

Hello, I am fine, thanks!

> I volunteered to maintain some version of
> emacs-guix recently. How do you feel about a fork moving to Savannah?

You (and all the Guix people) are free to do whatever you think is
appropriate.  Emacs-Guix is a free software after all.

So if you will maintain the "official" (used by Guix) version of
Emacs-Guix at Savannah, I will only be happy that I don't have this
burden anymore.

As for me, I will continue to use my version of Emacs-Guix and to adjust
it for my needs.

And thank you for your latest commits that fixed Emacs-Guix for the
current versions of Guix and Geiser!

1: 


> Anyway, the situation is confusing; there’s no point in having two
> slightly different variants.  I suggest we check with Alex off-list to
> get a better understanding of what they want.  Worst case, we can
> cherry-pick commits from Alex’s copy if Alex doesn’t want to be involved
> in discussions around Emacs-Guix or Guix development.

To add to the confusion, note that this Gitlab repo [2] also contains
some issues.  But both Gitlab and Github repos are sync by Alex, I
guess.

BTW, note this message [3] by Alex on April 2020:

I am very sorry but I rarely use Guix and Emacs-Guix these days and I
don't have any wish to maintain it. I mean, if it is some small
easy-to-fix problem or a proposed patch, then I will look at it, but
investigating a problem like this is too much for me currently. Sorry 
:-(

Hopefully, someone else who has this problem will look at it.

3: 

and I sent them an email off-list asking them the status on 29 May 2020,
15:33.  And I am not able to find an answer back.


Cheers,
simon

2: 

Re: The case for moving raw binaries

[zimoun]

Hi,

On Thu, 28 Apr 2022 at 18:37, Liliana Marie Prikler  
wrote:

> "raw binaries" (henceforth rawbins) are the unwrapped binaries that
> Guix leaves behind in $PACKAGE/bin with the .$WRAPPER-real name.  This
> practise causes several issues.  For one, those rawbins are visible in
> the shell by typing a dot and using tab completion.  What's more, in
> some build systems there might be two (or even more) off them.  This
> makes a generic wrap after wrap pattern almost impossible to achieve.

Could you provide more details or pointers about «several issues»?

For instance, I do not consider that these “rawbins” visible from shell
is an issue.  Why do you consider it is one?

And I do not understand what you mean by « makes a generic wrap after
wrap pattern».  Could you explain?


> So, what's the fix?  I propose moving rawbins to a different location.
> libexec would spring to mind as a place in which we could hide them, so
> would a new directory in the root of $PACKAGE.  Other than that, adding
> a rawbin output would also be possible, but I am not certain whether
> that'd be the right tradeoff.

Since I do not understand well the problems, contrary, I find “easier”
to have these “rawbins“ in the output store item.  But maybe, I am miss
a key point.


Cheers,
simon

Re: Hardened toolchain

[zimoun]

Hi,

On Tue, 29 Mar 2022 at 12:15, Ludovic Courtès  wrote:

> Stack smashing protection (SSP) may incur measurable run-time overhead
> though so enabling that one by default may be less consensual.

That’s true and it could be an issue for HPC practitioners.  However,
quoting Wikipedia [1], for what it is worth:

--8<---cut here---start->8---
All Fedora packages are compiled with -fstack-protector since Fedora
Core 5, and -fstack-protector-strong since Fedora 20.[19][20] Most
packages in Ubuntu are compiled with -fstack-protector since 6.10.[21]
Every Arch Linux package is compiled with -fstack-protector since
2011.[22] All Arch Linux packages built since 4 May 2014 use
-fstack-protector-strong.[23] Stack protection is only used for some
packages in Debian,[24] and only for the FreeBSD base system since
8.0.[25] Stack protection is standard in certain operating systems,
including OpenBSD,[26] Hardened Gentoo[27] and DragonFly BSD.
--8<---cut here---end--->8---

Well, I miss if Guix is built using this ’-fstack-protector’ flag; or
whether it is included by default.


Cheers,
simon



1: 

Re: The case for moving raw binaries

[Maxime Devos]

raingloom schreef op vr 29-04-2022 om 00:52 [+0200]:
> It should be pretty easy to detect a wrapped binary without moving it.
> We could just include a magic string in it and scan for that, the exact
> same way we scan for store references. If it contains the "wrapped"
> magic UUID, it's wrapped.

This is already the case, at least for 'wrap-program':

(define (wrapped-program? prog)
  "Return #t if PROG is a program that was moved and wrapped by 'wrap-
program'."
  [...])

[...]
  (when (wrapped-program? prog)
(error (string-append prog " is a wrapper. Refusing to wrap.")))


  (if already-wrapped?

  ;; PROG is already a wrapper: add the new "export VAR=VALUE"
lines just
  ;; before the last line.
  [...])
[...]

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: The case for moving raw binaries

[Maxime Devos]

Liliana Marie Prikler schreef op vr 29-04-2022 om 06:13 [+0200]:
> The extra wrapping isn't cancelled though?  You just append the
> definition of $Y to the the already existing definitions, but you don't
> move the wrapper to $RAWBIN_DIR, because the actual binary already
> exists there.

As I understood it, the suggestion was to cancel wrapping if there's
already things in $RAWBIN_DIR.

> In other words, you have after wrap:
> - bin/foo ~> rawbin/foo
> and after wrap-again
> - bin/foo ~> rawbin/foo
> where ~> is the wrapping relation.
> 
> Currently, you have after one wrap
> - bin/foo ~> bin/.foo-real
> after two
> - bin/foo ~> bin/.foo-real
> - bin/.foo-real ~> bin/..foo-real-real
> after three
> - bin/foo ~> bin/.foo-real
> - bin/.foo-real ~> bin/..foo-real-real
> - bin/..foo-real-real ~> bin/...foo-real-real-real
> and so on.
> 
> Is this clearer now?

I thought that

  (if already-wrapped?
  ;; PROG is already a wrapper: add the new "export VAR=VALUE"
  ;; lines just before the last line.
  [...])

in 'wrap-program' would avoid creating ..foo-real-real?

Also, doesn't 'wrap-program' refuse to wrap .foo-real:

  (when (wrapped-program? prog)
(error (string-append prog " is a wrapper. Refusing to wrap.")))

so ..foo-real-real shouldn't be created in the first place?
Do you have a concrete example in which ..foo-real-real happens?

That said, the proposed new behaviour seems reasonable to me -- "pidof
emacs" would then actually find Emacs.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

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