Re: make dist and related fun (was: The next release)

On Wed, Feb 19, 2025 at 02:06:43PM -0800, Vagrant Cascadian wrote: > On 2025-02-15, Vagrant Cascadian wrote: > > On 2025-02-11, Efraim Flashner wrote: > >> We discussed the next release during Guix Days and I volunteered to lead > >> the effort. > ... > > I may

Re: The next release

On Mon, Feb 17, 2025 at 02:48:59PM +0100, Andreas Enge wrote: > Hello, > > I think something we need to do urgently is to run an ungrafting > process - grafting takes a considerable amount of time when updating my > system now, and I suppose it will also waste a bit of space. We should > not burde

Re: make dist and related fun (was: The next release)

On 2025-02-19, Vagrant Cascadian wrote: > On 2025-02-15, Vagrant Cascadian wrote: >> On 2025-02-11, Efraim Flashner wrote: >>> We discussed the next release during Guix Days and I volunteered to lead >>> the effort. > ... >> I may just make an attempt at makin

Re: make dist and related fun (was: The next release)

On 2025-02-19, Vagrant Cascadian wrote: > Also, in reviewing the copyright and license headers while packaging for > Debian, this raised a broader question about translating license headers > in files such as doc/guix.de.info: > > > https://salsa.debian.org/debian/guix/-/blob/debian/latest/doc/g

make dist and related fun (was: The next release)

On 2025-02-15, Vagrant Cascadian wrote: > On 2025-02-11, Efraim Flashner wrote: >> We discussed the next release during Guix Days and I volunteered to lead >> the effort. ... > I may just make an attempt at making a git snapshot or something, which > I did once in th

Re: The next release

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

Re: The next release

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

Re: The next release

On 2025-02-11, Efraim Flashner wrote: > We discussed the next release during Guix Days and I volunteered to lead > the effort. Thanks for working on it! > The short version: > > * We need a tagged release so we can update the version in Debian and > other distros, in CI sys

The next release

We discussed the next release during Guix Days and I volunteered to lead the effort. The short version: * We need a tagged release so we can update the version in Debian and other distros, in CI systems, etc. * We need a newer point-in-time for the installer. * A new release increases interest

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

Hi Guix, Here is the report of my first attempt at reinstalling Guix System in a rally long time! Quoting Tanguy LE CARROUR (2024-02-06 13:52:31) > 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 clic

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: Let's include powerpc64le-linux in the next release

Hello, On Tue, Mar 30, 2021 at 10:24 AM Ludovic Courtès wrote: > Plus, I’m really grateful to OSUOSL for giving > us access to this machine! Yes, it's really nice to have access to those, and in the future, if we want to really support the ppc64le with substitutes, we may ask for a CI-class VM w

Re: Let's include powerpc64le-linux in the next release

Hi Tobias, Tobias Geerinckx-Rice skribis: > Ludovic Courtès 写道： >> Like Efraim wrote, the person who makes the release (I’m afraid >> it’ll be >> me) needs to be able to offload to a “trustworthy” machine for that >> platform. > > Define trustworthy? I put quotes because it’s informally defined

Re: Let's include powerpc64le-linux in the next release, Re: Let's include powerpc64le-linux in the next release

Tobias Geerinckx-Rice writes: > Ludovic Courtès 写道： >> Like Efraim wrote, the person who makes the release (I’m afraid >> it’ll be >> me) needs to be able to offload to a “trustworthy” machine for that >> platform. > > Define trustworthy? The project has access to an 8-core POWER9 VM > from OSUO

Re: Let's include powerpc64le-linux in the next release

Ludo', Ludovic Courtès 写道： Like Efraim wrote, the person who makes the release (I’m afraid it’ll be me) needs to be able to offload to a “trustworthy” machine for that platform. Define trustworthy? The project has access to an 8-core POWER9 VM from OSUOSL, currently running Debian, to whic

Re: Let's include powerpc64le-linux in the next release

On Tue, 2021-03-23 at 14:42 +0100, Ludovic Courtès wrote: > Like Efraim wrote, the person who makes the release (I’m afraid it’ll > be > me) needs to be able to offload to a “trustworthy” machine for that > platform. > > If we can do that, we should adjust the ‘release’ target in > ‘Makefile.am’ t

Re: Let's include powerpc64le-linux in the next release

Hi Chris, Chris Marusich skribis: > How shall we build the binary tarball for the release? Of course, > anybody with a copy of the (source) release tarball can build their own > guix binary by invoking "make guix-binary.powerpc64le-linux.tar.xz" > themselves. However, for convenience, it would

Re: Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?)

On Tue, 2021-03-16 at 09:08 +0200, Efraim Flashner wrote: > On Mon, Mar 15, 2021 at 09:03:04PM -0700, Chris Marusich wrote: > > How shall we build the binary tarball for the release? Of course, > > anybody with a copy of the (source) release tarball can build their > > own > > guix binary by invok

Re: Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?)

On Mon, Mar 15, 2021 at 09:03:04PM -0700, Chris Marusich wrote: > > How shall we build the binary tarball for the release? Of course, > anybody with a copy of the (source) release tarball can build their own > guix binary by invoking "make guix-binary.powerpc64le-linux.tar.xz" > themselves. Howe

Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?)

Hi, I have good news! Chris Marusich writes: > Subject: [PATCH] syscalls: mount: Fix a matching bug. If there are no concerns about this patch, I will commit it to master (with the "mount" typo fixed so it reads "mounts") in the next few days. > Efraim Flashner writes: > >> I'm now running m

Re: preparing the next release v0.15.0

l...@gnu.org (Ludovic Courtès) skribis: > In other news, these installation tests pass for me, as of > a51cf16031c974ffa238e5dd9ced32f0d68c9227, on x86_64: All of these pass at this commit: PASS: /gnu/store/rdaib0mw3r81h1d87kv669z9wd49072s-installed-os PASS: /gnu/store/9wzidlrcv38rspvai26k62h64b

Re: preparing the next release v0.15.0

Ludovic Courtès writes: > BTW, did “we” fix access to the OverDrive by berlin.guixsd.org? I opened a ticket to have the firewall rules adjusted but the network security person who usually does these things is currently out sick. Looks like it’s going to take a little longer, unfortunately. (I

Re: preparing the next release v0.15.0

Hello! Efraim Flashner skribis: > make guix-binary.aarch64-linux.tar.xz works as exptected Great, thanks for checking! BTW, did “we” fix access to the OverDrive by berlin.guixsd.org? In other news, these installation tests pass for me, as of a51cf16031c974ffa238e5dd9ced32f0d68c9227, on x86_64

Re: preparing the next release v0.15.0

On Mon, Jul 02, 2018 at 11:44:42AM +0200, Ludovic Courtès wrote: > Hello! > > Clément Lassieur skribis: > > > I think we need https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30602 to > > be fixed. > > Done. \o/ > > With Guile 2.2.4 now released, we can go ahead with 0.15. Could people > build

Re: preparing the next release v0.15.0

st, if nothing changes in the last commits. rust does not really matter since we do not have many depending packages for it. Mysql is more grave. Any takers on mysql? > * collecting new features and big changes in NEWS. The NEWS file > already lists some of the changes that the next rele

Re: preparing the next release v0.15.0

e with others who investigate them.) * collecting new features and big changes in NEWS. The NEWS file already lists some of the changes that the next release would provide compared to 0.14.0, but we all know that there are more. Who would like to take charge of the NEWS file? This in

Re: preparing the next release v0.15.0

Hi Kei, > but I do have a quick question: I take it that there exists a > script for determining the new packages and updates for each release? > Maybe I've missed it in the repository or in discussion. It is done with “make update-NEWS”. It depends on a checkout of the maintenance repository

Re: preparing the next release v0.15.0

swedebugia writes: > On June 20, 2018 8:38:46 PM GMT+02:00, Kei Kebreau > wrote: > > Marius Bakke writes: > > On the NEWS side, here is what springs to mind: > > [...] > > * Packages can specify that some CVEs don't apply to them > > Around when (or what commit) was this feature introduce

Re: preparing the next release v0.15.0

l...@gnu.org (Ludovic Courtès) writes: > Hello Guix! > > Thanks for all the ideas, I’ve updated NEWS accordingly. I’m sure we’re > still missing a number things (so much has happened!) so more ideas are > still welcome. :-) > > Ludo’. Hi Ludo, Looking at your changes to the log file increases

Re: preparing the next release v0.15.0

On June 20, 2018 8:38:46 PM GMT+02:00, Kei Kebreau wrote: >Marius Bakke writes: > >> On the NEWS side, here is what springs to mind: >> >[...] >> * Packages can specify that some CVEs don't apply to them > >Around when (or what commit) was this feature introduced? f4007b25476dfd97885f358d2dabb

Re: preparing the next release v0.15.0

Kei Kebreau writes: > Marius Bakke writes: > >> On the NEWS side, here is what springs to mind: >> > [...] >> * Packages can specify that some CVEs don't apply to them > > Around when (or what commit) was this feature introduced? It was added in commit f4007b25476dfd97885f358d2dabbd463f6f6017,

Re: preparing the next release v0.15.0

Hello Guix! Thanks for all the ideas, I’ve updated NEWS accordingly. I’m sure we’re still missing a number things (so much has happened!) so more ideas are still welcome. :-) Ludo’.

Re: preparing the next release v0.15.0

Hi Julien and Marius, >> On the NEWS side, here is what springs to mind: >> >> * `guix weather` now reports CI statistics >> * Guix will give hints for how to resolve common configuration errors >> * RHEL6 systems are again supported >> * Reproducibility improvements all around >> * Lots of new su

Re: preparing the next release v0.15.0

Is it worth mentioning that guix pull for some time now is back to relatively decent 1GB RAM consumption? I think I had it even succeed on 512MB RAM per handwritten notes here, but I haven't had the possibility to test again on low specs.

Re: preparing the next release v0.15.0

Marius Bakke writes: > On the NEWS side, here is what springs to mind: > [...] > * Packages can specify that some CVEs don't apply to them Around when (or what commit) was this feature introduced? signature.asc Description: PGP signature

Re: preparing the next release v0.15.0

On June 19, 2018 2:48:49 PM GMT+02:00, Julien Lepiller wrote: >Le 2018-06-19 14:36, Marius Bakke a écrit : >> Ricardo Wurmus writes: ... Snip... >> >> On the NEWS side, here is what springs to mind: >> >> * `guix weather` now reports CI statistics >> * Guix will give hints for how to res

Re: preparing the next release v0.15.0

keep track of these things and coordinate with others who investigate them.) * collecting new features and big changes in NEWS. The NEWS file already lists some of the changes that the next release would provide compared to 0.14.0, but we all know that there are more. Who would like to

Re: preparing the next release v0.15.0

stigate and fix these problems? (Note: you >> obviously don’t need to fix them yourself, just keep track of these >> things and coordinate with others who investigate them.) >> >> * collecting new features and big changes in NEWS. The NEWS file >> already lists so

Re: preparing the next release v0.15.0

t; > things and coordinate with others who investigate them.) > > > > * collecting new features and big changes in NEWS. The NEWS file > > already lists some of the changes that the next release would provide > > compared to 0.14.0, but we all know that there

Re: preparing the next release v0.15.0

stigate and fix these problems? (Note: you >> obviously don’t need to fix them yourself, just keep track of these >> things and coordinate with others who investigate them.) >> >> * collecting new features and big changes in NEWS. The NEWS file >> already lists so

Re: preparing the next release v0.15.0

I'd be happy to help unfortunately this month is hectic for me. Had it been July or August I would have been more free. Sorry :( -- Pierre Neidhardt signature.asc Description: PGP signature

Re: preparing the next release v0.15.0

keep track of these > things and coordinate with others who investigate them.) > > * collecting new features and big changes in NEWS. The NEWS file > already lists some of the changes that the next release would provide > compared to 0.14.0, but we all know that there are more

Re: preparing the next release v0.15.0

big changes in NEWS. The NEWS file >> already lists some of the changes that the next release would provide >> compared to 0.14.0, but we all know that there are more. Who would >> like to take charge of the NEWS file? This involves asking people for >> changes t

Re: preparing the next release v0.15.0

ts some of the changes that the next release would provide > compared to 0.14.0, but we all know that there are more. Who would > like to take charge of the NEWS file? This involves asking people for > changes they would really like to be mentioned and coordinating with >

Re: preparing the next release v0.15.0

Hi! Ricardo Wurmus skribis: >> Can we aim for a v1.0 release? At least for the package manager? I am >> facing people that say Guix is not mature and therefore insecure and >> therefore they can justifiably ignore my pleas for installation >> without even looking. > > I would like to leave 1.0 f

Re: preparing the next release v0.15.0

Ricardo Wurmus writes: > retiring of GUIX_PACKAGE_PATH, and more. What alternative do you have in mind? -- Pierre Neidhardt signature.asc Description: PGP signature

Re: preparing the next release v0.15.0

Hi Pjotr, Pjotr Prins writes: > Can we aim for a v1.0 release? At least for the package manager? I am > facing people that say Guix is not mature and therefore insecure and > therefore they can justifiably ignore my pleas for installation > without even looking. > > I think any outstanding featu

Re: preparing the next release v0.15.0

Hi Pjotr, > Can we aim for a v1.0 release? At least for the package manager? I am > facing people that say Guix is not mature and therefore insecure and > therefore they can justifiably ignore my pleas for installation > without even looking. I would like to leave 1.0 for the future. Things th

Re: preparing the next release v0.15.0

Can we aim for a v1.0 release? At least for the package manager? I am facing people that say Guix is not mature and therefore insecure and therefore they can justifiably ignore my pleas for installation without even looking. I think any outstanding features can be projected on later realeases. Gu

preparing the next release v0.15.0

, just keep track of these things and coordinate with others who investigate them.) * collecting new features and big changes in NEWS. The NEWS file already lists some of the changes that the next release would provide compared to 0.14.0, but we all know that there are more. Who would

Re: Planning for the next release

Ludovic Courtès writes: > Hello! > > Leo Famulari skribis: > >> If possible, I would appreciate if the release included a QEMU image >> that we could offer to VPS hosters like serveraptor.com, as discussed in >> this thread: >> >> https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00772.h

Re: Planning for the next release

l...@gnu.org (Ludovic Courtès) skribis: >> It looks like the initrd is becoming obese. Adding "-m 168M" makes it >> boot (qemu defaults to 128MiB). Not sure what to do about it. > > Oh, that didn’t come to mind. I’m pretty sure this is because we’re > pulling dynamically-linked stuff that bring i

Re: Planning for the next release

Hi! Marius Bakke skribis: > Ludovic Courtès writes: > >> Hi again! >> >> I build the installation image with from commit >> 96afb480f8165a315a69b1dd3a031e053044d3b2: >> >> ./pre-inst-env guix system disk-image --image-size=1.2G >> gnu/system/install.scm -K >> >> and then ran QEMU on that ima

Re: Planning for the next release

Ricardo Wurmus skribis: > Ludovic Courtès writes: > Not a release blocker, but a kind of general blocker: we have a ‘guix offload’ bug for which we need more testers and hackers to get better debugging info: . >>> >>> I’ll try to give this a try either

Re: Planning for the next release

Ludovic Courtès writes: >>> Not a release blocker, but a kind of general blocker: we have a ‘guix >>> offload’ bug for which we need more testers and hackers to get better >>> debugging info: . >> >> I’ll try to give this a try either tonight or tomorrow. > > Great! >

Re: Planning for the next release

Ludovic Courtès writes: > Hello Guix! > > An update on the release that never comes. ;-) […] > The “Noteworthy bug fixes” section of ‘NEWS’ also needs to be improved. I just pushed commit 402f241da, which fills that section a bit. Thank you for the many bug fixes that I’ve combed through jus

Re: Planning for the next release

Marius Bakke writes: > Anyway, the problem is that the parted script gets a negative size for > TESTS=basic: > > creating partition table with 2 partitions... > > DEBUG: (mkpart primary ext2 1048576B -19922944B set 1 boot on mkpart primary > ext2 -199224

Re: Planning for the next release

Ludovic Courtès writes: > Hi again! > > I build the installation image with from commit > 96afb480f8165a315a69b1dd3a031e053044d3b2: > > ./pre-inst-env guix system disk-image --image-size=1.2G > gnu/system/install.scm -K > > and then ran QEMU on that image: > > qemu-system-x86_64 -enable-kvm

Re: Planning for the next release

Hi again! I build the installation image with from commit 96afb480f8165a315a69b1dd3a031e053044d3b2: ./pre-inst-env guix system disk-image --image-size=1.2G gnu/system/install.scm -K and then ran QEMU on that image: qemu-system-x86_64 -enable-kvm -serial stdio \ -net nic,model=virtio -n

Re: Planning for the next release

Hi! Ricardo Wurmus skribis: > Ludovic Courtès writes: > >> Hello Guix! >> >> An update on the release that never comes. ;-) >> >> The main remaining item is merging UEFI support in ‘version-0.13.0’: >> . Marius already fixed this one.

Re: Planning for the next release

Ludovic Courtès writes: > Hello Guix! > > An update on the release that never comes. ;-) > > The main remaining item is merging UEFI support in ‘version-0.13.0’: > . > > The “Noteworthy bug fixes” section of ‘NEWS’ also needs to be improv

Re: Planning for the next release

Hello Guix! An update on the release that never comes. ;-) The main remaining item is merging UEFI support in ‘version-0.13.0’: . The “Noteworthy bug fixes” section of ‘NEWS’ also needs to be improved. Not a release blocker, but a kind o

Re: Planning for the next release

On Wed, May 17, 2017 at 02:38:13PM +0200, Ludovic Courtès wrote: > Hi Leo, > > Leo Famulari skribis: > > > From 1c9ad17ea0b64b29117e49526ff07d2e7e7c6c13 Mon Sep 17 00:00:00 2001 > > From: Leo Famulari > > Date: Sat, 13 May 2017 20:44:36 -0400 > > Subject: [v2] maint: The 'release' target builds

Re: Planning for the next release

Hi Leo, Leo Famulari skribis: > From 1c9ad17ea0b64b29117e49526ff07d2e7e7c6c13 Mon Sep 17 00:00:00 2001 > From: Leo Famulari > Date: Sat, 13 May 2017 20:44:36 -0400 > Subject: [v2] maint: The 'release' target builds a VM image. > > * Makefile.am (GUIXSD_VM_SYSTEMS, GUIXSD_VM_IMAGE_BASE, > GUIXSD

Re: Planning for the next release

Hello! Leo Famulari skribis: > On Tue, May 16, 2017 at 07:51:36PM -0500, sirgazil wrote: >> On 16/05/17 13:19, Leo Famulari wrote: >> > Although, I am wondering why 'installer.svg' seems specific to the VM >> > image now. The VM image is not an installer. >> Hi Leo :) >> >> I don't know if I un

Re: Planning for the next release

On Tue, May 16, 2017 at 07:51:36PM -0500, sirgazil wrote: > On 16/05/17 13:19, Leo Famulari wrote: > > Although, I am wondering why 'installer.svg' seems specific to the VM > > image now. The VM image is not an installer. > Hi Leo :) > > I don't know if I understand correctly, but the "installed.s

Re: Planning for the next release

On 16/05/17 13:19, Leo Famulari wrote: > On Tue, May 16, 2017 at 09:41:38AM -0500, sirgazil wrote: >> On 15/05/17 07:44, Ludovic Courtès wrote: >>> Hi Leo! >>> >>> (sirgazil: this is about providing a ready-to-use VM image of GuixSD for >>> download, in addition to the installation image. See at

Re: Planning for the next release

On Mon, May 15, 2017 at 02:44:51PM +0200, Ludovic Courtès wrote: > Leo Famulari skribis: > > Subject: [PATCH 1/2] doc: Mention the pre-built VM image. > > * doc/guix.texi (Running GuixSD in a VM): Mention the pre-built VM image. > > > Subject: [PATCH 2/2] maint: The 'release' target builds a VM im

Re: Planning for the next release

On Tue, May 16, 2017 at 09:41:38AM -0500, sirgazil wrote: > On 15/05/17 07:44, Ludovic Courtès wrote: > > Hi Leo! > > > > (sirgazil: this is about providing a ready-to-use VM image of GuixSD for > > download, in addition to the installation image. See at the bottom.) > > [...] > > > sirgazil: do

Re: Planning for the next release

On Tue, May 16, 2017 at 09:41:38AM -0500, sirgazil wrote: > On 15/05/17 07:44, Ludovic Courtès wrote: > > Hi Leo! > > > > (sirgazil: this is about providing a ready-to-use VM image of GuixSD for > > download, in addition to the installation image. See at the bottom.) > > [...] > > > sirgazil: do

Re: Planning for the next release

If it's not too late for the release, I think it would be good to make guile-json an optional dependency (currently it is required). A simple fix is here: http://debbugs.gnu.org/26860 Although Ricardo suggested another solution there. -- Alex

Re: Planning for the next release

On 15/05/17 07:44, Ludovic Courtès wrote: > Hi Leo! > > (sirgazil: this is about providing a ready-to-use VM image of GuixSD for > download, in addition to the installation image. See at the bottom.) [...] > sirgazil: do you think we should add a special icon or something for the > VM image? Ye

Re: Planning for the next release

Hi Leo! (sirgazil: this is about providing a ready-to-use VM image of GuixSD for download, in addition to the installation image. See at the bottom.) Leo Famulari skribis: > I think the name should be "guixsd-vm-image-VERSION", since this follows > the convention established with `guix system

Re: Planning for the next release

On Sun, May 14, 2017 at 03:14:07PM -0400, Leo Famulari wrote: > Subject: [PATCH 2/2] maint: The 'release' target builds a VM image. > > * Makefile.am (GUIXSD_VM_SYSTEMS, GUIXSD_VM_IMAGE_BASE, > GUIXSD_VM_IMAGE_SIZE): New variables. > (release): Add logic to build a VM image. After following the i

Re: Planning for the next release

On Sun, May 14, 2017 at 03:14:07PM -0400, Leo Famulari wrote: > Subject: [PATCH 1/2] doc: Mention the pre-built VM image. > > * doc/guix.texi (Running GuixSD in a VM): Mention the pre-built VM image. [...] > +If you built your image image, you must copy it out of the store s/image image/own ima

Re: Planning for the next release

On Sat, May 13, 2017 at 03:59:24PM +0200, Ludovic Courtès wrote: > Leo Famulari skribis: > > If possible, I would appreciate if the release included a QEMU image > > that we could offer to VPS hosters like serveraptor.com, as discussed in > > this thread: > > > > If the maintainers want to try for

Re: Planning for the next release

On Sat, May 13, 2017 at 3:59 PM, Ludovic Courtès wrote: > Leo Famulari skribis: > >> If possible, I would appreciate if the release included a QEMU image >> that we could offer to VPS hosters like serveraptor.com, as discussed in >> this thread: +1 >> If the maintainers want to try for this, I

Re: Planning for the next release

Hello! Leo Famulari skribis: > If possible, I would appreciate if the release included a QEMU image > that we could offer to VPS hosters like serveraptor.com, as discussed in > this thread: > > https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00772.html > > This would also depend on

Re: Fwd: Re: Planning for the next release

Manolis Ragkousis writes: > We also need to fix the glibc on hurd (the patch for i686 should not be > applied there), but I haven’t been able to reproduce the failure on > hydra. https://hydra.gnu.org/build/2036383/nixlog/1/raw Yes, I’m working on it. I wasn’t able to reproduce this in my pas

Re: Planning for the next release

On Fri, 12 May 2017, Leo Famulari wrote: On Thu, May 11, 2017 at 11:00:16AM +0200, Ludovic Courtès wrote: With UEFI (almost) ready, Guile 2.2 in the house, and “make release”, should we aim for next week (like Wed. 17th)? Can we focus on polishing the remaining bits and testing? If the schedu

Re: Planning for the next release

Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> Ludovic Courtès writes: > > [...] > >>> With UEFI (almost) ready, Guile 2.2 in the house, and “make release”, >>> should we aim for next week (like Wed. 17th)? Can we focus on polishing >>> the remaining bits and testing? >>> >>> If the s

Fwd: Re: Planning for the next release

Forgot to cc the list -- Forwarded message -- From: "Manolis Ragkousis" Date: May 12, 2017 21:17 Subject: Re: Planning for the next release To: "Ricardo Wurmus" Cc: Hey Ricardo, On May 12, 2017 08:45, "Ricardo Wurmus" wrote: We also need to fi

Re: Planning for the next release

On Thu, May 11, 2017 at 11:00:16AM +0200, Ludovic Courtès wrote: > With UEFI (almost) ready, Guile 2.2 in the house, and “make release”, > should we aim for next week (like Wed. 17th)? Can we focus on polishing > the remaining bits and testing? > > If the schedule turns out to be too tight, we co

Re: Planning for the next release

Ricardo Wurmus skribis: > Ludovic Courtès writes: [...] >> With UEFI (almost) ready, Guile 2.2 in the house, and “make release”, >> should we aim for next week (like Wed. 17th)? Can we focus on polishing >> the remaining bits and testing? >> >> If the schedule turns out to be too tight, we co

Re: Planning for the next release

Am 12.05.2017 um 07:45 schrieb Ricardo Wurmus: > > With UEFI (almost) ready, Guile 2.2 in the house, and “make release”, > > should we aim for next week (like Wed. 17th)? Can we focus on polishing > > the remaining bits and testing? > > > > If the schedule turns out to be too tight, we could move

Re: Planning for the next release

Ludovic Courtès writes: > Hello Guix! > > l...@gnu.org (Ludovic Courtès) skribis: > >> It’s time to plan for the next release! Here’s what we maintainers >> think should be done for the next release, which would hopefully happen >> within less than a month: >

Re: Planning for the next release

Hello Guix! l...@gnu.org (Ludovic Courtès) skribis: > It’s time to plan for the next release! Here’s what we maintainers > think should be done for the next release, which would hopefully happen > within less than a month: > >1. ‘core-updates’ merged. We’re almost there!

  1   2   >