Hello Leo,
> "[...] the ability to compare the results of two evaluations
> and show the *differences* between those results, i.e. to enumerate the
> newly failing jobs, the newly succeeding jobs, and the newly aborted
> jobs."
Yes that's something we should definitely add to Cuirass. On the
Hello,
> That’s indeed the case: the store is smaller than it used to be (but
> still 27 TiB), it’s GC’d more aggressively than before, and instead we
> rely on /var/cache/guix/publish for long-term storage.
>
> Perhaps we should go further and keep the store smaller though.
That's what I did
Hello Maxim,
> They pointed to me that the page wouldn't load in LibreJS, which is true
> (I had forgotten the issue myself, having whitelisted the domain long
> ago).
Fixed with 8726ef9c6572cd07eafd96fce76fd329e9faf469.
Thanks,
Mathieu
Hello,
> VTK 8 fails to build on core-updates-frozen. This blocks freecad.
> It looks like libraries aren’t properly linked with other VTK
> libraries. The build log is littered with output like this:
The vtk-8 package was dedicated to freecad. I managed to get freecad to
use vtk-9 so that
Hello,
On the newly installed honeycomb machines, some Cuirass remote-worker
process freeze completely and stop communicating with the
remote-server.
This has already been observed, but is for some reason more repeatable
on those machines.
Here are the information I could collect on such a
Hello,
> ../include/agg_renderer_outline_aa.h:1378:45: error: binding reference of
> type ‘agg::line_profile_aa&’ to ‘const agg::line_profile_aa’ discards
> qualifiers
> 1378 | line_profile_aa& profile() { return *m_profile; }
Fixed with f22dfba53032c59fb260173143abf0e4e9a4f1e1.
Hello Tobias,
This error was likely caused by the core-updates-frozen-batched-changes
specification removal in Cuirass. Some builds keep referring to removed
specifications causing unexpected behaviours.
The strange thing is that I'm using the "DELETE CASCADE" SQL property
that should remove
Hey,
The following MR were accepted upstream:
https://gitlab.gnome.org/GNOME/gnome-boxes/-/merge_requests/462
https://gitlab.gnome.org/GNOME/gnome-boxes-logos/-/merge_requests/12
https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/360/diffs
I applied those patches on c-u-f with:
Hello,
I observed the following deadlock on the cuirass-remote-server log file
on berlin:
--8<---cut here---start->8---
2021-11-17T23:12:00 fetching
'/gnu/store/g6iqlblaxyvlvycrri110kfli9vhm8s0-julia-mlstyle-0.4.10.drv' from
http://141.80.167.159:5558
> mathieu@berlin ~$ ps auxww|grep 37195
> root 37195 0.0 0.0 183260 33440 ?Sl 03:59 0:00
> /gnu/store/49vfv8l1j96bbd73ssbqanpnjz83arss-guix-1.3.0-11.014f1b6/libexec/guix/guile
> \ /gnu/store/49vfv8l1j96bbd73ssbqanpnjz83arss-guix-1.3.0-11.014f1b6/bin/guix
> gc
Hello,
On berlin, the daily GC command is still running whereas it was started
9 hours ago.
--8<---cut here---start->8---
guix processes
[...]
SessionPID: 37231
ClientPID: 37195
ClientCommand:
Hello Vagrant,
This is fixed on master with d5073fd113c621fe0b55382f7dd336ee118e759f.
Thanks,
Mathieu
Hello,
I noticed that some builds were missing dependencies in the Cuirass web
interface. For instance, compare those two builds of python-git-review:
https://ci.guix.gnu.org/build/89691/details
https://ci.guix.gnu.org/build/135/details
When looking closer to one dependency,
Hello,
> However, we only propose an xzipped iso (and not a raw iso file), so
> the data does not provide information on downloading. Either we have
> an outdated osinfo-db, or the lack of download option prevents boxes
> from showing it as a choice.
The reason for GNU Guix not showing up in
Hey!
> This should be fixed by df46bef48eaa43c502fa9193371692c039b460c1, whose
> log contains all the gory details. :-)
Wooo, thanks for fixing that :) I gave it a try but this is still a part
of the code base I'm not familiar with.
> This should allow us to move forward with system testing
Hello Jonathan,
Thanks for the complete bug report, this is fixed with
d58e52b0713648dd30d41b41277854a935d8d15a.
> The installation image comes from
> a3324e57531186a42feb3aa488556faa67386e9c. Its built with '--no-grafts'
> due to https://issues.guix.gnu.org/50676.
This one looks more tricky
Hey,
> With this patch I think the 'install-keystore' phase of icedtea-7 will
> also have to be updated to search for the ".pem" files instead of the
> ".crt" ones.
Right, thanks for the heads up. I pushed the original two patches plus a
new one to fix icedtea-7.
Thanks,
Mathieu
Hello,
> In kdenlive, I can't add any media ("clips") to a project because the
> file choosing dialog is not working.
This cannot be reproduced on master, closing.
Thanks,
Mathieu
Hey,
The duplicated system derivation appears to be a grafted version of
the first one.
Running:
--8<---cut here---start->8---
./pre-inst-env guix system image gnu/system/examples/bare-bones.tmpl -t qcow2
--no-grafts
--8<---cut
rom 18248cc817952c690694707cc965283dad1933c2 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Date: Mon, 20 Sep 2021 10:26:30 +
Subject: [PATCH 1/2] gnu: certdata2pem: Produce pem files.
Create files with pem extension instead of crt.
* gnu/packages/certs.scm (certdata2pem)[arguments]<#:phases>{fix-extension}:
Hey,
>>#:strip-flags '("--strip-debug" "--enable-deterministic-archives")
Pushed as 650e85d85514c5fae06adf97ae615643a41bbbd8 :).
> That one works as well. I tested it :)
Thanks for the suggestion Ludo and for the testing Jonathan.
Mathieu
Hey Ludo!
> What command did you use?
The same one as you :)
> drops me in the GRUB rescue shell right from the start, but I think
> that’s because the command surprisingly builds an EFI image, as can be
> seen from the generated genimage.cfg:
Yep, that would be because of the Grub stripping
Hello,
When a producing a disk-image, the system derivations are built twice:
--8<---cut here---start->8---
building /gnu/store/8w9ic3h26w6rp4pj94gd93lw2bnqywgm-system.drv...
successfully built /gnu/store/8w9ic3h26w6rp4pj94gd93lw2bnqywgm-system.drv
building
Turns out stripping Grub modules was causing this issue. I'm not sure
why we do not experience this issue on master.
Anyway, 71aa29911cf3f4e6db5f9bff9237308b5f93283d fixes it for me.
I also discovered another issue related to image creation that I'll
report separately.
Thanks,
Mathieu
Hello,
> Mathieu, can you think of a way we could address this? Maybe Cuirass
> could handle those /log URLs since it already has build log URLs anyway?
I fixed it with 60190401ce4ccc890629ec3cb22a84a8ab8c2645 in Cuirass and
abaf1392287d50a7225cdb3e3f3f8b82b827c7db in maintenance.
I now
Hello Maxim,
> OK, nevermind, I found that the test case was deleting the 'fix-tests'
> build phase from glade3, and building the package. I confirm the fix
> works!
Great, that's exactly what I was trying to test but you beat me to it
:). I'll be afk for a month so I won't be able to confirm
Hello Maxim,
>> 1. rustc bootstrap from 1.39 (the itch to make it faster comes back
>> everytime I have to build it ;-)).
>
> I'm nearing completion on this front.
That will be a welcomed improvement!
>> 2. fontconfig update that should allow per-profile fonts management via
>>
Hello Carl,
> The error line is L1299: "make: stat:Makefile: sterror: unknown error”
This reminds me of:
https://lists.gnu.org/archive/html/bug-guix/2020-05/msg00335.html.
I never took the time to fix this issue. Bottom line is that building
the bootstrap toolchain fails on NVME disks because
Hello,
The generation of the documentation of the Gnome projects is broken on
core-updates-frozen. Passing the "-Dgtk_doc=true" build option to evince
or libhandy packages results in the following error:
--8<---cut here---start->8---
Traceback (most recent
Hello,
I tried to upgrade glade to the 3.38.2 release on core-update and
encountered the following test issue:
--8<---cut here---start->8---
2/5 modules FAIL0.29s killed by signal 5 SIGTRAP
>>>
Hello Leo,
> ld: ../../lib/libWebCore.a: error adding symbols: malformed archive
I missed your thread and ended up applying the same set of patches, to
reach the same error.
According to
https://stackoverflow.com/questions/45654547/linker-could-not-read-symbols-malformed-archive,
this could
Hello,
When building "emacs-org-contrib" on core-updates-frozen, the following
message is printed:
--8<---cut here---start->8---
tar: Exiting with failure status due to previous errors
error: in phase 'unpack': uncaught exception:
%exception #< program:
Hello,
> deleting the records with `starttime` equal to 0 from `builds` table,
> cuirass could start again. but the issue happens again after a while.
This is fixed with aa2f682facce5de727bdae5bbd5d1a2a27923ebb and
1dcaebc66097ce503bd827c7b28e0a0936c1daee.
Thanks,
Mathieu
Fixed with b210fcc963865acd820078e705132cd2b5f339a7.
Thanks,
Mathieu
Hello Julien,
> When searching for builds on the cuirass website, I made a typo,
> looking for "maven sytem:x86_64-linux" (instead of system). The
> website returns an empty error 500 page.
That's fixed with e95e723f3c4fddc4a2fa7a9ac58230c262470c76.
Thanks for reporting,
Mathieu
Hello!
> Sorry for taking so long to respond. I think the issue has been indeed
> solved,
> as I retried installing Guix with the latest image from a few days ago and I
> didn't encounter this issue anymore. Thank you!
That's great to hear, thanks for testing!
Mathieu
Hey Ludo!
I found out the reason of this failure, the .185 key was not authorized
on Berlin. This issue while really simple, took us a long time to
detect. I think we need to come out with a big warning somewhere when a
substitute is refused because the server is not authorized.
In the
Hello Ludo,
> It’s the first time I see this. My understanding is that Cuirass makes
> a GET request on ‘guix publish’ upon build completion. Could there be a
> race condition or something that can explain this?
Your understanding is correct :). However, looking at the
Hello,
The Cuirass RSS feed is reported as invalid by the W3C checker, see:
https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Fci.guix.gnu.org%2Fevents%2Frss%2F%3Fspecification%3Dmaster.
Thanks,
Mathieu
Hello Hartmut,
Thanks for this patchset!
> +(define* (api-url base-url path #:rest query)
> + "Build a proper API url, taking into account BASE_URL's trailing slashes."
s/BASE_URL/BASE-URL/
You could also indicate what is the expect format for query: '("name"
"value") lists.
> +
Hello,
> After some more discussion with Tobias on IRC, it seems that this was caused
> by a `git pull` followed by a `make` and lacked a `make clean-go`. After
> running
> `make clean-go` and rebuilding, the problem went away.
I can confirm this was caused by an API mismatch in
Hello Christophe,
> During the manual partitioning, if you delete a free space (by
> mistake), the installation crashes (message: "the installer has
> encountered an unexpected problem (...)": see picture) and you have to
> start again from the beginning (language choice).
This is fixed with
Hello,
> Seems like the definition of icecat or some dependency of icecat does
> not support aarch64. Anyway, here is a patch. Could you confirm it works?
Applied as 5ef96ecaaeeabd5500e406f0103ca52ec079fdb9.
Thanks,
Mathieu
Hey,
> But maybe I’m not looking at the right thing.
>
> Do you have evidence or a reproducer?
Yes, adding the following debug message here:
--8<---cut here---start->8---
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -416,6 +416,7
> When rolling back to an older guix@f1bfd9f, things work as expected. The
> regression probably lies in between those 1084 commits. I'll try to
> bisect more precisely later on.
The bisection leads to this commit:
8cef92d0633850d97c1a1d4521812268f56672be, but it doesn't appear clearly
to me
Hello,
When using guix@caf4a7a2, I cannot no longer build a functional
guix-daemon using the following classic commands:
--8<---cut here---start->8---
guix environment guix
./configure --localstatedir=/var --sysconfdir=/etc
make -j4
--8<---cut
Hello Maxime,
> guix substitute: warning: [...].local: host not found: Naam of dienst is niet
> bekend
> guix substitute: warning: tijdens het binnenhalen van
> https://ci.guix.gnu.org/nar/lzip/r8a9kzhhx89rmmkz66i3324acgliqdwa-gdm-3.34.1:
> de server is een beetje traag
> guix substitute:
With the attached file,
Mathieu
Hey,
> Mathieu, do you have Zabbix graphs showing how we’re doing wrt. storage
> on berlin?
Here's one attached, we have been stable around ~10TiB of free space for
the last couple of months.
> If we’re doing well, we should definitely increase the ‘guix publish’ TTL.
What about increasing
Hey,
> I've installed Guix about 5 times after building an image from the
> latest changes, works perfectly for me both with encrypted and
> unencrypted root partitions.
Great, I improved the installation device detection again with:
e12be802e02b3345a753e7ec1287852a7337a0a5.
I think we can
Hey,
> Does Parted provide a way to tell whether a storage device is read-only?
> That would be ideal.
Yes it does, but this is not enough for a reliable installation device
detection. In Qemu the installation device is /dev/sr0 that is
reported as read-only by parted.
Using real hardware,
Hello Matthias,
> I built the iso from commit 245cab2abc1fd74d1df489e500432c66c88f6b25 and
> confirm that the partitioning works now.
> Only need to figure out how to get my wifi running and soon I'll be booting
That's great to hear, thanks for testing! Regarding Wifi support, you
can have a
Hello Ludo,
> Possible improvements are:
>
> 1. gracefully handling this error;
> 2. filtering out read-only storage devices from the menu.
>
> Thoughts?
Thanks to David's help[1], I realized that the non-filtering of the
installation device was causing some of the (uuid->string #f) issues
Hello Matthias,
> I had Linux installed already on this computer and would not need to
> re-partition.
>
> Any ideas how to fix this?
Thanks for the report. This should be fixed with:
245cab2abc1fd74d1df489e500432c66c88f6b25. The issue was that the
installer could not mount FAT16 partitions.
Hello,
This could be fixed by 154a4e046281c28e39b5016e965d3d937a2ea4a1.
Would it be possible for you to try to reproduce the issue with this
installation image: https://ci.guix.gnu.org/download/331?
It would also be great if you could switch to a TTY (cltr-alt-f3), run
"fdisk -l" and report
Hello,
> Sorry for not specifying extra details, I forgot: I used guided
> partitioning for the whole disk. Selected XFCE as the only DE, the SSH
> daemon and NSS certs as extra stuff, and the system language as
> Romanian. Access to the internet was provided through an Ethernet cable.
Thanks
Hey,
> It seems that for some reason the installer has automatically picked a
> mount point of `/boot/efi' for `/dev/sda2' in addition to the mount
> points on my actual hard drive. I now see an error dialog saying that
> it can't retrieve the UUID of /dev/sda2 when I try to proceed past the
>
Hello David,
>> I'm using manual partitioning with the first partition mounted as the
>> ESP partition and the sixth partition as the root directory.
My issue here is that those partitions were never formatted. The
read-partition-uuid method returns #f on unformatted partitions, causing
the
Hey David,
> Take a look at these logs from a `guix repl' session (sorry for the
> image, couldn't copy text from that machine):
>
> https://0x0.st/-_no.jpg
Thanks for the very valuable information here! I managed to reproduce a
very similar crash in Qemu by simulating your hard drive layout:
Hello Leo,
> I wonder what is going on?
The current mutt package output is:
--8<---cut here---start->8---
mathieu@meije ~$ guix build mutt --no-grafts
/gnu/store/c0wp5iq5k11mvqrm4bs011qlm7qy48ia-mutt-2.0.7
--8<---cut
Hello David,
> I also just hit this issue while using the graphical installer on a
> machine that previously had Guix installed on it via the shell-driven
> manual installation flow. I'm working on a video to show how to install
> Guix using the graphical installer so it's a big blocker for me
Hello Andrew,
> This happens when I use _any_ partitioning scheme, manual or
> automatic.
Thanks for the complete bug report. I think that this bug falls into the
same category as https://issues.guix.gnu.org/47996,
https://issues.guix.gnu.org/47567, https://issues.guix.gnu.org/44872 and
Hello,
> Shouldn't cuirass first schedule builds for dependencies before it
> builds dependents?
Yes fixed with
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=d1a95e8b33b454a45bda506a22a8b9d9d2c8b16e.
Thanks,
Mathieu
Hey Ludo,
>> (define* (channel-with-substitutes-available chan url
>> #:key
>> (specification "master"))
>
I have fixed the evaluation complete? field issue with
a2155f41f53eeb5000857e7160c5ad0916dc9bfa.
Hello Leo,
> I think we need to make these "active" of registered derivations into GC
> roots.
This is fixed with 303845d26682e9e9536ef1ff6d6c68ec90fad170.
Thanks,
Mathieu
Hey,
> Otherwise LGTM, but I haven't tested.
Fixed with 7003b2db526fc367664f3a7c4bdbe38a7c717da6.
Thanks,
Mathieu
Hey,
I posted a patchset adding keep-alive support to guix publish earlier:
https://issues.guix.gnu.org/48556.
Thanks,
Mathieu
Hey Ludo,
> Wouldn’t it be enough to look for the latest completed evaluation (of a
> given jobset)?
I guess it would be enough but we would need to specify the jobset that
needs to be used, this way maybe:
--8<---cut here---start->8---
(define*
Hello Maxime,
> warning: avahi daemon is not running, cannot auto-discover substitute
> servers!
This should be fixed with the attached patch.
Thanks,
Mathieu
>From a50bbf99f65d26bbdb0d16112a49335bf913b822 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Date: Fri, 21 May 2021
Hey,
> I'll have a closer look, thanks for your help.
So this snippet in the http-write procedure of the (guix scripts
publish) module:
--8<---cut here---start->8---
(swallow-zlib-error
(close-port port))
--8<---cut
Hey,
> That's on the server side, the actual problem is probably on the client
> side, as I guess there are possibly places where closed connections
> aren't handled properly. This reminds me I sent some patches relating to
> closing connections, this could well be related [1].
Oh, you're
Hello,
We recently have a lot of those errors on Cuirass:
--8<---cut here---start->8---
guix substitute: warning: while fetching
http://141.80.167.131:5557/nar/g7ka09613k5v1vlznh87yg35905ggw51-python2-scipy-1.2.2-guile-builder:
server is somewhat slow
guix
Hello,
> Disk: select hard drive
> Partitioning Scheme: Everything in one partition
Thanks for the bug report. I definitely looks like an installer
crash. Could you share the initial formatting of your disk (MSDOS or
GPT and existing partitions) ?
Mathieu
Hello Vagrant,
> But I'm building this on an aarch64 system; it shouldn't need to use an
> aarch64-linux-gnu cross-compiler on an aarch64-linux system! It would be
> nice if it could build images natively, too. :)
Yes indeed! It has been discussed here:
https://issues.guix.gnu.org/45020
Hello,
> I found this stops being an issue after reverting
> 66b14dccdd0d83c875ce3a8d50ceab8b6f0a3ce2.
> @Timothy do you know how we can get guile-json in there for SWH?
I think this is fixed with d2b5bb5f9de8dc1a51260e17cd91c3039070a7f2 to
fd5527407ff336c4af1c5511e19c0956720cd7aa. Could you
> Tested in a VM: it switches layouts like crazy, doesn’t leak a single
> FD, and generally behaves as expected.
Thanks for testing :) I pushed a variant of this patch both on master
and version-1.3.0 branches.
Mathieu
that input was always the main user keyboard I guess. The
attached patch fixes that issue by registering the FIFO on the first
input, but applying the keyboard layout to all the inputs.
Thanks,
Mathieu
>From 1a0fddd844ced62c802db0d6d133af45880435f0 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Hello,
> Regarding the MSDOS/UEFI patch, it is almost identical to what Florian
> tested. I chose not to force GPT on UEFI if the user disk is already
> MBR formatted, mostly to keep the code readable.
Pushed on master and cherry-picked on version-1.3.0 branch.
Thanks,
Mathieu
not to force GPT on UEFI if the user disk is already
MBR formatted, mostly to keep the code readable.
Thanks,
Mathieu
>From c75278d39e977488516507fb8a67c167facda926 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Date: Tue, 27 Apr 2021 17:39:42 +0200
Subject: [PATCH 1/3] installer: Force GPT disk la
Hey Ludo & Florian,
> The patch looks reasonable to me, thanks a lot!
Thanks for having a look! I'm working on an UEFI installation test as we
discussed. Almost there but for a strange reason, even if the
installation works smoothly, the created image isn't bootable in QEMU.
I'll keep
Hello Stefan,
> I’d like to ask you to apply my patch. It paves the way for using
> nfs-shares inside virtual machines, which is not possible today. This
> is certainly a good impovement.
OK, I'll first need to dive into this NFS subject that I'm not familiar
with. In the meantime, let's not
Mathieu
>From 65339286fe9d0c4758c04cfcaa177334577741cc Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Date: Sun, 25 Apr 2021 19:06:31 +0200
Subject: [PATCH] wip esp
---
gnu/installer/newt/partition.scm | 16 +++-
gnu/installer/parted.scm | 45 ++--
2 files changed, 28
Hello,
> I’m not entirely sure how it decides between GPT and DOS, though;
> Mathieu?
>
> We should add UEFI installation tests using OVMF.
I could reproduce this issue with the following steps:
--8<---cut here---start->8---
qemu-img create -f qcow2
Hello Stefan,
Thanks for having a look!
> I’m now sure that this test has never been working.
I also share the impression that this test never worked. Plus the actual
version has a lot of FIXME and commented lines that scare me off.
> With the attached changes, the NFS server side tests are
Hey,
> Okay, thanks! By the way, what is that '68a11045'? If it's a Git commit,
> I can't figure out where it is.
Yeah, but it disappeared when I removed the wip branch. I pushed it on
master: 2ccb715ab3ebef5ddbc53d706cbc42b3b765d613.
I tried to install a CI produced tarball
Hello,
Fixed with 868d8068a0b0ea985c6f8d28cb7a436c96bd4de5.
Thanks,
Mathieu
Hello,
> I installed "by hand" using this tarball, and it worked fine.
>
> Since this bug is really about a broken CI job, and not the release
> artifacts, I'm removing it from the list of release blockers.
There's indeed a discrepancy between the Makefile and the (gnu ci)
release job. I'm
Hello,
> I wonder if this regression comes from Ocrad itself or from the input
> Qemu screeshot.
I fixed it by removing the OCR delay altogether with:
822eacc6bb0878323e6687d4460a7c53066545e1.
Thanks,
Mathieu
Hello,
The "ldap" system test is failing this way:
--8<---cut here---start->8---
mathieu@meije ~/guix [env]$ cat
/gnu/store/5qq5ql92k9n57hx5l6ysk1rwnb0diwsv-ldap-test/ldap.log
Starting test ldap
Group begin: ldap
Test begin:
test-name: "LDAP server
Hello,
I'm working on fixing all the system tests before the release. The
"nfs-root-fs" test is failing this way:
--8<---cut here---start->8---
mathieu@meije ~/guix [env]$ cat
Hello,
> Also having the "newly failing jobs" list would allow to mail the people
> that have commited changes between the last evaluation.
>
> Of course this is easier said than done, it might imply to update our
> database structure among other things.
This has been implemented with a new
> ). Please consider running po4a-updatepo to refresh it.
> Your input po file ./guix-manual.de.po seems outdated (The amount of entries
> differ between files: 10012 is not 325
> ). Please consider running po4a-updatepo to refresh it.
> mmap(PROT_NONE) failed
> builder for
>
> This causes the build failure. However, we do not have this makeinfo
> error on the master guile-lib. That's because the docs are not compiled
> for a reason I don't understand.
Ok so I finally understand sorry for the spamming. Guile-lib contains
a pre-compiled docs/guile-library.info. This
> MAKEINFO guile-library.info
> /tmp/guix-build-guile-lib-0.2.7.drv-0/guile-lib-0.2.7/build-aux/missing: line
> 81: makeinfo: command not found
Looks like the devel manual generation is fixed. The guile-lib@0.2.7
build failure above only happens when generating the stable manual.
In that
Hello Leo,
> ERROR: In procedure %resolve-variable:
> Unbound variable: %strict-tokenizer?
This variable is provided by guile-lib@0.2.7 while this derivation uses
guile-lib@0.2.6.1 from guix-1.2.0-17.ec7fb66.
I have restarted mcron which now uses guix-1.2.0-18.6e7ba45 and
guile-lib@0.2.7.
Hey,
> Could it be that the bug was fixed in the meantime? Or that this one
> was, say, built directly via Guix whereas the other one was built
> through Cuirass? Mystery!
That's strange. There's nothing really special about how Cuirass builds
its stuff. It's a plain "build-derivations" call
Hey,
> Awesome, thank you!
As you confirmed on IRC that it fixed the situation, closing this one.
Thanks,
Mathieu
Hello David,
> Thanks. I forked ur test-channel and updated my specs accordingly and it only
> works the first evaluation, until I push a new commit to the config channel,
> then Im getting this:
Ludo experienced the same issue. I fixed it with
ac29d37e2ffd7a85adfcac9be4d5bce018289bec and
Also note that you can now use this specification:
--8<---cut here---start->8---
(list
(specification
(namee "my-pkgs")
(build '(channels my-guix-packages))
(channels
(list %default-guix-channel
(channel
(name 'my-guix-packages)
Hello Clément,
It is possible to search for the last build of a given job using the Web
interface search form.
For example,
http://ci.guix.gnu.org/search?query=spec%3Aguix-master+gajim
which corresponds to the search "spec:guix-master gajim", will show the
last build job for gajim on master.
201 - 300 of 670 matches
Mail list logo
