Re: 1.5.0 release?

Hi Greg, Ludo', I think 5 months are a long but not unbelieveable amount of time, especially if the team has to be onboarded in that time frame as well. I work for my dayjob as Release Engineer at a company that makes another Linux distribution, so I happen to have an idea of some o

Re: 1.5.0 release?

On Fri, Sep 6, 2024 at 5:32 AM Ludovic Courtès wrote: > > Hi Greg, > > Greg Hogan skribis: > > > With the recent core-updates merge, and as the master branch > > stabilizes, is there a plan or desire for a 1.5.0 release? > > Desire, definitely; plan? we have

Re: 1.5.0 release?

Hi Greg, Greg Hogan skribis: > With the recent core-updates merge, and as the master branch > stabilizes, is there a plan or desire for a 1.5.0 release? Desire, definitely; plan? we have to come up with one. I think there should be a team of ~4 volunteers who can commit to focus on

1.5.0 release?

Hi Guix, With the recent core-updates merge, and as the master branch stabilizes, is there a plan or desire for a 1.5.0 release? It has been 20 months since the 1.4.0 release, which is already more than the previously longest interval (18 months for v1.4.0). 2023 was the first year without a

Re: Scheduling a new release?

Am Tue, May 14, 2024 at 11:41:26AM +0200 schrieb Ludovic Courtès: > As discussed at the 2023 Guix Days (!), we could follow a model similar > to that of NixOS: form a release team (~4 people) dedicated to keeping > track of issues in particular wrt. the installer, and committed to >

Re: Scheduling a new release?

Christina O'Donnell writes: > On 08/05/2024 14:01, Christopher Baines wrote: >> I think it would be nice to have a new release, and indeed release more >> often, I think the way to get there is for less things to be broken >> between releases, such that releasing tak

Re: Scheduling a new release?

Hi, On 08/05/2024 14:01, Christopher Baines wrote: I think it would be nice to have a new release, and indeed release more often, I think the way to get there is for less things to be broken between releases, such that releasing takes less effort in terms of testing and fixing things. To give

Re: Scheduling a new release?

could follow a model similar to that of NixOS: form a release team (~4 people) dedicated to keeping track of issues in particular wrt. the installer, and committed to publishing a release within 4–6 months. (I think several people actually volunteered back in Feb. 2023. :-)) After that, another team, po

Re: Scheduling a new release?

> bug report above. > > Well, the bugs appear because the user is upgrading guix-daemon. ;-) > > In both cases (#70659 and #70726), it comes from a fresh install (latest > release v1.4.0) and then the first ’guix pull’ aiming to upgrade all > leads to that reported error.

3 kinds of bootstrap (was Re: backdoor injection via release tarballs combined with binary artifacts)

Hi, I am late to the party… On mer., 10 avril 2024 at 15:57, Ludovic Courtès wrote: >> That has happened to me too. >> Why not use Git directly always? > > Because it create{s,d} a bootstrapping issue. The > “builtin:git-download” method was added only recently to guix-daemon and > cannot be

Re: Scheduling a new release?

Re, On lun., 06 mai 2024 at 13:12, Simon Tournier wrote: > Although these days I do not have much free time, let make a new release > as soon as possible. WDYT? > > Who’s in? Well, the patch review sessions could be helpful. Maybe we could run some online hackathons. IMHO, havin

Scheduling a new release?

ser is upgrading guix-daemon. ;-) In both cases (#70659 and #70726), it comes from a fresh install (latest release v1.4.0) and then the first ’guix pull’ aiming to upgrade all leads to that reported error. Therefore, I strongly advise upgrading latest Guix release. ;-) Although these days I

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

Hi, Skyler Ferris skribis: > In short, I'm not sure that we actually get any value from checking the > PGP signature for most projects. Either HTTPS is good enough or the > attacker won. 99% of the time HTTPS is good enough (though it is notable > that the remaining 1% has a disproportionate

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

34s1mn5p@xelera.eu/) >>> >>> ...and if needed read that message again to understand the context, >>> please. >>> >> I assume that this was an indirect response to the email I sent >> previously where I discussed the problems with PGP signatures on re

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

ystem of rules for attackers to manipulate. On the other hand, if we assume people aren't doing the things they need to then no amount of technical support will give us a secure system. How much is reasonable to expect of people? From my extremely biased perspective, it's difficult to s

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

o understand the context, > please. > > I assume that this was an indirect response to the email I sent previously where I discussed the problems with PGP signatures on release files. I believe that this was in scope because of the discussion about whether to use VCS checkouts which l

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

n to understand the context, >> please. >> > I assume that this was an indirect response to the email I sent > previously where I discussed the problems with PGP signatures on release > files. No, believe me! I'm sorry I gave you this impression. :-) > I believe that

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

Hi Attila, sorry for the delay in my reply, I'm asking myself if this (sub)thread should be "condensed" in a dedicated RFC (are RFCs official workflows in Guix, now?); if so, I volunteer to file such an RFC in the next weeks. Attila Lendvai writes: >> Are there other issues (different from the

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

m should really do: have a reasonable level of trust that the origin is really the upstream one. But here we are /brainstormig/ about the very issue that led to the backdoor injection, and that issue is how to avoid "backdoor injections via build subversion exploiting semi-binary seeds in rel

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

lie in addressing bootstrapping issues with core > packages: glibc, GCC, Binutils, Coreutils, etc. I’m not sure how to do > that but… does it have to be an "all of nothing" choiche? I mean "continue using release tarballs" vs "use git" for "all"? If usi

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

Hi! Andreas Enge skribis: > Am Wed, Apr 10, 2024 at 03:57:20PM +0200 schrieb Ludovic Courtès: >> I think we should gradually move to building everything from >> source—i.e., fetching code from VCS and adding Autoconf & co. as inputs. > > the big drawback of this approach is that we would lose ma

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

> > I think we should gradually move to building everything from > > source—i.e., fetching code from VCS and adding Autoconf & co. as inputs. > > > the big drawback of this approach is that we would lose maintainers' > signatures, right? it's possible to sign git commits and (annotated) tags, t

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

Hi, and everybody is reading. This is a steep claim! I agree that nobody reads generated files in a release tarball, but I am not sure how many other files are actually read. Yea, it is. I'd also love to know how effective is the reading in a release tarball vs a VCS repo. Quality o

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

inguish the "original" from its clones in a VCS. With the signature by the known (this may also be a wrong assumption, admittedly) maintainer there is at least some form of assurance of origin. > and everybody is reading. This is a steep claim! I agree that nobody reads generated files in a r

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

h is that we would lose maintainers' signatures, right? Would the suggestion to use signed tarballs, but to autoreconf the generated files, not be a better compromise between trusting and distrusting upstream maintainers? Andreas Probably not, because the release tarballs might code th

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

Hello, Am Wed, Apr 10, 2024 at 03:57:20PM +0200 schrieb Ludovic Courtès: > I think we should gradually move to building everything from > source—i.e., fetching code from VCS and adding Autoconf & co. as inputs. the big drawback of this approach is that we would lose maintainers' signatures, right

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

the bootstrapping repos, git-archive them > ourselves and host them properly signed. At least, we could challenge > them using git (similar to what we do with the substitutes), which we > cannot do right now with the release tarballs against the actual code > of the repository. I

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

On Thu, 04 Apr 2024 12:34:42 +0200 Giovanni Biscuolo wrote: > Hello everybody, > > I know for sure that Guix maintainers and developers are working on > this, I'm just asking to find some time to inform and possibly discuss > with users (also in guix-devel) on what measures GNU Guix - the > soft

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

building from git? which, i think, would even take less effort. > > but these generated man files are part of the release tarball, so > > cross compilation works fine using the tarball. > > > AFAIU in this case there is an easy alternative: distribute the > (genera

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

numerous, especially among the core GNU components. OK, thank you for the confirmation. [...] >> ...or is it better to completely avoid release tarballs as our sources >> uris? > > yes, and this^ would guarantee the previous point, but it's not always > trivial. >

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

gure scripts are expected to be near incomprehensible. They contain no comments, are filled to the brim with portable (lowest common denominator) shell magic, and contain bizarrely named variables. Not using generated output is a good idea anyway and removes the requirement to trust that the release tarb

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

them. And we'll be forced to use git, too, or at least clone the bootstrapping repos, git-archive them ourselves and host them properly signed. At least, we could challenge them using git (similar to what we do with the substitutes), which we cannot do right now with the release tarballs a

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

undreds of thousand of lines of configure > scripts and other (auto)generated files bundled in release tarballs > "pragmatically impossible" to be peer reviewed? yes. > Can we consider that artifacts as sort-of-binary and "force" our > build-systems to r

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

was > acquired from. if the hash matches the one in the package definition, > then it's the same archive that the guix packager has seen while > packaging. Ehrm, you are right, mine was a stupid question :-) We *are* already verifying that tarballs had not been tampered

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

Hello, a couple of additional (IMO) useful resources... Giovanni Biscuolo writes: [...] > Let me highlight this: «It is pragmatically impossible [...] to peer > review a tarball prepared in this manner.» > > There is no doubt that the release tarball is a very weak "trusted &

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

> Also, in (info "(guix) origin Reference") I see that Guix packages can have a > list of uri(s) for the origin of source code, see xz as an example [7]: > are they intended to be multiple independent sources to be compared in > order to prevent possible tampering or are they "just" alternatives to

backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

e not present in Git (although a configure.ac might be). >> Guix should build from Git. Two useful pointers explaining how the backdoor has been injected are [1] (general workflow) and [2] (payload obfuscation) The first and *indispensable* condition for the attack to be succesful is this:

Re: On the road to the next release: testing the installer

Hi, On February 10, 2024 11:35:56 AM GMT+01:00, Josselin Poiret wrote: >Hi Tanguy, > >Tanguy LE CARROUR writes: > >> Grub asked me right away my passphrase and… it did not work! 😱 >> After several attempts, I figured out that the keyboard layout >> was apparently set to `qwerty` even though I h

Re: Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)

Hi Josselin, On February 13, 2024 10:35:42 AM GMT+01:00, Josselin Poiret wrote: > Same for the >at_keyboard module, although I'm wondering how the current situation >works for you then. As for now, the `at_keyboard` module is not loaded, only the default `console` module, with which I don't ha

Re: Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)

Hello, On February 12, 2024 11:29:37 AM GMT+01:00, Josselin Poiret wrote: >Hi Felix, > >Felix Lechner writes: > >> I do not suffer from the issue described here but rewrote the bootloader >> code locally for more flexibility (and may be able to contribute >> it). Could we simply move the refere

Re: Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)

Hi Romain, Romain writes: > IIRC, grub doesn't take the keymap into account unless the `at_keyboard` > module is loaded. It is not the case at the moment. > Also there seems to be an incompatibility between this module and some laptop > keyboards (for example I have a Thinkpad X220 with libreb

Re: Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)

Hi Felix, Felix Lechner writes: > I do not suffer from the issue described here but rewrote the bootloader > code locally for more flexibility (and may be able to contribute > it). Could we simply move the reference to keyboard-layout-config here > up by a few lines? [1] We could move it up an

Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)

[unable to locate Romain's original message] Hi Josselin, On Sat, Feb 10 2024, Josselin Poiret wrote: > The idea would be to ... make sure that keyboard-layout-config appears > first in the generated config. I do not suffer from the issue described here but rewrote the bootloader code locally f

Re: On the road to the next release: testing the installer

Hi Romain, Quoting Romain (2024-02-10 13:35:14) > On February 10, 2024 11:35:56 AM GMT+01:00, Josselin Poiret > wrote: > >Tanguy LE CARROUR writes: > > > >> Grub asked me right away my passphrase and… it did not work! 😱 > >> […] > > > >We don't try to embed the required keymap in the GRUB imag

Re: On the road to the next release: testing the installer

Hi Vivien, Quoting Vivien Kraus (2024-02-10 11:43:33) > Le vendredi 09 février 2024 à 12:24 +0100, Tanguy LE CARROUR a écrit : > > Grub asked me right away my passphrase and… it did not work! 😱 > > After several attempts, I figured out that the keyboard layout > > was apparently set to `qwerty` ev

Re: On the road to the next release: testing the installer

Hi Romain, Romain writes: > Hi, > > On February 10, 2024 11:35:56 AM GMT+01:00, Josselin Poiret > wrote: >>We don't try to embed the required keymap in the GRUB image and load it >>early on. It shouldn't be too hard, but would require a bit of >>refactoring. >> > > I started looking at this i

Re: On the road to the next release: testing the installer

On 2024-02-10 11:43:33 +0100, Vivien Kraus wrote: > Le vendredi 09 février 2024 à 12:24 +0100, Tanguy LE CARROUR a écrit : > > Grub asked me right away my passphrase and… it did not work! 😱 > > After several attempts, I figured out that the keyboard layout > > was apparently set to `qwerty` even th

Re: On the road to the next release: testing the installer

Le vendredi 09 février 2024 à 12:24 +0100, Tanguy LE CARROUR a écrit : > Grub asked me right away my passphrase and… it did not work! 😱 > After several attempts, I figured out that the keyboard layout > was apparently set to `qwerty` even though I had selected `bépo > AFNOR` > during the configurat

Re: On the road to the next release: testing the installer

Hi Tanguy, Tanguy LE CARROUR writes: > Grub asked me right away my passphrase and… it did not work! 😱 > After several attempts, I figured out that the keyboard layout > was apparently set to `qwerty` even though I had selected `bépo AFNOR` > during the configuration. When I eventually typed my p

Re: On the road to the next release: testing the installer

ot;build it yourself" [1], > right?! > > [1]: > https://guix.gnu.org/en/manual/devel/en/html_node/Building-the-Installation-Image.html As I was reinstalling my computer at work and I was in a bit of a hurry, I had created 2 USB stick installers: - 1 that I built myself from the late

Re: On the road to the next release: testing the installer

Quoting Tanguy LE CARROUR (2024-02-06 08:31:39) > In order to test the latest installer, I went to the "latest download" > page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux" > and ended up on an error page [2]: > […] > Is it the ISO that has to be tested? How can I download it?

On the road to the next release: testing the installer

Hello Guix, In order to test the latest installer, I went to the "latest download" page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux" and ended up on an error page [2]: """ {"error":"Could not find the requested build product."} """ [1]: https://guix.gnu.org/en/download/late

Re: Branch and release process

Am Wed, Mar 15, 2023 at 09:32:44AM -0400 schrieb Maxim Cournoyer: > I see; so it'd be useful for the integration of package changes > impacting multiple others; some kind of staging or core-updates > topic-focused branches. Simple leaf package updates could still be > merged directly to master wit

Re: Branch and release process

Hi Efraim, Efraim Flashner writes: > On Tue, Mar 14, 2023 at 11:30:52PM -0400, Maxim Cournoyer wrote: >> Hi, >> >> Leo Famulari writes: >> >> > On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: >> >> Felix Lechner writes: >> >> > With the core-updates process now abandoned, I

Re: Branch and release process (was: gnu: inetutils: Update to 2.4.)

"Leo Famulari" writes: > On Tue, Mar 14, 2023, at 23:30, Maxim Cournoyer wrote: >> Hi, >> >> Leo Famulari writes: >> >>> On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: Felix Lechner writes: > With the core-updates process now abandoned, I retitled the issue to

Re: Branch and release process (was: gnu: inetutils: Update to 2.4.)

On Tue, Mar 14, 2023, at 23:30, Maxim Cournoyer wrote: > Hi, > > Leo Famulari writes: > >> On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: >>> Felix Lechner writes: >>> > With the core-updates process now abandoned, I retitled the issue to >>> >>> Could you share the reference o

Re: Branch and release process (was: gnu: inetutils: Update to 2.4.)

On Tue, Mar 14, 2023 at 11:30:52PM -0400, Maxim Cournoyer wrote: > Hi, > > Leo Famulari writes: > > > On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: > >> Felix Lechner writes: > >> > With the core-updates process now abandoned, I retitled the issue to > >> > >> Could you shar

Branch and release process (was: gnu: inetutils: Update to 2.4.)

Hi, Leo Famulari writes: > On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: >> Felix Lechner writes: >> > With the core-updates process now abandoned, I retitled the issue to >> >> Could you share the reference of that? I'm not against it, but our >> currently documented proce

Re: Guix release broken without substitutes on ungrafted openssl

Hi, I overlooked the issue. Here, it is about just building because the test suite is time-dependant. Arf! IHMO, it does not change my previous but unrelated message. :-) Cheers, simon

Re: Guix release broken without substitutes on ungrafted openssl

Leo Famulari skribis: > On Wed, Feb 15, 2023 at 12:15:21PM -0500, Greg Hogan wrote: >> Installing guix from source fails on the build of openssl@1.1.1l. I >> see the same error on my working system (log attached) when executing >> the command below. The issue looks to be caused by OpenSSL's expir

Re: Guix release broken without substitutes on ungrafted openssl

Hi, On 2023-02-15, 12:15 -0500, Greg Hogan wrote: > Guix, > > Installing guix from source fails on the build of openssl@1.1.1l. I > see the same error on my working system (log attached) when executing > the command below. The issue looks to be caused by OpenSSL's expired > test certs fixed in

Re: Guix release broken without substitutes on ungrafted openssl

Hi, On Wed, 15 Feb 2023 at 13:33, Leo Famulari wrote: > I'd guess it's happened 4 times in the last several years. > > It's one of several reasons that rebuilding old Guix releases actually > approaches being a Hard Problem. The issue is from the impure world. ;-) Well, yeah it would probably

Re: Guix release broken without substitutes on ungrafted openssl

this is secure with Guix handling the git authentication. I see the same openssl@1.1.1l error when building with the system clock set to 2022/12/19, the date of the 1.4.0 release, so it appears that the release was never bootstrappable without hijinks. For the general case perhaps there cou

Re: Guix release broken without substitutes on ungrafted openssl

On Wed, Feb 15, 2023 at 12:15:21PM -0500, Greg Hogan wrote: > Installing guix from source fails on the build of openssl@1.1.1l. I > see the same error on my working system (log attached) when executing > the command below. The issue looks to be caused by OpenSSL's expired > test certs fixed in 1.1.

Guix release broken without substitutes on ungrafted openssl

Guix, Installing guix from source fails on the build of openssl@1.1.1l. I see the same error on my working system (log attached) when executing the command below. The issue looks to be caused by OpenSSL's expired test certs fixed in 1.1.1p [0]. Guix currently grafts openssl 1.1.1s but it seems gra

Release (was Re: Discussion notes on releases and branches)

Hi, Thanks Andreas for the notes. :-) On Thu, 09 Feb 2023 at 13:19, Andreas Enge wrote: > - A release schedule for a release every 4 to 6 months sounds > reasonable. > - Mathieu, Simon, Julien and Andreas volunteer to be members of a release Ludo was volunteer for helping, if I

Setting up the release team

Hello! Simon Tournier skribis: >> I think we should start thinking about the next release, forming a >> small release team, and I’ll be happy to mentor! > > Definitively! Count on me to candidate on such team. :-) Yay, thank you!! Who else is able and willing to dedicat

Re: Release progress, week 10

Hi, zimoun skribis: > On Sun, 18 Dec 2022 at 16:13, Ludovic Courtès wrote: > >> I wrote a couple of paragraphs about this and other things yesterday >> (tried to keep it relatively short). Let me know if you think >> anything’s missing. > > All appears to me good. You do not mention that the

Re: Release progress, week 10

Hi, On Sun, 18 Dec 2022 at 16:13, Ludovic Courtès wrote: > I wrote a couple of paragraphs about this and other things yesterday > (tried to keep it relatively short). Let me know if you think > anything’s missing. All appears to me good. You do not mention that the coverage for git-fetch is a

Re: cirrus (was Re: Release progress, week 10)

t; <https://issues.guix.gnu.org/60002>. > > This wasn’t under my radar and I think it’s too late for such a change > now. OK. > But look, we can do 1.4.1 next month if we want it. There’s a position > for a release management team (2–3 people) coming up BTW, so you can all &

Re: Release progress, week 10

Hi! zimoun skribis: > On Thu, 15 Dec 2022 at 17:38, Ludovic Courtès wrote: > >> If everything goes well, I plan to publish the release on Monday, 19th. >> Time to get to your instrument for a release song or whatever other >> performance you feel like making! :

Re: cirrus (was Re: Release progress, week 10)

This wasn’t under my radar and I think it’s too late for such a change now. But look, we can do 1.4.1 next month if we want it. There’s a position for a release management team (2–3 people) coming up BTW, so you can all prepare your applications. :-) Ludo’.

Re: cirrus (was Re: Release progress, week 10)

"pelzflorian (Florian Pelz)" writes: > That hold-up aside, maybe could you also tentatively add the cirrus > initrd module to the 1.4.0 installation image? I suppose it won’t break > anything, but it might help with bugs like > . I tested the following chance:

Re: Release progress, week 10

Hi Ludo, On Thu, 15 Dec 2022 at 17:38, Ludovic Courtès wrote: > If everything goes well, I plan to publish the release on Monday, 19th. > Time to get to your instrument for a release song or whatever other > performance you feel like making! :-) It reminds me the announce on hpc.

cirrus (was Re: Release progress, week 10)

Ludovic Courtès writes: > There are currently two installer bugs that I think now have a valid fix: > > https://issues.guix.gnu.org/60010 > https://issues.guix.gnu.org/59784 Sadly those are still not completely fixed… That hold-up aside, maybe could you also tentatively add the cirrus initrd

Release progress, week 10

Hello Guix! Here’s what may be the last update for the 1.4.0 release. The second release candidate was released earlier a few days ago: https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00145.html Thanks to everyone who tested and reported back! There are currently two installer bugs

Release progress, week 9

Hello Guix! Release progress: week 9. Here are the main improvements that landed on ‘version-1.4.0’ since RC1: • System test failures and ARM image build failures fixed: https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00063.html • Missing file added to Makefile.am: https

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 ar

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 #

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' c

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 incompa

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 tha

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 i

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/websi

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.o

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 u

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? Sugge

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

Release progress, week 8

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

Preparing the release on the ‘version-1.4.0’ branch

Hello Guix! Just a heads-up: the lights are green on ‘version-1.4.0’ to prepare a release candidate: --8<---cut here---start->8--- $ make assert-binaries-available Compiling Scheme modules... Compiling Scheme modules... Compiling Scheme modules... Com

Release progress, week 7

Hello Guix! Release progress: week 7. • ‘make assert-binaries-available’ reports 99% coverage (details below). 💪 • Architectures: - i586-gnu: Instead of dropping i586-gnu from ‘etc/release-manifest.scm’, I fixed a few things, running ‘guix build’ on berlin to get

Re: Release progress, week 6

Hi, Efraim Flashner skribis: > On Thu, Nov 17, 2022 at 05:04:43PM +0100, Ludovic Courtès wrote: [...] >> - i586-gnu: as proposed last week, I’ll drop i586-gnu from >> ‘etc/release-manifest.scm’. >> >> - armhf-linux: Mathieu re-queued a n

Re: Release progress, week 6

they > are not received by the worker. OK, that would explain it. >> Should we send out a call for testing the installer? Looks like >> we’re ready, no? > > Sure, I'll take care of that on Monday. I’m thinking we might as well do a proper RC1, produced by “

Re: Release progress, week 6

sting the installer? Looks like > we’re ready, no? Sure, I'll take care of that on Monday. > • Release issue <https://issues.guix.gnu.org/53214> blocked by 2 open > bugs, down from 5! > > 58221 nautilus: Crashes loading KgxNautilus plugin twice (probl

Re: Release progress, week 6

On Thu, Nov 17, 2022 at 05:04:43PM +0100, Ludovic Courtès wrote: > Hello Guix! > > Release progress: week 6. > > • ‘make assert-binaries-available’ reports 92.3% coverage (details > below), similar to last week. Please give a hand! :-) > > • Architectures:

Release progress, week 6

Hello Guix! Release progress: week 6. • ‘make assert-binaries-available’ reports 92.3% coverage (details below), similar to last week. Please give a hand! :-) • Architectures: - i586-gnu: as proposed last week, I’ll drop i586-gnu from ‘etc/release-manifest.scm

Re: Release progress, week 3

Am Tue, Nov 15, 2022 at 03:48:26PM -0500 schrieb Maxim Cournoyer: > It'll have to go to core-updates. The release will be cut from current > master. Okay, thanks, I will push it to core-updates when it comes out. Andreas

Re: Release progress, week 3

Hi, Andreas Enge writes: > Hello, > > mpfr-4.1.1 is expected to be released tomorrow: >https://sympa.inria.fr/sympa/arc/mpfr/2022-11/msg0.html > > I do not expect there to be any breakage (this is a bugfix release), > but adding it would require to recompile ev

Re: Release progress, week 5

Hey, >Probably we’ll postpone that post-release and drop i586-gnu from > ‘etc/release-manifest.scm’ in the meantime. Objections? No. > - armhf-linux: No progress; can we arrange so that ci.guix at least >builds these core subset of packages? We alre

  1   2   3   4   5   6   7   8   9   >