<attila_lendvai>i'm playing with `guix system vm myfile.scm`, and it stopped working and i have no idea why. i get into a guile repl, and prior to that: no boot file passed via '--load'. nothing changed in how i invoke the wm, only in my service, probably some error
<attila_lendvai>when i quit the repl: Kernel panic - not syncing: Attempted to kill init!
<apteryx>if you haven't configured anything you won't see any match, which means your daemon is using 1 job
<apteryx>but even without multiple jobs, I think the same output can appear many times in the UI as the download progress
<apteryx>it's a limitation/problem in the UI where the build plan gets populated as the process occurs, and new items are being added to the list and the output refreshes, causing the same items to appear again
<apteryx>it doesn't mean they are *downloaded* multiple times; just printed
<sneek>mothacehe, nckx says: When (manually) restarting a CI build, would it be feasible to automatically restart all dependent packages that were marked as ‘dependency failed’ because of that package alone?
<sneek>mothacehe, nckx says: If that is already the case, it's not clear from the UI. A dependent (gnome-shell) remained ‘failed’ even when all dependencies became green. Maybe it was being rebuilt in the background though, I didn't wait around and manually restarted it.
<mothacehe>nckx: that's indeed the case, failed builds are automatically restarted when their dependencies are all successfully built
<chrislck>anyone knows how to roll-back guix home beyond the initial generation? where's the original configuration saved at
<rekado>efraim: this time php built fine on aarch64
<rekado>I built it on grunewald; it previously failed three times on pankow.
<attila_lendvai>so, i can copy-paste into a qemu vm started by `guix system vm foo.scm` by copy-pasting the content of the run-vm.sh, and editing it to add console=ttyS0 to the -append line. this is rather cumbersome... is there a way to atomate this? i'm willing to write code, too.
<rekado>you could also just call run-vm.sh with extra arguments
<attila_lendvai>oh well, #:graphic? #false still opens a separate qemu window (as opposed to using the terminal it was started in). i need to patch system-qemu-image/shared-store-script to also include -nographic, but... well, we'll see what the maintainers think about it. preliminary feedback is welcome!
<apteryx>attila_lendvai: the usual workaround is to copy that /gnu/store/...run-vm.sh script somewhere and edit it to your needs
<attila_lendvai>apteryx, that's what i was doing, but it's a serious slowdown in my cycle
<apteryx>not pretty, but gets the job done. a patch to qemu so that later args take precedence above earlier one, and an -append that truly appends would be great patches for QEMU in my opinion
<zimoun>apteryx, cool! Thanks. Wait v2 later today. :-) v2 will fix julia-* packages for i686.
<GuiGuiGuix>nckx: I try to access the admin cups portal either but does not work with root or current user
<nckx>But how exactly does it fail? Note that CUPS does not have a Web interface by default, so if you visit localhost:631 and just can't connect, you need to make sure you have ‘(web-interface? #t)’ in your cups-configuration.
*apteryx tries the i686-linux cross-built rustc in a 32 bit VM
<roptat>GuiGuiGuix, intellij is hard to package, but at least I was able to run it by downloading the binary version. I had to create myself a shell with the dependencies, in a container so I could mount FHS locations from the profile
<roptat>that way, I can provide dependencies where it expects them to be
<apteryx>cross-compiled 'rustc --help' on 32-bit VM runs \o/
<nckx>I wouldn't, but ask in #guile. The seeding example is explicitly ‘for non-security-critical applications’. It never mentions what security-critical ones should do…
<attila_lendvai>damn. i have a command that i'm unable to run in herd (but it runs fine in guix repl). "< /dev/urandom tr -dc _A-Z-a-z-0-9 2> /dev/null | head -c32 >password-file". in herd arcivation form the system call returns 2, and i have no clue why. i'm replacing the tools with the full store path.
<attila_lendvai>i guess i should forget guile's random. it straight out starts up with the same seed every time, and "To seed the random state in a sensible way for non-security-critical applications, do this ..."
<janneke>/gnu/store/r1zsxj7wlvw1aa1ifv3nyrrjag44pc9s-xz-mesboot-5.0.0/bin/xz: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, with debug_info, not stripped
<bdju>I have a video call interview in a few days. Does anyone know if it's possible to screenshare from Sway on Guix System? I'm not sure if I'll need to, but it's a concern I have.
<attila_lendvai>correction: the system call fails even without fork and setuid involved.
<attila_lendvai>a clue is that system* works, but system doesn't. must be something with /bin/sh. the service user's shell is nologin, but the C system manpages explicitly talk about /bin/sh, not the user's shell
<podiki[m]>bdju: I haven't used Sway, but hopefully wouldn't be any different than another distro, likely depends on the video call software you are using
<attila_lendvai>it's the same after changing the user's shell to bash from nologin
<podiki[m]>(though may depend on master vs core-updates-frozen for software versions needed?)
<bdju>podiki[m]: well, the weirdness would be related to wayland, and I might need certain things in place that might not be packaged
<bdju>jpoiret: thanks for the info. is there a guide on how it's configured somewhere?
<podiki[m]>bdju: I have yet to use wayland, so can't comment there sorry. (I do plenty of video conferencing on X with guix that is fine at least)
<bdju>well, I don't run a display manager right now, and iirc startx doesn't work on guix system. so I would have to do quite a bit of setup to get X going at this point. I'd sooner use a different machine probably
<bdju>(also, I don't really want to use X if I can help it...)
<apteryx>sneek: later tell civodul hi! "ld-wrapper-cross" appears as a native-input in cross-gcc, but is there otherwise a way to get a handle to it in a cross-built package? I'd like to add it to the PATH of the cross-built 'cargo'.
<zimoun>apteryx: In fact julia-* is broken for master on i686. Therefore, it is a bit longer than expected. :-) I will send a v2 fixing all Julia things for i686 on core-updates-frozen tomorrow. I guess. The fix for julia itself remains the same for v1 or v2. Wait just avoid to let CI build some julia-* that I know are broken. :-)
<cryptograthor>Hi, first time here. Running into issues on installing from a USB, I get the message "/mnt/boot/efi doesn't look like an EFI partition"; $ fsck -N /dev/nvme0n1p1 (the efi partition) says the system is formatted as vfat as expected. What else should I look at?
<nckx>Hm, and yet that error is triggered only by ‘grub_strcmp (fs->name, "fat")’ in GRUB.
<nckx>Thanks. I've got to go now. I told cryptograthor to reinstall Guix System (something was clearly wrong with GRUB in a way that would be hard to debug remotely). If someone here might hold their hand, it would be wonderful.
<lilyp>attila_lendvai: The kernel random-number generator is designed to produce a small amount of high-quality seed material to seed a cryptographic pseudo-random number generator (CPRNG). It is designed for security, not speed, and is poorly suited to generating large amounts of random data. Users should be very economical in the amount of seed material that they read from /dev/urandom (and /dev/random); unnecessarily reading large quantities of
<lilyp>data from this device will have a negative impact on other users of the device.
<dissent>hey guix, i successfully used guix lint and build on a package i'm attempting to add. this was in admin.scm. when i attempted to lint and build another package it reads "unknown package". what could be the issue here?
<lilyp>i.e. don't read from urandom directly into passwd; that's wasteful af
<lilyp>dissent: if it only exists in your local checkout you might need to build that first and use pre-inst-env
<lilyp>it could also be a hidden package or something in which case you need to eval your way around it
<attila_lendvai>background: i'm using /dev/urandom to generate a password when a service first starts. this is what upstream does also (in their debian package).
<dissent>lilyp: thanks for the response. will attempt to figure it out.
<roptat>the_tubular, they're "minimal" variants that have less dependencies, in general
<the_tubular>Yes, this is what I could gather, are the features comparable ?
<roptat>since there are less optional dependencies, there are less features