IRC channel logs
2023-01-25.log
back to list of logs
<ecbrown>guix system lets you change services and even the kernel. guix itself is largely userland <gnucode>ecbrown: I think it would be interesting if guix system become the first userland to support 4+ kernels. <gnucode>but it seems like guix is tied pretty tightly to glibc. <mirai>it'd be interesting to see it happen <apteryx>rekado: do you mean, other than fold-packages? <greenfork>Does Guix System expect a particular partition scheme? When I try to manually change everything to a single partition, it doesn't work. But with a default scheme of /dev/sda1 - 2MB boot, /dev/sda2 - swap and /dev/sda3 - root, everything works <kramento>I'm trying to package (locally/privately) a dotnet pre-built tar ball so that I can have guix manage it instead of installing it in opt and setting env variables manually. But is there a good way to get GUIX to add an /opt/PACKAGE directory to the PATH? The info page about search paths has clean instructions on what to do with environment variables like DOTNET_ROOT in this case but I also want to add $DOTNET_ROOT to the path. If set <kramento>PATH in the native-search-paths field will guix to the right thing (concatenate with the others paths it manages)? <PotentialUser-31>Hey, I need to make an OS config file that does not replace the current uboot environment, is that possible? <PotentialUser-31>Okay turns out I don't got it, it seems like for M1 you need to build uboot from scratch, but I'm not quite sure how to then expose that to the bootloader system configuration in Guile. <elevenkb>Has there been a discussion about upgrading =emacs-minimal= to a more recent version? <unmatched-paren>i sent an email to the devel mailing list regarding my difficulties with writing the monads blog post <rekado>apteryx: yes, I mean with “guix graph” <bumble[m]>hey @unmatched-paren I'm interested to try and debug the wlgreet blinking-cursor issue on my machine if you would advise initial steps for me to follow in troubleshooting <bumble[m]>I have to sleep soon but if you have ideas on where to start <Guest647>I am having a problem with getting common lisp, sbcl, to work. It keeps wanting libc-3.4 andI have 33. There seems to be a patch for this but it can't find the guix version. (I have guix a package manage under a ubuntu 22.04 server setup) <bumble[m]>feel free any time to message me and I will begin following your direction <unmatched-paren>bumble[m]: okay, cool. i'm afraid i have no idea where to start though :( <bumble[m]>maybe not nownow but I will get around to it at least during the weekend <bumble[m]>I would normally jump in and try to solve, but I don't know guile or guix very well and the steps to setting up the user and all with all of the unknowns together make things very overwhelming <Guest647>So there is a problem with mixing lisp code gotten from guix and code gotten with quicklisp. <Guest647>In cl+ssl I could load the cl+ssl/config and the set the variable to the correct .so files then load cl+ssl. However no such option is available for cl-cffi-gtk. <Guest647>I am running on a raspi 4, so aarch_64 (thumb32 instr. set) <seninha>Hi, the reference manual mentions an /etc/configuration/desktop.scm example configuration file on the installation image. I'm using the QEMU image, and the /etc/configuration directory is not available there. Where can I find those files (either on the QEMU image or on the Web)? <nckx>I think those are the same as the .tmpl files in gnu/system/examples in the Guix git repository. <nckx>greenfork: No, but your machine might. Like that tiny 'boot' partition you mention sounds like a 'BIOS boot' area, required by GRUB to boot from a GPT-partitioned device on non-UEFI systems. You can't just drop it (although you can comfortably fit it in the <1MiB alignment gap before the first real partition if you really refuse to sacrifice even a KiB—like me :-) <nckx>Also the visual difference between 👆 and the 🖕 I very nearly sent is criminally small. In case it ever happens. <greenfork>nckx: Yes, I had a similar idea about this Boot partition. Right now I'm at a stage where I can't manually install the system following all the instructions even after I did the partitioning via an interactive installation. Really weird, I'm trying to find out what I'm doing differently <nckx>Any details? (Don't know if I'll be much help on fone but I'll try.) <greenfork>nckx: `guix system init /mnt/etc/config.scm /mnt` reports all good, after that I managed to get infinite reboot or rescue GRUB mode with the error that normal.mod is not found. I think I will try a couple more attempts and try to post my steps on a mailing list <greenfork>I don't really like the prospect of trying to explain a complicated topic of installing a system, too many things can go wrong and maybe not everyone will be willing to look into it. But maybe I will be lucky and it will just work during my attempts to document it :) <nckx>Hmm. Sorry for the obvious question, but you did adjust your file-systems list, right? A /boot that's just a subdirectory of / should absolutely work. <nckx>Even if / is not ext4/btrfs, but just in case: is it? <greenfork>Yes, I have the simplest layout with a single root / in the file-systems configuration <nckx>There were some bugs with subvols but those are fixed and probably not what you mean my simplest anyway :-) <greenfork>I don't use any btrfs configs, no :) Just plain and simple <nckx>If you do mail help-guix at gnu dot org, include your system.scm and fdisk -l output. <hjckr>hi folks, what's the best place to put in additional channels systemwide, such as nonguix/nongnu ? <nckx>Sounds like you're describing /etc/guix/channels.scm. It is not cumulative with ~/.config/guix/channels.scm, but users who want to amend the defaults could explicitly load it. <hjckr>ok, I will add in there, thanks, looks like a much better place than /root/.config/guix/ <nckx>I guess it depends on your workflow, but most people won't use (or even have) a root guix, so I agree. <ham5urg>The Guix manual describes a manual LVM installation. But I can't find a hint to toggle the partition to Linux LVM (30). Is this not needed? <tricon>I wonder if a ~/.config/guix/channels.scm skeleton for new users is merited. <weidtn>I am running guix on a manjaro system. I think I have two different glibc versions or something. When running stuff like firefox installed with pacman i get `symbol lookup error: /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE`. The one installed by guix works. <nckx>This has been reported a lot (…lately? I'm not sure, could be confirmation bias.) <nckx>Skeletons are icky but sometimes necessary. But if they are not, why deal with the ick? <apteryx>when I add "CFLAGS=-Og" (or -O0) to the configure-flags of rpm locally, the debug symbols are no longer usable it seems: No debugging symbols found in /gnu/store/aclhrhdrz06h746gjvq8sriv8rfi7ann-profile/lib/debug//gnu/store/37d4rkwydzp3gmm80hy9x7rfvnrzkmc0-rpm-4.18.0/bin/rpm.debug. Why could that be? <tricon>nckx: They do seem to become a maintenance sinkhole in the long-term. <nckx>apteryx: And that file exists? <nckx>That would be the weird part. <nckx>apteryx: Could you share your diff? <nckx>Never mind, I can reproduce it with just that. <nckx>Thanks. That's exactly the same. <apteryx>surprisingly the debug symbols output is smaller with -Og compared to the default <apteryx>and then, to debug, I use: ~/src/guix/pre-inst-env guix shell rpm rpm:debug gdb -- rpm --debug --query --dump /gnu/store/13b9qvm1glf3lnd9ss5dyyw2j396iivb-hello-rpm-pack.rpm (or any rpm you can get your hands on) <nckx>I just used ‘gdb rpm ^D’ which is enough to trigger the difference in output. <nckx>And there is more code in the ‘good’ file but no header/format differences I'm aware of… :-S <nckx>Weirder than I expected! <apteryx>I'll try asking the GDB wizards in #gdb <nckx>So -Og *mostly* implies -O1, while we're building rpm with ‘-O2 -g’ by default. I'll try ‘-O1 -g’. <apteryx>ah! I seem to recally civodul mentioning that a common gotcha in guix is overriding CFLAGS and forgetting to keep '-g' <apteryx>but i failed to see where that -g comes from? <nckx>Yeah, so I'm running a build with -O1 and -Og and explicit -g, for the same hunch^Wreason. <apteryx>scanning gnu.scm or gnu-build-system.scm for '-g' yields nothing <apteryx>ah, that's the default in Autotools, right? <nckx>apteryx: Hell if I know. <nckx>Hand in your Bash licence right now. <nckx>Indeed: ‘Note that -Og does not imply -g, it simply disables optimizations that may interfere with debugging.’ (Gentoo Wiki) (We knew, but now it's official) (Oh wait no it's the Gentoo Wiki) (Still.) <apteryx>can't find a ref to -O1 in autoconf or automake manuals <nckx>I'm not as familiar with a{c,m} as you probably are, and I've definitely added -g to Guix-packaged non-autotools packages before, so I do think it's not ‘us’. <civodul>yeah Autoconf-generated configure defaults to CFLAGS="-O2 -g" <apteryx>that's not documented anywhere, is it? <civodul>so it you run ./configure CFLAGS="-xyz", then you lose "-O2 -g" <civodul>yeah, it's a bit of a hack, that's why it wasn't documented :-) <nckx>That's not how it works. I am a proud member of the million monkeys club and I typed it once and it worked, so it's API. <nckx>First bug I found in it \o/ <nckx>(Who needs fuzzers when you have users.) <rekado>I’m a little dissatisfied with the python- prefix <rekado>there are many bioinfo tools that are dual use: they offer executables but they can also be imported as modules <rekado>in order to support the use as a set of modules we propagate inputs and use the python- prefix <rekado>I wonder if there’s something we could do about this… <apteryx>you could split the packages to have the python-something as the library, and just 'something' as the tool, but that's micro-management <rekado>it looks like we’re overlooking a pattern, but I can’t identify it <apteryx>is your ultimate concern closure size, or something else? <rekado>I find propagated inputs concerning <rekado>they force us to harmonize the whole world of Python packages <rekado>variable names like python-*-next give me nightmares; they are bound to cause problems when someone installs a package using the variant without “-next” <apteryx>right; -next shouldn't be propagated ideally <rekado>and the only reason for all of that is that we make these packages available as libraries <rekado>even if people would want to merely use them as executables <rekado>I don’t have a proposal or a solution <rekado>but I wonder if there’s something in the Python load path handling that could be improved to make propagation unnecessary <apteryx>hartmut had experimented with virtualenv in the past, see guix-devel <apteryx>It was working for individual packages, but I think it caused problems when composing packages. <ham5urg>Is there a way to get output when guix system init /mnt/etc/config.scm /mnt is working? <PurpleSym>rekado: I experimented with embedding Python dependency paths into the packages themselves a while ago. That would get rid of GUIX_PYTHONPATH. <nckx>ham5urg: What do you get now? <ham5urg>nckx, just a newline with a blinking cursor. <PurpleSym>I’ll have a look at it again when I’m done with wip-haskell. Still trying to figure out how to decrease closure sizes. <rekado>we have the same problem in R and Guile, but it’s less annoying because those packages are much more likely to be used primarily as libraries <rekado>PurpleSym: last time I worked on reducing the pandoc closure I had to cut a lot of corners and do a static build. <nckx>ham5urg: You can unleash a lot of spam with ‘--verbosity=9 --debug=9’ (or lower, saner values) but this sounds like infinite recursion, which those won't catch AFAIK. <nckx>It would catch network hangs though. Worth a shot. <PurpleSym>Yeah, I’ve seen pandoc, rekado. Not pretty. I’m currently running builds that put everything into a :runtime output and then selectively move things that are not needed at runtime back to :out (adjusting the config files to point to the proper directories again), but only at compile-time. <PurpleSym>Let’s see if I can get a) a dynamic build of pandoc like this and b) if it’s reasonably small. <ham5urg>Exist a infinite recursion due to config.scm? <apteryx>rekado: with Guile being compiled to .go, which is in the ELF format, it seems should be "easy" to add extra entries to that, such as a new RUNPATH? :-) <apteryx>ACTION continues work on the rpm generator, which has entered a phase that looks more like reverse engineering <civodul>apteryx: oh, that's for 'guix pack'? <civodul>did anyone try to abuse Cuirass for CI of a non-Guix project? <janneke>civodul: yeah, but that was some time ago <janneke>hmm, there used to be a tests/hello-git.scm but that has been removed <janneke>it was moved to examples/hello-git.scm, and later removed...dunno <janneke>ACTION remembers adding patches for Cuirass to support tracking git <civodul>what i'd try is using a 'manifest' spec, and in that spec i'd have a package whose source is (local-file ".") or something like that <elb>what is the preferred way to write things like python scripts that need shebang lines without using FHS compatibility? <janneke>ACTION usually has something like that in guix.scm <elb>I'm trying to use a container shell to run some code that ordinarily runs on a FHS system, and it's full of things like /usr/bin/python3 and /usr/bin/awk -f <janneke>i'm keeping a proper released package description in guix/git/<package>.scm, and in toplevel guix.scm inherit from that and use se source (local-file ".") trick <elb>I can get them to work with -F, but that prevents me from using a manifest-controlled profile directly, and requires me to instead use the manifest; not a huge deal, but it means the manifest-declared packages track the current state of the guix system, and things like rollback are trickier <apteryx>civodul: yes, for 'guix pack -f rpm' <apteryx>currently at error: /gnu/store/5qzl5s6qqmqihfj4d69alxh8fasm7vln-hello-rpm-pack.rpm: Header SHA256 digest: BAD (header tag 273: invalid size 63), eh <hjckr>folks, is it possible to pass btrfs fs flag: discard=async via the filesystem module, seems like the validation is not successful? <nckx>Yes. It's not a flag, but an option. <nckx>apteryx: Prefer open standards instead :) <hjckr>nckx, thanks, let me try this instead <apteryx>re rpm, I now only get: warning: RPM v3 packages are deprecated: hello-2.12.1-0.x86_64 <apteryx>and --query --xsl shows the metadata correctly <hjckr>mirai, thanks, why options is a string and flags is something else '( ? <mirai>the options field can be a string or an alist if you prefer those <nckx>hjckr: Because flags a set from a known list of valid [C] bitflags, while options are free-form strings interpreted by the kernel. <mirai>you'll have to read the manpage for fstab to understand the differences <hjckr>so flags will get to be translated, ie no-atime becomes noatime, there is a mapping somewhere, right ? <hjckr>and options is used for those that do not already have their mappings pre-set <devmsv>hi, is it possible to apply "Installing Guix on a Cluster" for Guix Systems? how so? what should I take into consideration? or better stick to Guix deploy for that kind of setup? what about sharing the profiles of users in the different machines? <jackhill>Am I missing something: guile-gnutls's gnutls-version proc reports 3.7.2, but its graph shows it using gnutls@3.7.7. So which is it? Is guile-gnutls using a buggy gnutls version? https://paste.debian.net/1268442/ <mirai>one is the record-type, the other is a compact shorthand for defining entries. <nckx>(Cleverness that does not appear to be working entirely as intended.) <nckx>ACTION will answer after testing a -> gnutls-latest patch :-) <civodul>anyway it did fix cross-compilation at the time <civodul>but hmm, it should be gnutls-latest for both <nckx>I'll test first, whether it causes any weirdness. <nckx>Maybe past you was very clever? :) <nckx>Well, if it works, I'll push the fix. <civodul>we still need both, but they both need to be gnutls-latest <civodul>devmsv: hi! i talked to people running running a Guix System cluster, but they rely on various tricks not in Guix yet <civodul>but yeah, the goal is to eventually have the same section for Guix System <nckx>(gnutls-version) => "3.7.7" <old>Anybody using the gnome desktop and make fractional scaling work? <devmsv>civodul: cool count with me on that! I have started working for a company which have some HPC (but not clustered) and I'm working on moving those machines to Guix System <devmsv>That's also why I have been trying to pack node project so we can use it to CI and CD with Guix. Unfortunately I don't know enough node.js nor guile, yet... <jackhill>I guess we can go ahead and update gnutls-next to 3.7.8. <jackhill>that leaves open the question why so many packages depend on gnutls (not next) <apteryx>it's disappointing that the last Guix release wasn't covered by Phoronix; they used to <apteryx>I had even ping'd them, albeit some 3 days later <lechner>apteryx / that may say more about phoronix than about guix <civodul>yeah that release had very little coverage <aadcg>I've sucesfully installed Guix system 1.4.0 following the graphical installation. However, when I booted into the system, it's stuck in tt0 and nothing happens... I can't go to anothe tty also. Any ideas? How can I debug it? <aadcg>I have the feeling that X is not being started (and thus gdm doesn't start), since the printed images don't show anything about it <aadcg>printed log messages I meant, not images <apteryx>try appending "nomodeset" to the linux kernel command line in GRUB <apteryx>I think the installer use it, so if it worked there, chances are it's that <aadcg>I was able to boot when I added "modprobe.blacklist=amdgpu" <apteryx>so yes your 125,000+ lines of code amdgpu free software graphic drivers probably requires the magic non-free proprietary blobs to be there to even give you video; a classic unchanged since 2015 it seems <aadcg>I can also report another difficulty I found during graphical installation <aadcg>I have a wired internet connection and the installer was stubborn and kept telling me that there's no internet connection. I went through Guix's sources and found out that creating file /tmp/installer-assume-online simulates it <aadcg>that was the only way I found to trick it... and indeed, then the installer was able to download all of the substitutes <aadcg>I wonder why the installer decided I had no internet connection though... <younder>Do you have a wireless connection which is not set up? <apteryx>perhaps the installer should first try to reach gnu.org before trying anything at all <aadcg>I have a wired connection. I also have a wireless card (that obviously didn't work due to the lack of the blobs) <younder>Normally you select connection during installation. <aadcg>in my case it automatically picked Wired connection <dthompson>any reason why we shouldn't update guile-3.0-latest to 3.0.9 now? <elb>OK; next Python trouble (more critical than the question about shebangs above): Python 3 aiohttp cannot verify certificates, does anyone know why that might be, and if I'm just missing a package? <elb>my guix environment has nss-certs installed, but that seems to be it <younder>A lot of applications seem to be confused by the non-standard directories guix uses. <younder>In common lisp I had problems with quicklisp which downloads source. It can't find glibc. Simulary witch Rust cargo and haskell. <younder>Sure a lot of these libs can be downloaded with guix which patches these problems but it remains a problem. <elb>guix containers with -F solve that in some cases <elb>try running `guix shell --container --network -F`, and then running your command from inside that <elb>you might have to include the offended packages in the list of packages installed for that container, or the offending packages, one <elb>-f is short for --emulate-fhs or something, it will give you a /bin and /lib and a few other directories that look like a "normal" Linux distribution <elb>it fixes some things for me, it doesn't fix others <elb>it solves shebang lines for many programs <lechner>did you source the new profile after installing quicklisp? <younder>I am currently on a raspi 4. It can't do a full guix installation (yes0 So I am running it on a Ubuntu 22.04 server and am using guix as a package manager. <younder>I have installed in a virtual machine on my workstation under qemu. <younder>So no, I'm not fully comitted. I spendt a fortune on 2 Nvidia Titan V's and they need the NVIDIA drivers. <younder>lecner: what do you mean source the net profile? <Maya[m]1><akirakyle> "Anyone know how to url-fetch a..." <- do you mean inside a build? or.. <akirakyle>Maya[m]1: Yeah getting an origin record from a lzip <nckx>akirakyle: There seems to be something missing from the question, since url-fetch doesn't care what it fetches (as long as it's found). <Maya[m]1>akirakyle: if it is a local file, i think in guix gexp there is local-file function, you can use it in origin as it accepts any file-like object. But i dont know if buildsystems can by default untar lzip files. That would be a bit trickier <akirakyle>nckx: Ah right, I guess I meant an unpack phase for lzip <nckx>Ah! Just add lzip to native-inputs and be happy. <lechner>younder / because of guix's unique way to refer to nearly everything via absolute patch into the store ("/gnu/store/...") or symbolic links thereto, you environment variables like PATH have to be exactly right. The profile is a short shell script that attempts to make those adjustments for you, but that does not always work for all software (and i have no experience with quicklisp) <akirakyle>Yay that did the trick! And here I was grepping through guix/guix for some lzip argument to add to the package <lechner>younder / guix home does it automatically for you <Maya[m]1>if you are not sure, the whole build process is described in guix/build-system/gnu.scm there is quite some magic going on there! <younder>lechner: Now that I think about it, yes, I dit run profile. <akirakyle>Maya[m]1: Yeah the build system inheritance often gets me though since this is actually for an emacs-build-system <nckx>The gotcha here is that some decompressors like gzip/bzip2/xz (I think that's all) are included by default; lzip/zip are not. There's code to extract both but only when they are added. It can certainly feel arbitrary but it's also not unreasonable. <hjckr>folks, any way to resume a failed package build with guix? Similar to 'ebuild <path to ebuild that failed> merge' in GNU/Gentoo's portage? <Maya[m]1>akirakyle: essentialy its almost all of it in gnu-build-system, and others only skip/change some phases <lechner>younder / another great way to get the profiles right is via 'guix shell' <nckx>You can keep the failed result for inspection but there is no way to resume the build or re-enter the environment cleanly. <hjckr>nckx, thanks. This is not ideal, but perhaps worth a feature request? ;-) <younder>lechner: Yes, that is probably what I should have done. I just installed it as user. No guix shell. <Maya[m]1>nckx: perhaps there could be some sort of a lint or something instead of failing inside tar with a cryptic error <younder>Guess I've gotta get working on those manifests. <lechner>younder / quicklisp may require some extra hoops. maybe hang around here, or look at those list archives <nckx>I'm not familiar with the exact error message. If tar prints a useless message, that's a shame; that affects far more users than Guix. <Maya[m]1>nckx: iirc it prints that no executable found lzip, or something similar <Maya[m]1>it’s more of a “this is how you fix it in guix, as it is a common error” <nckx>Not to be dismissive, but that might make a good low-hanging patch? :) <Maya[m]1>nckx: if i already havent pending a patch to shepherdize linux containers… (the patch is written i have been procrastinating writing tests) <Maya[m]1>but i might look into it, although there might be a “lack of design” when it comes to error reporting in general in guix and that is no low hanging fruit (i mean i think it hasnt been planned how should the errors work) <nckx>‘Just throw exceptions’ but sure, I understand the feeling. <Maya[m]1>nckx: can i just throw on the build side? <mirai>could someone review #60357? It fixes a pesky crash that occurs somewhat erratically <nckx>Maya[m]1: I think so, at least I think that's it needn't be prettier than that. I still think it's an obscure error. <Maya[m]1>my question was more of a “does it show nicely on failed builds and will it get accepted” <nckx>(My answer was meant to imply that I don't think this needs to be *that* nice, or presented at a different level than tar's own stderr would be.) <nckx>Accepted: I can't say, but I wouldn't have suggested it if I thought it wouldn't be. <nckx>I'll leave it up to you, but I didn't mean to discourage you either :-/ <nckx>‘SyntaxError: invalid syntax:’ <nckx>${c1}````'\"""\""""${c2}'\"""\""""" <nckx>(Also, OK hyfetch codebase.) <Maya[m]1>nckx: sometimes i am sad, than i remember that i dont have to write parser for python grammar, and suddenly im good again <Maya[m]1>nckx: but hey at least im more inclined to actually finish that docker patch! <weidtn>Still nobody knows about a fix for the symbol lookup error of libpthread? <michl>Can anybody help me to install Guix System on lvm on luks? <michl>I get a system running using root on luks and I can get a system running using root on lvm <michl>but if i put the physical volume of the lvm on a luks partition I cannot boot the system <tricon>well well well, if it isn't gnucode. <tricon>Oh just dragging through the end of the work day. Yourself? <gnucode>mirai: I got my server firewall set up. :) <gnucode>tricon: Trying to work for a few hours. :) I'm in a public place so people keep trying to talk to me. I've got a sign that says, "A russian oligarch promised he would kill my entire blood line if I don't set up his website by 6pm. I can play after 6pm. Thanks!" <mirai>did you find out what the issue was? <gnucode>mirai no idea. :) I just used the basic server config from the arch linux wiki. <rekado>I may need a little help with jack2 <rekado>I have a headless system and I’d like to launch a few synths on it <rekado>“jack_control start” aborts with a python dbus error <rekado>it does the right thing when launched with dbus-launch <rekado>subsequent “stop” and “start” fail <rekado>and lots of dbus-daemon processes are launched <rekado>other than doing “dbus-launch bash” what’s the best way to get jack and dbus to do the right thing? <rekado>(do I *need* to use dbus to use jack2?) <rekado>“dbus-launch bash” doesn’t actually work, nor does “dbus-run-session bash” <rekado>“jack_control start” launches jackdbus, but it doesn’t get a response from dbus and assumes that the launch failed. <rekado>I don’t even remember what idea I had that would have benefited from launching a synth <mirai>I'm checking your post right now <apteryx>rekado: ^^' it often happens to me: OK, let's do X... Ends up pursuing a rabbit hole doing Z <tricon>michl: I'm not seeing anything that refers to "cryptpiet" after you've defined it. <apteryx>but hm, d-bus. I wouldn't have thought jack requires d-bus. d-bus doesn't exactly resonates with low-latency <rekado>apteryx: it doesn’t use dbus for message passing <rekado>it’s just for “automatically” launching jack when needed by a client <rekado>but this is a lot of manual work for something automatic… <rekado>I guess on this headless system I’d need to run dbus-service and arrange for DBUS_SESSION_BUS_ADDRESS to be set <rekado>dbus-daemon appears to be running, but I don’t know what value I should set for DBUS_SESSION_BUS_ADDRESS <apteryx>usually the user dbus-session is started by the graphical session session manager, I think <rekado>because otherwise python-dbus will try to launch a new dbus-daemon, and that fails because: “Unable to autolaunch a dbus-daemon without a $DISPLAY for X11” <rekado>don’t have that, because it’s a headless machine <apteryx>so maybe have a guix home/shepherd service that spawns it when you login <apteryx>with the dbus eval trick in a ~/.bash_profile, perhaps <rekado>I might not even log in, actually <apteryx>if it's a single purpose box, why not always leave jack running? <rekado>I can automate this, but … I haven’t even been able to get this done manually <rekado>yes, jack will always be running <rekado>I’m currently fiddling with the settings <apteryx>ACTION checks their shepherd services <rekado>and to launch the synth I’ll also need to be able to talk to dbus (so that it can discover that jack is available) <ham5urg>I have a remote VM and try to install Guix. When I do a 'guix system init /mnt/etc/config.dcm /mnt' I get a 100% cpu-usage, a newline and a blinking cursor. As if stucked in a loop. --verbosity=9 and/or debug=9 did not helped either. The only way to get out is ctrl+c. I tried the GUI-installation but no luck either. <weidtn>But I am not sure if I have to update something special or if guix pull and then guix upgrade is enough to get this? <michl>tricon: on "cryptpiet" lives the pv for the volume group "piet". the later is referenced in the lvm-mapping. This is the way I understood other configs doing it. Am I suppose to reference it directly somewhere? <michl>And, the mapped-device is referenced by the root file system <civodul>ham5urg: it's hard to tell; it networking working fine? <civodul>also, what process is spinning at 100%? <civodul>is it 'guix system init' itself, or some helper such as 'guix substitute'? <ham5urg>civodul, it is Guix itself which uses 100% of the CPU, networking is ok, I can ping gnu.org <civodul>ham5urg: weird, perhaps you can try "guix system build" of the same config on another machine to see whether the same happens? <weidtn>okay, when I try to run sudo -i guix pull I get the following error: <weidtn>guix pull: error: Git error: failed to read index: '/root/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/index' no longer exists <apteryx>that's a cache, so you could always clear it <weidtn>with rm or some special guix command? <tricon>Thus, /dev/mapper/cryptroot gets mounted as / <tricon>I don't know the Guix internals, but LVM needs to be able to discover the PV group after the LUKS volume is mounted. <ham5urg>When I boot the install-iso, is there something else I have to do except passwd & herd start ssh-daemon ? When I try to login via ssh root@... I just get an time out. <tricon>ham5urg: Are you able to ping the booted device from the SSH client device? (assuming ICMP isn't filtered or blocked on your network...) <weidtn>okay so sudo -i guix pull did not give me the needed patch. What do I have to do to get this? <civodul>weidtn: you can check what "sudo -i guix describe" reports, and see whether it's a commit that includes the one you want <civodul>(perhaps you don't need to run everything as root BTW?) <weidtn>it seems like the commit does not include it. So I somehow need to manually add it? Why is a commit from december not in my pull from end of january? <weidtn>can i just run guix pull --commit=047425a662608f56ba530052e21106028c5d6eeb --allow-downgrades? Or will this break something?