Re: Teams

Hello Ricardo, I would suggest to extend a bit the scope of this idea. What about creating an etc/tutors.scm file as the one attached. This way people would run something like: --8<---cut here---start->8--- git send-email $(get-tutors.scm HEAD^^) *.patches --

Re: branch master updated: gnu: python-lxml: Update to 4.6.5.

Hey > * gnu/packages/xml.scm (python-lxml): Update to 4.6.5. I had to revert it as it caused >15k rebuilds. I also cancelled all the triggered builds in the CI. Thanks, Mathieu

Re: 'staging' freeze

Hey Marius, > The 'staging' branch is in a pretty good shape, let's get it merged! Nice work! > I'm fairly rusty when it comes to Cuirass, and don't see a button to > start the jobset here even when authenticated: > > https://ci.guix.gnu.org/jobset/staging > > Can someone remind me how to en

Re: branch master updated: gnu: gitolite: Wrap programs instead of using propagated inputs.

Hello David, I noticed that the gitolite test is now failing. Any chance it is related to the recent work on the package? https://ci.guix.gnu.org/build/1333185/details Thanks Mathieu

Re: 02/02: gnu: shepherd: Update to 0.9.2.

Hey Ludo, The installation system tests have fail this night and I suspect this is related with the shepherd update. The problem seems to occur when we restart the guix-daemon service before running the installation command, in the install-system procedure. Any idea what could cause it? The cgi

Re: 04/07: guix: Add compression module.

Hey Ludo, > While I agree this should be factorize, I wonder if this should be > promoted to (guix compression). The module name intuitively is a better > fit for the compression-related things currently in (guix utils). > > Not sure, maybe (gnu compression) would make more sense? Thanks for n

Re: 02/04: services: Add samba service.

Hello, Thanks for this new service :) I noticed that while the "samba" test works fine on my machine, it fails on the CI: https://ci.guix.gnu.org/build/1495525/log/raw any idea why? Mathieu

Pick your team!

Hello, We recently introduced a teams.scm[1] file defining different teams such as "Julia team", "Lisp team" or "Mentors". If you are a newcomer seeking for some guidance to contribute to a Lisp package, you can run the following command: --8<---cut here---start

Re: branch master updated: services: Add file system utilities to profile.

Hey, > So it would seem like e2fsprogs is not being added to the profile of the > installation image. I think that's because there is no ext4 file-system needed for boot, as root is an iso9660 file-system. I added e2fsprogs to the operating-system packages for this specific test with: 0f66ef9aa

Maintainers meeting notes.

Hello, For the last six months or so, the maintainers have been conducting monthly meetings on Jami. They are scheduled every first Tuesday of the month. It is often the occasion to plan some actions and discuss the administration of the build farm. The meeting notes are available here: https:

Re: Release progress, week 2

Hey, Thanks for the update! > - armhf-linux is disabled on ci.guix due to improper offloading >setup (probably along the lines of >). Should we try and reenable >it, or should we drop it? > > - powerpc64le-linux is disabled o

Re: Status of armhf-linux and powerpc64le-linux

Hey, > How frequently does that machine become unreachable? > > Its uptime right now is “only” 51 days, but it seems to have been > reliably building things so far (surprisingly so!). Oh so it must be available from the Cuirass point of view but not from the guix offload point of view. I'll try

Installer for 1.4.0

Hello, The installer has been hardened during the past months when it comes to error reporting: - Guile exceptions are caught, displayed and possibly uploaded to dump.guix.gnu.org if the user agrees to do so. - Failing system commands can be run again. I think that it would be nice to go a

Re: Release progress, week 5

Hey, >Probably we’ll postpone that post-release and drop i586-gnu from >‘etc/release-manifest.scm’ in the meantime. Objections? No. > - armhf-linux: No progress; can we arrange so that ci.guix at least >builds these core subset of packages? We already have the 'c

Re: i586-gnu builds on ci.guix

Hello, > Alas Cuirass depends on Fibers, which is currently Linux-only¹, so we > cannot {cross-,}build it for GNU/Hurd. The good news is that > ‘remote-worker.scm’ itself doesn’t seem to use Fibers. So I wonder if > we could arrange to build a stripped-down package that contains nothing > but

Re: Release progress, week 6

Hello, >It would seem that a lot of aarch64 builds are queued but not >getting processed. Any idea how to investigate that, Mathieu? That would be because we only had a single ARM machine available till this week (kreuzberg). It seems that overdrive1 and grunewald are back thou

Re: Release progress, week 8

Hey, Thanks for your hard work to publish the RC1! > Now we need reports from users to act upon. I’d say we can decide next > week whether we need an RC2 or not. I can handle the next release > candidate or the release itself, but I’ll be unavailable on Dec. 12–15. I noticed that we have fai

Re: Release progress, week 8

Hey Ludo, > fe563a87ad gnu: texinfo, info-reader: Do not run tests when cross-compiling. Wow, that's a lot of fixes! > Yesterday on IRC we discussed an installer crash received at > dump.guix.gnu.org. Did you or will you have time to look into it? Yes and I think that for some reason we ar

Re: Has ci.guix.gnu.org stopped building?

Hello Leo, > According to the web interface, ci.guix.gnu.org stopped building things > on December 31, with evaluation 79343. > > Is this true? What's wrong? Yes the master specification has not been evaluated since December 30. It looks like all subsequent evaluations are never finishing which

Re: Has ci.guix.gnu.org stopped building?

> This was fixed with commit 658c09333da095edf6e1b3c5e351a7bfa3c87354 Builds have restarted! Good catch, thanks! Mathieu

Re: 04/08: gnu: QEMU: Unbundle iPXE.

Hello Marius, > glib > gtk+ > + ipxe-qemu > libaio > libcacard;smartcard support > attr libcap-ng ;VirtFS support I just noticed that: --8<---cut here---start

Re: 01/09: services: base: Add extra-env support to guix-configuration.

Hey, > Nitpick: To stick to existing naming conventions, could we rename it to > ‘environment-variables’ or ‘environment’? I changed to environment and pushed. Thanks, Mathieu

Cross compilation status

Hello, In order for Guix to become an alternative to tools such as Yocto and Buildroot, having most or all our packages cross-compiling is a prerequisite. Here is a status of cross-compilation in Guix. For cross-compilation to work, the build-system needs to support cross-compilation. The follo

Re: Implementing the guix-dameon in Guile

Hey Chris, Congrats on getting the grant! I'm sure it will lead to a lot of positive things. I tried it myself a couple years ago, for the exact same subject, without success. > I imagine the daemon could be structured as a set of actors (it’s really > my thing these days ;-)), with an eye on

Re: Cross-compilation broken on canonical packages.

Hey Ludo, > Do we need to do it for ‘lower-object’? I think that one is (almost) > always called from a gexp compiler where it’s explicitly passed ‘system’ > and ‘target’. Yes because of lower-object call in "system-derivation" procedure of (gnu services). > Also, a test or two would be welco

Re: 02/02: gexp: Default to current target.

Hey, > Could you push to ‘master’ as well? > > In general, to minimize the risks of merge conflicts, I’m all for > pushing things on ‘master’ only (unless they entail full rebuilds of > course.) Eventually, they get merged to ‘core-updates’, ‘staging’, etc. Yes makes sense! Pushed to master!

Re: branch core-updates updated: gnu: guix: Fix cross-compilation.

Hey, > I suppose we need to adjust ‘guile3.0-guix’ as well, and perhaps > ‘guix-daemon’ too? Yes, you were right about guile3.0-guix, fixed on core-updates! "guix-daemon" seems to work fine. Thanks, Mathieu

Guix System for embedded systems roadmap.

Hello, At Fosdem 2020, I gave a talk about using GNU Guix as an alternative to Yocto, focusing on cross-compiling a Guix System. Here's a status and my personal roadmap on this topic. * On core-updates, since commit d594963856690f1aacf228c8a83e406d33bc44ce, cross-compiling a bare-bones Guix

Re: Plan for a release!

Hey! >>> • More testing of the guided installer and related issues: >>> >>> https://issues.guix.gnu.org/issue/39729 >>> https://issues.guix.gnu.org/issue/39712 > > Done, but it’d be nice to add more test of the installer! I can help on that. Maybe adding: * More partitioning patter

Re: Plan for a release!

ith installation failures. Thanks, Mathieu >From 11193c030fa64cc3e2f6505062b7aa4fa9b2a2f4 Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Fri, 20 Mar 2020 11:36:33 +0100 Subject: [PATCH] tests: install: Abort when one installation step fails. When marionette-eval calls fail in gui-test-program, the installation continues w

Re: Plan for a release!

Hello Gábor, > I believe what could be done is to create and extended installer image with > the packages need for testing available. > It could work similarly to how the barebones closure is included right now. > These images would be quite big, and impractical for anything but testing. > I bel

Re: Help wanted: Nightly builds for Guix

Hello Carl, > I would like to help make nightly builds available for Guix. This was > something > that was discussed briefly at Guix Days, and the reception was positive. Do you mean nightly builds of Guix itself? If yes, I guess one good starting point would be what we already build in our CI

Re: Plan for a release!

Hello, > Yes: you need to have ‘installation-os-for-gui-tests’ (or preferably a > variant thereof) include all the services/packages needed for the target > config. > > In the manual installation tests we use ‘define-os-with-source’ to both > embed the target OS and its references in the install

Use genimage for disk-image creation.

Hello, I recently spent some time generating a lot of Guix System disk-images (embedded system images, installation tests). The mechanism Guix and Nix are using: spawning a VM to create the disk-image does not scale at all when the disk-image size increase. So, I looked at what the competition

Re: Use genimage for disk-image creation.

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 ment

Re: Use genimage for disk-image creation.

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 t

Re: native or not

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 cross-compil

Re: native or not

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

Re: native or not

> 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

Re: [PATCH 1/6] gnu: cgit: Make some inputs native.

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

Re: [PATCH 2/6] gnu: darktable: Make some inputs native.

> +(native-inputs > + `(("intltool" ,intltool) > + ("pkg-config" ,pkg-config))) > (inputs > `(("libxslt" ,libxslt) > ("libxml2" ,libxml2) > @@ -502,9 +506,7 @@ photographic equipment.") > ("ilmbase" ,ilmbase) > ("libsoup" ,libsoup) > ("pyth

Re: [PATCH 5/6] gnu: mailutils: Make some inputs native.

> + `( > ("m4" ,m4) You can join those two lines. Thanks, Mathieu

Re: [PATCH 6/6] gnu: nethack: Make some inputs native.

> +(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 app

Re: [PATCH 1/6] gnu: cgit: Make some inputs native.

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

Re: Proxy settings wrt guix daemon

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 > modification

Re: Proxy settings wrt guix daemon

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

Re: Proxy settings wrt guix daemon

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 s

Re: Proxy settings wrt guix daemon

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

Re: 1.1.0rc1 available for test!

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

Re: 1.1.0rc1 available for test!

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 2

Re: 1.1.0rc1 available for test!

> 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 mount

Re: 1.1.0rc1 available for test!

> * 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

Re: 1.1.0rc2 available for testing!

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.

Re: 1.1.0rc2 available for testing!

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 gu

Re: 1.1.0rc2 available for testing!

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 di

Image generation

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 layo

U-boot update revert.

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

Re: Image generation

> * 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 --file-system-type=iso9660

Re: Image generation

> 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

Re: 02/02: image: Disable compression for ISO images.

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: https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00374.html

Re: guix system vm-image --target=i586-pc-gnu Hurd'le

Hello! > (define* (hurd-grub-configuration-file config entries >#:key >(system (%current-target-system)) >(old-entries '())) > (let ((hurd (if (equal? system (%current-system

Towards a graphical installer?

graphical 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 Dat

Re: Towards a graphical installer?

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 t

Re: Towards a graphical installer?

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 con

Re: Release Guix 1.1.1?

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]. *

Providing a Guix System images catalog.

ld extend 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: [PAT

Re: Providing a Guix System images catalog.

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, a

Re: installer no longer signals success or offer reboot

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,

Re: installer no longer signals success or offer reboot

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 upon.

Re: The size of ‘.go’ files

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% > /gnu/store/abiva5ivq99x30r2s9pa3jj0pv9g16sv-guix-1.

Canonical-packages restoration.

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 some

Re: Canonical-packages restoration.

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

Re: Canonical-packages restoration.

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 exam

Re: Why does slim-service-type depend on GTK+?

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 /gnu/store/hh2z7mqlj54cs23a94

Cuirass image download

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: https://ci.guix.gnu.org/search?query=spec%3

Re: Cuirass image download

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

Re: installer no longer signals success or offer reboot

> 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

Latest download from website

;s not my 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 "

Re: Latest download from website

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 into

Re: Providing a Guix System images catalog.

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 bett

Re: Latest download from website

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" wra

Re: Release Guix 1.1.1?

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

Re: ARM build machines

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 a

Re: File search progress: database review and question on triggers

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

Re: Improving CI throughput

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 g

Re: 02/02: linux-libre: Enable module compression.

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. > > Sho

Re: [PATCH] hydra: Use the new 'systems' field for build-machine definitions.

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 x86_64->qemu-arm

Re: [PATCH] hydra: Use the new 'systems' field for build-machine definitions.

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 proc

guile-sqlite3 trace support

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

Re: Cuirass: "lint -c archival"?

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! :-) Yeste

Re: Release v1.2 timetable

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 b

Re: Release v1.2 timetable

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 boar

Re: Release v1.2 timetable

> 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 ov

Re: Continuous integration - automatic EMAIL

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 bui

Call for 1.2 installer testing.

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

Re: Shipping more installer images?

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 400

Re: [PATCH] installer: Add Emacs EXWM desktop environment. [WAS Re: Call for 1.2 installer testing.]

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 in

Re: Release v1.2 timetable

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

Re: bug#43879: Problem with graphical installer

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 forma

Re: GNU Guix 1.2.0rc1 available for testing!

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

  1   2   3   4   5   >