IRC channel logs
2023-12-27.log
back to list of logs
<cmiller>If my font does not support japanese characters, this should be no problem if I am on a website that loads a font for it anyways? <lilyp>Correct, but it doesn't hurt to install one that has Japanese characters <cmiller>If I have a system font that does not support emojis, but I have another one which does, will it load the missing emojis from the other font? <lilyp>unless you bork your fontconfig i'd say yes <rebiw>About the auto login issue, the problem that I had was the use of the --no-graphic argument. The tty used for login is tty <rebiw>ttyS0, not compatible with mingetty. <cmiller>Which build system is suited for a package that uses gradle (Java)? <rebiw>I just want to confirm that the auto login works fine with agetty and the --no-graphic option for guix system vm. Maybe a warning could be introduced in the guix cookbook, mingetty does not work for that use case. <cmiller>Should I package feature complete or minimalist? For example, I am currently working on an IRC client that has support for printing, I guess no one is going to use this. But there could be a user that requires that feature. <tsmish>Kabouik: wait, you missed my 300 word essay on why that wouldn't work and succedded? Impressive. I guess guix build system actually makes cmake pass flags to pkgconf that would make it work. <Kabouik>I did not miss it but I saw your essay after it worked and after you logged out. :0 <Kabouik>Has florhizome been online lately? The last activity I can see in this channel is like 11 months ago, and same for all git activity I could find. <recj>this is going to seem little, but is there a way to make python = python3 <recj>other than setting an alias <podiki>recj: use python-wrapper package insetad <podiki>sneek: later tell recj use python-wrapper instead <muradm>may some one look at #67657. thanks <jdlugosz963>Hi, i'm trying to run ungoogled-chromium, but i'm getting: Bus error. <recj>thank you podiki and sneek <sneek>recj, podiki says: use python-wrapper instead <tsmish>jdlugosz963: does the message say system bus? <tsmish>jdlugosz963: actually, can you post complete error message to paste.debian.org. I can run ungoogled-chromium in container even without any dbus-daemons running. <jdlugosz963>and im also getting this error whilie im trying to run discord with flatpak <tsmish>jdlugosz963: That has nothing to do with dbus. This is about invalid memory accesses (SIGBUS). Internet suggests moving chromium's folder. Can you try doing "mv ~/.config/chromium{,.bak}"? Also I assume you're on amd64 and not on some exotic architecture. <jdlugosz963>discord works too, i removed this directory ~/.var/app/com.discordapp.Discord/ and re-run flatpak command. <bdunahu>Hi, I am having difficulty testing out home containers on a new system install due to XDG_RUNTIME_DIR not existing. When manually echo the variable, it points to a directory that does exist and is already populated with files. My system configuration is lightly configured, though it still includes the services included in %desktop_services. Does anyone have an idea of how I might troubleshoot this? <bdunahu>It is the on-first-login script that I can't get to run, and it seems like it prevents me from fully testing my configuration. <tsmish>bdunahu: Can you post the configuration and error messages to paste.debian.net? $XDG_RUNTIME_DIR has a note in guix documentation about having logind running, but since the folder exists and you are trying to use containers it shouldn't apply to you. <bdunahu>elogind is started as part of %desktop services right? <tsmish>bdunahu: well, container recreates XDG_RUNTIME_DIR somewhere and on-first-login runs in container, so that may be the issue. <tsmish>bdunahu: yes, elogind-service-type is included in %desktop-services. <tsmish>bdunahu: there is something called home-xdg-base-directories-service-type in (gnu home services xdg) that creates xdg directories. <bdunahu>Sorry, is that service described in the Guix Manual (info guix)? If not, is there another source to find more about how to set it up? <tsmish>bdunahu: yeah, that will be the issue, intrestingly enough I have it in container, despite my configuration being very bare bones. <bdunahu>Do you mean you were able to get the configuration I sent you running in your own container? <tsmish>bdunahu: No, that was my configuration when I was helping somebody else fix their problems. But I can reproduce your problem. <tsmish>bdunahu: I think that service is internal and undocumented. It is part of home essential-services, so it should be injected in your configuration. <tsmish>bdunahu: In case you wonder how I found out about it, I have guix monorepo and just ripgrep through it. <Franciman>i'm in a guix shell containing glibc as dependency, how can i get the path of the library? <bdunahu>tsmish: Sorry, do you mean I simply need to include the (service home-xdg-base-directories) inside of the list of home services s-expression already included in my configuration? <tsmish>bdunahu: I checked list of services by running "(map (compose service-type-name service-kind) (home-environment-services (load "config.scm")))" in guix repl and home-xdg-base-directories is there, but it is after home-run-on-first-login.. <bdunahu>It does warn me of a duplicate definitions for XDG environment variables when I add home-xdg-base-directories... <tsmish>bdunahu: added it in my config and the problem still reappears <bdunahu>so your config has the same result as mine? <tsmish>bdunahu: this actually looks like a bug, I'll try reordering services so home-xdg-base-directories is placed before home-run-on-first-login. <bdunahu>I wouldn't be super surprised. My system was installed not even a day ago, so my environment and configs are still relatively untouched. The config file I gave you is mostly just what was generated with guix home import <tsmish>bdunahu: add (service home-shepherd-service-type) to services list. It will fix the problem. <tsmish>That's a little hacky, but shepherd needs to put it's socket in XDG_RUNTIME_DIR and in doing so will create it. <tsmish>That's why my configuration works. <tsmish>That does in fact look like a bug in "guix home container". It should create /run/user/<uid> since there is no elogind in container. <bdunahu>tsmish: Thank you, that seemed to work! <Franciman>i'm using the trivial-build-system, but inside the #:builder code when i use %build-inputs, it says unbound variable %build-inputs <efraim>trivial-build-system could be renamed the DIY build system. You have to do all the pieces by yourself <efraim>oh, or you've made a mistake between gexps and quasiquotes <jpoiret>Franciman: is texlab that hard to package? <jpoiret>it doesn't seem to have too many external dependencies <jpoiret>right, and that doesn't work with the crate importer? <Franciman>the latest texlab is not published on crates.io <jpoiret>i tried packaging wluma yesterday and it reminded me why I've chosen to avoid rust programs <Franciman>as soon as I have a bit of time, i'll try to properly package texlab <jpoiret>there's digestif as an alternative which is way easier to package <Franciman>fucking hell, i'd never heard of it lol. Thanks a lot! <jpoiret>i would even argue that it's the better implementation, since it uses the lua APIs of luatex iirc <jpoiret>imo an lsp server for latex is overkill :p <Franciman>but now i want to learn to package this binary, before switching to digestif <Franciman>eh jpoiret it is so useful for dealing with synctex <jpoiret>??? synctex is completely independent of LSP no? <jpoiret>ref autocompletion sure, although on emacs I think citar is enough <tsmish>Franciman: didn't mean that you should know about it, just remembered that I saw something for packaging binaries specifically. <jpoiret>tsmish, Franciman: packaging binaries is quite hard, I think the above would get you most of the way <tsmish>that repo is also kinda persona-non-grata <jpoiret>and since it's Rust you probably only need to patch the libc reference <jpoiret>if it's just for ref autocompletion digestif will be 100% enough <Franciman>i'm almost there, i just have to understand why patchelf returns 1, when running --set-interpreter <Franciman>jpoiret: re: synctex, yes it's totally independent <jpoiret>Franciman: there's always the issue that there's not enough space to patch the file, and patchelf doesn't support rewriting the whole binary just to get more space <Franciman>i should probably use invoke-error or something of that sort <jpoiret>invoke doesn't swallow stderr iirc, and patchelf should output some error message <Franciman>well, thanks for the help. I will try later to get it working. Now I'm curious about digestif :P <Franciman>jpoiret: thanks for digestif, it's so smooth. It's much smaller and also seems faster. At the cost of some featuers but he not a problem! <gabber>is it possible there is a discrepancy/bug WRT to $(guix deploy) and services? it seems $(guix deploy) didn't update my service definitions -- which was fixed when i re-flashed the $(guix system image) from the same definitions <tsmish>efraim: did you see bug#68017? It is about cargo-build-system. <davidl__>What package do I need to.install to get javac? Javacc didn't work <lilyp>davidl__: openjdk@JAVA_VERSION:jdk for JAVA_VERSION >= 9 <bdunahu>This may end up more of an emacs question, but has anyone had success with emacs 29.1 transparency with the guix way of setting up an exwm environment? The 'alpha-background frame parameter does nothing, yet the alpha parameter does. The only difference I can think of between this and my previous exwm setup is that emacs-exwm was installed as part of my system configuration, and not with package.el. <jpoiret>bdunahu: is the guix package's version the same as the package.el one? <bdunahu>guix search shows emacs-exwm v0.28, and M-x list-packages on a parabola system shows v0.28, so it seems so <jpoiret>you mention using it with package.el, was it with guix's emacs as well or parabola's? <bdunahu>I'm not sure if I understand what you mean. I don't have experience with managing emacs packages in guix yet. My previous system managed all of the emacs packages with package.el, which had working transparency. I copied my emacs configuration over to my guix system, though it seems like emacs-exwm exists as a system-wide package that is installed, so it is probably being used instead. I'm not sure if it is a problem with exwm, though <bdunahu>it is strange, because my compositor seems to be working <jpoiret>i'm asking if the proper behavior you observed was with guix or parabola's emacs <bdunahu>Yes, picom. It was working with the parabola system. I didn't have a login manager there. I am not really sure how the default gnome login manager included works (included in %desktop-services), though that might not be the issue either, because picom is starting upon login either way. <bdunahu>I just had the idea to restart my session with a blank emacs config and still does not work, so that seems to narrow it down further <efraim>tsmish: I can look into what it would take to propagate non cargo-inputs through the cargo-build-system <efraim>cuurently I'm moving a bunch of packages from crates-io to crates-vcs, crates-io is approaching 100k lines already <tsmish>efraim: This is not particularly pressing issue, it's just weird that you need to manually track non-cargo dependencies across the graph. <tsmish>The actual issue I had was with rust-bindgen definining clang as input and me having to define it again as an input to my package for no reason. <efraim>we're trying to make the rust stuff less of a special case. I've been at it so long I don't always notice what's out of place <tsmish>well, at least now there is a bug that people may be pointed to <efraim>I can't think of a good name for grouping windows and mac crates together or if I should do them separately <apoorv569>Why am I getting errors from a config that worked fine before I tried to split it up into a base config and a small per system config that I inherit from the base config? <tsmish>crates-useless.scm :) for all the crates that exist only to satisfy cargo and not used in runtime. Doesn't guix actually run on Macs though? But well, I know almost nothing about rust. <efraim>in theory we oculd cross compile to it <apoorv569>In the change per-system config I just inherit from base and change couple things, hostname, filesystem and I add a couple of extra package depending on the system like for laptops I want tlp for example and a couple of extra services if needed. <apoorv569>This is error I'm getting ATM, guix system: error: no target of type 'special-files' for service 'special-file-/usr/bin/env' <apoorv569>I know there are more error because if I comment this `special-files` service something else is upset. <Franciman>sorry jpoiret do you have first hand experience with digestif? <jpoiret>Franciman: a bit, haven't used it in a while, why? <Franciman>did you ever use it with multi-file projects? <jpoiret>tsmish: guix doesn't run on macos, no <jpoiret>Franciman: no, but the README says you can use a magic comment on the mail file to identify it <Franciman>hmm yes i am using it :P well seems like i have to try harder! <jpoiret>apoorv569: do you have the snippet of the per-system config that inherits? <jpoiret>Gooberpatrol66: you can run pipewire without guix home <jpoiret>just start pipewire, pipewire-pulse and wireplumber (after killing pulseaudio if it's running with pulseaudio --k) <apoorv569>There is a lot of commented code in there, basically all the commented code is suppose to be moved to the base config. <apoorv569>In the base config I don't have a `(services ` but rather a `(define-public base-system-services` which I am appening to in the per-system config. <apoorv569>I will remove all the commented code once the config works as expected. <gabber>i have issues packaging python's keyboard module (https://pypi.org/project/keyboard/) due to the fact that Guix's paths for (pypi-uri "keyboard" version) don't seem to match anything existing upstream. should i hard-code the URL referred to under "Download files" from the pypi website? <gabber>nvm, i get the sources from the repo's github <alexey`>I've got a question. My boot setup requires activation of an lvm group because the `/' is on a logical volume. Is it enough to add `mapped-devices' to the `initrd' to do this? <alexey`>As I understand, all configuration is done in the `config.scm', is that right? <gabber>i have little to no experience with your first question, but the manual has a whole section to Mapped Devices -- see 11.4 in the Reference Manual <jpoiret>alexey`: you shouldn't have to add anything, as long as the lvm volume is listed as a dependency of your root file system <jpoiret>also, if you have lvm+luks, you should order them in mapped-devices accordingly (luks *before* lvm) <ssouth>Building master fails for me right now with "ice-9/eval.scm:293:34: error: gnutls: unbound variable". Anyone else seeing this? <jpoiret>apoorv569: you commented out %base-services <alexey`>gabber, jpoiret: Thanks. I've followed the section on mapped devices and have them configured correctly (checked initrd init script and fsatb), but for some reasons, which I don't understand, logical volumes are inactive during boot process, so their uuids do not show up. <jpoiret>do you use multiple physical devices for the logical volume? <Franciman>I'm using a build system provided by a channel in my custom channel (and i have both channels added to the list of channels). But guix pull keeps saying that the module exporting the channel has no code <alexey`>No, it's one disk, one logical group, which has some logical volumes, but the `/gnu/store' is on a separate logical volume. <Franciman>i also tried declaring the channel dependency inside .guix-channel in my channel repo <jpoiret>alexey`: can you paste.debian.net your (mapped-devices ...) and (file-systems ...) sections? redacting uuids of course <apoorv569>jpoiret: Ah! Is that needed? Let me see what services are in the `base-services` list.. <jpoiret>Franciman: you need to declare the channel dependency inside .guix-channel, yes. Make sure you follow the syntax described in "(guix) Declaring Channel Dependencies" <jpoiret>apoorv569: the special-files service that was in the error above is included in there <jpoiret>ssouth: hm, seems like yet another issue with the libgit2-managed checkout... <apoorv569>jpoiret: Just looked at base-services seems like pretty important stuff in there.. <gabber>is it possible to mount usb thumbdrives to a pre-defined mount point? e.g. /media <davidl__>So I'm trying to use buildozer on guix (installed via pip), and at first I was getting an error about some aidl binary not existing, but I checked it and it tried to use /lib/ld-linux-64.so.2 or something so I patchelfed it with the x86_64 version but that doesn't work. Any ideas how to fix this? I'm just trying to build an apk file but in the android SDK there's some binary or binaries that need 32bit libs. <jpoiret>can you go into ~/.cache/guix/checkouts/, find the checkout corresponding to guix itself (should contain the gnu and guix directories), then type `git status` and report back? <jpoiret>davidl__: i think the "installed via pip" part is pretty important <ssouth>jpoiret: I see two folders there. In the one that appears to contain a complete copy of the Guix source tree: <apoorv569>Is `(cons*` and `(append (list ` same thing? <ssouth>Your branch is behind 'origin/master' by 634 commits, and can be fast-forwarded. <ssouth>nothing to commit, working tree clean <jpoiret>can you do `git merge --ff-only`, then `git clean -dfx`and try again? <ssouth>jpoiret: Sure---this is from within the subfolder of .cache/guix/checkouts, yes? <jpoiret>yes (be careful not to do it in a random git repo, that would remove all uncommitted changes) <apoorv569>Ah! Yes all errors gone by adding back `%base-services` <ssouth>jpoiret: Done. "git status" now reports "Your branch is up to date with 'origin/master'." <jpoiret>just the fact that your master branch is behind after a `guix pull` is weird <ssouth>I'll try building again from my work folder.. <jpoiret>guix pull should be cwd-agnostic though <jpoiret>apoorv569: (cons* x y ... l) is equivalent to (cons x (cons y (... l))) <ssouth>jpoiret: I'm not running "guix pull", I'm building the source tree from git. <jpoiret>no, i was thinking of `guix pull` instead <jpoiret>what i was saying about your .cache/guix/checkouts/ folder is completely moot :p <ssouth>Ah. So it is something on my system then. <jpoiret>your commit is 756ba0429e84ee0f8ce30484439b78c00c61d286, right? <apoorv569>jpoiret: I see. But it seems to work regardless if I do `(cons*` of `(append (list`? Does the procedure accepts both in this case? <ssouth>Very strange. I've certainly built guix on this machine before without issues so it seems something has changed. <jpoiret>what procedure? both of these would compute the same list <jpoiret>but cons* is, imo, more idiomatic if you're just adding elements to the head of a list <ssouth>jpoiret: Thanks for the help in any case. <jpoiret>ssouth: you can do `make clean-go` and try again <jpoiret>that'll rebuild all the go files but it's better to start from a clean slate since guile has no dependency tracking <apoorv569>`(services (cons * %base-services))` and `(services (append (list .. ) %base-services))` are same thing then? <ssouth>jpoiret: I've just run "make distclean" and am trying again. Previously I'drun "git clean -fxd" so I doubt it's an issue with outdated artifacts. <ssouth>Incidentally it gets only to "[ 12%] LOAD guix/tests.scm", without trying to build any package modules. <jpoiret>do you have an idea what file raises this error? <ssouth>Not really. It's not guix/tests.scm. Presumably something else within the guix module but I haven't tracked it down yet. <ssouth>It would be nice if Guile and/or the build process gave more clues as to where the fault actually lies... <jpoiret>it wouldn't be fun if the build system reported errors properly <jpoiret>well, i gotta run, but maybe we have a problem in master and it's my incremental compilation that hasn't detected it yet :p. I should try from a fresh checkout <ssouth>jpoiret: Again, thanks for the help. I'll see if I can track down what the problem is. Could very well be just something on my end. <ssouth>Yep, same problem. What is going on. <alexey`>One thing I noticed is that grub needs tweaking too. # Set 'root' to the partition that contains /gnu/store. -- this is false in my case. <alexey`>Hm, interesting. GNU Guix system (by default ?) puts initrd to the `/gnu/store`? <apoorv569>jpoiret: I was able to reconfigure my system just fine. There is one small issue though, I have `lightdm-service-type` defined in base config as I would like it on each system I inherit this from. <apoorv569>And the lightdm service has this `(extra-config (list %xorg-libinput-config))))` now libinput config is only needed on my laptop for touchpad config. <apoorv569>Now I can move the `(define %xorg-libinput-config` var in base instead and it would work.. but that defeats the point of base and per-system config. <apoorv569>Franciman: guix has a pipewire home service now? <apoorv569>I don't like doing `pw-jack APP` from terminal <gabber>i have troubles mounting the filesystem referred to by its device name "/dev/sda1" to a specific mount-mount. there is nothing suspicious in the logs -- what could be the issue? https://termbin.com/mm03 <- this is the file-system block of my operating-system <ssouth>gabber: What's the error message you see? "sudo mount /data" should work I believe. <ssouth>I'm not sure this is something you want to put in your operating-system definition though, if your intention is to mount the SD card only occasionally. <jpoiret>gabber: did you check whether /etc/fstab does contain that entry? <jpoiret>i'll `make clean-go` and see for myself <ssouth>jpoiret: No, although (some) older commits build just fine. I'm bisecting the source tree right now trying to see where the problem began. <jpoiret>alright, i'm getting the same as you :) <ssouth>jpoiret: 7578c25b934a9a4550d6d47a75202c66556b8d47 <gabber>ssouth: yes, manually mounting worked and jpoiret: yes, i found the entry in /etc/fstab. gotta test if it (still) doesn't work <gabber>no, for some reason it doesn't mount automatically <gabber>after a $(mount -a) everything is mounted correctly <gabber>after boot /data was not mounted from /dev/sda1 - after typing and executing `mount -a` manually /data was mounted from /dev/sda1 <gabber>i somewhat expect guix to mount all file-systems listen in the relevant field in (operating-system) to mount? <jpoiret>do you see a shepherd service related to it? <ssouth>gabber: If this is a plug-in SD-card reader (like an SD-to-USB adapter) I wonder if the USB device had not yet been detected at boot by the time the filesystems were being mounted. <jpoiret>auto-mounting on boot is handled by shepherd services, so you should see it <jpoiret>ssouth: it's probably a matter of cyclic dependency chain which is going to be a pain to debug <gabber>jpoiret: i can indeed see the shepherd service (status started) - restarting it just rebooted the system <gabber>fsck checks the device during boot, so it's visible <jpoiret>it should've brought down your sessions at least <gabber>and yes, it's a pendrive, a so-called USB stick <jpoiret>if you want auto-mount for removable media i'd suggest udisks2 instead <ssouth>gabber: I would suggest reading through the system log then to see when exactly the device was detected. <gabber>jpoiret: thanks for the hint! i'll give that a try <ssouth>Ah, but an auto-mount daemon would make more sense anyway. <gabber>is there more (complete) documentation than the short passage in the manual's udisks-service-type section? <jpoiret>huh. guix/tests.scm has a lot of transitive dependencies <ssouth>So perhaps it is that file then. <jpoiret>the dependency situation in Guix is terrible <jpoiret>it was taking a long time to load so i was kind of expecting that <ssouth>jpoiret: Incidentally commit 766822aa87b94eacb3c49fd68261ae4ce9088a56 is also good. <ssouth>Looks like Guix doesn't really accept any configuration options for the udisks service so a simple "(service udisks-service-type)" should suffice. <jpoiret>ssouth: i think i know what's going on (and it's not good that it keeps happening) <ssouth>gabber: Take my suggestion with a grain of salt; udisks relies on DBus so you are probably better off adding %desktop-services to your services configuration, and perhaps filtering from it services you don't want. <gabber>ssouth: thanks for the heads up! <jpoiret>basically, (gnu packages tor) is in the huge cyclic dependency graph that (guix tests) depends on. one has to assume that while (gnu packages tls) is being loaded, the #:use-modules at the top causes (gnu packages tor) to be loaded before gnutls is defined <jpoiret>but with 756ba0429e84ee0f8ce30484439b78c00c61d286 (first bad commit), that package loads (gnu packages browser-extensions), which *while loading* tries to refer to gnutls <jpoiret>(create cyclic dependencies that don't show up immediately) <jpoiret>also it's a problem that guix/tests.scm pulls in all the gnu/packages/ files before they are compiled <jpoiret>it seems to be working, i'll test some more and then push <jpoiret>funnily enough, that problem doesn't happen with guix pull :) it's probably because of the order the files are compiled in <jpoiret>yeah, guix/tests.scm is compiled in guix-extras, after the packages <gabber>if i understand correctly udisks-service-type just provides the user-space program udisksctl which is able to mount the disk -- i can also just let my program (which is run as root) do a "mount -a" at start <jpoiret>it adds a D-Bus system daemon that mounts removable drives as they are detected <jpoiret>then you can interact with it using udisksctl or other client applications, I use udiskie <gabber>this is unfortunately not what happens. it shows the disk but does not auto-mount -- unless i execute $(udisksctl mount /dev/sda1) <jpoiret>security warning: automatically mounting fs's is considered unsafe because maliciously crafted file systems might corrupt your kernel <jpoiret>you might need to enable auto-mounting using udisksctl <jpoiret>huh, no, apparently auto-mounting is not managed by udisks itself but by your client application. still, udiskie does that <jpoiret>once it receives a notification from udisks that there is a new drive, it can decide to auto-mount or not <gabber>so i just add udiskie... to the os-configuration? <gabber>ACTION wants to share the information that i'm working on an "embedded" type system, not a user-internet interface kind <jpoiret>ah, you want it to work without a user being logged in necessarily, right? <gabber>and i don't care about the exact nature of the drive <jpoiret>and the removable drive is not truly *removable*, right? always plugged in? <gabber>to be removed when the system is powered down <jpoiret>mhm. Then the initial (file-system ...) thing might be enough. <jpoiret>sorry to have lead you on a stray path <gabber>no problem! thanks for the input. i'll sloppily add a $(mount -a) to my application code for time is running out <ssouth>jpoiret: Wonderful, thanks so much. I'll try it right now. <ssouth>jpoiret: Looking at the change I'm baffled at how you were able to track that down so quickly. <jpoiret>it's not my first dependency cycle rodea <jpoiret>allowing cyclic dependencies is an unfortunate design decision and we're now paying its price <jpoiret>most people aren't aware of what they might cause and don't test enough (although testing all possible scenarios is *really* complicated, since we have multiple ways of building guix that aren't equivalent) <gabber>isn't that very closely related to lazy evaluation and/or just-in-time compilation? <mirai>gabber: don't forget to set mount? to #f <jpoiret>i wouldn't say closely, but rather that lazy evaluation (thunks in guile parlance) along with lazy variable lookup (a true *nightmare*) lets us get away with it <jpoiret>mirai: i think they do want it to auto mount <gabber>yes, i'd love that mount to happen automagically <mirai>jpoiret: well, that's gonna result in a boot hang if that disk happens to be missing <gabber>mirai: this wouldn't be too tragic. it's a data acquisition application that stores the data on the USB drive -> no drive, no acquisition possible <jpoiret>guix on an embedded device though, pretty daring aren't we? :p <gabber>though i currently have #:mount-may-fail? set to #t (so i can still log in and debug) <jpoiret>although I guess mothacehe has some experience with it <gabber>jpoiret: it seems to be one of the few ways to ensure reproducibility and relieves me from the pain of manually setting up Raspbian each time i switch SD cards or hardware or ... <gabber>also "embedded" has become super-sized in the recent years. many platforms often used in so-called embedded (or IoT) applications could also be used as (not too powerful) desktop setups <ssouth>jpoiret: The build has made it past "LOAD guix/tests.scm" so it seems we are out of the woods here. <ssouth>Many thanks for the (speedy!) fix. <jpoiret>side note: on online chats like IRC, you probably want to always ask the question directly and not ask if you can ask the question, that way if you don't get an answer before leaving people would still be able to see your question :) <jpoiret>PotentialUser-27: do you have a GPU/what is your CPU's dGPU? <jpoiret>it's possible that it requires non-free firmware, and when the kernel wants to initialize modesetting it tries to load firmware files which are not available in Linux Libre <PotentialUser-27>However, for some reason, it appears that Guix is attempting to load Radeon on boot <jpoiret>mhm. You can in the meantime try to boot with the nomodeset argument: in GRUB, while hovering over the proper boot option, press 'e', and add nomodeset to the `linux` line <jpoiret>oh, i guess you already know how to add kernel parameters <jpoiret>that should at least let the server boot with a working display <apoorv569>I moved the lightdm-service-type of per-system for now.. <PotentialUser-27>I see that AMD drivers are being modprobed in the boot config for some reason, so I'm going to try to remove that. <PotentialUser-27>The last message always seems to be "radeonfb: Monitor 2 type no found", what does this mean? <PotentialUser-27>Anyways, I'm re-flashing my USB now, just to rule out the flashing process as a point-of-failure. <jpoiret>You can try blacklisting the module using module_blacklist=radeonfb (if that's the one causing the problem) <PotentialUser-27>jpoiret: Yes, I'll try that if the issue persists. I have to wait for my USB flashing to finish first, though (Rufus takes a while). <euouae>Hello how can I make my channels part of my system configuration? <euouae>e.g. if I have a custom kernel to be pulled from my channel <euouae>right now it sits on my ~/.config/guix/channels.scm but I think there's a way I can make it part of /etc/config.scm <PotentialUser-27>jpoiret: Thank you for the help, the fix seems to have worked! However, I would like to know what the underlying issue is, since this does not seem like a permanent fix. Well, unless disabling the module is required, that is. <jpoiret>euouae: you can add the file at /etc/channels.scm (eg. through etc-service-type) but you also need to not have ~/.config/guix/channels.scm <euouae>what do you mean I need to not have that jpoiret? Why would something under ~/.config affect system configuration? <euouae>ACTION looks into etc-service-type <euouae>so if I had something under /etc/channels.scm, how would I make use of it? To be frank, I thought I just had to set %default-channels to some value *inside* /etc/config.scm <euouae>(or do you mean guix system reconfigure /etc/config.scm -C /etc/channels.scm or similar? Definitely provenance-service-type also seems interesting. <PotentialUser-27>jpoiret: Nevermind, it seems that the Guix installer is aware that my graphics hardware may not work. It's provided me with instructions on a permanent fix, so I will have to say bye now. <elevenkb>Does anyone know how to get offloads to no build from source? <PotentialUser-27>It turns out that the ethernet devices my server uses (Broadcom NetXtreme II BCM5709) is non-free, and cannot be used for GNU Guix. However, upon trying to look for any drivers, I found that the Linux driver 'bnx2' supports it. Does this driver load proprietary blobs? I am unfortunately not able to read C code much, or at all, really. <elevenkb>or maybe I'm wrong about how they might need me to build stuff from source? <euouae>can someone help me with full disk encryption? I want a simple setup but I can't figure out how to proceed <euouae>Â I've made the concession that I'll be using pbkdf2 but I still can't understand how to set it up <Franciman>do you use guix home to keep track of your dotfiles? If so, is there any example on how to do it? <euouae>Do I format /dev/sda with just 1 partition? Then encrypt it with cryptsetup? And then? <euouae>Franciman: the manual shows you an example where you can create a home configuration from your current configuration <euouae>yes but you can see how it's done and then you can add more files in your guix-config <euouae>it also tells you how to test the home configuration in a throwaway container <Franciman>i'm sorry i can't help with your issue. Because you've been very helpful for me! <euouae>Franciman: you're welcome. The home-*-service-type will tell you how it uses your files to make up your home configuration <euouae>there are general files you can dump under your $HOME with a service and there's XDG config files you can dump under $HOME/.config with another service <euouae>sigh I don't know. I'll just have /boot unencryupted for now <Franciman>sorry euouae, after declaring the home service for XDG config, do i have to manually copy the rc files in the proper location? <Franciman>btw, euouae the default installer allows you to encrypt the full disk <euouae>all your configuration files should be at the appropriate places inside inside your guix-config/ <euouae>I can't use the default installer because it won't run <euouae>it doesn't want to run because I have a proprietary gpu <euouae>so I have to use the manual shell installation instead <euouae>Franciman: and there's no auto-discovery: every config file should be declared in the home configuration .scm file <Franciman>oh damn, but i think you can define your own installer, read about that well known dark side webside <euouae>I don't undeerstand what you mean <euouae>you can certainly "autodiscover" the config files with some guile code if you know how to write guile <euouae>jpoiret: do you know if there is some encryption scheme that works with guix? <euouae>I can't figure it out no matter what I tryu <euouae>I'll go with the kexec route and see if I can figure it out <euouae>f*** I just fat-fingered my other partition and I now need to fix debian too <benwr>ok I'm still struggling a bit with per-user shepherd on Guix System. Trying to run it as a non-privileged user, I get "No such file or directory: /run/user/1000/shepherd". Fair enough; indeed /run/user doesn't exist. What's the right way to cause it to be there? <benwr>ah, the manual says it will look in XDG_RUNTIME_DIR/shepherd when that's set. Is there a preferred setting for that? or a preferred place to set it? <benwr>I see I probably need to enable elogind