bug#41709: installed-os test failing

> Now multiple options: > > * Revert this commit. > * Find other system closure improvements. > * Up the limit to 1.5GiB. > > WDYT? Digging a bit more, I discovered multiple culprits in the image closure size. * "openssh" is dragging "xauth" which drags some X libraries (but this does not accou

bug#41709: installed-os test failing

Hello The installed-os test is failing because the image closure is (again) bigger than the allocated 1.4GiB in the test partition. --8<---cut here---start->8--- guix size $(./pre-inst-env guix system build gnu/system/examples/bare-bones.tmpl) --8<--

bug#41693: freshly installed system cannot run “guix pull”

Hello Ricardo, > I just installed two servers with the installer image built from commit > 2f49007dd076b14feb40d7c3331dee3e737265c8. Both of these servers boot > just fine, but “guix pull” does not work. > > It fails with the following error: > > guix pull: error: glibc-bootstrap-system-2.2.5

bug#41541: merge wip-hurd-vm

Hey! > Legend (in order of merge'ability / is there a convention for this?): > > [M] Mathieu > [L] Ludo >g good to go LGTM'd >t trivial (self-LGTM :-) >. direct dependency of/partially superseded by a LGTM > > ack or review needed >! troublesome Hehe, nice one :)

bug#41541: merge wip-hurd-vm

> Now, how could we have runsystem run another RC? Hmm, runsystem is > being called with --load and --system arguments too; we could even > give it an --rc=RC-FILE if that's more convenient. > > Then, we would only need to add this RC-FILE to the system, maybe add a > %hurd-"something" service?

bug#41541: merge wip-hurd-vm

Hello Jan, > I have managed to completely boot-activation. Still using the same > patch for hurd-directives, but I've got a feeling we're getting real > close now. Just discovered your (gnu build hurd-boot), that's awesome! I wonder if we could go one step further and move the "rc" script outs

bug#41541: merge wip-hurd-vm

e "make-device-node", I would propose to "link" it to the image definition, as proposed in the attached patch. I'll see if we can do something similar for the "extra-directives" and the "boot-activation". Thanks, Mathieu >From 371f2bab466cef53f66ac

bug#41481: Can't build glibc-mesboot0

Hello Roel, > I installed Guix System on my computer but I am facing two problems: > > 1. "guix pull" returns: > Updating channel 'guix' from Git repository at ' > https://git.savannah.gnu.org/git/guix.git'... > Building from these channels: > guix https://git.savannah.gnu.org/git/guix.gi

bug#41429: Shepherd Sometimes Crashes

Hello Katherine, > I'm running `strace` against the Shepherd process in an attempt to > submit a better bug report, but this is all I have for now. Maybe others > have also seen this behavior. Yes, I have observed this behavior. This should be fixed with the upcoming 0.8.1 release of Shepherd (

bug#41264: Bootstrap packages fail to build.

Hello, > So stat, lstat, and all other related function will return -EOVERFLOW > unless their 64 bits stat64, lstat64 counterpart is used. > > So I think this means that one cannot build the Guix bootstrap toolchain on an > NVME disk. After further investigations I think that it is needed to pa

bug#41120: uvesafb service is unsupported on aarch64

Hey Ludo, > Anyway, it took me much more time than I thought, but it’s here now: > > 502f609d05 vm: Use 'let-system'. > 300a54bb98 utils: 'target-arm32?' & co. take an optional parameter. > 644cb40cd8 gexp: Add 'let-system'. > d03001a31a gexp: Compilers can now return lowerable objects.

bug#41264: Bootstrap packages fail to build.

Hello, > fstat(3, 0xffad5874)= -1 EOVERFLOW (Value too large for > defined data type) > fstat64(3, {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 > fstat64(3, {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 > > So I think somehow, bootstrap packages use the legacy "fstat" sys

bug#41264: Bootstrap packages fail to build.

Hello, This command fails on one of my systems: --8<---cut here---start->8--- guix build -e "(@@ (gnu packages commencement) glibc-mesboot0)" --8<---cut here---end--->8--- with the following error: --8<---cut

bug#41120: uvesafb service is unsupported on aarch64

Hello, > We could maybe do something like that: > > (define (operating-system-hardware-specific-services) > #~(let-system (system target) > (cond > ((target-arm? system target) > '()) > ((target-intel? system target) >

bug#41182: Profile hooks ignore system and target

Hello Jan, > and with that "system build" succeeds (after a while) but "system vm-image" > says > > guix system: error: gnu/packages/glib.scm:404:2: > gobject-introspection@1.62.0: build system `meson' does not support cross > builds > > This could be mostly harmless...still building a fu

bug#40682: frozen installer in WiFi section -guix 1.1.0

Hey Leo, > If we have a fix, can we make a new installer image? There are people on > #guix having trouble getting online in the installer, and I think they > are hitting this issue. This bug has been fixed with ea6594e0. However, I left the ticket open because I'm supposed to add some testing

bug#41182: Profile hooks ignore system and target

Hey Ludo, > So I’m very much tempted to instead require each hook to take ‘system’ > and ‘#:target’ arguments and pass them to ‘gexp->derivation’. It’ll > break the API, in case someone out there has custom profile hooks > (unlikely given that it’s not really documented), but I’d say that’s OK.

bug#40981: Graphical installer tests sometimes hang.

was to add a 'sleep' between fork and exec, it works way better! Tell me if you think its better to drop it. > Could you send an updated patch? Here it is! > Thanks for the bug hunting and for the patch! Thanks for the fast review :) Mathieu >From 79d3603bf15b8f815136178be8c8

bug#41120: uvesafb service is unsupported on aarch64

Hello, Thanks for working on that Florian & Efraim. > + (if (and (string-suffix? "linux-gnu" %host-type) > +(or (string-prefix? "x86_64" %host-type) > +(string-prefix? "i686" %host-type))) > + #~(lambda () > +

bug#41123: shepherd exits for no good reason

Hey Ludo, > May 7 09:36:52 localhost shepherd[1]: Exiting shepherd... > May 7 09:36:52 localhost shepherd[1]: Service xorg-server has been stopped. > May 7 09:36:52 localhost shepherd[1]: Service console-font-tty2 has been > stopped. > May 7 09:36:52 localhost shepherd[1]: Service term-t

bug#40981: Graphical installer tests sometimes hang.

:00 2001 From: Mathieu Othacehe Date: Thu, 7 May 2020 18:39:41 +0200 Subject: [PATCH] service: Fix 'make-kill-destructor' when PGID is zero. When a process is forked, and before its GID is changed in "exec-command", it will share the parent GID, which is 0 for Shepherd. In

bug#41120: uvesafb service is unsupported on aarch64

Hello Efraim, > the uvesafb-service which was added to the installation image isn't > supported on aarch64 (or probably any non-x86 system) and causes the > creation of an installation image to fail. Thanks for reporting. There's this small snippet in uvesafb-service: --8<---cut he

bug#40981: Graphical installer tests sometimes hang.

* stop guix-daemon * start guix-daemon If the second stop occurs after "fork" has been done, but before "setsid", then "(getpgid)" returns 0. The naive patch attached could fix the situation. WDYT? Mathieu >From 0e4167251a56d6baa4f51fe72250a6e3bffae8c3 Mon Sep 17 0

bug#41082: nomodeset

Hello, Thanks for reporting! It has been discussed on IRC, and booting the same machine with integrated graphics works. While uvesafb allows us to get framebuffer support in the installer, the installed system will blackscreen or fail to boot with those AMD GPUs. Should we propose the installa

bug#40981: Graphical installer tests sometimes hang.

Hey! > OK, but the trace above is “as expected”, isn’t it? Oh sorry, I pasted the wrong part! Here's the part where getpgid returns zero and the full log in attachment: --8<---cut here---start->8--- [pid 1] stat("/etc/localtime", {st_mode=S_IFREG|0444, st

bug#40981: Graphical installer tests sometimes hang.

> I'll keep looking! Ok, getting closer. Here's a suspect part of Shepherd strace log: --8<---cut here---start->8--- [pid 1] stat("/etc/localtime", {st_mode=S_IFREG|0444, st_size=2298, ...}) = 0 [pid 1] write(9, "shepherd[1]: changing HTTP/HTTPS"...,

bug#40981: Graphical installer tests sometimes hang.

Hello, Graphical installer tests sometimes hang, before starting marionette tests. See for instance: https://ci.guix.gnu.org/log/d31s9sycixhvfak5lpzdg0mzvz5aa9av-gui-installed-os-encrypted. Restarting tests just after a hang (on the same installed image), sometimes work. I removed the "quiet" k

bug#35574: bcm5974 touchpad is not recognized as touchpad

> On Wed, Apr 29, 2020 at 06:41:22PM +0200, pelzflorian (Florian Pelz) wrote: >> I suggest the attached revert instead This patch and the associated revert look fine to me. Let's maybe wait for Brice opinion. In the meantime, if you could give me your opinion on: https://lists.gnu.org/archive/h

bug#40790: OOM error in graphical installer tests.

> * I have some hangs when doing the final testing in marionette. Still > trying to understand why. Fixed with c537d2bcb7c652b4776435cd1e2a5119af43dd78. Still an issue remaining. "gui-installed-desktop-os-encrypted" closure is about 5.5GiB which makes too much files for libisofs: --8<

bug#35574: bcm5974 touchpad is not recognized as touchpad

Hello Florian, > This avoids a race with the bcm5974 kernel module. > Fixes . This seems indeed better than not building the module. I know that (for now) having a mouse in the installer is not very useful. But maybe `kernel-arguments' in (gnu system install) should

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

Hello! >> This is because running grub-install needs root permissions, to mess with >> /dev/something in order to write the MBR I guess. > > Hmm...so we need to do some work, is that bad? Not sure yet, but I'll investigate it. >> We could also create a Hurd ISO if grub-mkrescue (that is used t

bug#40790: OOM error in graphical installer tests.

Hello, > Can we throw a little bit more memory at it? :-) That's what I did with ae1a0f758 :) > Is there a commit that trigger this failure? I didn't have the courage to bisect it, given how long this test is. Fixing it, I discovered two more issues: * "sherpherd services" test was failing

bug#40912: [BUG] GUI installer loops when using a NVME drive

Hello Kozo, > Did some troubleshooting with Civodul. Submitting the message log that > helped him determine it was a NVME issue. I guess you used the 1.1.0 release? This bug should be resolved on master. Do you have the possibility to build a new ISO image? You can run this command as explaine

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

Hello Janneke! I had a look to (gnu system hurd), this is really nice! I think we could try an explosive mixture of our two branches :) More seriously, we could do something like: --8<---cut here---start->8--- (define hurd-disk-image (image (format 'dis

bug#35574: bcm5974 touchpad is not recognized as touchpad

Hello Florian, > I tested the patch with linux-libre 5.4 on various x86_64 machines and > I tested 5.4, 4.19 and 4.4 on my Macbook. I did not wait for > compilation to complete on non-Intel architectures, but I doubt the > patch causes problems. Thanks for fixing this! This seems like a reason

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

> The wip-hurd-vm branch cross-builds a VM for the Hurd. It uses some > dedicated hacks to build the system packages, services, system profile > and shepherd configuration and cross-build them into a qemu image. > > We did this to avoid too much struggle up front with parameterizing, > working a

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

Hello Jan, > /gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go > $ 11:27:25 janneke@dundal:~/src/guix/core-updates [env] > $ file /gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go > /gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go: ELF 64-bit > L

bug#40790: OOM error in graphical installer tests.

Hello, The "gui-installed-os" test fails on master because "guix system init" command is OOM killed. Log of the failure is attached. Thanks, Mathieu oom.log Description: Binary data

bug#40682: frozen installer in WiFi section -guix 1.1.0

Hey, > I’ve now pushed it as two proper service types: ‘hostapd-service-type’ > and ‘simulated-wifi-service-type’, the latter using parts of the former. > > Note that currently the installer tests bypass connectivity checks > altogether, but perhaps we can still check what comes before, namely >

bug#40590:

Hello, Thanks for your answer! > The amd option didn't work, but nomodeset allowed me to get to a shell, > at which point I could start experimenting with various settings to see > if I could get a graphical environment. I finally did by switching over > to the proprietary kernel (which points

bug#40682: frozen installer in WiFi section -guix 1.1.0

Hey, I believe this is fixed by ea6594e0 on master. This is indeed very fragile, and converting it to D-Bus would be the right move. I will have a look to Nyacc! Writing a clean Guile-Dbus library could also be a nice and valuable GSoC/Outreachy project. In the meantime, could we merge your pa

bug#40590:

Hello, > Just in case its relevant, I did the installation twice (both through > TTY in order to run the mount/rm commands): > 1. 2 partitions, boot and encrypted root w/ swapfile, using desktop.scm > as a base > 2. 3 partitions, boot, root, and a swap partition, using > lightweight-desktop.scm

bug#40538: installer: Support uvesafb to install on machines without KMS.

Hey Florian, > They do show that the uvesafb shepherd service was started, even when > it did not load uvesafb. Maybe the shepherd service should be > renamed. I did check on my recent hardware, the module is not loaded anymore and everything works fine. On my old Intel machine, I guess uvesaf

bug#40538: installer: Support uvesafb to install on machines without KMS.

Hello Florian, > Please try adding nomodeset to the kernel parameters. I hope this > makes the Intel machine work fine. Yes it works fine with nomodeset! Do you think we can do something about it, besides adding a few lines in the documentation to warn that old hardware may require this option

bug#40590:

Hey, >> * This custom release[3]: 1.1.0-rc2 + the patch suggested by Danny for >> partitions > 1TiB. >> [3]: Via ipfs: QmbbkQZc7fbsDrutNwVuvpFep3dBjZx6muni3WgXjRneq7 > It occured to me that the Samsung drive might have been corrupted at > some point, so I dd'd /dev/zero into the first few gigaby

bug#36783: Guix graphical installation failure on all drives with size > 1 TiB

Hello, > Your fix seems ok for me, thank you! I don't get why you negative values > though. I'll try to find a big hard drive to understand this before > pushing this patch. I still don't have a big enough hard drive to test it, but I applied your patch anyway. If someone with hard drive > 1 Ti

bug#40590:

Hello, > The first error comes when trying to partition the SSD via the graphical > installer, choosing a guided installation. This will happen choosing with > or without encryption, and with or without a separate /home partition. Sorry for all the errors you encountered, but many thanks for th

bug#40572: installer networking: Connman detects no technologies on Acer Aspire

> Apr 12 16:35:35 localhost vmunix: [ 48.124498] uvesafb: fb0: VESA VGA frame > buffer device > Apr 12 16:35:35 localhost vmunix: [ 48.129053] shepherd[1]: Service uvesafb > has been started. > Apr 12 16:35:40 localhost shepherd[1]: Service dbus-system could not be > started. > Apr 12 16:

bug#40538: installer: Support uvesafb to install on machines without KMS.

Hey! > All is fine vga=793 does not break uvesafb on my Acer Aspire but does > not help either. Only on QEMU vga=793 broke everything. Maybe leave > the patch as is. Thanks for your patch. I tried briefly 1.1.0-rc2 on some hardware of mine. On three somehow recent laptops, everything still wo

bug#40572: installer networking: Connman detects no technologies on Acer Aspire

Hello Florian, Thanks for the analysis! > Error getting peers: The name net.connman was not provided by any .service > filesError getting technologies: The name net.connman was not provided by any > .service files > connmanctl> This is the kind of error you get when connmanctl cannot reach c

bug#40493: installer: Provide a way to select multiple keyboard layouts

Hello Florian, > I added some more heuristics on whether a layout is Latin or not and > after much testing pushed as 91c231a2223440081426929828a23c7baa0214fd. > There are still few false positives like non-Kana Japanese layouts > that are Latin but toggle to U.S. They can be fixed later. Nice!

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

Hey, > Ideally we’d also offer a way to choose multiple layouts in the > installer, so that one can end up with: > > (keyboard-layout "ar,us" #:options '("grp:alt_shift_toggle")) > > Although that’s mostly useful for the console as GDM and GNOME should be > able to do the right thing. > > Anyw

bug#40493: installer: Provide a way to select multiple keyboard layouts

Hello, The installer gained support for keyboard layout switching from every step recently[1]. It is also possible with commit 2729cb406d9f3e9eb22cc660f887138134edb3a8 to specify comma-separated keyboard layouts, this way: --8<---cut here---start->8--- (keyb

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

Hey, > Yes please! (BTW, sorry for the latency when replying; if you want, > please do chime in on #guix on IRC.) Merged! Heh, I know you are already quite busy :p The installer tests are really a nice addition. Being able to test it running: --8<---cut here---start--

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

Hello, > Do you think that branch is ready for a merge? Or did you want to > further discuss some of the changes? Florian seemed to agree that it’s > a good thing. Yes, for me it's ready. If you are ok I can check that our new fancy tests are still passing and merge it :) Now, there are othe

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

Hey, > That’s exactly what it does, see (shepherd comm). > > Perhaps we just need to have the installer service depend on ‘syslogd’, > at which point nothing goes to /dev/console? Heh, I read it too fast, sorry :) The issue was in fact that we are calling `start-service' and `stop-service' from

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

Hello Ludo, > Ouch. Are there possible other such issues lurking? The problem occurs when using `procedure->pointer' and passing the returned pointer to a C library that stores it globally. Because, in that case the pointer can be collected from the Guile side and used later-on from the C side

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

> Yes, that is definitely a good place, *but* now that I saw Debian, it > would be good to additionally have a key combination. I think > switching in an F1 help menu is more discoverable and having both > would be good. OK, noted. > From what an Arab friend told me, they are used to a key com

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

Hey, > * Guile-newt functions "newt-set-help-callback" and > "add-component-callback" seem to be tripping over each other and I'm > having a hard time trying to understand why. Ok I found out why, it was the GC that was collecting the callback pointers. I fixed it in Guile-newt. Now I push

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

Hello, Maybe we could add a help menu with key shortcut. From that help menu, one could change the current keyboard layout from any installation step? WDYT? Mathieu

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

Hey, > I test the Newt-based Debian 10 installer via QEMU. When I select > English language with Arabic keymap, I can choose a key combination > for switching the layout, Alt+Shift by default. But I cannot choose > between AZERTY and QWERTY, I always get QWERTY. Defining such a combination co

bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'

Hello, A small update on this bug, cross-compilation to x86_64-w64-mingw32 does not fail anymore on core-updates. However, the native gcc is used to build perl so there is still some work required! Mathieu

bug#39941: Disk-image size increase on core-updates.

>> +--- a/libgcc/configure >> b/libgcc/configure > > I suspect this is the only file we need to patch, no? At least, we can > remove all the m4 and m4-related Makefile.in changes and the unrelated > ‘configure’ changes. The configure files of the other libraries are needed too because they

bug#35700: Fixed

This has been fixed by 64704be417ab6f2788e8e3bc36fede1db35470e7. Thanks, Mathieu

bug#35690: Fixed

This has been fixed by 64704be417ab6f2788e8e3bc36fede1db35470e7. Thanks, Mathieu

bug#35543: Installer crashes on retry when selecting keyboard layout

and done. Mathieu

bug#35543: Installer crashes on retry when selecting keyboard layout

Hello, This has been fixed by 64704be417ab6f2788e8e3bc36fede1db35470e7. Thanks, Mathieu

bug#36402: installation error

Hello, This has hopefully been resolved by Guile-Parted 0.0.2 update, so closing! Thanks, Mathieu

bug#39941: Disk-image size increase on core-updates.

--end--->8--- In short, quite a big mess... > Apologies for suggesting some more tedious work, but I think it’ll be > helpful! :-) Hehe no worries, here's an updated patch :) Mathieu >From 31402fc14126f04e175081ce851e9794cc3ab218 Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Sat

bug#40071: Cross-compiled package closure size.

Hello, After applying the patch proposed here[1], the closure of cross-compiled "hello" still contains unwanted packages. --8<---cut here---start->8--- mathieu@elbruz ~/guix [env]$ guix size /gnu/store/14ygibryjr7mcly0q9mb8306hlg16nhq-hello-2.10 store item

bug#39941: Disk-image size increase on core-updates.

@@ -14,7 +14,7 @@ # Copyright © 2016, 2017, 2018, 2019 Jan (janneke) Nieuwenhuizen # Copyright © 2017, 2018, 2019, 2020 Tobias Geerinckx-Rice # Copyright © 2017, 2018 Clément Lassieur -# Copyright © 2017 Mathieu Othacehe +# Copyright © 2017, 2020 Mathieu Othacehe # Copyright © 2017, 2018

bug#39712: Partitions produced by the installer not properly unmounted?

This is fixed by 64704be417ab6f2788e8e3bc36fede1db35470e7. Thanks, Mathieu

bug#39941: Disk-image size increase on core-updates.

Hi, > Ah yes, we should try to introduce a “lib” output there as well. I > vaguely remember this was tricky but I’m not sure why; worth a try! Ok then, I'll give it a try. > Speaking of which, the Data Service has things like: > > > http://data.guix.gnu.org/gnu/store/p8in2npgl5yhliy25ikz7s

bug#39941: Disk-image size increase on core-updates.

Hey, > Could you find out (perhaps by looking at ‘guix graph -t references’) > what is referencing these two cross-compilers? Turns out on master, --8<---cut here---start->8--- guix size `guix build guile|grep -v debug` --8<---cut here---

bug#39941: Disk-image size increase on core-updates.

The "guix size" report is attached. Several issues appear: * Inclusion of gcc-cross-sans-libc-aarch64-linux-gnu-7.5.0 and gcc-cross-aarch64-linux-gnu-7.5.0. * Three different versions of guile-2.2.6. * Duplicated glibc, bash and coreutils. Thanks, Mathieu size_core Description: Binary data

bug#39941: Disk-image size increase on core-updates.

Hello, When building the attached operating-system (very close to bare-bones.tmpl) with the following command: guix system disk-image --target=aarch64-linux-gnu mini.scm --no-grafts the produced disk-image weights 2.6G (2717242368 bytes). On the same branch in January it was around 1.5G. I'll

bug#36882: Qemu 4.2.0 build for x86_64-linux fails

Hey, > clang-runtime requires a similar fix for CPLUS_INCLUDE_PATH. No idea > what's up with GHC@8.4 yet, but unsurprisingly removing libc from the > include paths does not make a difference. Closing this one, thanks for pushing! Mathieu

bug#36882: Qemu 4.2.0 build for x86_64-linux fails

Hello Janneke, > Do you have a patch/branch where I can see this related error? If mes > builds are an exception, it could be nice to solve it there? Or is > this a Qemu thing and is Qemu the only package that suffers from this? > > Trying to help here, but I'm not sure if I understand what's

bug#36882: Qemu 4.2.0 build for x86_64-linux fails

commencement) for mes packages. So, maybe the best option is to patch QEMU directly, as proposed in the attached patch. WDYT? Thanks, Mathieu >From 6d5dea746ce7b501cdb5ba41c5eff0c9ea7eb0b0 Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Tue, 3 Mar 2020 12:45:33 +0100 Subject: [PATCH

bug#36882: Qemu 4.2.0 build for x86_64-linux fails

Hey Marius, > Did you get anywhere with this? As Ludovic mentioned, it might make > sense to work around it in gnu-build-system too if patching GCC turns > out to be difficult. Yup, turned out patching GCC was too difficult. I'm experimenting a filter over inputs passed to set-path-environment

bug#36882: Qemu 4.2.0 build for x86_64-linux fails

Oops wrong shortcut, sorry! > I’d rather go for #2. To do that, we could modify the ‘set-paths’ phase > to manually remove glibc from C_INCLUDE_PATH (fragile), or we could > modify GCC (perhaps removing the ‘remove_duplicates’ call for SYSTEM). > > Either way, this wouldn’t work well with ‘guix

bug#36882: Qemu 4.2.0 build for x86_64-linux fails

Hey! > I’d rather go for #2. To do that, we could modify the ‘set-paths’ phase > to manually remove glibc from C_INCLUDE_PATH (fragile), or we could > modify GCC (perhaps removing the ‘remove_duplicates’ call for SYSTEM). > > Either way, this wouldn’t work well with ‘guix environment’, where gl

bug#36882: Qemu 4.2.0 build for x86_64-linux fails

Hey, > So is it expected that C_INCLUDE_PATH comes before the hard-coded GCC > include directory? How can we work around that? Turns out, the best source of documentation here is gcc/incpath.c. Here's a summary of my understanding. Header search list: * QUOTE -> -iquote * BRACKET -> -I go

bug#36882: Qemu 4.2.0 build for x86_64-linux fails

Hello, > On master there’s pretty much the same command as above, with ‘-m16’, > and “yet it works”. > > https://ci.guix.gnu.org/log/ymzp5yz2r3zfw4xczwwlykyjv2kqcqs0-qemu-4.2.0 On master, when building qemu, this is the gcc include path (obtained with "gcc -v -x c -E /dev/null"): --8<---

bug#39712: Partitions produced by the installer not properly unmounted?

Hey Ludo, > But I think the problem should show up even with “make check-system > TESTS=installed-os” on master. Well this does not involve the graphical installer, so I'm not sure to understand. Anyway, testing the installer in Qemu, I can reproduce a failure where the first umount in "umount

bug#39712: Partitions produced by the installer not properly unmounted?

Hey Ludo, Nice progress on that branch :) > Could it be a side effect of the MS_MOVE dance in > 1d02052067e04d7dd8fd1ec17557ca02a30b9bcf? Could be, I ran the following command on wip-installer-test branch: --8<---cut here---start->8--- make check-system TES

bug#36882: Qemu 4.2.0 build for x86_64-linux fails

Hello, On core-updates, qemu-minimal (4.2.0), fails to build. This seems to be the same issue as this bug. The error is: --8<---cut here---start->8--- In file included from /gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include/features.h:489:0,

bug#39657: Failed to compute derivation for Guix

Hello, > "815d3ac4c343c75beca2d752adc34312bfeff4fe"; system: "x86_64-linux"; > host version: "98e3953e96d1f172e2e44d1f2d2f2e6b107f2daa"; pull-version: 1). > Please report it by email to . > > I attached the full output of the pull. This seems to be caused by the update to Guile-SSH 0.12.0. I re

bug#38447: Fix installer restart.

> This should allow us to close: > > https://issues.guix.info/issue/39217 > https://issues.guix.info/issue/38447 Fixed by 1d02052067e04d7dd8fd1ec17557ca02a30b9bcf. Thanks, Mathieu

bug#39217: Fix installer restart.

This should allow us to close: https://issues.guix.info/issue/39217 https://issues.guix.info/issue/38447 And other issues I'm not aware of? Mathieu

bug#38320: Cuirass: Allow to use authenticated Git repositories as inputs

Hey, > Perhaps we should not call it at the top level, in case it throws an > exception or has unwanted side effects? I’d suggest moving it to > the procedures where it’s used. Thoughts? > > Apart from that it LGTM, thanks! Fixed and pushed! Shall we inform users (guix pull news?) that they c

bug#38320: Cuirass: Allow to use authenticated Git repositories as inputs

ay.) Here's a version with optional authentication support. I do not find it too intrusive, but let me know what you think! Thanks, Mathieu >From 4554baf59564eb0c31cfe235acd078d54afef6d7 Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Mon, 3 Feb 2020 18:05:02 +0100 Subject: [PATCH] git

bug#38320: Cuirass: Allow to use authenticated Git repositories as inputs

rks for Cuirass inputs and (guix git-download) module. Mathieu >From ae380c15f1c37e2c94e0954975f5f712e76340ac Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Mon, 3 Feb 2020 18:05:02 +0100 Subject: [PATCH] git: Add ssh authentication support. SSH agent authentication method is used.

bug#38703: installion cannot be cancelled

Hello, > You mean that Ctrl-C wouldn’t work on the ‘guix system init’ process, > right? Is that behavior controlled by Newt, Mathieu? Before running the guix process, newt is suspended and resumed right after (see run-install-shell procedure). So it should reset the original terminal settings.

bug#38447: Guix Stand-alone OS installation Error - T410 - x86 - intel - lenova

mar Ramalingam > > On Mon, Dec 2, 2019 at 9:18 AM Pon Arun Kumar R > wrote: > >> I downloaded the 1.0.1 image from the guix webpage and wrote a bootable >> DVD and used the graphical installer on a machine (lenova thinkpad t410 >> 64bit) >> >> On Mon, Dec 2,

bug#38320: Cuirass: Allow to use authenticated Git repositories as inputs

Hey! > Apart from this detail, it looks great to me! > > You have push access, right? > > Speaking of which, we really need to push a release at some point. > Erik, would you be available to do that, or would you like to delegate? Great, thanks for reviewing :). I couldn't get it to work with a

bug#38359: Guix 1.0.1-10.41b4b71 test fails on armhf

Hola! > As for the detection, this appears to work: > > (define (binfmt-misc?) > (let ((pid (getpid)) > (cmdline (call-with-input-file "/proc/self/cmdline" > get-string-all))) > (match (primitive-fork) > (0 (dynamic-wind > (const #t) > (la

bug#38320: Cuirass: Allow to use authenticated Git repositories as inputs

9851b02e78096963616d4e2f999119fc4d Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Mon, 9 Dec 2019 16:16:45 +0100 Subject: [PATCH] Add ssh authentication support. * Makefile.am (SOURCES): Add git/auth.scm, (TESTS): add tests/clone.scm. * configure.ac: Check for git and ssh binaries. * git.scm

bug#38447: Guix Stand-alone OS installation Error - T410 - x86 - intel - lenova

ead keys, > > I tried several attempts, and I doubt whether it is something to do with > the BIOS settings update as a pre-requite for the installation. > > Thanks, > Pon ArunKumar R > > On Mon, Dec 2, 2019 at 8:54 AM Mathieu Othacehe > wrote: > >> >> Hel

bug#38359: Guix 1.0.1-10.41b4b71 test fails on armhf

now how to detect it properly for the test suite. WDYT? Mathieu >From 3b6f5708043a29343275fadf0b0e0e651bb6971e Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Fri, 29 Nov 2019 10:37:12 +0100 Subject: [PATCH] process: Fix binfmt support. Guix-daemon does fork itself for each client process. The pid of the client is hardcode

<    1   2   3   4   5   6   7   >