Hello,
Cuirass is now able to send build notification on different channels.
* By email on this new mailing list:
https://lists.gnu.org/mailman/listinfo/guix-ci.
* On Mastodon: https://fosstodon.org/web/accounts/316215.
* Using RSS: https://ci.guix.gnu.org/events/rss/.
Don't hesitate to
Hey Leo,
> I would have guessed that a single slot is appropriate for the machine,
> but I'm curious what you saw that led to the change?
This is most likely due to a worker crash. Workers are removed from the
database when there are no signs from them since 120 seconds.
I'll try to
Hello,
> I think the status quo of 64-bit ARM for us is untenable. The emulated
> builds cause mass failures that can't be reproduced on real hardware.
> There is a growing demand for this platform among hobbyists and hackers
> who we could convert to Guix contributors!
Following discussions
Hey,
> The network team asks me to test it now. Could you please give it a
> try?
I ran a few tests, it seems to work perfectly! It's really impressive
how Wireguard is easy to set up. I think it deserves a complete Guix
service :).
--8<---cut
Hello Chris,
> Near the beginning of 2020, things changed such that I suddenly had some
> time, and some of that time I spend putting idea's I'd had for a while
> around building derivations, including across multiple machines, in to
> practice [1].
With the Guix Build Coordinator, you made an
Hello,
> Yes, this should be okay. Does this mean that we can get rid of all the
> other ports that we previously requested?
Yes, the SSH tunnels and the associated open ports shouldn't be useful
anymore, as we'll be able to route all the build nodes traffic through
the VPN.
> If you’re sure
> Turns out "core-updates" is still configured to build the "core" subset,
> I don't really understand why the evaluation 74281 triggered the build
> of so many packages.
Just fixed it with 2c30440f89244202bddebe76f90c6b0b8145ba5d on
maintenance repository.
We will now be building 87 jobs
Hey Ludo,
> Agreed, I think that was the intent. Can we make it focus on the ‘core’
> subset? How does one do that nowadays? Looks like my sqlite3/Cuirass
> foo is no longer helpful. :-)
Turns out "core-updates" is still configured to build the "core" subset,
I don't really understand why
Hello,
The evaluation of the core-updates branch on Cuirass has been broken for
a long time. It now appears to be fixed[1]. This means that around 45k
packages must be built. Each change on this branch can possibly trigger
the same amount of builds.
Even if the core-updates builds have to the
Hello,
> What would it take to connect at least one OverDrive? How can the
> admins among us help?
I have reconfigured the overdrive1 so that it runs a Cuirass remote
worker. Now several ports on berlin and the overdrive1 need to be opened
for the remote building mechanism.
The easier way to
Hey Leo,
> So, minor improvements to aarch64, but x86_64 is actually worse!
> Mathieu, I'm curious, are we using the overdrives again? Or still
> emulating aarch64?
I have not connected the overdrives yet, so the aarch64 builds are still
100% emulated. Regarding x86_64, I guess it's because it
> That's slightly different than what I have been doing, but
> the resulting image has the same problem than mine, no
> LCD output, nothing answering on serial console (@1.5Mbps
> (uboot speed) or 115.2Kbps (kernel speed, I think)).
Strange, seems that Caliph did manage to get a serial console.
Hello,
> trying to DL (in browser or with wget) the build output, by using
> the "https://ci.guix.gnu.org/download/190783; link, I get:
> error "Could not find the request build product."
Oh, it's already been garbage collected on Berlin, sorry about that
:(. I'll see what I can do. In the
Hello Vincent,
You can download the latest Pinebook Pro image here:
https://ci.guix.gnu.org/build/190783/details
to search for the latest images:
https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+status%3Asuccess+pinebook-pro
Thanks,
Mathieu
Hello Vincent,
> I even attempted building the pinebook pro image without success.
It seems that Caliph Nomble succeeded to build a Pinebook Pro image and
booted it, without graphics, after a few fixes:
https://issues.guix.gnu.org/45584.
You may want to try again :).
>> There is almost no
Hey Ludo,
> You seem to imply that the issue is the number of architectures, rather
> than the small number of ARMv7 build machines (now that we disabled
> 32-bit builds on AArch64). Do I get it right?
Yes my point is that building three specifications on three
architectures, including an
Hello Jonathan,
> I can not speak for Nix, but openSUSE has around 10 more or less powerful ARM
> servers for native building. See https://build.opensuse.org/monitor
Thanks for sharing, I like very much the design of this page, I might
take some ideas from it to improve
Hello Tobias,
> I don't think it's obvious and I don't think it's true.
Well obvious was a poor choice of word. But I've been spending several
weeks/months monitoring Berlin and I think I'm starting to have a good
overview of the situation.
This new page[1] shows what the build machines are
> The armhf-linux platform is in the worst shape, both on the master and
> staging branches. It's a shame because it's also the least powerful,
> with almost no hardware thermally capable of sustained CPU usage, so
> users will have the worst experience building packages for it.
>
> Does anyone
Hello Leo,
> --
> master branch
> aarch64: 66%
> x86_64: 93%
> i686: 85%
> armhf: 51%
>
> staging branch
> aarch64: 44%
> x86_64: 80%
> i686: 60%
> armhf: 30%
> --
Thanks for the figures. I can comment on some stuff. Until recently it
was hard to monitor the build farm status
Hello Luis,
> About the integration of this logo with the Guix look, I thought that this
> logo was for Cuirass itself, not necessarily for the instance available in
> https://ci.guix.gnu.org/.
I thought it could be nice to use to logo for:
- The Cuirass project page that would be hosted at
Hello Luis,
> Variants A, B, and C only differ in the shape of the S characters.
>
> What do you think?
Woo, that was fast! All your proposals seem terrific to me but I have a
small preference for the design 2B with the blue background.
What do other people think :)?
Many thanks for your
Hello Pierre,
> - Why is it called "Cuirass"? :p
No idea, you would have to ask Mathieu Lirzin about it!
> - Why the move to PostgreSQL?
At first I thought that all the performance issues we had were caused by
unoptimized SQL queries. Turns out it was only half of the problem.
As we have
Hello,
I have started some heavy background work on Cuirass including its port
to PostgreSQL and a new remote building mechanism.
I think it would be nice to give the project a nice logo that could be
displayed on the web interface, and maybe on an hypothetical project
page.
A 'Cuirass' is a
Hello,
> However, it's sad that there's no option for user to specify substitute
> url in GUI installer of Guix ISO. It means that people new to Guix still
> have to tolerate the slow connection during the installation.
>
> Can we add such option for GUI installer?
Adding such an option
Hello,
This commit caused the following evaluation issue:
--8<---cut here---start->8---
Generating package cache for
'/gnu/store/dylz1h2sxgaqd6jhzq01b6y26797zjm5-profile'...
(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value
Hello zimoun,
> 1. Loop with commit-parents as it is done for ’commit-closure’ in
> guix/git.scm.
>
> 2. Bind git_revwalk_* and use it instead.
>
> WDYT?
>
> Well, #1 is more straightforward but less efficient, IIUC.
Running something like:
--8<---cut
Hello Chris,
> I believe SQLite checkpoints the WAL file after transactions commit, if
> the WAL is over 1000 pages in size. At least for the Guix Build
> Coordinator though, that didn't seem to be working/happening as the WAL
> file seemed to just grow and grow.
I have noticed that the WAL
Hey,
> So perhaps we should adjust the docstring to reflect that?
Sure, done with: d9e57db72479812cfa30ed8e30a6351959f9a2b2.
> Yeah, ‘guix offload’ should not connect to the daemon. It does so
> currently for one thing (registering GC roots IIRC), which should be
> done in Scheme instead.
Hey,
> Looking at LocalStore::ensurePath, I don’t think a GC root is made.
> You have to call ‘add-temp-root’ if you want that to happen, no?
Yes, I think we do indeed.
> However ‘ensure-path’ can substitute the store item, which I suppose
> means you can substitute .drv files without
Hey,
> One this patch is in, I think we’re ready for either an RC2 or the real
> thing.
Pushed to 1.2.0 and master. Thanks Florian for all the testing!
No objections to make the rc2 the final one.
Thanks,
Mathieu
Hey Ludo,
> Should we go ahead and apply this one? Not polling would be nicer, but
> maybe there’s no real way to do that?
I proposed a variant of this patch a few minutes ago. I added some time
logging and I would like to see what's the result on Florian machine to
see if the new delay is
Hello Miguel,
> I didn't update my mail so often and you've already solved it... Sorry
> for the noise and thank you for the patch. :-)
Thanks for having a look to this :). I sent an updated patch because the
first one could cause a regression in "non-install-devices" procedure I
think.
know if
4 seconds is enough or if we should use an even higher delay.
Thanks again,
Mathieu
>From f3d41cff6704ad748d51e4dd548c045034656b66 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Date: Tue, 17 Nov 2020 09:50:01 +0100
Subject: [PATCH] installer: Fix device synchronization.
Reported b
disk. The
"with-delay-device-in-use?" tries 4 times every 250ms to detect if the
device is still in use.
Maybe it takes longer on your HW to synchronize the partition tables. If
you could test the attached patch on top of 1.2.0 it would be terrific.
Thanks,
Mathieu
>From 6fec27303d0f87
Hello Miguel,
> + ;; TRANSLATORS: The ~{ and ~} format specifiers are used to iterate the
> list
> + ;; of device names of the user partitions that will be formatted.
> + (run-confirmation-page (format #f (G_ "We are about to write the
> configured \
> +partition table to the disk and
Hey Ludo,
> For that we need a Guile-Git release, which could be made anytime now.
> Mathieu, do you want to take care of it? If not, I can do it.
Done with fbac2572f6ab6bf709302b0a270e1e66a942ba07.
Thanks,
Mathieu
Hey janneke,
> It works for me; I found Emacs EXWM missing however. After zenny also
> asked about that this morning, I decided to create a patch.
Thanks for testing and for the patch! I think it might be necessary to
add "emacs-exwm" to "installation-target-os-for-gui-tests" in (gnu tests
Hey Ludo,
> So that’s 3 more 1 GiB installer images, right? If we target Oct. 29th,
> how are we going to test them in the meantime? How long will it take to
> build them, even assuming we build on an OverDrive?
I plan to provide compressed disk images for those boards so it's more
around
Hello,
The 1.2 release is on its way. So here's the traditional call for
installer testing. This time, the CI is building latest installer
images, which should ease testing.
I propose that we first concentrate our efforts on this image:
https://ci.guix.gnu.org/download/654 which corresponds to
Hello Danny,
> Please, can we have the build servers send build failures to guix-devel
> instead of hoping that people check manually? I have other things to do
> in my life than to poll random servers every few hours.
That feature is definitely on my list. Fixing Cuirass and improving the
> I'm actually not really sure how one would use the installer on one of
> the boards. I think the bare-bones disk-images would be best; just
> download it and flash it onto the board or an SD card and edit
> /etc/config.scm to add your user and services. Or to boot up into the
> installer and
Hello Efraim,
> What's the plan for an installer for the armhf/aarch64 boards? Do we
> want to produce installer images for them or just ensure they work? I
> ran into some issues when I was trying to create an installer for the
> beaglebone black.
I think that creating installer for those
Hey zimoun,
> What is the status of the installer?
I don't think there are known issues at the moment. I have started
testing it on my laptop, by booting on a flash drive and installing on
another one, while being quite anxious for my main hard drive :p.
Maybe it would be nice to start a 1.2
Hello zimoun,
> The idea behind is then to ask SWH folks to increase the rate limit
> for a specific IP (or couple of IPs). Today, the SWH rate is 10 save
> requests per hour, i.e., 240 per day (more or less). And the new
> chart [1] shows that there are ~2000 builds per day. Ouch! :-)
Hello Danny,
Any chance you could have a look to
https://notabug.org/guile-sqlite3/guile-sqlite3/pulls/16.
I'd like to use it log all Cuirass SQL queries.
Thanks,
Mathieu
--
https://othacehe.org
Hello Maxim,
> The reason I've kept those in is that they are used to dial the speed
> field of the emulated build machines down, to prefer native hardware.
> I'm not sure if this is still useful / worth the additional complexity?
Oh, I missed that detail. Then I guess you can feel free to
Hello Maxim,
> (fast/hurd (filter (compose childhurd-ip? build-machine-name) fast)))
>(append overdrive (map aarch64->armhf overdrive)
> armv7
> - x86_64 (map x86_64->i686 x86_64)
> + x86_64
> (map x86_64->qemu-aarch64 fast)
> (map
Hello,
>> * gnu/packages/aux-files/linux-libre/5.8-arm.conf: Enable GZ compression.
>> * gnu/packages/aux-files/linux-libre/5.8-arm64.conf: Ditto.
>> * gnu/packages/aux-files/linux-libre/5.8-i686.conf: Ditto.
>> * gnu/packages/aux-files/linux-libre/5.8-x86_64.conf: Ditto.
>
>
Hey,
> Yeah, this is a ridiculous situation. We should do a hackathon to get
> better monitoring of useful metrics (machine load,
> time-of-push-to-time-to-build-completion, etc.), to clearly identify the
> bottlenecks (crashes? inefficient protocol? scheduling issues? Cuirass
> or offload or
Hello Pierre,
Thanks for sharing your progress. A few remarks below.
> 3. Size of the database:
>I've persisted all locally-present store items for my current Guix version
>and it produced a database of 72 MiB. It compresses down to 8 MiB in zstd.
>
>But since we can have multiple
Hello Jonathan,
Thanks a lot for this nice report. Let me summarize a bit the situation
first, before commenting on your findings.
On our main "berlin" build farm, we have currently a few aarch64
machines:
* overdrive.guixsd.org
* dover.guix.info
* dmitri.tobias.gr
* sergei.tobias.gr
We are
Hey Ludo,
> I think we’ve pretty much reached all these milestones. So we need to
> do some testing again of the installer, but at least we no longer have
> the excuse of adding one last feature. So I guess we could seriously
> work on it. Thoughts?
That's true, really nice we could achieve
Hey Ludo!
> I missed something. Can’t we have a static page that refers to
> ci.guix.gnu.org/…/latest, and Cuirass returns a redirect from /latest to
> the actual URL?
Yes in fact I missed something first :). I did add build products
support to cuirass JSON API and its Guix "latest-builds"
Hello,
>> I wonder about how this composes; if I'd want to add say a guix-daemon
>> service to the bare-hurd, how would I do that?
>
> How about leaving the ‘operating-system’ field of to #f or some
> default value, and then filling it in with the argument passed to ‘guix
> system’?
>
> Or
Hey Ludo!
> That looks nice to me! I think it should prominently say that these are
> “development snapshots” (probably these two words must appear) though,
> and perhaps contain a link to /download for those looking for releases.
>
> Other than that, I’d say go for it!
I took your remark
cup of tea).
Anyway, the patch and a screenshot are attached, please tell me what you
think.
Thanks,
Mathieu
>From 1ef4c571934118deaae93f7f6eccc23ed8c32f9a Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Date: Mon, 15 Jun 2020 17:13:25 +0200
Subject: [PATCH] wip: website: Add "latest" d
> I feel a bit stuck here, I cannot find an alternative to overlayfs and
> on the other hand umounting the overlay is problematic.
>
> Do people have some ideas here?
Ok, this should be fixed with: 876a8d987085b8c64f32c8a320e4219575af285c.
Thanks,
Mathieu
Hey!
> Very nice! It would be good to have “(ISO-9660)” or similar next to the
> file name.
Thank you :) Fixed with c2aed4a5c1cbed44a9cdf9aab660c4a196a7837d.
> Yes, we could add support for /latest links.
Ok, I'll see what I can do about that.
Thanks,
Mathieu
Hello,
With the last Cuirass revision, it is now possible to download directly
from the Web interface some build outputs.
For now, only ISO9660 images can be downloaded, but this could be
extended to other build products in the future.
You can visit:
Hello Pierre,
> Any idea how and why?
Yes, you can use "guix graph" this way:
--8<---cut here---start->8---
mathieu@elbruz ~/guix-master [env]$ guix graph -t references
/gnu/store/9pnnigbg2a173xxabfrb50mayw4la2ag-system --path
Hey Ludo!
> What if, instead, we removed those “canonical” packages entirely from
> the reference graph? Do you think that’s an option?
It seems to be a better option! So, as I did remove most of the explicit
references to 'canonical-packages' the only references left are
implicit.
A good
Hey Jan,
> Just a quick question: why?; would that reduce a system's closure size?
Yes mostly, even if the gains are not huge (~100MiB). However, I feel
like its easier the tackle the system closure size issue if we get rid
of the "noise".
Thanks,
Mathieu
Hello,
With f30d84d32db0f4f6cb84e139868e1727a7dc0a51 and
dfc8ccbf5da96a67eb1cade499f0def21e7fdb02, I did remove most of the
"canonical-package" calls because they were breaking system
cross-compilation.
Now, I'd like to somehow restore them, using the new "let-system". My
idea is to define
Hey Ludo,
> $ guix size $(readlink -f /run/current-system) | head -5
> store item totalself
> /gnu/store/4d0p06xgaw8lqa9db0d6728kkba8bizj-qemu-5.0.01651.6
> 745.2 18.8%
>
Hey,
> I can reproduce this issue on a VM, I'm currently investigating it.
Ok, found it, it's the cow-store umount bitting again. As a reminder,
once the installation is over, we need to umount the cow-store overlay
in order to be able to umount to underlying media which Guix is
installed
Hey Ricardo,
> It worked but at the end of the installation when it prompted me to hit
> Return it did not tell me that the installation was successful and that
> I could reboot. Instead it brought me right back to the language
> selection of the installer.
I can reproduce this issue on a VM,
Hey,
>> That's pretty nice!
>
> +1!
Thanks to both of you for your quick feedback!
>> I wonder about how this composes; if I'd want to add say a guix-daemon
>> service to the bare-hurd, how would I do that?
>
> How about leaving the ‘operating-system’ field of to #f or some
> default value,
tend it to other boards that we've been hacking on
(beaglebone-black, pinebook-pro ...).
Please tell me what do you think!
Thanks,
Mathieu
>From 0eefcc0bef8fb950611ec5801a9f4d2e256b6b59 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Date: Mon, 25 May 2020 17:18:23 +0200
Subject: [PATCH] wip: s
Hello Marius,
> What do y'all think about targeting a 1.1.1 release a few weeks from
> now?
>
> Any milestones we should try to complete before an eventual release?
This seems like a very good idea. It would be good if this release could
include:
* A new shepherd release fixing this bug[1].
Hello Florian,
> I suppose keyboard input method (IME) support is a reason why someone
> might wish to use an Xorg-based installer. Are there other reasons?
> What are the reasons for a real desktop environment; is the goal to
> offer a live image? Previously I would have thought a virtual
Hello Tobias and Jonathan,
> Are you, for example, able to connect to a Wi-Fi network the Gnome way (not
> using the installer), without a Gnome authentication dialogue popping up that
> doesn't understand the notion of ‘no password’? I had to open a terminal and
> ‘passwd’ myself out of that
backend, could be not so hard.
I don't think I'll have the bandwidth to do this anytime soon, but is
someone is interested, I'm willing to help/review :).
Thanks,
Mathieu
>From 3ec7528c0a7bcc318e380f41f7cbd91df9927b8a Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Date: Mon, 11 May 2020 15:25
Hello!
> (define* (hurd-grub-configuration-file config entries
>#:key
>(system (%current-target-system))
>(old-entries '()))
> (let ((hurd (if (equal? system
Hey Tobias,
> guix-comm...@gnu.org 写道：
>> + ;; XXX: Temporarily disable compression to speed-up the tests.
>> + (compression? #f)))
>
> Interesting! What kind of improvement do you see, roughly?
I posted some figures here:
> Wow! Why did it take 2h30? Do you have KVM?
Yes, I'm not sure why it's so long. It seems that
"estimated-partition-size" takes a large proportion of this time,
because if I run the same command with a fixed disk-image size it goes
faster.
Mathieu
> * Add support for ISO images.
For ISO images, by running make-iso9660-image directly on the host (see
wip-disk-image branch), I have a considerable time decrease.
This command:
--8<---cut here---start->8---
guix system disk-image
Hello Vagrant,
I reverted the U-Boot update to 2020.04 because it breaks the build of
u-boot-tools package. Could you please have a look?
Thanks,
Mathieu
Hello,
I made some progress on the image generation topic. As discussed
previously, the goal is to use the same principles as genimage[1], to
achieve faster image generation, without resorting to VM.
A very related topic, is to bring the possibility to create Guix System
images with custom
Hey Ludo,
> Sorry, I missed this message yesterday so I was stuck on the one where
> you said Guile-Parted 0.0.3 and > 1 TiB disks can wait. My apologies!
>
> (It’s really hard for me to track all these issues and remain in sync!)
>
> I guess 1.1.1 will fix these problems and others.
Well I
Hello Maxim,
> Apologies if I'm confusing things, but is this bug (about partition size
> greater than 1 TiB the same as what I reported here:
> https://gitlab.com/mothacehe/guile-parted/-/issues/1) ?
I completely missed your report sorry about that. I need to activate
Gitlab notifications I
Hey,
> This bug is not about rc2, is it? WDYT Mathieu?
No, I think its a Guile-Parted bug, I forget about, that causes
installer failures when the partition size is > 1 TiB. It has presumably
always been around.
I did a Guile-Parted 0.0.3 release and updated the package definition on
master.
> * Esperanto language/layout crashes the installer.
Fixed by 1a24df44347629cd67821d672edad7636404f293 on master.
Ludo, you may want to cherry-pick it to 1.1.0 branch :)
Mathieu
> As the system language & locale rather than
> - Esperanto
I can reproduce it in QEMU. So there are two issues here:
* Esperanto language/layout crashes the installer.
* When the installer crashes, `umount-cow-store' is not called and the next
installation is bound to fail because some
Hello Florian,
> For me the Guix System installer crashes reproducibly after manual
> partitioning, even when not formatting the partition. The ESP and
> root partition have not been deleted (no matter if I tell the
> installer to format them or not). This applies to EFI installation on
> my
Hello Alex,
Thanks for your feedback!
> Then the screen flashes back to the beginning of the installer. Running
> through the process again results in the disk drive not being available
> for partitioning.
Are you running the installer on a VM or on real hardware? Could you try
the following
Hello,
> BTW, if we agree, could you change these strings so we can do a last
> round through the TP and release Thursday/Friday?
Yes, I applied those changes and added proxy support. I'll try to see
how connman is behaving now.
Thanks,
Mathieu
Another issue could be that, to make sure that we are connected to the
internet, we check connman status (see connman-state in (gnu installer
connman)) during the install.
If there's a network HTTP proxy, I guess this may fail. So we would need
to also call "connmanctl proxy auto PROXY_URL" or
Hey,
> I went ahead and pushed it as 3302e03ba0edca49347c6a2b215e56bd53a6b113.
> Another 2017 bug closed! \o/
Well done!
>
> Ideally, the installer would have a dialog box to select a proxy.
> Do we want to do that? Or leave it for the next release?
Yes I could do that. I wonder what's the
Hello Vicent,
>
> What is the UI to run that guix-daemon --set-proxy ?
> Use herd set-proxy guix-daemon "https://proxy:3128; ?
> (Like what is done for mcron)
>
> I really need a few "make this thing here do that" hints...
>
> And then also a bit of a hint on how I would test the
>
Hey,
> Did you not get my reply[0] yesterday? Please let me know if it didn't get
> delivered.
Nope, didn't get it. Too bad because you did a more complete review :)
Mathieu
> +(native-inputs
> + `(("bison" ,bison)
> +("flex" ,flex)))
> (inputs
>`(("ncurses" ,ncurses)
> -("bison" ,bison)
> -("flex" ,flex)
> ("less" ,less)))
> (build-system gnu-build-system)
> (arguments
This one LGTM but it doesn't
> + `(
> ("m4" ,m4)
You can join those two lines.
Thanks,
Mathieu
> +(native-inputs
> + `(("intltool" ,intltool)
> + ("pkg-config" ,pkg-config)))
> (inputs
> `(("libxslt" ,libxslt)
> ("libxml2" ,libxml2)
> @@ -502,9 +506,7 @@ photographic equipment.")
> ("ilmbase" ,ilmbase)
> ("libsoup" ,libsoup)
>
Hello Vincent,
> + ("groff" ,groff)
> + ("python-docutils" ,python-docutils)
> ("xz" ,xz)))
python-docutils provides rst2html.py that seem to be used at run-time
(see patch-absolute-file-names phase).
So I think it should be an input not a native-input.
Thanks,
Mathieu
> I only build-tested them natively on/for x86_64 (and
> cross built for aarch64 for the sudo one)
This LGTM, I added your copyright on the two first patches and pushed!
Thanks,
Mathieu
Hey,
> I'm not seeing any size difference, but groff is not in the output:
OK, then its normal.
> That fails on master (libpaper) whereas with the patch it works,
> so I guess the patch is useful on that front.
>
> The patch for sudo will be in the following emails.
>
> Is there anything else
Hello Vincent,
> Is there a way to see any benefit from these changes
> (without building a vm or container image each time) ?
>
> Are those changes useful to do on their own ?
Well yes it may reduce the closure size of the package (run `guix size
sudo`) to get it.
It can also fix
Hey!
> I’m completely sold to the idea. :-)
I'm glad you like it!
> Looking at ‘image-ext2.c’ reveals that genimage actually just shells out
> to mke2fs. Indeed, I discovered that ‘mke2fs -d /my/root’ copies
> /my/root as the image’s root directory. Likewise, for ISO, it just
> shells out
Hello Vincent,
> FYI, I'm investigating the test suite failures for the newer
> releases of genimage (v11 (+1 FAIL) & v12 (+2 FAIL))...
>
> I think I'll report / PR them upstream before updating
> guix's version, to avoid unnecessary churn.
Ok good, let us know how it goes :) I should have
101 - 200 of 413 matches
Mail list logo
