gnutls 3.6.12 fails to build: FAIL: status-request-revoked

OpenSubmitted by Christopher Baines.
Details
7 participants
  • Carl Dong
  • jeremiah
  • Leo Famulari
  • Ludovic Courtès
  • Christopher Baines
  • Marius Bakke
  • Maxime Devos
Owner
unassigned
Severity
important
C
C
Christopher Baines wrote on 10 Nov 2020 21:49
(address . bug-guix@gnu.org)
87d00los2d.fsf@cbaines.net
I found this when trying to build guile3.0-gnutls:
guix time-machine --commit=94585fffb23079fe71110e2bf99782eb4ccfa12b -- build --no-grafts --check guile3.0-gnutls
FAIL: status-request-revoked============================
trying NORMAL:-VERS-ALL:+VERS-TLS1.2received status requestreceived status requestcert_verify_callback:263: certificate verify status doesn't match: 100402 != 22FAIL status-request-revoked (exit status: 1)
-----BEGIN PGP SIGNATURE-----
iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAl+q/OpfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2JhaW5lcy5uZXQACgkQXiijOwuE9Xd51BAAinwaFsmiRFUPttJP9RutzROS0rh7e8yL83pkM//kJoP+KDqfRNJ3eRz7sHwiWD5hbdn/Yyi4a0sAwKgHNuJhvU5ijWBLOzWJ0sFk0QrDZfeejamtYikssHasYJfwXm9gE2SzQJJq1E6SxsMcfjbpwsmw0Pl2K2LIptg7H3wMaj9ooLxVMVNfswSAGpka1fdpWIYIElgU8fqJ3uSOhMizpiSzpgh73FXadqntLA7/5Bzuk4h6C71TfNRQIJbqeT27SB5fnacUl5faSa7oyqyGF899+iDyvVnCVek6YqzvDLIaVdZrBVs1jkCeUY0LWOStK6/36n++ZPaj26aV1V2yxLztzj77ARZ5S4K9p4ccq780SMT4QiJSgFMnpyr3bga/Wl/WmNGABgaVfzTU68LfPhV+Td4QTvOcRX5kgfZ68+lZ5oVTWD5DwTs3ZRh+IS3MBul3qA4Y56DDc80QrVeWKheDxbVaB5Vhya+OP+Pr8b9qJjzUvhO8HGj/ilp8XzgGySCLmS7Px0xVzEELIuqgqqCgNYCH820DaFgctowjhLF7whaPZs+aDuDj8mXV+ATnEJLKDRtO4d8dmIy6bE9E8fupEu4u2HtU8Y3xthQboMoYUUM39fLg73W3pY6XdJBYbPlxavnruijlyJ45awYL//q4uLNgBbKmuJsXQF4C9lI==PIzS-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 12 Nov 2020 22:06
(name . Christopher Baines)(address . mail@cbaines.net)(address . 44559@debbugs.gnu.org)
87v9eaffpa.fsf@gnu.org
Hi,
Christopher Baines <mail@cbaines.net> skribis:
Toggle quote (13 lines)> I found this when trying to build guile3.0-gnutls:>> guix time-machine --commit=94585fffb23079fe71110e2bf99782eb4ccfa12b -- build --no-grafts --check guile3.0-gnutls> >> FAIL: status-request-revoked> ============================>> trying NORMAL:-VERS-ALL:+VERS-TLS1.2> received status request> received status request> cert_verify_callback:263: certificate verify status doesn't match: 100402 != 22FAIL status-request-revoked (exit status: 1)
This was fixed upstream between 3.6.12 and 3.6.14 with this patch byBernhard (it’s a small world!):
Toggle snippet (15 lines)commit ed208fe55f31478732fd6cc394f9576b315a42cdAuthor: Bernhard M. Wiedemann <bwiedemann@suse.de>Date: Sun Apr 5 15:09:57 2020 +0200
tests: Fix status-request-revoked after 2020-10-24 included certs expire 2020-10-24 so this test fails after that date. Fixes #967 This patch was done while working on reproducible builds for openSUSE. Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de>
The question for us becomes how to ensure long-term reproducibility inthe presence of such bugs.
In this case, I think the only solution would be to change the systemclock when one rebuilds GnuTLS (or to use ‘--without-tests=gnutls’, butyou end up with different derivations, which is not necessarilydesirable).
Thoughts?
Ludo’.
M
M
Marius Bakke wrote on 12 Nov 2020 22:18
(address . 44559@debbugs.gnu.org)
87zh3mb7fr.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (10 lines)> The question for us becomes how to ensure long-term reproducibility in> the presence of such bugs.>> In this case, I think the only solution would be to change the system> clock when one rebuilds GnuTLS (or to use ‘--without-tests=gnutls’, but> you end up with different derivations, which is not necessarily> desirable).>> Thoughts?
There is a related bug report here:
https://issues.guix.gnu.org/39310
Perhaps we could make a "--with-system-clock" option for 'guix build'that instructs the daemon to fake the system time?
-----BEGIN PGP SIGNATURE-----
iQFDBAEBCgAtFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl+tppgPHG1hcml1c0BnbnUub3JnAAoJEKKgbfKjOlT6SZUH/2JQce28Rehio2Dk1QbAXM2/8Peo8xhfOnA8NYzJuUkjaqf8LNEs7uB/4zGsJ51IHznTqLecuqdjO+g6zEpzzNrdXmvVqv9A2XcyGGa+ci5hUVKErrG+KGTQEiEtkRUjkzBKGZKv2jc4MpnXJgsDl0qidIZIOi/JmuC1vtSTVM09dG8pj79MefTFKuJtRv0xEpXNRiaJNOjHO5jiThimoiKl15XtSgexPgU0mzv9MV2Po3QRbhc/EE49P/oxuJqjmwFSPdCwL/0YlNEemr2bQx18ps6H9y9Hmg7W5awKGRn0vAK5I45i0jyJyVWHk0a90lEIJSLwJF4Pul2CmpJsVm0==g9FH-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 15 Nov 2020 12:05
(name . Marius Bakke)(address . marius@gnu.org)
87zh3iani0.fsf@gnu.org
Hi,
Marius Bakke <marius@gnu.org> skribis:
Toggle quote (19 lines)> Ludovic Courtès <ludo@gnu.org> writes:>>> The question for us becomes how to ensure long-term reproducibility in>> the presence of such bugs.>>>> In this case, I think the only solution would be to change the system>> clock when one rebuilds GnuTLS (or to use ‘--without-tests=gnutls’, but>> you end up with different derivations, which is not necessarily>> desirable).>>>> Thoughts?>> There is a related bug report here:>> https://issues.guix.gnu.org/39310>> Perhaps we could make a "--with-system-clock" option for 'guix build'> that instructs the daemon to fake the system time?
How would it fake it though?
There are time_namespaces(7), but it’s only for CLOCK_MONOTONIC andCLOCK_BOOTTIME.
LD_PRELOAD like ‘datefudge’ does is probably not a viable option.
Ludo’.
L
L
Ludovic Courtès wrote on 16 Nov 2020 16:04
control message for bug #44559
(address . control@debbugs.gnu.org)
87zh3huyuf.fsf@gnu.org
severity 44559 importantquit
J
J
jeremiah wrote on 31 Dec 2020 01:27
Solution
(address . 44559@debbugs.gnu.org)
87k0syddlu.fsf@ITSx01.pdp10.guru
I created a procedure to work around the build failure and enable asuccessful build:

# when gnutls-3.6.12 build breaks you need to do:# run the following as root# turn off networkingip link set enp0s25 down# Fixup the time so that the build will succeedtimedatectl set-ntp falsetimedatectl set-time '2020-10-01'# Try to build but it will absolutely fail by lack of source if you# don't enable networking or because you enable networking.# But turn on networking when specified belowguix time-machine --commit=94585fffb23079fe71110e2bf99782eb4ccfa12b --# build --no-grafts --check guile3.0-gnutls# after it finishes building# /gnu/store/vhphki5sg9xkdhh2pbc8gi6vhpfzryf0-gnutls-3.6.12.drv# and starts building# /gnu/store/akm0wl58avib46g3d9razlfzfgfg8m6m-python-3.8.2.drv...# but before it begins building# /gnu/store/bja7gqzxr62a0akid0rpzmynzy78nkwg-zstd-1.4.4.tar.gz.drv.# Fix the time and turn on networking as it has additional things to# download.# specifically# https://github.com/facebook/zstd/releases/download/v1.4.4/zstd-1.4.4.tar.gz# and substitutes for some reason# failing to do so will result in you needing to repeat the above steps# again.timedatectl set-time '$current_date'timedatectl set-ntp true# turn on networkingip link set enp0s25 up# it'll fail building because the time is current again# But that is fine, we now will not need networking for this build cycle# and thus the altered time will be fine and the build will be# successful this time# turn off networkingip link set enp0s25 down# Fixup the time so that the build will succeedtimedatectl set-ntp falsetimedatectl set-time '2020-10-01'#guix build gnutls@3.6.12 finallyguix time-machine --commit=94585fffb23079fe71110e2bf99782eb4ccfa12b --# build --no-grafts --check guile3.0-gnutls# wait until it completes.# Then we can put the system back in a working statetimedatectl set-time '$current_date'timedatectl set-ntp true# turn on networkingip link set enp0s25 up
C
C
Carl Dong wrote on 16 Feb 22:00 +0100
Re: bug#44559
(address . 44559@debbugs.gnu.org)
CF6115A8-8536-4087-BC71-F6BC05D74F4F@carldong.me
Hi all,
As bitcoin core begins the planning to officially transition to Guix-based releases, I've had many community members build guix v1.2.0 from source and afterward attempt `--bootstrap --no-substitutes` builds. As you may imagine, they are getting stuck on this gnutls problem and cannot proceed further.
I'm wondering:
1. Is there a workaround that does not involve changing the system time? We have attempted several flags: 1. --with-graft=gnutls=gnutls@3.6.14 2. --without-tests=gnutls 3. --with-input=gnutls=gnutls@3.6.14 These attempts all failed to work around this bug, and I’m curious as to why that would be. My guess would be that when we do `--bootstrap`, Guix bootstraps itself first without taking into account these flags?
2. Since bootstrappability is one of the core tenets of Guix, might it be appropriate to cut a v1.2.1 release with this problem (and any other potential bootstrap problems) fixed? (Happy to discuss in separate thread if more appropriate)
Cheers,Carl Dongcontact@carldong.me"I fight for the users"
L
L
Leo Famulari wrote on 16 Feb 22:49 +0100
Re: bug#44559:
(name . Carl Dong)(address . contact@carldong.me)(address . 44559@debbugs.gnu.org)
YCw+Bh1532zjxRRA@jasmine.lan
On Tue, Feb 16, 2021 at 04:00:11PM -0500, Carl Dong wrote:
Toggle quote (14 lines)> Hi all,> > As bitcoin core begins the planning to officially transition to Guix-based releases, I've had many community members build guix v1.2.0 from source and afterward attempt `--bootstrap --no-substitutes` builds. As you may imagine, they are getting stuck on this gnutls problem and cannot proceed further.> > I'm wondering:> > 1. Is there a workaround that does not involve changing the system time? We have attempted several flags:> 1. --with-graft=gnutls=gnutls@3.6.14> 2. --without-tests=gnutls> 3. --with-input=gnutls=gnutls@3.6.14> These attempts all failed to work around this bug, and I’m curious as to why that would be. My guess would be that when we do `--bootstrap`, Guix bootstraps itself first without taking into account these flags?> > 2. Since bootstrappability is one of the core tenets of Guix, might it be appropriate to cut a v1.2.1 release with this problem (and any other potential bootstrap problems) fixed? (Happy to discuss in separate thread if more appropriate)
You should see what the Guix maintainers say about this.
My personal opinion is that you should fork Guix your use case. If youare building from the bootstrap, there is little added cost to makingminor adjustments like disabling this test. You can periodically re-syncyour fork with GNU Guix as convenient. And it's probably more in tunewith your threat model. [0]
This problem of "expiring software" has occurred several times in Guix'shistory and I'm sure it will happen again. In general, users areexpected to use substitutes to work around it. They are no worse offthan with traditional binary distros in that case.
[0] Savannah is great but lacking the resources to devote to security.
L
L
Ludovic Courtès wrote on 19 Feb 16:33 +0100
(name . Carl Dong)(address . contact@carldong.me)
87lfbkkr6r.fsf@gnu.org
Hi Carl,
Carl Dong <contact@carldong.me> skribis:
Toggle quote (2 lines)> As bitcoin core begins the planning to officially transition to Guix-based releases, I've had many community members build guix v1.2.0 from source and afterward attempt `--bootstrap --no-substitutes` builds. As you may imagine, they are getting stuck on this gnutls problem and cannot proceed further.
Yeah. :-/
Toggle quote (8 lines)> I'm wondering:>> 1. Is there a workaround that does not involve changing the system time? We have attempted several flags:> 1. --with-graft=gnutls=gnutls@3.6.14> 2. --without-tests=gnutls> 3. --with-input=gnutls=gnutls@3.6.14> These attempts all failed to work around this bug, and I’m curious as to why that would be. My guess would be that when we do `--bootstrap`, Guix bootstraps itself first without taking into account these flags?
‘--without-tests’ should work, but you need to pass the right versionnumber I guess?
Toggle quote (2 lines)> 2. Since bootstrappability is one of the core tenets of Guix, might it be appropriate to cut a v1.2.1 release with this problem (and any other potential bootstrap problems) fixed? (Happy to discuss in separate thread if more appropriate)
I agree it’s a problem, and yes, it would probably be a good idea torelease 1.2.1 with the upgraded GnuTLS we now have in ‘master’.
Longer-term, we need to find a way to address or avoid this issue. Abrute-force approach would be to have the build machines at ci.guix runwith a clock ten years ahead. That should generally be fine since theonly place where timestamps matter are unmodified upstream tarballs. Inall other cases, mtime is set to 1.
Perhaps we could start by testing this hypothesis on a separate buildfarm. Chris, Mathieu, WDYT?
Thanks,Ludo’.
M
M
Maxime Devos wrote on 19 Feb 19:32 +0100
5d72d9c66d0e9f70f6ff1fb3b4d08ed530551288.camel@telenet.be
Hi Guix,
On Fri, 2021-02-19 at 16:33 +0100, Ludovic Courtès wrote:
Toggle quote (7 lines)> [...]> Longer-term, we need to find a way to address or avoid this issue. A> brute-force approach would be to have the build machines at ci.guix run> with a clock ten years ahead. That should generally be fine since the> only place where timestamps matter are unmodified upstream tarballs. In> all other cases, mtime is set to 1.
Alternatively, could the build container be adjusted to always begin at1970-01-01, using ‘time namespaces’?
Linux: https://lwn.net/Articles/766089/Hurd analogue: https://www.gnu.org/software/hurd/gnumach-doc/Host-Interface.html#Host-Interface
(Of course, someone needs to find the time to write the patches first. MaybeI'll have a try at it eventually, but probably not anytime soon.)
Also, is there any particular reason to set the clock only ten years ahead,and not, say, a millenia or two? Some possible reasons:
* year 2038,2446 problem: the ext2 and ext4 filesystems have a restricted date range* year 2038 problem: https://www.gnu.org/software/hurd/gnumach-doc/Host-Interface.html#Host-Interface
IMO, the year 2038 problem is a bug and affected packages should simply be fixed. But perhaps reality is a little more complicated.
Greetings,Maxime
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYDAEQhccbWF4aW1lZGV2b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7kPYAQCWmod5dnlTmIL1qglgDABubuZzyIEjBAIK/uHVrA0dZAD+IcBDUvCqH9f1+T99P4Y0RxasGyd4fDOUFWrCI23sNAY==dA4d-----END PGP SIGNATURE-----

C
C
Carl Dong wrote on 20 Feb 00:49 +0100
(address . 44559@debbugs.gnu.org)
E95315E4-134B-43E0-BE5F-575B69030940@carldong.me
Hi Guix!
Thanks to all of you for your thoughtful replies!
On Feb 19, 2021, at 10:33 AM, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (2 lines)> I agree it’s a problem, and yes, it would probably be a good idea to> release 1.2.1 with the upgraded GnuTLS we now have in ‘master’.
I’m very heartened by your affirmation of the project’s support of bootstrappability and building from source. :-)
In addition, I think it would be good to make sure that the package transformation options are powerful enough to allow users to sidestep these problems in their own workflow and decrease the pressure on maintainers.
On Feb 19, 2021, at 10:33 AM, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (3 lines)> ‘--without-tests’ should work, but you need to pass the right version> number I guess?
Oh! That may be the case. I am using `guix time-machine` however, and that does not yet have the `--without-tests` flag, I have opened bug#46650 so that we can discuss that issue there.
On Feb 19, 2021, at 1:32 PM, Maxime Devos <maximedevos@telenet.be> wrote:
Toggle quote (2 lines)> Alternatively, could the build container be adjusted to always begin at> 1970-01-01, using ‘time namespaces’?
Unfortunately, as Ludovic mentioned earlier in this thread, time_namespaces(7) is only for CLOCK_MONOTONIC and. CLOCK_BOOTTIME. :-(
Carl Dongcontact@carldong.me"I fight for the users"
Toggle quote (37 lines)> On Feb 19, 2021, at 10:33 AM, Ludovic Courtès <ludo@gnu.org> wrote:> > Hi Carl,> > Carl Dong <contact@carldong.me> skribis:> >> As bitcoin core begins the planning to officially transition to Guix-based releases, I've had many community members build guix v1.2.0 from source and afterward attempt `--bootstrap --no-substitutes` builds. As you may imagine, they are getting stuck on this gnutls problem and cannot proceed further.> > Yeah. :-/> >> I'm wondering:>> >> 1. Is there a workaround that does not involve changing the system time? We have attempted several flags:>> 1. --with-graft=gnutls=gnutls@3.6.14>> 2. --without-tests=gnutls>> 3. --with-input=gnutls=gnutls@3.6.14>> These attempts all failed to work around this bug, and I’m curious as to why that would be. My guess would be that when we do `--bootstrap`, Guix bootstraps itself first without taking into account these flags?> > ‘--without-tests’ should work, but you need to pass the right version> number I guess?> >> 2. Since bootstrappability is one of the core tenets of Guix, might it be appropriate to cut a v1.2.1 release with this problem (and any other potential bootstrap problems) fixed? (Happy to discuss in separate thread if more appropriate)> > I agree it’s a problem, and yes, it would probably be a good idea to> release 1.2.1 with the upgraded GnuTLS we now have in ‘master’.> > Longer-term, we need to find a way to address or avoid this issue. A> brute-force approach would be to have the build machines at ci.guix run> with a clock ten years ahead. That should generally be fine since the> only place where timestamps matter are unmodified upstream tarballs. In> all other cases, mtime is set to 1.> > Perhaps we could start by testing this hypothesis on a separate build> farm. Chris, Mathieu, WDYT?> > Thanks,> Ludo’.
L
L
Ludovic Courtès wrote on 20 Feb 14:46 +0100
(name . Maxime Devos)(address . maximedevos@telenet.be)
87v9amj1hn.fsf@gnu.org
Hi,
Maxime Devos <maximedevos@telenet.be> skribis:
Toggle quote (13 lines)> On Fri, 2021-02-19 at 16:33 +0100, Ludovic Courtès wrote:>> [...]>> Longer-term, we need to find a way to address or avoid this issue. A>> brute-force approach would be to have the build machines at ci.guix run>> with a clock ten years ahead. That should generally be fine since the>> only place where timestamps matter are unmodified upstream tarballs. In>> all other cases, mtime is set to 1.>> Alternatively, could the build container be adjusted to always begin at> 1970-01-01, using ‘time namespaces’?>> Linux: https://lwn.net/Articles/766089/
Unfortunately, time namespaces are just for CLOCK_{MONOTONIC,BOOTTIME},which I think is of little use here:
https://issues.guix.gnu.org/44559#3
Toggle quote (10 lines)> Also, is there any particular reason to set the clock only ten years ahead,> and not, say, a millenia or two? Some possible reasons:>> * year 2038,2446 problem: the ext2 and ext4 filesystems have a restricted> date range> * year 2038 problem: https://www.gnu.org/software/hurd/gnumach-doc/Host-Interface.html#Host-Interface>> IMO, the year 2038 problem is a bug and affected packages should simply be fixed.> But perhaps reality is a little more complicated.
Yeah, one problem at a time. :-)
Setting it 10 years ahead would cache the kind of issue we’re talkingabout, while not opening the Y2038 can of worms. I think we need to trythat out and see how it goes.
Ludo’.
L
L
Ludovic Courtès wrote on 20 Feb 15:12 +0100
Detecting “expiring” builds
(name . Maxime Devos)(address . maximedevos@telenet.be)
8735xqj0b0.fsf_-_@gnu.org
It occurred to me that, just like we have childhurds, we could provide aservice that sets up a sub-Guix System running in a VM with its clockset years ahead, and you would offload to that. That’s not perfect, butit’s a rather easy addition.
Another option would be to have built-in support in the daemon. If youturn on some option, it would transparently run derivation builds inqemu-user (does that support changing the system date?) or similar, butthat’s more work.
Ludo’.
C
C
Christopher Baines wrote on 22 Feb 23:36 +0100
Re: bug#44559:
(name . Ludovic Courtès)(address . ludo@gnu.org)
875z2jn30q.fsf@cbaines.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (3 lines)> Perhaps we could start by testing this hypothesis on a separate build> farm. Chris, Mathieu, WDYT?
I'm currently thinking about attempting these kind of things (testingbuilding derivations under different conditions) through the agent tagsin the Guix Build Coordinator.
I haven't used this functionality yet, but it's mostly implemented. Theidea is that agents have tags, that describe various attributes that areimportant (time=normal, time=future, maybe for example), and builds canalso be targeted at specific agents by tagging the builds with thosesame tags.
Where I'm going with this is that I'm not sure a separate build farm isneeded, it would be good to just incorperate this in to the build farmused for testing patches and non-master branches.
-----BEGIN PGP SIGNATURE-----
iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmA0MfVfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2JhaW5lcy5uZXQACgkQXiijOwuE9XfzTA//dDib81Fosmi7ryPzjls5juWaCuIeyDrFKmr62mhR6ekqBSSzIpbMPwKdqXRSfVUAGrnHoYrUSmOa4svQzmA/e9pS0qH9dLrTAOVBDQTROTSIjHHZe4m0aYHvhug8lMxxAzV7hjgh+A5QRtAnuY+BMvmjohyqSMGhsVizxlurSywEo5z9t4wgmMex6u4jwKL5AUwEJSrDOpdQjGHhjoDsCdPJNsKQ2pn6U48D1A9nDbo99wQwHK/iOY6iB8H+pMEsJsQ0YCsprAfOZeywVT5xqFcOJJLPjGv6CwQrKGUiDsFkclwMfNK14jbpAsqY5H3YbrcyuouLqjCT6bafVzxkyK1s8Rp4X+ExehZLH2kcKpxNENAHZ3drKuigY/CnBxtwTQTCmktKFhkX+mklyFVbqYbEktEl+X71P1MtrNPV0Ogg0ByuR0UHduMa8llNM5Utl+70jsCkgtjRLHFlMokolpbuqGOvQF81BVUGGs32jjBEJhC0X04Keo1Wib/HioypvAQquPkWnV7VlQW5NkqTnoXMqzH37tXYWrmPbeaCcjeDk/NUl/+9QtZmIVdqQ0SINxo8Equ3do5UGM3gqR9uxhaopLcvPyDEFL+70wfmokLkodJQlZeITIWdo1YRURzGF8VXKNi+xvr+i3zoSJPe9+68w79qVZw6/I5KlhXdU2E==IyUw-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 23 Feb 09:41 +0100
(name . Christopher Baines)(address . mail@cbaines.net)
87o8gb6us7.fsf@gnu.org
Hi,
Christopher Baines <mail@cbaines.net> skribis:
Toggle quote (15 lines)> Ludovic Courtès <ludo@gnu.org> writes:>>> Perhaps we could start by testing this hypothesis on a separate build>> farm. Chris, Mathieu, WDYT?>> I'm currently thinking about attempting these kind of things (testing> building derivations under different conditions) through the agent tags> in the Guix Build Coordinator.>> I haven't used this functionality yet, but it's mostly implemented. The> idea is that agents have tags, that describe various attributes that are> important (time=normal, time=future, maybe for example), and builds can> also be targeted at specific agents by tagging the builds with those> same tags.
Sounds nice! Also varying kernels I guess.
Toggle quote (4 lines)> Where I'm going with this is that I'm not sure a separate build farm is> needed, it would be good to just incorperate this in to the build farm> used for testing patches and non-master branches.
Sure. For the build-in-the-future thing, I think we could just do thatby default; what I meant is that we just need to double-check beforehandthat nothing breaks badly.
Thanks,Ludo’.
C
C
Christopher Baines wrote on 23 Feb 09:55 +0100
(name . Ludovic Courtès)(address . ludo@gnu.org)
8735xnmadw.fsf@cbaines.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (21 lines)> Hi,>> Christopher Baines <mail@cbaines.net> skribis:>>> Ludovic Courtès <ludo@gnu.org> writes:>>>>> Perhaps we could start by testing this hypothesis on a separate build>>> farm. Chris, Mathieu, WDYT?>>>> I'm currently thinking about attempting these kind of things (testing>> building derivations under different conditions) through the agent tags>> in the Guix Build Coordinator.>>>> I haven't used this functionality yet, but it's mostly implemented. The>> idea is that agents have tags, that describe various attributes that are>> important (time=normal, time=future, maybe for example), and builds can>> also be targeted at specific agents by tagging the builds with those>> same tags.>> Sounds nice! Also varying kernels I guess.
Yeah, there's a whole range of variations it would be nice tomethodically test against (filesystems, Linux versions, system time, onevs many cores, ...).
Toggle quote (8 lines)>> Where I'm going with this is that I'm not sure a separate build farm is>> needed, it would be good to just incorperate this in to the build farm>> used for testing patches and non-master branches.>> Sure. For the build-in-the-future thing, I think we could just do that> by default; what I meant is that we just need to double-check beforehand> that nothing breaks badly.
Ah, I guess that might work, if I have some time, I'll have a look in tomaking the necessary machine changes.
-----BEGIN PGP SIGNATURE-----
iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmA0wutfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2JhaW5lcy5uZXQACgkQXiijOwuE9XehGRAAld83UM+Ugw1JQ02r3N1BA5URMhNuJVXgb7mVH+IgU4xIlnLzC34vyKV3nnmXmsJuf0dOK98XrXQcaCoBin01f29unuMMZl2sgXTzpeRRAUlCL16tpopPQaWVFlOw2l+0yzVU+E1WB1Twa762hs5WAVF4hV5qfUQvdjgOVqL1+/Pg0EMlvMQSfUCoWIJdUzI/q6P7HENSkmboNFk5tHaXGblL0XJ5pfQXe/XRja88GKb3ITvgeluepc64eE1qVmvaXdaYjknejPbbuCQSdk/3Mwb9Ro3tmoBqY4czl0xUe0fYK6WxSvBzIhKEK1dDHyMJOvQKfdYMOs3/Q3rVtgZ2UJQxK0d1HxGzTVgzQwzArRbNXDG1xaEa3tBO8MMDHijIU7IpByxXBAclaGZXGoU9szWJ9GLV2zCZMOWRrklB+xWkMHXl3NIW30akJjufVwKPQNMpHF8X2mXopnRGpiS2Xro+uyqyqo/2dnLraS16Zcnlyxax7/rUQqS3PZCdCWqTsCpQmiNbD2wv7aleJG1HVsGJ+Gq6+mxILYFafaysvIXwV8JthaNvB9XEju4N9dnWRhbulT5W3Hc/x129U2WDBqOlQQPQnOvHAzq/v+U/aF8UWjJMdQBlQ5z0rxrpTKnmJ8rK1MURick+oru7dnTjc4mbAcyDDSs3uWd5P+C3u5o==Ag9k-----END PGP SIGNATURE-----
?