Re: Core-updates merge

[Maxim Cournoyer]

Hello,

My gratitude for your patience and perseverance on merging the
core-updates branch :-).

Congratulations everyone!

-- 
Thanks,
Maxim

Re: Setuid handling?

[Saku Laesvuori]

> >  /run/setuid-programs/ should be at the top of your PATH.
> 
> Well, the home profile ends up being first here:

I, too, have my home profile as the first one. Having peeked into
/etc/profile and ~/.guix-home/setup-environment it seems like that is
the original order without any interference from the user's shell
configuration.

> > The default /etc/profile should ensure that

The default /etc/profile only ensures that when the user profile is
~/.guix-profile or ~/.config/guix/current. Guix home stores the profile
at ~/.guix-home/profile.

> Thanks for that pointer! I'm in Bash, via Eat. [1] Right now I'm not
> sure where to look, so more references from anybody would be
> appreciated.

Maybe you could remove the packages with setuid-programs from your home
configuration, but really this seems like a bug in guix home to me.


signature.asc
Description: PGP signature

Re: Setuid handling?

[Leo Famulari]

On Tue, Apr 25, 2023 at 09:21:52AM -0700, Felix Lechner via Development of GNU 
Guix and the GNU System distribution. wrote:
> Well, the home profile ends up being first here:

That's wrong on Guix System.

Check your user's shell initialization files, such as ~/.bash_profile,
~/.profile, ~/.bashrc. If you are using something besides Bash, adjust
accordingly.

Something is changing your $PATH in a way that is broken on Guix System.

Re: Mesa vulkan layer path fix for core-updates

[Kaelyn]

Hi,

--- Original Message ---
On Tuesday, April 25th, 2023 at 2:15 PM, Andreas Enge  wrote:


> 
> 
> Hello Kaelyn,
> 
> thanks for your research!

You're welcome! :)

> Am Wed, Apr 19, 2023 at 04:07:51PM + schrieb Kaelyn:
> 
> > * https://issues.guix.gnu.org/62176 can be closed when core-updates is 
> > merged, since core-updates contains mesa 22.2.4
> > * Though not exactly mesa-related, https://issues.guix.gnu.org/61364 can 
> > possibly be closed now, and almost certainly once the core-updates merge is 
> > completed. (The ticket is a number of workarounds the user applied in early 
> > Feb to be able to build their system profile using core-updates, to pick up 
> > Mesa 22 for newer hardware support. I'm not sure if any of the patches are 
> > still relevant.)
> 
> 
> I just closed these two.
> 
> > * https://issues.guix.gnu.org/58887 looks like an alternate way of solving 
> > the layer path issues that https://issues.guix.gnu.org/59453 also 
> > addresses. Additionally, it adds two new nonstandard VK_*_PATH variables to 
> > vulkan-loader, with at least VK_ILAYER_PATH seeming very similar in 
> > functionality to VK_LAYER_PATH and VK_ADD_LAYER_PATH described at 
> > https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderInterfaceArchitecture.md
> > * https://issues.guix.gnu.org/58251 would be fixed by 
> > https://issues.guix.gnu.org/59453

I feel these two can be closed once 59453 lands, as then the manifests will 
have the store path to their corresponding shared objects. I also think having 
the full paths in the manifests will lead to fewer cross-version/cross-package 
mixing of objects, compared to setting and using environment variables of 
directories to search.

> > * https://issues.guix.gnu.org/62313 might need a modification to mesa e.g. 
> > to add VDPAU_DRIVER_PATH as a native-search-path (one possible solution; in 
> > my home profile I made VDPAU work by setting 
> > "VDPAU_DRIVER_PATH=/run/current-system/profile/lib/vdpau").
> > * https://issues.guix.gnu.org/48868 appears to be the same 
> > VDPAU_DRIVER_PATH issue as https://issues.guix.gnu.org/62313.

For the VDPAU drivers, I plan to do a little more digging and some 
experimenting but I suspect defining VDPAU_DRIVER_PATH as a native-search-path 
is the best way forward. I'll send a patch once I've tested a change locally 
without having my profile set VDPAU_DRIVER_PATH to 
/run/current-system/profile/lib/vdpau.

Cheers,
Kaelyn
> 
> 
> And leave these to you and anybody who wants to work on them!
> 
> Andreas

Re: `mumi send-email' means no more debbugs dance to send multiple patches

[Josselin Poiret]

Hi Arun,

Arun Isaac  writes:

> Hi Josselin,
>
> Ouch! Unfortunately, timeouts can happen. I was just hoping it would be
> unlikely. Did you wait out the full 15 retries of `mumi send-email'?

Yes, I did wait until it completely timed out.

> This is admittedly a somewhat fragile system, but it is the best we can
> do considering debbugs' limitations. Given email's asynchronous store
> and forward design and all the polling we do, a `mumi send-email'
> timeout is possible. Do you think increasing the number of times `mumi
> send-email' retries would help? Did the email you sent using `mumi
> send-email' finally reach debbugs and the mumi server? How long did it
> take? How long do your emails typically take to reach debbugs and the
> mumi server?

My mails usually take less that 30 seconds to get a reply from debbugs.
I don't remember how long it took yesterday for the issue to appear on
mumi though, but more than the 15 retries of mumi send-email (I manually
checked).

> Thanks for the feedback, and happy hacking! :-)

Thanks for your tool!

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: Setuid handling?

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

Hi Josselin,

On Tue, Apr 25, 2023 at 8:37 AM Josselin Poiret  wrote:
>
> Are you on Guix system?

Thanks for asking! I am, and always have been.

>  /run/setuid-programs/ should be at the top of your PATH.

Well, the home profile ends up being first here:

$ echo $PATH | tr : '\n'
/home/lechner/.guix-home/profile/bin
/home/lechner/.guix-home/profile/sbin
/home/lechner/.guix-home/profile/bin
/home/lechner/.guix-home/profile/sbin
/run/setuid-programs
/home/lechner/.config/guix/current/bin
/home/lechner/.guix-profile/bin
/home/lechner/.guix-profile/sbin
/run/current-system/profile/bin
/run/current-system/profile/sbin
/gnu/store/0c1yfbxyv877mlgychfgvmk5ha2jqh52-gzip-1.10/bin
/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin

> The default /etc/profile should ensure that

Mine is shown below.

> but if you do anything else with env variables it might get
> shadowed.

I have buffer-env installed (I'm in EXWM) although I am not sure it
makes a difference. I also do not understand where the gzip and
coreutils references come from.

> I am not too sure of how guix home deals with this, you might
> have to dig deeper there.

Thanks for that pointer! I'm in Bash, via Eat. [1] Right now I'm not
sure where to look, so more references from anybody would be
appreciated.

Kind regards
Felix

[1] https://codeberg.org/akib/emacs-eat

* * *

$ cat /etc/profile
# Crucial variables that could be missing in the profiles' 'etc/profile'
# because they would require combining both profiles.
# FIXME: See .
export 
MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man
export 
INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
export XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share
export 
XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg

# Make sure libXcursor finds cursors installed into user or system
profiles.  See 
export 
XCURSOR_PATH=$HOME/.icons:$HOME/.guix-profile/share/icons:/run/current-system/profile/share/icons

# Ignore the default value of 'PATH'.
unset PATH

# Load the system profile's settings.
GUIX_PROFILE=/run/current-system/profile ; \
. /run/current-system/profile/etc/profile

# Since 'lshd' does not use pam_env, /etc/environment must be explicitly
# loaded when someone logs in via SSH.  See .
# We need 'PATH' to be defined here, for 'cat' and 'cut'.  Do this before
# reading the user's 'etc/profile' to allow variables to be overridden.
if [ -f /etc/environment -a -n "$SSH_CLIENT" \
 -a -z "$LINUX_MODULE_DIRECTORY" ]
then
  . /etc/environment
  export `cat /etc/environment | cut -d= -f1`
fi

# Arrange so that ~/.config/guix/current comes first.
for profile in "$HOME/.guix-profile" "$HOME/.config/guix/current"
do
  if [ -f "$profile/etc/profile" ]
  then
# Load the user profile's settings.
GUIX_PROFILE="$profile" ; \
. "$profile/etc/profile"
  else
# At least define this one so that basic things just work
# when the user installs their first package.
export PATH="$profile/bin:$PATH"
  fi
done

# Prepend setuid programs.
export PATH=/run/setuid-programs:$PATH

# Arrange so that ~/.config/guix/current/share/info comes first.
export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"

# Set the umask, notably for users logging in via 'lsh'.
# See .
umask 022

# Allow Hunspell-based applications (IceCat, LibreOffice, etc.) to
# find dictionaries.
export 
DICPATH="$HOME/.guix-profile/share/hunspell:/run/current-system/profile/share/hunspell"

# Allow GStreamer-based applications to find plugins.
export GST_PLUGIN_PATH="$HOME/.guix-profile/lib/gstreamer-1.0"

if [ -n "$BASH_VERSION" -a -f /etc/bashrc ]
then
  # Load Bash-specific initialization code.
  . /etc/bashrc
fi

Re: Core-updates merge

[Leo Famulari]

Thank you for leading this effort!

The value of leadership and project management is sometimes underappreciated in 
software projects, but they are essential for our success.

On Tue, Apr 25, 2023, at 10:09, Andreas Enge wrote:
> Hello all,
>
> I have just merged core-updates into master and deleted the branch!
> This has been a long adventure, which became particularly intensive
> after the last Guix Days in February. First and foremost many thanks to
> everyone who contributed to the branch, be it by commits, discussions or
> by working on the infrastructure.
>
> Each and every package is not yet in shape; please feel free to submit
> patches for your favourite packages that fail to build. In particular:
> - python-yubikey-manager does not build currently; work to correct this
>   is underway.
> - R on powerpc does not build; this will also be corrected soon;
> - aarch64 has very few substitutes; I think this is mainly due to the build
>   farm catching up and not so much to packages not building, but this is
>   difficult to know.
> If any of these are essential to you, you may wish to wait a little bit
> longer before a "guix pull", or for the time being pull to a commit just
> before the merge by issuing
>guix pull --commit=472706ae2f9160833951a4e4bcc4c206e03097b0
>
> Every end of a story is the beginning of many new ones. Several areas of
> work have already been identified; I will summarise what came up on the
> mailing list and who expressed interest to work on it - please feel free
> to join if a topic interests you, or launch another initiative if you
> want to work on a different subject!
> - rust-team already has a branch that is almost ready to be built and
>   merged, as a precursor to the team based workflow that we need to invent
>   (Efraim Flashner).
> - R on powerpc64le needs to be built by changes to valgrind and lz4
>   (Simon Tournier, I).
> - Many Python packages need updates, in particular with the aim of building
>   python-yubikey-manager (John Kehayias, Lars-Dominik Braun, Brian Cully).
> - There is still work to do to bootstrap GHC until the latest version on
>   i686, and to potentially shorten the bootstrap chain (Lars-Dominik Braun).
> - OCaml could be simplified by dropping version 4.07 (Julien Lepiller).
> - After the mesa update is before the mesa update, and it looks like more
>   features can be enabled (Kaelyn Takata, John Kehayias).
> - Too much in Guix depends on too much else, which makes building things
>   needlessly entangled; in particular time zone data should not be referred
>   to by packages, but be loaded at runtime (Leo Famulari).
>
> All the best in your Guix endeavours,
>
> Andreas

Re: Setuid handling?

[Josselin Poiret]

Hi Felix,

Felix Lechner  writes:
> $ command -v su
> /home/lechner/.guix-home/profile/bin/su

This is the crux of the issue here, it should be
/run/setuid-programs/su.  Are you on Guix system?  /run/setuid-programs/
should be at the top of your PATH.  The default /etc/profile should
ensure that, but if you do anything else with env variables it might get
shadowed.  I am not too sure of how guix home deals with this, you might
have to dig deeper there.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: Core-updates merge

[Josselin Poiret]

Hi Andreas,

Andreas Enge  writes:

> Hello all,
>
> I have just merged core-updates into master and deleted the branch!
> This has been a long adventure, which became particularly intensive
> after the last Guix Days in February. First and foremost many thanks to
> everyone who contributed to the branch, be it by commits, discussions or
> by working on the infrastructure.

Great work and congrats!  Thank you for taking care of this, especially
with the time it took.  Hopefully we'll never have to do this again :)

> Each and every package is not yet in shape; please feel free to submit
> patches for your favourite packages that fail to build. In particular:
> - python-yubikey-manager does not build currently; work to correct this
>   is underway.
> - R on powerpc does not build; this will also be corrected soon;
> - aarch64 has very few substitutes; I think this is mainly due to the build
>   farm catching up and not so much to packages not building, but this is
>   difficult to know.

The graphical installer is also broken, but that should be adressed by
my recent patchset.

> Every end of a story is the beginning of many new ones. Several areas of
> work have already been identified; I will summarise what came up on the
> mailing list and who expressed interest to work on it - please feel free
> to join if a topic interests you, or launch another initiative if you
> want to work on a different subject!
> [...]

I also want to add something to the list: working out how we can best
implement the team-driven workflow.  We're currently lacking a lot of
documentation for it, and one thing I would really love to see is what
each team's current goals are.  Following the MLs/IRC is one thing, but
not everyone is able to read up on everything.  Should intra-team
communication be on guix-devel for everyone to see?  Should we display
the teams on the website?  How should we approach merging feature
branches to master?

Also, we have the new release on the horizon (I don't really remember
how far in the future it is), so we could maybe try to create a calendar
for it, and set team goals accordingly?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: Core-updates merge

[Katherine Cox-Buday]

On 4/25/23 8:40 AM, Felix Lechner via Development of GNU Guix and the 
GNU System distribution. wrote:

Hi Andreas,

On Tue, Apr 25, 2023 at 7:09 AM Andreas Enge  wrote:


many thanks to
everyone who contributed to the branch, be it by commits, discussions or
by working on the infrastructure.


I'd like to please also acknowledge your pivotal role in shepherding
that monumental merge.

With grace and patience you took on an unrewarding legacy task that
had hardly any potential for glory. For your dedication in advancing
the codebase, you earned my sincere admiration and gratitude. Thank
you!


An emphatic +1.

Re: `mumi send-email' means no more debbugs dance to send multiple patches

[Ricardo Wurmus]

Arun Isaac  writes:

> The mumi server fetches emails from the debbugs server using a periodic
> rsync. This happens once every few minutes (< 5 minutes)[1]. After
> sending the first email, `mumi send-email' polls the mumi server once
> every minute to see if the email has reached the mumi server. `mumi
> send-email' retries this poll for a maximum of 15 times before giving
> up.

This could be changed.  We don’t need to wait for the email to arrive on
the mumi server; could we ask debbugs directly for the email?  (If we
can’t ask for the mail we could ask for newest bugs and check if that
contains the email.)

-- 
Ricardo

Re: Core-updates merge

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

Hi Andreas,

On Tue, Apr 25, 2023 at 7:09 AM Andreas Enge  wrote:
>
> many thanks to
> everyone who contributed to the branch, be it by commits, discussions or
> by working on the infrastructure.

I'd like to please also acknowledge your pivotal role in shepherding
that monumental merge.

With grace and patience you took on an unrewarding legacy task that
had hardly any potential for glory. For your dedication in advancing
the codebase, you earned my sincere admiration and gratitude. Thank
you!

Kind regards
Felix

Re: Setuid handling?

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

Hi Josselin,

On Tue, Apr 25, 2023 at 5:26 AM Josselin Poiret  wrote:
>
> What is `command -v su`

$ command -v su
/home/lechner/.guix-home/profile/bin/su

> and `ls /run/setuid-programs/`?

Please see below for output.

> Have you rebooted since reconfiguring?

Yes, I have---at least twice. Thanks for looking into this!

Kind regards
Felix Lechner

* * *

$ ls -l /run/setuid-programs/
total 4236
-r-sr-xr-x 1 root root55184 Apr 24 19:55 chfn
-r-sr-xr-x 1 root root73368 Apr 24 19:55 dbus-daemon-launch-helper
-r-sr-xr-x 1 root root35432 Apr 24 19:55 fusermount
-r-sr-xr-x 1 root root40560 Apr 24 19:55 fusermount3
-r-xr-sr-x 1 root smtpq  200904 Apr 24 19:55 mailq
-r-xr-sr-x 1 root smtpq  200904 Apr 24 19:55 makemap
-r-sr-xr-x 1 root root56576 Apr 24 19:55 mount
-r-xr-sr-x 1 root smtpq  200904 Apr 24 19:55 newaliases
-r-sr-xr-x 1 root root51664 Apr 24 19:55 newgidmap
-r-sr-xr-x 1 root root37176 Apr 24 19:55 newgrp
-r-sr-xr-x 1 root root51632 Apr 24 19:55 newuidmap
-r-sr-xr-x 1 root root64824 Apr 24 19:55 passwd
-r-sr-xr-x 1 root root70536 Apr 24 19:55 ping
-r-sr-xr-x 1 root root61352 Apr 24 19:55 ping6
-r-sr-xr-x 1 root root32536 Apr 24 19:55 pkexec
-r-sr-xr-x 1 root root22048 Apr 24 19:55 polkit-agent-helper-1
-r-xr-sr-x 1 root smtpq  200904 Apr 24 19:55 send-mail
-r-xr-sr-x 1 root smtpq  200904 Apr 24 19:55 sendmail
-r-sr-xr-x 1 root root37176 Apr 24 19:55 sg
-r-xr-sr-x 1 root smtpq  200904 Apr 24 19:55 smtpctl
-r-sr-xr-x 1 root root45848 Apr 24 19:55 su
-r-sr-xr-x 1 root root   265032 Apr 24 19:55 sudo
-r-sr-xr-x 1 root root   265032 Apr 24 19:55 sudoedit
-r-sr-xr-x 1 root root35832 Apr 24 19:55 umount
-r-sr-xr-x 1 root root  1776328 Apr 24 19:55 xlock

Re: Mesa vulkan layer path fix for core-updates

[Andreas Enge]

Hello Kaelyn,

thanks for your research!

Am Wed, Apr 19, 2023 at 04:07:51PM + schrieb Kaelyn:
> * https://issues.guix.gnu.org/62176 can be closed when core-updates is 
> merged, since core-updates contains mesa 22.2.4
> * Though not exactly mesa-related, https://issues.guix.gnu.org/61364 can 
> possibly be closed now, and almost certainly once the core-updates merge is 
> completed. (The ticket is a number of workarounds the user applied in early 
> Feb to be able to build their system profile using core-updates, to pick up 
> Mesa 22 for newer hardware support. I'm not sure if any of the patches are 
> still relevant.)

I just closed these two.

> * https://issues.guix.gnu.org/58887 looks like an alternate way of solving 
> the layer path issues that https://issues.guix.gnu.org/59453 also addresses. 
> Additionally, it adds two new nonstandard VK_*_PATH variables to 
> vulkan-loader, with at least VK_ILAYER_PATH seeming very similar in 
> functionality to VK_LAYER_PATH and VK_ADD_LAYER_PATH described at 
> https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderInterfaceArchitecture.md
> * https://issues.guix.gnu.org/58251 would be fixed by 
> https://issues.guix.gnu.org/59453
> * https://issues.guix.gnu.org/62313 might need a modification to mesa e.g. to 
> add VDPAU_DRIVER_PATH as a native-search-path (one possible solution; in my 
> home profile I made VDPAU work by setting 
> "VDPAU_DRIVER_PATH=/run/current-system/profile/lib/vdpau").
> * https://issues.guix.gnu.org/48868 appears to be the same VDPAU_DRIVER_PATH 
> issue as https://issues.guix.gnu.org/62313.

And leave these to you and anybody who wants to work on them!

Andreas

Core-updates merge

[Andreas Enge]

Hello all,

I have just merged core-updates into master and deleted the branch!
This has been a long adventure, which became particularly intensive
after the last Guix Days in February. First and foremost many thanks to
everyone who contributed to the branch, be it by commits, discussions or
by working on the infrastructure.

Each and every package is not yet in shape; please feel free to submit
patches for your favourite packages that fail to build. In particular:
- python-yubikey-manager does not build currently; work to correct this
  is underway.
- R on powerpc does not build; this will also be corrected soon;
- aarch64 has very few substitutes; I think this is mainly due to the build
  farm catching up and not so much to packages not building, but this is
  difficult to know.
If any of these are essential to you, you may wish to wait a little bit
longer before a "guix pull", or for the time being pull to a commit just
before the merge by issuing
   guix pull --commit=472706ae2f9160833951a4e4bcc4c206e03097b0

Every end of a story is the beginning of many new ones. Several areas of
work have already been identified; I will summarise what came up on the
mailing list and who expressed interest to work on it - please feel free
to join if a topic interests you, or launch another initiative if you
want to work on a different subject!
- rust-team already has a branch that is almost ready to be built and
  merged, as a precursor to the team based workflow that we need to invent
  (Efraim Flashner).
- R on powerpc64le needs to be built by changes to valgrind and lz4
  (Simon Tournier, I).
- Many Python packages need updates, in particular with the aim of building
  python-yubikey-manager (John Kehayias, Lars-Dominik Braun, Brian Cully).
- There is still work to do to bootstrap GHC until the latest version on
  i686, and to potentially shorten the bootstrap chain (Lars-Dominik Braun).
- OCaml could be simplified by dropping version 4.07 (Julien Lepiller).
- After the mesa update is before the mesa update, and it looks like more
  features can be enabled (Kaelyn Takata, John Kehayias).
- Too much in Guix depends on too much else, which makes building things
  needlessly entangled; in particular time zone data should not be referred
  to by packages, but be loaded at runtime (Leo Famulari).

All the best in your Guix endeavours,

Andreas

Re: Adding content-addressed URLs to https://guix.gnu.org/sources.json

[Maxim Cournoyer]

Hi Simon,

Simon Tournier  writes:

[...]

> $ guix repl -- build-package-metadata.scm /tmp/
> guix repl: package metadata will be written to '/tmp/'
> Backtrace:
>
> [...]
>
> In procedure %origin-patches-real: Wrong type argument: #< 
> name: "ruby-sorbet-runtime-0.5.10610.20230106174520-1fa668010-checkout" gexp: 
> # (string-append # url: 
> "https://github.com/sorbet/sorbet; commit: 
> "0.5.10610.20230106174520-1fa668010" recursive?: #f> # sha256:0f21dl06alxwn6xgdxyrkd58plmmsv04z2bcls9ld4cfzsrs5537> () 
> 7fa67b7f6000>:out> "/gems/sorbet-" #) # out>)) gnu/packages/ruby.scm:14078:5 7fa67b701c90> guile: #f options: 
> (#:local-build? #t)>
>
>
>
> Somehow, it reveals 3 currently uncovered cases: computed-file appearing
> as,
>
>  1. ’origin’ in source field (ruby-sorbet-runtime)
>  2. ’inputs’ (racket-minimal)
>  3. ’snippet’ in origin in source field (chromium)
>
> And I think we should not try to fix these cases on
> build-package-metadata.scm side but instead investigate why they are
> needed in the first place.
>
>
> The regression in build-package-metadata is introduced by commit
> 7405e0c83f8f4eee5c4c40e809a40f2e4407a38c:
>
>   CommitDate: Tue Mar 28 22:22:24 2023 -0400
>   Author: Maxim Cournoyer 
>
>   gnu: Add ruby-sorbet-runtime.
>
>   * gnu/packages/ruby.scm (ruby-sorbet-runtime): New variable.
>   (sorbet-version): New variable.
>   (sorbet-monorepo): New variable.
>   (make-sorbet-gem-source): New procedure.
>
> (define (make-sorbet-gem-source gem)
>   "Return the source of GEM, a sub-directory."
>   (computed-file
>(string-append "ruby-sorbet-" gem "-" sorbet-version "-checkout")
>(with-imported-modules (source-module-closure '((guix build utils)))
>  #~(begin
>  (use-modules (guix build utils))
>  (copy-recursively (string-append #$sorbet-monorepo
>   "/gems/sorbet-" #$gem)
>#$output)
> [...]
>
> (define-public ruby-sorbet-runtime
>   (package
> (name "ruby-sorbet-runtime")
> (version sorbet-version)
> (source (make-sorbet-gem-source "runtime"))
>
>
> This pattern appears to me wrong.  It should use ’snippet’.  And if the
> point is to have a meaningful path in /gnu/store, as it is the case with
> icecat or linux or emacs-company-box, the current way is
> ’computed-origin-method’ from (guix packages).
>
> For ’ruby-sorbet-runtime’, the fix seems ’computed-origin-method’.

Per the source, IIRC, 'computed-origin-method' is also considered a hack
or workaround around the fact that a snippet can't affect the name of a
source.  But it's a well established one.  That was indeed the rationale
here (to have meaningful top level directory names matching the source),
which is worth it in my opinion.

-- 
Thanks,
Maxim

Re: Adding content-addressed URLs to https://guix.gnu.org/sources.json

[Ludovic Courtès]

Hello,

(+Cc: guix-sysadmin)

Simon Tournier  skribis:

> On Mon, 24 Apr 2023 at 18:41, Ludovic Courtès  
> wrote:
>
>> How does that sound?
>
> The patch LGTM.

Applied in maintenance.git commit
b7af47ceb629b2267ea8c28dbe5750a456be0b8f.

I’ll reconfigure berlin soonish to it runs this updated script.

BTW, I noticed that many ci.guix.gnu.org/file URLs are 404, when those
are bordeaux.guix are not.  This may be due to a more aggressive GC
policy on berlin, since ‘guix publish’ serves /file URLs right from the
store.  We have an nginx cache for /file URLs (see
‘hydra/nginx/berlin.scm’) but it’s no good if files don’t get a change
to reach it before they’re removed from the store.  We should look more
closely into that!

Thanks,
Ludo’.

Re: Adding content-addressed URLs to https://guix.gnu.org/sources.json

[Ludovic Courtès]

Hi!

Simon Tournier  skribis:

> PS: On a side note, building sources.json fails since ~1 month.
>
> $ guix repl -- build-package-metadata.scm /tmp/
> guix repl: package metadata will be written to '/tmp/'
> Backtrace:
>
> [...]
>
> In procedure %origin-patches-real: Wrong type argument: #< 
> name: "ruby-sorbet-runtime-0.5.10610.20230106174520-1fa668010-checkout" gexp: 
> # (string-append # url: 
> "https://github.com/sorbet/sorbet; commit: 
> "0.5.10610.20230106174520-1fa668010" recursive?: #f> # sha256:0f21dl06alxwn6xgdxyrkd58plmmsv04z2bcls9ld4cfzsrs5537> () 
> 7fa67b7f6000>:out> "/gems/sorbet-" #) # out>)) gnu/packages/ruby.scm:14078:5 7fa67b701c90> guile: #f options: 
> (#:local-build? #t)>

I believe this is fixed by 1df54ceab38873dfc0fd2ec27313d7d17c79c350.
(It broke the ‘source’ and ‘disarchive’ jobsets as well.)

> Somehow, it reveals 3 currently uncovered cases: computed-file appearing
> as,
>
>  1. ’origin’ in source field (ruby-sorbet-runtime)
>  2. ’inputs’ (racket-minimal)
>  3. ’snippet’ in origin in source field (chromium)

I think #1 and #2 are okay: we can use any file-like object there, not
just origin/package.  Of course,  is meant to be the best choice
for ‘source’, and  the best choice for ‘inputs’.  But I think
it’s fine to occasionally resort to some other abstraction when these
two are not adequate.

Ludo’.

Re: `mumi send-email' means no more debbugs dance to send multiple patches

[Arun Isaac]

Hi Josselin,

> I've just tried it out, but unfortunately mumi didn't receive the mail
> in time and it just timed out sending the replies :( is there anything
> that could be done on that front?  Does mumi use IMAP IDLE?

Ouch! Unfortunately, timeouts can happen. I was just hoping it would be
unlikely. Did you wait out the full 15 retries of `mumi send-email'?

There are three parts to the system---the debbugs server, the mumi
server and the `mumi send-email' client. `mumi send-email' sends emails
to the debbugs server but polls the mumi server to see if its mail has
been received and registered.

The mumi server fetches emails from the debbugs server using a periodic
rsync. This happens once every few minutes (< 5 minutes)[1]. After
sending the first email, `mumi send-email' polls the mumi server once
every minute to see if the email has reached the mumi server. `mumi
send-email' retries this poll for a maximum of 15 times before giving
up.

This is admittedly a somewhat fragile system, but it is the best we can
do considering debbugs' limitations. Given email's asynchronous store
and forward design and all the polling we do, a `mumi send-email'
timeout is possible. Do you think increasing the number of times `mumi
send-email' retries would help? Did the email you sent using `mumi
send-email' finally reach debbugs and the mumi server? How long did it
take? How long do your emails typically take to reach debbugs and the
mumi server?

Thanks for the feedback, and happy hacking! :-)

Regards,
Arun

[1]: I don't know the exact polling interval of this rsync. Maybe
 Ricardo (CCed) can clarify?

Re: Setuid handling?

[Josselin Poiret]

Hi,

Felix Lechner via "Development of GNU Guix and the GNU System
distribution."  writes:

> Hi,
>
> After reconfiguring today (see below) I can no longer invoke a
> familiar set of setuid executables:
>
> $ su -
> su: Not setuid and you are not root, expect this to fail
> root's password:
>
> $ mailq
> mailq: need root privileges
>
> Has the handling for such executables changed?

What is `command -v su`, and `ls /run/setuid-programs/`?  Have you
rebooted since reconfiguring?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: Adding content-addressed URLs to https://guix.gnu.org/sources.json

[Simon Tournier]

Hi,

On Mon, 24 Apr 2023 at 18:41, Ludovic Courtès  wrote:

> How does that sound?

The patch LGTM.

Cheers,
simon


PS: On a side note, building sources.json fails since ~1 month.

--8<---cut here---start->8---
$ guix repl -- build-package-metadata.scm /tmp/
guix repl: package metadata will be written to '/tmp/'
Backtrace:

[...]

In procedure %origin-patches-real: Wrong type argument: #< name: 
"ruby-sorbet-runtime-0.5.10610.20230106174520-1fa668010-checkout" gexp: # url: "https://github.com/sorbet/sorbet; 
commit: "0.5.10610.20230106174520-1fa668010" recursive?: #f> # () 
7fa67b7f6000>:out> "/gems/sorbet-" #) #)) gnu/packages/ruby.scm:14078:5 7fa67b701c90> guile: #f options: 
(#:local-build? #t)>
--8<---cut here---end--->8---


Somehow, it reveals 3 currently uncovered cases: computed-file appearing
as,

 1. ’origin’ in source field (ruby-sorbet-runtime)
 2. ’inputs’ (racket-minimal)
 3. ’snippet’ in origin in source field (chromium)

And I think we should not try to fix these cases on
build-package-metadata.scm side but instead investigate why they are
needed in the first place.


The regression in build-package-metadata is introduced by commit
7405e0c83f8f4eee5c4c40e809a40f2e4407a38c:

  CommitDate: Tue Mar 28 22:22:24 2023 -0400
  Author: Maxim Cournoyer 

  gnu: Add ruby-sorbet-runtime.

  * gnu/packages/ruby.scm (ruby-sorbet-runtime): New variable.
  (sorbet-version): New variable.
  (sorbet-monorepo): New variable.
  (make-sorbet-gem-source): New procedure.

(define (make-sorbet-gem-source gem)
  "Return the source of GEM, a sub-directory."
  (computed-file
   (string-append "ruby-sorbet-" gem "-" sorbet-version "-checkout")
   (with-imported-modules (source-module-closure '((guix build utils)))
 #~(begin
 (use-modules (guix build utils))
 (copy-recursively (string-append #$sorbet-monorepo
  "/gems/sorbet-" #$gem)
   #$output)
[...]

(define-public ruby-sorbet-runtime
  (package
(name "ruby-sorbet-runtime")
(version sorbet-version)
(source (make-sorbet-gem-source "runtime"))


This pattern appears to me wrong.  It should use ’snippet’.  And if the
point is to have a meaningful path in /gnu/store, as it is the case with
icecat or linux or emacs-company-box, the current way is
’computed-origin-method’ from (guix packages).

For ’ruby-sorbet-runtime’, the fix seems ’computed-origin-method’.

Well, some data behind ’computed-file’ appears in two other places:

./gnu/packages/racket.scm:505:  (computed-file
./gnu/packages/chromium.scm:348:  (computed-file

For ’chromium’, it appears to me somehow overcomplicated to extract all
the layers of patches; the work does not appears to me worth.  Somehow,
I would accept that “our way“ to build Chromium would be lost.

It remains the case of ’racket-minimal’ – which is somehow a corner case
of ’package-direct-sources’,

--8<---cut here---start->8---
scheme@(guix-user)> ,use(gnu packages racket)
scheme@(guix-user)> racket-minimal
$1 = #
scheme@(guix-user)> (package-direct-sources racket-minimal)
$2 = ()
--8<---cut here---end--->8---

However, the case is indeed covered by the chain:

 + racket-minimal lists the input racket-vm-cs
 + racket-vm-cs inherits from racket-vm-bc
 + racket-vm-bc inherits from racket-vm-cgc
 + racket-vm-cgc has the source %racket-origin

--8<---cut here---start->8---
scheme@(guix-user)> (package-direct-sources (@@ (gnu packages racket) 
racket-vm-cgc))
$3 = (# url: "https://github.com/racket/racket; 
commit: "v8.7" recursive?: #f> # 
("/gnu/store/g6xlx4ik4skazfdl0a9vbd5r0lmqnnd9-guix-module-union/share/guile/site/3.0/gnu/packages/patches/racket-backport-8.7-pkg-strip.patch"
 
"/gnu/store/g6xlx4ik4skazfdl0a9vbd5r0lmqnnd9-guix-module-union/share/guile/site/3.0/gnu/packages/patches/racket-chez-scheme-bin-sh.patch"
 
"/gnu/store/g6xlx4ik4skazfdl0a9vbd5r0lmqnnd9-guix-module-union/share/guile/site/3.0/gnu/packages/patches/racket-rktio-bin-sh.patch"
 
"/gnu/store/g6xlx4ik4skazfdl0a9vbd5r0lmqnnd9-guix-module-union/share/guile/site/3.0/gnu/packages/patches/racket-zuo-bin-sh.patch")
 7f88dea48720>)
--8<---cut here---end--->8---

Therefore the source data of ’racket-minimal’ is correctly archived.


WDYT to modify ’ruby-sorbet-runtime’ and let ’chromium’ uncovered?


Cheers,
simon