Re: An update on ‘core-updates’

[Janneke Nieuwenhuizen]

Efraim Flashner writes:

Hi,

> On Fri, Jan 12, 2024 at 01:55:47PM +0100, Janneke Nieuwenhuizen wrote:
>> Ludovic Courtès writes:
>> 
>> Building a bare-hurd system on core-updates succeeded "not long ago"
>> (after the glibc+locales patch series I think) but now fails on
>> gcc-cross-sans-libc-i586-pc-gnu-11.4.0
>> 
>> --8<---cut here---start->8---
>> Configuring in i586-pc-gnu/libobjc
>> [..]
>> checking dynamic linker characteristics... configure: error: Link tests are 
>> not allowed after GCC_NO_EXECUTABLES.
>> [..]
>> builder for 
>> `/gnu/store/94lj8490ixpd997m3siaxw5yhd52za6g-gcc-cross-sans-libc-i586-pc-gnu-11.4.0.drv'
>>  failed with exit code 1
>> --8<---cut here---end--->8---
>> 
>> Any ideas what may have happened/changed here?  Hmm, it looks like
>> 
>> d21d596f72ad491937123980e65d3efedc903bd6
>> gnu: gcc: Support objc, objc++ by default.
>> 
>> was probably the problem.  Trying the attached patch, Hurd system not
>> build yet.
>
> you might need ,@(if (target-hurd?)

Yeah, that's the canonical form, but in this case that's not the case.

Luckily this patch is now obsolete as it has been fixed (more) properly in 
commit

bb1c78b0014b80095da31b5e0ff44ca7d847f153
gnu: cross-base: Build cross-compilers with ‘--enable-languages=c,c++’.

(yay)

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: An update on ‘core-updates’

[Janneke Nieuwenhuizen]

Janneke Nieuwenhuizen writes:

Hello,

> Janneke Nieuwenhuizen writes:
>
> Hi!
>
>>> Long story short: I’d like us to freeze and merge the branch ASAP,
>>> notably because the glibc graft on ‘master’ leads to a bad user
>>> experience.  I’m happy with the current state of the branch and wouldn’t
>>> mind postponing remaining upgrades for the next cycle.
>>>
>>> Thoughts?
>>
>> FWIW, I'm all for this.  The longer we wait, the harder it gets?  As
>> soon as everything works, see below...
>
> Hmm, I just found than binutils 2.41 update makes guix system builds
> hang.

Err, you may ignore this; mildly Interestingly, bisecting found this
commit, but power-cycling my build and substitute server (restarted the
daemons several times) made this ghost go away.  The server had not been
rebooted for almost a year, and been upgraded/redeployed about 10 times.

> From 0e1bf5714261de8f25baabca3b826284102b6c40 Mon Sep 17 00:00:00 2001
> Message-ID: 
> <0e1bf5714261de8f25baabca3b826284102b6c40.1705149527.git.jann...@gnu.org>
> From: Janneke Nieuwenhuizen 
> Date: Fri, 12 Jan 2024 13:24:14 +0100
> Subject: [PATCH 1/3] gnu: gcc: Fix building cross compiler for the Hurd.
>
> This is a follow-up to commit
> d21d596f72ad491937123980e65d3efedc903bd6
> gnu: gcc: Support objc, objc++ by default.
>
> * gnu/packages/gcc.scm (gcc-4.7): Only build c,c++ when building for the Hurd.

This patch is now obsolete as it has been fixed (more) properly in commit

bb1c78b0014b80095da31b5e0ff44ca7d847f153
gnu: cross-base: Build cross-compilers with ‘--enable-languages=c,c++’.

(yay)

> From bb99ace974103c1d9d8fda2da19d76cb5edb20c3 Mon Sep 17 00:00:00 2001
> Message-ID: 
> 
> In-Reply-To: 
> <0e1bf5714261de8f25baabca3b826284102b6c40.1705149527.git.jann...@gnu.org>
> References: 
> <0e1bf5714261de8f25baabca3b826284102b6c40.1705149527.git.jann...@gnu.org>
> From: Janneke Nieuwenhuizen 
> Date: Sat, 13 Jan 2024 10:46:21 +0100
> Subject: [PATCH 2/3] gnu: gnumach-headers: Update to v1.8+git20230410.

Pushed to core-updates.

> From 78f3a4661f5357434a3b2cf61cb348a185089890 Mon Sep 17 00:00:00 2001
> Message-ID: 
> <78f3a4661f5357434a3b2cf61cb348a185089890.1705149527.git.jann...@gnu.org>
> In-Reply-To: 
> <0e1bf5714261de8f25baabca3b826284102b6c40.1705149527.git.jann...@gnu.org>
> References: 
> <0e1bf5714261de8f25baabca3b826284102b6c40.1705149527.git.jann...@gnu.org>
> From: Janneke Nieuwenhuizen 
> Date: Sat, 13 Jan 2024 10:52:59 +0100
> Subject: [PATCH 3/3] gnu: hurd-headers: Update to v0.9.git20231217.

Pushed to core-updates.

Also, pushed a patch to have Hurd use glibc-2.28.  With these patches,
I've built all dependencies for a Hurd image, except for guix itself.

I've added an ugly hack to hurd-team

7aa380c5f92029fad6cb999fbb113ec08389a0b1
HACK gnu: guix: Disable guix-cookbook.ko when building for the Hurd.

(building the info fails in the Hurd cross build), but lateron there's
another segfault.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

How to always keep build tree when run guix build.

[Feng Shu]

Hello:

  How to always keep build tree when run guix build, at the moment, I 
use --keep-failed, but it will remove build tree when build success, the
problem is that build success alway not right build success :-), I need
go to build tree to check some thing.

Thanks!


-- 

Re: GUIX days and FOSDEM 2024

[Pjotr Prins]

Guix days has close to 40 participants now - that is the number we can
host in the main room due to fire regulations. Do add yourself if you
intend to join because if we are too many we'll go by this list. Add
the day if it is just for a day.

Looks like next year we need a larger venue :)

Pj.

On Thu, Jan 04, 2024 at 09:49:09PM +, Pjotr Prins wrote:
> Just a quick heads up. Feb 1+2 we are organising Guix days and a devroom at
> FOSDEM (Feb 4).
> 
> https://libreplanet.org/wiki/Group:Guix/FOSDEM2024
> 
> (do add your name if you want to attend - the amount of attendees of
> Guix days is limited to some 40).
> 
> https://fosdem.org/2024/schedule/track/declarative-and-minimalistic-computing/
> 
> If you want to meet with the Guix and Guile hackers this is an event
> you should not miss out on :). And FOSDEM is itself is free and
> amazing. Just look at the Saturday programme:
> 
> https://fosdem.org/2024/schedule/day/saturday/
> 
> There is something for everyone. If you can't make it in person -
> every talk is streamed.
> 
> Looking forward to seeing you!
> 
> Pj.
> 

-- 

Re: Commit Access: Sharlatan Hellseher

[John Kehayias]

On Thu, Jan 11, 2024 at 07:56 PM, Sharlatan Hellseher wrote:

>
> Hi Guix!
>
> I am happy to have been granted commit access and I am ready to help
> review pending issues and prepare queued packages for GNU packages in
> astronomy. I would like to concentrate on the packages covered by the
> Go, Lisp, Python, and Science teams.
>
> I would like to thank the Guix team for allowing me to become a
> committer member. I am looking forward to continuing our collaboration.
>
> If anyone has a good patch review workflow using Emacs, Gnus, and Magit,
> I would appreciate it ;-)
>
> Regards,
> Sharlatan Hellseher (Oleg)
>

Welcome and looking forward to your further Guix contributions!

John

Using the pyproject-build-system

[Troy Figiel]

Hi Guix/Python team,

My fix for python-requests-kerberos was pushed today (thanks Oleg!) and
I thought it would be an appropriate moment to ask about the
pyproject-build-system. In short, is the pyproject-build-system a
preferable default over the python-build-system? The manual states
"experimental", but "encouraged to try it", leaving me wondering which
one to use when.

And in long:

Although not fully PEP 517-compliant according the documentation, the
pyproject-build-system does seem to fall back to setuptools.build_meta
if the pyproject.toml is missing. Contrary to what the name implies to
me, it can therefore also be used for packages with only a setup.py file.

This usually leads to slicker definitions, since quite a few packages
seem to only use pytest as their testing suite and in these cases the
pyproject-build-system does not require an override of the check phase.

Should I therefore always try to use the pyproject-build-system instead
of the python-build-system, or is there some different guideline to
follow?

Best wishes,

Troy

OpenPGP_0xC67C9181B3893FB0.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: An update on ‘core-updates’

[Roman Scherer]

Hello,

if we include the jemalloc patch Efraim is talking about, could we please
also include this one here:

https://issues.guix.gnu.org/68257 (gnu: mesa: Build asahi driver on aarch64)

Btw, is there a way to figure out if the rebuild of jemalloc on aarch64
would affect (also rebuild) mesa?

Thanks, Roman.

On Mon, Jan 15, 2024 at 10:02 AM Efraim Flashner 
wrote:

> On Thu, Jan 11, 2024 at 04:10:14PM +0100, Ludovic Courtès wrote:
> > Hello Guix!
> >
> > Several of us have been fiddling with the ‘core-updates’ branch for a
> > while.  I think there’s now consensus that the branch is really
> > dedicated to core packages and (guix build …) modules, as embodied in
> > the new ‘core-packages’ team¹.
> >
> > We’ve updated GCC 11.x, glibc, binutils, and various packages from (gnu
> > packages base).  Notable exceptions are Coreutils, Findutils, sed, and
> > tar; I tried but that’s a bit more work, notably because their variants
> > in commencement.scm would no longer build because their build scripts
> > use sed patterns not supported by Gash-Utils.
> >
> > Long story short: I’d like us to freeze and merge the branch ASAP,
> > notably because the glibc graft on ‘master’ leads to a bad user
> > experience.  I’m happy with the current state of the branch and wouldn’t
> > mind postponing remaining upgrades for the next cycle.
> >
> > Thoughts?
> >
> > Remaining work includes: checking that cross-compilation targets still
> > work after the recent Binutils updates, checking i586-gnu (GNU/Hurd) and
> > other platforms, and possibly addressing the Gawk non-determinism
> > issue².
> >
> > Currently package subsets are built here:
> >
> >   https://ci.guix.gnu.org/jobset/core-updates
> >   https://guix.bordeaux.inria.fr/jobset/guix-core-updates
> >
> > I don’t think I can commit to coordinating the stabilization effort
> > though as I’m busy with other things this month.  Would anyone like to
> > take the lead on this?
> >
> > Happy updating!
> >
> > Ludo’.
> >
> > ¹ https://issues.guix.gnu.org/67880
> > ² https://issues.guix.gnu.org/68378
>
> There's a patch floating around somewhere to adjust the page size on
> jemalloc on aarch64 to be at least 64k so that people running guix
> software on apple silicon don't have issues.  I think we should add it
> for core-updates so it doesn't get forgotten, I've seen it come up on
> IRC at least once a week.
>
> --
> Efraim Flashner  רנשלפ םירפא
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
>

Re: Guix CLI, thoughts and suggestions

[Carlo Zancanaro]

Hi Ian,

Much of what you've written is fair, and I'm sure that Guix's commands
could be better organised. I'm not really involved in Guix development,
but I think there are two "inconsistencies" that you've mentioned which
can be explained.

On Mon, Jan 15 2024, Ian Eure wrote:
> Some examples of where I think Guix could do better.  This is an
> illustrative list, not an exhaustive one.
>
> Inconsistent organization
> =
>
> Most package-related commands are under `guix package', but many are
> sibling commands.  Examples are `guix size', `guix lint', `guix hash',
> etc.

I think the real inconsistency here is that `guix package' is poorly
named. This command really operates on profiles, and performs operations
(install, remove, list, etc.) on those profiles. Packages are given as
arguments to this command.

The other commands operate on, and show the properties of, packages.
Similarly with `guix build'.

> Inconsistency between verbs and options
> ===

> ... For example, installing a package is `guix package -i foo' rather
> than `guix package install foo', removing is `guix package -r foo'
> rather than `guix package remove foo', and listing installed packages
> is `guix package -I' rather than `guix package installed' (or
> similar).

The specific example of `guix package' might be explained by considering
it as a single transaction to update the profile. The command `guix
package' really says "perform a transaction on the profile", and the
options are the commands in the transaction. Since there can be multiple
commands, and the command names look like package names, they are
provided as options.

This doesn't fully explain the behaviour. In particular the example you
give:

> This means that users can express commands which *seem* like they
> should work, but do not.  For example `guix package -i emacs -r
> emacs-pgtk -I' represents a command to 1) install emacs 2) remove
> emacs-pgtk 3) list installed packages (which would verify the previous
> two operations occurred). ...

seems reasonable to have working within the view of `guix package' as a
transactional operation.

It's also worth noting that there are convenience shortcuts in `guix
install' and `guix remove'.

> It seems like a lot of work to change, and backwards compatibility
> also is an issue.

I see backwards compatibility as the main issue here. There was a lot of
discussion preceding the inclusion of `guix shell', because of the
prospect of breaking existing tutorials/documentation floating around on
the internet. This is an even bigger concern for a more drastic
reorganisation of the CLI.

Carlo

Re: Feedback of the GNU Guix manual

[Christian Miller]

> I care about this.  How can I help?

I don't know.  I would also create patches but don't know if it should
be a huge patch or multiple ones, or maybe even it's own branch.

> What's TTY mode?  M-x tty  reveals nothing for me.

Mode is probably the wrong word.  It basically is just running
"emacsclient --tty".  I sometimes use Emacs in a Linux console, since
I like how it looks (also helps in learning the keybindings and
actually using them, since it forces me to not use the mouse).  I
mentioned it, since it changes how the documentation is rendered.  For
example, there will be no pictures since there is no graphics in a
Linux console.

> I appreciate you taking the time to write them all up.
Thanks.

-- 
Christian Miller

Re: Problems with Emacs vterm

[Christian Miller]

Hello Oleg,

> Both work on my Guix System.  The ‘2.’ works both for a Guix and non
> Guix systems.

Interesting. (directory-tracking) It never did work for me since
several months.  I also created a VM to be sure that it is not my
Emacs config.  Does not work in the VM for me, too.

This is how I tested it.

Use the following file as preset:

--8<---cut here---start->8---
;; This is an operating system configuration generated
;; by the graphical installer.
;;
;; Once installation is complete, you can learn and modify
;; this file to tweak the system configuration, and pass it
;; to the 'guix system reconfigure' command to effect your
;; changes.


;; Indicate which modules to import to access the variables
;; used in this configuration.
(use-modules (gnu))
(use-service-modules desktop networking ssh xorg spice)
(use-package-modules certs gnome)

(operating-system
  (locale "en_US.utf8")
  (timezone "Europe/Berlin")
  (keyboard-layout (keyboard-layout "de"))
  (host-name "gnu")

  ;; The list of user accounts ('root' is implicit).
  (users (cons* (user-account
  (name "test")
  (comment "Test")
  (password (crypt "pw" "$6$abc"))
  (group "users")
  (home-directory "/home/test")
  (supplementary-groups '("wheel" "netdev" "audio" "video")))
%base-user-accounts))

  ;; Packages installed system-wide.  Users can also install packages
  ;; under their own account: use 'guix search KEYWORD' to search
  ;; for packages and 'guix install PACKAGE' to install a package.
  (packages (append (list (specification->package "nss-certs")
  (specification->package "emacs")
  (specification->package "emacs-vterm")) 
%base-packages))

  ;; Below is the list of system services.  To search for available
  ;; services, run 'guix system search KEYWORD' in a terminal.
  (services
   (append (list (service gnome-desktop-service-type)

 (service spice-vdagent-service-type)

 (set-xorg-configuration
  (xorg-configuration
   (keyboard-layout keyboard-layout
   
   (modify-services %desktop-services
(gdm-service-type config =>
  (gdm-configuration
   (inherit config)
   (auto-login? #t)
   (default-user "test"))
  
  ;; Allow resolution of ".local" host names with mDNS
  (name-service-switch %mdns-host-lookup-nss)

  ;; Use sudo without password
  (sudoers-file (plain-file "etc-sudoers-config"
"root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
test ALL=(ALL) NOPASSWD: ALL"))

  (bootloader
   (bootloader-configuration
(bootloader grub-bootloader)
(targets '("/dev/vda"))
(terminal-outputs '(console

  (file-systems (cons (file-system
   (mount-point "/")
   (device "/dev/vda1")
   (type "ext4"))
  %base-file-systems)))
--8<---cut here---end--->8---

$(guix system vm .scm) -m 4096 -smp 2

(in the VM)

1. Start Emacs
2. M-x vterm
3. cd Downloads
4. C-x C-f (find-file): It starts with "~/" instead of the expected
   "~/Downloads/"


--8<---cut here---start->8---
cm@gnu ~$ cat /etc/os-release 
NAME="Guix System"
ID=guix
PRETTY_NAME="Guix System"
LOGO=guix-icon
HOME_URL="https://guix.gnu.org;
DOCUMENTATION_URL="https://guix.gnu.org/en/manual;
SUPPORT_URL="https://guix.gnu.org/en/help;
BUG_REPORT_URL="https://lists.gnu.org/mailman/listinfo/bug-guix;

cm@gnu ~$ guix describe
Generation 6Jan 10 2024 19:26:00(current)
  guix c1fda6c
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: c1fda6cf61d4044d65c694cd309ca88c6b1ed5b7
--8<---cut here---end--->8---

Yes, I use Bash for local and remote.  I currently use GNU Guix System
on revision c1fda6cf61d4044d65c694cd309ca88c6b1ed5b7.

-- 
Christian Miller

Re: Questions about packages because of license and other

[Christian Miller]

Thanks for the feedback.

-- 
Christian Miller

Re: Guix CLI, thoughts and suggestions

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

Hi Ian,

On Mon, Jan 15 2024, Ian Eure wrote:

> What do you all think?

The pain is not yet great enough to make changes.

Also, the interface may have more basic issues. [1]

Kind regards
Felix

[1] https://issues.guix.gnu.org/58908

Guix CLI, thoughts and suggestions

[Ian Eure]

Greetings,

As I’ve been learning Guix, one of the things I’ve found somewhat 
unpleasant is the lack of consistency within the guix CLI tool. 
It feels a bit Git-like, with not much consistency, commands that 
non-obvioulsy perform more than operation, related commands in 
different places in the tree, etc.


Just so you know where I’m coming from: I’ve found that compliex 
CLI tooling benefits from organization and consistency.  The Linux 
ip(8) command is a good example of this kind of organization: to 
add an IP address, you use `ip address add'.  To show address, `ip 
address show', and to remove one `ip address del'.  When options 
are needed, they get added after the verb or branch in the verb 
tree; the final verb may take positional arguments as well as 
--long or -s (short)-form options.


Some examples of where I think Guix could do better.  This is an 
illustrative list, not an exhaustive one.


Inconsistent organization
=

Most package-related commands are under `guix package', but many 
are sibling commands.  Examples are `guix size', `guix lint', 
`guix hash', etc.



Inconsistency between verbs and options
===

Some verbs are bare-word positional arguments, and others are 
flags to related verbs.  IMO, this is the biggest problem, and 
makes it very difficult to find all the things the CLI can do. 
`guix package' is a major offender in this area, as it mixes verbs 
and verb-specific options into the same level.  For example, 
installing a package is `guix package -i foo' rather than `guix 
package install foo', removing is `guix package -r foo' rather 
than `guix package remove foo', and listing installed packages is 
`guix package -I' rather than `guix package installed' (or 
similar).


This means that users can express commands which *seem* like they 
should work, but do not.  For example `guix package -i emacs -r 
emacs-pgtk -I' represents a command to 1) install emacs 2) remove 
emacs-pgtk 3) list installed packages (which would verify the 
previous two operations occurred).  This is a valid command within 
the accepted organization of `guix package', and doesn’t cause an 
error, but doesn’t work: the install and remove steps are ignored. 
A thing I’ve found throughout my career is that designing systems 
so it’s *impossible* to represent unsupported, nonsensical, or 
undefined things is an extremely valuable technique to avoid 
errors and pitfalls.  I think Guix could get a lot of mileage out 
of adopting something similar.


This causes a related problem of making it impossible to know what 
options are valid for what verbs.  Will `guix package --cores=8 -r 
emacs' remove the package while using eight cores of my system? 
Will `guix system -s i686 switch-generation 5' switch me to a 
32-bit version of generation 5?  If verbs are organized better, 
and have their own options, this ambiguity vanishes.



More inconsistency
==

Other parts of guix have the opposite problem: `guix system 
docker-image' probably ought to be an option to `guix system 
image' rather than a separate verb.



Inconsistency between similar commands
==

There are generations of both the system (for GuixSD) and the user 
profile, however, they work differently.  For the system, there’s 
`guix system list-generations' and `guix system 
switch-generation', but for the user profile, you need `guix 
package --list-generations' and `guix package 
--switch-generation=PATTERN'.  Additionally, no help is available 
for either of the system commands: `guix system switch-generations 
--help' gives the same output as `guix system --help' -- no 
description of the supported ways of expressing a generation are 
available.



Flattened verbs
===

Related, the generation-related commands under `guix system' ought 
to be one level deeper: `guix system generation list', `guix 
system generation switch' etc.



Repeated options


Many commands (`guix package', `guix system', `guix build', `guix 
shell') take -L options, to add Guile source to their load-path. 
This probably ought to be an option to guix itself, so you can do 
`guix -L~/src/my-channel build ...'.



Suggestions
===

All commands should be organized into a tree of verbs.

Verbs should have common aliases (`rm' for `remove', etc).

Verbs should be selected by specifying the minimum unambiguous 
substring.  For example `guix sys gen sw' could refer to `guix 
system generation switch'.


Options should be applicable to each level of the tree, ex `guix 
-L~/src/my-channel' would add that load-path, which would be 
visible to any command.  

Requesting help is a verb.  Appending "help" to any level of the 
verb tree should show both options applicable to that verb, and 
its child verbs.  `guix help' would show global options and all 
top-level verbs (package, system, generation, etc); `guix package 
help' would show 

Re: An update on ‘core-updates’

[Roman Scherer]

Sorry, if this mail arrived in multiple parts. I somehow messed
something up in my mail client. :/

Roman Scherer  writes:

> Hello,
>
> if we include the jemalloc patch Efraim is talking about, could we please 
> also include this one here:
>
> https://issues.guix.gnu.org/68257 (gnu: mesa: Build asahi driver on aarch64)
>
> Btw, is there a way to figure out if the rebuild of jemalloc on aarch64 would 
> affect (also rebuild) mesa?
>
> Thanks, Roman.
>
> On Mon, Jan 15, 2024 at 10:02 AM Efraim Flashner  
> wrote:
>
>  On Thu, Jan 11, 2024 at 04:10:14PM +0100, Ludovic Courtès wrote:
>  > Hello Guix!
>  >
>  > Several of us have been fiddling with the ‘core-updates’ branch for a
>  > while.  I think there’s now consensus that the branch is really
>  > dedicated to core packages and (guix build …) modules, as embodied in
>  > the new ‘core-packages’ team¹.
>  >
>  > We’ve updated GCC 11.x, glibc, binutils, and various packages from (gnu
>  > packages base).  Notable exceptions are Coreutils, Findutils, sed, and
>  > tar; I tried but that’s a bit more work, notably because their variants
>  > in commencement.scm would no longer build because their build scripts
>  > use sed patterns not supported by Gash-Utils.
>  >
>  > Long story short: I’d like us to freeze and merge the branch ASAP,
>  > notably because the glibc graft on ‘master’ leads to a bad user
>  > experience.  I’m happy with the current state of the branch and wouldn’t
>  > mind postponing remaining upgrades for the next cycle.
>  >
>  > Thoughts?
>  >
>  > Remaining work includes: checking that cross-compilation targets still
>  > work after the recent Binutils updates, checking i586-gnu (GNU/Hurd) and
>  > other platforms, and possibly addressing the Gawk non-determinism
>  > issue².
>  >
>  > Currently package subsets are built here:
>  >
>  >   https://ci.guix.gnu.org/jobset/core-updates
>  >   https://guix.bordeaux.inria.fr/jobset/guix-core-updates
>  >
>  > I don’t think I can commit to coordinating the stabilization effort
>  > though as I’m busy with other things this month.  Would anyone like to
>  > take the lead on this?
>  >
>  > Happy updating!
>  >
>  > Ludo’.
>  >
>  > ¹ https://issues.guix.gnu.org/67880
>  > ² https://issues.guix.gnu.org/68378
>
>  There's a patch floating around somewhere to adjust the page size on
>  jemalloc on aarch64 to be at least 64k so that people running guix
>  software on apple silicon don't have issues.  I think we should add it
>  for core-updates so it doesn't get forgotten, I've seen it come up on
>  IRC at least once a week.
>
>  --
>  Efraim Flashner  רנשלפ םירפא
>  GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
>  Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Feedback of the GNU Guix cookbook manual

[Matt]

  On Sun, 14 Jan 2024 16:15:57 +0100  Christian Miller  wrote --- 

 > I read the cookbook on revision
 > ee7c9d254117fa470686210ad2ef5e7f1ba4fefc using Emacs in TTY mode.
 >
 > Here are some things I noticed:

Thank you for taking the time to write these up!

--
Matt Trzcinski
Emacs Org contributor (ob-shell)
Learn more about Org mode at https://orgmode.org
Support Org development at https://liberapay.com/org-mode

Re: Feedback of the GNU Guix manual

[Matt]

I care about this.  How can I help?

- Convert the notes into patches?
- Proofread any patches that derive from Christian's efforts?
 
  On Sun, 14 Jan 2024 16:01:58 +0100  Christian Miller  wrote --- 

 > I read through the GNU Guix manual on revision
 > ee7c9d254117fa470686210ad2ef5e7f1ba4fefc with Emacs in TTY mode.

What's TTY mode?  M-x tty  reveals nothing for me.
 
 > As a beginner, the manual was helpful and I learned lot's of stuff.
 > Though it felt heartless.  No consistency and sometimes the structure
 > is confusing (especially the contributing part, since it tries to get
 > GNU Guix System and GNU Guix under one section and it was kinda
 > confusing for me).

Thank you for sharing your experience.  I'm sorry it wasn't more positive.  
I've found it challenging to read as well.

 > It seems that there is no style guide.  Sometimes default values are
 > mentioned and sometimes not.  Also some use uppercase and other use
 > lowercase for type of variable.  There is also Scheme code which is
 > most of the time in the old style notation.  For me as a beginner,
 > this was confusing.

The GNU project has several:

- https://www.gnu.org/prep/standards/html_node/Documentation.html
- https://www.fsf.org/licensing/gnu-press/GNU-Press-styleguide.pdf

 > I will mention lot's of style issues since at that time I did not know
 > it is in such a bad state.

I respectfully disagree that it's in bad taste to mention them.  I find such 
feedback helpful towards correcting the problems you experience.  I appreciate 
you taking the time to write them all up.  It's nice to know someone reads the 
manual! :)

--
Matt Trzcinski
Emacs Org contributor (ob-shell)
Learn more about Org mode at https://orgmode.org
Support Org development at https://liberapay.com/org-mode

Re: %base-packages and default grub theme depend on rust

[kiasoc5]

Hi Vagrant,

On 1/14/24 22:24, Vagrant Cascadian wrote:

So, I stumbled a bit with a fairly recently installed aarch64/arm64
system. The install went fine late December, but then I tried "guix
system reconfigure" a couple days ago, and even though it is a very
simple configuration (based on bare-bones.tmpl with grub-efi)... it
pretty much needed to rebuild about 12 rust versions, as no substitutes
were available on aarch64-linux. *sigh*

I thought I tracked this down to guix-icons depending on librsvg, which
depends on rust... and guix-icons is in %base-packages.

So I dropped use of %base-packages-artwork, which pulls in guix-icons
and used all the various other %base-packages-* stuff explicitly... but
it still wanted to pull in guix-icons/librsvg/rust-* etc ... it just did
so later in the build process... foiled again!

This is because the default grub theme generates a .png from an .svg
... using guile-rsvg, which uses librsvg, which uses rust ...

But this machine just has a serial console, and has no need of a
background image in the grub configuration...

So eventually I figured out how to get a grub theme without a background
image and drop guix-icons from the configuration by avoiding use of
%base-packages-artwork:

(bootloader (bootloader-configuration
+(theme (grub-theme (image #f)))
  (bootloader grub-efi-bootloader)
  (targets '("/boot/efi"

-  (packages (cons screen %base-packages))
+  (packages (append (list screen nss-certs)
+  %base-packages-interactive
+  %base-packages-linux
+  %base-packages-networking
+  %base-packages-utils))

Maybe these is a more elegant way of doing this.


So, the example bare-bones system configuration does seems to have heavy
layers of rust obscuring the bones.

Do we want a really-quite-bare-bones configuration example?
Should guix-icons not actually be in %base-packages?
Can the grub theme be implemented differently without requiring rust?


At least a PNG copy of the SVG could be created ahead of time without 
having to use librsvg to convert it.



This seems like possibly a discussion so far, but I would also be happy
to turn this into a bug report if desired!


Thanks everyone!


live well,
   vagrant

Re: January hybrid Guix London meetup

[Arun Isaac]

Hi all,

Just a gentle reminder for today's meetup! Details below.

Regards,
Arun

> Hi all,
>
> The next Guix London meetup is scheduled for Monday 15th January, 6 pm
> London time (i.e. UTC) onward. Join us in person or online, address and
> link below.
>
> - In person, from 6:00 pm: 20 Farringdon St, EC4A 4AB
> - Online, from 6:10 pm: https://meet.jit.si/london-guix-meetup
> - https://www.meetup.com/guix-london/events/298422197/
>
> If you attend in person, please make sure you RSVP and share your full
> name (or a nickname) so that we can register you at the building's
> reception.
>
> The main part of the meetup will be an introduction to the guix-forge
> project. If you have any Guix or Guile related question or topic, there
> should be time to talk about that too. All welcome! Talk abstract
> follows.
>
> --8<---cut here---start->8---
> # Self-hosting and autonomy using guix-forge
>
> As free software programmers, whether we like it or not, we often host
> our projects on large centralized and proprietary software forges such
> as GitHub. In theory, it is perfectly possible to host our own forges
> using free software such as GitLab, Gitea, etc. But, life is short, and
> setup and maintenance of these services is more work than it seems at
> first.
>
> GNU Guix is well-known as a package manager, for the high quality of its
> packages, and for the strong reproducibility guarantees it
> provides. But, it is much less appreciated for its services, system
> definitions and deployment features. That's such a shame since these
> features can let you summon and dismiss entire systems at will—be they
> bare-metal or virtualized—with nothing but a declarative plain text
> configuration file.
>
> In this talk, Arun will speak about guix-forge, a Guix channel that
> provides Guix services for easy setup and maintenance of a software
> forge. guix-forge uses existing free software such as cgit and/or klaus
> for serving git repositories on the web, laminar and webhook for
> continuous integration, uacme for managing TLS certificates, etc.
> --8<---cut here---end--->8---
>
> QA (on guix-forge) and open discussion (on anything Guix related) after
> the talk.
>
> Guix London has no official ties with the Guix project. We commit to
> promote the project and to always operate with the best intentions; any
> mistake that we might make is due to us, Guix London, not the Guix
> project.
>
> # Code of conduct
>
> We, Guix London's organisers, intend to create an open, friendly, and
> safe environment where people from the most diverse backgrounds can get
> together, learn about, teach, and discuss Guix and related topics in a
> welcoming and constructive way.
>
> To this end, Guix London adheres to the Guix project's official Code of
> Conduct, as published at this link. Please make sure you familiarise
> with the document and that you share its principles, before attending
> our events.
>
> Should you—at any time before, during, or after one of our events— want
> to raise an issue or discuss any CoC-related topic, please do not
> hesitate to reach out to the organisers at the contacts below.
>
> - Arun Isaac, arunis...@systemreboot.net
> - Fabio Natali, m...@fabionatali.com
>
> # Get involved
>
> Should you be interested in becoming a Guix London organiser, please let
> us know. It'd be great to have you onboard. No previous Guix knowledge
> is required. If you're interested (or simply want to know more), do not
> hesitate to reach out to us!
>
> Similarly, if you want to present on any Guix-related topic at one of
> our events, that's also great. We'd love to hear from you.
>
> Cheers!
> Arun

Re: [swh-devel] Call for public review - SWH Nix/GNU Guix stack

[Ludovic Courtès]

Hey Antoine,

"Antoine R. Dumont (@ardumont)"  skribis:

>>> My understanding is that so far these URLs were ignored by the
>>> lister/loader because they didn’t end in *.tar.*.⁰
>
> FWIW, in the "new" lister [1] implementation, there are a bunch of extra
> computations done [1] to try and resolve those situations. It's trying
> to fetch more information from upstream server (e.g. crates urls which
> ends in /download, ...) now. It's probably not exhaustive though.
>
> [1] 
> https://gitlab.softwareheritage.org/swh/devel/swh-lister/-/blob/master/swh/lister/nixguix/lister.py?ref_type=heads
>
>>> I’m sure Simon Tournier (Cc’d) already discussed with others at SWH
>>> how crucial it is for us to be able to query content by nar hash.
>
>> So yeah, we are looking forward to some ExtID interface.  :-)
>
> Yes, and there is an ongoing merge request about the new interface [2]
>
> [2] 
> https://gitlab.softwareheritage.org/swh/devel/swh-web/-/merge_requests/1220

These are both excellent news, thank you!

Ludo’.

Re: Problems with Emacs vterm

[Oleg Pykhalov]

Hello Christian,

Christian Miller  writes:

> I have two problems with vterm.
>
> 1: It does have directory-tracking according to it's manuals.  I also
> looked at the package and the required scripts are present.  But this
> feature does not work for me.
>
> 2: I don't know why but TRAMP is not working with vterm, too.  It
> opens a new buffer that is killed instantly.  This also breaks the
> prompt of newly created vterm buffers for me.

Both work on my Guix System.  The ‘2.’ works both for a Guix and non
Guix systems.
--8<---cut here---start->8---
  $ cat /etc/os-release
  NAME="Guix System"
  ID=guix
  PRETTY_NAME="Guix System"
  LOGO=guix-icon
  HOME_URL="https://guix.gnu.org;
  DOCUMENTATION_URL="https://guix.gnu.org/en/manual;
  SUPPORT_URL="https://guix.gnu.org/en/help;
  BUG_REPORT_URL="https://lists.gnu.org/mailman/listinfo/bug-guix;

  $ guix describe
  guix 8920cf3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 8920cf302c5a2fd457a2629afe24cf4768f1fed7
--8<---cut here---end--->8---

Do you use Bash as a shell for local and remote systems?  What is your
Guix version and is it a Guix System?


Oleg.


signature.asc
Description: PGP signature

RE: [swh-devel] Call for public review - SWH Nix/GNU Guix stack

[Antoine R. Dumont (@ardumont)]

>> My understanding is that so far these URLs were ignored by the
>> lister/loader because they didn’t end in *.tar.*.⁰

FWIW, in the "new" lister [1] implementation, there are a bunch of extra
computations done [1] to try and resolve those situations. It's trying
to fetch more information from upstream server (e.g. crates urls which
ends in /download, ...) now. It's probably not exhaustive though.

[1] 
https://gitlab.softwareheritage.org/swh/devel/swh-lister/-/blob/master/swh/lister/nixguix/lister.py?ref_type=heads

>> I’m sure Simon Tournier (Cc’d) already discussed with others at SWH
>> how crucial it is for us to be able to query content by nar hash.

> So yeah, we are looking forward to some ExtID interface.  :-)

Yes, and there is an ongoing merge request about the new interface [2]

[2] https://gitlab.softwareheritage.org/swh/devel/swh-web/-/merge_requests/1220

Cheers,
tony / Antoine R. Dumont (@ardumont)

-
gpg fingerprint BF00 203D 741A C9D5 46A8 BE07 52E2 E984 0D10 C3B8

Simon TOURNIER  writes:

> Hi,
>
>> The initial NixGuix loader (currently in production) lists and loads
>> origins from a manifest, ignoring the specific origins mentioned above. The
>> new stack will be able to ingest those origins. It will also optionally
>> associate, if present, a NAR hash (specific intrinsic identifier to Nix and
>> Guix) to what’s called an ExtID (SWH side).
>
> Cool!  Thank you.
>
>> Regarding the SWH API reading side of the ExtID though is a work to be done.
>
> In short, currently Guix relies on SWH API for resolving from
> “something” to SWHID, where “something” can be:
>
>  + Git label tag + url
>  + Git commit hash
>  + plain url
>
> Well, the situation is in good shape IMHO – I do not have recent
> numbers, say all is fine for 75% of all Guix packages and for 90% of
> Guix packages coming from some Git repositories – but still, we have
> examples where “Git label tag + url” fails.  For one instance, see [1]
> pointed by [2].
>
> The information – history of history – is there in SWH but it would
> require on Guix side to parse the snapshot information and extract as
> best as possible; trying several SWH snapshots until a match.  Something
> like that.  Chance of success until completion?  Weak. :-)
>
> Moreover, what about the missing 25%?  They are Guix packages coming
> from Mercurial repositories or from Subversion repositories or some
> others.
>
> Back on October 2020, we had discussion [3] for sending a save request
> for packages using SVN checkouts but at the time we did not have a clear
> path for retrieving.  Then on March 2023, maybe an path for retrieving
> with this discussion [4]… but still many hacks are required [5].
>
> Again, the information is there in SWH but it would require on Guix side
> to parse the snapshot information and extract as best as possible;
> trying several SWH snapshots until a match.  Something like that.
> Chance of success until completion?  Weak. :-)
>
> If only one source is missing, all the castle potentially falls down.  
> Somehow,
> a dictionary from ExtID as nar hash to SWHID would help to have the
> castle more robust. :-)
>
> The SWH archive coverage of Guix packages would not be 75% because we, on
> Guix side, are not able to know or retrieve these missing 25%.  Such 
> dictionary
> could reinforce the bridge between reproducible computational environment 
> and archiving, IMHO.
>
> So yeah, we are looking forward to some ExtID interface.  :-)
>
> Cheers,
> simon
>
>
> 1: https://issues.guix.gnu.org/66015#0-lineno53
> 2: 
> https://gitlab.softwareheritage.org/swh/devel/swh-loader-git/-/issues/4751#note_148587
> 3: https://issues.guix.gnu.org/43442#9
> 4: https://sympa.inria.fr/sympa/arc/swh-devel/2023-03/msg9.html
> 5: https://issues.guix.gnu.org/43442#13


signature.asc
Description: PGP signature

Re: An update on ‘core-updates’

[Efraim Flashner]

On Thu, Jan 11, 2024 at 04:10:14PM +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> Several of us have been fiddling with the ‘core-updates’ branch for a
> while.  I think there’s now consensus that the branch is really
> dedicated to core packages and (guix build …) modules, as embodied in
> the new ‘core-packages’ team¹.
> 
> We’ve updated GCC 11.x, glibc, binutils, and various packages from (gnu
> packages base).  Notable exceptions are Coreutils, Findutils, sed, and
> tar; I tried but that’s a bit more work, notably because their variants
> in commencement.scm would no longer build because their build scripts
> use sed patterns not supported by Gash-Utils.
> 
> Long story short: I’d like us to freeze and merge the branch ASAP,
> notably because the glibc graft on ‘master’ leads to a bad user
> experience.  I’m happy with the current state of the branch and wouldn’t
> mind postponing remaining upgrades for the next cycle.
> 
> Thoughts?
> 
> Remaining work includes: checking that cross-compilation targets still
> work after the recent Binutils updates, checking i586-gnu (GNU/Hurd) and
> other platforms, and possibly addressing the Gawk non-determinism
> issue².
> 
> Currently package subsets are built here:
> 
>   https://ci.guix.gnu.org/jobset/core-updates
>   https://guix.bordeaux.inria.fr/jobset/guix-core-updates
> 
> I don’t think I can commit to coordinating the stabilization effort
> though as I’m busy with other things this month.  Would anyone like to
> take the lead on this?
> 
> Happy updating!
> 
> Ludo’.
> 
> ¹ https://issues.guix.gnu.org/67880
> ² https://issues.guix.gnu.org/68378

There's a patch floating around somewhere to adjust the page size on
jemalloc on aarch64 to be at least 64k so that people running guix
software on apple silicon don't have issues.  I think we should add it
for core-updates so it doesn't get forgotten, I've seen it come up on
IRC at least once a week.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: An update on ‘core-updates’

[Efraim Flashner]

On Fri, Jan 12, 2024 at 01:55:47PM +0100, Janneke Nieuwenhuizen wrote:
> Ludovic Courtès writes:
> 
> Hi!
> 
> > We’ve updated GCC 11.x, glibc, binutils, and various packages from (gnu
> > packages base).  Notable exceptions are Coreutils, Findutils, sed, and
> > tar; I tried but that’s a bit more work, notably because their variants
> > in commencement.scm would no longer build because their build scripts
> > use sed patterns not supported by Gash-Utils.
> 
> CC'ing Ekaitz and I'll also relay this to #guix-risc-v.  There's quite
> some work going on in commencement, we can probably incorporate these.
> 
> I think a possible workaround was suggested by Timothy
> 
> https://lists.gnu.org/archive/html/gash-devel/2023-09/msg2.html

The update to stage0-posix, mes-boot and tcc-boot0 are now in
core-updates, and I didn't see any regressions on x86_64/i686.

> > Long story short: I’d like us to freeze and merge the branch ASAP,
> > notably because the glibc graft on ‘master’ leads to a bad user
> > experience.  I’m happy with the current state of the branch and wouldn’t
> > mind postponing remaining upgrades for the next cycle.
> >
> > Thoughts?
> 
> FWIW, I'm all for this.  The longer we wait, the harder it gets?  As
> soon as everything works, see below...

Currently there's an issue on riscv64/ppc64le (and maybe others?) about
zstd not being available for patch-and-repack for make-boot0 and
perl-boot0 (and probably others).

> > Remaining work includes: checking that cross-compilation targets still
> > work after the recent Binutils updates, checking i586-gnu (GNU/Hurd) and
> > other platforms, and possibly addressing the Gawk non-determinism
> > issue².
> 
> Building a bare-hurd system on core-updates succeeded "not long ago"
> (after the glibc+locales patch series I think) but now fails on
> gcc-cross-sans-libc-i586-pc-gnu-11.4.0
> 
> --8<---cut here---start->8---
> Configuring in i586-pc-gnu/libobjc
> [..]
> checking dynamic linker characteristics... configure: error: Link tests are 
> not allowed after GCC_NO_EXECUTABLES.
> [..]
> builder for 
> `/gnu/store/94lj8490ixpd997m3siaxw5yhd52za6g-gcc-cross-sans-libc-i586-pc-gnu-11.4.0.drv'
>  failed with exit code 1
> --8<---cut here---end--->8---
> 
> Any ideas what may have happened/changed here?  Hmm, it looks like
> 
> d21d596f72ad491937123980e65d3efedc903bd6
> gnu: gcc: Support objc, objc++ by default.
> 
> was probably the problem.  Trying the attached patch, Hurd system not
> build yet.

you might need ,@(if (target-hurd?)

my debugging trick is to make the changes and then check the "else" case
to see if it's changed anything there.  Since it looks like you're not
trying to change the flags for other architectures the derivation
shouldn't change if you've gotten the rest of the patch correct :)

> Greetings,
> Janneke
> 

> From 0e1bf5714261de8f25baabca3b826284102b6c40 Mon Sep 17 00:00:00 2001
> Message-ID: 
> <0e1bf5714261de8f25baabca3b826284102b6c40.1705062924.git.jann...@gnu.org>
> From: Janneke Nieuwenhuizen 
> Date: Fri, 12 Jan 2024 13:24:14 +0100
> Subject: [PATCH] gnu: gcc: Fix building cross compiler for the Hurd.
> 
> This is a follow-up to commit
> d21d596f72ad491937123980e65d3efedc903bd6
> gnu: gcc: Support objc, objc++ by default.
> 
> * gnu/packages/gcc.scm (gcc-4.7): Only build c,c++ when building for the Hurd.
> 
> Change-Id: I21ce5dd30d7ab253e6a46173eb674b55d6c01505
> ---
>  gnu/packages/gcc.scm | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
> index ecd88931eb..111b096185 100644
> --- a/gnu/packages/gcc.scm
> +++ b/gnu/packages/gcc.scm
> @@ -15,6 +15,7 @@
>  ;;; Copyright © 2022 Greg Hogan 
>  ;;; Copyright © 2023 Bruno Victal 
>  ;;; Copyright © 2023 Maxim Cournoyer 
> +;;; Copyright © 2024 Janneke Nieuwenhuizen 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -132,9 +133,11 @@ (define-public gcc-4.7
>  ;; contents of (maybe-target-tools).
>  (list 'quasiquote
>(append
> -   '("--enable-plugin"
> - "--enable-languages=c,c++,objc,obj-c++"
> - "--disable-multilib"
> +   '("--enable-plugin")
> +   (if (target-hurd?)
> +   '("--enable-languages=c,c++")
> +   '("--enable-languages=c,c++,objc,obj-c++"))
> +   '("--disable-multilib"
>   "--with-system-zlib"
>  
>   ;; No pre-compiled libstdc++ headers, to save space.
> 
> base-commit: 8e9573784f06ec2af96f9298c6dd434668fb
> -- 
> 2.41.0
> 

> 
> -- 
> Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
> Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351

Re: Commit Access: Sharlatan Hellseher

[Efraim Flashner]

On Fri, Jan 12, 2024 at 05:21:51PM +0100, Clément Lassieur wrote:
> On Thu, Jan 11 2024, Sharlatan Hellseher wrote:
> 
> > Hi Guix!
> >
> > I am happy to have been granted commit access and I am ready to help
> > review pending issues and prepare queued packages for GNU packages in
> > astronomy. I would like to concentrate on the packages covered by the
> > Go, Lisp, Python, and Science teams.
> >
> > I would like to thank the Guix team for allowing me to become a
> > committer member. I am looking forward to continuing our collaboration.
> >
> > If anyone has a good patch review workflow using Emacs, Gnus, and Magit,
> > I would appreciate it ;-)
> 
> Hey, welcome.
> 
> I use this Emacs code to apply patches, with emacs-debbugs and Gnus.
> 
> --8<---cut here---start->8---
> (defun my-apply-patch-or-abort ()
>   (interactive)
>   (my-apply-patch-internal "git am || git am --abort"))
> 
> (defun my-apply-patch ()
>   (interactive)
>   (my-apply-patch-internal "git am --reject"))
> 
> (defun my-apply-patch-or-abort-attachment (n)
>   (interactive "P")
>   (my-apply-patch-attachment-internal "git am || git am --abort" n))
> 
> (defun my-apply-patch-attachment (n)
>   (interactive "P")
>   (my-apply-patch-attachment-internal "git am --reject" n))
> 
> (defun my-apply-patch-attachment-internal (cmd n)
>   "C-u  M-x my-apply-..."
>   (let ((git-dir "~/src/guix"))
> (save-window-excursion
>   (gnus-article-part-wrapper
>n
>(lambda (handle)
>  (let ((default-directory git-dir))
>(mm-pipe-part handle cmd)))
> 
> (defun my-apply-patch-internal (cmd)
>   "Works with a selection of articles."
>   (let ((git-dir "~/src/guix")
> (articles (gnus-summary-work-articles nil)))
> (save-window-excursion
>   (while articles
> (gnus-summary-goto-subject (pop articles))
> (with-current-buffer gnus-summary-buffer
>   (let ((default-directory git-dir))
> (gnus-summary-save-in-pipe cmd))
>   (gnus-article-hide-headers))
> --8<---cut here---end--->8---
> 
> Just my 2 cents, I imagine every person here has their own workflow.

I'm going to suggest 'git am -3' that someone else here suggested to me.
When a patch fails to apply cleanly git will try harder and leave the
failed-to-apply bits inside the code, making it easier to clean-up the
patch than to manually apply it.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Golang check phase skipping some tests?

[Troy Figiel]

Hi everyone,

When looking into the Go build system, I noticed the default check phase
runs (invoke "go" "test" import-path), which only runs the tests in the
root directory of the source. Running the tests in all subdirectories
would require something like this instead:

--8<---cut here---start->8---
(define* (check #:key tests? import-path #:allow-other-keys)
  "Run the tests for the package named by IMPORT-PATH."
  (when tests?
(invoke "go" "test" (string-append import-path "/...")))
  #t)
--8<---cut here---end--->8---

For example, if the -v flag is added (which might be a better default?)
to the check phase of go-github-stretchr-testify, it can be seen that
only `TestImports' runs, none of the tests in assert, http, etc.
However, the source code in these subdirectories is still recursively
copied to out during the install phase.

Is this desired behaviour? I assumed it isn't, because it looks like we
are skipping a lot of tests during the check phase. However, I might
also simply be overlooking something here as I am new to packaging
Golang with Guix.

Best wishes,

Troy

OpenPGP_0xC67C9181B3893FB0.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Proposition to streamline our NAR collection to just zstd-compressed ones

[Efraim Flashner]

On Wed, Jan 10, 2024 at 12:36:51PM +0100, Ludovic Courtès wrote:
> Hello,
> 
> Maxim Cournoyer  skribis:
> 
> > It's been on my head for quite a bit of time (about 2 years, according
> > to [0]), to streamline our offering of cached nars.  Letting go of gzip
> > 2 years ago, along a more aggressive garbage collection policy allowed
> > us to reduce our storage needs by at least 6.5 TiB.  I'm proposing to do
> > the same with our lzip compressed nars, to let go of an additional 3.9
> > TiB:
> 
> Those space savings would be welcome.
> 
> > The above suggests that zstd compressed nars are about 5% larger than
> > the lzip ones, which is not big enough to justify carrying both, in my
> > opinion.  In exchange for a little bit more bandwidth, users would have
> > the nars decompressed much faster with less CPU overhead locally.
> 
> The difference is slightly higher, with lzip being 8% smaller, for a big
> package like ungoogled-chromium or icecat:
> 
> --8<---cut here---start->8---
> $ wget -qO- 
> https://ci.guix.gnu.org/7n95j1zlnwzc44azjs7nj8givnzdfs87.narinfo|grep -B1 
> ^FileSize
> Compression: lzip
> FileSize: 85783483
> --
> Compression: zstd
> FileSize: 92796393
> $ wget -qO- 
> https://ci.guix.gnu.org/prpjnnnhay0alanmkgjh66vfwjlb98kq.narinfo|grep -B1 
> ^FileSize
> Compression: lzip
> FileSize: 295991
> --
> Compression: zstd
> FileSize: 323456
> --8<---cut here---end--->8---
> 
> But yeah, even though adaptive compression selection on the client is a
> minor improvement, whether it warrants the extra space is debatable.

There's another zstd flag that we should probably add: --rsyncable.

--rsyncable: zstd will periodically synchronize the compression state to
make the compressed file more rsync-friendly.  There is a negligible
impact to compression ratio, and a potential impact to compression
speed, perceptible at higher speeds, for example when combining
--rsyncable with many parallel worker threads.  This feature does
not work with --single-thread. You probably don´t want to use it with
long range mode, since it will decrease the effectiveness of the
synchronization points, but your mileage may vary.


> > What do you think?  Should we go ahead and effect the following simple
> > change for the Berlin build farm?
> >
> > modified   hydra/modules/sysadmin/services.scm
> > @@ -683,7 +683,7 @@ to a selected directory.")
> > ;; 
> > 
> > ;; for the compression ratio/decompression speed
> > ;; tradeoffs.
> > -   (compression '(("lzip" 9) ("zstd" 19)))
> > +   (compression '(("zstd" 19)))
> 
> No objection from me, but…
> 
> … an important consideration: zstd support was added in 1.3.0, released
> in May 2021.
> 
> From experience we know that users on foreign distros rarely, if ever,
> upgrade the daemon (on top of that, upgrading the daemon is non-trivial
> to someone who initially installed the Debian package, from what I’ve
> seen, because one needs to fiddle with the .service file to adjust file
> names and the likes), and we can be sure that many are still running an
> old daemon.  We spent a lot of time on user support after gzip
> substitutes had been removed (‘guix substitute’ would just crash) and we
> must avoid that.
> 
> (guix store) emits a warning when connecting to an “old” daemon, but
> only for daemons older than 2018.  We could emit a warning based on
> whether or not “builtin:git-download” is available, but maybe that’s too
> early?

builtin:git-download sometimes bites me on my machines since I don't
upgrade my aarch64/riscv64 installs that often.

Also, 2018 is now about 5 years ago.  It might be a good idea to just
have a rolling YEAR-3 warning that the daemon is getting old and they
might be missing out on features present in newer daemon versions.

> In addition to the warning, we should communicate in advance and make
> sure our instructions on how to upgrade the daemon are accurate and
> clear.
> 
> Thoughts?
> 
> Ludo’.
> 

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature