Re: Golang go-updates feature branch?
On Thu, Feb 16, 2023 at 09:05:42PM +0100, Josselin Poiret wrote: > What's the reason behind branch-specific manifests? I'd imagine we'd > want to test that Guix as a whole still works, even when upgrading just > specific parts. Otherwise, I guess this shouldn't qualify for a blog > post, maybe the cookbook but I'd even just add this as a comment at the > very top of `build-aux/cuirass/evaluate.scm`, since that's where people > will go looking for it. If it does end up becoming widespread, perhaps > a section of the manual/cookbook dedicated to how feature branches work > could be a nice home for these bits of info. Well, now that you ask, I guess there's not a good reason to use manifests here. After creating the kernel-updates CI job based on a manifest, I figured we'd use the same pattern for this, but I agree it's a bit clunky. On the other hand, Cuirass does tend to obscure the salient information when testing a branch that doesn't rebuild the world (i.e. core-updates). For example, for kernel updates, I want to know 1) if the kernel packages built and 2) do the system tests still pass? If I simply asked Cuirass to build everything on the kernel-updates branch, it might end up showing me the result of a bunch of unrelated package builds just because they happened to be selected as part of this jobset rather than 'master', due to (un)lucky timing. Does that make sense? Zooming out, our tooling still has a very long way to go. There are so many crucial features of Nix's Hydra (which we used previously) that we are still missing from Cuirass, and it's made it *much* more difficult to efficiently and carefully perform big updates to Guix, even though the build farm hardware is more capable than when we used to run Hydra. This was all so much easier with Hydra. Sorry for the rambling response that went off-topic. This has been on my mind.
Re: Merging core-updates?
Hi everyone, I'd love to help with the core-updates merge, but I don't have a beefy machine right now and would love to avoid building all the bootstrap locally. The evaluations on CI seem to keep failing, with no info available [1]. Do we have more info about them/know what's making them fail? [1] https://ci.guix.gnu.org/jobset/core-updates Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Golang go-updates feature branch?
Hi Leo, Leo Famulari writes: > Thank you for your help Josselin! It's much appreciated. Happy to help! > As part of our effort to move towards a "feature branch" development > workflow, it will be useful to collect these tips so that everyone can > create and test their own manifests and Cuirass specs. > > I wonder where it should go: a blog post, the cookbook, the Guix manual, > etc? What's the reason behind branch-specific manifests? I'd imagine we'd want to test that Guix as a whole still works, even when upgrading just specific parts. Otherwise, I guess this shouldn't qualify for a blog post, maybe the cookbook but I'd even just add this as a comment at the very top of `build-aux/cuirass/evaluate.scm`, since that's where people will go looking for it. If it does end up becoming widespread, perhaps a section of the manual/cookbook dedicated to how feature branches work could be a nice home for these bits of info. Best, -- Josselin Poiret signature.asc Description: PGP signature
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 1.1.1p [0]. Guix currently grafts openssl 1.1.1s > but it seems grafts are not part of the bootstrap process (substitutes > disabled). > > If this is the correct diagnosis then we should be ungrafting before > future releases any bootstrap dependencies relating to build failures > (not necessarily for security updates). > > My personal fix was to adapt my installation script to iteratively set > back then reset the clock, as openssl only builds in the past but > diffutils-boot0 then fails due to newly created files being older than > distributed files. > > Greg I was recently building a deb pack of guix for riscv and encountered the same problem, so far I just turned off the tests for openssl@1.1.1l -- Best regards, Aleksandr Vityazev
Re: Golang go-updates feature branch?
On Tue, Feb 14, 2023 at 10:22:07PM +0100, Josselin Poiret wrote: > The inferior that's used in 'build-aux/cuirass/evaluate.scm' is built > from the current check-out by first adding the checkout to the store and > then building it the usual way. However, that copy only selects files > that belong to the git tree using the git-predicate. If you add the > manifest to the git checkout by first committing it, it should proceed > happily (at least it did over here). Thank you for your help Josselin! It's much appreciated. As part of our effort to move towards a "feature branch" development workflow, it will be useful to collect these tips so that everyone can create and test their own manifests and Cuirass specs. I wonder where it should go: a blog post, the cookbook, the Guix manual, etc?
Re: Merging core-updates?
Am Thu, Feb 16, 2023 at 12:41:08PM +0100 schrieb Maxime Devos: > You didn't write the hash. As the hash is unknown, it would be > irreproducible for the Guix daemon to grant the build process access to the > network, so the Guix daemon doesn't. > You'll need to enter a hash (possibly a bogus one that the daemon can > complain about later). Interesting, thanks for the explanation! Andreas
Re: Merging core-updates?
I haven't tried the patch, but before it, I was already able to build mpc for x86_64 on a SSD with btrfs. Le 16 février 2023 16:03:15 GMT+01:00, Janneke Nieuwenhuizen a écrit : >Andreas Enge writes: > >> Am Wed, Feb 15, 2023 at 09:39:39AM +0100 schrieb Janneke Nieuwenhuizen: >>> I have released 0.24.2 and updated mes-boot on core-updates as >>> Let's hope this fixes these bugs. >> >> With your latest patch, I have successfully bootstrapped core-updates >> on x86_64 up to hello and mpc. Thanks a lot! > >Great, thanks so much for checking! Are you using any of tmpfs or btrfs >on /tmp? > >Greetings, >janneke >
Re: Merging core-updates?
Am Thu, Feb 16, 2023 at 04:03:15PM +0100 schrieb Janneke Nieuwenhuizen: > Great, thanks so much for checking! Are you using any of tmpfs or btrfs > on /tmp? No, it is all on SSD, so we probably cannot conclude for the bugs, unfortunately. Andreas
Re: Merging core-updates?
Andreas Enge writes: > Am Wed, Feb 15, 2023 at 09:39:39AM +0100 schrieb Janneke Nieuwenhuizen: >> I have released 0.24.2 and updated mes-boot on core-updates as >> Let's hope this fixes these bugs. > > With your latest patch, I have successfully bootstrapped core-updates > on x86_64 up to hello and mpc. Thanks a lot! Great, thanks so much for checking! Are you using any of tmpfs or btrfs on /tmp? Greetings, janneke -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: Merging core-updates?
Am Wed, Feb 15, 2023 at 09:39:39AM +0100 schrieb Janneke Nieuwenhuizen: > I have released 0.24.2 and updated mes-boot on core-updates as > Let's hope this fixes these bugs. With your latest patch, I have successfully bootstrapped core-updates on x86_64 up to hello and mpc. Thanks a lot! Andreas
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 be difficult to install from scratch Guix v1.0 in some future. However, the hope is that, guix time-machine --commit=v1.0 -- using distant future Guix to run from Guix v1.0. The distant future Guix should be able to deal with the distant future impure world and populate for the past running inside a pure world. For sure, it is a Hard Problem. As I like to say when presenting “guix time-machine”, it is a real world experiment, probably unique, to know what is the size of the time frame where reproducible time-travel is possible. I try to explain that this reproducible time-travel requires three conditions: 1. source code availability 2. Linux kernel compatibility 3. hardware compatibility Now, I would add: 4. being able to communicate with the world via the network Cheers, simon
Re: Merging core-updates?
On 15-02-2023 19:51, Andreas Enge wrote: I am trying to build openjdk13 without the patch as follows: (define-public openjdk13 (make-openjdk openjdk12 "13.0.13" "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji" (source (origin (method git-fetch) (uri (git-reference (url"https://github.com/openjdk/jdk13u/;) (commit "jdk-13.0.13-ga"))) (file-name (git-file-name name version)) (sha256 #f) (with the hash to be determined later). This fails with Initialized empty Git repository in/gnu/store/dyxp7njz9k20mar2h2cp8f2g438vigm2-openjdk-13.0.13-checkout/.git/ fatal: unable to access 'https://github.com/openjdk/jdk13u/': Could not resolve host: github.com Do you know why? I am at a total loss as to what is happening... You didn't write the hash. As the hash is unknown, it would be irreproducible for the Guix daemon to grant the build process access to the network, so the Guix daemon doesn't. You'll need to enter a hash (possibly a bogus one that the daemon can complain about later). Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Openjdk (was: Merging core-updates?)
Le 16 février 2023 12:03:35 GMT+01:00, Efraim Flashner a écrit : >On Wed, Feb 15, 2023 at 08:19:08PM +0100, Andreas Enge wrote: > >> Is it necessary to keep all these version of openjdk and to bootstrap >> version n with version n-1? > >Probably? I assume if you can cut some out that'd be ok. I'm pretty sure >openjdk-11 and openjdk-17 are considered LTS by upstream so it would >make sense to keep those specifically. Upstream ensures openjdk N+1 can be built by openjdk N, but not necessarily with N-1. We can try :)
Re: Openjdk (was: Merging core-updates?)
On Wed, Feb 15, 2023 at 08:19:08PM +0100, Andreas Enge wrote: > Am Wed, Feb 15, 2023 at 07:51:56PM +0100 schrieb Andreas Enge: > > Actually the patch has already been applied to openjdk13, if I am not > > mistaken. So I do not understand how the source could be built in master > > then, while the exact same code (?!) fails on core-updates... > > Well, there is a somewhat hidden difference. > core-updates introduces > "openjdk-10-hotspot-pointer-comparison.patch" > "openjdk-10-hotspot-stack-size.patch" > to openjdk10. > > openjdk11 is a package of its own without the patch. > > openjdk12 uses the newly defined make-openjdk to start from openjdk11, > overwriting the source together with openjdk-10-hotspot-stack-size.patch > in core-updates, and without the patch in master. (And it uses an obscure > tarball instead of a git checkout - why?) > > openjdk13 has the same code in core-updates and master: > (define-public openjdk13 > (make-openjdk openjdk12 "13.0.13" > "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji")) > So in core-updates it inherits the patch from openjdk12, in master > it does not (I think). And then I suppose it passes the patch on to all > its descendants. It's definitely possible that the master->core-updates merge messed with the package definitions and the inheritance and I didn't notice it. > The following seems to work and create source for openjdk13 and later: > (define-public openjdk13 > (make-openjdk openjdk12 "13.0.13" > "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji" > (source (origin > (inherit (package-source base)) > (patches '()) > > Okay to push if I manage to build current openjdk with it? Yeah, that's probably fine. > Is it necessary to keep all these version of openjdk and to bootstrap > version n with version n-1? Probably? I assume if you can cut some out that'd be ok. I'm pretty sure openjdk-11 and openjdk-17 are considered LTS by upstream so it would make sense to keep those specifically. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Rust team branch
Am Tue, Feb 14, 2023 at 10:07:12PM +0200 schrieb Efraim Flashner: > > By "pull out" you mean revert them in staging and apply them on a separate > > branch? That would also delay #61475 and maybe ease merging of the staging > > branch. > I was thinking more of cherry-picking them into a branch, not > necessarily reverting them on staging. Okay. But it would be nice then to revert at least as much in staging that the branch builds and can be merged. Andreas
