<Kolev>guix system: error: #<<setuid-program> program: #<file-append #<package shadow@4.9 gnu/packages/admin.scm:806 7f1c749a6420> "/bin/passwd"> setuid?: #t setgid?: #f user: 0 group: 0>: invalid G-expression input <tschilptschilp23>I was just wondering, where my gnome-maps went after upgrading and switching to wayland. <tschilptschilp23>Turns out that the desktop-file in my home-profile has a somewhat strange Exec-line: ~Exec=gapplication launch org.gnome.Maps %U~ <tschilptschilp23>If I start it up directly via ~gnome-music~, it comes up, but there is no zoom-scrolling and dragging the map around anymore! <tschilptschilp23>My first real guix-time-travel later I think that this is related to wayland somehow -- the situation was the same with commit d7e1c5acb3c8282c6a568d97ab164db82e33324f on a wayland session. <tschilptschilp23>On X11 with 6bfb3fc1f450c7d618041303d0ff35691b5991c0 gnome-maps are totally fine! <tschilptschilp23>Funny enough ~gnome-maps --version~ does not give an output here, but I do not care as I can read from the GUI that it's 41.2 as well *tschilptschilp23 needs some sleep <ajarara>Hello #guix! I'm packaging git-secret. Tests fail when building, but pass when run through 'guix environment --pure -C -f git-secret.scm', unless I source the environment-variables file found from keeping the first failed build run around, which has paths that don't exist in the container. What could I be doing wrong? <ajarara>to re-run tests, I'm running 'make test' manually. Nix puts phases in the path, afaict Guix doesn't do that. ***califax- is now known as califax
<mroh>can you please paste us the (failing) build.log somewhere? <droople>how do I fix my ethernet interface not showing up? I guess I have to set up guix to load a module on boot, and I get how that typically works, but how does it work in guix? <efraim>guile@3.0.8 FTBFS on powerpc-linux, 'adjust-bootstrap-flags failed, so it looks like I'll need to adjust that again <kitzman>Pulled and -u'ed. Now sway can't run. Xdg runtime dir is set. Stracing reveals that sway tries to open /run/systemd/users/1000 <kitzman>Pfft sway change. If you encounter this, set SEATD_SOCK and run seatd before <kitty1>yknow, before I start bothering around mailing lists, since no other IRC has been able to help, on the offchance guix is playing a role and it not being entirely an emacs problem; has anyone using emacs org-mode struggled to get scheme code to run and output a result? Just asking here on the offchance its guix weirdness and not me messing something else up. Have more details if necessary but didn't <kitty1>feel like writing it all down right now lmao <kitty1>only reason I am thinking there is a chance it could be related to guix is because my friend on nixos is also experiencing similiar issues that appear to be happening nowhere else <aadcg>I have a .authinfo.gpg file and when I save it it tells me "Untrusted key 6875A3A8B8A15D8E Maxim Cournoyer <maxim.cournoyer@gmail.com>. Use anyway? (y or n)" <aadcg>I'm wondering if anyone knows how to bypass it <aadcg>notice that, in the mentioned file, I have the local variable epa-file-encrypt-to set to my email address <declan>I believe this is an gpg usage question. There are some keys you can play around in `epa-list-keys` buffer I think. aadcg <aadcg>declan: that is indeed true. it seems that there was a recent change in guix, and now epa is aware of maxim's key... <rekado_>efraim: is it failing tests? I’ve got test failures for 3.0.8 on aarch64, too. <rekado_>(I’m *still* trying to ‘guix pull’ on the aarch64 nodes; some five days later) <rekado_>now I’m building yet another coreutils derivation on one of the overdrives. Maybe the fourth. <rp1>I've successfully patched the racket package to build the new version of racket, 8.4, which was released a few days ago. What do I have to do to submit the patch? It's my first time <rp1>attila_lendvai: thank you <rp1>I'm not sure I can follow those instructions. I just have a file which I've edited (which I got using guix edit <package>). It suggests using git format-patch, but I don't have a git repo. Do I need to download/locate a git repo and work in there with git tools? <rp1>Or is there a way to produce a more simple patch from the file that I've got? <leinad>jpoiret: do you remember the message about elogind I posted? after your patch I still see this message. So the race was not with gdm. I have seen that NetworkManager also has no elogind required. Isn't NetworkManager also using elogind? So maybe that's the problem. <attila_lendvai>rp1, if you have plans to do such things in the future, then i suggest reading the preceeding chapters. in short: you'll need to check out the git repo, make your changes there, then record the changes into a git commit, and then you can use git format-patch to save it as a file, or straight out git send-patch to send it in an email, but that'll require SMTP configured for git <rp1>attila_lendvai: thanks for the pointers. i'm not a developer but i thought i'd give it a try to see if i can help out <rp1>also scratching an itch for myself, as i want the latest version of racket :) <attila_lendvai>rp1, the question is: are you planning to be? if yes, then the above are generally useful knowledge, not very guix specific. if not, then maybe you can paste your package using https://paste.debian.net/ as a non-expiring paste, and someone can submit it for you. <jpoiret>leinad: I'm nut sure networkmanager requires elogind but I might be wrong <jpoiret>it needs polkit though, which should require elogind iiuc <leinad>glimpsing over the polkit-service definition I don't see any reference to elogind :/ <jpoiret>let me check if it needs it lazily or right when it starts <jpoiret>although it's not that different I guess <jpoiret>it might be worth trying adding elogind to that service also <droople>How can I get guix to detect my ethernet interface? I've already tried modprobing <leinad>droople: what kind of ethernet device do you have? Note that Guix system uses linux-libre as its kernel which does not contain non-free firmware. <droople>leinad: I have a librebooted x200. That free enough? <jpoiret>civodul: i've got a working current-guix that manages to end up with the same derivations as `guix pull` (in fact it reuses the same channel->derivation code) <droople>Intel 82567LM ethernet controller detected by lspci <efraim>rekado_: some file moved, i need to adjust the powerpc-linux specific phase and test it again <jpoiret>the issue is that it's done as a package with a custom build system, and most of the work is done in (build ), which leads to a bunch of work being done every time the package is lowered <jpoiret>do you think memoizing (build ) is a good idea? <jpoiret>it's really a shame that one needs so much work simply to create the derivations when `guix pull`ing <PotentialUser-65>How do I set up that all all emacs packages are compiled with the emacs I actually use, e.g. emacs-next-pgtk? <civodul>the custom build system is channel-build-system or something else? <jpoiret>it's very similar but channel-build-system builds a profile <civodul>memoizing "build" shouldn't be necessary because the package-to-derivation mapping itself is memoized <jpoiret>is it though? When I tried replacing the guix of the installer with (current-guix), the Guix derivation was computed multiple times <civodul>could it be that current-guix returns a fresh package object every time? <jpoiret>no, i've memoized it to make sure the package was the same each time <civodul>the profile gives the package cache + provenance mdatadata <civodul>it'd be great to have a single channel-build-system rather than two slightly different things <jpoiret>yeah, I wasn't sure about the package cache generation being skipped this way, but the `guix` package is missing it as well so we're not losing functionality <jpoiret>the issue here is that the end product will end up in a profile (the system profile), so building it as a profile is a no-no I feel like <jpoiret>although I haven't tried to be honest <civodul>the real "manifest" file will take precendence over the one from 'guix' i think <jpoiret>right. I can try merging channel-build-system with the one I added <civodul>if you want you can send what you have to the issue, that may make it easier to understand the subtleties :-) <jpoiret>I have a mail ready to go, but wanted to test with the installer <droople>where's the /etc/modprobe.d equivalent in guix? <jpoiret>droople: there isn't one yet, but I have a service for that (untested yet, haven't reconfigured since I made it) <droople>Or better yet: what should I try after modprobe e1000(e) doesn't make my ethernet interface appear <droople>This is so weird. wlan is supposed to be what gives me trouble <jpoiret>lspci -k can show you what kernel module is using the pci device <droople>jpoiret: Already tried that. None are <droople>Which is why I tried manually loading drivers <rp1>attila_lendvai: thanks, I think you're right. step by step, i'll use the debian paste this time <rp1>I didn't do much: updated the version number, updated the new hash and removed a comment that was out of date <rp1>Then I checked that everything built, which it did <jpoiret>droople: does dmesg report anything? <rp1>If someone could update the packages, then I would be very grateful <droople>jpoiret: There's a little blurb when I loaded the module, but otherwise nothing <droople>e1000e loads, and then it says Interrupt Throttling Rate set to dynamic conservative mode <droople>That's the only mention of ethernet stuff in dmesg <jpoiret>it's weird that the pci device wouldn't then be used by that driver <GNUtoo>hi, how do I get a working MBR grub setup with guix system image? I only see rock64-raw pinebook-pro-raw pine64-raw novena-raw hurd-raw hurd-qcow2 iso9660 raw-with-offset qcow2 efi-raw uncompressed-iso9660 docker <attila_lendvai>rp1, i hope someone with the commit bit picks it up. if not, i'll keep it open in my browser and i'll file it myself. <jpoiret>I think the iso9660 installer image works with Legacy BIOS boot <jpoiret>but that doesn't mean it has to be MBR <GNUtoo>I'm looking for the regular installation, with ext4 and so on <jpoiret>what is the use case? burning to usb/cdrom or making a qcow2 image? <GNUtoo>jpoiret: just installing on an x86_64 laptop which runs Coreboot + SeaBIOS <GNUtoo>According to the manual it defaults to efi-raw, and I've tried that and grub doesn't find normal.mod <jpoiret>is the normal route installer -> guix system init not available? <jpoiret>GNUtoo: do you have access to the GRUB shell? <jpoiret>isn't SeaBIOS a BIOS implementation on top of EFI though? can it boot efi applications? <GNUtoo>yes, but it's the restricted shell <GNUtoo>normally it does insmod normal.mod and that fails <GNUtoo>I can load manually the modules and I managed to load normal.mod but it takes a very long time, you need to use find in the image to find the .mod, try to load it, then it fails, the load its dependency etc <GNUtoo>and then it still doesn't load the config file <GNUtoo>and for SeaBIOS, no it's just a BIOS implementation <GNUtoo>It can be compiled for several runtimes including UEFI <jpoiret>I don't think you should use efi-raw for it then <GNUtoo>but it can also be compiled for Coreboot or SeaBIOS <GNUtoo>When compiled for Coreboot or SeaBIOS there is no UEFI at all <GNUtoo>And I'm not sure it can really run "on top of UEFI" like duet does for instance <GNUtoo>It's more intended to be used as CSM (Compatibility software module) <GNUtoo>Basically it's when you choose BIOS mode in the UEFI settings <aadcg>does it make sense to test the installation image for the next release? <jpoiret>hmmmmm, i didn't know much about coreboot, I thought it was an open source EFI firmware <jpoiret>well, if you're planning on doing the usual BIOS boot, efi-raw won't cut it <GNUtoo>Yes, in my case it's like a regular BIOS boot <GNUtoo>as for Coreboot , it's just some code that initialize the hardware and then it runs a payload <GNUtoo>the payload can be GRUB, SeaBIOS, Tianocore, etc <jpoiret>well, if you want to boot a efi-raw image, maybe coreboot + tianocore would work better, no? <GNUtoo>For some laptops like the ones supported by Libreboot it's almost 100% free (it has still options to add nonfree microcode in the image) but for modern laptops it's almost 100% nonfree: coreboot doesn't do much anymore, and nonfree binaries from Intel/AMD do all the hardware intialization <jpoiret>i'll look at the efi-raw generation code <PotentialUser-65>A propos osboot: the easiest way to build it is probably through a vm with a distribution that supports its dependency management, right? <GNUtoo>I just want to boot in BIOS mode <GNUtoo>I'll try raw-with-offset though AFAIK that's for ARM SOCs <jpoiret>i don't think there's a `guix system image` option to get a working BIOS-compatible image that's not iso9660 <jpoiret>can't you simply install from the installer though? <GNUtoo>So I should probably bugreport then <GNUtoo>And use an old guix installation in the meantime <GNUtoo>Thanks a lot for that information <GNUtoo>Installing it through the installer kind of defeat the point of the way I want to use Guix system in that case <jpoiret>maybe you could look into `gnu/system/image.scm`, you could generate your own image the way you want it <jpoiret>although I'm not sure how one would use a custom image type with the cli <GNUtoo>ddrescue $(guix system image -t <image-type> system.scm) /dev/sdZ -f <jpoiret>the thing is, `guix system image` isn't made to generate a whole system to just `dd` onto your main disk, at least that's not its purpose <GNUtoo>And is there a tool that has that goal? <jpoiret>guix system image could definitely do it, but I think its primary use-case is just creating iso9660 installers, docker images or flashable things <GNUtoo>flashable things is the same thing <GNUtoo>AFAIK it's far from being perfect as for instance it doesn't handle LUKS yet, but at least its goal is to do that <jpoiret>I don't think there's a userspace LUKS/dm-crypt implementation <jpoiret>cryptsetup is just a front-end to the kernel's dm-crypt <jpoiret>it communicates with the device manager <GNUtoo>Yes, I meant that you need some tools to create the LUKS / cryptsetup partition <GNUtoo>Like one the partition itself, beside encryption there is a format where some parameters are stored <GNUtoo>I think it's called a header of something <GNUtoo>And there is 2 formats in use actually <GNUtoo>If you use that, you definitely need guix system init as guix system image doesn't create encrypted images so far <GNUtoo>And LVM and so on isn't handled either AFAIK, but for simple things it should work in theory <jpoiret>heh, I saw you submitting a patch to grub-devel on cryptdisks, no? <jpoiret>since LUKS2 isn't supported by grub-install <GNUtoo>Right now it's Glenn Washburn who picked up my patches <GNUtoo>Glenn wanted to rework the crypt subsystem to make the code way cleaner <GNUtoo>As for the BIOS boot in Guix I'll bugreport <GNUtoo>ah wait there was an issue in my system.scm *GNUtoo left my configuration from another computer that runs coreboot+grub in the flash (so grub isn't to be handled by Guix in that case) <sughosha>Hi people, is there a way to run binary and appimage files in Guix? For me everytime "no such file or directory" error occurs when I try to execute such file. I also checked the execute permission for them. I think probably it requires access to /lib or /bin files, while Guix saves every program in /guix/store. Thanks for any help. <GNUtoo>jpoiret: so it was an issue in my configuration and the default (efi-raw according to the manual) works <GNUtoo>This is what selects "grub-pc": (bootloader (bootloader-configuration (bootloader grub-bootloader))) <GNUtoo>And I had the one for Libreboot or Coreboot+GRUB which only generates the grub.cfg but doesn't install the bootloader <mbakke>sughosha: you can get pretty far by adding a /lib/ld-linux-x86-64.so.2 symlink that points to <glibc>/lib/ld-linux-x86-64.so.2 (this can be done declaratively with the 'extra-special-file' service) <vldn>hey sughosha, binaries could be a bit tricky, you could find out which libries are needed via ldd or libwhich and link them with extra-special-file service <GNUtoo>Maybe efi-raw should be renamed to "pc" <ngz>mbakke: Wouldn't this deserve an entry in the cookbook? :) <leinad>sughosha: you could also use patchelf to patch the binary with the correct paths for the libs <vldn>there are some guix game channels than have neat definitions for patchelf'ing the binaries via scm definitions @ sughosha <mbakke>ngz: dunno! executing binary-only programs is not really something Guix is usually concerned with :-) <mbakke>ngz: btw, did you mean to push the TeX Live changes to 'core-updates'? <attila_lendvai>sughosha, i have failed to run appimage'es, but flatpak's work fine <ngz>mbakke: yes, did I fumble somehow? <GNUtoo>or maybe guix system image should only override the settings when the user asked for on the command line <mbakke>ngz: I just heard rekado talking about a new 'wip-texlive' branch that may be difficult to reconcile with your core-updates changes ... it may already be difficult due to many changes on 'master'. But I didn't check, and have a habit of perceiving problems where there are none :P *mbakke still has nightmares from that time they worked on TeX Live on core-updates, and a long-forgotten wip-texlive branch was merged to 'master' ***aya is now known as gyara
<sughosha>@mbakke @vldn @leinad @attila_lendvai thanks for your replies :) <ngz>I didn't realize wip-texlive was still a thing. <attila_lendvai>any comitter around for a quick fix? libfprint requires python in its native-inputs to build. <attila_lendvai>...or alternatively skip the tests. for some reason it skips most of them anyway. <sughosha>@mbakke could you please explain extra-special-service? Is it something to add in /etc/config.scm? <mbakke>ngz: no worries! perhaps the TeX Live rework should be done on core-updates anyway, I suppose you should coordinate with rekado :-) <ngz>mbakke: Last commit in wip-texlive is 1 month old. Is this branch really alive? <mbakke>ngz: I think that branch has been merged already and should be deleted <ngz>In any case, something's rotten in the state of "tex.scm". Many packages are broken, in the sense that they do not provide all the expected files. <sughosha>mbakke: Thanks for the quick link. I'll read it and try using the service. <vldn>sughosha: maybe helpful cli command: info guix extra-special-file <rekado_>that’s why I wrote the new importer and the files-differ? helper <sughosha>vldn: I didn't know that `info` command could also be use with subcommands. I was always using `info guix` and then going through. I'm reading it. <vldn>and something like guix system search cups (e.g.) is helpful to know which package is needed to include, but most of the time the system compilation spits out an error and give hints what to import :) <sughosha>Hm, thanks for the tip :) while trying packaging something, the hint is always helpful as it says "Did you forget use-modules X Y?". I didn't know about `guix system` also has a `search` option. <ngz>rekado_: We may want to coordinate, and write down a check-list somewhere in the interwebs so anyone can take care of these packages without duplicating work. <ngz>rekado_: Also I think there's something sub-optimal in the way we currently list locations. I.e., if we list "/tex/latex/foo/A" and "/tex/latex/foo/B", we might as well write "/tex/latex/foo". <ngz>Maybe we should limit ourselves to the entry points in the TDS, e.g., stop as soon as the package name appears in the directory added as a location. ***aya is now known as gyara
<rekado_>sneek: later tell ngz We do use directories in the origin when it makes sense. The importer produces the shortest common prefix. <efraim>almost 3 hours in to building ghc@8.4 on aarch64, I really hope it works <civodul>efraim: ghc@4 builds in like 5mn on x86_64, it's wonderful <efraim>civodul: now you're just showing off <civodul>(the bottleneck is likely the terminal, which has to display loads of compiler warnings) <efraim>didn't you have some patches to add an actual gcc-2.95 package and stuff? <efraim>I bet with that I could get powerpc-linux with haskell too eventually, as if that was something we were missing :P <attila_lendvai>i get "In procedure load-thunk-from-memory: incompatible bytecode version" in a local checkout using ./pre-inst-env, even though i have `make ditclean`ed and rebuilt everything. what am i doing wrong? any hints? *attila_lendvai tries again <civodul>attila_lendvai: we'd need to see details, but basically Guile 3.0.8 produces .go files that 3.0.7 cannot read, hence the message <attila_lendvai>both guile --version and ./pre-inst-env guile --version prints 3.0.8. i'll wait for another distclean rebuild cycle, just to be sure <sughosha>I would like to thank everyone who helped me with executing third-party binary. Finally patchelf command and also `#:patchelf-plan` argument worked for me! 😃️ ***roptat is now known as Guest3438
<rekado_>civodul: the ghc@4 build would be a little longer if we also built the compiler and the standard lib. <rekado_>the way it is now it should be on par with the build time of hugs <rekado_>but it is refreshing nonetheless to see old packages build *so* much faster <rekado_>attila_lendvai: gotta check your GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH <rekado_>attila_lendvai: whenever there’s a new Guile out and used in Guix I recommend using ‘guix environment -C guix’ to make sure that your system’s Guile isn’t influencing your build. ***Guest3438 is now known as roptat
<civodul>rekado_: refreshing and worrying too? :-) <civodul>"worrying" is not accurage, because at a "micro" level, we know what these tools gained in the meantime <civodul>at a "macro" level, things are sometimes less clear <tschilptschilp23>is there a ~scanimage~ command somewhere in guix, so I can start debugging? <tschilptschilp23>at the moment I simply scan through the printer/scanner's webinterface, which actually results in smaller files, than I know from sane on other systems <tschilptschilp23>I'd just like to scan straight to gimp, that's why I started with that again... <jpoiret>roptat: "A deep dive into the documentation ..." doesn't seem to point to a video <efraim>no suprise, gcc-2.95 builds just fine on powerpc-linux <roptat>jpoiret, I know blake is late :/ <nckx>tschilptschilp23: scanimage is in the sane-backends (yes, I know :) package. <tschilptschilp23>nckx: thanks, in the meantime I found that one :) but now I struggle how to tell whom (!?) to tell about to use sane-airscan and not sane backends as a backend! <nckx>Hi cwebber. tschilptschilp23: I'm sorry to say that whilst the sane-airscan package works, I'm probably its only user (a rather ‘embedded’ scan server in one of my offices, no access from here) and it just uses a custom sane-backends package that has sane-airscan as an input, much like the default Guix sane-backends hacks in HPLIP <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/scanner.scm#n206>. I don't think Guix *has* a way to configure S <nckx>ANE the way you can, e.g., CUPS, to add extensions at will. That would need to be added. <cwebber>I'm doing the unpleasant work of trying to figure out how to get a quasi-modern mail setup working on top of guixsd. I've noticed that a bunch of other folks have also done the same. This seems like something that's in desperate need of a cookbook guide. ;) <nckx>Guix does plain modern too :) <nckx>Although I'm not sure it does spam filtering. <nckx>cwebber: Why unpleasant? <cwebber>nckx: not guix that's making it unpleasant, but the modern world of running an email server <cwebber>and all the stuff you have to do to try and duct tape "security" on board (for various reasons I'll argue that email has absolutely the wrong security model, but I'm in no position to help fix that) <tschilptschilp23>nckx: thanks for the information. this makes me feel, I should rather continue to use the embedded webserver of my printer, as this i going into a only partly sane direction... <nckx>> implying mail has a security model <nckx>Whilst I quite ‘enjoy’ managing mail, unlike you, I'm still forced to agree. <nckx>The design is pretty sane but unless you want to add something like a sane-union or sane-configuration interface yourself there's no easy ‘user’ way to do it at the moment. <tschilptschilp23>I'd actually 'just' want to convince xsane or simple-scan to use sane-airscan, about which it's said that it supports my printer/scanner. And at the same time let gimp see xsane or simple scan. And that, for some reason, although I have a bookmark to the scanning-tab of the printer/scanner's in my browser anyway... <tschilptschilp23>which automatically creates 500kb high-quality scans compared to 5MB file-bombs, that I would have to somehow gs-downsize afterwards. I think I found my deal <nckx>Great. Front-ends don't use back-end drivers, by the way, they just use libsane which is configured through e.g. dll.conf. <tschilptschilp23>Excuse my rant, I guess I should rather focus on working and reading up stuff. Thanks for your input. <fiesh>hmm I just realized my screen's backlight isn't turned off on lid-switch-external-power... I guess I have to come up with a udev rule or something myself? <lilyp>cwebber: email has the right security model for a world in which we sadly don't live in <jackhill>after the change in 54000 will there be a different way to see the new and upgraded packages between guix generations? I think it's a good cleanup, but I'd still like to be able to see that information when I want to <cwebber>lilyp: hm, sorta. I have strong opinions on this one and why it's wrong which have to do with the kind of ocap stuff happening in spritely :) but email evolved in a world before even encryption was widely available. everything is backported awkwardly <lilyp>well, looking at spritely itself, some of the comments are amusing in their own right :) <ggoes>ooh, the water damage talk looks cool <apteryx>rekado_: It'd be nice to reboot berlin sometime this week to get rid of the old mounts <jeko>I wanted to add gnutls as a propagated input for my package. But Guix does not seem to like it… <jeko>(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (gnutls)) (value #f)) <roptat>jeko, probably you forgot to import the module that defines gnutls <jeko>roptat: rho bingo haha ^^' <rekado_>apteryx: okay, tomorrow should be fine <cassio>I'm having a very hard time getting Guix to work. I finally have a machine that apparently doesn't need any non-free drivers, so I thought I'd give Guix a try... <apteryx>it should be smooth (not touching root fs yet; just /var/cache mounts) <cassio>So I installed it completely bare-bones, as a proof of concept. <cassio>it's working, but with a few quirks: <cassio>1. when I had `(swap-devices (list (uuid "...")))` the compilation went ok, but the swap service would not start. <cassio>2. then I changed it to `(swap-devices (list "/.swapfile")`, and the installation process complained that this syntax shouldn't be used anymore -- but then the swap service is up now. <cassio>But there is still one service that won't start: the service `termauto` --- can someone tell me what that is? <cassio>I want to make sure that everything is OK before I try again to install the graphical interfaces... <tschilptschilp23>I'm here on a graphical system with a stopped term-auto service. Honestly I do not know if this is supposed to be like that, but the computer runs nicely. In fact I get a message about term-auto not being able to be restarted after every system reconfigure. So I'd also be interested in details about this service... <cassio>Yeah, tschilptschilp23, it's weird --- I too would like to know what it's supposed to do... <tschilptschilp23>looking at the shepherd graph I just can tell, that it's unidirectly connected to the hostname, udev and user-processes services. But I don't know in which kind. <tschilptschilp23>in my case it looks like it's on the same hierarchical level like term-tty{1-6}, the difference to those is that it's lacking a 'parent'. The other ones have console-font-tty{1-6} 'one level higher'. So maybe it's the missing console-font that prevents it from starting. But this is heavy guessing... <attila_lendvai>which compiler is used to compile llvm and clang? clang or gcc? staring at llvm.scm it seems to be unchanged, i.e. gcc. is that right? <mbakke>attila_lendvai: both are built with GCC, yes <attila_lendvai>mbakke, thanks! then my c2ffi package shouldn't require clang... only clang-runtime. *attila_lendvai digs deeper