<nckx>When you want to append it to another. <nckx>The question makes sense only when you have multiple lists. You never need it for ‘a’ list. <lechner>Hi, why would I get guix lint: error: connect: Connection timed out in the [archival] stage on guix lint nyacc but only in the guix source tree with 'guix environment --pure' and './pre-inst-env and not with my system guix after a 'guix pull'? <lechner>fwiw, i also saw this WARNING: Use of `load' in declarative module (guix ui). Add #:declarative? #f to your define-module invocation. <lechner>Hi, will this explicit setting of arguments to ./configure for linux-pam replace or interfere with the --prefix argument that is otherwise essential to Guix? http://ix.io/4bsp <nckx>lechner: That does not look like the right link. If you are running (invoke "./configure" "--stuff"): yes. If you are using #:configure-flags as intended: no. Otherwise: maybe. The 'WARNING' warning is annoying but harmless. Maybe adding nss-certs will help with connecting. <nckx>I guess the patch question is moot now. <jpoiret>unmatched-paren: maybe it would be wiser to add a greetd.scm file since it's likely there will be multiple greetd greeters <jpoiret>i recently switched to greetd so i may be able to test it out, however for now I'd say this needs a bit of reorganization. Want me to send an email <jpoiret>civodul: do you think shepherd 0.10 could fit some new features or would you like to get it out soon-ish? <jpoiret>i'm not sure how yet but i'd love for services to be able to pass information to their dependents, for example environment variables <jpoiret>that way we'd have a dbus-like "activation environment" that would be scoped for each service <civodul>jpoiret: it's a good time to squeeze in new features <jpoiret>i even read the fibers manual recently, that'll be a good time to test it out :) <civodul>as an example, i'd like to have a journalctl kind of interface <civodul>to make it easy to view the tail of a log <civodul>(right now i refrain from touching it because i feel i should be helping on the Guix release :-)) <civodul>apteryx: hi! i think we should keep overdrive1.scm (it's handy) and have deploy-overdrive.scm include it <jpoiret>what are the blockers for a release? <jpoiret>i haven't seen any mails about that (haven't finished reading them though) <jpoiret>maybe i'll need to really organize a TODO list this time around :) <liltechdude>What I'm doing wrong when could not import (gi) module, but previously install it with `guix install guile-gi'? <rekado>I’d like to work on cgroups support in shepherd; probably not for the upcoming release, though. <Luk6655>Is anyone using channel authentication with more that one openpgp fingerprint? I wonder if it is possible to add more than one? <nckx>Could you explain the threat model? <Luk6655>I'm not sure if I understand correctly how it works, but imagine I have a fork of guix channel. I commit my own changes to it which I sign with my own key. However I would like to also occasionally pull from gnu.savannah.org and get new commits from there <nckx>Is this about the introductory commit? If not, where else is there such a limitation? <Luk6655>I would like both my commits signed with my key and those from guix be recognised as authorised if possible <nckx>As long as you don't delete existing keys from the upstream keyring I'd think you're good? <nckx>I haven't tried this, mind you, but I'm not seeing the gotcha (yet :-) <Luk6655>for guix channel, probably as it is configured to trust them, but I have other channels that I modified, those (based on the manual) one authenticates by adding an introduction with an openpgpg fingerprint <Luk6655>so then if I change the channel introduction to my fingerprint I suspect it will stop trusting the original authors if I pull their commits too <nckx>I don't think letting someone say 'oh no actually I'm a trusted committer now, trust me, I signed this' can ever work. <Luk6655>I point my channels'scm to my fork of a channel <nckx>Well, not seamlessly I mean. That's the point. <Luk6655>hmm, I have a feeling I'm missing something. I find it strange to be able to specify just one pgp fingerprint per channel <nckx>If users change their root of trust to your new 'forked!' commit in their channels.scm, it works fine. <nckx>Because they are explicitly trusting your fork announcement, basically (first commit signed by you). <Luk6655>even if I then do a pull from the original remote? <nckx>I think so. But you have to keep the keyring in sync now. <Luk6655>do I need to then sign commits made by original authors with my fingerprint if I want them to be trusted as well? <nckx>I think you're viewing Guix's trust model as users saying 'I trust this list of fingerprints', which it isn't. <Luk6655>yes, exactly, how should I view it? (in general) <nckx>You're typing too fast for me to respond on phone :-) <nckx>Someone else can, but otherwise I'll TTYL. <nckx>I want to answer but this is too risky, I could easily confuse you beyond repair, <Luk6655>sure, no worries I'll do some experiments <attila_lendvai_>i'd like to fork+exec-command a service in a way that i can talk to it through its stdin/stdout. does it make sense to try to smarten up shepherd's fork+exec-command to accommodate for that? or shall i roll my own, copying/duplicating a lot of magic from it...? it's somewhat unfortunate that it calls the streams log-port as opposed to calling it what it is, the child's stdout... <nckx>I thought the question was simpler. Yeah, a good first step. *attila_lendvai_ kindly pings civodul for guidance ***attila_lendvai_ is now known as attila_lendvai
***wielaard is now known as mjw
<bost>2022-09-26 13:34:52 ERROR 404: Not Found. <bost>I guess the bc072c9 is not generated yet, right? So then, how can I see which is the latest existing binary I can download? <civodul>bost: ah, that file doesn't actually exist <bost>civodul: but I'd really like to use the devel version, so that the `guix pull` on the machine where I'm going to install Guix won't take so long <civodul>i think there's a short URL pointing to the latest one, but i can never remember it <bost>civodul: thx. Also, I'm finding out I could try to build an installation image myself. `guix system image -t iso9660 gnu/system/install.scm` could do the trick... I'm trying it now. *bost is probably in the process of terribly messing up his Guix machine... ohje. <minima>i'd expect a file gets created under my home, but it doesn't <minima>sorry, i should have said that i've been testing this in a guix home container <minima>i do see log files being created under ./local/var/log/ <minima>including a shepherd.log and mcron.log <minima>the shepherd log file says that mcron has regularly started <minima>if i replace '(system* "date" ">" "/home/user/test")' with '(system* "echo" "hello")', then i see that message printed in the mcron log file, once a minute <minima>do you think i should be including some modules for "date"? <minima>oh well, i can try with "date" (with not parameters nor redirection to file) and see if that prints something <minima>oh ok, that works - so it's nothing to do with missing dependencies <minima>i must be using 'system*' improperly <jpoiret>minima: system* doesn't run the given args in a shell <jpoiret>so the stdout redirection won't make sense <jpoiret>either use system, or use system* but start bash with the proper arguments <minima>oh i see... that makes sense, thanks jpoiret <apteryx>civodul: hi! you were able to reboot overdrive1? <apteryx>because there's one thing which seems off; I'd expect 4.5 GiB of swap, but it shows as 0.5, so it appears to be missing the latest addition (4 GiB of ZRAM) <civodul>apteryx: nope; like i wrote, it was rebooted ~12h ago, so i thought you had rebooted it after all? <civodul>it did reboot 10h ago anyway according to 'uptime' <civodul>i can reboot it right now, and if it doesn't reboot, i'll take a look when i'm back home in a few hours <apteryx>I think we should reconfigure it one last time, since it never really succeeded for me, due to the issues reported <apteryx>I'll reconfigure locally to avoid these other issues <civodul>apteryx: yes, i'm reconfiguring with "guix deploy", chasing that second bug while at it <apteryx>I'll punt on reconfiguring it myself then; let me know if that's needed post investigations <apteryx>after a reboot there should be 4.5 GiB of swap <civodul>alright, i'll let you know when i'm done *attila_lendvai tries to use guile's open-pipe* from a shepherd start GExp *attila_lendvai realized that open-pipe* is hopelessly inadequate, and will need to duplicate the forkexec machinery <civodul>attila_lendvai: what are you trying to do? <rekado>attila_lendvai: I don’t know what you’re trying to do, but it seems to me that the shepherd launch mechanism is the wrong location. <rekado>if you want a process that communicates with the outside world wouldn’t it be better to make it listen/respond on a socket? <rekado>then shepherd wouldn’t need to know anything about it. <jpoiret>i concur. please do not duplicate the forkexec machinery, it is a dead-end <attila_lendvai>civodul, i want to start a service process so that i can talk to it through a pipe. i.e. a fork+exec-command that does not redirect the child's stdout into a log file, but rather spawns a fiber that processes the stdout of the child, and writes stuff to its stdin in response <jpoiret>you'll likely encounter more issues than you'll solve <attila_lendvai>rekado, unfortunate that part is outside of my control. the service has an stdio based UI that i need to talk to <jpoiret>oh, so you want some O_NONBLOCK pipes iiuc? <attila_lendvai>jpoiret, i think blocking pipes are also ok, because the messages exchanged are small. <jpoiret>the issue is not only the size but also the delay <jpoiret>but yeah blocking shouldn't be that big of an issue <jpoiret>how is open-pipe* inadequate for that use-case? <attila_lendvai>jpoiret, setting the user/group of the child process, rlimits, etc. i.e. all the stuff that fork+exec-command does. <attila_lendvai>basically, i think what i need is a fork+exec-command that is slightly smarter, and allows me to provide a fiber to process the stdio (as opposed to treating it as a log stream) <civodul>hopefully fork+exec-command lets you do that? <attila_lendvai>civodul, i don't see how. it unconditionally spawns a fiber that calls either service-file-logger or service-builtin-logger <attila_lendvai>it also insists calling the child's stdio streams as log-this-and-that. but i see a way to reshape it into something that allows for a custom fiber that defaults to handling the child's stdio as a log stream, but it would be an extensive change affecting the API <attila_lendvai>and frankly, when i first encountered it, the #:log-file stuff was confusing me badly until i realized that it's actually the child's stdout <attila_lendvai>civodul, i think what i'm asking here is whether this above makes sense, and if it does, then whether you're at all open for proposals (in the form of a patch) that reshapes fork+exec-command into something more generic that accommodates for my needs <attila_lendvai>if you're open, i'll try to hack on shepherd. but if you find this hairy, then i'll just duplicate the machinery, and reshape the copy <apteryx>oh, qemu test failure: 32/619 qemu:qtest+qtest-aarch64 / qtest-aarch64/migration-test ERROR 161.19s -> killed by signal 6 SIGABRT <attila_lendvai>hrm... thinking about it, i think i should just duplicate, reshape, see what the end result looks like, and then decide whether to propose it upstream or not. that would also make development much easier than hacking shepherd itself. *attila_lendvai sets out to define a (shepherd service2) module in his own repo <civodul>attila_lendvai: it's unusual for a 'start' method to talk to the daemon (?) over a pipe, that's for sure <civodul>but then i'd expect fork+exec-command to accomodate your needs, it's already pretty generic <civodul>dunno, we'd need to discuss the service you're looking at in more concrete terms :-) <civodul>it doesn't look like something we've needed so far <civodul>attila_lendvai_: looks quite complex; the bottom line is that service startup must be non-interactive <civodul>and secrets shouldn't go in the store ***attila_lendvai_ is now known as attila_lendvai
<Luk6655>Does anyone know which package is responsible for the locale in guix? I'm currently running on a foreign distro so I don't have system's packages. During package builds I sometimes get an error that it couldn't open locale. <jpoiret>civodul: regarding 58036, it seems that operating-system-initrd-modules is accessed in machine-check-initrd-modules without any system parametrization on the host, so the thunked field is not evaluated in the right dynamic environment <jpoiret>i don't have anything to test it on, but I think that may be the reason <civodul>(more or less; i keep being interrupted) <civodul>those parameters/fluids are terrible <jpoiret>and the thunked field mechanism isn't widely understood i think, which just makes it seem like magic incantations <jpoiret>i'm afraid we'd need monadic values :) <jpoiret>to be more precise, reader monad to the rescue! <jpoiret>the nice thing about using a monad in this case is that you *have* to "parameterize" to get the value back, you can't pretend there's no dependency <jpoiret>the bad thing is, you'd have mvals everywhere <jpoiret>usual haskell hell with monad lifting everywhere <civodul>but we can do "monads without monads" so to speak <jpoiret>but operating-system definitions don't have such a system for now, maybe they should ***ft_ is now known as ft
<civodul>we need system tests for "guix deploy" <civodul>i'd like to have one that spins up two VMs with one deploying to the other <civodul>but i can't remember how to wire two QEMU instances network-wise <jpoiret>i'm the most basic qemu user, i wouldn't know how to do that either <apteryx>civodul: I sometimes wanted that too (two different systems talking to each other in a system test) <civodul>i'm pretty sure i've done it before, i just don't know how <apteryx>with the xvnc-service-type in review I ended up using only one os, VNC'ing to itself. <apteryx>perhaps you could guix deploy to localhost... <jpoiret>wondering if anyone has ever tried using proot instead of linux namespaces, and if that had an influence over building processes in general <civodul>jpoiret: PRoot is used by "guix pack -RR", but it's a sledgehammer <Maya[m]1>I have been experimenting with guix api trying to implement a new service type, but every time i try to reconfigure my system the whole machine freezes on “building upgrade-shepherd-services” <jpoiret>oh, damn, i thought the performance impact would be lower :( <civodul>that said, the New Daemon in Scheme™ could do like "guix pack -RR" and have several backends <jpoiret>yes, that's exactly what I was thinking of <lechner>civodul: Hi, opensmtpd was the only mail server i could get to work in Guix. What do you use, please? <civodul>lechner: nothing! i don't run a mail server <jpoiret>i don't seem to have user namespaces on my laptop (the sysctl knob kernel.unprivileged_userns_clone doesn't even exist), so I was looking at other solutions <jpoiret>Maya[m]1: could you paste the relevant file at paste.debian.net? <civodul>Maya[m]1: hi! this looks weird; maybe you could try "guix system extension-graph config.scm | xdot -" first to view your service extensions? <Maya[m]1>jpoiret: yes, give me a second i need to hard reboot my laptop again lol <lechner>civodul: okay, thanks! as the unhappy owner of some WD drives, i could not live without email notifications from smartmontools <Maya[m]1>the freeze happens even if the shepherd services are not started <civodul>Maya[m]1: you're 'stop' session should look like: (shepherd-service ... (stop #~(lambda _ (exec-command ...)))) <civodul>that is, with the 'exec-command' wrapped in a lambda <civodul>without it, you end up calling that 'exec-command' at boot/reconfigure time, when the config file is read <civodul>also, the 'stop' method must return #f to indicate that the service was actually stopped <Maya[m]1>now I managed to break another part of my system :) efibootmgr reports no space keft on device and I can’t reconfigure my system :))) <jpoiret>you have to delete dump files in /sys/firmware/efi/efivars/ <jpoiret>the efivars get filled with dump files for a reason I can't remember <jpoiret>you can just rm the corresponding files <Luk6655>I'm just wondering, is it possible to host substitutes via a static web server(like on aws s3), or is additional functionality always required to make it work? <jpoiret>look at which files you're deleting first <jpoiret>you'll maybe need to reboot (or just remount the efivars, not sure) <apteryx>rekado: seems the bandwidth has increased from ci.guix.gnu.org? <Maya[m]1>jpoiret: it’s great when you say reboot, since grub firsthand purges the old entry, so there’s no way to boot the system :D (oh well time to boot my guix usb stick) <apteryx>rekado: qtbase-6.3.1-debug 287.7MiB 9.2MiB/s 00:31 [##################] 100.0% (the other side of the Atlantic) *apteryx didn't asked for qtbase:debug to be downloaded but... *unintelligible grumble* <pkill9>Luk6655: yes it is possible, someone did that as a test for serving substitutes over ipfs <Luk6655>pkill9: I don't suppose there is a description how they did it? (or perhaps an irc log etc?) <Luk6655>ok, just knowing it is possible it makes me want to try it some time <Luk6655>Also, reading about guix publish I found a bit in the manual that guix will mirror source tarballs too, this is an interesting <minima>hi, i've got a bunch of locale and guix related env variables that get defined in my '.bash_profile', https://paste.debian.net/1255076/ - do you think i still need those when instantiating my bash via guix home and 'home-bash-configuration'? <Luk6655>I have a local slow-but-big hdd where I store large files to avoid re-downloading them over my not that fast internet connection, perhaps looking at this code will help me implement some sort of cache that integrates seamlessly with existing package definitions <jpoiret>minima: the guix home bash configuration should be able to do all of that automatically <pkill9>my log suggests it was ixmpp that did the ipfs thing <jpoiret>if not, I'd say this is an issue on guix home's part <minima>jpoiret: this is great to hear! thanks <yewscion>Is anyone online right now who knows more about AVX2 and how the substitute servers specifically compiles the x86_64 target? <minima>i'll see if it works then and if not, i'll raise a bug <jpoiret>yewscion: generally things built under guix should not use recent CPU microarchs <Luk6655>pkill9 thanks, I'll search the irc logs, perhaps I'll find something <yewscion>I have been made aware of a possible issue surrounding a package I contributed to Guix a bit ago, and want someone who feels more comfortable around these particulars to weigh in, if it's not too much trouble <minima>but i suppose i still need to explicitly 'export PATH="${HOME}/.local/bin${PATH:+:}$PATH"' <minima>or is that also taken care of by the 'home-bash-configuration'? <Luk6655>regarding that local cache, I know one can specify in package definition a location like file:///some/directory, it would be great if one could specify a system-wide storage folder where guix would check for the file firs, and download it only if needed <jpoiret>minima: you should be able to add the extra path in home-bash-configuration <minima>excellent, thanks, i'll add it there - ty!! <yewscion>jpoiret: Ah, okay. Assuming a package definition was configured and built properly on the substitution server with -march=native, would that be likely to cause an issue with users that are attempting to use it? <jpoiret>if the servers do have CPU extensions, that will optimize the code to use them, which would end up with unusable binaries for people without those extensions <jpoiret>you might need to disable that particular target/optimization <jpoiret>people who do want to use those optimizations could use package transformations, you could even provide them yourself <jpoiret>if -march=native is enough, then you're already covered by --tune i think <yewscion>Copy that, I will submit a patch for cbqn then so that it specifically targets the safer option, and include a transformed package for the extension. <jpoiret>it's possible that they might not accept that patch though <jpoiret>you might want to patch it in Guix only <jpoiret>maybe I sound too defeatist, but people generally like their "just run make and it works" approach, even if that means sacrificing reproducibility <jpoiret>rather, it sounds like you're doing `make o3-singeli`, when you could be doing `make o3`, right? ***Dynom_ is now known as Guest8266
<yewscion>jpoiret: Sorry, I meant submit a patch to Guix. I believe the default (as the it is listed first) is o3. I would still explicitly specify o3, in case the default changes, but I would submit a patch so the cbqn defaults to an o3 build in Guix. <jpoiret>oh, I completely misread your sentence then, sorry <yewscion>But yeah, the o3-singeli target apparently requires AVX2, and so should not have been the default. I wasn't aware of that when I submitted my packag.e <yewscion>I'll open an issue with a patch sometime today. <yewscion>Is there a more-canonical way to denote a derived/transformed package than just adding a suffix? If I want to have a transformed package for cbqn in my patch (with the base package being cbqn) should it be cbqn-avx2, cbqn/avx2, cbqn+avx2, or something else? <ekaitz>Hi all! Any idea of when are the talks from the 10 years event will be available?? <ekaitz>I'm interested in some of them I didn't have the chance to watch... :( <minima>this is mostly the result of me randomly typing characters and see if it works - it turns out it's not a very efficient strategy <minima>ok, i think i'm not supposed to use 'system*' (nor 'system') <davidl>lechner: there is a guix branch called wip-postfix that might be of interest, and there should be some email thread on the mailing lists about it. rekado rebased it not so long ago, but I don't think it got merged to master. <pseudonymous>So, I'm correct in understanding that guile has no package manager of its own like CL has asdf/quicklisp and Racket has raco. .. ? Packages are essentially distributed as tarballs to be installed manually into site-directories or through guix ? <lechner>davidl: thanks for the pointer! as a sidenote, I am actually happy with opensmtpd <davidl>lechner: youre welcome :-) do you mind sharing your opensmtpd config? I have a setup with postfix, but not on guix, but wanna switch to guix, but Im unsure about getting opensmtpd up and running as I want it to. <yewscion>pseudonymous: The equivalents for guile scheme would be hall and akku, if You want to check them out. Neither are as popular as quicklisp or roswell, though. <davidl>jpoiret: there was guildhall before right? Is that project dead? <jpoiret>isn't that just some tool to help setup autotools-based tarballs? <jpoiret>it's nowhere near other package managers afaik <jpoiret>akku does seem to fit the bill though, hadn't heard about it <yewscion>jpoiret: hall (never used guildhall) has actually been moving towards working directy with guix; The default usage installs a guix.scm file that targets all of the *.scm files in the project directory. <yewscion>So, depending on the usecase, it could be used to shim something like an npm install: Just add any guile module in guix to the hall project, and guix works behind the scenes to make it so. <yewscion>But yeah, even so, nothing as cohesive as quicklisp or roswell. Early efforts, maybe. <lechner>davidl: hi, i have three configurations: MTAs that authenticate with and forward to a relay (five lines in opensmtpd), a relay serving about a dozen virtual domains that signs outgoing mails with DKIM (a bit harder), and a backup mail server. which one are you interested in? <davidl>lechner: idk if you keep it in git somewhere? Then I could look around if you send me a link. <lechner>davidl: if you have not used opensmtpd before, my recommendation would be to start small. i don't currently keep my machine configs in Git (although I would like to). here is 'guix system' config for the small forwarder. https://paste.debian.net/1255087 <lechner>davidl: the secrets file has the simple format lechner-desktop ${password} not sure what happens if the latter contains spaces <lechner>davidl: also, to be fair that that config currently only provides a local port 25, but does not work with 'mail' from mailutils out of the box. i set it up a few days and haven't had time to investigate. <lechner>davidl: my big mail server, however, has been running well since April. The Debian servers tell me occasionally that my mail server is blacklisted with Spamhaus due to a "localhost" HELO, but i have had no issues besides that ***ChanServ sets mode: +o civodul
***civodul changes topic to 'GNU Guix | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o civodul
<lilyp>attila_lendvai: where possible, we prefer the official tarballs <lilyp>that being said, if you just want to do the full bootstrap, I think you'd have more support <attila_lendvai>lilyp, this makes it much easier to test shepherd changes in a guix vm, and automatically gives SWH backups, too <attila_lendvai>hacking on shepherd in general is much harder than it should be. e.g. it doesn't have any logging set up, and swallows errors without logging them. <lilyp>and what makes it harder than it should be? <lilyp>hint: I believe it's only tangentially related to git <attila_lendvai>lilyp, add a (define my-shepherd (package (inherit shepherd-0.9) ...) and redirect its source to a local patched git checkout of shepherd, and use it in a shepherd-configuration inside an operating-system <attila_lendvai>or in short: easily testing shepherd in a VM, in a real environment (as opposed to running its test suite) <attila_lendvai>lilyp, the other thing is what i wrote about swallowing errors and turning them into (useless) localized error messages <lilyp>you can define your shepherd already, no problem there ***mark_ is now known as mjw
<lilyp>only one thing your patch changes is an actual nuisance; find out which <lilyp>and find out what it's missing <lilyp>I'mma start a huge compile job rn, so I probably won't be able to reply <jpoiret>attila_lendvai: isn't the (delete 'strip) in a completely random place? <apteryx>why is openjdk so fat? openjdk-17.0.3-jdk 262.5MiB <jpoiret>well, at least i don't think it should be conditionally deleted depending on the target system <attila_lendvai>jpoiret, oh, good point! that's a merge error on my part in one of the past rebases... thanks! <apteryx>lib/server/libjvm.diz takes most of it at 166.1 MiB <rekado>apteryx: bandwidth is really unpredictable. <rekado>apteryx: as far as the server is concerned nobody really challenges it. <rekado>from within the MDC network we see 300+MB/s; beyond the firewall the best I’ve seen is 30MB/s (via host europe) <rekado>and everybody else seems to get at most 2MB/s <rekado>I don’t know what to blame this on. <lechner>(violin sound) comcast in california gets 700kB per second, on average <podiki[m]>bordeaux has been better for me (east coast us) <rekado>from an AWS EC2 instance in Frankfurt I see something like 40MB/s <attila_lendvai>turns out that duplicating the fork+exec-command stuff in my own module in my own channel is not trivial, due to shpeherd's fibers module not available for the copied code... :/ will duplicate it in-place in a customized shepherd <minima>any idea on how to do something like this (or whether this makes any sense in the first place): '("LS_COLORS" . ,(<output of dircolors --sh here>))' <minima>actually no need for me to set 'LS_COLORS', as i found out <f3n1x>GNU Guix newbie here. Happy to share cyber-space-time <f3n1x> After my very first Guix install ... Installed Thunar, as long as it is capable of managing auto-mounting. <f3n1x>( An the plugin needed for). <f3n1x>Yet... when i insert a pen drive i cannot get to the files in there. What am i missing ? Thanks, thanks, thanks <attila_lendvai>f3n1x, i can reproduce: guix shell thunar, then start thunar from that terminal, and insert a pendrive. stuff like that gets printed: "thunar-volman: Unsupported USB device type "usb"." <f3n1x>Ah...in any case. How can i get onto to the pendrive files on the terminal ? *attila_lendvai won't be a new thunar user after all