Re: Release team nomination

Hi, Noé Lopez via "Development of GNU Guix and the GNU System distribution." writes: > Hi everyone, > > According to GCD 005, the first step towards a release in November¹ is > the nomination of a release team! > > We need one release manager with commit access and four other > people. If I a

Re: Release team nomination

Hi! I don't have a commit access, but I want to be a one of these four courageous people. Best regards, Rodion Goritskov

Re: Release team nomination

Hi! > Sounds good! Can you confirm your codeberg username is rodion-goritskov? Sure, it definitely is. Thanks!

Re: Release team nomination

Hello! So that’s 3 people (or 4, if Andreas is in) on the release team so far. Congrats y’all! Anyone else joining? No pressure, but November is really close. :-) I will not be on the release team but as I wrote before, I’m happy to give a hand or provide guidance as someone who published relea

Re: Release team nomination

Rodion Goritskov writes: > Hi! > > I don't have a commit access, but I want to be a one of these four courageous > people. > > Best regards, > Rodion Goritskov Hi Rodion, Sounds good! Can you confirm your codeberg username is rodion-goritskov? Thanks, Noé signature.asc Description: PGP sign

Re: Release team nomination

Hello Noé, thanks for getting the ball rolling! In France we are still a bit in vacation mode until the end of August, but that is - now! When I sponsored the GCD for regular releases, I was aware that this might imply a moral obligation to be on the release team :) So if necessary, I can take pa

Re: Release team nomination

On Mon, Aug 18, 2025 at 09:03:58AM +0200, Noé Lopez via Development of GNU Guix and the GNU System distribution. wrote: > Hi everyone, > > According to GCD 005, the first step towards a release in November¹ is > the nomination of a release team! > > We need one release manager with commit access

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)

Ludovic Courtès writes: > "pelzflorian (Florian Pelz)" skribis: >> 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 >> .

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! :-) > > It reminds me the announce

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

Hi, "pelzflorian (Florian Pelz)" skribis: > 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… Both should be fixed

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.guix.info. We

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

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 that we have fai

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/website/drafts/gnu-guix-1.4.0-released.md >> >> Comm

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

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? Suggestions? Happiness? Excitem

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 te

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 number of armhf-linux builds >>s

Re: Release progress, week 6

Hi! Mathieu Othacehe skribis: > Hello, > >>It would seem that a lot of aarch64 builds are queued but not >>getting processed. Any idea how to investigate that, Mathieu? > > That would be because we only had a single ARM machine available till > this week (kreuzberg). It seems th

Re: Release progress, week 6

Hello, >It would seem that a lot of aarch64 builds are queued but not >getting processed. Any idea how to investigate that, Mathieu? That would be because we only had a single ARM machine available till this week (kreuzberg). It seems that overdrive1 and grunewald are back thou

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: > > - i586-gnu: as prop

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 everything. > > Is this feasi

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 already have the 'c

Re: Release progress, week 3

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 everything. Is this feasible before the release? Or should we do it

Re: Release progress, week 3

Hi, Efraim Flashner skribis: > If you want to add a bit more to the mix you can add riscv64-linux and > powerpc-linux as build targets. We don’t have hardware in the build farms for these two, so that’s future work. Ludo’.

Re: Release progress, week 3

On Thu, Oct 27, 2022 at 10:04:13AM -0700, Vagrant Cascadian wrote: > On 2022-10-27, Ludovic Courtès wrote: > > Release progress: week 3. > ... > > • Architectures: > > > > - powerpc64le-linux builds are back behind ci.guix, thanks to > >Tobias! > ... > > - armhf-linux: No progre

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

On 2022-11-03, Ludovic Courtès wrote: > Vagrant Cascadian skribis: test-name: channel-news, no news ... actual-error: + (git-error + #< code: -1 message: "invalid version 0 on git_proxy_options" class: 3>) result: FAIL >>> >>> This looks like an ABI issue with

Re: Release progress, week 3

Hi, Vagrant Cascadian skribis: >>> test-name: channel-news, no news >>> ... >>> actual-error: >>> + (git-error >>> + #< code: -1 message: "invalid version 0 on >>> git_proxy_options" class: 3>) >>> result: FAIL >> >> This looks like an ABI issue with libgit2. Are you sure the same >> version

Re: Release progress, week 3

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

Re: Release progress, week 3

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

Re: Release progress, week 3

Ludovic Courtès skribis: > Release progress: week 3. > > • Architectures: > [...] > - armhf-linux: No progress so far. I tried doing a "guix pull" for armhf-linux on a Raspberry Pi 2 B (Raspberry Pi OS with Guix as package manager), and also on a more powerful x86_64 machine with "gu

Re: Release progress, week 3

On 2022-10-27, Ludovic Courtès wrote: > Release progress: week 3. ... > • Architectures: > > - powerpc64le-linux builds are back behind ci.guix, thanks to >Tobias! ... > - armhf-linux: No progress so far. Not sure where this fits into the release process, but I uploaded a git s

Re: Release progress, week 2, release manifest, what builds are failing: gst-plugins-bad

Christopher Baines writes: > /gnu/store/msq74p2bd4g99n2x2wl85pjwc51pp82f-gst-plugins-bad-1.20.3.drv I spotted ci.guix.gnu.org actually has a substitute for this. Turns out it's just very flaky. bordeaux.guix.gnu.org has now attempted to build it 9 times, and only 1 build succeeded: https://dat

Re: Release progress, week 2, release manifest, what builds are failing?

Ludovic Courtès writes: > $ make assert-binaries-available > Compiling Scheme modules... > Compiling Scheme modules... > Compiling Scheme modules... > Compiling Scheme modules... > computing 401 package derivations for x86_64-linux... > looking for 508 store items on https://ci.guix.gnu.org...

Re: Release progress, week 2

Ludovic Courtès writes: > • Architectures: > > - armhf-linux is disabled on ci.guix due to improper offloading >setup (probably along the lines of >). Should we try and reenable >it, or should we drop it? > > - powerpc64le-l

Re: Release progress, week 2

On Thu, Oct 20, 2022 at 03:49:00PM +0200, Ludovic Courtès wrote: > Hello! > > Release progress: week 2. > > • ‘staging’ branch → merged! > > Apparently there’s a regression with Rust no longer being buildable > on aarch64-linux, but I can’t find a bug report. Marius? I can answer thi

Re: Release progress, week 2

Hey, Thanks for the update! > - armhf-linux is disabled on ci.guix due to improper offloading >setup (probably along the lines of >). Should we try and reenable >it, or should we drop it? > > - powerpc64le-linux is disabled o

Re: Release progress, week 1

Ludovic Courtès writes: > Release progress: week 1. > > Ludovic Courtès skribis: > >> Here’s a list of things to do to get there: >> >> • Merge ‘staging’ (?). What’s the status of that one, it seemed ready >> a couple of weeks ago, but then I lost track of it. Marius? > > Marius, any up

Re: Release progress, week 1

On Thu, Oct 13, 2022 at 05:19:48PM +0200, Ludovic Courtès wrote: > Hello! > > Release progress: week 1. > > Ludovic Courtès skribis: > > > Here’s a list of things to do to get there: > > > > • Merge ‘staging’ (?). What’s the status of that one, it seemed ready > > a couple of weeks ago,

Re: Release v1.4?

On Wed, Jun 22, 2022 at 03:31:34PM +0200, Ludovic Courtès wrote: > Hi, > > Brian Cully skribis: > > > Ludovic Courtès writes: > > > >> So plain ‘emacs’ package doesn’t work on Wayland? That sounds like > >> a > >> recipe for a poor user experience, no? > > > > The mainline Emacs is not Wayland

Re: Release v1.4?

Hi, Brian Cully skribis: > Ludovic Courtès writes: > >> So plain ‘emacs’ package doesn’t work on Wayland? That sounds like >> a >> recipe for a poor user experience, no? > > The mainline Emacs is not Wayland-native, but it (along with just > about everything else) will run fine under XWayland.

Re: Release v1.4?

On Fri, Jun 17, 2022, at 11:37 AM, Brian Cully via Development of GNU Guix and the GNU System distribution. wrote: > Ludovic Courtès writes: > >> So plain ‘emacs’ package doesn’t work on Wayland? That sounds >> like a >> recipe for a poor user experience, no? > > The mainline Emacs is not Wayla

Further thoughts on Xorg "vs" Wayland etc -- was: Re: Release v1.4?

Hi brian, et al, On +2022-06-17 11:37:18 -0400, Brian Cully via Development of GNU Guix and the GNU System distribution. wrote: > > Ludovic Courtès writes: > > > So plain ‘emacs’ package doesn’t work on Wayland? That sounds like a > > recipe for a poor user experience, no? > > The mainline E

Re: Release v1.4?

Ludovic Courtès writes: So plain ‘emacs’ package doesn’t work on Wayland? That sounds like a recipe for a poor user experience, no? The mainline Emacs is not Wayland-native, but it (along with just about everything else) will run fine under XWayland. It's how I've been running it for so

Re: Release v1.4?

Hello, Ludovic Courtès writes: > So plain ‘emacs’ package doesn’t work on Wayland? That sounds like a > recipe for a poor user experience, no? It does, but only through XWayland which is not ideal, and doesn't look as good as Emacs on native X or emacs-pgtk on Wayland (font rendering in XWaylan

Re: Release v1.4?

Hi, Josselin Poiret skribis: > I'm not sure, it does seem like a fraction of people use it on IRC but > then again it's more likely that Wayland users would talk about it, X > being the default. If there are no outstanding bugs with Wayland Gnome > though, I think it'd be a better choice: no te

Re: Release v1.4?

Hello, Ludovic Courtès writes: >> * switching gdm-configuration-wayland? to #t, so that the OOB experience >> with Wayland sessions is better. > > Perhaps I’m biased because I use Xorg, but I wonder how good a default > that is? To put it differently, what fraction of the user base uses > Waylan

Re: Release v1.4?

Hello, Ludovic Courtès ezt írta (időpont: 2022. jún. 15., Sze 11:12): > Hello! > > Josselin Poiret skribis: > > > Should we also make use of the point release to remove some deprecated > > things/switch some defaults? I'm thinking of: > > * removing the swap-devices deprecation warning and com

Re: Release ?

Efraim Flashner skribis: > I think we do release and then core-updates, before we get bogged down > in fixing packages in core-updates. Agreed! Ludo’.

Re: Release v1.4?

Hello! Josselin Poiret skribis: > Should we also make use of the point release to remove some deprecated > things/switch some defaults? I'm thinking of: > * removing the swap-devices deprecation warning and compatibility code; > * removing the bootloader-configuration-target warning and compati

Re: Release ? (was: Merging ‘staging’?)

On Tue, Jun 14, 2022 at 12:32:13PM +0200, zimoun wrote: > Hi, > > On Mon, 13 Jun 2022 at 09:03, Ludovic Courtès wrote: > > > Merged, enjoy! :-) > > Cool! > > > > Next up: release and ‘core-updates’. > > Do you want to do a ’core-updates’ merge before the release? I think a > release on Jul

Re: Release v1.4?

Hello everyone, Ludovic Courtès writes: > Thanks for the heads-up! I think merging ‘staging’ should be > top-priority. People are welcome to upgrade/reconfigure from it with: I'm currently running on staging with no bugs to report (x86_64-linux)! Should we also make use of the point release

Re: Release v1.4?

Hello, vi...@riseup.net writes: > On 2022-06-06 01:57, zimoun wrote: >> Hi, >> >> On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès wrote: >> >>> guix time-machine --branch=staging -- … >>> >>> Remaining things to check: >>> >>> - [ ] system tests >>> - [ ] status on non-x86_64 architectures

Re: Release v1.4?

On 2022-06-06 01:57, zimoun wrote: > Hi, > > On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès wrote: > >> guix time-machine --branch=staging -- … >> >> Remaining things to check: >> >> - [ ] system tests >> - [ ] status on non-x86_64 architectures > > I agree. To me, it is part of the same

Re: Release v1.4?

Hi, On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès wrote: > guix time-machine --branch=staging -- … > > Remaining things to check: > > - [ ] system tests > - [ ] status on non-x86_64 architectures I agree. To me, it is part of the same effort. From my point of view, we missed the window

Re: Release v1.4?

Hello! zimoun skribis: > Schedule a release is the occasion to tackle some not-so-fun tasks as > merging the ’staging’ branch [1], many upgrades as Haskell [2] or Julia, > etc. Thanks for the heads-up! I think merging ‘staging’ should be top-priority. People are welcome to upgrade/reconfigure

Re: Release v1.4 (or 2.0): process and schedule ?

Hello! For the record, I created a few days ago an issue to keep track of progress towards the release by blocking it with issues that we think must be fixed before we release: https://issues.guix.gnu.org/53214 Click on “Details” to see the blocking issues. Hopefully it’ll allow everyone of u

Re: Release v1.4 (or 2.0): process and schedule ?

Hi Chris, Chris Marusich writes: [...] > With Ludo's feedback, I was able to fix 52940 without rebuilding the > world in commit 195bb1fb9d55d8e5187d669c63a3cde747fc5f64 on master. Can > you try merging master into your version-1.4.0 branch? Awesome! As you may have noticed, today version-1.4

Re: Release v1.4 (or 2.0): process and schedule ?

On 2021-12-26, Maxim Cournoyer wrote: > Vagrant Cascadian writes: >> On 2021-12-19, Maxim Cournoyer wrote: >>> zimoun writes: Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do we go for v1.4 or v2.0? ... >> Would it be appropriate to fix the ~700 low-hanbging fruit

Re: Release v1.4 (or 2.0): process and schedule ?

Hi Maxim, Maxim Cournoyer writes: > Hello Chris, > > Chris Marusich writes: > >> Maxim Cournoyer writes: >> >>> About the current status, I'm nearing on pushing a version-1.4.0 branch >>> which is based on master with a few more (core-ish) updates. There's >>> still a few days ahead of that,

Re: Release v1.4 (or 2.0): process and schedule ?

Hello Chris, Chris Marusich writes: > Maxim Cournoyer writes: > >> About the current status, I'm nearing on pushing a version-1.4.0 branch >> which is based on master with a few more (core-ish) updates. There's >> still a few days ahead of that, so if you manage to get many of this >> kind of

Re: Release v1.4 (or 2.0): process and schedule ?

Maxim Cournoyer writes: > About the current status, I'm nearing on pushing a version-1.4.0 branch > which is based on master with a few more (core-ish) updates. There's > still a few days ahead of that, so if you manage to get many of this > kind of problems fixed & merged in master they can eas

Re: Release v1.4 (or 2.0): process and schedule ?

Hello, Ludovic Courtès writes: > Hello! > > Maxim Cournoyer skribis: > >> About the current status, I'm nearing on pushing a version-1.4.0 branch >> which is based on master with a few more (core-ish) updates. There's >> still a few days ahead of that, so if you manage to get many of this >> k

Re: Release v1.4 (or 2.0): process and schedule ?

On 2022-01-03, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> On 2021-12-21, Vagrant Cascadian wrote: > > [...] > >>> Would it be appropriate to fix the ~700 low-hanbging fruit issues that >>> are identified by: >>> >>> guix lint --checkers=description,synopsis > > [...] > >> Could guix

Re: Release v1.4 (or 2.0): process and schedule ?

Hello! Maxim Cournoyer skribis: > About the current status, I'm nearing on pushing a version-1.4.0 branch > which is based on master with a few more (core-ish) updates. There's > still a few days ahead of that, so if you manage to get many of this > kind of problems fixed & merged in master the

Re: Release v1.4 (or 2.0): process and schedule ?

Hello! Vagrant Cascadian skribis: > On 2021-12-21, Vagrant Cascadian wrote: [...] >> Would it be appropriate to fix the ~700 low-hanbging fruit issues that >> are identified by: >> >> guix lint --checkers=description,synopsis [...] > Could guix style be adapted to apply some of these chang

Re: Release v1.4 (or 2.0): process and schedule ?

Hi Vagrant, Vagrant Cascadian writes: > On 2021-12-19, Maxim Cournoyer wrote: >> zimoun writes: >>> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do >>> we go for v1.4 or v2.0? >> >> As I've mentioned previously, I'd go for a 1.4.0 release, since overall >> we've refined

Re: Release v1.4 (or 2.0): process and schedule ?

On 2021-12-21, Vagrant Cascadian wrote: > On 2021-12-19, Maxim Cournoyer wrote: >> zimoun writes: >>> In both case, what is the target for a release date? I propose January >>> 31rst. WDYT? >> >> I'd like to fix #52051 before issuing the first release candidate (RC). >> Assuming this can be made

Re: Release v1.4 (or 2.0): process and schedule ?

On 2021-12-19, Maxim Cournoyer wrote: > zimoun writes: >> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do >> we go for v1.4 or v2.0? > > As I've mentioned previously, I'd go for a 1.4.0 release, since overall > we've refined and improved (greatly!) what we already had rathe

Re: Release v1.4 (or 2.0): process and schedule ?

Hi, On Mon, 20 Dec 2021 at 22:24, Ludovic Courtès wrote: > Same here. But first it’d be nice to come up with a summary of what we > did in ‘core-updates’ because I think we’ve all forgotten most of it. > :-) A summary as a ChangeLog or a summary as a blog post? :-) Cheers, simon

Re: Release v1.4 (or 2.0): process and schedule ?

Hi, zimoun skribis: > On Sun, 19 Dec 2021 at 21:12, Maxim Cournoyer > wrote: >> zimoun writes: > >>> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do >>> we go for v1.4 or v2.0? >> >> As I've mentioned previously, I'd go for a 1.4.0 release, since overall >> we've refin

Re: Release v1.4 (or 2.0): process and schedule ?

Hi all, On +2021-12-19 21:12:36 -0500, Maxim Cournoyer wrote: > Hi Simon, > > zimoun writes: > > > Hi, > > > > Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do > > we go for v1.4 or v2.0? > > As I've mentioned previously, I'd go for a 1.4.0 release, since overall > we've

Re: Release v1.4 (or 2.0): process and schedule ?

On Mon, 20 Dec 2021 at 10:04, zimoun wrote: >> I'd like to fix #52051 before issuing the first release candidate (RC). >> Assuming this can be made before the end of January with the first RC >> coming out around New Year, and that the kind of collaboration I've seen >> in the last weeks contin

Re: Release v1.4 (or 2.0): process and schedule ?

Hi Maxim, On Sun, 19 Dec 2021 at 21:12, Maxim Cournoyer wrote: > zimoun writes: >> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do >> we go for v1.4 or v2.0? > > As I've mentioned previously, I'd go for a 1.4.0 release, since overall > we've refined and improved (greatly

Re: Release v1.4 (or 2.0): process and schedule ?

On Sun, 19 Dec 2021 21:12:36 -0500 Maxim Cournoyer wrote: > Hi Simon, > > zimoun writes: > > > Hi, > > > > Now core-updates-frozen is merged. Now The Big Change [1 ]is done. > > Do we go for v1.4 or v2.0? > > As I've mentioned previously, I'd go for a 1.4.0 release, since > overall we've

Re: Release v1.4 (or 2.0): process and schedule ?

Hi Simon, zimoun writes: > Hi, > > Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do > we go for v1.4 or v2.0? As I've mentioned previously, I'd go for a 1.4.0 release, since overall we've refined and improved (greatly!) what we already had rather than introduced something

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

For reference, crossposting: I pushed 00c67375b17f4a4cfad53399d1918f2e7eba2c7d to core-updates. Your patch. Thank you for it. Let's watch for upstream zstd fix also. I pushed 9feef62b73e284e106717a386624d6da90750a3d to master. Ubuntu released a patch in the mean time, so while we couldnt make su

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

On Tue, Mar 23 2021, zimoun wrote: > Hi, > > On Tue, 23 Mar 2021 at 11:32, Xinglu Chen wrote: > >>> And if someone is in the mood to check why ghc-haddock is broken. :-) >> >> This was an issue with upstream[1], it has since been fixed but the >> releases that include the fix are only built for G

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

Hi, On Tue, 23 Mar 2021 at 11:32, Xinglu Chen wrote: >> And if someone is in the mood to check why ghc-haddock is broken. :-) > > This was an issue with upstream[1], it has since been fixed but the > releases that include the fix are only built for GHC 8.8 or later. Thanks! Much appreciated.

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

On Wed, Mar 10 2021, zimoun wrote: > Using the command “guix weather --display-missing” at commit 6bed29b, I > identify 180 packages ghc-* which are missing. Then I locally rebuild > all of them and they build successfully. The only one broken is: > > ghc-haddock > > Therefore, is it possible

Re: Release 1.2.1: status

On Sun, Mar 21, 2021 at 12:00:20AM +0100, zimoun wrote: > We discussed that and I agree. We also discussed some tagging and Maxim > did some tests, IIRC. Please go ahead and let try if it helps to > synchronize. :-) Here is the checklist: https://bugs.gnu.org/47297 I've added a few items, but

Re: Release 1.2.1: status

Thanks for the details, zimoun. On Sunday, March 21, 2021 12:16 AM, zimoun wrote: [...] > > Also, I got a backtrace when checking icecat: > > ★★★ > > Backtrace:cecat@78.8.0-guix0-preview1 [archival]... > > [...] > > > ice-9/boot-9.scm:1667:16: In procedure raise-exception: > > In p

Re: Release 1.2.1: status

Hi Luis, Thanks for testings and reporting. On Fri, 19 Mar 2021 at 22:26, Luis Felipe wrote: > ‐‐‐ Original Message ‐‐‐ > On Thursday, March 18, 2021 2:28 PM, zimoun wrote: > > [...] > >> We are still missing a good story to monitor what is archived on >> Software Heritage and

Re: Release 1.2.1: status

On Sat, Mar 20, 2021 at 11:56:57PM +0100, zimoun wrote: > > From the wip-next-release branch, we should cherry-pick the tzdata > > updates and Qt 4 removal. > > > > I'll rewrite the branch with those commits today, and then see about > > getting it built on CI. > > Do you mean cherry-pick and then

Re: Release 1.2.1: status

Hi Andreas, On Fri, 19 Mar 2021 at 19:31, Andreas Enge wrote: > Am Thu, Mar 18, 2021 at 03:28:38PM +0100 schrieb zimoun: >> guix weather --display-missing > > I am giving it a try, but after about one hour at 100% CPU on one core it > is still only half way through. Is this normal? I think I wi

Re: Release 1.2.1: status

Hi Leo, On Sat, 20 Mar 2021 at 16:01, Leo Famulari wrote: > I suggest we use debbugs to keep track of tasks for the release. > > We can create a new bug called "1.2.1 release checklist". > > This bug can be made to depend on other bugs using the "block" feature > of debbugs: > > https://debbugs.g

Re: Release 1.2.1: status

Hi Leo, On Sat, 20 Mar 2021 at 14:09, Leo Famulari wrote: > On Fri, Mar 19, 2021 at 09:50:55AM +0100, zimoun wrote: >> The release work happens on master. The branch wip-next-release >> contains fixes, but AFAIK, it is not built by the CI, and these fixes >> are ’core-updates’-like changes; I do

Re: Release 1.2.1: status

I suggest we use debbugs to keep track of tasks for the release. We can create a new bug called "1.2.1 release checklist". This bug can be made to depend on other bugs using the "block" feature of debbugs: https://debbugs.gnu.org/server-control.html Concretely, this means we send email to debbu

Re: Release 1.2.1: status

On Fri, Mar 19, 2021 at 09:50:55AM +0100, zimoun wrote: > The release work happens on master. The branch wip-next-release > contains fixes, but AFAIK, it is not built by the CI, and these fixes > are ’core-updates’-like changes; I do not know if it is doable to merge > on time. I agree. The scope

  1   2   3   >