Re: No default OpenJDK version?

[Vagrant Cascadian]

On 2024-04-16, Julien Lepiller wrote:
> Currently, most java packages use the implicit jdk from the build
> system (ant- or maven-build-system), which is… icedtea@8. We still
> have quite a lot of old packages that don't build with openjdk9, so
> I'm not sure when we can update the default jdk…

But for the packages that explicitly need to pull in openjdk:

  git grep 'openjdk[1-9]' | grep -v define-public | grep -v java.scm | nl
 1  gnu/packages/android.scm:(native-inputs (list openjdk12))
 2  gnu/packages/apl.scm:(inputs (list bash-minimal openjdk18))
 3  gnu/packages/apl.scm:(native-inputs (list `(,openjdk18 "jdk") zip))
 4  gnu/packages/axoloti.scm: `(("openjdk" ,openjdk11 "jdk")
 5  gnu/packages/bioconductor.scm: (list (list openjdk11 "jdk")
 6  gnu/packages/bioinformatics.scm:   #:jdk openjdk11))
 7  gnu/packages/cran.scm:   ("jdk" ,openjdk11 "jdk")
 8  gnu/packages/diffoscope.scm: (list `(,openjdk12 "jdk")
 9  gnu/packages/emacs-xyz.scm:   (list emacs-ecukes emacs-espuds 
emacs-undercover openjdk9))
10  gnu/packages/geo.scm:   openjdk11))
11  gnu/packages/geo.scm:   #:jdk ,openjdk11
12  gnu/packages/groovy.scm:   #:jdk ,openjdk9
13  gnu/packages/groovy.scm:   #:jdk ,openjdk9
14  gnu/packages/groovy.scm:   #:jdk ,openjdk9
15  gnu/packages/groovy.scm:   #:jdk ,openjdk9
16  gnu/packages/groovy.scm:   #:jdk ,openjdk9
17  gnu/packages/gstreamer.scm:   ("openjdk" ,openjdk14)
18  gnu/packages/gstreamer.scm:   ("openjdk:jdk" ,openjdk14 "jdk")
19  gnu/packages/java-compression.scm:   #:jdk ,openjdk9
20  gnu/packages/kodi.scm:   openjdk9 ;like 
groovy
21  gnu/packages/mpi.scm: `(("jdk" ,openjdk11 "jdk")
22  gnu/packages/pep.scm:   `(,openjdk9 "jdk") which yml2))


It is not a crazy number of packages, but in cases like diffoscope and
enjarify, which seem fairly compatible with arbitrary versions, it would
be nice to have an unversioned option to specify?

Maybe I confused things by talking about the "default" version, I guess
I was wondering if it would make sense for an "openjdk-latest" or
"openjdk-lts" or whatever color you want, just as long as it does not
require specifying (and more importantly, keeping track of) the version
of openjdk needed.

live well,
  vagrant


signature.asc
Description: PGP signature

No default OpenJDK version?

[Vagrant Cascadian]

When recently taking a look at diffoscope, I was reminded that there is
effectively no default openjdk version, you have to pick a specific
version for each package definition...

At some time in diffoscope's history, that was openjdk@12.

But there are quite a few versions to choose from:

  guix package -A openjdk | sort -V
  openjdk 9.181   out,jdk,doc gnu/packages/java.scm:869:2
  openjdk 10.46   out,jdk,doc gnu/packages/java.scm:1140:2
  openjdk 11.0.22 out,jdk,doc gnu/packages/java.scm:1218:2
  openjdk 12.33   out,jdk,doc gnu/packages/java.scm:1536:2
  openjdk 13.0.14 out,jdk,doc gnu/packages/java.scm:1576:2
  openjdk 14.0.2  out,jdk,doc gnu/packages/java.scm:1583:2
  openjdk 15.0.10 out,jdk,doc gnu/packages/java.scm:1598:2
  openjdk 16.0.2  out,jdk,doc gnu/packages/java.scm:1617:2
  openjdk 17.0.10 out,jdk,doc gnu/packages/java.scm:1625:2
  openjdk 18.0.2.1out,jdk,doc gnu/packages/java.scm:1642:2
  openjdk 19.0.2  out,jdk,doc gnu/packages/java.scm:1646:2
  openjdk 20.0.2  out,jdk,doc gnu/packages/java.scm:1663:2
  openjdk 21.0.2  out,jdk,doc gnu/packages/java.scm:1667:2

Some packages may only work with a specific era of openjdk, but I
suspect many of the packages in guix just picked whatever version
happened to be present when it was added to guix.

Which makes it hard to know when to update the openjdk dependency...

In the diffoscope case, it seems to have work fine with openjdk@21, with
the only result being that some openjdk-version-specific tests pass and
some are skipped as a one-for-one trade compared to the old openjdk@12.

Alternately, I would be tempted to switch to openjdk@17, which is the
current default in Debian, so has a little more testing behind it...

Though there is a bit of a perverse incentive to stick with the oldest
version that still works, due to openjdk having a very long bootstrap
chain of itself...

And then the question gets to be of diffoscope's dependencies, what
versions of openjdk do they pull in (notably enjarify, which uses
openjdk@12, although that also seems to work ok with openjdk@21)?


Would it make sense to have an openjdk "default" version, so packages
could instead depend on that, and only need to specify a version if
needed for some particular reason? Or is compatibility across openjdk
versions troublesome enough that it really always needs to be handled on
a case-by-case basis?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Bug#1066113: guix: CVE-2024-27297

[Vagrant Cascadian]

Control: severity 1066113 serious

On 2024-03-16, Vagrant Cascadian wrote:
> On 2024-03-15, Salvatore Bonaccorso wrote:
>> On Fri, Mar 15, 2024 at 11:22:52AM -0700, Vagrant Cascadian wrote:
>>> On 2024-03-13, Vagrant Cascadian wrote:
>>> > On 2024-03-12, Vagrant Cascadian wrote:
>>> >> On 2024-03-12, Salvatore Bonaccorso wrote:
>> We had a look, and as per
>> https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/b11b98d89550ce201b0de31401e822c55f4fa2a1
>> we think that it does not require a DSA, but a fix in the upcoming
>> point releases would be good.
>
> Oh my! I am a bit shocked by this honestly ... why is it treated as a
> minor security issue?
>
> I realize Guix is pretty niche in Debian... Nix is perhaps a little more
> widely used...
>
> For anyone with Guix or Nix installed, if I understand correctly, it
> basically allows arbitrarily replacing the source code for anything that
> you might build using Guix or Nix.
>
>
>> So can you submit it for the point releases? (make sure to adjust the
>> target distribution to bullseye respetively bookworm instead of
>> *-security).
>
> I can... although, I would like to make a kind and freindly nudge to
> reconsider a DSA if at all possible. :)

Thinking more on this... I worry that this issue is maybe more serious
than the Debian Security Team realizes?

If issues like this do not warrant a security update in Debian, I feel
the better course of action may be to remove Guix from Debian. I say
this reluctantly, with a heavy heart...

Marking as serious severity to reflect my opinion as the maintainer.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: doc: installation: fix ~root confusion (was Re: doc: Removing much of Binary Installation)

[Vagrant Cascadian]

On 2024-03-11, John Kehayias wrote:
> On Sunday, March 10th, 2024 at 9:58 PM, Vagrant Cascadian 
>  wrote:
>> On 2024-03-10, Suhail Singh wrote:
>> 
>> > Vagrant Cascadian vagr...@debian.org writes:
>> > 
>> > > but "guix pull" does not update the running guix-daemon;
>> > 
>> > Just to be clear, however, if one were to do =sudo -i guix pull=
>> > instead, followed by =systemctl restart guix-daemon.service= it /would/
>> > update the running guix-daemon on Debian, correct? Or is that not the
>> > case?
>> 
>> 
>> No, out of the box guix-daemon is provided by the Debian guix package.
>> 
>
> That means the instructions to update the guix daemon in the manual,
> <https://guix.gnu.org/en/manual/devel/en/html_node/Upgrading-Guix.html>
> is incorrect or doesn't work? Or am I misunderstanding what you meant
> here?

I presume it works fine if you install from the GNU Guix binary tarball,
but not with the Debian guix packages without configuring systemd or
whatever init system to use the guix daemon provided by "guix pull".


> (I know in the past some discussions have come up about older
> guix-daemon on foreign distros, presumably because the packages there
> don't get updated and a user wouldn't think to upgrade guix
> separately? But it seems you are saying you can't upgrade without
> modifying the e.g. systemd service definition? This is also important
> for security updates to guix itself, of course.)

As with other packages in Debian, security updates would, at least in
theory, be uploaded via Debian's security update process, like any other
package in Debian... unless you actually configure it to work like the
instructions above (e.g. add a systemd override).

At least once, I pulled patches from guix upstream into the Debian
package to resolve security issues in the Debian packages.

Just to be absolutely clear here, "guix pull" and whatnot works fine;
that part of upgrading is no different than Guix System or Guix Binary
installation on a foreign distro.


live well,
  vagrant

>> > In other words, on Debian, does the systemd unit reference
>> > =/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon= ?
>> 
>> 
>> But you could provide an override pointing at whatever guix-daemon you
>> want, of course! :)
>> 
>> Once you do that, you may as well remove the Debian packaged guix,
>> although users that have not yet run "guix pull" would need to guess
>> where to find guix, as there will be no guix on PATH.


signature.asc
Description: PGP signature

Re: doc: installation: fix ~root confusion (was Re: doc: Removing much of Binary Installation)

[Vagrant Cascadian]

On 2024-03-10, Suhail Singh wrote:
> Vagrant Cascadian  writes:
>> but "guix pull" does not update the running guix-daemon;
>
> Just to be clear, however, if one were to do =sudo -i guix pull=
> instead, followed by =systemctl restart guix-daemon.service= it /would/
> update the running guix-daemon on Debian, correct?  Or is that not the
> case?

No, out of the box guix-daemon is provided by the Debian guix package.


> In other words, on Debian, does the systemd unit reference
> =/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon= ?

But you could provide an override pointing at whatever guix-daemon you
want, of course! :)

Once you do that, you may as well remove the Debian packaged guix,
although users that have not yet run "guix pull" would need to guess
where to find guix, as there will be no guix on PATH.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: doc: installation: fix ~root confusion (was Re: doc: Removing much of Binary Installation)

[Vagrant Cascadian]

On 2024-03-10, m...@excalamus.com wrote:
>  On Wed, 06 Mar 2024 22:29:23 +0100  Vagrant Cascadian  wrote ---
>> As the one who packaged and maintains guix in Debian...
>
> Thank you for doing this work!
>
>> The guix-daemon should continue to work from the packaged version, although 
>> as guix develops more and more features; how long an old version can be 
>> expected to continue to work remains an open question.
>
> I was under the impression that Guix installed through a foreign package 
> manager is able to update with 'guix pull'.  This is what the current 
> documentation says,
>
> "If you’re running Debian or a derivative such as Ubuntu, you can instead 
> install the package (it might be a version older than 0.0-git but you can 
> update it afterwards by running ‘guix pull’):"
>
> Is this correct?  Does 'guix pull' update Guix when installed through a 
> foreign package manager?

Yes, with the guix packages provided by Debian, generally I would
recommend doing "guix pull" to get current packages (a lot has changed
since guix 1.4!) ... but "guix pull" does not update the running
guix-daemon; that is not the responsibility of "guix pull".

There is also the classic issue of updating PATH and other environment
variables after the first "guix pull" but that is not unique to the
packages from Debian.

A newly pulled guix should continue to remain compatible with older
guix-daemon to some extent, but it may be missing new guix-daemon
features (and possibly security updates, though those are grounds for
getting it fixed in the package), and possibly someday may no longer be
compatible.

live well,
  vagrant


signature.asc
Description: PGP signature

Re: doc: Removing much of Binary Installation (was: Feedback of the GNU Guix manual)

[Vagrant Cascadian]

On 2024-03-06, pelzflorian (Florian Pelz) wrote:
> I don’t feel qualified to judge, but is this the preference?  Arch wiki
> advises against the Arch AUR package: “Therefore, after updating Guix
> once, the AUR advantage really turns into a disadvantage, as there will
> be many unnecessary files in the /usr file tree that are part of the
> Guix AUR package but that are never used by Guix anymore.  Therefore,
> consider using the manual installation.” [0]
>
> The reason of existence for these distribution packages is probably
> similar to the reason why the Binary Installation section exists.

Indeed, after the first guix pull, most of the packaged files are no
longer used.

As the one who packaged and maintains guix in Debian, my main motivation
was and is to have a trust path from debian; mainly not having to
manually verify the signatures of the manual installation method (I
would hazard to guess that the percentage of people who actually do
manually verify signatures is disturbingly small).

The guix-daemon should continue to work from the packaged version,
although as guix develops more and more features; how long an old
version can be expected to continue to work remains an open question.

I cannot say I have done a *great* job at maintaining guix in Debian,
but hopefully at least a passable job. Although there are some annoying
things that probably need to be fixed:

  https://bugs.debian.org/1064748
  a.k.a.
  https://issues.guix.gnu.org/69518

... or backported to Debian stable:

  https://bugs.debian.org/1036304
  https://bugs.debian.org/1038916


I have found a fair number of issues (especially typos!) to fix in
upstream guix as a result of packaging it for Debian, so if nothing
else, it is some quality assurance! :)


live well,
  vagrant


signature.asc
Description: PGP signature

Migrate from p7zip to 7zip?

[Vagrant Cascadian]

I noticed Debian is switching to 7zip from p7zip... my guess is because
7zip is actively maintained, whereas p7zip does not appear to as
actively maintained?

I am not hugely opinionated on the matter, but figured it was worth
mentioning, if anyone wanted to take a stab at it!

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Core-updates coordination and plans

[Vagrant Cascadian]

On 2024-02-27, Andreas Enge wrote:
> Am Mon, Feb 26, 2024 at 07:26:57AM -0800 schrieb Felix Lechner:
>> How about a 48-hour period every month in which commits are permitted
>> even if they cause "world rebuilds"?
>> We could pause the substitute builders during that period. It would get
>> rid of core-updates forever.
>
> a time-based approach sounds like a good idea indeed; if just for things
> like ungrafting, which are considered extremely low risk. It might still
> be good to do it in a separate branch instead of master, and to merge it
> after substitutes are available. Since "guix pull" takes the latest commit
> from the master branch, users could otherwise end up with a world-rebuild
> commit without substitutes.
>
> So maybe we could have a time window, but also discuss and prepare before-
> hand which big changes we would like to push?

Or a similarly "short" time period where commits to master are blocked,
so that substitutes being built for branches-to-be-merged are not
chasing a moving target?


signature.asc
Description: PGP signature

Re: You're invited to the first patch review session!

[Vagrant Cascadian]

On 2024-02-22, Steve George wrote:
> We're going to run some online patch review sessions. The first one is on 
> *Thursday, 7th March* and you can sign-up here:
>
>   https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024

Hoping to make it for some of these, thanks for doing it!

One small point is if people could include the scheduled times in UTC in
addition to "arbitrary" timezones. It is much easier to compare against
UTC (especially because it does not do daylight savings time) if you
don't happen to be in one of the specified timezones. :)

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Guix Days: Patch flow discussion

[Vagrant Cascadian]

On 2024-02-07, Josselin Poiret wrote:
> The fact that you have to wait for Debbugs's response after the first
> mail to get the proper mail to reply to means that we can't automate
> sending whole patchsets, and have to resort to hacks like the CLI `mumi`
> tool uses.  I can't just send a patchset and be done with it, I have to
> wait a couple minutes.

Well, that is a conflict between guix policies/practices and
debbugs.

Debbugs handles sending multiple patches in a single email just fine,
which can be done on the initial submission.

That has downsides with regards to threading, but given all the current
limitations, I wonder if the downsides of having to wait for the initial
bug number to land are worth the cost of having to implement a
user-interface tool (mumi CLI) to workaround it.

That said, the tool already exists... but not everyone is aware of it or
for whatever reason is not necesarily using it.

Are there other downsides to allowing a multiple patches in a single
email?

Ideally the technology would fit whatever practicies guix would like to
implement... but then we have what we have right now.

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Introducing Guix "Features"! (Was: Syntactic Diabetes)

[Vagrant Cascadian]

On 2024-02-02, Attila Lendvai wrote:
>> > for an average unix user a service is a process that is running in the
>> > backgroud, doing stuff mostly without any user interaction. you can
>> > try to argue this away, but i'm afraid that this is the state of
>> > things.
>> 
>> 
>> I don’t think it’s a good idea to aim to satisfy some presumed “average
>> unix user”, because such a user would not be familiar with many concepts
>> introduced by Guix (e.g. “guix shell” or “guix system”).
>
>
> the primary argument was that two, very different abstractions share the same 
> name, and in shared contexts.
>
> it's just icing on the cake that one of the abstractions is nothing like what 
> most users understand by the name 'service'.

In the systemd realm, there are different types of services, I think one
is called "one-shot" which is effectively quite similar to the types of
services guix has... they do something once, and there is no running
daemon. So, for better or worse, guix is not so far from one of the most
widespread and commonly used systems here...

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Core-updates coordination and plans

[Vagrant Cascadian]

On 2024-01-31, Josselin Poiret wrote:
> One conundrum we have for now: glibc 2.38 has a couple of new CVEs, and
> we have three options:
> 1) change glibc to track the 2.38 release branch → world rebuild.
> 2) graft glibc → bad user experience (and we're not supposed to graft
> outside of master).
> 3) switch to 2.39 → world rebuild + possibly more work fixing new build
> failures.
>
> glibc 2.39 should hopefully release tomorrow (01/02/2024)
>
> What is everyone's opinion regarding those?
>
> IMO, option 2 is the one I'd like to avoid, and between 1 and 3 I'd
> ideally prefer 3 but we don't know yet if there is going to be a lot of
> breakage because of that (feels like usually it's toolchain updates, not
> glibc updates that cause them the most).

How about doing *both* 1 and 3 ... more world rebuilding, sure, but it
means we will have the information to make the correct decision about
which to merge into master. It is *possible* that 2.39 is no worse or
even less broken than the 2.38 release, even if it is likely that 2.38
is more well tested... and even if 2.38 ends up being the glibc to merge
to master, things are better positioned to fairly quickly switch to 2.39
once it becomes a more known quantity...

live well,
  vagrant


signature.asc
Description: PGP signature

%base-packages and default grub theme depend on rust

[Vagrant Cascadian]

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?


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


signature.asc
Description: PGP signature

Re: Mixing GPL and non-copyleft code in source files

[Vagrant Cascadian]

On 2024-01-03, Wojtek Kosior via wrote:
> Before getting back to the discussion, please let me ask 1 question.
> Assume I submit a patch series that adds some useful and needed code and
> includes a copyright notice with a promise, like this
>
> ;;; Copyright © 2023 Wojtek Kosior 
> ;;; Wojtek Kosior promises not to sue for violations of this file's license.
>
> Will this weirdness be considered minor enough to tolerate?  I made
> sure the promise line takes below 78 chars.

I am not at all a lawyer, but this seems like an entirely different
license, and at the very least a pragmatic headache.

"I promise not to sue" might even hold up in one court, but not another;
anyone with a modicum of legal caution would reasonably avoid using
software with such terms, and people who are naive enough to use
something with such a baited risk attached are just setting themselves
up for getting legally attacked.

You claim you do not want to threaten anyone with force, but this sort
of licensing clause opens the door wide to all sorts of legal abuses and
threats.

It honestly feels like a sabotage clause to me, even if that is not the
intention.

I would be very concerned about guix accepting such licensing terms.

live well,
  vagrant


signature.asc
Description: PGP signature

Re: [bug#67261] [PATCH 3/3] images: Add orangepi-r1-plus-lts image.

[Vagrant Cascadian]

On 2023-12-03, Efraim Flashner wrote:
> On Fri, Dec 01, 2023 at 11:58:57AM -0800, Vagrant Cascadian wrote:
>> On 2023-11-18, Herman Rimm wrote:
>> > * gnu/local.mk: Register image.
>> > * gnu/system/images/orangepi-r1-plus-lts-rk3328.scm: New file.
>> > * gnu/system/install.scm (orangepi-r1-plus-lts-rk3328-installation-os):
>> >   New variable.
>> 
>> I guess this opens in my mind a larger question of how many images do we
>> want to build out-of-the-box?
>> 
>> Building images for every (ARM) board variant possibly supported in guix
>> might not be sustainable in the long term... this could easily become
>> hundreds of images. How big is each image?
>> 
>> On the other hand, most of the images for a given architecture will
>> share much of the work between them, as most of the individual packages
>> used to build each image are the same.
>> 
>> Not having CI build each and every image is one approach... although
>> then you might not notice when an individual image breaks.
>
> Do we normally build all the images in (gnu system images)? There seems
> to be a large number of different file-system offsets needed for
> different boards.  I suppose we could standardize on a larger size that
> would take care of most of them, but until something is setup to make it
> possible I'm not sure it's possible to support them for Guix System
> without also adding an OS config for the offsets for the root file
> system.

From a quick look, ci.guix.gnu.org builds
pinebook-pro-barebones-raw-image, pine64-barebones-raw-image,
novena-barebones-raw-image ... but I could not find an image for rock64
... so I am not sure what is built by CI out of the box.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [bug#67261] [PATCH 3/3] images: Add orangepi-r1-plus-lts image.

[Vagrant Cascadian]

On 2023-11-18, Herman Rimm wrote:
> * gnu/local.mk: Register image.
> * gnu/system/images/orangepi-r1-plus-lts-rk3328.scm: New file.
> * gnu/system/install.scm (orangepi-r1-plus-lts-rk3328-installation-os):
>   New variable.

I guess this opens in my mind a larger question of how many images do we
want to build out-of-the-box?

Building images for every (ARM) board variant possibly supported in guix
might not be sustainable in the long term... this could easily become
hundreds of images. How big is each image?

On the other hand, most of the images for a given architecture will
share much of the work between them, as most of the individual packages
used to build each image are the same.

Not having CI build each and every image is one approach... although
then you might not notice when an individual image breaks.

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Turning off tests leads to a different store item

[Vagrant Cascadian]

On 2023-11-08, Felix Lechner via wrote:
> On Wed, Nov 08 2023, Maxim Cournoyer wrote:
>> A source tree doesn't produce a derivation.  A derivation is the
>> complete build recipe that captures the source and the package
>> definition, that when built by the daemon produces a store item.
>
> Okay, thanks! Now I'm going to get it right:
>
> The store item that is produced should not change whether build-time
> tests run or not.
>
> It does not make sense (and wastes resources) to rebuild a consuming
> package because build-time tests were enabled or disabled in an input.
>
> The historical version of openssl gave rise to this thread. It did not
> build anymore because the tests no longer worked with the certificates
> shipped in that release (a common problem in TLS libraries). Rebuilding
> openssl without running the tests rendered the rebuild useless because
> it produced a different store item. That should not happen.
>
> Does that make more sense?

I do not really think people are misunderstanding you, more that your
*should* does not align with reality in a way that guix can depend on;
build-time tests *do* affect the build result in some cases.

You can write tests that can be run outside the build environment, like
Debian's autopkgtest, but those may need to actually be different tests
and most upstreams do not provide them yet...

The only way to ensure they do not change the build results is even more
resource-intensive; systematically run the build without tests and then
run the build with tests and compare the store items... assuming the
build is reproducible in the first place, which is not yet 100% reliable
either, unfortunately.


This does seem well outside the context of help-guix (drop from CC in
replies?) at this point, and should perhaps be moved to guix-devel(added
to CC), as it may require significant changes to guix; it is not a
simple matter of helping someone figure out how to do something with
guix.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

On 2023-09-14, Giovanni Biscuolo wrote:
> Maxim Cournoyer  writes:
>> I like the 'Closes: ' trailer idea; it's simple.  However, it'd need to
>> be something added locally, either the user typing it out (unlikely for
>> most contributors) or via some mumi wizardry (it's unlikely that all
>> users will use mumi), which means its usage (and value) would depend on
>> how motivated individuals are to learn these new tricks.
>
> I agree: the ratio, or better usecase, of my /trivial/ (in design, not
> in implementation) initial proposal [1] was to try to help committers
> closing bugs "in one go" by adding proper information to the commit
> message, e.g. "Closes: #N"

To be really, really clear, I am honestly pretty much fine with anything
except:

  Closes:.*#N

or

  Closes:.*N

These are already widely used in Debian, and their use was well
established before guix or even nix were even an inkling of an idea
wriggling around in any human brains.

Staying away from anything that uses any permutation of "close" would be
most appreciated. :)

(There may be some slightly more complicated variants; I think someone
posted a link to the regexp used earlier in the thread)

Since I push the entire relevent portions of upstream guix git history
when pushing changes for guix packaging in Debian, it would be a
significant bother for me if guix started using the same syntax, or
similar enough that a trivial typo might lead to something acting on the
wrong issue tracker...

This is why I think it is important for projects to have some sort of
namespacing for this sort of thing; I am not really opinionated on the
exact details, other than it not conflicting with Debian's terribly
generic entirely un-namespaced historical "Closes:" syntax. :)

live well,
  vagrant


signature.asc
Description: PGP signature

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

On 2023-09-15, Liliana Marie Prikler wrote:
> Am Donnerstag, dem 14.09.2023 um 15:51 -0700 schrieb Vagrant Cascadian:
>> On 2023-09-10, Liliana Marie Prikler wrote:
>> > Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant
>> > Cascadian:
>> > > I am much more comfortable with the "Fixes" convention of:
>> > > 
>> > >   Fixes: https://issues.guix.gnu.org/NNN
>> > I like the idea, but we should also consider the bugs.gnu.org
>> > address
>> > here as well as the convention of putting it into angular
>> > brackets.  In
>> > fact, I might even prefer it if the convention was
>> >   Fixes: Bug description 
>> > where bug description is a (possibly empty) name for the bug such
>> > as "Emacs hangs when I press a key" or something.
>> > 
>> > 
>> > As for when to send it, remember that we already send a bunch of
>> > mails to guix-comm...@gnu.org as our commit hook?  I think it
>> > shouldn't be too hard to search for the fixes line and send it to
>> > debbugs control.
>> 
>> Well, the complication gets to be ... which branch did it land in? in
>> master, it's fairly obvious... you can just mark it as
>> done/closed/etc. I guess with other branches it makes sense to mark
>> it with the "pending" or maybe some more specific usertag
>> "pending-in-BRANCH"?
> I don't think such a distinction is needed in most cases.  In fact, if
> it's about regular bugs, then a graft should likely hit master in case
> that an actual update is needed on another branch.  Other than that,
> it'd be silly to mark bugs specifically for e.g. "emacs-team" as still
> pending on the account of them not having hit master yet.

I guess I do not consider anything done until it lands in the master
branch, but obviously if it is committed in some branch, it is nice to
flag that somehow. "pending" seems appropriate up until it lands in
master.

Maybe marking by team or branch or whatnot is overkill, sure. Though it
would allow you could see at a glance which branch to look in without
diving into the whole history of the issue...

Of course, I will not make terrible loud noises if folks decide
otherwise. :)

live well,
  vagrant


signature.asc
Description: PGP signature

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

On 2023-09-10, Liliana Marie Prikler wrote:
> Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant Cascadian:
>> I am much more comfortable with the "Fixes" convention of:
>> 
>>   Fixes: https://issues.guix.gnu.org/NNN
> I like the idea, but we should also consider the bugs.gnu.org address
> here as well as the convention of putting it into angular brackets.  In
> fact, I might even prefer it if the convention was
>   Fixes: Bug description 
> where bug description is a (possibly empty) name for the bug such as
> "Emacs hangs when I press a key" or something.
>
>
> As for when to send it, remember that we already send a bunch of mails
> to guix-comm...@gnu.org as our commit hook?  I think it shouldn't be
> too hard to search for the fixes line and send it to debbugs control.

Well, the complication gets to be ... which branch did it land in? in
master, it's fairly obvious... you can just mark it as
done/closed/etc. I guess with other branches it makes sense to mark it
with the "pending" or maybe some more specific usertag
"pending-in-BRANCH"?

live well,
  vagrant


signature.asc
Description: PGP signature

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

On 2023-09-13, Maxim Cournoyer wrote:
> Vagrant Cascadian  writes:
>> On 2023-09-09, Maxim Cournoyer wrote:
>>> The Change-Id stays the same unless you manually edit it out of your
>>> commit message when amending / rebasing, so the commit hash may change
>>> while the Change-Id stays the same.  So you can rebase your feature
>>> branch on master and share a v2, whose existing commits will have the
>>> same Change-Ids (newly added commits would get their own Change-Id
>>> trailer).
>>
>> Ok, that makes some sense.
>>
>> Although the majority of bugs in the cleanup work I did were actually
>> filed by someone else entirely... so the Change-Id will not help with
>> those. Not a reason not to implement it, but not consistent with some of
>> the triggers of this thread. :)
>
> I doubt the Change-Id idea would help much closing *bugs* on the
> bug-guix tracker, but I'd expect it to be useful to close already merged
> (but forgotten on the guix-patches tracker) *patches*.

Well, all of the "bugs" I was referring to were submitted patches
tracked at debbugs.gnu.org via the issues.guix.gnu.org
frontend... weather they were submitted via guix-patches@ or bug-guix@
or n...@debbugs.gnu.org... :)

They are all "bugs" to me, though "issues" seems a bit more neutral in
tone and I like it better, but new packages or package updates are just
generally wishlist bugs/issues and not inherrently something broken,
though they may sometimes fix things or be related to fixes...


> The Change-Ids would be added automatically without the user having to
> install anything, so from the time it's deployed we'd have a means to
> identify which patch series were all merged.

Well, they would still have to install the commit hook, or did I miss
something?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Implementing the guix-dameon in Guile

[Vagrant Cascadian]

On 2023-09-13, Christopher Baines wrote:
> I think this has been talked about for a while [1], but I want to make it
> happen. Currently the guix-daemon is still similar to the nix-daemon
> that it was forked from, and is implemented in C++. I think that a Guile
> implementation of the guix-daemon will simplify Guix and better support
> hacking on and around the daemon to add new features and move Guix
> forward.
>
> 1: 
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/ROADMAP.org#n71
...
> Let me know if you've got any comments or questions!

Sounds great!

My only real concern, as someone maintaining guix packages in Debian, is
to make sure that we do not break compatibility with being able to use
an older daemon, as Debian stable/bookworm is still at guix 1.4.x and it
would be nice to not have to force people to manually upgrade the daemon
(e.g. and even if a newer version lands in a future Debian stable
release, in general it will stuck using that version for some years as
well).

I have noticed occasional issues with the Debian packages of guix having
compatibility issues when newer versions of guile-git/libgit2,
guile-ssh/libssh2, etc. get introduced, and wonder if the same would
hold true of a daemon?

In Guix, by design you wouldn't really notice these sorts of problems as
it is always generally built with the current version, but Debian does
rely on ABI compatibility for package upgrades... I might be able to
keep better track of these types of issues in Debian, although various
guile-* modules that depend on C libraries seem to avoid the normal
detection mechanisms to trigger rebuilds in Debian.

That is a bit of a tangent, but it reminded me about that issue...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

On 2023-09-09, Maxim Cournoyer wrote:
> Vagrant Cascadian  writes:
>>> Did you see my message about integrating a commit-hook similar to what
>>> Gerrit uses?  It produces unique ID such as:
>>>
>>> --8<---cut here---start->8---
>>> Change-Id: I9b86781869d80eda347659f0c009b8dfe09bdfd0
>>> --8<---cut here---end--->8---
...
>> That seems like it would only work if the patch was identical, as
>> opposed to a slightly rebased patch on top of newer patches on master?
>>
>> How can you correlate Change-Id to a patch in the tracker?
>
> The Change-Id stays the same unless you manually edit it out of your
> commit message when amending / rebasing, so the commit hash may change
> while the Change-Id stays the same.  So you can rebase your feature
> branch on master and share a v2, whose existing commits will have the
> same Change-Ids (newly added commits would get their own Change-Id
> trailer).

Ok, that makes some sense.

Although the majority of bugs in the cleanup work I did were actually
filed by someone else entirely... so the Change-Id will not help with
those. Not a reason not to implement it, but not consistent with some of
the triggers of this thread. :)

live well,
  vagrant


signature.asc
Description: PGP signature

Re: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

[Vagrant Cascadian]

On 2023-09-11, Simon Tournier wrote:
> On Mon, 11 Sep 2023 at 16:23, Ludovic Courtès  wrote:
>> Note that the patch series adds a hard dependency on Git.
>> This is because the existing ‘git-fetch’ code depends on Git,
>> which is itself motivated by the fact that Git supports
>> shallow clones and libgit2/Guile-Git doesn’t.
...
> Personally, I do not have a strong opinion about the Big Plan™.  I note
> that the introduction of Git as a hard dependency is a slippery slope
> considering the current state of libgit2.  Here, it starts with “git
> clone”, then “git gc” (unsupported by libgit2) is also in the pipes
> (#65720 [1]).

What about making git an optional dependency, and only calling out to
"git gc" if git is available in PATH? Maybe possible also with shallow
clones?

Then you have the best/worst of both worlds! Speaking to the worst, you
have at least two disparate codepaths for a seemingly similar operation,
and that might be annoying...

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Process for reviewing patches as someone without commit access

[Vagrant Cascadian]

On 2023-09-06, Maxim Cournoyer wrote:
> Simon Tournier  writes:
>> On Wed, 06 Sep 2023 at 16:55, Christopher Baines  wrote:
>>
>>> Once we know what tags to use, I can have the QA frontpage do something
>>> similar to the "Mark as moreinfo" links, so it's easy to just click a
>>> button then send the email to change the state of a issue.
>>
>> That’s cool!
>>
>> Well, using emacs-debbugs and then
>>
>> C-u M-x debbugs-gnu-usertags guix-patches RET
>>
>> the list of usertags is:
>>
>> guix-patches  for-core-updates
>> guix-patches  reviewed-looks-good
>>
>> And if instead of guix-patches we consider guix then it reads,
>>
>> guix  build-system
>> guix  cross-compilation
>> guix  for-core-updates
>> guix  looks-good
>> guix  patch
>> guix  plz-work
>> guix  powerpc64le-linux
>> guix  ready-to-review
>> guix  reproducibility
>> guix  reviewed
>> guix  reviewed-looks-good
>> guix  test-tag
>> guix  v1.3.0
>>
>> However, I do not know how to list all the bugs for the package
>> guix-patches that matches the usertag reviewed-looks-good.  Anyway!
>
> Clicking on an entry in the above list shows them; I'm sure we could
> define a procedure to directly show the bugs associated with a usertag,
> which would be useful.
>
>> I think that the usertag ’reviewed’ is a good idea.  That would be a
>> very good start.  Then if it helps, we could add other usertags as
>> reviewed-julia for patches that the Julia team can merge.
>
> +1 for the 'reviewed' usertag (using the 'guix' user).
>
>> Discussing about idea, would it be possible that the QA infrastructure
>> automatically send a message to Debbugs for tagging?  For example, the
>> usertag ’qa-ok’ or whatever other meaningful name. :-)
>
> +1 for that as well, maybe 'qa-passed'.

Overall, I like this!

The only concern is that it is maintaining QA information in multiple
places, the QA service itself, and trying to mirror it to the bug
tracker...

QA might fail with a later patch iterations, so it should also then go
and remove the qa-passed tag? Should it remove the tag when QA is
currently in an unknown state?

live well,
  vagrant


signature.asc
Description: PGP signature

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

On 2023-09-07, Giovanni Biscuolo wrote:
> Hi Maxim and Ludovic,
> Maxim Cournoyer  writes:
>> Giovanni Biscuolo  writes:
..
>>> When I asket I though the best way would be to scan for a string like
>>> "Close #" in the commit message (the committer should add
>>> such a string) but probably this can be avoided: the bug can be closed
>>> when a patch is committed to one of the listed official brances (master,
>>> core-updates, etc.)
>>
>> You mean by simply matching the subject?  Maybe that could work.
>
> Thinking twice maybe it's better to add a "Close: #" to the commit
> message.

So... I maintain the guix package in Debian, and want to make sure
that whatever bug-closing indicator guix upstream uses, does not end up
triggering when I push new upstream versions to salsa.debian.org ... and
start incorrectly marking incorrect bug numbers on bugs.debian.org that
were meant for debbugs.gnu.org.

Currently that is:

  
https://salsa.debian.org/salsa/salsa-webhook/-/blob/997412ad4b1d89fd3227d5409471bdf71abcf863/helpers/bugs.rb#L19

  SCAN_BUGS = 
/Closes:\s+(?:Bug)?#(?:(\d{4,8})\b)(?:,?\s*(?:Bug)?#(?:(\d{4,8})\b))*/i

"Close: #" is a bit nervously close; I could see a stray typo of an
extra "s" triggering the occasional very annoying problem.

I am much more comfortable with the "Fixes" convention of:

  Fixes: https://issues.guix.gnu.org/NNN


So, while I cannot insist here... I can plead a bit... and a namespaced
URL is kind of better in some ways anyways. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

On 2023-09-07, Maxim Cournoyer wrote:
> Felix Lechner  writes:
>> On Thu, Sep 7, 2023 at 4:08 AM Giovanni Biscuolo  wrote:
>>>
>>> close the bugs that are listed in
>>> the commit message
...
> Did you see my message about integrating a commit-hook similar to what
> Gerrit uses?  It produces unique ID such as:
>
> --8<---cut here---start->8---
> Change-Id: I9b86781869d80eda347659f0c009b8dfe09bdfd0
> --8<---cut here---end--->8---
>
> at the bottom (it's a git trailer) of a commit message.  Being unique,
> these could be used to match if a patch on the tracker has been merged
> in the master branch.
>
> Attached is what the hook looks like.  The random 'Change-Id' is
> generated via
>
> --8<---cut here---start->8---
> random=$({ git var GIT_COMMITTER_IDENT ; echo "$refhash" ; cat "$1"; } |
>   git hash-object --stdin)
> --8<---cut here---end--->8---

That seems like it would only work if the patch was identical, as
opposed to a slightly rebased patch on top of newer patches on master?

How can you correlate Change-Id to a patch in the tracker?

Would it break git commit signatures?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [workflow] Triaging issues (was Automatically close bug report when a patch is committed)

[Vagrant Cascadian]

On 2023-09-07, Giovanni Biscuolo wrote:
> Christopher Baines  writes:
>
>> Giovanni Biscuolo  writes:
>
> [...]
>
>>> 20 bugs with messages similar to this one:
>>>
>>>
>>>  rofi-wayland was added in:
>>>
>>>  04b5450ad852735dfa50961d3afc789b2e52b407 gnu: Add rofi-wayland.
>>>
>>>  And updated to a newer version in:
>>>
>>>  19c042ddf80533ba7a615b424dedf9647ca65b0f gnu: rofi-wayland: Update to 
>>> 1.7.5+wayland2.
>>>
>>>  Marking as done.
>>>
>>> (https://yhetil.org/guix/87zg25r0id.fsf@wireframe/)
>>>
>>> IMO we need a way automatically close this kind of bug reports... or am
>>> I missing something?
>>
>> I think the example you give doesn't relate to what you're looking at
>> below (a post-receive hook).
>
> Oh I see, thanks!
>
> This is a complex case (see below), at least not one that can be solved
> by automatically closing bug reports upon commits :-O
>
> Sorry for the confusion I added by pointing out the wrong example, a
> quick look at many bug reports made by Vagrant Cascadian last Fri and
> Sat shows that many (all?) of the closed bug reports was some sort of
> "duplication" of others.  Vagrant please can you tell us?

Yes, I think a fair amount was from "duplicate" patches. From memory, I
would say many, if not most, of the bugs were due to one person
submitting a patch, and someone else independently committing the same
or newer version.

Part of the problem with duplicates may be the difficulty of reviewing a
very long poorly curated list of bugs... before issues.guix.gnu.org was
a thing, it was difficult to actually find prior submissions... and it
is still long enough that it is not easy.


> Probably /triaging/ is one of the most critical bug report management
> issue, it should be addressed properly:
>
> - by finding or developing triage helping tools to automate what is
>   possible
>   
> - by having more people do the (boring) task of triaging bugs
>
> Probably we should consider adding one more contributor "level": the
> triager; the triager is _not_ a reviewer (obviously not a committer),
> even if she could /also/ be a reviewer and/or committer.
>
> The point is that triaging is a (boring) activity that Someone™ should
> perform, sooner or later (as Vagrant did with the bug reports mentioned
> above).

I was definitely in the mood for "let me get some relatively easy, if
boring things done" the other day. :)


> Obviously a contrubutor could (should) also be a self-triager, if she
> wants help making the review process more efficient.

FWIW, I think I used the search:

  https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Apatch

Sorted by date, and searched for the phrase "update" in the subject, as
old bugs proposing to update to a newer version were and are, well,
likely candidates for culling. :)

Other tooling that could further help with the process would be
valuable.


>> There were at least two different issues with patches for adding
>> rofi-wayland [1] and [2].
>>
>> 1: https://issues.guix.gnu.org/53717
>
> This was to add (version "1.7.3+wayland1") and AFAIU was never committed

Right, I marked this (and several others) as done because it was
effectively superseded by newer versions in current guix.

There were sometimes some things that were not merged, and I made
judgement calls on weather they still needed to be, such as a tweak to
the packaging that was maybe only needed to get an older version to
build, but the newer version was building correctly.


>> 2: https://issues.guix.gnu.org/59241
>
> This issue have 2 patches:
>
> [PATCH 1/2] gnu: rofi: Update to 1.7.5.
>
> [PATCH 2/2] gnu: Add rofi-wayland.
>
> A (self-)triager should have noted two problems in that patch set
> submisison:
>
> 1. patch contains two set of unrelated changes (?)
>
> Point 12. of the "check list" in 22.6 Submitting Patches
> https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html 
> says:
>
> --8<---cut here---start->8---
>
> Verify that your patch contains only one set of related changes. Bundling 
> unrelated changes together makes reviewing harder and slower.
>
> Examples of unrelated changes include the addition of several packages, or a 
> package update along with fixes to that package.
>
> --8<---cut here---end--->8---

That is a good reminder, there was at least one bug that seemed like a
collection of "music" packages, and over time more packages were added,
even after the original packages in the bug title were

Re: How can we decrease the cognitive overhead for contributors?

[Vagrant Cascadian]

On 2023-09-06, Liliana Marie Prikler wrote:
> Am Dienstag, dem 05.09.2023 um 19:41 -0400 schrieb brian
>> ‘* foo/bar.scm new-package (inputs): add input’
>> 
>> stuff. I literally can never remember this format, no matter how many
>> times I do it. I'm reasonably sure square brackes go in there some
>> where. It can take me quite a while to put together all that stuff,
>> even with magit's help.
> It's 
>
> * file (variable)[field]{do you need 4 levels?}

Honestly, not knowing the difference between a variable and field and
selector... this comment is of little help to me.

I always get tripped up with phases, modify-phases, etc. as there seem
to be potentially four or more levels deep in some common code
patterns... for example, a recent commit mentioning phases:

commit c14c25b4fb625c2a5b9512618b3eb17ff15f7e71

gnu: go-github-com-tdewolff-minify-v2: Regenerate hash.

* gnu/packages/golang.scm (go-github-com-tdewolff-minify-v2)[#:phases]: Add
phase 'regenerate-hash.
...
diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index 44953d6111..3c486c4121 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -3685,11 +3685,24 @@ (define-public go-github-com-tdewolff-minify-v2
 "0h006wpfkl0ls0skqxblwcanrhmphgq5q0ii26l2ayh7s99cgmy3"
 (build-system go-build-system)
 (arguments
- (list #:import-path "github.com/tdewolff/minify/v2"))
+ (list #:import-path "github.com/tdewolff/minify/v2"
+   #:phases
+   #~(modify-phases %standard-phases
+   (add-after 'unpack 'regenerate-hash
...

Why is it not more like:

* gnu/packages/golang.scm
(go-github-com-tdewolff-minify-v2)[arguments][phases][modify-phases]:
Add 'regenerate-hash.

Honestly, that *seems* ridiculous to me, but I do not understand *why*
based on the comment above or other patterns I have observed in the
wild.

My inclination would be:

(go-github-com-tdewolff-minify-v2)[arguments]: Add phase 'regenerate-hash.

What goes in the square brackets? How many levels deep? Do I put
something in the prose of the comment or in square brackets?

For me, all this is only from observing many commits, submitting a few
patches, getting some good feedback, but really at the end of the day I
am just cargo-culting...

I have been submitting patches, and even pushing commits to guix for
several years now, and it is still quite unclear to me.

I can wing it just fine, and am able to submit imperfect patches and
have patience for reviews and suggestions and have the resources to
respond (at least, most of the time)...

I can see how really not wanting to iterate with N back-and-forth
discussions in review could hinder someone with a less flexible
schedule, especially if there are no other significant changes to the
patch... it could get demotivating.

It is obviously tricky, as sometimes people need back-and-forth
discussion to learn... though maybe they would rather focus their
limited energy learning how to program, a new language (guile), or just
learning how guix works in practice.

For some people, they might just not have the time or emotional energy
and just prefer to keep their changes in their local branch so they can
move on to the next thing that actually is motivating their work,
tinkering, play, etc. or move on to something else entirely which is
more rewarding, such as gardening...

This is not to say there is no value in the current commit message
format norms. Obviously some people have described the value it has for
them...

One value may be contextually dependent and sometimes at odds with other
values.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: How can we decrease the cognitive overhead for contributors?

[Vagrant Cascadian]

On 2023-09-03, Ricardo Wurmus wrote:
> Maxim Cournoyer  writes:
>
>> In the simplest case, it can be as simple as:
>>
>> $ ./pre-inst-env guix refresh -u some-package
>> [build it, try it, fix if needed]
>> $ ./etc/committer.scm
>> $ git send-email
>>
>> Since it's a single patch, there's no jumping through hoops to create
>> the original issue, and the auto-configured git will CC teams people
>> subscribed to the scope of your change (if there are any).
>
> Sadly the not-so-simple case is much more annoying.
>
> I like an email-based workflow, don’t get me wrong.  At the same time
> I’m really not a fan of Debbugs.  It makes simple things more difficult
> than they should be (send a cover letter, wait for your mail to pass the
> anti-spam measures, remember that you wanted to send a couple of
> patches, etc), and no amount of sugar coating (whether that be a
> different frontend like Mumi or a hell of a lot of client-side
> scripting) can overcome this inherent clunkiness.

The only thing clunky about this particular aspect of the workflow
described is the fact that the guix community (maintainers?) have
decided on a one patch per mail policy with a cover letter, rather than
submitting the patches as attachments in the initial mail.

Debbugs may have numerous other ugly warts, but that is not really one
of them, in my opinion.

Changing that one policy (expectation?) would probably remove a
significant portion of the friction many people have with patch
submissions...

That change will likely have have other frictions, but I suspect they
would be much easier to adapt to...


> If only we can find a suitable baby sieve, I’d be happy to see the
> turbid bathwater drained.  If Mumi and Debbugs went down the drain to
> reveal a new hassle-free web/email hybrid patch workflow I’d be
> ecstatic.

I cannot complain about wanting the best of both worlds if the cost is
not too high. :)

For most of my work in Debian, I accept patches via bugs.debian.org (the
*original* debbugs instance, primarily email) or salsa.debian.org (a
gitlab instance, primarily web)...

Sometimes it is a little awkward because specific maintainers prefer one
interface over the other, or only pay attention to one or the
other... but for the most part I find it allows people to use whatever
works best for them...


At the end of the day git allows quite a few workflows, and the
submitters and committers do not even have to use the entirely same
workflow. There is plenty of room to be flexible.

I recently learned about and started using:

  https://git.guix-patches.cbaines.net/git/guix-patches

This allows me to pull the latest (usually!) patch submissions and
fiddle with and chew on offline... in the same way I might work with
most other git-based projects, merging and cherry-picking and doing
unmentionable things to those poor patches, all from the comfort of my
local machine. It suppliments the email workflow quite nicely, in my
opinion.


So, on the other end, if there was a central place where people (ideally
very open) could push patch submissions, so that people could more
easily pull them all at once, that might help alleviate some of the
issue from the other direction...


The fact that Guix code is largely a single git repository is something
I really value, and makes many things much easier... compared to Debian
which has largely one git respository per package, which might be hosted
on arbitrary servers, or maybe some other VCS, or maybe not even any VCS
at all (other than the Debian mirror itself)...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Guix meetup at FOSSY?

[Vagrant Cascadian]

On 2023-07-11, Timothy Sample wrote:
> Vagrant Cascadian  writes:
>> My current best idea is the handful of food carts at pioneer courthouse
>> square
...
> This sounds great, but I just remembered that FOSSY provides lunch!
> Maybe we should roll with that – it would make the timing a little
> easier.
...
> Otherwise, it’s
> probably simpler just to set up a “Guix table” at the regular lunch.

Yeah, that could work too, presuming that it is possible to eat
outside...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Guix meetup at FOSSY?

[Vagrant Cascadian]

On 2023-07-06, Timothy Sample wrote:
> Vagrant Cascadian  writes:
>> On 2023-07-04, Timothy Sample wrote:
>>
>>> What about having a Guix lunch on Friday?
...
>> There are not a lot of things near the venue, but I will look for
>> options that are nearby and/or quick to get to by public transit ... and
>> ideally with outdoor seating or takeaway options.
>
> That sounds fantastic!  Thank you.

My current best idea is the handful of food carts at pioneer courthouse
square, with a few different carts that cater to various dietary needs
and appetites... about 10-15 minutes on the MAX, with stops right at
both endpoints!

Presuming nobody wants to miss any talks, looks like Friday lunch is
from 12:30 to 2pm... so that should leave roughly a short hour to hang
out and chat and whatnot, more if we coordinate transit times. :)

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Guidelines for pre-trained ML model weight binaries (Was re: Where should we put machine learning model parameters?)

[Vagrant Cascadian]

On 2023-07-04, zamfofex wrote:
>> On 07/03/2023 6:39 AM -03 Simon Tournier  wrote:
>> 
>> Well, I do not see any difference between pre-trained weights and icons
>> or sound or good fitted-parameters (e.g., the package
>> python-scikit-learn has a lot ;-)).  As I said elsewhere, I do not see
>> the difference between pre-trained neural network weights and genomic
>> references (e.g., the package r-bsgenome-hsapiens-1000genomes-hs37d5).
>
> I feel like, although this might (arguably) not be the case for
> leela-zero nor Lc0 specifically, for certain machine learning
> projects, a pretrained network can affect the program’s behavior so
> deeply that it might be considered a program itself! Such networks
> usually approximate an arbitrary function. The more complex the model
> is, the more complex the behavior of this function can be, and thus
> the closer to being an arbitrary program it is.
>
> But this “program” has no source code, it is effectively created in
> this binary form that is difficult to analyse.
>
> In any case, I feel like the issue Ludovic was talking about “user
> autonomy” is fairly relevant (as I understand it). For icons, images,
> and other similar kinds of assets, it is easy enough for the user to
> replace them, or create their own if they want. But for pretrained
> networks, even if they are under a free license, the user might not be
> able to easily create their own network that suits their purposes.
>
> For example, for an image recognition software, there might be data
> provided by the maintainers of the program that is able to recognise a
> specific set of objects in input images, but the user might want to
> use it to recognise a different kind of object. If it is too costly
> for the user to train a new network for their purposes (in terms of
> hardware and time required), the user is effectively entirely bound by
> the decisions of the maintainers of the software, and they can’t
> change it to suit their purposes.

For a more concrete example, with facial reconition in particular, many
models are quite good at recognition of faces of people of predominantly
white european descent, and not very good with people of other
backgrounds, in particular with darker skin. The models frequently
reflect the blatant and subtle biases of the society in which they are
created, and the creators who develop the models. This can have
disasterous consequences when using these models without that
understanding... (or even if you do understand the general biases!)

This seems like a significant issue for user freedom; with source code,
you can at least in theory examine the biases of the software you are
using.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Guix meetup at FOSSY?

[Vagrant Cascadian]

On 2023-07-04, Timothy Sample wrote:
> Vagrant Cascadian  writes:
>> On 2023-06-29, Timothy Sample wrote:
>>> The first FOSSY (Free and Open Source [Software] Yearly) conference
>>> is coming up in two weeks!  It’s being hosted in Portland, OR by the
>>> Software Freedom Conservancy.
>>>
>>> Why don’t we plan a little Guix meetup?
>>
>> Sounds great!
>
> Well, I was waiting to hear from more folks, but maybe not that many of
> us are going to FOSSY.  Either way, I still think we should plan
> something.
>
> What about having a Guix lunch on Friday?  I don’t really have strong
> feelings, but I thought I’d propose something concrete to get things
> going.  I’ve never been to Portland, so I don’t have thoughts about
> where to meet.  Do you know the city at all?

I have a couple decades of experience in Portland... :)

There are not a lot of things near the venue, but I will look for
options that are nearby and/or quick to get to by public transit ... and
ideally with outdoor seating or takeaway options.

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Guix meetup at FOSSY?

[Vagrant Cascadian]

On 2023-06-29, Timothy Sample wrote:
> The first FOSSY (Free and Open Source Yearly) conference is coming up in
> two weeks!  It’s being hosted in Portland, OR by the Software Freedom
> Conservancy.
>
> I was looking over the schedule and I spotted a few familiar names from
> the Guix community.  Why don’t we plan a little Guix meetup?  It could
> be as simple as a Guix luncheon or we could try to find time for some
> sort of hackathon (though it’s getting to be short notice for that...).
> Let’s take this opportunity to bring some Guixers together in North
> America for a change!
>
> Who’s in?

Sounds great!

Will present a talk Sunday in which I will definitely be mentioning the
Guix bootstrapping work!

  Breaking the Chains of Trusting Trust: Reproducible Builds and More!
  https://2023.fossy.us/schedule/presentation/118/

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Maybe a way to get a few more developpers to work on Guix ?

[Vagrant Cascadian]

On 2023-06-24, Nicolas Graves via "Development of GNU Guix and the GNU System 
distribution." wrote:
> On 2023-06-24 13:08, Csepp wrote:
>> Nicolas Graves via "Development of GNU Guix and the GNU System 
>> distribution."  writes:
>> IMHO LLMs for Guix are so damn not worth the effort.  It will not fix
>> any of the actual issues with Guix, like the huge performance gap
>> between it and traditional package managers.
>
> I've also opened another discussion on the subject on guix-devel
> recently. Do you have any benchmark material to back this up?

Well, I just ran "apt update" on Debian, and it took approximately 7
seconds, which was mostly spent downloading moderately sized files from
Debian mirrors (~1MB).

A corresponding "guix pull" took 299 seconds, downloading at least 8MB
(from a quick eyeball calculation as guix does not summarize the results
for me), and compiling all the various guix-*.drv that make up guix
pull. The vast majority of the time was spent compiling
derivations. This was also using a local copy of guix.git, so having to
update guix.git over the network would take even longer... (and it did
even spend a fair amount of time copying from the local guix.git on a
fast NVMe device)

Obviously, guix pull is doing a lot more, but it is ... doing a lot
more!

"apt install hello" (~2.3 seconds) and "guix install hello" (~1.5
seconds) were actually in a similar ballpark, which honestly surprised
me. Guix is much faster with "guix remove hello" ... although arguably
"guix remove hello && guix gc --delete $(guix build hello)" would be a
more similar operation, and although I did not time it, it was
reasonably fast, too.

So, presuming substitutes are available, the main slowness with guix
seems to be guix pull?

I did not test "guix system reconfigure" ... but in a way, that may be a
more real comparison than "guix install" ... although we are starting to
get into fundemental differences between apt and guix here.

The other big factor in my mind is that even with a single generation of
guix with nothing for guix gc to do, there may be multiple copies of
some libraries at various versions left around in the store, which is
probably not terribly space efficient... there are usually reasons for
this (e.g. bootstrapping from a tiny seed, yay!) but nevertheless, those
reasons have some cost (and benefits!).


live well,
  vagrant


signature.asc
Description: PGP signature

Re: rust-build-system from antioxidant

[Vagrant Cascadian]

On 2023-06-11, Maxim Cournoyer wrote:
> Maxime Devos  writes:
>> Op 02-06-2023 om 20:02 schreef Nicolas Graves:
>>> A few months ago, Maxime Devos worked on a new rust-build-system to
>>> handle a few issues we were experiencing with cargo (see discussions on
>>> antioxidant in guix-devel).
>>> A month ago, we discussed about the possibility of the integration
>>> in
>>> core guix, and the required steps. Maxime and I had a different
>>> approach. Maxime highlighted the possibility to make a smooth transition
>>> but once that would require many gradual changes and deprecation. My
>>> approach was that since we'll have to eventually migrate all packages to
>>> rust-build-system, and since we can freeze all former rust packages in
>>> an archive channel, I would be clearer to make the transition at once.
>>> [...]
>>
>> Actually, I started out with the non-gradual approach, but that was
>> overruled by Ludo', IIRC.
>
> Did you perhaps meant to say that it was disagreed with, or at worst
> "blocked by"?  There should not be a notion of 'overruling' in our
> contribution processes (unless the Guix co-maintainers have to step in
> as a last resort) if all participants strive to build consensus, as
> mentioned in info '(guix) Commit Access':
>
>It is expected from all contributors, and even more so from committers,
>to help build consensus and make decisions based on consensus.  To learn
>what consensus decision making means and understand its finer details,
>you are encouraged to read
>.
>
> I thought I knew what consensus meant myself, but the above link helped
> me to re-frame a few things in a way that is more conducive to building
> consensus.

A possible reframing that might be relevent here too that is maybe not
captured in the seedsforchange link referenced...

In a consensus decision (formal or informal), it is often really
valuable to not get caught up in "so-and-so is blocking X, Y, Z", but
rather more "this issue so-and-so raised is blocking X, Y, Z" or even
"this issue is blocking X, Y, Z". It is a perhaps subtle distinction,
but an important one, as I think it can refocus on a problem-solving
approach rather than finger-pointing-and-blaming approach.

That said, I definitely get the impression the Guix community practices
a very informal ad-hoc form of consensus, which ... while very flexible,
misses many of the strongest benefits of consensus (notably, clarity of
when a decision is actually reached and the next steps to move forward
with it).

A quick attempt at condensing a (more) formal consensus decision making
process boils down to:

* describe a situation, issue, proposal, etc.
* clarify understanding of the above (this step unfortunately
  may get skipped as people are very eagre to...)
* raise concerns
* address concerns (as a distinct step from raising concerns)
(iterate and repeat above steps as necessary)
* call for a decision (all concerns ideally resolved or mostly so.. ?)
* record decision (noting outstanding concerns if any)

I am not suggesting that a more formal process is even appropriate to
guix patch review...

Obviously, with the asyncronous nature of, say, a mailing list
discussion, these things do not necessarily happen in a structured
sequential way, though possibly being aware of the "ideal" formal
process, people can informally attempt to approximate it.

I do want to point out that informal processes are more prone to falling
into difficult patterns (e.g. defaulting to hierarchy or other power
dynamics), at least with the social aspects... I think this is a
collaborative project, so everything kind of has a social component!

We all fall down sometimes or lapse into old habits now and then, but
even if there is no formalized clarity of process, it is helpful to at
least reach towards the spirit of consensus building...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Do substitutes download slowly for you? / Speeding up substitute delivery/mirrors

[Vagrant Cascadian]

On 2023-05-25, Christopher Baines wrote:
> France:wget 
> https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
> US:wget 
> https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
> Singapore: wget 
> https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0

Thanks for revisiting this!


> So please share the output from wget and if you're comfortable doing so,
> the rough real world location of where the computer doing the
> downloading is.

Ok, sitting in Portland, Oregon, USA, with native IPv4 and IPv6 over a
wireguard VPN routed via Freemont, California, USA... I tested both IPv4
and IPv6 for those that have IPv6 (US mirror only has IPv4). There is
constant internet activity from other machines on the local network, so
a lot of uncontrolled variables...

The results seem to be all over the place, with the best speed result
france (IPv4), the second best singapore(IPv6), the worst singapore
(IPv4) and second worst the US mirror (IPv4), somewhat surprisingly.

Maybe fetching the same content over IPv4 followed up by IPv6 warmed up
the disk cache on the server side... but clearly not consistently.

My VPN is hosted somewhere with much better internet connectivity, so
maybe wireguard manages to queue packets and send them more efficiently
for the IPv6 connections... sometimes?


--2023-05-25 07:55:21--  
https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)... 185.233.100.56
Connecting to bordeaux.guix.gnu.org 
(bordeaux.guix.gnu.org)|185.233.100.56|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 208615205 (199M) [text/plain]
Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0’

078vr3r8mn3yrwzwxw64hmcyshic9p3q 
100%[==>] 198.95M  
1.45MB/sin 56s

2023-05-25 07:56:17 (3.56 MB/s) - 
‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0’ saved [208615205/208615205]

--2023-05-25 07:56:17--  
https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)... 2a0c:e300::58
Connecting to bordeaux.guix.gnu.org 
(bordeaux.guix.gnu.org)|2a0c:e300::58|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 208615205 (199M) [text/plain]
Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.1’

078vr3r8mn3yrwzwxw64hmcyshic9p3q 
100%[==>] 198.95M  
2.61MB/sin 2m 12s

2023-05-25 07:58:30 (1.51 MB/s) - 
‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.1’ saved 
[208615205/208615205]

bordeaux-us-east-mirror.cbaines.net has address 5.161.49.48
--2023-05-25 07:58:30--  
https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
Resolving bordeaux-us-east-mirror.cbaines.net 
(bordeaux-us-east-mirror.cbaines.net)... 5.161.49.48
Connecting to bordeaux-us-east-mirror.cbaines.net 
(bordeaux-us-east-mirror.cbaines.net)|5.161.49.48|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 208615205 (199M) [text/plain]
Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.2’

078vr3r8mn3yrwzwxw64hmcyshic9p3q 
100%[==>] 198.95M  
3.60MB/sin 2m 39s

2023-05-25 08:01:11 (1.25 MB/s) - 
‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.2’ saved 
[208615205/208615205]

bordeaux-singapore-mirror.cbaines.net has address 64.176.80.78
bordeaux-singapore-mirror.cbaines.net has IPv6 address 
2401:c080:1400:71df:5400:4ff:fe73:757d
--2023-05-25 08:01:11--  
https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
Resolving bordeaux-singapore-mirror.cbaines.net 
(bordeaux-singapore-mirror.cbaines.net)... 64.176.80.78
Connecting to bordeaux-singapore-mirror.cbaines.net 
(bordeaux-singapore-mirror.cbaines.net)|64.176.80.78|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 208615205 (199M) [text/plain]
Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.3’

078vr3r8mn3yrwzwxw64hmcyshic9p3q 
100%[==>] 198.95M  
1.51MB/sin 3m 0s

2023-05-25 08:04:12 (1.11 MB/s) - 
‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.3’ saved 
[208615205/208615205]

--2023-05-25 08:04:12--  
https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
Resolving bordeaux-singapore-mirror.cbaines.net 
(bordeaux-singapore-mirror.cbaines.net)... 
2401:c080:1400:71df:5400:4ff:fe73:757d
Connecting to bordeaux-singapore-mirror.cbaines.net 
(bordeaux-singapore-mirror.cbaines.net)|2401:c080:1400:71df:5400:4ff:fe73:757d|:443...
 connected.
HTTP request sent, awaiting 

Re: Should commit signing always be required for local work? [was Re: bug#63261: Recent changes to git config cause errors for non-committers]

[Vagrant Cascadian]

On 2023-05-24, Felix Lechner via "Development of GNU Guix and the GNU System 
distribution." wrote:
> On Wed, May 24, 2023 at 2:01 PM Vagrant Cascadian  wrote:
>>
>> Please revert ASAP.
>
> I am not affected, but if I understood Maxim's message from 5/18
> correctly, the signature requirement was already reverted:
>
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=03b453cfe54756bcec6b7c7dfaf71566d84c7a75

True! Figured this out, but wow it was circuitous!

So, the very non-obvious behavior was triggered by using git worktrees
with a mix of updated and not very updated checkouts...

So I have ~/src/guix and a ~/src/guix-workspace which is a worktree from
~/src/guix...

When I ran "./configure && ./bootstrap ... && make" from
~/src/guix-workspace it installed a rule in ~/src/guix/.git/config:

  [include]
  path = ../etc/git/gitconfig

So there was no obvious entry for [commit] in the configuration
file... so on a glance I missed that. Manually adding:

  [commit]
  gpgsign=false

Did work around the problem.

My initial check for ~/src/guix-workspace/.git/config was wrong, as it
was a worktree and .git is a file... so it obviously did not show any
configuration at a non-resolvable path.

Also updating the git checkout at ~/src/guix fixed the issue, even
though I was *working* from ~/src/guix-workspace and my working
directory etc/git/gitconfig had the fix...

Having an [include] entry pointing to files that were not in my working
directory from some arbitrary checkout (I will reiterate my working
directory actually *did* have the fix!) kind of broke my mind a bit.

I get it now. I think. :)

This is not the first time I have been burned by using worktrees, but it
was certainly the most convoluted!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Should commit signing always be required for local work? [was Re: bug#63261: Recent changes to git config cause errors for non-committers]

[Vagrant Cascadian]

On 2023-05-19, Simon Tournier wrote:
> On ven., 19 mai 2023 at 11:34, Josselin Poiret  wrote:
>> I'm curious Leo, in general (not Guix because we have a pre-push hook),
>> how do you make sure you always publish signed commits?  I don't want to
>> put unsigned commits anywhere except locally, but it feels like I might
>> just forget to sign them before pushing.
>
> Well, I am not Leo. :-) Maybe I misunderstand your question but usually
> my file ~/.gitconfig contains my default; say always sign.  Then
> locally, for some project [1], I set other options with the local file
> .git/config of the repository.
>
> And for the ones I do not want to sign locally but I will push signed, I
> have pre-push hooks.  Note, in practise, I do not have such
> configuration. :-)

This is basically a show-stopper for me working on guix right now. I
intentionally do not have access to my openpgp key on Guix System
machines. This completely breaks my workflow.

Neither changing ~/.gitconfig not .git/config in the working repository
seems to work around this.

I think the case can be made that not requiring signatures will actually
prevent unintentional changes from getting pushed to the archive, as the
server-side hooks will prevent unsigned changes from landing in the
repository... this is why I prefer to leave my local work-in-progress
changes unsigned. I only sign things I am confident I might want to
push.

Please revert ASAP.

live well,
  vagrant


signature.asc
Description: PGP signature

tracking /etc/profile.d/*guix.sh in downstream distributions

[Vagrant Cascadian]

Philip McGrath recently pointed out that the /etc/profile.d/guix.sh
snippet had not been updating in the Guix packaging for Debian:

  https://bugs.debian.org/1036304

(and as bonus complication, was also renamed to zzz-guix.sh)

The reason I never noticed before is because it is actually a manual
process, with this script embedded in the sys_create_init_profile()
function of etc/guix-install.sh ... and thus easy to miss when updating
packaging.

What would be the impact of separating the /etc/profile.d/zzz-guix.sh
into a separate file upstream? Would guix-install.sh need to be adjusted
to guix-install.sh.in so as to embed the contents of this file?

Alternately, maybe guix-install.sh could be updated to optionally output
or generate the zzz-guix.sh file either by passing commandline arguments
or some other conditional mechanism?

For the short term, I will try to update this manually, but would love
to see a longer term option for future releases!

I am somewhat hoping updating /etc/profile.d/zzz-guix.sh would also fix:

  https://bugs.debian.org/988260


live well,
  vagrant


signature.asc
Description: PGP signature

Trailing whitespace in /etc/guix/acl

[Vagrant Cascadian]

I've noticed there is some trailing whitespace in /etc/guix/acl ... some
of it comes from the keys in etc/substitutes/ci.guix.gnu.org.pub ... but
some of it comes from whatever code assembles /etc/guix/acl (or rather,
whatever the symlink points to in /gnu/store).

I noticed this by trying to add the bordeaux substitute server for the
Debian package, and swear in the past I was able to do it
bit-for-bit-identical... but now with the inconsistent whitespace
differences, while they do not make it impossible, make it needlessly
more difficult than it needs to be, having to match the extraneous
whitespace exactly...

I have not figured out where in the code to look for all this stray
whitespace... maybe someone could take a peek? Maybe the lazy approach
might be to strip all trailing whitespace from the file after generating
it?

Thanks!

live well,
  vagrant


signature.asc
Description: PGP signature

python-ledgerblue as input for electrum? (was: Core-updates, the last metres)

[Vagrant Cascadian]

On 2023-04-23, Guillaume Le Vaillant wrote:
> Here are a few leaf packages that don't build because of some
> failing dependencies:
>  - blender is blocked by opencolorio
>  - electrum is blocked by python-ledgerblue

Hrm this is kind of an aisde, but python-ledgerblue is a plugin for
electrum to support specific hardware, which makes me wonder why it is
in one of the inputs for electrum at all...

There is at least one other, python-btchip-python; electron-cash has
similar inputs, python-keepkey and python-trezor.

My understanding is optional plugins in general should not be in inputs
for packages; people should add the plugins to their profile or
manifest, etc. for the hardware they plan to use...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: PSA for LUKS users

[Vagrant Cascadian]

On 2023-04-19, Felix Lechner via wrote:
> Given the broad popularity of LUKS full-disk encryption among our
> fellow Guix users, I thought the community might appreciate reading
> about potentially weak key-derivation functions in older LUKS
> installations. [1]
>
> The article even offers fixes, although I cannot say whether your
> system will boot after you follow the steps since I do not use LUKS
> personally. Stay safe!
...
> [1] https://mjg59.dreamwidth.org/66429.html

In short, those instructions will almost certainly break Guix System!

While recent grub2 finally has limited support for luks2, it only
supports the weaker KDF (key derivation function) (PBKDF2?), as I
understand it, though would be happy to be proven wrong!

Because Guix System does not yet support a separate /boot partition,
this means if you want "full-disk encryption" you are limited to weak
KDF for the whole filesystem, instead of just a weak /boot partition
(e.g. either luks1, luks2 with weaker pbkdf2, or entirely
unencrypted). There is a bug about being able to use a split /boot
partition:

  https://issues.guix.gnu.org/48172

Alternately, you could probably get a weaker encrypted rootfs (using
luks1 or luks2+PBKDF) and still have a state-of-the-art luks2+argon2id
partition for /home. Maybe if you were adventurous /var/guix, which
might allow detecting a compromise with "guix gc" which contains the
checksums of files in /gnu/store?

With both the split /boot approach or the weaker rootfs with stronger
/home partition, there is some risk of a (admittedly very sophisticated
and still probably quite expensive) evil maid attack.

  https://en.wikipedia.org/wiki/Evil_maid_attack


Well... fun times, folks!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Time travel accident

[Vagrant Cascadian]

On 2023-04-17, Simon Tournier wrote:
> On lun., 17 avril 2023 at 15:32, Ludovic Courtès  wrote:
>
>> My plan is to write a service that makes it easy to offload a build to a
>> VM that runs with a different time (“in the past”) or something along
>> these lines to mitigate the problem.
>
> Do you mean “in the future” instead?  We need to know if the package
> will still build with a different time from the future, no?

I can see "in the past" being useful to handle builds with time-bombs
that already slipped through the cracks, and "in the future" to detect
these time-bombs while there is still time to fix them...


> Wording aside :-) What do Reproducible Builds for that?  Because
> time-bomb seems similar as timestamp…

At least for https://tests.reproducible-builds.org/debian on
amd64/x86_64, I think one of the builds runs approximately 1 year, 1
month and 1 day in the future (+397 days?), which pretty much maximizes
the chance of a difference in year, month or day, while sommewhat
minimizing detection of time bombs...

For detecting time-bombs, I would guess you want to test even further
into the future, maybe 5-10 years or so. Much longer, and you are
getting pretty close to 2038, which is an extra-special set of timebombs
that will need to be addressed at some point!

If guix someday has a long-term support release model, catching these
sorts of time-bombs as early as possible becomes even more important,
though with the current release model of once or twice a year or so, it
is a bit less problematic... although if it happens in something low on
the dependency graph, it of course gets more urgent!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: bug#61894: [PATCH RFC] Team approval for patches

[Vagrant Cascadian]

On 2023-03-08, Maxim Cournoyer wrote:
> On a side note, it would also introduce some kind of hierarchy in the
> group, which I dislike.  One of the things that make Guix special is
> that it's pretty flat -- everybody can participate at the same level, at
> least between committers).  I'd rather we don't try to emulate Debian on
> that point.

I have been watching this thread with great curiosity for exactly this
reason!

One of the things I like about Guix, coming from a couple decades of
involvement with Debian, is the lack of package "ownership" ... in
Debian, any Debian Developer with upload rights can technically upload
any package, but it is considered inappropriate to do so without
following various processes. Over the years, ways to opt-in to
streamlined processes now exist, but the norm is still very much package
"ownership".

Guix is starting from a much more flexible model, but struggling with
challenges of scale ... a small number of people maintaining a huge
number of packages.

I am a bit concerned that formalizing this much process for teams just
yet...

There is not much granularity of team scope and responsibilities. The
current teams implementation seems to involve claiming one or more
gnu/packages/*.scm files (or other files)... but not individual packages
or groups of packages within one of those. It seems quite rough around
the edges and I am concerned about how it will play out to further
formalize the process.

I almost wonder if it wouldn't be good to spell out what exactly is
desired to be accomplished by having teams? Maybe much of that
conversation has already happened, but ... spelling it out first, and
then trying to come up with implementation details that attempt to fit
the goals?


I have a hunch that this dish might benefit from a bit more seasoning. I
am not sure exactly which herbs and spices to reach for, or how long to
leave it simmering on the stove... but I know people are getting hungry!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: universal aarch64/riscv64 images

[Vagrant Cascadian]

On 2023-02-27, Efraim Flashner wrote:
> I've been thinking some about how we create our disk images for aarch64
> devices and how we'll eventually create images for riscv64 devices.
> Currently we use u-boot to load extlinux to boot linux. I propose we use
> u-boot with its EFI interface to load grub-efi to boot linux.
>
> Major benefit of this is that we can create one generic aarch64 image
> using raw-with-offset to create the image and then ship a separate
> script to flash either the SD card or an SPI chip or whatever someone
> wants.

It is certainly worth exploring this!

That said...

By default u-boot will pass a device-tree from the one included u-boot,
which may or may not be compatible with the kernel you want to
boot. There is a mechanism for grub to load a specific device-tree,
but... that will be device-specific again, kind of weakening the
benefits of a device-agnostic "universal" image. Or fix grub to support
a device-tree-directory (much like u-boot syslinux/extlinux support).

U-boot does not (yet?) implement EFI variables, such as the boot order
for EFI to load, so you have to use the fallback /EFI/BOOT/BOOTX64.efi
path, rather than, say, /EFI/GUIX/GRUBX64.efi.

There are probably more surprises!


Ideally, you could build an image that supports both grub-efi and one of
u-boot's other boot methods (boot.scr, syslinux/extlinux style menu,
etc.) ... fundamentally speaking, I do not see any compelling reason you
could not have both grub-efi/grub.cfg and extlinux.conf on the same boot
media, and I have manually built images that do exactly that.

Then people can "bring their own boot firmware" either by using a system
with EFI already out of the box, or installing u-boot (possibly shipped
with guix) to other media, or directly onto the image itself. Or using
https://tow-boot.org, a u-boot fork for some platforms configured to be
installed outside of the boot media when possible (e.g. SPI or eMMC boot
partitions).

For maximal compatibility, I would suggest the first partition should
start at 16MB with an MBR/DOS-style partition table(GPT is basically
incompatible with sunxi64), leaving the rest of the image empty up till
the first partition, so that you can install u-boot directly to the
image if needed or desired. Welcome to the festival of rabbit holes!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Thoughts on committers pushing simple changes from other committers?

[Vagrant Cascadian]

On 2023-02-21, Christopher Baines wrote:
> So probably in part due to the recent changes to the commit policy [1] I
> think there are more "simple" changes being sent to guix-patches by
> committers, which I think is good, but that's got me thinking about the
> process for these changes.
>
> 1: 
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9aa2b7419854306b7ae78d4c4f7684316b834b1d
>
> Generally, I don't push changes for other committers, but I wonder if
> that would be helpful now.

As someone who submitted a patch a few weeks ago:

  https://issues.guix.gnu.org/60940

...which was very recently ACKed, I would definitely welcome someone
pushing it!

There is also no sign like "this has been reviewed by N people" better
than one person authoring it and another person pushing and signing it,
with some Reviewed-by or other relevent tags in the commit.

For some patches (60940 took a few months of on-again, off-again work,
testing, and poking at it), by the time it lands as a submitted patch, I
might be a little tired of staring at it. :)

Even with a quick (e.g. a couple days) response to a submitted patch, I
likely have moved onto other things, it may not be fresh in my mind, the
right things may not be in my /gnu/store anymore to quickly re-test it,
it may take a bit to apply the patch on the right branch...

In this particular case, not only has my attention shifted to other
things for a while (e.g. Debian freeze cycle and things entirely outside
of computer realms) ... to top it off the machine I tested the changes
on ceased to exist!

A lot can happen in a few days, or weeks, etc.

Obviously, for someone else to push a "my" patch, they may have to go
through a lot of the same sorts of issues... but if they have freshly
reviewed it, maybe they are more in a state of "working on guix" and it
might be less of a context switch? Or maybe not...

I guess one way might be to be more explicit about intentions and access
when submitting or reviewing patches:

"Reviews definitely appreciated, but please let me push it myself when
it is ready."

"On reviewing this patch, it looks good to me, but I cannot push it
myself right now. Push when you can or maybe another committer can do
it."

"Thanks for the patch, I will push in X days unless you beat me to it!"

"Reviewers, if you like this patch, go ahead and push it, as I do not
have commit access."

"I am so *done* with this patch, any reviewers please consider pushing
directly if you think it is ready!"

Just a few ideas, could maybe formalize and document it a bit with some
specific recommended tags or keywords or whatever...


Maybe QA could even look up the committers by email and compare against
the submitter to determine if they have commit access or not, and
display that information on the patch review pages? No need to be
perfect, just more right than not. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: guix lint false positives and RFC patch

[Vagrant Cascadian]

On 2023-01-27, Simon Tournier wrote:
> On sam., 12 nov. 2022 at 17:54, Vagrant Cascadian  wrote:
>> On 2022-11-05, Ludovic Courtès wrote:
>>> Vagrant Cascadian  skribis:
>>>> From bfa13fdd3616839883e50efbbc05fb132610ce67 Mon Sep 17 00:00:00 2001
>>>> From: Vagrant Cascadian 
>>>> Date: Wed, 2 Nov 2022 19:56:12 -0700
>>>> Subject: [PATCH 01/12] guix: lint: Exclude some "@" symbols from various
>>>>  checks.
>>>>
>>>> The visual representation of "@code{}" or similar in the description and
>>>> synopsis do not include the string, so exclude it from checks to avoid 
>>>> false
>>>> positives.
>>>>
>>>> FIXME handle @command, @file, @acronym, etc.
>>>>
>>>> * guix/linx.scm (properly-starts-sentence): Exclude leading "@".
>>>>   (check-synopsis-length): Exclude "@code" and "@acronym".
>>>
>>> LGTM!  Bonus points for a test in ‘tests/lint.scm’.  :-)
>>
>> No bonus points for me just yet...
>
> [...]
>
>> What is failing to match what here?
>
> Well, almost done but not merged, right?
>
> Still an issue this ’match’?

Thanks for bringing this back up to the surface! I struggled with it a
bit and honestly do not remember where I last left it... I think I made
some further progress... and then hit a new blocker and the sun went
down and slept on it ... and never got back to it.

So I was definitely stuck writing a test. From vague memory, I think
once I figured out how to have the test not fail wit guile complaining
inscrutibly... it did not effectively test the thing it was supposed to.

The other thing I remember being caught up on, which was not a
deal-breaker, per se, was hoping for a way to loop through a bunch of
@SOMETHING things ... I was not happy with:

+(if (>= (string-length (string-replace-substring
+(string-replace-substring synopsis "@acronym" "")
+"@code" ""))
+   80)

And then adding @command, @file, @acronym, etc. ... using increasingly
nested levels string-replace-substring would eventually become difficult
to read and surely there is a better way!

I might be able to take another look at this in february, but I would
welcome help wrapping this up regardless!

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Some team related thoughts and questions...

[Vagrant Cascadian]

On 2023-01-09, Simon Tournier wrote:
> On ven., 06 janv. 2023 at 10:42, Vagrant Cascadian  wrote:
>> More I wanted to look through the patch text rather than the package
>> descriptions. It would ideally catch things like "reproducible" or
>> "deterministic" in comments in patches as well as git commit summary.
>
> Well, IIUC, your point would be to have teams based on “topic“ referred
> by search term in patches.  Why not, although it is far to be
> implemented, I guess. ;-)

Sure, it is wishing for a feature, on the hopes that someone more savvy
with parens sees the value and implements it. :)


> BTW, I would recommend to give a look at lei [1,2] from the Guix package
> public-inbox.  For instance, over the last 12 months, all patches
> containing the terms ’r-build-system’ and ’reproducible’,
>
> 1. Extract from a public-inbox instance:
>
> guix shell public-inbox \
>  -- lei q --threads --dedupe=mid \
>  -I https://yhetil.org/guix-patches/ -o /tmp/Mail/patches \
>  'dfn:gnu/packages AND b:r-build-system AND b:reproducible AND 
> rt:12.months.ago..'
>
> 2. Read it with a mail reader support Maildir:
>
> guix shell neomutt -- neomutt -f /tmp/Mail/patches
>
>
> where
>
>dfn: match filename from diff
>b:   match within message body, including text attachments
>rt:  match date-time range, git "approxidate" formats supported
> Open-ended ranges such as `d:last.week..' and `d:..2.days.ago'
> are supported

Thanks for the examples! I have tried to wrap my head around
public-inbox and related tooling, as it seems extremely
useful. Hopefully this gets me into actually using it. :)

Though using public-inbox is obviously working at it from the other end,
not getting CCed on things but having to rummage through the heap of
patches to find them. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Some team related thoughts and questions...

[Vagrant Cascadian]

On 2023-01-06, Simon Tournier wrote:
> On Tue, 03 Jan 2023 at 22:11, Vagrant Cascadian  wrote:
>
>> Perhaps a description would for the team(s) would help a bit here.  I
>> see embedded as dealing with bootloaders or firmware commonly used on
>> embedded systems, and perhaps cross-compilers?
>
> Well, currently the ’team’ record contains the description field.  So it
> can be expanded if it helps.

Right, there was no description for the "Embedded / Bootstrap" team
... so basically asking what the intention of the team is (and a little
confused at the co-mingling of two seemingly distinct teams, at least in
my mind).


>> I wonder if the team.scm script could also have a few regexps in it for
>> the patch description. For example, "deterministic" or "reproducible"
>> might be a useful search term for my recently proposed Reproducible
>> Builds team, which otherwise would only be interested in a small pool of
>> reproducible builds tooling packages, but reproducible builds issues
>> actually could be relevent for all packages in guix.
>
> I guess something like,
>
> ./etc/teams.scm list-teams | recsel -q deterministic
>
> should list the teams where ’deterministic’ appears.  It is far from
> being perfect but it allows minimal queries.

More I wanted to look through the patch text rather than the package
descriptions. It would ideally catch things like "reproducible" or
"deterministic" in comments in patches as well as git commit summary.


>> Lastly, I use the name "Vagrant Cascadian" with my contributions to
>> guix, but I may use a different email address depending on the nature of
>> the contribution (e.g. reproducible builds). I am not sure what would
>> happen if I added "Vagrant Cascadian" twice, with two different email
>> addresses. Does it handle that reasonably?
>
> You would like to have an email address different depending on the
> team, right?
>
> Currently, a person (record ) has one name (string) and one
> email (string) and then this person is part of one more teams (list).
>
> Well, it is not implemented but the macro ’define-member’ could be
> tweaked to associate one email to one team for a person, I guess.

If a "person" is identified by "name"+"email" then it should be fine. I
was worried if a "person" is identified solely by "name".

Defining myself as two persons with the same name and different email
addresses works for my needs, if that is indeed how it works!

live well,
  vagrant


signature.asc
Description: PGP signature

Some team related thoughts and questions...

[Vagrant Cascadian]

I filed a couple patches related to teams recently, which pointed out a
few things about the teams process to me...


First off, I wonder if there is (or it is worth creating) a way to make
the scope of a team more fine-grained... e.g. I think the Embedded team
would want to be notified of changes to gnu/packages/bootloaders.scm,
for the u-boot-* packages, but maybe not for grub? Similar also for the
arm-trusted-firmware-* or opensbi packages, but maybe not for
ath9k-htc-firmware (although the case could be made that that is an
embedded system unto itself).


I also wonder about splitting Embedded and Bootstrap into separate
teams; some things are obviously one or the other, but I do not, at
least in my mind, see the overlap.

Perhaps a description would for the team(s) would help a bit here.  I
see embedded as dealing with bootloaders or firmware commonly used on
embedded systems, and perhaps cross-compilers?

Is the Bootstrap team ... bootstrapping a new language compiler family?
bootstrapping a system from scratch? Yes to both? What is it's scope?


I wonder if the team.scm script could also have a few regexps in it for
the patch description. For example, "deterministic" or "reproducible"
might be a useful search term for my recently proposed Reproducible
Builds team, which otherwise would only be interested in a small pool of
reproducible builds tooling packages, but reproducible builds issues
actually could be relevent for all packages in guix.


Lastly, I use the name "Vagrant Cascadian" with my contributions to
guix, but I may use a different email address depending on the nature of
the contribution (e.g. reproducible builds). I am not sure what would
happen if I added "Vagrant Cascadian" twice, with two different email
addresses. Does it handle that reasonably?

It would be a little awkward to add a "Vagrant Cascadian (reproducible
builds)" in the name field but I guess that might be a trivial
workaround if having "Vagrant Cascadian" twice causes issues.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [PATCH] gnu: u-boot-am335x-boneblack: Revert to old name.

[Vagrant Cascadian]

On 2022-12-28, Maxim Cournoyer wrote:
> This reverts to the name this package had previous to commit
> c2c1dfdf5760873f1db86d14873f725a105f7feb ("gnu: bootloader: Add U-Boot
> packages for Raspberry Pi models."), which caused the package name to be
> derived from the board name.
>
> * gnu/packages/bootloaders.scm (u-boot-am335x-evm-boneblack): Remove the
> NAME-SUFFIX keyword argument.  Specify the full name via the name field.
> * gnu/bootloader/u-boot.scm (u-boot-beaglebone-black-bootloader): Adjust to
> the renamed package.
>
> Reported-by: Vagrant Cascadian 

I haven't tested that it builds, but it looks good to me; thanks for
sorting that out!


live well,
  vagrant

> ---
>  gnu/bootloader/u-boot.scm|  2 +-
>  gnu/packages/bootloaders.scm | 28 +---
>  2 files changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/gnu/bootloader/u-boot.scm b/gnu/bootloader/u-boot.scm
> index de3a43ed70..6cad33b741 100644
> --- a/gnu/bootloader/u-boot.scm
> +++ b/gnu/bootloader/u-boot.scm
> @@ -144,7 +144,7 @@ (define u-boot-bootloader
>  (define u-boot-beaglebone-black-bootloader
>(bootloader
> (inherit u-boot-bootloader)
> -   (package u-boot-am335x-evm-boneblack)
> +   (package u-boot-am335x-boneblack)
> (disk-image-installer install-beaglebone-black-u-boot)))
>  
>  (define u-boot-allwinner-bootloader
> diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
> index 89f051f337..e379a38127 100644
> --- a/gnu/packages/bootloaders.scm
> +++ b/gnu/packages/bootloaders.scm
> @@ -890,17 +890,23 @@ (define*-public (make-u-boot-package board triplet
>  (define-public u-boot-malta
>(make-u-boot-package "malta" "mips64el-linux-gnuabi64"))
>  
> -(define-public u-boot-am335x-evm-boneblack
> -  (make-u-boot-package
> -   "am335x_evm" "arm-linux-gnueabihf"
> -   ;; Patch out other device trees to build an image small enough to fit
> -   ;; within typical partitioning schemes where the first partition begins at
> -   ;; sector 2048.
> -   #:configs '("CONFIG_OF_LIST=\"am335x-evm am335x-boneblack\"")
> -   #:name-suffix "-boneblack"
> -   #:append-description "This U-Boot is built for the BeagleBone Black, which
> -was removed upstream, adjusted from the am335x_evm build with several device
> -trees removed so that it fits within common partitioning schemes."))
> +(define-public u-boot-am335x-boneblack
> +  (let ((base (make-u-boot-package
> +   "am335x_evm" "arm-linux-gnueabihf"
> +   ;; Patch out other device trees to build an image small enough
> +   ;; to fit within typical partitioning schemes where the first
> +   ;; partition begins at sector 2048.
> +   #:configs '("CONFIG_OF_LIST=\"am335x-evm am335x-boneblack\"")
> +   #:append-description
> +   "This U-Boot is built for the BeagleBone Black, which was
> +removed upstream, adjusted from the am335x_evm build with several device 
> trees
> +removed so that it fits within common partitioning schemes.")))
> +(package
> +  (inherit base)
> +  ;; The name is not derived from the board name on purpose, as the 
> config
> +  ;; is modified per the comment above, parting from the default
> +  ;; am335x_evm configuration.
> +  (name "u-boot-am335x-boneblack"
>  
>  (define-public u-boot-am335x-evm
>(make-u-boot-package "am335x_evm" "arm-linux-gnueabihf"))
>
> base-commit: fde5af3962c8fafc5d20e5d742cc7aea907f3563
> -- 
> 2.38.1


signature.asc
Description: PGP signature

Re: u-boot-am335x-boneblack -> u-boot-am335x-evm-boneblack

[Vagrant Cascadian]

On 2022-12-26, Maxim Cournoyer wrote:
> Vagrant Cascadian  writes:
>> On 2022-12-22, Maxim Cournoyer wrote:
>>> Vagrant Cascadian  writes:
>> I will take a guess that it was commit
>> c2c1dfdf5760873f1db86d14873f725a105f7feb which removed the "name" bit:
>
> Oh, that explains it, thank you for digging a bit.
>
> The following should return us to the previous name, fixing that
> regression:
>
> --8<---cut here---start->8---
> modified   gnu/bootloader/u-boot.scm
> @@ -144,7 +144,7 @@ (define u-boot-bootloader
>  (define u-boot-beaglebone-black-bootloader
>(bootloader
> (inherit u-boot-bootloader)
> -   (package u-boot-am335x-evm-boneblack)
> +   (package u-boot-am335x-boneblack)
> (disk-image-installer install-beaglebone-black-u-boot)))
>  
>  (define u-boot-allwinner-bootloader
> modified   gnu/packages/bootloaders.scm
> @@ -890,17 +890,23 @@ (define*-public (make-u-boot-package board triplet
>  (define-public u-boot-malta
>(make-u-boot-package "malta" "mips64el-linux-gnuabi64"))
>  
> -(define-public u-boot-am335x-evm-boneblack
> -  (make-u-boot-package
> -   "am335x_evm" "arm-linux-gnueabihf"
> -   ;; Patch out other device trees to build an image small enough to fit
> -   ;; within typical partitioning schemes where the first partition begins at
> -   ;; sector 2048.
> -   #:configs '("CONFIG_OF_LIST=\"am335x-evm am335x-boneblack\"")
> -   #:name-suffix "-boneblack"
> -   #:append-description "This U-Boot is built for the BeagleBone Black, which
> -was removed upstream, adjusted from the am335x_evm build with several device
> -trees removed so that it fits within common partitioning schemes."))
> +(define-public u-boot-am335x-boneblack
> +  (let ((base (make-u-boot-package
> +   "am335x_evm" "arm-linux-gnueabihf"
> +   ;; Patch out other device trees to build an image small enough
> +   ;; to fit within typical partitioning schemes where the first
> +   ;; partition begins at sector 2048.
> +   #:configs '("CONFIG_OF_LIST=\"am335x-evm am335x-boneblack\"")
> +   #:append-description
> +   "This U-Boot is built for the BeagleBone Black, which was
> +removed upstream, adjusted from the am335x_evm build with several device 
> trees
> +removed so that it fits within common partitioning schemes.")))
> +(package
> +  (inherit base)
> +  ;; The name is not derived from the board name on purpose as the config
> +  ;; is modified per the comment above, parting from the default
> +  ;; am335x_evm configuration.
> +  (name "u-boot-am335x-boneblack"
>  
>  (define-public u-boot-am335x-evm
>(make-u-boot-package "am335x_evm" "arm-linux-gnueabihf"))
> --8<---cut here---end--->8---
>
> Does it look good to you?  If so, I'll commit it.

It doesn't look obviously wrong... but there are a lot of whitespace
changes that my lazy eyeballs might not catch... :)

I would like to be able to see the results with "git diff
--ignore-allspace" but it is not formatted in a way I understand how to
actually apply it to git.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Stratification of GNU Guix into Independent Channels

[Vagrant Cascadian]

On 2022-12-24, jgart wrote:
> I wanted to ask you what are your thoughts on this idea. This is a
> thought experiment at this stage.
>
> Should GNU Guix be a small core of packages (and services?)?
>
> For example, GNU Guix would be a core channel containing the reduced
> binary seed bootstrap and a few other core packages to bootstrap the
> system. That's it. Users subscribe to this channel to get started.

I definitely am excited and hopeful to think this *could* be possible!


> Users could then decide what channels they'd like to subscribe to/opt
> in to by adding any of the following channels as they please:
>
> python-channel
> rust-channel
...
> scheme-channel
> etc...
>
> The above channels would still be maintained under the auspices of GNU.
>
> What do you think would be the pros and cons of the stratified
> approach versus the monorepo approach that we currently have?

The pros would be only having to pull the small bits you actually want,
and that could be faster to run "guix pull".

This would certainly make it much easier to package a "core" subset of
guix for other distros (e.g. I work on packaging guix in Debian) that
having to package the whole entire guix universe.

I suspect the "small bootstrap core set" to eventually pull in quite a
bit of other things, and continually be at risk of needing to pull in
more things...

You would probably need to have inter-channel dependencies... which
makes me wonder how many cyclic dependencies might result...

git alone pulls in dependencies for perl, python, git, subversion,
openssl ... and what is the dependency cycle for each of those? Guix
apparently can generate pretty charts for this stuff, though I have yet
to try. :)

I have the (perhaps mininformed) impression nix has a split more along
these lines with the core of nix being one thing, and then collections
of packages being other repositories.


> GNU Guix proper would be a solid core of packages that is very easy to
> maintain. This would greatly reduce the maintenance burden since
> maintaining a world of rust, golang, or python packages is opt in by
> those who want to do that particular work.

If it is possible, it seems likely to make releasing more regularly and
less stressfully...


> Would being subscribed to just the hypothetical small core channel in
> this proposal increase download/installation speeds given the
> availability of substitutes?

I suspect it would significantly increase guix pull speeds, at the very
least.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: u-boot-am335x-boneblack -> u-boot-am335x-evm-boneblack

[Vagrant Cascadian]

On 2022-12-22, Maxim Cournoyer wrote:
> Vagrant Cascadian  writes:
>
>> Wondering what necessitated this change from the old variable name to a
>> new name...
>>
>> commit c04528d2a2597d79278833f3607c806278253446
>> Author: Maxim Cournoyer 
>> Date:   Tue Dec 20 21:25:27 2022 -0500
>>
>> gnu: u-boot-am335x-evm-boneblack: Fix variable name.
>>
>> * gnu/packages/bootloaders.scm (u-boot-am335x-boneblack): Rename to...
>> (u-boot-am335x-evm-boneblack), to match the package name.
>> * gnu/bootloader/u-boot.scm (u-boot-beaglebone-black-bootloader): Adjust
>> accordingly.
>> ...
>> diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
>> index bd9f7bb577..c8b8adbc93 100644
>> --- a/gnu/packages/bootloaders.scm
>> +++ b/gnu/packages/bootloaders.scm
>> @@ -889,7 +889,7 @@ (define*-public (make-u-boot-package board triplet
>>  (define-public u-boot-malta
>>(make-u-boot-package "malta" "mips64el-linux-gnuabi64"))
>>
>> -(define-public u-boot-am335x-boneblack
>> +(define-public u-boot-am335x-evm-boneblack
>>(make-u-boot-package
>> "am335x_evm" "arm-linux-gnueabihf"
>> ;; Patch out other device trees to build an image small enough to fit
>>
>> The u-boot-am335x-boneblack was named to match the original target that
>> was removed from upstream, adapting the upstream am335x-evm to fit into
>> a smaller gap in the partition tables... (e.g. 2MB partition offset
>> instead of 4MB offset required by the default am335x-evm board
>> configuration).
>
> The problem was that the *name* of the package was
> "u-boot-am335x-evm-boneblack", as computed by the MAKE-U-BOOT-PACKAGE
> procedure, which includes the board argument in its name (it's been like
> this since its inception in 862e38d5518, 2017).
>
> If the previous variable name should have been its name, the name field
> would have needed to be overridden to it (or perhaps we could introduce
> a #:name argument that would take precedence over any cleverness).
>
> I noticed of the problem when trying to build the package; "guix build
> u-boot-am335x-boneblack" would tell me it didn't exist.
>
> I considered making a deprecated alias but decided against, because in
> the past we didn't when moving/renaming packages *variables*.

Odd. I was certainy able to build u-boot-am335x-boneblack from commit
6b99afeef89233b71d113a63cf04a6b4b49a4679 when it was introduced in 2019,
though it has been quite some time since I tested it...

I will take a guess that it was commit
c2c1dfdf5760873f1db86d14873f725a105f7feb which removed the "name" bit:

 (define-public u-boot-am335x-boneblack
-  (let ((base (make-u-boot-package
-   "am335x_evm" "arm-linux-gnueabihf"
-   ;; Patch out other device trees to build an image small enough
-   ;; to fit within typical partitioning schemes where the first
-   ;; partition begins at sector 2048.
-   #:configs '("CONFIG_OF_LIST=\"am335x-evm am335x-boneblack\""
-(package
-  (inherit base)
-  (name "u-boot-am335x-boneblack")


live well,
  vagrant


signature.asc
Description: PGP signature

Re: bug#60227: guile-ssh 0.16 update

[Vagrant Cascadian]

On 2022-12-21, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>
>> Well, that is what I did, pulled guix to the curren wip-guile-ssh-0.16
>> branch (which contains an update to guile-ssh 0.16 and updates guix to
>> use a commit containing that), and managed to guix copy from one machine
>> to another, so I *think* we are good!
>
> As mentioned on IRC, I tested it with ‘GUIX_DAEMON_SOCKET=ssh://…’ and
> ‘guix copy’, and it all seems good.  So I think you can go ahead!

Ok, pushed as 0744540d09ddef8dbf25cc5d65da9d029dab338c.


>> Patch attached for the guile-ssh update. Once that lands in master we
>> can consider updating guix to use it...
>
> No need to update the ‘guix’ package, or am I missing something?  The
> ‘guix’ package depends on guile-ssh, so it’ll end up using the new
> version anyway.

Probably (clearly?) just me overthinking it and somehow... guix builds
with the inputs from the guix commit defined in the guix package, not
just as the source code for the guix package built with the currently
defined guix inputs to using the guix build tool... guix building guix
with guix and with guix defining the guix inputs... to alleviate risk of
casuing any genuine (further) confusion...

I'll trust your judgement here!


live well,
  vagrant


signature.asc
Description: PGP signature

u-boot-am335x-boneblack -> u-boot-am335x-evm-boneblack

[Vagrant Cascadian]

Wondering what necessitated this change from the old variable name to a
new name...

commit c04528d2a2597d79278833f3607c806278253446
Author: Maxim Cournoyer 
Date:   Tue Dec 20 21:25:27 2022 -0500

gnu: u-boot-am335x-evm-boneblack: Fix variable name.

* gnu/packages/bootloaders.scm (u-boot-am335x-boneblack): Rename to...
(u-boot-am335x-evm-boneblack), to match the package name.
* gnu/bootloader/u-boot.scm (u-boot-beaglebone-black-bootloader): Adjust
accordingly.
...
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index bd9f7bb577..c8b8adbc93 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -889,7 +889,7 @@ (define*-public (make-u-boot-package board triplet
 (define-public u-boot-malta
   (make-u-boot-package "malta" "mips64el-linux-gnuabi64"))

-(define-public u-boot-am335x-boneblack
+(define-public u-boot-am335x-evm-boneblack
   (make-u-boot-package
"am335x_evm" "arm-linux-gnueabihf"
;; Patch out other device trees to build an image small enough to fit

The u-boot-am335x-boneblack was named to match the original target that
was removed from upstream, adapting the upstream am335x-evm to fit into
a smaller gap in the partition tables... (e.g. 2MB partition offset
instead of 4MB offset required by the default am335x-evm board
configuration).

Was this a side-effect of some of the changes that were implemented with
the raspberry pi series? Is the name change actually needed in some way,
or is it just "housecleaning" ? It doesn't actually "match" the name of
the target, which is "am335x_evm", not "am335x_evm_boneblack".

I would think keeping the old name would allow for seamless upgrades. Or
at least leaving a deprecated package placeholder or something like that
if the rename is actually needed... but a little unclear on the
situation at the moment.


With all that said... having 512MB of ram, I wonder how well a
beaglebone black would do running guix at all...

Are people actually using some of these low-end boards with guix? I'll
admit, I added a bunch of them in my early days of enthusiastically
contributing to guix... but wonder if they are pragmatic to use.


live well,
  vagrant


signature.asc
Description: PGP signature

guile-ssh 0.16 update

[Vagrant Cascadian]

On 2022-12-20, Vagrant Cascadian wrote:
> On 2022-11-02, Ludovic Courtès wrote:
>> Vagrant Cascadian  skribis:
>>> On 2022-10-28, Vagrant Cascadian wrote:
>>>> Updating guile-ssh to 0.16.0 actually went mostly smoothly, except
>>>> guix-jupytertest suites fail.
> ...
>>> For clarity, I used:
>>>
>>> ./pre-inst-env guix build --keep-going $(./pre-inst-env guix refresh 
>>> --list-dependent libssh guile-ssh | cut -d : -f 2 | sed -e 
>>> 's,guix-daemon,guix,g' | tr ' ' '\n' | grep -v kodi | grep -v jupyter)
>>
>> You can also test Guix SSH functionality, to be on the safe side, for
>> example by running ‘guix copy’ on the ‘guix’ package built with these
>> new versions.
...
> So, I attempted that in the newish wip-guile-ssh-0.16 branch, but
> getting test suite failures even without the guile-ssh patches, so hard
> to test that guix copy works...

That seems to have been fixed by:

  680970490c556ae0029aa1ba2b0faba162118186 tests: Adjust 'guix package' test to 
latest package search metrics.

Thanks!

> Is this at least the right approach? e.g. point guix at a commit where
> guile-ssh is updated? Is there anything special with the revision? As
> you can see from the wip-guile-ssh-0.16 branch, I tried revision "0.1"
> and then switched back to "0" ... (fearing clobbering a real-world "1"
> revision someday...). I pushed a wip branch just to be able to easily
> pull to a commit not on master... as I don't know how to do that
> locally.
>
> Presuming I can get guix to build successfully, do i then need to
> reconfigure the systems to use a guix-daemon with guile-ssh on both?
> ... and then run "guix copy" between the two systems?

Well, that is what I did, pulled guix to the curren wip-guile-ssh-0.16
branch (which contains an update to guile-ssh 0.16 and updates guix to
use a commit containing that), and managed to guix copy from one machine
to another, so I *think* we are good!

Patch attached for the guile-ssh update. Once that lands in master we
can consider updating guix to use it...

live well,
  vagrant
From 6f33de5f2df02c0ca2ef05409b1993b9fc69f4f9 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 27 Oct 2022 13:13:28 -0700
Subject: [PATCH] gnu: guile-ssh: Update to 0.16.0.

* gnu/packages/ssh.scm (guile-ssh): Update to 0.16.0.
---
 gnu/packages/ssh.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/ssh.scm b/gnu/packages/ssh.scm
index babed807f9..65280bc4da 100644
--- a/gnu/packages/ssh.scm
+++ b/gnu/packages/ssh.scm
@@ -318,7 +318,7 @@ (define-public openssh-sans-x
 (define-public guile-ssh
   (package
 (name "guile-ssh")
-(version "0.15.1")
+(version "0.16.0")
 (home-page "https://github.com/artyom-poptsov/guile-ssh;)
 (source (origin
   (method git-fetch)
@@ -328,7 +328,7 @@ (define-public guile-ssh
   (file-name (git-file-name name version))
   (sha256
(base32
-"0zzn5hsf97b35gixyg4z14sspl15qwnp52y4h89wra4y31l7467q"
+"1ka5ayrg7kysx3bi5d8s0z6n12sdc06qp9gc4k9h2mlw3vz187ny"
 (build-system gnu-build-system)
 (outputs '("out" "debug"))
 (arguments
-- 
2.35.1



signature.asc
Description: PGP signature

guile-ssh 0.16 update (was Re: guile-ssh and libssh updates)

[Vagrant Cascadian]

On 2022-11-02, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>> On 2022-10-28, Vagrant Cascadian wrote:
>>> Updating guile-ssh to 0.16.0 actually went mostly smoothly, except
>>> guix-jupytertest suites fail.
...
>> For clarity, I used:
>>
>> ./pre-inst-env guix build --keep-going $(./pre-inst-env guix refresh 
>> --list-dependent libssh guile-ssh | cut -d : -f 2 | sed -e 
>> 's,guix-daemon,guix,g' | tr ' ' '\n' | grep -v kodi | grep -v jupyter)
>
> You can also test Guix SSH functionality, to be on the safe side, for
> example by running ‘guix copy’ on the ‘guix’ package built with these
> new versions.

Well, this being on the safe side has turned out to be quite the
adventure...


So, I attempted that in the newish wip-guile-ssh-0.16 branch, but
getting test suite failures even without the guile-ssh patches, so hard
to test that guix copy works...

Tried updating guix to bd6d76b7a

diff --git a/gnu/packages/package-management.scm 
b/gnu/packages/package-management.scm
index 2ffaa12247..6b3c47e5a1 100644
--- a/gnu/packages/package-management.scm
+++ b/gnu/packages/package-management.scm
@@ -165,7 +165,7 @@ (define-public guix
   ;; Note: the 'update-guix-package.scm' script expects this definition to
   ;; start precisely like this.
   (let ((version "1.4.0")
-(commit "8e2f32cee982d42a79e53fc1e9aa7b8ff0514714")
+(commit "bd6d76b8a44bb14dedaed070b7056f2f56c2e161")
 (revision 0))
 (package
   (name "guix")
@@ -182,7 +182,7 @@ (define-public guix
   (commit commit)))
 (sha256
  (base32
-  "042mipw2bp9lc75m9g5q6rdifrp8483cmk57kwrdps0i3vd590dl"))
+  "0hxv9p5zq4i4xfhd696n9jxrpslm7bf8i3c8zdgf79lvv9mbs43z"))
 (file-name (string-append "guix-" version "-checkout"
   (build-system gnu-build-system)
   (arguments

The test suite failues are a bit long, but in case this short clip helps...

FAIL: tests/guix-package


+ guix package --version
guix package (GNU Guix) 1.4.0
Copyright (C) 2022 the Guix authors
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
+ module_dir=t-guix-package-11599
+ profile=t-profile-11599
...
  /tmp/guix-tests/store/y4dirvvs7f7dpzgyzbwaf4x3ijzqvk92-gmp-6.2.1.drv
  /tmp/guix-tests/store/lp4rpsrvji0y5idkam7hxfkw95d6rmld-gmp-6.2.1.tar.xz.drv
  /tmp/guix-tests/store/7hhl5sa5w96qnwl7dqx6ycnz3sqz6rsp-gmp-6.2.1.tar.xz.drv
  /tmp/guix-tests/store/v3f6d36pvlh52mcfq3x6b3lx88kyk2cx-m4-1.4.18.drv
  /tmp/guix-tests/store/9s8fa4cpxcc45mh6q69c7kk927jpsnvr-m4-1.4.18.tar.xz.drv
++ guix package -L t-guix-package-11599 -s '^fileutils$'
++ grep '^name:'
+ test 'name: ocaml-fileutils' = ''
+ rm -f t-profile-11599 t-profile-11599.lock t-profile-11599-1-link 
t-guix-package-file-11599
+ rm -rf t-guix-package-11599 t-home-11599
FAIL tests/guix-package.sh (exit status: 1)


Is this at least the right approach? e.g. point guix at a commit where
guile-ssh is updated? Is there anything special with the revision? As
you can see from the wip-guile-ssh-0.16 branch, I tried revision "0.1"
and then switched back to "0" ... (fearing clobbering a real-world "1"
revision someday...). I pushed a wip branch just to be able to easily
pull to a commit not on master... as I don't know how to do that
locally.

Presuming I can get guix to build successfully, do i then need to
reconfigure the systems to use a guix-daemon with guile-ssh on both?
... and then run "guix copy" between the two systems?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: GNU Guix 1.4.0rc2 available for testing!

[Vagrant Cascadian]

On 2022-12-11, Ludovic Courtès wrote:
> The second release candidate of the upcoming 1.4.0 release is now
> available for testing, fixing issues that were reported for rc1:

Also available in .deb format on your favorite Debian mirrors:

  https://tracker.debian.org/pkg/guix

Currently only in Debian sid/unstable, but probably installable on a
Debian bookworm/testing system, too.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: guile-ssh and libssh updates

[Vagrant Cascadian]

On 2022-11-02, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>> On 2022-10-28, Vagrant Cascadian wrote:
>>> I've been poking at updating guile-ssh to 0.16.0 and libssh to 0.10.4 in
>>> guix, but hit a few blockers.
>>>
>>> Updating guile-ssh to 0.16.0 actually went mostly smoothly, except
>>> guix-jupytertest suites fail.
...
>>> Updating libssh to 0.10.4 mostly works, but breaks guile-ssh tests:
>>>
>>>   https://github.com/artyom-poptsov/guile-ssh/issues/34
>>>
>>> Updating libssh to 0.10.4 with tests disabled for guile-ssh,
>>> guix-jupyter and kodi and kodi-wayland fail to build...
>>
>> For clarity, I used:
>>
>> ./pre-inst-env guix build --keep-going $(./pre-inst-env guix refresh 
>> --list-dependent libssh guile-ssh | cut -d : -f 2 | sed -e 
>> 's,guix-daemon,guix,g' | tr ' ' '\n' | grep -v kodi | grep -v jupyter)

So regarding libssh... what I discovered is that libssh deprecates the
DSA key algorithm (it is of dubious strenth, after all), and 0.10.x
disables DSA by default. Passing -DWITH_DSA=on to re-enable DSA support
in the libssh build helps guile-ssh pass most tests, but some tests
still fail. Since libssh plans to entirely remove DSA support in future
versions, may as well adapt sooner than later...

For Debian at the moment, I've patched out the DSA code from the
guile-ssh test suites, and that seems to work fine.

More details on the upstream guile-ssh bug report referenced above...


> You can also test Guix SSH functionality, to be on the safe side, for
> example by running ‘guix copy’ on the ‘guix’ package built with these
> new versions.

Clearly this has been a blocker for me... I don't have any systems where
I use that functionality, and I haven't taken the time to set them up to
test myself.

Anyone willing to offer some "guix copy" testing to have greater
confidence in updating guile-ssh? :)


> And then feel free to push!  (Guix-Jupyter has been failing tests for
> unrelated reasons.)

So, here we are... :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Should a Guix package include documentation dependencies to be considered complete?

[Vagrant Cascadian]

On 2022-12-07, jg...@dismail.de wrote:
> We have abjad packaged but we don't necessarily have all the
> dependencies needed to build everything that abjad provides such as a
> PDF document that it mentions in its project Makefile.
>
> Should we include the LaTeX dependencies in the abjad package?
>
> Should all Python packages include the required dependencies to build 
> documentation?

With my Reproducible Builds hat on...

Some of the main remaining reproducibility issues in Debian are with
documentation generation, notably .pdf and various non-determinism
issues in sphinx, frequently used to generate documentation in various
formats in python projects.

I would hate to have a policy to always generate documentation if it
makes Guix less reproducible... maybe putting the documentation into a
separate output at least? While unreproducible documentation is
unfortunate, it is not that same as, say, the kernel or important core
libraries.

I personally have a strong preference for formats that are largely
readable as "plain" text (markdown, restructuredtext) to fancy
formatting; you can just copy them into the package rather than having
to transform them into some fancy format. I also get that that does not
work for everyone...


> We currently include all the dependencies to run the tests, why not do
> the same for documentation building?
>
> Should we make it a requirement or goal to always package a given package's 
> "documentation-inputs"?

Systematically and programatically being able to distinguish between
"regular" inputs and test and documentation inputs sounds useful in a
number off ways... my only worry would be when a particular input might
shift from one category to another without noticing, and keeping track
of those changes, and maybe cross building would be something to
consider as well. But the advantages might outweigh the disadvantages.

In Debian there is a concept of build profiles (e.g. nocheck, nodoc)
which alter which dependencies are required to build the package.


live well,
  vagrant


signature.asc
Description: PGP signature

missing sanity check

[Vagrant Cascadian]

On 2022-12-03, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>
>>   In guix/packages.scm:
>> 1295:37  5 (_)
>> 1555:16  4 (package->bag _ _ _ #:graft? _)
>> 1652:22  3 (thunk)
>>   In guix/gexp.scm:
>>  523:11  2 (lower "python-gwcs-0.18.2" #:source _ #:inputs _ # _ . #)
>>  460:52  1 (%local-file #f # …)
>>   In unknown file:
>>  0 (basename #f #)
>
> D’oh, this was due to a file missing from the tarball, which should be
> fixed with 90612b9f1f5fe2d976356e4fa40293a245ebd6c5.
>
> If you feel like doing it, you can run ‘make dist’ from ‘version-1.4.0’
> and try again.  :-)

I definitely did not feel up for a round of 'make dist' for it; I just
patched it in to the debian package:

  
https://salsa.debian.org/debian/guix/-/commit/6b9d57fec61edad9b9303e8a3fad1feb0ce8a004

And it worked, thanks!

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Guile-Gcrypt 0.4.0 released

[Vagrant Cascadian]

On 2022-12-01, Ludovic Courtès wrote:
> I’m pleased to announce Guile-Gcrypt version 0.4.0:
>
>   git clone https://notabug.org/cwebber/guile-gcrypt.git
>   cd guile-gcrypt
>   git checkout v0.4.0  # or 425554d4327eeeb60c39e3d4a1b7bc5e36b63953
>   git tag -v v0.4.0

FWIW, I updated guile-gcrypt to 0.4.0 in Debian experimental and updated
to guix 1.4.0rc1 in Debian experimental using guile-gcrypt 0.4.0, and it
seemed to go fine so far...

  https://buildd.debian.org/status/package.php?p=guile-gcrypt=experimental
  https://buildd.debian.org/status/package.php?p=guix=experimental

I'm guessing guile-gcrypt 0.4.0 will not land in the soon-to-be-released
guix 1.4.0 once it is released, though?

Looking at the longer term, makes me wonder if I should build guix with
guile-gcrypt 0.3.0 currently in Debian unstable & testing ... or if
0.4.0 is a small enough difference that it will probably be fine to
build guix 1.4.0* against it (and eventually migrate it to debian
unstable and eventually testing)?

I know the guix thing would be to package all the relevent versions, but
that is a bit trickier in Debian! :)

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Release progress, week 8

[Vagrant Cascadian]

On 2022-12-02, Ludovic Courtès wrote:
> Release progress: week 8.
>
> Apologies for not sending this one on time this Thursday; instead we got
> RC1, which is nice.  :-)
>
>   https://lists.gnu.org/archive/html/guix-devel/2022-12/msg0.html

Yay, love not having to build the source tarball to test it! :)


> The RC was made from ‘version-1.4.0’ branch, which only takes important
> fixes now (if in doubt, please ask).

Must not fix trivial known guix lint typo fixes, check! :)


With more seriousness... here come the test suite failures!

When building on Debian there are a number of tests that fail with the
same symptoms, notably something wrong with how "scm_to_utf8_stringn" is
called:

  test-name: find-packages-by-name with cache
  location: /build/guix-HqZNpM/guix-1.4.0~rc1/tests/packages.scm:1760
  source:
  + (test-equal
  +   "find-packages-by-name with cache"
  +   (find-packages-by-name "guile")
  +   (call-with-temporary-directory
  + (lambda (cache)
  +   (generate-package-cache cache)
  +   (mock ((guix describe) current-profile (const cache))
  + (mock ((gnu packages)
  +cache-is-authoritative?
  +(const #t))
  +   (find-packages-by-name "guile"))
  expected-value: (# 
# # # # #)
  actual-value: #f
  actual-error:
  + (wrong-type-arg
  +   "scm_to_utf8_stringn"
  +   "Wrong type argument in position ~A (expecting ~A): ~S"
  +   (1 "string" #f)
  +   (#f))
  result: FAIL


Tests that appear affected by this issue:

  tests/graph.log:test-name: reverse bag DAG
  tests/graph.log:result: FAIL

  tests/packages.log:test-name: fold-available-packages with/without cache
  tests/packages.log:result: FAIL

  tests/packages.log:test-name: find-packages-by-name with cache
  tests/packages.log:result: FAIL

  tests/packages.log:test-name: find-packages-by-name + version, with cache
  tests/packages.log:result: FAIL

  tests/packages.log:test-name: find-package-locations with cache
  tests/packages.log:result: FAIL

And tests/inferiors.scm dies with a backtrace, and stops processing any
further tests so it is hard to know if those fail too:

  Backtrace:
17 (primitive-load-path "tests/inferior.scm")
  In ice-9/eval.scm:
  619:8 16 (_ #(#(# #) #))
 293:34 15 (_ #(#(# #) #))
  159:9 14 (_ #(#(# #) #))
  159:9 13 (_ #(#(# #) #))
  In guix/discovery.scm:
  189:3 12 (fold-module-public-variables _ _ _)
  In guix/combinators.scm:
  48:26 11 (fold2 # …)
  48:26 10 (fold2 # …)
  In guix/discovery.scm:
 192:33  9 (_ # …)
  In gnu/packages.scm:
 233:37  8 (_ # …)
  In guix/packages.scm:
1317:17  7 (supported-package? # …)
  In guix/memoization.scm:
  101:0  6 (_ # # …)
  In guix/packages.scm:
1295:37  5 (_)
1555:16  4 (package->bag _ _ _ #:graft? _)
1652:22  3 (thunk)
  In guix/gexp.scm:
 523:11  2 (lower "python-gwcs-0.18.2" #:source _ #:inputs _ # _ . #)
 460:52  1 (%local-file #f # …)
  In unknown file:
 0 (basename #f #)

  ERROR: In procedure basename:
  In procedure scm_to_utf8_stringn: Wrong type argument in position 1 
(expecting string): #f


Other than that, it seems to build fine. I haven't actually tested it
yet.


signature.asc
Description: PGP signature

Re: Licence of the Guix blog posts

[Vagrant Cascadian]

On 2022-11-28, Ludovic Courtès wrote:
> You might remember that I started long ago asking people who had
> contributed to the blog whether they would agree to licensing their work
> under CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant
> Sections, no Front-Cover Texts, and no Back-Cover Texts¹.
...
> Simon, what do you think about emailing the authors of the “10 years of
> stories” post asking if they agree with the licensing?  :-)  No rush,
> though the sooner the more likely we are to get an answer.

Happy for my contribution to be under those licensing terms!

live well,
  vagrant


signature.asc
Description: PGP signature

Re: advanced?

[Vagrant Cascadian]

On 2022-11-26, Simon Josefsson via "Development of GNU Guix and the GNU System 
distribution." wrote:
> I find use of the term 'advanced' wrt Guix confusing and even mildly
> excluding, even though it is wide-spread.  What is advanced about Guix?
> Can I use it even if I'm not an advanced user?  What do others think?
> Is there some historical background for this description of Guix?

Thanks for bringing this up!

It does seem consistent with the guix manual section on package synopsis
and descriptions:

  https://guix.gnu.org/en/manual/devel/en/guix.html#Synopses-and-Descriptions

  Please avoid marketing phrases such as “world-leading”,
  “industrial-strength”, and “next-generation”, and avoid superlatives
  like “the most advanced”—they are not helpful to users looking for a
  package and may even sound suspicious. Instead, try to be factual,
  mentioning use cases and features.

I'm just not sure what stating "advanced" up-front really adds or
improves a brief statement about what guix is...

Reading through your patch, it just seems like an extra word thrown in
hoping for the positive connotations and possibly dragging in some
negative ones (e.g. elitist, not for everybody).

It also makes me wonder if "advanced" will stand the test of
time. Someday Guix-style systems might just be status quo, and thus no
longer advanced. Guix of course will likely evolve over time... maybe it
will still hold qualities worthy of being called "advanced", maybe not.

Reminds me of when I used to work at a computer re-use and recycling
organization, and we would routingly get computers with stickers on them
proclaiming "Blazing fast 400MHz processor" and the likes. Marketing
phrases quickly loose context.


> If we want to use the term, I think it would be better to rephrase
> things as 'Guix supports advanced features such as X, Y and Z' if we
> really want to drive home that we are advanced.

This works for me... describe *why* it is advanced rather than just
proclaiming it.


live well,
  vagrant


signature.asc
Description: PGP signature

WIP branch for MNT/Reform DIY laptop

[Vagrant Cascadian]

I've been working on adding support for MNT/Reform to guix

  https://mnt.re/media/reform_md/2020-05-08-the-much-more-personal-computer.html

Just pushed the wip-mnt-reform branch; all it has is a kernel that I
have sucessfully booted on Debian, so it should be theoretically
possible to build a guix system image with it...

I haven't done extensive testing:

Working:

  Built-in Display
  keyboard
  ethernet
  serial console
  NVMe

Untested:

  Audio
  HDMI (non-FSDG)

There are a couple of FSDG issues, notably the HDMI and boot firmware
require binary blobs. I haven't included support for any of those.

One thing I haven't yet tried is seeing if the default linux-libre for
aarch64-linux; it might at least work with a serial console, though that
isn't much of a laptop. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: guix lint false positives and RFC patch

[Vagrant Cascadian]

On 2022-11-05, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>> From bfa13fdd3616839883e50efbbc05fb132610ce67 Mon Sep 17 00:00:00 2001
>> From: Vagrant Cascadian 
>> Date: Wed, 2 Nov 2022 19:56:12 -0700
>> Subject: [PATCH 01/12] guix: lint: Exclude some "@" symbols from various
>>  checks.
>>
>> The visual representation of "@code{}" or similar in the description and
>> synopsis do not include the string, so exclude it from checks to avoid false
>> positives.
>>
>> FIXME handle @command, @file, @acronym, etc.
>>
>> * guix/linx.scm (properly-starts-sentence): Exclude leading "@".
>>   (check-synopsis-length): Exclude "@code" and "@acronym".
>
> LGTM!  Bonus points for a test in ‘tests/lint.scm’.  :-)

No bonus points for me just yet...

diff --git a/tests/lint.scm b/tests/lint.scm
index ce22e2355a..26e93ca37b 100644
--- a/tests/lint.scm
+++ b/tests/lint.scm
@@ -283,6 +283,16 @@ (define (warning-contains? str warnings)
  (synopsis (make-string 80 #\X)
  (check-synopsis-style pkg

+(test-equal "synopsis: exclude @code from long synopsis"
+  '()
+  (single-lint-warning-message
+   (let ((pkg (dummy-package "x"
+ (synopsis
+  (string-append
+"@code{X}"
+(make-string 72 #\X))
+ (check-synopsis-style pkg
+
 (test-equal "synopsis: start with package name"
   "synopsis should not start with the package name"
   (single-lint-warning-message

The above test doesn't catch this issue, even though the code works on
real packages... I am a bit stumped as to why. I guess '() (or "" which
I also tried) is not a valid way to try to express "this test expects no
warning/error/message/etc."?

Here is a log from the test I cargo-culted:

test-name: synopsis: too long
location: /home/vagrant/src/guix/tests/lint.scm:279
source:
+ (test-equal
+   "synopsis: too long"
+   "synopsis should be less than 80 characters long"
+   (single-lint-warning-message
+ (let ((pkg (dummy-package
+  "x"
+  (synopsis (make-string 80 #\X)
+   (check-synopsis-style pkg
expected-value: "synopsis should be less than 80 characters long"
actual-value: "synopsis should be less than 80 characters long"
result: PASS

And from my test in the patch listed above:

test-name: synopsis: exclude @code from long synopsis
location: /home/vagrant/src/guix/tests/lint.scm:286
source:
+ (test-equal
+   "synopsis: exclude @code from long synopsis"
+   '()
+   (single-lint-warning-message
+ (let ((pkg (dummy-package
+  "x"
+  (synopsis
+(string-append "@code{X}" (make-string 72 #\X))
+   (check-synopsis-style pkg
expected-value: ()
actual-value: #f
actual-error:
+ (match-error "match" "no matching pattern" ())
result: FAIL


What is failing to match what here?


live well,
  vagrant


signature.asc
Description: PGP signature

test suite/ABI issues building guix on Debian (was Re: Release progress, week 3)

[Vagrant Cascadian]

On 2022-11-03, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>>>> test-name: channel-news, no news
>>>> ...
>>>> actual-error:
>>>> + (git-error
>>>> +   #< code: -1 message: "invalid version 0 on 
>>>> git_proxy_options" class: 3>)
>>>> result: FAIL
>>>
>>> This looks like an ABI issue with libgit2.  Are you sure the same
>>> version of libgit2 is used on all these platforms?

Well, rebuilding guix with a freshly built guile-git (against the newer
libgit2) seemed to resolve the issue on at least one build, so will
update in Debian and see if that helps in general...


>> My quick and rough archeaology shows that libgit2-dev
>> 1.1.0+dfsg.1-4.1+b1 was used to build guile-git 0.5.2-4, but the current
>> libgit2-dev package in Debian is 1.5.0+ds-6 ... so that seems plausible.
>
> [...]
>
>> Maybe there is a better way I can track the various guile-* packages in
>> Debian, but manually tracking all the relevent dependents seems
>> implausible (or at least, a lot of work)... which may lead to the
>> conclusion that maintaining Guix in Debian implausible. :/
>
> I don’t see how that’s specific to guile-* packages though.  Anytime a
> dependency is upgraded that introduces a different ABI, you need to
> rebuild dependents, right?  That’s what’s happening here.

Well, sure. I just have not personally maintained many packages that
need to worry about those kinds of headaches too much... Debian still
requires manual intervention to handle it in some form and lacks the
elegance of guix in this regard. :)


>> Seems like the most likely ones I would have to keep a close eye on are
>> guile-gcrypt, guile-git, guile-gnutls (although currently part of gnutls
>> this will likely change soonish), guile-lzlib, guile-ssh, guile-sqlite3,
>> guile-zlib, guile-zstd. And there's also keeping an eye on guile itself,
>> which adds another set of packages. Wheee. Hrm.
>
> Heh.  Speaking of which, guile-gnutls is now a thing of its own,
> separate from GnuTLS:
>
>   https://gitlab.com/gnutls/guile/
>
> I believe Andreas Metzler already update Debian’s guile-gnutls package
> accordingly.

Oh wow, it is already in debian experimental. :)

Will have to try building guix with it, now... and mentally prepare for
the possibility of more test-suite failure wrangling.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: guix lint false positives and RFC patch

[Vagrant Cascadian]

On 2022-11-03, Vagrant Cascadian wrote:
> On 2022-11-03, Ludovic Courtès wrote:
>> Vagrant Cascadian  skribis:
>>
>>> --- a/guix/lint.scm
>>> +++ b/guix/lint.scm
>>> @@ -313,7 +313,8 @@ (define (tests-explicitly-enabled?)
>>>'()))
>>>  
>>>  (define (properly-starts-sentence? s)
>>> -  (string-match "^[(\"'`[:upper:][:digit:]]" s))
>>> +  (string-match "^[(\"'`[:upper:][:digit:]]"
>>> +(string-replace-substring s "@code{" "")))
>>
>> An identifier in @code or file name in @file may legitimately start with
>> a lower-case letter so I don’t think we should try to prevent that.
>>
>> However, maybe we could change the regexp above to something that
>> accepts @ or some other non-letter character at the start?
>
> Great suggestion, as it is simpler, easier to read, and actually covers
> more false positives! Updated patch attached!
>
> I think there was only one case fixed by the @code{} check for the
> synopsis length check, and I don't see any obvious other @*{} checks
> that would currently improve anything, though it would be ideal to make
> it more future-proof just in case... though I think my attempt at that
> would be awfully ugly, help from others would be welcome!

Well, ugly is what I have... Found two packages affected by @acronym.

Also realized that it should leave the {} in the length-matching, as
they are typically replaced by other characters when rendered.


> That said, I think this resolves 52 false positives with guix lint (~10%
> of the 536 synopsis/description issues currently).

Think with this applied there are 54 false positives fixed.

live well,
  vagrant
From bfa13fdd3616839883e50efbbc05fb132610ce67 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 2 Nov 2022 19:56:12 -0700
Subject: [PATCH 01/12] guix: lint: Exclude some "@" symbols from various
 checks.

The visual representation of "@code{}" or similar in the description and
synopsis do not include the string, so exclude it from checks to avoid false
positives.

FIXME handle @command, @file, @acronym, etc.

* guix/linx.scm (properly-starts-sentence): Exclude leading "@".
  (check-synopsis-length): Exclude "@code" and "@acronym".
---
 guix/lint.scm | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/guix/lint.scm b/guix/lint.scm
index 8e3976171f..76b17b297d 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -313,7 +313,7 @@ (define (tests-explicitly-enabled?)
   '()))
 
 (define (properly-starts-sentence? s)
-  (string-match "^[(\"'`[:upper:][:digit:]]" s))
+  (string-match "^[@(\"'`[:upper:][:digit:]]" s))
 
 (define (starts-with-abbreviation? s)
   "Return #t if S starts with what looks like an abbreviation or acronym."
@@ -650,7 +650,10 @@ (define check-start-article
   '()
 
   (define (check-synopsis-length synopsis)
-(if (>= (string-length synopsis) 80)
+(if (>= (string-length (string-replace-substring
+(string-replace-substring synopsis "@acronym" "")
+"@code" ""))
+   80)
 (list
  (make-warning package
(G_ "synopsis should be less than 80 characters long")
-- 
2.35.1



signature.asc
Description: PGP signature

Re: guix lint false positives and RFC patch

[Vagrant Cascadian]

On 2022-11-03, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>
>> --- a/guix/lint.scm
>> +++ b/guix/lint.scm
>> @@ -313,7 +313,8 @@ (define (tests-explicitly-enabled?)
>>'()))
>>  
>>  (define (properly-starts-sentence? s)
>> -  (string-match "^[(\"'`[:upper:][:digit:]]" s))
>> +  (string-match "^[(\"'`[:upper:][:digit:]]"
>> +(string-replace-substring s "@code{" "")))
>
> An identifier in @code or file name in @file may legitimately start with
> a lower-case letter so I don’t think we should try to prevent that.
>
> However, maybe we could change the regexp above to something that
> accepts @ or some other non-letter character at the start?

Great suggestion, as it is simpler, easier to read, and actually covers
more false positives! Updated patch attached!

I think there was only one case fixed by the @code{} check for the
synopsis length check, and I don't see any obvious other @*{} checks
that would currently improve anything, though it would be ideal to make
it more future-proof just in case... though I think my attempt at that
would be awfully ugly, help from others would be welcome!

That said, I think this resolves 52 false positives with guix lint (~10%
of the 536 synopsis/description issues currently).


live well,
  vagrant
From d4ddd4a90f18666352b07a4ebe0ed6b79c74f21e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 2 Nov 2022 19:56:12 -0700
Subject: [PATCH] guix: lint: Exclude some "@" symbols from various checks.

The visual representation of "@code{}" or similar in the description and
synopsis do not include the string, so exclude it from checks to avoid false
positives.

FIXME handle @command, @file, @acronym, etc.

* guix/linx.scm (properly-starts-sentence): Exclude leading "@".
  (check-synopsis-length): Exclude "@code{".
---
 guix/lint.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/guix/lint.scm b/guix/lint.scm
index 8e3976171f..26d8f59a2c 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -313,7 +313,7 @@ (define (tests-explicitly-enabled?)
   '()))
 
 (define (properly-starts-sentence? s)
-  (string-match "^[(\"'`[:upper:][:digit:]]" s))
+  (string-match "^[@(\"'`[:upper:][:digit:]]" s))
 
 (define (starts-with-abbreviation? s)
   "Return #t if S starts with what looks like an abbreviation or acronym."
@@ -650,7 +650,7 @@ (define check-start-article
   '()
 
   (define (check-synopsis-length synopsis)
-(if (>= (string-length synopsis) 80)
+(if (>= (string-length (string-replace-substring synopsis "@code{" "")) 80)
 (list
  (make-warning package
(G_ "synopsis should be less than 80 characters long")
-- 
2.35.1



signature.asc
Description: PGP signature

guix lint false positives and RFC patch

[Vagrant Cascadian]

I've noticed a handful of false positives in guix lint checking
descriptions and synopsis, and tracked several down to the use of
@code{} and similar.

The attached patch partly addresses this, though could definitely be
written better (e.g. handling more cases, also stripping out the
relevent "}", etc.)

This fixes about 11 out of 544 overall guix lint issues with
descriptions and synopsis. Had expected it to fix more issues, but I
think stripping the "@code{" reveals issues in other checks that were
previously hidden maybe.

I will reiterate that this leaves a lot of room for improvement. :)

live well,
  vagrant
From 209c97b91d02831d78fc0b032f3b83fd5e0b9cb1 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 2 Nov 2022 19:56:12 -0700
Subject: [PATCH] guix: lint: Exclude "@code{" from various checks.

The visual representation of the relevent description and synopsis do not
include the string, so exclude it from checks to avoid false positives.

FIXME handle @command, @file, @acronym, etc.

* guix/linx.scm (properly-starts-sentence): Exclude leading "@code{".
  (check-synopsis-length): Exclude "@code{".
---
 guix/lint.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/guix/lint.scm b/guix/lint.scm
index 8e3976171f..4dc35218db 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -313,7 +313,8 @@ (define (tests-explicitly-enabled?)
   '()))
 
 (define (properly-starts-sentence? s)
-  (string-match "^[(\"'`[:upper:][:digit:]]" s))
+  (string-match "^[(\"'`[:upper:][:digit:]]"
+(string-replace-substring s "@code{" "")))
 
 (define (starts-with-abbreviation? s)
   "Return #t if S starts with what looks like an abbreviation or acronym."
@@ -650,7 +651,7 @@ (define check-start-article
   '()
 
   (define (check-synopsis-length synopsis)
-(if (>= (string-length synopsis) 80)
+(if (>= (string-length (string-replace-substring synopsis "@code{" "")) 80)
 (list
  (make-warning package
(G_ "synopsis should be less than 80 characters long")
-- 
2.35.1



signature.asc
Description: PGP signature

Re: Release progress, week 3

[Vagrant Cascadian]

On 2022-11-02, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>
>> On 2022-10-27, Ludovic Courtès wrote:
>>> Release progress: week 3.
>> ...
>>>   • Architectures:
>>>
>>>  - powerpc64le-linux builds are back behind ci.guix, thanks to
>>>Tobias!
>> ...
>>>  - armhf-linux: No progress so far.
>>
>> Not sure where this fits into the release process, but I uploaded a git
>> snapshot to Debian of guix from commit
>> c07b55eb94f8cfa9d0f56cfd97a16f2f7d842652 ...
>
> Yay, thanks!
>
>> All 6 of the failures have the same error:
>>
>> test-name: channel-news, no news
>> ...
>> actual-error:
>> + (git-error
>> +   #< code: -1 message: "invalid version 0 on git_proxy_options" 
>> class: 3>)
>> result: FAIL
>
> This looks like an ABI issue with libgit2.  Are you sure the same
> version of libgit2 is used on all these platforms?

My quick and rough archeaology shows that libgit2-dev
1.1.0+dfsg.1-4.1+b1 was used to build guile-git 0.5.2-4, but the current
libgit2-dev package in Debian is 1.5.0+ds-6 ... so that seems plausible.

Though, curiously, it looks like the amd64 and arm64 packages built
"fine" with these same versions... while i386 and armhf triggered these
issues. Maybe there was some 32-bit specific difference in the newer
libgit2 versions...


Lacking the property of guix where dependency chain changes trigger
package rebuilds... this has to be done manually on Debian when it
matters (e.g. ABI changes)...


Maybe there is a better way I can track the various guile-* packages in
Debian, but manually tracking all the relevent dependents seems
implausible (or at least, a lot of work)... which may lead to the
conclusion that maintaining Guix in Debian implausible. :/


For this specific set of tests, I can rebuild guile-git against the
current libgit2 and then try building guix again ... maybe that will
help.

Though long-term, that means any time one of guix's dependencies (at
least with C library dependencies?) changes in Debian, I'll also have to
rebuild guix in Debian as well... I think.

Seems like the most likely ones I would have to keep a close eye on are
guile-gcrypt, guile-git, guile-gnutls (although currently part of gnutls
this will likely change soonish), guile-lzlib, guile-ssh, guile-sqlite3,
guile-zlib, guile-zstd. And there's also keeping an eye on guile itself,
which adds another set of packages. Wheee. Hrm.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: guile-ssh and libssh updates

[Vagrant Cascadian]

On 2022-10-28, Vagrant Cascadian wrote:
> On 2022-10-28, Vagrant Cascadian wrote:
>> I've been poking at updating guile-ssh to 0.16.0 and libssh to 0.10.4 in
>> guix, but hit a few blockers.
>>
>> Updating guile-ssh to 0.16.0 actually went mostly smoothly, except
>> guix-jupytertest suites fail.
>>
>> Looking at guix-jupyter history, the last build of master was
>> successful, but it doesn't exactly look to have a reliable history of
>> building successfully:
>>
>>   https://ci.guix.gnu.org/search?query=guix-jupyter
>>
>> So I don't know if that should block updating guile-ssh?
>>
>>
>> Updating libssh to 0.10.4 mostly works, but breaks guile-ssh tests:
>>
>>   https://github.com/artyom-poptsov/guile-ssh/issues/34
>>
>> Updating libssh to 0.10.4 with tests disabled for guile-ssh,
>> guix-jupyter and kodi and kodi-wayland fail to build...
>
> For clarity, I used:
>
> ./pre-inst-env guix build --keep-going $(./pre-inst-env guix refresh 
> --list-dependent libssh guile-ssh | cut -d : -f 2 | sed -e 
> 's,guix-daemon,guix,g' | tr ' ' '\n' | grep -v kodi | grep -v jupyter)

This time kodi and whatnot built too, so:

  ./pre-inst-env guix build --keep-going $(./pre-inst-env guix refresh 
--list-dependent libssh guile-ssh | cut -d : -f 2 | sed -e 
's,guix-daemon,guix,g' | tr ' ' '\n'  | grep -v guix-jupyter)

So, really it's only guix-jupyter blocking updating guile-ssh, and the
upstream issue with guile-ssh blocking updating libssh. At least, while
the constellations are aligned in just this exact way...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: guile-ssh and libssh updates

[Vagrant Cascadian]

On 2022-10-28, Vagrant Cascadian wrote:
> I've been poking at updating guile-ssh to 0.16.0 and libssh to 0.10.4 in
> guix, but hit a few blockers.
>
> Updating guile-ssh to 0.16.0 actually went mostly smoothly, except
> guix-jupytertest suites fail.
>
> Looking at guix-jupyter history, the last build of master was
> successful, but it doesn't exactly look to have a reliable history of
> building successfully:
>
>   https://ci.guix.gnu.org/search?query=guix-jupyter
>
> So I don't know if that should block updating guile-ssh?
>
>
> Updating libssh to 0.10.4 mostly works, but breaks guile-ssh tests:
>
>   https://github.com/artyom-poptsov/guile-ssh/issues/34
>
> Updating libssh to 0.10.4 with tests disabled for guile-ssh,
> guix-jupyter and kodi and kodi-wayland fail to build...

For clarity, I used:

./pre-inst-env guix build --keep-going $(./pre-inst-env guix refresh 
--list-dependent libssh guile-ssh | cut -d : -f 2 | sed -e 
's,guix-daemon,guix,g' | tr ' ' '\n' | grep -v kodi | grep -v jupyter)

live well,
  vagrant


signature.asc
Description: PGP signature

guile-ssh and libssh updates

[Vagrant Cascadian]

I've been poking at updating guile-ssh to 0.16.0 and libssh to 0.10.4 in
guix, but hit a few blockers.

Updating guile-ssh to 0.16.0 actually went mostly smoothly, except
guix-jupytertest suites fail.

Looking at guix-jupyter history, the last build of master was
successful, but it doesn't exactly look to have a reliable history of
building successfully:

  https://ci.guix.gnu.org/search?query=guix-jupyter

So I don't know if that should block updating guile-ssh?


Updating libssh to 0.10.4 mostly works, but breaks guile-ssh tests:

  https://github.com/artyom-poptsov/guile-ssh/issues/34

Updating libssh to 0.10.4 with tests disabled for guile-ssh,
guix-jupyter and kodi and kodi-wayland fail to build...

Patches for the two updates attached, though obviously need some work
before applying...


live well,
  vagrant
From 8635c5b9d5e3424331aa553a15811ef316654514 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 27 Oct 2022 13:13:28 -0700
Subject: [PATCH 1/2] gnu: guile-ssh: Update to 0.16.0.

* gnu/packages/ssh.scm (guile-ssh): Update to 0.16.0.
---
 gnu/packages/ssh.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/ssh.scm b/gnu/packages/ssh.scm
index 6a3779ee55..deec5fcc8f 100644
--- a/gnu/packages/ssh.scm
+++ b/gnu/packages/ssh.scm
@@ -318,7 +318,7 @@ (define-public openssh-sans-x
 (define-public guile-ssh
   (package
 (name "guile-ssh")
-(version "0.15.1")
+(version "0.16.0")
 (home-page "https://github.com/artyom-poptsov/guile-ssh;)
 (source (origin
   (method git-fetch)
@@ -328,7 +328,7 @@ (define-public guile-ssh
   (file-name (git-file-name name version))
   (sha256
(base32
-"0zzn5hsf97b35gixyg4z14sspl15qwnp52y4h89wra4y31l7467q"
+"1ka5ayrg7kysx3bi5d8s0z6n12sdc06qp9gc4k9h2mlw3vz187ny"
 (build-system gnu-build-system)
 (outputs '("out" "debug"))
 (arguments
-- 
2.35.1

From 76d628a097731cbfefc52f081c1cbf678df0de25 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 27 Oct 2022 13:18:46 -0700
Subject: [PATCH 2/2] gnu: libssh: Update to 0.10.4.

* gnu/packages/ssh.scm (libssh): Update to 0.10.4.
---
 gnu/packages/ssh.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/ssh.scm b/gnu/packages/ssh.scm
index deec5fcc8f..966de32fce 100644
--- a/gnu/packages/ssh.scm
+++ b/gnu/packages/ssh.scm
@@ -130,7 +130,7 @@ (define-public hss
 (define-public libssh
   (package
 (name "libssh")
-(version "0.9.6")
+(version "0.10.4")
 (source (origin
   (method url-fetch)
   (uri (string-append "https://www.libssh.org/files/;
@@ -138,7 +138,7 @@ (define-public libssh
   "/libssh-" version ".tar.xz"))
   (sha256
(base32
-"16w2mc7pyv9mijjlgacbz8dgczc7ig2m6m70w1pld04vpn2zig46"
+"0zfr9fy4vg1bmz1k836hg9wi20mmaz2sgw61s6464iv1mda2qf87"
 (build-system cmake-build-system)
 (outputs '("out" "debug"))
 (arguments
-- 
2.35.1



signature.asc
Description: PGP signature

Re: Release progress, week 3

[Vagrant Cascadian]

On 2022-10-27, Ludovic Courtès wrote:
> Release progress: week 3.
...
>   • Architectures:
>
>  - powerpc64le-linux builds are back behind ci.guix, thanks to
>Tobias!
...
>  - armhf-linux: No progress so far.

Not sure where this fits into the release process, but I uploaded a git
snapshot to Debian of guix from commit
c07b55eb94f8cfa9d0f56cfd97a16f2f7d842652 ... ppc64le still has not built
yet, and it has the same test suite failures on two 32-bit architectures
(i386 and armhf):

  
https://buildd.debian.org/status/fetch.php?pkg=guix=armhf=1.3.0%2B26756.c07b5-1=1666838910=0
  
https://buildd.debian.org/status/fetch.php?pkg=guix=i386=1.3.0%2B26756.c07b5-1=1666825176=0


Testsuite summary for GNU Guix 1.3.0.26756-c07b5

# TOTAL: 2286
# PASS:  2002
# SKIP:  274
# XFAIL: 4
# FAIL:  6
# XPASS: 0
# ERROR: 0


All 6 of the failures have the same error:

test-name: channel-news, no news
...
actual-error:
+ (git-error
+   #< code: -1 message: "invalid version 0 on git_proxy_options" 
class: 3>)
result: FAIL


Would love to figure out these issues in time for release!


Good news is it built reproducibly (at least on amd64; i386, armhf and
arm64 pending):

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/guix.html

This is partly because the Debian package works around
https://issues.guix.gnu.org/20272 by disabling parallelism in the
build. Sure would be nice if guix was reproducible when built with Guix
too!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Trusted Firmware-A (ARMv8)

[Vagrant Cascadian]

On 2022-10-24, Joshua Branson wrote:
> Kevin Vigouroux via "Development of GNU Guix and the GNU System
> distribution."  writes:
>
>> I would like to install Guix (System) on the Banana Pi M5 [0]. The
>> board is “open source” but not the firmware released by Amlogic [1].
>>
>> The platform (Amlogic Meson S905X3) is currently not supported by the open
>> source project Trusted Firmware-A [2][3].
>>
>> I am a user not an expert and I don’t know what to do.
>>
>
> This kind of question might get a better answer in help-g...@gnu.org.
> :)
>
> Well, if you are trying to preserve your computing freedom, you might
> need to ask how well will the board operate without the closed firmware.
>
> Will wifi work?  Probably not, but you can purchase usb wifi dongles.
>
> Will graphics work... I've no idea.

It is a signed boot firmware, so the board will not work at all without
it. I have managed to get other S905* boards to boot, but it requires
using the vendor-provided signing tools, which include some non-free
blobs. There were attempts to replace that functionality, but as far as
I know they are no longer active:

  https://github.com/afaerber/meson-tools
  https://github.com/angerman/meson64-tools

That particular SoC has not yet been ported to upstream
trusted-firmware-a (a.k.a. arm-trusted-firmware)... not sure how
difficult that would be.

So I don't hold my breath for something fully freedom-respecting from
that family of boards... even though you can probably build more of the
boot firmware from source than many systems people use regularly as they
don't build any part of their boot firmware... a messy world.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Supported architectures

[Vagrant Cascadian]

On 2022-10-07, Efraim Flashner wrote:
> On Thu, Oct 06, 2022 at 04:50:22PM +0200, Ludovic Courtès wrote:

> Firstly, I'd like to mention that we, in general, have a minimum system
> requirement of 2GB of RAM, and IIRC there aren't a lot of armhf boards
> out there which have that much. We do have a difference between building
> natively and cross building / building with '--target'.
>
> I'd like to comment on armhf for a moment. My memory is a but rusty, but
> I'm pretty sure that in December of 2021 mesa was bumped from 21.2.x to
> 21.3.x, and at that time it stopped building on/for armhf. I noticed in
> May of 2022 (5 months later) and got the build working again. That we
> went 5 months without anyone saying anything in bug reports that mesa
> wasn't building shows that either everyone who is using it is using
> software that doesn't use mesa, or we really don't have any armhf-linux
> users. I'm not advocating dropping the architecture, but it does feel
> like we're already at a best-effort level with it. As far as the pieces
> needed for bootstrapping aarch64 software (go and probably others),
> those get built anyway as needed by aarch64, so there's no worry about
> losing support for those software bits.

FWIW, on Debian guix 1.3.0 is currently at risk due to armhf and
i386/i686-linux missings builds due to test suite failures. It has been
hard to keep up with Guix in Debian, especially supporting "obscure"
platforms...

Though I'm guessing there may be reluctance to drop support for
i686-linux... I much more frequently encounter test suite failures when
building it, at least on Debian. It is surely less well supported than
x86_64-linux.

But dropping armhf and i386 at the moment looks ... helpful from a
Debian packaging perspective... :/

I'll try to package a git snapshot of guix and see if that fares any
better and hopefully find and fix issues before the next guix release!

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Capitole du Libre at Toulouse

[Vagrant Cascadian]

On 2022-09-25, Andreas Enge wrote:
> I am not quite sure how one presents a distribution at a booth, since
> there is not really much to attract the eye, or is there?

I know Debian used to have an automated debian-installer running on a
screen looping through all the supported languages of the installer.
Would be cool to implement something similar for Guix someday, but
probably not in a few weeks...

Maybe just a screen capture with large fonts of someone doing some guixy
things and play it on a loop?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: guix lint should support overrides

[Vagrant Cascadian]

On 2022-09-05, zimoun wrote:
> On mer., 24 août 2022 at 14:06, Vagrant Cascadian  wrote:
>
>> Maybe something like:
>>
>> (define-public thispackages
>>   (package
>>(name "thispackages"
>>...
>>(lint-overides
>> (list
>> ;; The upstream name is actually "This Packages", not a typo.
>> "typo in description: 'This Packages' should be 'This Package'")) 
>>
>> And then guix lint would hide or ignore things that would otherwise emit
>> the strings listed in lint-overrides ... or something like that. Maybe
>> exact match, maybe get into a little pattern matching, not
>> sure. Implementation is not my strong point here. :)
>
> Well, it is possible to turn off one specific checker for one package;
> using the ’properties’ field.  However, this “overides” requires more
> work. :-)

Though a single checker may check multiple things, and only get some of
them "wrong"; seems it would be worth having granularity for individual
checks.

> Basically, the wish is for description and synopsis and mainly for typo,
> right?

No, it seems odd to me to restrict this to particular categories of
checks. I would say any specific lint check might have cases where it is
not practical to fix the lint check, yet is not appropriate for a
particular package.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: guix lint should support overrides

[Vagrant Cascadian]

On 2022-08-24, zimoun wrote:
> On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian  wrote:
>
>> But, because there is no way to silence a particular inappropriate
>> suggestion from guix lint, it becomes noise, and each person evaluating
>> the results of the package in the future then needs to take time to
>> figure out if guix lint is wrong, or something should be changed.
>
> Do you have some packages as example?  In order to be concrete about the
> false-positive and how to programatically fix them.

Off the top of my head, no, though it came up in the course of a
convesation on #guix recently, and it reminded me of advice I've gotten
in the past to just ignore a particular check on a particular package.


> For instance, do you mean exclude on specific checker for one specific
> package?

Yes, this! :)

Maybe something like:

(define-public thispackages
  (package
   (name "thispackages"
   ...
   (lint-overides
(list
;; The upstream name is actually "This Packages", not a typo.
"typo in description: 'This Packages' should be 'This Package'")) 

And then guix lint would hide or ignore things that would otherwise emit
the strings listed in lint-overrides ... or something like that. Maybe
exact match, maybe get into a little pattern matching, not
sure. Implementation is not my strong point here. :)

You might also want to add a guix lint check for unused overrides
(e.g. something that no longer triggers the issue, either fixed upstream
in guix lint itself, or some other way).


> Or teach one specific checker for one specific package in
> order to avoid an error specific to this package running this specific
> checker?

No. Maybe in some cases this might make sense, but was not what I was
suggesting.


>> The downside is this becomes one more thing to maintain... in exchange
>> for making the output having a higher degree of relevency in "guix lint"
>> output, so you can be more confident that someone hasn't already looked
>> at a given issue and decided it was best to just ignore it (not that
>> that will not ever happen anymore, but still).
>
> The cost for a poor maintenance is low compared to the benefit, IMHO.
>
> For instance, it is boring to run massive lint:
>
>  1. because “guix lint” does not support the option --manifest
>  2. because “guix lint” reports some false-positive messages

Yeah, my suggestion was mostly about trying to address aspects of point
2.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: FSDG issues of SCUMMVM-based games

[Vagrant Cascadian]

On 2022-08-24, Liliana Marie Prikler wrote:
> Am Mittwoch, dem 24.08.2022 um 14:53 +0200 schrieb Nicolas Goaziou:
>> Liliana Marie Prikler  writes:
>> 
>> > The packages
>> > - drascula,
>> > - lure,
>> > - queen, and
>> > - sky
>> > all share issues that make me question whether they should be in
>> > Guix.
>> > 
>> > 1. Their license explicitly prohibits selling of the games
>> > themselves and may thus be qualified as non-free.
>> > 2. The "sources" consist of binaries that are installed as-is.
>> > 
>> > Given the above, I think we ought not distribute them.  Note that
>> > this is not a statement on SCUMMVM itself, but only the packages
>> > built with it.
>> > 
>> > WDYT?
>> 
>> For the record, I added these games because I agree with Debian
>> packagers on the topic. See
>> <
>> https://metadata.ftp-master.debian.org/changelogs//main/d/drascula/drascula_1.0+ds4-1_copyright
>> >.
> This statement seems to contradict itself.
>> The data included in the source package represents the preferred form
>> for modifications.
>> If they were licensed under the G P L it would fail the "preferred
>> form of modification" requirement
> As far as I'm concerned, "preferred form of modification" should not be
> dependant upon the license in question.

Is it Functional Data:

  https://www.gnu.org/distros/free-system-distribution-guidelines.html

  "For example, some game engines released under the GNU GPL have
  accompanying game information—a fictional world map, game graphics,
  and so on—released under such a verbatim-distribution license. This
  kind of data can be part of a free system distribution, even though
  its license does not qualify as free, because it is non-functional."


> Speaking of the license in question, it's prohibition of selling is
> nowhere mentioned.

It is mentioned in the above link:

"2) You may charge a reasonable copying fee for this archive, and may
distribute it in aggregate as part of a larger & possibly commercial
software distribution (such as a Linux distribution or magazine coverdisk).
You must provide proper attribution and ensure this Readme and all
associated copyright notices, and disclaimers are left intact.
 .
 3) You may not charge a fee for the game itself. This includes reselling the
game as an individual item."

You cannot sell the game itself, but you can charge "a reasonable
copying fee" and distribute it commercially... while slightly confusing
and seemingly contradictory at a passing glance, those two clauses alone
do not appear to violate any of the four freedoms to me:

  https://www.gnu.org/philosophy/free-sw.html#four-freedoms


I'm not really sure you have the right to "sell" most software in GNU
Guix, but you're free to distribute it and even charge for the
distribution of it, and use it in products that you sell to customers.

Most licenses do not give you ownership of the software; they roughly
give you permission to use, study, modify, and share it under the terms
of that license. If you do not own it, I am not sure you can sell it...


live well,
  vagrant


signature.asc
Description: PGP signature

guix lint should support overrides

[Vagrant Cascadian]

I love guix lint! The vast majority of the time I even use it!

But... sometimes a guix lint suggestion isn't appropriate, at which
point it becomes noise for future contributors of that package.

tt might not be possible, or at least not worth the effort, to improve
guix lint to catch that particular case. Sometimes human judgement is
still valuable.

But, because there is no way to silence a particular inappropriate
suggestion from guix lint, it becomes noise, and each person evaluating
the results of the package in the future then needs to take time to
figure out if guix lint is wrong, or something should be changed.

You could add comments to the package about which lint warnings are
inappropriate, but would it be better if you could just override the
suggestion programatically, hiding it from the eyes and minds of the
valuable and limited humans with their great powers of judgement?

Debian's correlary, lintian, has a mechanism to do exactly this, where
you list the various things that aren't appropriate, and can even
comment on why, in a way that lintian basically hides the issue from
further attention.


The downside is this becomes one more thing to maintain... in exchange
for making the output having a higher degree of relevency in "guix lint"
output, so you can be more confident that someone hasn't already looked
at a given issue and decided it was best to just ignore it (not that
that will not ever happen anymore, but still).


Thoughts?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Reproducible Builds Status Summary for Guix

[Vagrant Cascadian]

On 2022-06-12, Vagrant Cascadian wrote:
> I've been working on Reproducible Builds in guix a fair amount this
> month.

I did another round of this...

I fixed a few packages recently, and noticed some other people fixing
packages too, yay!

As of this moment for x86_64, it looks like:

* ~83% matching (a.k.a. reproducible) for 18920 packages
* ~6% not matching (a.k.a. NOT reproducible) for 1337 packages
* ~11% unknown (e.g. not built on both build farms) for 2440 packages

  
https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/package-reproducibility

Ignoring the pesky unknown packages, it is more like ~93% reproducible
and ~7% unreproducible... that feels a bit better to me!

These numbers wander around over time, mostly due to packages moving
back into an "unknown" state while the build farms catch up with each
other... although the above numbers seem to have been pretty consistent
over the last few days.


> Some rough summaries about the types of issues:
>
>   * ecl-* packages account for nearly half of the issues (~500 out of
> ~1000 packages)

More like ~570 out of ~1300 this time.

Apparently there is an upstream issue for ecl, which is referenced in
the summary.

>   * ~850 packages categorized (ecl-* accounting for most of them)

~990 packages reviewed (many duplicates from previous run). Slightly
higher number to review higher this time, mostly due to some previous
unknowns being reproducible/not reproducible.

There are a handful of older-versions of things (e.g. package@1.0 vs
package@2.0) that fail to build reproducibly and I didn't bother to
look, I only checked the most recent versions of packages, so there are
probably 300+ packages that could be reviewed.

>   * 19 packages embed kernel version

22 kernel version

>   * 63 packages embed timestamps

92 timestamps

>   * 52 packages embed dates (harder to reproduce that full timestamps)

46 dates

>   * 5 timestamps in python .pyc files

7 .pyc timestamps

>   * 12 timestamps in .jar files

12 .jar timestamps

>   * 66 ordering issues

82 ordering

>   * 3 ordering issues in .pyc files

3 .pyc ordering

>   * 9 ordering in .jar files

10 .jar ordering

>   * 16 ordering in guile .go files

13 guile .go ordering

>   * ~160 largely unidentified and inscrutible issues

193 unidentified


> This does reveal that there are some opportunities for toolchain fixes,
> fixing multiple packages at a time (and future packages too!), such as
> ecl, sbcl, python, java, guile, clojure, texlive (see FORCE_SOURCE_DATE
> proposal
> https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00171.html ).

Still true!

I tried patching texlive directly and failed to come up with something
that worked, but haven't tried again recently.


> I haven't done extensive cross-referencing with other distros, but
> suspect there may be patches to fix some of these toolchain issues... If
> you've savvy with any of the above languages, help fixing toolchain
> issues would be amazing!

Did a little of this, but still more to do!


> If you're looking to get your hands dirty with some reproducibility
> fixes in guix, a fair number of the timestamp, date and kernel version
> fixes are likely fairly easy, but you generally have to manually verify
> that the date or kernel version aren't embedded, as "guix build
> --rounds=2" will likely happen with the same kernel version and date.

Still very true! Maybe I should arrange a little virtual hackfest or
something...

I should probably normalize these issues a bit more and simplify them,
but the full list I looked should be attached.

Would it be ok to maintain this and some of the relevent tooling in a
branch in guix.git, say, "reproducibility-notes"? Or make a new
repository just for this? It most likely wouldn't share history with the
other branches (much like the "keyring" branch), but presumably won't
grow too large either.


live well,
  vagrant


guix-rb-notes.yml
Description: Binary data


signature.asc
Description: PGP signature

Re: Guix on my ROCKPro64 and on an old Android Tablet

[Vagrant Cascadian]

On 2022-08-13, Tobias Platen wrote:
> Today I began building the Guix System for my ROCKPro64.
> I installed Guix on top of Debian and tried to build uboot, it works:
>
> guix build u-boot-rockpro64-rk3399
> successfully built /gnu/store/g1d4kjgn9b46vqk9mwhd0kc2r6sfi7cz-u-boot-
> rockpro64-rk3399-2022.04.drv
> /gnu/store/90p0yndkj89c5chnri2asj9m46glxq50-u-boot-rockpro64-rk3399-
> 2022.04

Yay!

Interestingly, a significant part of my reason for packaging guix for
Debian was to be able to bootstrap Guix System on arm* devices where
Debian was already working somewhat. :)

I think I've only used that functionality once or twice, though.

I did the opposite with the pinebook pro, where I first got Guix System
running on it, and eventually installed Debian with it. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Set FORCE_SOURCE_DATE=1 by default

[Vagrant Cascadian]

On 2022-07-04, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>> --- a/gnu/packages/tex.scm
>> +++ b/gnu/packages/tex.scm
>> @@ -395,6 +395,12 @@ (define-public texlive-bin
>>   (("srcdir/tests/pprecA-0.ind pprecA-0.ind1 \\|\\| exit 
>> 1")
>>"srcdir/tests/pprecA-0.ind pprecA-0.ind1 || exit 
>> 77")
>>   '())
>> + (add-after 'unpack 'default-to-force-source-date
>> +   ;; 
>> https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00330.html
>> +   (lambda _
>> + ;; texk/web2c/lib/texmfmp.c:  string sde_texprim = getenv 
>> ("FORCE_SOURCE_DATE");
>> + (substitute* "texk/web2c/lib/texmfmp.c"
>> +(("getenv ..FORCE_SOURCE_DATE..") "1"
>
> That looks reasonable to me.  Let us know how your testing goes!

Reasonable, perhaps, but it failed to actually work when I tried it last
month...

Will give it another shot with fresh eyes, although if anyone else wants
to give it a shot, that would be nice too! :)

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Repology and outdated packages

[Vagrant Cascadian]

On 2022-06-07, Nicolas Goaziou wrote:
> kias...@disroot.org writes:
>
>> I've been watching the Repology page for Guix and I've noticed that
>> we've dropped to 51% outdated packages
>> [https://repology.org/repository/gnuguix]. We used to be at 40%
>> outdated packages a few months ago.
>
> Repology hasn't been able to caught Guix package updates for a while
> now. As a consequence, many packages are marked as outdated in Repology
> even though they are not.

I wondered about this again, and was pointed to:

  https://github.com/repology/repology-updater/issues/1261

Appears that where the website is hosted might indirectly (e.g. nobody
explicitly configured this on guix infrastructure) have traffic
originating in Russian blocked...

Wonder if it makes sense to sync the files to multiple sites and put in
round-robin DNS? Apparently it is already available at bayfront.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic

[Vagrant Cascadian]

On 2022-07-14, zimoun wrote:
> Well, dreaming about science fiction, it appears me more approachable to
> have Guix running on something as Debian/kfreeBSD – it could be an
> interesting project with the help of Debian folks.  Other said, “just”
> replace the Linux kernel by a variant of the FreeBSD one running with
> GNU GLibc.

Well, guile-3.0 does not build on Debian GNU/kFreeBSD, so that would be
a bit of a blocker for a GNU Guix port:

  https://buildd.debian.org/guile-3.0

But guile-2.2 built fine:

  https://buildd.debian.org/guile-2.2

It is a rough port, I have toyed with it now and again ... requires lots
of patches to code that assume userland based on running kernel; patches
that upstreams are hesitant to take, etc. It is great as a grueling test
of coding assumptions, though!

My guess is you would have the same sort of problems with porting GNU
Guix to any of the *BSD.

Definitely the sort of project that would take someone highly motivated
over many years...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [WIP Patch] Adding an FHS container to guix shell

[Vagrant Cascadian]

On 2022-07-12, John Kehayias wrote:
> Apologies for the long email, so let me start with the punchline:
> attached is a diff which adds an '--fhs-container' (or -F) option to
> guix shell/environment to set up an FHS-like container. This includes
> the usual /lib directory and a glibc which loads (a generated in the
> container) /etc/ld.so.cache. This should allow running most things
> that expect a more "typical" Linux environment. Give it a try!

Nice!


> 1. Set up directories like /lib. This is easy enough and can be done
> currently, like in roptat's response here [1] by building the profile
> first to know where to link to. Note that it is easier to do it within
> the environment code since we have access to the profile even if it is
> being built for the first time. There are some wrinkles with linking
> something like /bin since we currently add a link for sh; see the
> comments in my diff.
>
> Right now I did not handle a multi-arch setup, though that shouldn't
> be too difficult. This would probably require an option to build
> either all or specified packages for an additional arch, like 32bit in
> a 64bit system, and make the libraries available (/lib32 or
> something). Though may run into a union-build bug [2]?

This might be splitting hairs, but that sounds like a bi-arch setup
e.g. "/lib and /lib32" vs. a multi-arch setup "/lib,
/lib/aarch64-linux-gnu/ and /lib/i386-linux-gnu"

  https://wiki.debian.org/Multiarch

Not sure how many extra hoops you'd need to jump through to make either
work well.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: maradns reproducibility fixes and the merits of picking a random number

[Vagrant Cascadian]

On 2022-07-11, Vagrant Cascadian wrote:
> I hear Efraim say better to have unique randomness and no substitutes,
> and I hear Tobias say more or less it's ok as long as upstream is right
> about it being ok to embed a specific prime as other random numbers get
> mixed in at runtime...

Well, now that I hit send already, I guess another option is ... to have
both?

One package without patches that is not substitutable and not
reproducible, and one with patches that is verifyably reproducible and
substitutable?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: maradns reproducibility fixes and the merits of picking a random number

[Vagrant Cascadian]

On 2022-06-28, Tobias Geerinckx-Rice wrote:
>>I am at a loss as to what to do then ... nothing and just have it be
>>unreproducible? embed a specific random number? come up with better
>>upstreamable patches?
>
> From upstream's response and my own biases and my reading of the room here, 
> I'd say #2.

Hrm.

I hear Efraim say better to have unique randomness and no substitutes,
and I hear Tobias say more or less it's ok as long as upstream is right
about it being ok to embed a specific prime as other random numbers get
mixed in at runtime...

I have a slight inclination towards making it non-substituteable, but I
may just be enamored of this as an interesting solution that most
distributions do not really have the option of taking. :)

Anyone else able to weigh in?

Or actually review the code?

If we can't find someone to review the code, seems like
non-substitutable is the safest approach ... at the guaranteed loss of
reproducibility. :/

Would love to resolve this issue one way or another.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: glibc-locales

[Vagrant Cascadian]

On 2022-07-03, Andreas Enge wrote:
> Am Sun, Jul 03, 2022 at 12:53:09PM +0300 schrieb Efraim Flashner:
>> I misread the source. I'd like glibc-utf8-locales built with glibc-final.
>
> Has glibc-utf8-locales not been removed some time ago? I always had it in
> my profile, then saw a message during upgrade that it had been removed,
> and dropped it from my profile (without any apparent harm to my GNU system).

Still is there as a hidden package and used as an input for some
packages, though this brings up another locales-related question...

Before glibc-utf8-locales was a hidden package, I preferred using that
because it only included a small subset of locales, and happened to
include the main one I needed (lucky me!).

How feasible would it be to make each locale it's own output on
glibc-locales (e.g. glibc-locales:en_US.utf8, or maybe cluster languages
together, e.g. glibc-locales:en) ? Most people probably only use a
relatively small number of locales on any given system... though which
locales any given person uses probably varies.

Is it a complexity vs. space-savings issue? Would it be tricky to
compose multiple locales packages into a single profile? Just not worth
the effort?

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Set FORCE_SOURCE_DATE=1 by default

[Vagrant Cascadian]

On 2022-06-23, Maxim Cournoyer wrote:
>>> Perhaps to show our stand here we could patch our copy of pdftex with
>>> 's/FORCE_SOURCE_DATE/SOURCE_DATE_EPOCH/', lest we end up with a grocery
>>> list of *SOURCE_DATE* variable variants.
>>
>> Sure, with some technical details fixed up, as I think they are
>> functionally different, in that FORCE_SOURCE_DATE is a boolean, and
>> SOURCE_DATE_EPOCH is an integer, though ... Guix sets
>> SOURCE_DATE_EPOCH=1 ... so it might just work by dumb luck! Though There
>> may be some rare packages that need SOURCE_DATE_EPOCH to be some larger
>> value...  "It can't possibly be 1970, this program was first written in
>> 2002, there must be some error, failing build..."
>>
>> At any rate, if diverging from upstream Tex Live is how Guix wants to
>> handle this, I'm all for it!
>
> Seems we have a small consensus here (Ludo, you and myself); would you
> like to give it a try?

My first naive attempt appeared to build, but failed lots of test
suites... so that clearly needs some more work!

diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm
index f6b4c25595..e8c99d202b 100644
--- a/gnu/packages/tex.scm
+++ b/gnu/packages/tex.scm
@@ -395,6 +395,12 @@ (define-public texlive-bin
  (("srcdir/tests/pprecA-0.ind pprecA-0.ind1 \\|\\| exit 1")
   "srcdir/tests/pprecA-0.ind pprecA-0.ind1 || exit 77")
  '())
+ (add-after 'unpack 'default-to-force-source-date
+   ;; 
https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00330.html
+   (lambda _
+ ;; texk/web2c/lib/texmfmp.c:  string sde_texprim = getenv 
("FORCE_SOURCE_DATE");
+ (substitute* "texk/web2c/lib/texmfmp.c"
+(("getenv ..FORCE_SOURCE_DATE..") "1"
  (add-after 'unpack 'unpack-texlive-extra
(lambda* (#:key inputs #:allow-other-keys)
  (mkdir "texlive-extra")


No idea if this approach would have any side-effects ... there is some
code that checks if both FORCE_SOURCE_DATE and SOURCE_DATE_EPOCH are set
... but i *think* this is the only spot where it directly checks if
FORCE_SOURCE_DATE is set. It would also be good to support
FORCE_SOURCE_DATE=0 if there is in fact some real-world use-case with
SOURCE_DATE_EPOCH is set and FORCE_SOURCE_DATE should be "0".

I'll try with tests disabled to see if it at least fixes the issue in
the two packages (itpp, discrover) that manually set FORCE_SOURCE_DATE.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: maradns reproducibility fixes and the merits of picking a random number

[Vagrant Cascadian]

On 2022-06-28, Gábor Boskovits wrote:
> Tobias Geerinckx-Rice  ezt írta (időpont: 2022. jún. 28., K
> 18:07):
>> Vagrant said:
>> > It is expensive to generate the random prime on some hardware, so doing
>> > so at runtime might not be feasible in some cases...
>>
>> But in the same reply you're paraphrasing, upstream also says:
>>
>> > In 2010, I updated that homegrown hash compression
>> > algorithm to also add a random number when compressing
>> > the input, and calculating another 32-bit random number
>> > when Deadwood starts.
>> ^^^
>>
>> and
>>
>> > I believe the hash compression algorithm is protected from hash
>> > bucket collision attacks, even if Deadwood is patched to make
>> > MUL_CONSTANT a constant number, since the add constant
>> > remains random.
>>
>> so their 'too computationally expensive' does not make sense to me.  Do
>> they bail out if generating the truly random part 'takes too long'?  Surely
>> not.
>>
>> Neither does the 'ah, but your urandom might be broken' argument for
>> silently substituting a still less random number.

Yeah, the response was a bit confusing to me, at least. :)


>> I don't think this alone justifies the scheme, or disabling substitutes.

I am at a loss as to what to do then ... nothing and just have it be
unreproducible? embed a specific random number? come up with better
upstreamable patches?


> I tend to agree.
> Afaics this can be solved in a workaround way. I don't think this random
> number is picked up by the build in any way.

What do you mean? The whole reason I discovered this issue is that it
embeds a random number in the build, making it not build reproducibly...


> Upstream could just provide it as an optional config value. That would
> be better in every respect.  Then they could just give a build flag to
> move to the new model.

That sounds reasonable to me...


> Do you think such a proposal would be accepted upstream?

I hope something better would be accepted upstream, but I don't myself
use maradns, and have a grand total of precisely one interaction with
maradns upstream so far... :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: maradns reproducibility fixes and the merits of picking a random number

[Vagrant Cascadian]

On 2022-06-22, Vagrant Cascadian wrote:
> On 2022-06-08, Vagrant Cascadian wrote:
>> On 2022-06-08, Efraim Flashner wrote:
>>> On Tue, Jun 07, 2022 at 07:20:25AM +0200, Julien Lepiller wrote:
>>>> On June 7, 2022 5:24:22 AM GMT+02:00, Felix Lechner 
>>>>  wrote:
>>>> >On Mon, Jun 6, 2022 at 6:50 PM Vagrant Cascadian
>>>> > wrote:
>>> This is something we can work with. We can just mark the package as
>>> '#:substitutable? #f' and then everyone will have to build it
>>> themselves. It still won't really be reproducible, but everyone will
>>> actually have their own special random number.
>>
>> This actually seems like the best approach in the short term! Leaving
>> time to work out a better fix long-term, probably by working with
>> upstream...
>>
>> Thoughts?
>
> Should I just push that part for the short-term workaround? Or does
> someone else want to push that?
>
>
>>>> >MaraDNS does not support DNSSEC so the program may not use entropy for
>>>> >keys. Either way, I'd rather use an unreproducible build than,
>>>> >accidentally, a known number series to encrypt secrets. Can one patch
>>>> >out the constant entirely so it is no longer available?
>>>> >
>>>> >The upstream website says: "People like MaraDNS because it’s ...
>>>> >remarkably secure." [1] Since many distributions have the same issue,
>>>> >upstream could perhaps offer the patch as a build switch to enable a
>>>> >build-time seed only when needed.
>>>> 
>>>> Sounds like the safest option. Maybe we could change the code that uses 
>>>> that number to naise an exception or abort?
>>
>> Yeah, seems worth taking this or similar ideas upstream...
>
> And, this was the best place I found to mention this issue upstream,
> will see what kind of response I get:
>
>   https://github.com/samboy/MaraDNS/discussions/101#discussioncomment-3006487

Upstream appears to think it is mostly ok to actually embed a specific
random prime... and not have it be different across all the builds, as
the number is mixed with other randomness from /dev/urandom.

It is expensive to generate the random prime on some hardware, so doing
so at runtime might not be feasible in some cases...

So, where do we go from here, knowing what we now know? :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: maradns reproducibility fixes and the merits of picking a random number

[Vagrant Cascadian]

On 2022-06-08, Vagrant Cascadian wrote:
> On 2022-06-08, Efraim Flashner wrote:
>> On Tue, Jun 07, 2022 at 07:20:25AM +0200, Julien Lepiller wrote:
>>> On June 7, 2022 5:24:22 AM GMT+02:00, Felix Lechner 
>>>  wrote:
>>> >On Mon, Jun 6, 2022 at 6:50 PM Vagrant Cascadian
>>> > wrote:
>> This is something we can work with. We can just mark the package as
>> '#:substitutable? #f' and then everyone will have to build it
>> themselves. It still won't really be reproducible, but everyone will
>> actually have their own special random number.
>
> This actually seems like the best approach in the short term! Leaving
> time to work out a better fix long-term, probably by working with
> upstream...
>
> Thoughts?

Should I just push that part for the short-term workaround? Or does
someone else want to push that?


>>> >MaraDNS does not support DNSSEC so the program may not use entropy for
>>> >keys. Either way, I'd rather use an unreproducible build than,
>>> >accidentally, a known number series to encrypt secrets. Can one patch
>>> >out the constant entirely so it is no longer available?
>>> >
>>> >The upstream website says: "People like MaraDNS because it’s ...
>>> >remarkably secure." [1] Since many distributions have the same issue,
>>> >upstream could perhaps offer the patch as a build switch to enable a
>>> >build-time seed only when needed.
>>> 
>>> Sounds like the safest option. Maybe we could change the code that uses 
>>> that number to naise an exception or abort?
>
> Yeah, seems worth taking this or similar ideas upstream...

And, this was the best place I found to mention this issue upstream,
will see what kind of response I get:

  https://github.com/samboy/MaraDNS/discussions/101#discussioncomment-3006487


live well,
  vagrant


signature.asc
Description: PGP signature