<alanz>nckx, I copied the full arguments list over and it worked. Thanks. <nckx>What will you do when Guix's imagemagick changes? <alanz>nckx: I agree, but at least I have confirmed what you told me. And learned in the process. Will look at that next (tomorrow). Thankw <acrow> Hmmm, I'm building a package with ant-build-system and it has a generate-jar-indices phase which is failing. <acrow>I can trivially delete it but I'd rather preserve it if I could understand ... <acrow>Why the build outputs made available to generate-jar-indices contains jars that do not get installed? <acrow>Or, neglecting this, I could wrap the generate-jar-indices in a filter for the jars that are supposed to be there. But, I don't think that outputs is a simple list of fq jar pathnames. Hmm, how to filter this? <lilyp>sneek later tell blake2b: Guile-based graphics libraries are still on the experimental side, but you do have curses, sdl, and gtk in some capacity. <itd_>Hi. I'd like to reproduce the build failure of efivar.i686-linux [1] on a (faster) x86_64-linux system. Is that possible? (I tried `guix build --target=i686-linux efivar` but that fails to fail.) Thanks! [1]: https://ci.guix.gnu.org/build/495200/details <attila_lendvai>the last profile i can boot on my (non-libre) laptop is feb 10. after that it hangs at boot, or boots up incompletely. it has to do with graphics mode switching and console, because CTRL+ALT+Fn doesn't switch the virtual consoles. any hints? *attila_lendvai specifies (commit ...) in the config based on guix system describe of the working profile, and tries a reconfigure <abrenon>do you have any idea what causes the boot to entirely hang or to be incomplete ? <abrenon>can you deterministically produce one or the other ? <attila_lendvai>abrenon, it's not deterministic. sometimes it reaches GDM, and i can type my password, but it hangs there. other times it doesn't even reach GDM. one thing i have noticed is that the working boot blinks very early and changes gfx mode while still at the console. it doesn't happen with the non-working profiles. <jpoiret>attila_lendvai: are you on linux-libre? if so there's a bug in it <attila_lendvai>jpoiret, no, it's the full linux kernel from that other channel. is that still affected by the iwlwifi related bug? <jpoiret>can you check /var/log/messages and friends after booting on an older generation to see if there's anything specifically wrong? <attila_lendvai>i see some MTRR sanitizer related stuff (vmunix: [ 0.002416] *BAD*gran_size: 2M chunk_size: 512M num_reg: 10 lose cover RAM: -256) <attila_lendvai>ok, so rewinding to feb 10 commits in the two channels results in a working system after a reconfigure. (the mttr error is the same, though, so it's probably not the showstopper) <pranavats>jpoiret: Keeping /boot on an ext4 unencrypted partition did help Grub unlock the crypt. But I get an error when I try to boot into Guix after that. "error: no such device /gnu/store/.../bzImage". "error: file /gnu/store/.../bzImage not found". "error: you need to load the kernel first". <pranavats>These errors correspond to three commands in my Boot command list. First is to search for bzImage device. Second to load linux kernel. And third initrd. <jpoiret>you do you configure the bootloader? is it fully handled by guix? <jpoiret>do you have the store on a separate partition? <jpoiret>do you configure the bootloader yourself?* damn my brain didn't leave S3 sleep before typing that one <pranavats>jpoiret: I provide it grub-efi-bootloader variable, and the target "/boot/efi". <jpoiret>does the file that it fails to find exist in your store? <pranavats>And no. My store is in the root logical volume itself. <jpoiret>how do you know that GRUB successfully unlocked the crypt? did you try browsing the partition contents using the GRUB rescue shell? <jpoiret>usually, if the root partition with the store is successfully decrypted, there's a guix background, otherwise it's plain blue <allana>Hi guix! Is there a canonical way to modify arguments (like configure flags) for a package variant? <pranavats>I entered the passphrase and it shows me a blue splash screen to boot from. <pranavats>Then it didn't unlock. It also doesn't say which keyslot opened it. <jpoiret>the keymap when unlocking in GRUB is qwerty, maybe that's why? <pranavats>jpoiret: I use qwerty, and I guess if the passphrase was incorrect it would prompt me for another passphrase? <jpoiret>now whenever I input the wrong passphrase I just power off and start again <pranavats>This is something very different from my experience of Grub with luks2 just a few days ago. Very frustrating. <jpoiret>are you sure you're using pbkdf2 for it, rather than Argon2? <jpoiret>you can check with cryptsetup luksDump /the/device <pranavats>I changed it using luksConvertKey and checked immediately afterwords. Let me check it again in a few minutes. <pranavats>But I notice that when initializing the system it downloads a argon2 package. Could be for something else. <jpoiret>you could manually check the generated grub.cfg in /boot/grub/ <jpoiret>check that the UUID is the right one in the cryptopen call <jpoiret>LUKS2 should work, at least it did when I tested in an emulator, so it's quite weird <jpoiret>you could also try running `cryptomount -a` from the rescue shell and see what the output is <jpoiret>and if it does unlock, check if the files are in the expected place *allana finds his own solution in gnu/packages/gnome.scm, where "substitute-keyword-arguments" is used with configure flags. <pranavats>jpoiret: It says `slot "1" opened`. cryptomount in grub shell. <jpoiret>hmmm, looks like it unlocks properly then <jpoiret>can you try to `ls` and find the files it wants to open from there? <jpoiret>i'm rusty wrt GRUB shell but TAB completion should work <pranavats>jpoiret: Yes I'm able to list the /gnu/store contents. <jpoiret>are you able to find the bzImage it wants to load? <pranavats>jpoiret: The luks container shows up but its filesystem isn't recognized, and I can't list its contents. <maximed>itd_: Try "guix build --system=i686-linux efivar" (i.e., --system instead of --target). --target is only for cross-compilation, and cross-compilation betweeen x86_64 and i686 is unsupported (though fixes welcome!) <maximed>sneek: later tell itd_: Try "guix build --system=i686-linux efivar" (i.e., --system instead of --target). --target is only for cross-compilation, and cross-compilation betweeen x86_64 and i686 is unsupported (though fixes welcome!) <maximed>sneek: later tell itd: Try "guix build --system=i686-linux efivar" (i.e., --system instead of --target). --target is only for cross-compilation, and cross-compilation betweeen x86_64 and i686 is unsupported (though fixes welcome!) <jpoiret>you can try running insmod lvm too and see if you can peer inside the filesystems then <jpoiret>now, why is insmod lvm not in the default grub.cfg is the question <jpoiret>alright, I think I know what's wrong <pranavats>Yeah. You're the guy for luks2 around here. So what's wrong? <jpoiret>in the usual LUKS1+LVM setup, grub-install recognizes that the root is on LVM on top of LUKS, and bakes the relevant modules right into the GRUB2 binary, so we never actually need to insmod them <jpoiret>with LUKS2, grub-probe (and so grub-install) is unable to read the disk properly and detect what's on it, and so it also doesn't include LVM modules <jpoiret>that's my guess without much testing <jpoiret>Maybe you'd like to test the patches I have for GRUB? I don't think it would be too hard <sughosha>with an example if there is one, is appreciated and thanks in advance. <apteryx>sughosha: we have gjs packaged; you should configure or patch tangram to use that <jpoiret>generally in guix, packagers unbundle such dependencies to use the packaged ones <phf-1>Hello Guix! I finally got Cuirass working with a couple of VPS using the remote build mechanism. Will publish something in the cookbook hopefully if it's of any use. <jpoiret>there are 2 patches in the archive + an example configuration file <sughosha>apteryx: I somehow succeeded building the appliation. But while running, I'm getting this error: `/usr/bin/env: 'gjs': No such file or directory` <phf-1>sneek later tell mothacehe I've got cuirass working with the remote build mechanism :) <jpoiret>basically you only have to create a new grub package with the patches added, and use that in the bootloader part <jpoiret>i just tested in a VM and it boots fine with LUKS2+LVM <apteryx>sughosha: you need to patch its reference in tangram's sources <sughosha>apteryx: Ok, thanks. I will try that. I thought that would be automated. <apteryx>rekado: hi! would today be a good "retry-day" for berlin? <gnoo>i finally solved my audio issue <gnoo>in /etc/asound.conf, there was a reference to path added by alsa-service that guix gc removed <gnoo>i've never manually enabled alsa-service, it must've been part of %destkop-services which i tried at the very start once <lfam>phf-1: It would be great to get a cookbook recipe, or even something for the Cuirass manual <lfam>Bonus points if it results in improvments to Cuirass itself make it easier to set up <apteryx>gnoo: oh! so /etc/asound.conf lingered there even there was no service for it? <akonai>is inserting a copyright notice on the top of the file necessary to submit a package? <gnoo>akonai: probably not, my package was accepted without it <gnoo>now, i need to figure out what's messing with gdk pixbuf cache <gnoo>can i remove lines from loaders.cache as root and will it be okay? <gnoo>there's double entry for svg and that's causing it to not work <apteryx>gnoo: you're having problems with the file pointed to by GDK_PIXBUF_MODULE_FILE? <phf-1>lfam, challenge accepted for this wk! <lfam>akonai: It's not necessary. If the code reviewer thinks your contribution is copyrightable, they will add it for you <gnoo>apteryx: yes, for now i've set it to /home/me/.local/loaders.cache where i removed the extra entry <apteryx>the file is created by a profile hook <apteryx>it just calls the GDK tooling to produce it <lfam>gnoo: There was an old and stale store name in /etc/asound.conf? <gnoo>lfam: the whole file was pointing to non-existing paths (in multiple places) so i removed it <lfam>We should change the service to avoid that <gnoo>apteryx: so, if i do change it, it will be fixed, hopefully ? <apteryx>gnoo: it calls gdk-pixbuf-query-loaders; the content of the file it produces depends of what's available in your profile <apteryx>see 'generate-gdk-pixbuf-loaders-cache-file' in (guix build glib-or-gtk-build-system) and 'gdk-pixbuf-loaders-cache-file' in (guix profiles) <gnoo>yes, but it's making wrong file, having the same entry twice which seemingly destroys everything using it <apteryx>can you create a bug report with this, with a reproducer? <gnoo>i don't really know how to reproduce this <lfam>Good news: #53712 "Guix System hangs after boot with linux-libre >=5.15.17" has been fixed in the latest kernel releases <apteryx>did you find the upstream commit that addressed the regression? <lfam>Yup, I mentioned it in the "closing" email to the bug ticket <nckx>Hi apteryx! Several reasons, really, but nothing actually related to (un)freedom. I use a heavily patched kernel (not only bcachefs, although that alone touches more of the kernel than you'd think) and having to rebase all that onto L-L (or deblob the whole tree at every little change) is prohibitive. <apteryx>OK! Thanks for sharing this use case. <nckx>It's a high price to pay to hide a few mentions of firmware I already know is there and unused. <nckx>apteryx: Eh, you asked 😛 <lfam>And now I've sent a patch to update the default kernel series to 5.16 <sleepydog>does guix have packages for plan9port ? i could try contributing some if not. they recently (~1 year) re-licensed to the MIT license <lfam>I don't see the string 'plan9port' in our codebase, so probably not <sleepydog>it could be a little tricky because a handful of its commands shadow coreutils and other commands, like `ls`, `troff`, and so on. I'm not sure if there's a convention for how to handle that already. <lfam>One would have to look at how PATH is created and consider the order <pranavats>jpoiret: So I removed the separate unencrypted /boot partition from my config, copied the package definition of grub-efi-luks2 and configured the bootloader accordingly. Unmounted /boot partition and remounted /boot/efi back. And reconfigured the system using config.scm. Grub still doesn't prompt for entering a password for luks2 for me. <pranavats>My /boot is a regular directory in the encrypted root now. <rictjo>I'm trying to run ROCm by AMD or more specifically rocm-bandwidth-test with license: NCSA/University of Illinois Open Source License using the amdgpu driver <pranavats>Nevermind jpoiret, I think I reconfigured with the wrong config.scm. Let me get back to you on this. <rictjo>I have an older card that was marked as compatible on the h-node site <rictjo>so... does anyone have experience with trying to run ROCM on guix <rictjo>the error is : Error: HSA_STATUS_ERROR_OUT_OF_RESOURCES: The runtime failed to allocate the necessary resources. <rictjo>it basically cannot find the correct card <rictjo>there is also a recurring error in dmesg > [ 30.059143] amdgpu 0000:09:00.0: [drm] Cannot find any crtc or sizes <rictjo>nut I don't know how to start fixing it <rictjo>I'm writing by watching a monitor that is connected to the card in question <rictjo>so I get a X screen that is working, but perhaps it has fallen back to some other driver... IDK <rictjo>any pointers would be appreciated <vivien>Dear guix, when I try to reconfigure my server, I get: erreur : le service « xorg-server » requiert « elogind » qui n'est fourni pas aucun service but when I include the elogind service, I can’t log in via SSH anymore <vivien>Is there a way to deactivate the "xorg-server" service? <alendvai__>how can i set the open files limit for shephard started processes? i have increased the system wide limit, and i have configured the pam-limits-service, and according to su - username -c 'ulimit -aHS' -s `which bash`, it is indeed elevated. but when i restart the service, the process has the default limit (according to cat /proc/123/limits, and according to the errors i'm seeing) ***alendvai__ is now known as attila_lendvai
<gnoo>vivien: afaik, xorg either requires elogind or being run as root. i migrated to wayland (using sway) due to this issue <vivien>gnoo, I don’t need a GUI on my server, I’m find without either :) <gnoo>vivien: are you using %base-serivces or %desktop-services? <gnoo>oh, then is something including xorg-server ? if not, you can just remove it <gnoo>the services i append to %base-services are openssh-service-type, seatd-service-type, bitlbee-service-type, dnsmasq-service-type and dhcp-client-service-type <vivien>gnoo, I think I just needed to remove the (set-xorg-configuration ...) <apteryx>rictjo: amdgpu is pretty useless without nonfree blobs, if I recall <attila_lendvai>so, it seems like setting the open files limit using the pam-limits-service only applies to interactive processes, i.e. not to daemons. am i suposed to extend shepherd's fork+exec-command with args to set the ulimits? i lack the linux fu to see what is a nice way to solve this. <GNUtoo>apteryx: it probably is because people don't do the easy work of adding support for them in linux-libre <GNUtoo>Basically the radeon driver requires a firmware so we just patch linux-libre to not error if a firmware is not found, a similar method can be attempted with amdgpu <rekado>apteryx: yes, we can try rebooting today <GNUtoo>Though in reality more hidden nonfree blobs are still present <GNUtoo>(there is some bytecode in the video BIOS that is used by the driver to intialize the GPU, and the video BIOS / GOP drivers are also typically used but there are ways not to use them by patching SeaBIOS for instance) <rekado>(I got sick so I won’t ride to the data centre if things go wrong; let’s just hope we will be able to recover in any case.) <apteryx>rekado: ugh, sorry to hear you got sick. I wish you prompt recovery! <lisbeths>Just completed my first guix install on my thinkpad. <avp>But through the Tor networks everything works OK. <rictjo>GNUtoo: so basically I need to launch a non free kernel to get everything running or add in support in the linux libre kernel by defining a custom one? <apteryx>GNUtoo: OK. I was under the impression that the nonfree bits are crucial in enabling any 3D/video acceleration, but I don't know much. <avp>Does anyone have an example of Guix configuration with Tor network, when Guix installed on upon another system (like Ubuntu GNU/Linux)? <GNUtoo>apteryx: there are several issues, for the AMD/ATI GPUs to work in linux-libre, you need support for it in linux-libre specifically, and when you have that then you don't have any 3D acceleration due to the missing firmware <GNUtoo>without that you have only the VESA / efifb driver <GNUtoo>So you're limited to 1 display, you might not have native resolutions, and the graphics may also be slower <acrow>attila_lendvai: IIRC PAM only cares about process owner id's and if those id value exceed the range for system uid's then they are non-system. I am not sure that the shell's conception of interactive is important to you, no? <GNUtoo>rictjo: for the amdgpu, we started work on that in linux-libre but it took me too much time to complete as I didn't have the GPU, I'll try to find the patch and thread <GNUtoo>For radeon it is usually pretty easy <GNUtoo>basically you have code like that: <GNUtoo>r = r100_cp_init_microcode(rdev); <GNUtoo>So the idea is to not return the error and it continues <GNUtoo>Then there is also a tweak needed for Xorg support that's also documented in that wiki page <attila_lendvai>acrow, i'm reading "The per-process limit is inherited by each process from its parent." and daemons are spawned by shepherd, the root process. they suggest to call ulimit before starting the daemon, and i'm seeing pointers to edit the "/etc/pam.d/common-session*", which is not available on guix <unmatched-paren>and here i was thinking that AMD was one of the better hardware companies... <GNUtoo>The reality is that it changes a lot <GNUtoo>And even in the same company different branches can be very different <GNUtoo>Example with Intel: its GPU were really good and might still be good though I didn't check recently <GNUtoo>but with Coreboot AMD was better (though now they don't release source code anymore) <unmatched-paren>so if you want to use a dedicated gpu with linux-libre you basically have to go with one of the old NVidias that works well with Nouveau? <GNUtoo>And for ATI/AMD you have a really good example of going back and forth <GNUtoo>like you had documentation for GPUs then no documentation then documentation again <acrow>attila_lendvai: that makes sense. <GNUtoo>The ideal is RYF computers where it works with Libreboot <unmatched-paren>they do whatever will make their wallets the largest at that particular point in time :/ <GNUtoo>With Nvidia GPUs they seem to work well with FSDG distributions but they still ship nonfree software AFAIK (also in the form of bytecode in the video BIOS, that is then used by drivers) *attila_lendvai realized that his service can extend the pam-root-service-type <acrow>attila_lendvai: then won't shepherd want to change the owner to someone other than root also? doesn't the identity of the subsequent process owner also have an impact on those kernel privs? <unmatched-paren>but then, every single hard disk in existence (afaik) contains nonfree stuff to manage the disk... eventually you reach a point where you've done everything you can <attila_lendvai>acrow, good question. the answer seems to be no, as per cat /proc/[pid]/limits, even though the daemon process is running with the right user <GNUtoo>The easiest way is probably to start with Linux and just try to find the right thing to comment <drakonis>its largely the same as when it was written for hurd <acrow>attila_lendvai: providing some extended services seems like a very guixy way to approach it. :) <GNUtoo>I start to remember why it was harder: there were several engines <GNUtoo>so you needed to not bail out for more than one firmware <GNUtoo>here the last patch has 4 lines replaced with /* DEBLOBED */ instead of the usual 1 line <GNUtoo>+ I probably made some mistakes along the way too <GNUtoo>So there is a bit more work for the amdgpu driver but it doesn't look too hard / long either <GNUtoo>Like it's probably around few day of work (because compilations take time and there is still time to spend to do the setup) <GNUtoo>It could be really fast if you're used to compile kernels <GNUtoo>And if you've got the right hardware setup it can be speeded up a lot: some computers can export GPUs to VMs, so it might be possible to use that to boot a just compiled kernel and test it real fast <GNUtoo>(so it depends a lot on how used you are with these things) <GNUtoo>Alternatively we could try to organize something to fix it, like find a way to get GPUs from each family and crowdfund the work <pranavats>jpoiret: I accidentally reconfigured with the wrong config.scm and system became unbootable. I'm initializing the guix system with your patches as we speak. Will let you know when it finishes. *GNUtoo is busy with other things so he doesn't have that much time to fix that radeon/amdgpu issue <nckx>unmatched-paren: unmatched paren: (which "echo")))))) <- here <nckx>You're closing modify-phases early. <nckx>I strongly recommend an editor of any faith that at least highlights pairs :) <unmatched-paren>i do have an editor that highlights pairs, but it doesn't support scheme, since there's no tree-sitter-scheme afaix <nckx>It claims to support several lisps. <nckx>I don't know tree-sitter, but if it doesn't try to be too clever, that might suffice. <unmatched-paren>i don't like tree-sitter, but the other features of the editor are too good to give up <nckx>Set it to elisp/CL/… and see if it's tolerable. <unmatched-paren>also, the .scm file extension is hijacked by the tree-sitter query syntax <nckx>At least we've now an origin story for you nickname. <unmatched-paren>nckx: i have removed one parenthesis from that line you pointed out, but it's still giving the same error, i guess there's another mistaken parenthesis <drakonis>helix doesnt seem to have support for any lisps <nckx>Same problem at "d2/dmd-testsuite/runnable_cxx/cppa.d")))))))) <- le naughty paren <unmatched-paren>add a submodule for the tree-sitter grammar in helix-syntax/languages/, add an entry for the language in languages.toml, then add some query files to runtime/queries/ for highlighting and indents <nckx>AND make-flags)))) <- zut alors <nckx>Unless my emacs has gone haywire, your editor is doing weird things? <nckx>Are we even suprised at this point that "dmd-testsuite|lit-tests|ldc2-unittest"))))) <- this is a sneaky wrongboi too? We are not. <itd_>sneek: later tell maximed: Task/efivar-build failed successfully. Thanks! :) <sneek>itd_, maximed says: Try "guix build --system=i686-linux efivar" (i.e., --system instead of --target). --target is only for cross-compilation, and cross-compilation betweeen x86_64 and i686 is unsupported (though fixes welcome!) <sneek>itd_, maximed says: Try "guix build --system=i686-linux efivar" (i.e., --system instead of --target). --target is only for cross-compilation, and cross-compilation betweeen x86_64 and i686 is unsupported (though fixes welcome!) <nckx>I did make a you/your typo earlier, but this was not one. One is enough. <nckx>Make sure it actually builds as you expect, though, since you can still quote syntactically valid nonsense. <unmatched-paren>i think i might move back round to nvim, helix is giving me too much grief <unmatched-paren>(the plugin system will use WASM, which i think is a really cool idea, since any language that can compile to WASI will be usable for it) <nckx>4 times is definitely enemy action. <unmatched-paren>but upstream guix did something that broke one of the rust packages that tree-sitter depended on <unmatched-paren>there is apparently no sane text editor, which is strange because there's so many of them <unmatched-paren>since i now have a (fixed) tree-sitter package in my channel thanks to helix, i'll try readding the nvim package <rictjo>GNUtoo: thank you for the hints. I'll get back if I make any progress <nckx>I fought someone for free hardware but I lost and they ran away. *GNUtoo has a different definition of hacking and is for hacking <Franciman>i was referring to all forms of violent computer hacks that illegaly hurt you <GNUtoo>btw, is it possible to use -e line in guix pack -e to refer to a file like with guix build -f mypackage.scm or guix install -f mypackage.scm ? <unmatched-paren>"NVIM v0.6.1" this is pretty nostalgic... nvim -> emacs -> helix -> nvim :) ***mike[m]1 is now known as beepbooptheory
<podiki[m]>very good nckx, you win the day, here's your internet point 🌟 <vivien>Maybe these cool snakes will help me reach a python reviewer for my patches ! <nckx>I'd feel guilted into helping if I spoke parceltongue, but I don't. <vivien>(don’t worry if you’re not in the mood though) <nckx>(By which I mean Python, I'm not merely being mean.) <vivien>I think there’s an effort to change the build system, made difficult by the fact that tests were not checked before (so now they fail) for a lot of packages <vivien>So the situation is rather difficult for python now <alanz>nckx, I finally got to look at the paste you sent last night. And it looks like it does it the way I hoped I could. Thanks. <nckx>I admit that s-k-a can look intimidating. <nckx>substitute-keyword-arguments <alanz>It's more about being unfamiliar with the ecosystem. I was pretty sure there had to be a thing like that. <alanz>But I am enjoying my foray into guix *GNUtoo wonders if we can review each other patches when we don't have commit access <GNUtoo>How do we do that in practice? we just reply to the mails after the fact? <GNUtoo>Usualy we don't get the first mail <nckx>If you subscribe to bug-guix and/or guix-patches you do. It is not tied to having commit access (although committers are encouraged to subscribe, I don't know if this is documented anywhere). <nckx>If you don't want to deal with the mail volume that implies, you can download the .mboxes, for example from the top-right icon on each message at <https://issues.guix.gnu.org/54129> to properly quote replies. <nckx>Maybe emacs-debbugs makes this more streamlined, I dunno. <ngz>Hmm. I get "ice-9/eval.scm:293:34: In procedure cdr: Wrong type argument in position 1 (expecting pair): #f" when I try to run make on Guix repository. <vivien>ngz, did you try to clean the files and run ./bootstrap, ./configure --localstatedir=/var and make again? <vivien>Sorry that’s a very stupid thing to debug, I don’t know much about your error <ngz>My next step is to run ./bootstrap and al. <ngz>Hmm. Same error, which is actually "error: failed to compile 'guix/build/clojure-build-system.scm'" <apteryx>if all else fail, 'git clean -xfdd' will put your checkout the same as if you'd just cloned it 