[bug#76098] The next release

  We discussed the next release during Guix Days and I volunteered to lead
the effort.

The short version:

* We need a tagged release so we can update the version in Debian and
  other distros, in CI systems, etc.
* We need a newer point-in-time for the installer.
* A new release increases interest in the project.

I've opened bug #76098 with a couple of patches but I figured it would
be better if I wrote here instead.

In the process toward a new release I took a look at the 'release' make
target and the release.scm manifest to start.

In the Makefile:
* Added riscv64-linux as a supported system
* switch the assert-binaries-available make target we've used previously
  to make sure we have substitutes for a base set of packages to point
  to the installer manifest.  If the purpose of the installer is to
  install and then everyone expected to run `guix pull` then we need the
  packages from the installer.

release.scm:
I don't have a real good use for this manifest currently, but I've made
some changes anyway:
* %base-packages already existed in (gnu system), and that seemed like a
  good list of packages that we would need.  This increased the list of
  packages.
* %system-packages: The note mentioned the installer, so I copied the
  work I did on the installer.scm to this list.  This also increased the
  list of packages.

installer.scm:
A manifest which only checks that we have substitutes for what can be
installed using the TUI installer (assuming no extra added items).  It
differs from the GUIX_SYSTEM_INSTALLER_SYSTEM variable in the Makefile
by including aarch64 as an architecture.  Ideally all the packages
should compile, which would allow someone to run the installer
successfully for x86_64-linux, i686-linux or aarch64-linux.  Currently
everything is in one big manifest, but I think it would be better if we
didn't do that, which would allow anyone to try to build the manifest
only on architectures they are interested in/able to fix.  Then we could
(using the cuirass interface) set which architectures to try to build
the manifest.

cross-compile.scm:
Ideally all the packages one would need to produce an OS image for
another architecture we support, or the same %base-packages for other
architectures we have.  Currently it only tests from x86_64-linux.

Ideally I'd like to see the installer.scm and cross-compile.scm
manifests added to Cuirass.  I'd hope we could keep 100% build on
installer.scm so we can actually offer all the options in the installer,
and the cross-compile.scm manifest might need to be split so we can
focus on cross-compiling an OS config vs cross-compiling binaries for
another architecture.
  

On 2025-02-11, Efraim Flashner wrote:
> We discussed the next release during Guix Days and I volunteered to lead
> the effort.

Thanks for working on it!

> The short version:
>
> * We need a tagged release so we can update the version in Debian and
>   other distros, in CI systems, etc.

Unless this happens very, very quickly(e.g. a week or two?), I am not
sure we will have this in time for Debian, which is about to enter
freeze for preparing the next release of Debian...

I may just make an attempt at making a git snapshot or something, which
I did once in the distant past... any recommendations on a particular
commit to aim at? Even an alpha or release candidate or whatever tag
would be nice...

live well,
  vagrant
  

Hi Efraim,

Efraim Flashner <efraim@flashner.co.il> skribis:

> The short version:
>
> * We need a tagged release so we can update the version in Debian and
>   other distros, in CI systems, etc.
> * We need a newer point-in-time for the installer.
> * A new release increases interest in the project.

Thanks a lot for getting the ball rolling!

One thing we discussed in Brussels is the need for more automation so
that pretty much anyone can make a release without having special
privileges and without spending an entire day building release
artifacts.

The main blocker is the two-step process with the ‘guix’ package update.
We briefly discussed the use of ‘current-guix’ as a way to bypass that.
(gnu services install) already uses it for the installer itself; the
next step would be to use it in the installed image and thus, possibly,
unconditionally.  The main reason why this is not done currently is that
it’s too expensive (equivalent to ‘guix pull’), but we could probably
address that.

I’m willing to give a hand in this area over the coming weeks.

Thanks,
Ludo’.
  

Hello,

I think something we need to do urgently is to run an ungrafting
process - grafting takes a considerable amount of time when updating my
system now, and I suppose it will also waste a bit of space. We should
not burden the installation process with it.

Did we not have a jobset on ci to automate this?

As said in Brussels, I would be happy to test a new installation image
on a further x86_64 I would like to get running Guix.

Andreas
  

On 2025-02-15, Vagrant Cascadian wrote:
> On 2025-02-11, Efraim Flashner wrote:
>> We discussed the next release during Guix Days and I volunteered to lead
>> the effort.
...
> I may just make an attempt at making a git snapshot or something, which
> I did once in the distant past... any recommendations on a particular
> commit to aim at? Even an alpha or release candidate or whatever tag
> would be nice...

So, in order to try this, the first thing I needed to do was remember
how to run "make dist" to generate the tarball...

Basically from a clean git checkout:

  guix git tag v1.4.0+XYZ HEAD # I used f7cd085f4a36e118aa05af5524e74830a30b3dca
  guix git authenticate && \
  guix shell --container --pure --development guix guix git imagemagick perl graphviz less -- ./bootstrap && \
  guix shell --container --pure --development guix guix git imagemagick perl graphviz less -- ./configure && \
  guix shell --container --pure --development guix guix git imagemagick perl graphviz less -- make -j1 dist

Not sure if that is the "right" way or if there is better
documentation... ?

Running "make -j5 dist" failed in various ways... so there are probably
some undefined dependencies.

graphviz was needed otherwise the bootstrap-graph.pdf failed to build
(graphviz-minimal gets pulled in by "--development guix" but does not
support .pdf generation).

The other inputs, well, they're just from the last times I tried running
"make dist"! maybe they are no longer needed, maybe the are!


The generated tarball also appears to be missing a few files, some of
which seem fine (e.g. .gitignore) but some which actually cause problems
(e.g. missing po4a.cfg, tests/*.scm, gnu/patches/*.patch), some of which
probably should be added to dist_patch_DATA in gnu/local.mk or other
relevent values:

  Only in ../guix-master/build-aux: cuirass
  Only in ../guix-master/build-aux: gitlog-to-changelog
  Only in ../guix-master: .editorconfig
  Only in ../guix-master/etc: copyright.el
  Only in ../guix-master/etc: git
  Only in ../guix-master/etc: snippets
  Only in ../guix-master/etc: teams
  Only in ../guix-master/etc: teams.scm
  Only in ../guix-master: .gitattributes
  Only in ../guix-master: .gitignore
  Only in ../guix-master/gnu/packages/patches: cyrus-sasl-ac-try-run-fix.patch
  Only in ../guix-master/gnu/packages/patches: gcc-10-tree-sra-union-handling.patch
  Only in ../guix-master/gnu/packages/patches: gegl-compatibility-old-librsvg.patch
  Only in ../guix-master/gnu/packages/patches: go-github-com-skip2-go-qrcode-fix-tests.patch
  Only in ../guix-master/gnu/packages/patches: librewolf-neuter-locale-download.patch
  Only in ../guix-master/gnu/packages/patches: openjdk-15-jtask-reproducibility.patch
  Only in ../guix-master/gnu/packages/patches: python-pytorch-for-r-torch-fix-codegen.patch
  Only in ../guix-master/gnu/packages/patches: python-pytorch-for-r-torch-system-libraries.patch
  Only in ../guix-master/gnu/packages/patches: rdkit-unbundle-external-dependencies.patch
  Only in ../guix-master/gnu/packages/patches: tinydir-fix-cbehave-test.patch
  Only in ../guix-master/gnu/system/examples: bare-hurd64.tmpl
  Only in ../guix-master/gnu/system/examples: devel-hurd64.tmpl
  Only in ../guix-master/gnu/system/examples: devel-hurd.tmpl
  Only in ../guix-master/gnu/tests: lightdm.scm
  Only in ../guix-master/gnu/tests: sddm.scm
  Only in ../guix-master: .mailmap
  Only in ../guix-master: .mumi
  Only in ../guix-master/nix: .gitignore
  Only in ../guix-master/nix/libstore: .gitignore
  Only in ../guix-master: .patman
  Only in ../guix-master/po/doc: po4a.cfg
  Only in ../guix-master/tests: hexpm.scm
  Only in ../guix-master/tests: ipfs.scm


I also fixed a bunch of typos, spelling, grammar, etc. that my workflow
building Guix in Debian detects in various package
synopsis/descriptions, and seem to have inspired others to do the same!
:)


In this process I also found a bug that caused "make dist" to fail due
to embedded store paths, and pushed a fix to guix.git as
0626f567378cf549fd097f3c3372fa498000a8a3.


Also, in reviewing the copyright and license headers while packaging for
Debian, this raised a broader question about translating license headers
in files such as doc/guix.de.info:

  https://salsa.debian.org/debian/guix/-/blob/debian/latest/doc/guix.de.info#L93

With my limited german, it is clearly a header to declare the file is
released under the GFDL in some form, but I wonder if that is a good
idea to translate the license headers ... as at least in the US, in
order to ship that file I would maybe need to at least consult with a
lawyer (the US only recognizes English for legal documents), and I
suspect various other countries might need something similar for
arbitrary languages... having to get a lawyer involved kind of kills the
joy of free software and the goal of free distribution...

This of course touches on some awful issues around language
imperialism. :/


live well,
  vagrant
  

Hi Vagrant,

Vagrant Cascadian <vagrant@debian.org> writes:

> On 2025-02-15, Vagrant Cascadian wrote:
>
> The generated tarball also appears to be missing a few files, 
> some of
> which seem fine (e.g. .gitignore) but some which actually cause 
> problems
> (e.g. missing po4a.cfg, tests/*.scm, gnu/patches/*.patch), some 
> of which
> probably should be added to dist_patch_DATA in gnu/local.mk or 
> other
> relevent values:
>
>   Only in ../guix-master/gnu/packages/patches: 
>   librewolf-neuter-locale-download.patch
>

135.0.1-1 released today and I’m prepping patches for it, I can 
include this fix if nobody beats me to it.

Can we glob so everything in gnu/packages/patches gets pulled in? 
It feels odd to maintain a separate list, presumably the patches 
wouldn’t be in there if something didn’t need them.

Thanks,
  -- Ian
  

Also, thank you for tackling this!

  -- Ian
  

On 2025-02-19, Vagrant Cascadian wrote:
> Also, in reviewing the copyright and license headers while packaging for
> Debian, this raised a broader question about translating license headers
> in files such as doc/guix.de.info:
>
>   https://salsa.debian.org/debian/guix/-/blob/debian/latest/doc/guix.de.info#L93
>
> With my limited german, it is clearly a header to declare the file is
> released under the GFDL in some form, but I wonder if that is a good
> idea to translate the license headers ... as at least in the US, in
> order to ship that file I would maybe need to at least consult with a
> lawyer (the US only recognizes English for legal documents), and I
> suspect various other countries might need something similar for
> arbitrary languages... having to get a lawyer involved kind of kills the
> joy of free software and the goal of free distribution...

For clarity, the US does recognize contracts and whatnot under other
languages, but requires a *certified* translation of the document into
English, which may also require getting legal counsel and in my opinion,
kind of defeats the purpose of free software at that point... as one
cannot freely share it without fear of undue legal burdens...

At least, that is my entirely not-a-lawyer concern...

Since this is only shipped in this form whe running "make dist"
... well, seems relevent for the release process. :)

live well,
  vagrant
  

On Mon, Feb 17, 2025 at 02:48:59PM +0100, Andreas Enge wrote:
> Hello,
> 
> I think something we need to do urgently is to run an ungrafting
> process - grafting takes a considerable amount of time when updating my
> system now, and I suppose it will also waste a bit of space. We should
> not burden the installation process with it.
> 
> Did we not have a jobset on ci to automate this?
> 
> As said in Brussels, I would be happy to test a new installation image
> on a further x86_64 I would like to get running Guix.

We do have an ungrafting job, but it needs to be tweaked to exclude the
glibc graft.  I agree that we need to do an ungrafting run before a
release but I'm not sure we're at the pre-release ungraft yet.  An
ungraft run in general would be a good thing.
  

On Wed, Feb 19, 2025 at 02:06:43PM -0800, Vagrant Cascadian wrote:
> On 2025-02-15, Vagrant Cascadian wrote:
> > On 2025-02-11, Efraim Flashner wrote:
> >> We discussed the next release during Guix Days and I volunteered to lead
> >> the effort.
> ...
> > I may just make an attempt at making a git snapshot or something, which
> > I did once in the distant past... any recommendations on a particular
> > commit to aim at? Even an alpha or release candidate or whatever tag
> > would be nice...
> 
> So, in order to try this, the first thing I needed to do was remember
> how to run "make dist" to generate the tarball...
> 
> Basically from a clean git checkout:
> 
>   guix git tag v1.4.0+XYZ HEAD # I used f7cd085f4a36e118aa05af5524e74830a30b3dca
>   guix git authenticate && \
>   guix shell --container --pure --development guix guix git imagemagick perl graphviz less -- ./bootstrap && \
>   guix shell --container --pure --development guix guix git imagemagick perl graphviz less -- ./configure && \
>   guix shell --container --pure --development guix guix git imagemagick perl graphviz less -- make -j1 dist
> 
> Not sure if that is the "right" way or if there is better
> documentation... ?

I think there is/was a 'make dist' cuirass job, but I've never actually
looked at it closely.  The guix.scm and manifest.scm both are in use,
but I could see putting together a make-dist.scm manifest, probably in
etc/manifests, and then documenting (somewhere) that it exists.  Or
putting the command in as a comment in the Makefile.

> Running "make -j5 dist" failed in various ways... so there are probably
> some undefined dependencies.
> 
> graphviz was needed otherwise the bootstrap-graph.pdf failed to build
> (graphviz-minimal gets pulled in by "--development guix" but does not
> support .pdf generation).
> 
> The other inputs, well, they're just from the last times I tried running
> "make dist"! maybe they are no longer needed, maybe the are!
> 
> 
> The generated tarball also appears to be missing a few files, some of
> which seem fine (e.g. .gitignore) but some which actually cause problems
> (e.g. missing po4a.cfg, tests/*.scm, gnu/patches/*.patch), some of which
> probably should be added to dist_patch_DATA in gnu/local.mk or other
> relevent values:
> 
>   Only in ../guix-master/build-aux: cuirass
>   Only in ../guix-master/build-aux: gitlog-to-changelog
>   Only in ../guix-master: .editorconfig
>   Only in ../guix-master/etc: copyright.el
>   Only in ../guix-master/etc: git
>   Only in ../guix-master/etc: snippets
>   Only in ../guix-master/etc: teams
>   Only in ../guix-master/etc: teams.scm
>   Only in ../guix-master: .gitattributes
>   Only in ../guix-master: .gitignore
>   Only in ../guix-master/gnu/packages/patches: cyrus-sasl-ac-try-run-fix.patch
>   Only in ../guix-master/gnu/packages/patches: gcc-10-tree-sra-union-handling.patch
>   Only in ../guix-master/gnu/packages/patches: gegl-compatibility-old-librsvg.patch
>   Only in ../guix-master/gnu/packages/patches: go-github-com-skip2-go-qrcode-fix-tests.patch
>   Only in ../guix-master/gnu/packages/patches: librewolf-neuter-locale-download.patch
>   Only in ../guix-master/gnu/packages/patches: openjdk-15-jtask-reproducibility.patch
>   Only in ../guix-master/gnu/packages/patches: python-pytorch-for-r-torch-fix-codegen.patch
>   Only in ../guix-master/gnu/packages/patches: python-pytorch-for-r-torch-system-libraries.patch
>   Only in ../guix-master/gnu/packages/patches: rdkit-unbundle-external-dependencies.patch
>   Only in ../guix-master/gnu/packages/patches: tinydir-fix-cbehave-test.patch
>   Only in ../guix-master/gnu/system/examples: bare-hurd64.tmpl
>   Only in ../guix-master/gnu/system/examples: devel-hurd64.tmpl
>   Only in ../guix-master/gnu/system/examples: devel-hurd.tmpl
>   Only in ../guix-master/gnu/tests: lightdm.scm
>   Only in ../guix-master/gnu/tests: sddm.scm
>   Only in ../guix-master: .mailmap
>   Only in ../guix-master: .mumi
>   Only in ../guix-master/nix: .gitignore
>   Only in ../guix-master/nix/libstore: .gitignore
>   Only in ../guix-master: .patman
>   Only in ../guix-master/po/doc: po4a.cfg
>   Only in ../guix-master/tests: hexpm.scm
>   Only in ../guix-master/tests: ipfs.scm

I saw a suggestion elsewhere to use pattern globbing for some stuff in
the Makefile. I only saw files ending in .patch in gnu/packages/patches,
and apparently we have over 1500 files there.  I'm guessing we could do
something similar with the .tmpl files in gnu/system/examples and
perhaps other places too.

> 
> I also fixed a bunch of typos, spelling, grammar, etc. that my workflow
> building Guix in Debian detects in various package
> synopsis/descriptions, and seem to have inspired others to do the same!
> :)

The package python-codespell has the codespell binary, and is something
I use occasionally to find typos.

> In this process I also found a bug that caused "make dist" to fail due
> to embedded store paths, and pushed a fix to guix.git as
> 0626f567378cf549fd097f3c3372fa498000a8a3.
> 
> 
> Also, in reviewing the copyright and license headers while packaging for
> Debian, this raised a broader question about translating license headers
> in files such as doc/guix.de.info:
> 
>   https://salsa.debian.org/debian/guix/-/blob/debian/latest/doc/guix.de.info#L93
> 
> With my limited german, it is clearly a header to declare the file is
> released under the GFDL in some form, but I wonder if that is a good
> idea to translate the license headers ... as at least in the US, in
> order to ship that file I would maybe need to at least consult with a
> lawyer (the US only recognizes English for legal documents), and I
> suspect various other countries might need something similar for
> arbitrary languages... having to get a lawyer involved kind of kills the
> joy of free software and the goal of free distribution...
> 
> This of course touches on some awful issues around language
> imperialism. :/
> 
> 
> live well,
>   vagrant
  

Hello Vagrant.

Vagrant Cascadian <vagrant@debian.org> writes:
> Also, in reviewing the copyright and license headers while packaging for
> Debian, this raised a broader question about translating license headers
> in files such as doc/guix.de.info:
>
>   https://salsa.debian.org/debian/guix/-/blob/debian/latest/doc/guix.de.info#L93
>
> With my limited german, it is clearly a header to declare the file is
> released under the GFDL in some form, but I wonder if that is a good
> idea to translate the license headers ... as at least in the US, in
> order to ship that file I would maybe need to at least consult with a
> lawyer (the US only recognizes English for legal documents), and I
> suspect various other countries might need something similar for
> arbitrary languages... having to get a lawyer involved kind of kills the
> joy of free software and the goal of free distribution...
>
> This of course touches on some awful issues around language
> imperialism. :/
>
> […]
> For clarity, the US does recognize contracts and whatnot under other
> languages, but requires a *certified* translation of the document into
> English, which may also require getting legal counsel and in my opinion,
> kind of defeats the purpose of free software at that point... as one
> cannot freely share it without fear of undue legal burdens...
> 
> At least, that is my entirely not-a-lawyer concern...
> 
> Since this is only shipped in this form whe running "make dist"
> ... well, seems relevent for the release process. :)
> 
> live well,
>   vagrant

We should translate license notices.  It is harmless.

My German translation of the GFDL header is derived from unofficial
translations of older GFDL version 1.2, linked at German Wikipedia and
clearly uncertified.

IANAL neither, but my defense of the current translated license headers
in manual, website and such would be that translated manual, website are
clearly marked as a translation in the first paragraph or website
header.  Clearly the original license applies and in some sentences the
translator also has copyright.  More clearly, deviation from the license
text in translations is an error.  The full English license is still
part of doc/guix.de.info and other languages.  So the English license
would likely apply.

Generally translation seems not to be a source of dispute in court.  I
believe I remember in court cases of Software Freedom Conservancy, all
parties agreed to use an unofficial German GPL translation.  So
generally translation seems not to be a source of dispute.  But I could
not anymore find example cases.  It was not the VMWare lawsuit.

Regards,
Florian
  

Efraim Flashner <efraim@flashner.co.il> skribis:

> On Mon, Feb 17, 2025 at 02:48:59PM +0100, Andreas Enge wrote:
>> Hello,
>> 
>> I think something we need to do urgently is to run an ungrafting
>> process - grafting takes a considerable amount of time when updating my
>> system now, and I suppose it will also waste a bit of space. We should
>> not burden the installation process with it.
>> 
>> Did we not have a jobset on ci to automate this?
>> 
>> As said in Brussels, I would be happy to test a new installation image
>> on a further x86_64 I would like to get running Guix.
>
> We do have an ungrafting job, but it needs to be tweaked to exclude the
> glibc graft.

I had to turn off that jobset shortly after activating it because the
‘glibc’ graft landed and it would have caused massive rebuilds without a
clear way to get things merged (in fact, the glibc change is not
“ungraftable” in the trivial way because it uses ‘git-fetch’, which
would cause circular dependencies on old daemons).

> I agree that we need to do an ungrafting run before a release but I'm
> not sure we're at the pre-release ungraft yet.  An ungraft run in
> general would be a good thing.

Yes.  The way I see it, this can be done on ‘core-packages-team’ this
time.

Ludo’.
  

Hi,

Vagrant Cascadian <vagrant@debian.org> skribis:

> The generated tarball also appears to be missing a few files, some of
> which seem fine (e.g. .gitignore) but some which actually cause problems
> (e.g. missing po4a.cfg, tests/*.scm, gnu/patches/*.patch), some of which
> probably should be added to dist_patch_DATA in gnu/local.mk or other
> relevent values:

Do you plan to submit a patch for this?

Thanks for working on this!

Ludo’.
  

On 2025-02-23, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant@debian.org> skribis:
>
>> The generated tarball also appears to be missing a few files, some of
>> which seem fine (e.g. .gitignore) but some which actually cause problems
>> (e.g. missing po4a.cfg, tests/*.scm, gnu/patches/*.patch), some of which
>> probably should be added to dist_patch_DATA in gnu/local.mk or other
>> relevent values:
>
> Do you plan to submit a patch for this?
>
> Thanks for working on this!

I pushed some fixes to guix git; there are still open questions:

  https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00395.html

Here are all my outstanding questions:

  build-aux/cuirass
  build-aux/gitlog-to-changelog
  etc/copyright.el
  etc/git
  etc/snippets
  etc/teams
  etc/teams.scm

Should these be in the tarball at all? If so, where do we add them?

  gnu/packages/patches/cyrus-sasl-ac-try-run-fix.patch
  gnu/packages/patches/gcc-10-tree-sra-union-handling.patch
  gnu/packages/patches/gegl-compatibility-old-librsvg.patch

Probably should just be deleted, not referenced in the code
anywhere... or am I missing something?

  gnu/tests/lightdm.scm
  gnu/tests/sddm.scm
  po/doc/po4a.cfg
  tests/hexpm.scm
  tests/ipfs.scm

Where to add?

live well,
  vagrant
  

On Sun, Feb 23, 2025 at 01:21:02PM -0800, Vagrant Cascadian wrote:
> On 2025-02-23, Ludovic Courtès wrote:
> > Vagrant Cascadian <vagrant@debian.org> skribis:
> >
> >> The generated tarball also appears to be missing a few files, some of
> >> which seem fine (e.g. .gitignore) but some which actually cause problems
> >> (e.g. missing po4a.cfg, tests/*.scm, gnu/patches/*.patch), some of which
> >> probably should be added to dist_patch_DATA in gnu/local.mk or other
> >> relevent values:
> >
> > Do you plan to submit a patch for this?
> >
> > Thanks for working on this!
> 
> I pushed some fixes to guix git; there are still open questions:
> 
>   https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00395.html
> 
> Here are all my outstanding questions:
> 
>   build-aux/cuirass
>   build-aux/gitlog-to-changelog
>   etc/copyright.el
>   etc/git
>   etc/snippets
>   etc/teams
>   etc/teams.scm
> 
> Should these be in the tarball at all? If so, where do we add them?

Thinking out loud, the point of the tarball from 'make dist' is to be
able to build and install the package.  So I'm leaning no.  Do they need
to be added to some NODIST variable?

>   gnu/packages/patches/cyrus-sasl-ac-try-run-fix.patch

git log --grep says this should be removed

>   gnu/packages/patches/gcc-10-tree-sra-union-handling.patch

git log --grep says this should be removed

>   gnu/packages/patches/gegl-compatibility-old-librsvg.patch

I think this patch was lost during a gnome-team merge.  We should
probably ask the gnome-team.  I believe it isn't needed, there is a
substitute for gegl for i686-linux.
 
> Probably should just be deleted, not referenced in the code
> anywhere... or am I missing something?
> 
>   gnu/tests/lightdm.scm
>   gnu/tests/sddm.scm
>   po/doc/po4a.cfg
>   tests/hexpm.scm
>   tests/ipfs.scm
> 
> Where to add?

I have a patch to add these in.  I've been testing it with running 'make
dist' and then using that tarball to build guix.

> live well,
>   vagrant

Thanks for working on this!


I'm getting a test failure on "'download' built-in builder" from
tests/derivations.scm, with an incorrect hash.  I'm not sure how it
could hash it twice and get different results, but here we are.  Also,
the incorrect hash throws an error, which kills the test suite, so I
don't know if there are any failures after that.
  

On Wed, Feb 19, 2025 at 02:06:43PM -0800, Vagrant Cascadian wrote:
> On 2025-02-15, Vagrant Cascadian wrote:
> > On 2025-02-11, Efraim Flashner wrote:
> >> We discussed the next release during Guix Days and I volunteered to lead
> >> the effort.
> ...
> > I may just make an attempt at making a git snapshot or something, which
> > I did once in the distant past... any recommendations on a particular
> > commit to aim at? Even an alpha or release candidate or whatever tag
> > would be nice...
> 
> So, in order to try this, the first thing I needed to do was remember
> how to run "make dist" to generate the tarball...
> 
> Basically from a clean git checkout:
> 
>   guix git tag v1.4.0+XYZ HEAD # I used f7cd085f4a36e118aa05af5524e74830a30b3dca
>   guix git authenticate && \
>   guix shell --container --pure --development guix guix git imagemagick perl graphviz less -- ./bootstrap && \
>   guix shell --container --pure --development guix guix git imagemagick perl graphviz less -- ./configure && \
>   guix shell --container --pure --development guix guix git imagemagick perl graphviz less -- make -j1 dist
> 
> Not sure if that is the "right" way or if there is better
> documentation... ?
> 

I was running: time guix shell --container --development guix \
    graphviz imagemagick perl -- \
    sh -c './bootstrap && ./configure && make dist'

I then test the tarball with:
guix build --no-grafts guix --with-source=guix=./guix-1.4.0+154701.013cc1952a8.142-dfff2.tar.gz
  

On 2025-02-24, Efraim Flashner wrote:
> On Sun, Feb 23, 2025 at 01:21:02PM -0800, Vagrant Cascadian wrote:
>> On 2025-02-23, Ludovic Courtès wrote:
>> > Vagrant Cascadian <vagrant@debian.org> skribis:
>> >
>> >> The generated tarball also appears to be missing a few files, some of
>> >> which seem fine (e.g. .gitignore) but some which actually cause problems
>> >> (e.g. missing po4a.cfg, tests/*.scm, gnu/patches/*.patch), some of which
>> >> probably should be added to dist_patch_DATA in gnu/local.mk or other
>> >> relevent values:
...
>> Here are all my outstanding questions:
>> 
>>   build-aux/cuirass
>>   build-aux/gitlog-to-changelog
>>   etc/copyright.el
>>   etc/git
>>   etc/snippets
>>   etc/teams
>>   etc/teams.scm
>> 
>> Should these be in the tarball at all? If so, where do we add them?
>
> Thinking out loud, the point of the tarball from 'make dist' is to be
> able to build and install the package.  So I'm leaning no.  Do they need
> to be added to some NODIST variable?

Not sure. I guess having such a mechanism would be helpful to document
what should not be shipped, if in fact that is the case...


>>   gnu/packages/patches/cyrus-sasl-ac-try-run-fix.patch
>
> git log --grep says this should be removed
>
>>   gnu/packages/patches/gcc-10-tree-sra-union-handling.patch
>
> git log --grep says this should be removed

So, should one of us be so bold and... just remove them? :)

I was leaning in that direction already, but figured I should check
before pushing, but you have come to the same conclusions!


>>   gnu/packages/patches/gegl-compatibility-old-librsvg.patch
>
> I think this patch was lost during a gnome-team merge.  We should
> probably ask the gnome-team.  I believe it isn't needed, there is a
> substitute for gegl for i686-linux.

Added gnome team members in CC, to help figure out the case of the
disappearing gegl patch!

It is non-obvious from git commit history where it disappeared.

It was introduced in 4beac7d95c84ea3be809030f942b8b71d155129e where gegl
0.4.46 was updated from 0.4.42, but the next commit
d6d9e65175d7e889c0d5020c949a65a396d1ca3d jumps from 0.4.42 to 0.4.48 ...

But yeah, I am inclined to remove the patch...


>>   gnu/tests/lightdm.scm
>>   gnu/tests/sddm.scm
>>   po/doc/po4a.cfg
>>   tests/hexpm.scm
>>   tests/ipfs.scm
>> 
>> Where to add?
>
> I have a patch to add these in.  I've been testing it with running 'make
> dist' and then using that tarball to build guix.

Mind sharing, or even better, just pushing it? :)


> I'm getting a test failure on "'download' built-in builder" from
> tests/derivations.scm, with an incorrect hash.  I'm not sure how it
> could hash it twice and get different results, but here we are.  Also,
> the incorrect hash throws an error, which kills the test suite, so I
> don't know if there are any failures after that.

I have those tests patched to skip unless network is available, but in
the Debian build environment things are pretty different...


live well,
  vagrant
  

Am Mittwoch, dem 26.02.2025 um 10:12 -0800 schrieb Vagrant Cascadian:
> > >   gnu/packages/patches/gegl-compatibility-old-librsvg.patch
> > 
> > I think this patch was lost during a gnome-team merge.  We should
> > probably ask the gnome-team.  I believe it isn't needed, there is a
> > substitute for gegl for i686-linux.
> 
> Added gnome team members in CC, to help figure out the case of the
> disappearing gegl patch!
It seems this was introduced in
4beac7d95c84ea3be809030f942b8b71d155129e, but no longer used after
d6d9e65175d7e889c0d5020c949a65a396d1ca3d.  Probably it is still left as
result from a weird merge.

Cheers
  

On Wed, Feb 26, 2025 at 10:12:55AM -0800, Vagrant Cascadian wrote:
> On 2025-02-24, Efraim Flashner wrote:
> > On Sun, Feb 23, 2025 at 01:21:02PM -0800, Vagrant Cascadian wrote:
> >> On 2025-02-23, Ludovic Courtès wrote:
> >> > Vagrant Cascadian <vagrant@debian.org> skribis:
> >> >
> >> >> The generated tarball also appears to be missing a few files, some of
> >> >> which seem fine (e.g. .gitignore) but some which actually cause problems
> >> >> (e.g. missing po4a.cfg, tests/*.scm, gnu/patches/*.patch), some of which
> >> >> probably should be added to dist_patch_DATA in gnu/local.mk or other
> >> >> relevent values:
> ...
> >> Here are all my outstanding questions:
> >> 
> >>   build-aux/cuirass
> >>   build-aux/gitlog-to-changelog
> >>   etc/copyright.el
> >>   etc/git
> >>   etc/snippets
> >>   etc/teams
> >>   etc/teams.scm
> >> 
> >> Should these be in the tarball at all? If so, where do we add them?
> >
> > Thinking out loud, the point of the tarball from 'make dist' is to be
> > able to build and install the package.  So I'm leaning no.  Do they need
> > to be added to some NODIST variable?
> 
> Not sure. I guess having such a mechanism would be helpful to document
> what should not be shipped, if in fact that is the case...
> 
> 
> >>   gnu/packages/patches/cyrus-sasl-ac-try-run-fix.patch
> >
> > git log --grep says this should be removed
> >
> >>   gnu/packages/patches/gcc-10-tree-sra-union-handling.patch
> >
> > git log --grep says this should be removed
> 
> So, should one of us be so bold and... just remove them? :)
> 
> I was leaning in that direction already, but figured I should check
> before pushing, but you have come to the same conclusions!
> 
> 
> >>   gnu/packages/patches/gegl-compatibility-old-librsvg.patch
> >
> > I think this patch was lost during a gnome-team merge.  We should
> > probably ask the gnome-team.  I believe it isn't needed, there is a
> > substitute for gegl for i686-linux.
> 
> Added gnome team members in CC, to help figure out the case of the
> disappearing gegl patch!
> 
> It is non-obvious from git commit history where it disappeared.
> 
> It was introduced in 4beac7d95c84ea3be809030f942b8b71d155129e where gegl
> 0.4.46 was updated from 0.4.42, but the next commit
> d6d9e65175d7e889c0d5020c949a65a396d1ca3d jumps from 0.4.42 to 0.4.48 ...
> 
> But yeah, I am inclined to remove the patch...
> 
> 
> >>   gnu/tests/lightdm.scm
> >>   gnu/tests/sddm.scm
> >>   po/doc/po4a.cfg
> >>   tests/hexpm.scm
> >>   tests/ipfs.scm
> >> 
> >> Where to add?
> >
> > I have a patch to add these in.  I've been testing it with running 'make
> > dist' and then using that tarball to build guix.
> 
> Mind sharing, or even better, just pushing it? :)

I pushed it a few days ago.  I also added the guix-gc.timer file
yesterday and then bumped the guix package.

> > I'm getting a test failure on "'download' built-in builder" from
> > tests/derivations.scm, with an incorrect hash.  I'm not sure how it
> > could hash it twice and get different results, but here we are.  Also,
> > the incorrect hash throws an error, which kills the test suite, so I
> > don't know if there are any failures after that.

This magically fixed itself. I'm not asking any questions.

> I have those tests patched to skip unless network is available, but in
> the Debian build environment things are pretty different...

I didn't look too closely at the test but I think it creates its own
HTTP server and serves itself a file.

> 
> live well,
>   vagrant