Release progress, week 8

Release progress, week 8

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

Hello Guix!

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/msg00000.html

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

Now we need reports from users to act upon.  I’d say we can decide next
week whether we need an RC2 or not.  I can handle the next release
candidate or the release itself, but I’ll be unavailable on Dec. 12–15.

I started writing super long release notes (a book!), comments welcome:

  https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.4.0-released.md

Comments?  Suggestions?  Happiness?  Excitement?  You tell!

Ludo’.

Week 7: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00274.html
Week 6: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00161.html
Week 5: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00026.html
Week 4: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00026.html
Week 3: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00293.html
Week 2: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00210.html
Week 1: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00137.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

Re: Release progress, week 8

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 4228 bytes --]

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/msg00000.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: (#<package guile@3.0.8 gnu/packages/guile.scm:392 1070318> #<package guile@3.0.7 gnu/packages/guile.scm:310 1070688> #<package guile@2.2.7 gnu/packages/guile.scm:250 1070738> #<package guile@2.2.4 gnu/packages/guile.scm:297 10706e0> #<package guile@2.0.14 gnu/packages/guile.scm:147 1070790> #<package guile@1.8.8 gnu/packages/guile.scm:76 10707e8>)
  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 (_ #(#(#<directory (test-inferior) 126f50> #<test-…>) #))
     293:34 15 (_ #(#(#<directory (test-inferior) 126f50> #<test-…>) #))
      159:9 14 (_ #(#(#<directory (test-inferior) 126f50> #<test-…>) #))
      159:9 13 (_ #(#(#<directory (test-inferior) 126f50> #<test-…>) #))
  In guix/discovery.scm:
      189:3 12 (fold-module-public-variables _ _ _)
  In guix/combinators.scm:
      48:26 11 (fold2 #<procedure 22e4990 at guix/discovery.scm:189:1…> …)
      48:26 10 (fold2 #<procedure 36224f0 at guix/discovery.scm:190:1…> …)
  In guix/discovery.scm:
     192:33  9 (_ #<package python-gwcs@0.18.2 gnu/packages/astronomy…> …)
  In gnu/packages.scm:
     233:37  8 (_ #<package python-gwcs@0.18.2 gnu/packages/astronomy…> …)
  In guix/packages.scm:
    1317:17  7 (supported-package? #<package python-gwcs@0.18.2 gnu/p…> …)
  In guix/memoization.scm:
      101:0  6 (_ #<hash-table 22e6c10 1900/3517> #<package python-gw…> …)
  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 #<promise #<procedure 3623160 at guix/…> …)
  In unknown file:
             0 (basename #f #<undefined>)

  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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Release progress, week 8

[zimoun]

Hi Ludo,

On Fri, 02 Dec 2022 at 23:45, Ludovic Courtès <ludo@gnu.org> wrote:

> I started writing super long release notes (a book!), comments welcome:
>
>   https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.4.0-released.md
>
> Comments?  Suggestions?  Happiness?  Excitement?  You tell!

I will try to propose a couple of paragraphs for this:

--8<---------------cut here---------------start------------->8---
# Supporting long-term reproducibility

TODO:
  - SWH fallback for channels
  - Disarchive
--8<---------------cut here---------------end--------------->8---

About “guix pack -f deb”, I thought it was experimental and it is not
mentioned.  Maybe,

--8<---------------cut here---------------start------------->8---
                                                                 —has
been extended with an experimental format: `guix pack -f deb` creates a
standalone `.deb` package 
--8<---------------cut here---------------end--------------->8---

It reminds me that,

    https://othacehe.org/wsl-images-for-guix-system.htm

could fit a Guix blog post.  Mathieu, WDYT?

About the part « **Python packaging** has seen important changes. » I
would mention the removal of many Python 2 packages.  Maxim, WDYT?


Cheers,
simon

Re: Release progress, week 8

[Ludovic Courtès]

Hi!

Vagrant Cascadian <vagrant@debian.org> 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 #<promise #<procedure 3623160 at guix/…> …)
>   In unknown file:
>              0 (basename #f #<undefined>)

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.  :-)

Thanks for testing!

Ludo’.

Re: Release progress, week 8

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]

Do we string freeze?

Le 2 décembre 2022 23:45:04 GMT+01:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>Hello Guix!
>
>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/msg00000.html
>
>The RC was made from ‘version-1.4.0’ branch, which only takes important
>fixes now (if in doubt, please ask).
>
>Now we need reports from users to act upon.  I’d say we can decide next
>week whether we need an RC2 or not.  I can handle the next release
>candidate or the release itself, but I’ll be unavailable on Dec. 12–15.
>
>I started writing super long release notes (a book!), comments welcome:
>
>  https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.4.0-released.md
>
>Comments?  Suggestions?  Happiness?  Excitement?  You tell!
>
>Ludo’.
>
>Week 7: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00274.html
>Week 6: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00161.html
>Week 5: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00026.html
>Week 4: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00026.html
>Week 3: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00293.html
>Week 2: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00210.html
>Week 1: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00137.html

[-- Attachment #2: Type: text/html, Size: 2560 bytes --]

missing sanity check

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

On 2022-12-03, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant@debian.org> 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 #<promise #<procedure 3623160 at guix/…> …)
>>   In unknown file:
>>              0 (basename #f #<undefined>)
>
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Release progress, week 8

[Maxim Cournoyer]

Hi Simon,

zimoun <zimon.toutoune@gmail.com> writes:

> Hi Ludo,
>
> On Fri, 02 Dec 2022 at 23:45, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> I started writing super long release notes (a book!), comments welcome:
>>
>>   https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.4.0-released.md
>>
>> Comments?  Suggestions?  Happiness?  Excitement?  You tell!

Thank you for writing it!  It looks good, though I think the explanation
of the benefit of GUIX_PYTHONPATH is a bit backward; one of the main
goals was to avoid having foreign distributions break spectacularly
because of Guix exposing their (sometimes incompatible) Python libraries
via the shared PYTHONPATH.  It also fixed a sometimes useful use case of
using Python's virtualenv on top of Guix.

[...]

> About “guix pack -f deb”, I thought it was experimental and it is not
> mentioned.  Maybe,

I don't think there's a need to label it as experimental.  The mechanics
are simple, and already proven to work.  I don't see the user-facing
options changing in backward incompatible ways in the future.

>                                                                  —has
> been extended with an experimental format: `guix pack -f deb` creates a
> standalone `.deb` package 
>
> It reminds me that,
>
>     https://othacehe.org/wsl-images-for-guix-system.htm
>
> could fit a Guix blog post.  Mathieu, WDYT?

Mathieu wrote one already, it's published on their personal blog.  I've
read it recently, it was interesting [0]

[0]  https://othacehe.org/wsl-images-for-guix-system.html

> About the part « **Python packaging** has seen important changes. » I
> would mention the removal of many Python 2 packages.  Maxim, WDYT?

It's already mentioned in the NEWS which will land in the announcement
emails, at least.  We could mention that despite removing 500+ Python 2
packages, our collection has grown from X to Y ;-).

I'll see if I can squeeze some extra bits in before the release.

-- 
Thanks,
Maxim

Re: Release progress, week 8

[zimoun]

Hi,

On Sun, 04 Dec 2022 at 00:32, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

>> It reminds me that,
>>
>>     https://othacehe.org/wsl-images-for-guix-system.htm
>>
>> could fit a Guix blog post.  Mathieu, WDYT?
>
> Mathieu wrote one already, it's published on their personal blog.  I've
> read it recently, it was interesting [0]
>
> [0]  https://othacehe.org/wsl-images-for-guix-system.html

Sorry to not have been clear, I am proposing to convert the already
published Mathieu’s post on their personal blog as a post on the Guix
blog.

I agree it is an interesting read and it appears to me worth for
communicating. :-)

It could be published “as is“ or could be a bit polished by proofreaders
(people behind the alias guix-blog@gnu.org; which includes myself :-)).

Mathieu, WDYT?


Cheers,
simon

Re: Release progress, week 8

[Mathieu Othacehe]

Hey,

Thanks for your hard work to publish the RC1!

> Now we need reports from users to act upon.  I’d say we can decide next
> week whether we need an RC2 or not.  I can handle the next release
> candidate or the release itself, but I’ll be unavailable on Dec. 12–15.

I noticed that we have failing tests on the version-1.4.0-tests
specification.

- docker-system (https://ci.guix.gnu.org/build/215380/details)
- prosody (https://ci.guix.gnu.org/build/215424/details)

that fail both on Berlin and on my machine and,

- fail2ban-extension (https://ci.guix.gnu.org/build/215447/details)

that only fails on Berlin.

There is also an issue with the system images. The following images are
failing on Berlin:

- novena-barebones-raw-image (https://ci.guix.gnu.org/build/215363/details)
- pine64-barebones-raw-image (https://ci.guix.gnu.org/build/215361/details)
- pinebook-pro-barebones-raw-image (https://ci.guix.gnu.org/build/215362/details)

It seems that those failures are caused by an issue during info-reader
build. I cannot reproduce it locally though.

Having an RC2 with all the tests passing and images buildable could be
nice.

On the other hand, I don't have much bandwidth to fix those issues and
they should not prevent us from releasing I guess.

Mathieu

Re: Release progress, week 8

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Thank you for writing it!  It looks good, though I think the explanation
> of the benefit of GUIX_PYTHONPATH is a bit backward; one of the main
> goals was to avoid having foreign distributions break spectacularly
> because of Guix exposing their (sometimes incompatible) Python libraries
> via the shared PYTHONPATH.  It also fixed a sometimes useful use case of
> using Python's virtualenv on top of Guix.

Oh I see.  Could you amend this part, or propose something I can squeeze
in?  As you can see, I’m no expert on these matters.  :-)

Thanks for your feedback!

Ludo’.

Re: Release progress, week 8

[Ludovic Courtès]

Hi,

Julien Lepiller <julien@lepiller.eu> skribis:

> Do we string freeze?

I guess we do!

Or, to put it differently, you could grab .pot files from
‘version-1.4.0’ rather than ‘master’.

Thanks,
Ludo’.

Re: Release progress, week 8

[Ludovic Courtès]

Hi!

Mathieu Othacehe <othacehe@gnu.org> skribis:

> I noticed that we have failing tests on the version-1.4.0-tests
> specification.
>
> - docker-system (https://ci.guix.gnu.org/build/215380/details)

Fixed:

  6232959311 tests: docker-system: Increase image size.
  f59aa79ca3 system: vm: Non-volatile 'run-vm.sh' creates a CoW image.

> - prosody (https://ci.guix.gnu.org/build/215424/details)

I suspect Freetalk (the client) might be at fault.  I tried fiddling
with it, using Loudmouth 1.5.3, removing Kerberos support, but that
didn’t have any effect.

Can someone more familiar with Prosody/XMPP take a look?

> - fail2ban-extension (https://ci.guix.gnu.org/build/215447/details)
>
> that only fails on Berlin.

I’ll take a look.

> There is also an issue with the system images. The following images are
> failing on Berlin:
>
> - novena-barebones-raw-image (https://ci.guix.gnu.org/build/215363/details)
> - pine64-barebones-raw-image (https://ci.guix.gnu.org/build/215361/details)
> - pinebook-pro-barebones-raw-image (https://ci.guix.gnu.org/build/215362/details)
>
> It seems that those failures are caused by an issue during info-reader
> build. I cannot reproduce it locally though.

Should be fixed now:

  fe563a87ad gnu: texinfo, info-reader: Do not run tests when cross-compiling.

> Having an RC2 with all the tests passing and images buildable could be
> nice.

Right.

Yesterday on IRC we discussed an installer crash received at
dump.guix.gnu.org.  Did you or will you have time to look into it?

I should be able to prepare and upload RC2 sometime between Thursday and
Sunday.  Now’s the time to report and fix installation problems!

Ludo’.

Re: Release progress, week 8

[Ludovic Courtès]

Mathieu Othacehe <othacehe@gnu.org> skribis:

> - fail2ban-extension (https://ci.guix.gnu.org/build/215447/details)

Fixed:

  a420b4f34e services: fail2ban: Start server in the foreground.
  a508b5c778 services: fail2ban: Remove unnecessary Shepherd 'modules' field.
  e45c83c397 services: fail2ban: 'stop' returns #f when the dameon is stopped.

(Oops, a typo.)

Ludo’.

Re: Release progress, week 8

[Mathieu Othacehe]

Hey Ludo,

>   fe563a87ad gnu: texinfo, info-reader: Do not run tests when cross-compiling.

Wow, that's a lot of fixes!

> Yesterday on IRC we discussed an installer crash received at
> dump.guix.gnu.org.  Did you or will you have time to look into it?

Yes and I think that for some reason we are not detecting the
installation device properly. However, as I cannot reproduce it, we
would need to find someone kind enough to run an instrumented installer
to understand this issue.

We can also add a few traces to the syslog and fix this issue later on,
depending on our schedule.

Thanks,

Mathieu