Re: Release progress, week 8
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
Re: Release progress, week 8
Mathieu Othacehe 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
Hi! Mathieu Othacehe 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
Hi, Julien Lepiller 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
Hi, Maxim Cournoyer 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
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
Hi, On Sun, 04 Dec 2022 at 00:32, Maxim Cournoyer 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-b...@gnu.org; which includes myself :-)). Mathieu, WDYT? Cheers, simon
Re: Release progress, week 8
Hi Simon, zimoun writes: > Hi Ludo, > > On Fri, 02 Dec 2022 at 23:45, Ludovic Courtès 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
Do we string freeze? Le 2 décembre 2022 23:45:04 GMT+01:00, "Ludovic Courtès" 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/msg0.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
Re: Release progress, week 8
Hi! 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. :-) Thanks for testing! Ludo’.
Re: Release progress, week 8
Hi Ludo, On Fri, 02 Dec 2022 at 23:45, Ludovic Courtès 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
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
