<Apteryx>OriansJ: what is M2-Planet? An ARM board? <OriansJ>Apteryx: A C compiler that will allow guix to reduce the number of bootstrap binaries down to a single 300byte bootstrap binary <Apteryx>wooow! Impressive :). And what does self-hosting mean? <Apteryx>ok! pretty cool :) but wouldn't using a bootstrapped M2-Planet to compile M2-Planet lead to the same opaque chain of trust problem? <OriansJ>Apteryx: nope, since M2-Planet is simple enough to be bootstrapped from mescc-tools (which can be bootstrapped from the 300byte hex0 assembler) <Apteryx>cool! So it all starts with hex0, which is simple enough to audit? And then builds from that all from auditable sources? <Apteryx>(by auditable I mean human readable/unobfuscated sources) <OriansJ>yes. the hex0 assembler is written in hex0 with lots of comments and the resulting binary of it building itself is bit for bit identical <Apteryx>cheers for this accomplishment! Looking forward to see it put to use in Guix :) <Apteryx>so this thing (hex0) is a native x86 program in machine code? <OriansJ>well hex0 is a specification and this program is an example of an implementation and any alternative implementation of the spec will produce identical outputs given the same inputs <OriansJ>One could write their own version in C, lisp, perl or anything they want for any hardware platform desired and provided their implementation conforms to the spec the results will be identical <OriansJ>In short we are hitting the DDC part of DDC hard and by careful engineering every platform is able directly reproduce indentical binaries for everyother platform too. <OriansJ>Diverse Double Compilation; basically inorder for a trusting trust attack to not be discovered, the attacker would have to compromise all implementations used in the test. And because mescc-tools and M2-Planet are platform neutral, we can in theory use arbitrary hardware that someone decideds to make out of TTL as a hobby if we so desire. <Apteryx>the approach sounds well thought out! <OriansJ>well yes, it is the result of about 2 years of work for a team of 3 <OriansJ>with janneke's mes being the next piece in the chain, giving us a full source path to gcc <marusich>OriansJ, congratulations! That's really awesome <g_bor>I've found a test in java-testng, that seems to be definitely not well written. It has a race condition, that sometimes triggers test failure. <g_bor>What should be done about that? <g_bor>In the meanwhile I got positive response from the java-jeromq team. We are now tracking the test failures on github, and a possible fix has been created. <marusich>g_bor, we should probably disable tests that fail non-deterministically, and possibly report the issue upstream. <marusich>Preferably we will disable only those tests which fail non-deterministically, rather than all the tests. <marusich>If they are probabilistic failures, another option might be to modify the tests so that the probability is "low enough". <g_bor>The test basically starts 40 threads, and check the event log, that all 40 started. The problem in this case, is that one of the methods starts to execute before all is started, polluting the event log, and failing the test. ***einarelen_ is now known as einarelen
<einarelen>Is there any concept like devel-versions of packages in guix? <OriansJ>einarelen: yes, many packages have -git versions of themselves <einarelen>Maybe I was unclear, meant more like fedoras libblah-devel or debians libblah-dev which you have to install if you want more than just the shared library <einarelen>I'm guessing that -git versions gets the latest from the development branches? Handy ifso <OriansJ>einarelen: all of our packages provide full source and headers and that is usually the difference with -devel in distros like fedora. So effectively all of our packages are the -devel version you are interested in. <adfeno>I would also extend this question of "-devel" version to "-dbg" versions of a package. <adfeno>So our packages provide the debug symbols/headers also? <OriansJ>adfeno: well, the -dbg would simply be a matter of passing the flags to have the build process include the debug information in the final binary. and the selection of to do that or not is ultimately up to the package maintainer but it is trivial to create your own derived package which changes that. <einarelen>@OriansJ Great to hear, I have always been frustrated by this in other distros <OriansJ>einarelen: guix if by nature a full source distro and binary packages are considered optional substitutes that you can independently built bit for bit duplicates should you so desire. <OriansJ>In many ways guix is designed for people building software and wanting to have more control over their build environments. <einarelen>Im looking forward to being able to mess around with it :) <ng0>adfeno: a very small number of packages here has debug symbols <ng0>you want to create local versions to get that <ng0>and remove the stripping phase if you're not getting useful debug symbols <einarelen>Im guessing you more or less have to write your own systemd service files for stuff installed by guix? Am I correct? :) <snape>einarelen: Guix doesn't use systemd, it uses GNU Shepherd instead. You can write your own service files, but it's probably better to contribute them ;) Existing services are in gnu/services/ <einarelen>Can shepherd and systemd coexist in a foreign distro? <snape>no, there can be only one init process (PID1) <pkill9>i think that's more of a question about if multiple init systems can coexist on that particular distro than about Guix <snape>well I'm not sure, but I think it doesn't make sense <einarelen>Figured. Shame, would prefer to use shepherd but Im stuck with fedora for now <snape>then you probably need to write your own Systemd files ;) <snape>you can use systemd existing files with Guix binaries, too <einarelen>That is what I've been doing although I had to change a bunch of paths etc <alex-vivo>Hello everyone, for some reason, the icecat substitute has been specifically failing to download after about 5-10 seconds of downloading citing some problem with gzip reaching end unexpectadly. I have resorted to compile it by hand since this is a new system and I need a browser. Is this issue known? <Apteryx>alex-vivo: by compile by hand, do you mean using --fallback? <Apteryx>alex-vivo: I think Ludovic and Ricardo are experimenting with Cuirass (the build server software) and sometimes it produces invalid substitute archives. You might want to ping them about the issue if it doesn't get resolved soonish. <Apteryx>usually it's just matter of clearing the bad archive on the server and regenerating it (IIUC). <Apteryx>rekado_: have you ever user SuperCollider? <alex-vivo>Apteryx: alright will try. Do you know if Iceweasel will get packaged for guix? It is Parabola's firefox rebranding getting rid of non FSDG parts and it happens to track the stable mozilla release. Icecat as is is a bit behind. <Apteryx>Icecat tracks the long term supported version of Firefox. Nothing gets packaged unless someone gets around it, hint hint ;) <Apteryx>I'm not aware of someone working on it. <thomassgn>Hey, guix lint tells me "the source file name should contain the package name" but e.g. gtk.scm contains lots of packages other than gtk... what's happening here, or rather - should I put some exports field or similar in the beginning of my package def. source file? <alex-vivo>Apteryx: I see, heh, well if I get icecat to work then I can at least read the docs on packaging for guix and then we'll see. What is the protocol for trying to contact the people you mentioned, Ludovic and Ricardo, I don't see them in this irc room, so mail list? <Apteryx>alex-vivo: they usually hang in this channel during day time (Europe). Ricardo is rekado and Ludovic is civodul. <alex-vivo>Another question I had is with regards to the i3 wm used here. After I log in, i3 shows a wallpaper that say "Logging in..." right in the middle of it, yet doesn't go away after any period of time. Is this just a gag since the wallpaper itself must have that writing as part of it? <alex-vivo>Apteryx: cool, will try to ask them about icecat if I catch them. <Apteryx>sneek: later tell civodul alex-vivo reported that the substitute served for Icecat fails with some error related to gzip reaching end unexpectedly. <Apteryx>alex-vivo: ^^ example of how to ping someone not in the channel using the sneek bot :) <alex-vivo>Apteryx: that's pretty cool :) is there a --help for sneek to see what it's capable of? <adfeno>OriansJ: Guix and debug symbols: Thank for the answer. :D <alex-vivo>Apteryx: how do you how it works then? Just say stuff at it? <Apteryx>the two things I know about it are 'later tell X /yourmessage/' and 'botsnack' ;) <thomassgn>I think that was how I got it to tell give me usage <thomassgn>Is the gzip reaching end unexpectedly a current problem? cause I think I saw that during an upgrade the other day. Unfortunately I changed something and just restarted the build without thinking about it and I don't think I've seen it after that... <alex-vivo>thomassgn: I encountered it while trying to install icecat. Had to resolve to the --fallback method. <thomassgn>hehe, yup. Remember when I was using gentoo. Every time there was an update to webkit or icecat, my laptop would spend 2 hours compiling. And that was when I wasn't doing any other work with it... <thomassgn>the only other thing that took so much time to compile was the kernel. But I updated it so seldom, webkit was like at leastonce a week <alex-vivo>BTW the installation guide at the end, after `guix system init /mnt/etc/config.scm /mnt` specifies that one should run `guix pull` in order to update the system and `guix system reconfigure` after that. While guix pull, obviously works, the system reconfigure doesn't without a file or something? I'm not really sure how it works. The info pages told me to use `guix package -u` instead and that has worked ok. What did the wiki mean? <thomassgn>oh, guix system needs a config file, like guix system init and similar <alex-vivo>thomassgn: yeah the infamous gentoo compilation. Out of all packages I wanted to have a binary it was my browser and what luck did I have! <thomassgn>so do a 'guix system reconfigure /path/to/your/config.scm' <alex-vivo>thomassgn: does it need the global one at /etc or manifest stuff also supposed to work through it, which I assume is like the one in /etc but for the user at hand only. <alex-vivo>Are you guys using guix with some other distro or on GuixSD? <thomassgn>it wants an operating-system, so no manifest. <thomassgn>guixsd here. You can also be dirty and just put your config whereever, but I guess /etc/ is the recommended place. <alex-vivo>thomassgn: nice, I'm running a fresh guixsd at the moment to test it, but don't really see why I can't make this my daily driver, after getting used to packaging. I've been running void linux as of late anyway so am used to unorthodox OSs, but this is definitely the next level. <thomassgn>switched from gentoo to nixos in 2015 I think. Then to GuixSD a year ago ish, or maybe more. Don't remember <jayspeer>thomassgn: What made you switch from gentoo? <pkill9>what made you then switch from NixOS to GuixSD? <gtoast>Does anyone have instructions for installing guix on ubuntu? I don't know how to translate the root user commands to Ubuntu where there is no root directory and barely a root user. <thomassgn>had been looking into config management for a while and tried to learn cfengine, but it's difficult. and when I heard about nixos it was just what I wanted <jayspeer>thomassgn: Now knowing guix, would you recommend sticking with gentoo + guix or running guixsd? <jayspeer>Thanks. I'll play around it a little bit more on my secondary machine and switch on desktop later <thomassgn>thing is, on guixsd, when (not if :P) I fuck up I just roll back or reboot into an older generation. when you fuck up on gentoo... youre screwed... <pkill9>thomassgn: what amde you switch from NixOS to GuixSD? <pkill9>oh sorry, you posted that article <alex-vivo>holy crap, icecat compiled, the interwebs await! <alex-vivo>thomassgn: thank you for the insight, I will check out your article. <jayspeer>Question to people running GuixSD: How to add exwm entry to slim? After installing exwm I cannot choose it when logging in. <pkill9>i'm thinking of switching from slackware+Guix to guixsd <alex-vivo>Alright, so icecat isn't able to load anything. Cites `Content encoding error: the page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.` Has anyone seen this before? <jayspeer>Ok, I'll try rephrasing it: There is a file in /gnu/store/something-exwm/share/xsessions/exwm.desktop. I need a symbolic link to it from /run/current-system/profile/share/xsession. Any idea how to accomplish this? Aside from doing it with ln -s, which is not the brightest idea. <amz3>gtoast: I replied on #guile, just do 'sudo su' <ng0>so... stupud question, but: if I set up offloading on a Debian host, do I need to guix package -i guix for the user that is defined as the user to build? I'm running into this really annoying horrible GUILE_LOAD_PATH issue again, with .guix-profile/etc/profile sourced AND guile-readling + guile + guile-ssh installed <ng0>locally, on the server, the test for the guix module succeds <OriansJ>jayspeer: did you add exwm to your package list and then do a guix reconfigure? As that should create the link required. <gtoast>amz3: Thanks! Didn't see your response. Will that allow the linking of the root profile? Several commands ask for files out of the root users home dir. My understanding is that there is no root home directory on Ubuntu. <alex-vivo>OriansJ: not the op, but if simply installing with guix package -i, would it not do the reconfigure step? I'm just worried that I install a lot of software like that, so maybe some of the issues I have are from this discrepancy. <ng0>frustrating... I'll continue tomorrow. <amz3>gtoast: there is a /root/ directory. Simple do the following: 'sudo su' then in the new prompt do 'cd && pwd' <einarelen>Is there any way to speed up/skip the manual page database creation step when installing packages? I'd like to install one package at a time but having each install taking 40 extra seconds is kind of annoying <OriansJ>alex-vivo: guix package -i only installs the program into your own personal profile and not any others <snape>OriansJ, jayspeer: I didn't follow the whole conversation, but it's useless to do a reconfigure to install exwm. <snape>jayspeer: you just install exwm, and add "exec exwm" as the last line of your ~/.xsession <jayspeer>snape: tried it did not work, I had some error with slim. <snape>has your ~/.xsession +x rights? <snape>and a shebang? (#!/bin/bash) <jayspeer>however I reconfigured my system as OriansJ said and it works, with added bonus of having it for other users. wigust: yes <wigust>jayspeer: GuixSD has only ‘#!/bin/sh’ by default, no ‘#!/bin/bash’. <jayspeer>However workarounds always exist, I can happily shitpost from within emacs <snape>jayspeer: oh right, for multi user setups it's definitely not useless, my bad <jayspeer>snape: multiuser as in me, myself and I ;) <snape>ha! Anyway one of the points of Guix is that users can install softwares (includeing WMs) as non-root. <einarelen>Anyone else having trouble with installing texlive? :( <einarelen>Doesnt seem to be able to download either the binary or source version <lfam>alex-vivo: Do you still have the exact URL of the IceCat substitute that failed to download? <shpx>`guix package --search="my query"` <wigust>einarelen: What are commands you invoke? <shpx>why do you have to make it so complicated <einarelen>guix package -i texlive, or, guix package -i texlive --fallback <alex-vivo>shpx: guix package --show=<package name> #detailed <shpx>but I don't want to type package or dashes <shpx>probably too late to change this of course <wigust>shpx: guix is not only a package manager, but a system/vm/container/workflow/‘what else’ deployer <alex-vivo>shpx: not gonna disagree, but there still has not been a single stable release and wrappers are normal. apt-get apt-search apt-repositor apt-key etc. etc. are pretty annoying too, that's why there is apt and aptitude. Wait for the toolkit to develop and be a positive movement in that if you have the time and the gut <alex-vivo>wigust: I'm not sure how to replicate the issue since I now have icecat installed and don't see under guix package --help a way to reinstall. It was using the default hydra/gnu repo. No configuration was done on my part. Fresh GuixSD install not even 12 hours old at this point. <atw>lfam: "guix substitute: error: corrupt input while restoring '/gnu/store/32yzy74zfh4r6w96k56bh366hm1rqrqz-icecat-52.3.0-gnu1/lib/icecat-52.3.0/browser/omni.ja' from #{read pipe}#" is what I saw. I'm using --fallback now. <wigust>alex-vivo: Sorry? I'm possibly the wrong guy you want :-) <atw>Pure coincidence that I'm also upgrading atm ☺ <lfam>atw: Do you know which server it came from? <lfam>Like, berlin.guixsd.org or mirror.hydra.gnu.org? <atw>Uh, should be the latter, judging by the substitute URLs in my scrollback. What's the official way to check? <lfam>The scrollback :) I'll try figuring it out from here <atw>I mean, I don't think I added berlin, but how can I check what my substitute servers are? <lfam>I checked and it's from the hydra mirror <lfam>I'm not sure how to know which substitute servers the daemon might query, but the list of signing keys in /etc/guix/acl is what determines where you'll accept substitutes from <fr33domlover>Hi! I'm using Guix on Debian Jessie, looks like some programs I install with guix package -i don't recognize Let's Encrypt certificates <lfam>Berlin is authorized by default atw <fr33domlover>(I installed darcs from the debian repo, and there it does recognize the cert) <lfam>fr33domlover: Did you do the x509 certificate setup mentioned in the installation instructions? <lfam>Also, does it happen with any other programs, like curl? <lfam>I see a comment in our darcs package that it doesn't support HTTPS :/ <fr33domlover>lfam, yes looks like there's some issue with curl too hmmm <fr33domlover>curl: (60) server certificate verification failed. CAfile: none CRLfile: none <alex-vivo>wingo:oh damn my bad, yes I meant someone else <fr33domlover>lfam, yay i think i fixed it for curl, i was missing a thing in .bashrc (I did one the cert dir but not the cert file defined there, maybe guix docs got updated since ^_^) <gtoast>so I ran the command to install the locales and now it looks like every gcc library known to man is being downloaded. Is this normal? <alex-vivo>lfam: sorry I ended up replying to someone else instead of you. In my case with icecate, it was with the hydra mirror, seems like what atw described is the same. <lfam>Thans alex-vivo, the corrupt substitute should be replaced soon <alex-vivo>Here's something else that confuses me. Pulseaudio was installed as a dependancy for one of the progs that my user uses. However, the user herself doesn't have pulseaudio in her path after the fact. In order to use pulseaudio they would have to explicitly install it. Does this create redundancy? Is this the normal operation. Does guix try to let programs use dependancies already installed on a system, even if I'm installing for a <alex-vivo>specific user that might now have any programs or dependancies that use a dependancy that was installed for another user? <lfam>gtoast: Accepting some exaggeration, it's normal to download some "extra" stuff after first installing Guix <lfam>alex-vivo: Programs should start pulseaudio "on-demand", so if there is already a pulseaudio running I think it will just use that one <alex-vivo>lfam: but what if I explicitly also want to use pulseaudio to change something, do I need to act as if I'm installing it from scratch? <lfam>I guess you have a few options. You could open your application and then configure the Pulseaudio it starts. You could install it with `guix package --install pulseaudio`, or you could just get it temporarily with `guix environment --ad-hoc pulseaudio` <lfam>gtoast: Building a profile requires some software, and if this is your first time making a profile (installing a package counts) then you may need to download the required programs <alex-vivo>lfam: thank you, I will explore those options further <pkill9>how would you configure the pulseaudio it starts? <lfam>I don't know how deep you can get configuring pulseaudio, but I can get the basics with pulsemixer <wigust>pkill9: pulsemixer is good as lfam mentioned, also check pavucontrol <Apteryx>do we have/need qtopengl in Guix or is it builtin qtbase? <atw>lfam: thanks for the work on the failing substitue. What was the issue? <lfam>atw: I reported it to the Guix sysadmins. Sometimes there is a problem transferring the substitutes to the mirror and they are truncated. That's usually the issue. I don't know if it's fixed yet <alex-vivo>If I was to run a script that uses `#!/usr/bin/env bash` what would I replace that with on guixsd? <Apteryx>or alternatively have a special file service create /usr/bin/env (I think this is covered in the Guix info manual). <Apteryx>like this: (extra-special-file "/usr/bin/env" <Apteryx> (file-append coreutils "/bin/env")) <wigust>alex-vivo: You could also run it as ‘sh SCRIPT’. <Apteryx>any idea what this failure could be due for? It happens during tests of SuperCollider, a C++/Qt application: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >' <Apteryx> what(): assign: Operation not permitted <alex-vivo>thank you I tried just hardcoding `$(which bash)` which worked, but need something more elegant, will look into what you guys explained <wigust>alex-vivo: yeah, ‘which’ could be not installed on the system <efraim>looks like the new recode doesn't work with enca <OriansJ>Apteryx: if you just add (service special-files-service-type `(("/usr/bin/env" ,(file-append (canonical-package coreutils) "/bin/env")))) to your list of your services /usr/bin/env will work again and no code changes will be required <OriansJ>Also minor question, does anyone know why packages in guix configuration files require cons* and will not work with list? Would it perchance have something to do with the (map canonical-package (list bash coreutils findutils grep sed diffutils patch gawk tar gzip bzip2 xz lzip)) in %base-packages <mange>They definitely can work with `list`, but you tend to want to use `cons*` to prepend the items you provide, rather than having a list of your packages with its last element being another list of elements. <mange>Because if %base-packages is a list, then (list nss-certs %base-packages) is effectively (list nss-certs (list bash coreutils findutils grep sed diffutils patch gawk tar gzip bzip2 xz lzip)). <OriansJ>mange: actually %base-packages is a cons* and should you replace the cons* with list, an error shows up during guix system init file /mnt <OriansJ>The big difference betwen cons* and list is the treatment of the last element which will cause bugs should you not properly test for termination cases. <mange>%base-packages is a list, isn't it? It might be constructed with cons* (I didn't check the code at all), but it's structure is a list. I was trying to show the shape of things, rather than the precise value. <OriansJ>mange: if you look in gnu/system.scm , you'll see (define %base-packages .. and the cons* used <OriansJ>what is more interesting is that if you don't include any additional packages and replace cons* in %base-packages with list, guix system init still breaks <mange>If you see "(guile) Lists", the definition of a list is "Either the empty list '()' or a pair which has a list in its cdr." The fact that it's constructed with cons* doesn't mean it's not a list. <mange>Which is my point. The special handling of the last argument to cons* means you're prepending, rather than leaving the last element of the list as a list iself. <OriansJ>mange: I am not denying that it functions like a list, I am just attempting to be specific since the difference between cons* and list is about termination. <mange>Surely that means it's entirely unsurprising that replacing cons* with list will break things? <OriansJ>mange: no, should the function that accepts the list do proper termination checking and cell evaluation even (list foo (list bar baz) bacon (list foo1 foo2) (cons* baz1 baz2 baz3)) will work correctly. <marusich>sneek, later tell einarelen Alex ter Weele has been investigating how to make it so unprivileged users on foreign distros and GuixSD can run services easily using Shepherd. Currently you can do so by starting your own Shepherd instance, but sadly you cannot easily re-use GuixSD-style services when you do this. If you're feeling adventurous, I'm sure he'd love additional help! See: https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00047.h <marusich>oh no, you didn't get the full url sneek D: <marusich>sneek, later tell snape Alex has been investigating how to make it so unprivileged users on foreign distros and GuixSD can run services easily using Shepherd. Currently you can do so by starting your own Shepherd instance, but sadly you cannot easily re-use GuixSD-style services when you do this. If you're feeling adventurous, I'm sure he'd love additional help! See: https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00047.html <mange>What do you mean "termination checking"? (list 'a 'b 'c) is different to (cons* 'a 'b 'c), so you shouldn't expect that a function will treat them the same way. In fact, in that example the cons* form isn't even a list. <mange>Whereas (cons* 'a 'b 'c '()) is a list. <OriansJ>mange: a single conditional with null? is all it takes for a function to be able to support cons* and list termination properly <atw>marusich: hey! I know I gotta respond to those emails <atw>marusich: re "you cannot easily re-use GuixSD-style services when you do this". My understanding is that this is because the GuixSD concept of a service is more general than a "Shepherd service". The latter is "a service that extends shepherd by making a shepherd config file". That's my intuition. <mange>atw: You're correct. The word "service" carries two distinct meanings, one for "system services" and one for "shepherd services". <mange>OriansJ: That works, but that function glosses over the difference between lists and "improper lists". I would argue it's being too liberal with its input. <mange>OriansJ: One of the guys I used to work with would write his Javascript to be very lenient with types. If you passed it the wrong type it would try to recover and continue, guessing what you wanted. It lead to a *lot* of bugs. <OriansJ>mange: I will not deny that being more tolerant of bad input can lead to possible bugs in the future. However the fact that guix allows services to be either cons* or list but packages does not and only allows cons* is not consistent and either services needs to become more strict or packages needs to be more flexible to be consistent with services. <mange>I'm pretty sure GuixSD requires both packages and services to be lists, doesn't it? I would have thought improper lists would fail in either case. <mange>In either case, I'm pretty sure the examples in the manual always end their (cons* ...) forms with a list (%base-packages for packages, or %base-services or %desktop-services for services), so the value of the packages/services field ends up being a list. <ng0>marusich: amz3 reported this for GNUnet, when we add the 'debug' output in GNUnet it is only useful when we disable the final stripping <ng0>didn't read the rest of the conversation. <marusich>atw, yeah I think that's part of it. But for Shepherd services, I imagine that on a foreign distro, you ought to be able to do a hack like use Guix to build the shepherd service you want, and then point your own shepherd config at the resulting start-up script in the store. but you'd still have to start shepherd by dropping start-up logic into your ~/.xinitrc or something. <marusich>ng0, ok, i will have to try that. thank you. <marusich>thomassgn, regarding "the source file name should contain the package name", I think Guix is advising you that the name of the source file used in the store (e.g., the one you see when you run "guix build -S the-package") does not look like the name of the package. You can resolve it by adding a file-name field in the right place; see "guix edit gnu-standards" for an example. <atw>marusich: I'm on GuixSD and I manually start my user's shepherd. I could automate it as you say. <marusich>I looked into automating it... It seems there are a million ways to do it. I wish there were just one easy way we could recommend. <marusich>I don't really need to run user services at this time, so I didn't dig much further. <mange>I just get xfce to start mine, instead of starting xfwm. <atw>Yeah, depends on if you want it to start on login, on graphical login... <marusich>atw, once you add the feature, we can just recommend the Guix way :) <mange>Yup, and those sorts of preferences are why we can't really have a "one size fits all" approach. <snape>wigust: I'm working on cgit :-) I really apologize for taking so long <sneek>snape, marusich says: Alex has been investigating how to make it so unprivileged users on foreign distros and GuixSD can run services easily using Shepherd. Currently you can do so by starting your own Shepherd instance, but sadly you cannot easily re-use GuixSD-style services when you do this. If you're feeling adventurous, I'm sure he'd love additional help! See: https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00047.html <ng0>marusich: see a recent post on the gnunet-developers@gnu.org mailinglist wrt "debugging GNUnet" or something <ng0>or the help list, idk <mange>For instance, I have my shepherd start my window manager (hence replacing xfwm), among other things. That clearly doesn't make sense if I'm logging in without an X server. Other things like my emacs daemon do make sense to start, even without X. <mange>I very rarely log in without X, so I just went with my most common use. <snape>marusich: this is very interesting, thank you! I do feel adventurous, but I feel very limited by time ;) <mange>Otherwise we'll need to solve the fun problem "what if they log in first in a tty, then open a graphical session?" <snape>wigust: I'll answer with how to implement the project-list as a plain-file <snape>if we don't do it it will be very inconvenient for the user, becuase they (those who use project-list) will need to manually edit files in /etc or so, unless they use special-file-service-type <wigust>snape: I kinda have an idea (based on dovecot and cups services) how to do this, but I'm not ready to do hack on this. <snape>The thing is: using plain-file directly in the user configuration doesn't work because it expects a string, and plain-file isn't a string, it's a file-like object <snape>so it has to be done either in the service itself, or not done at all ;) <snape>(or in special-file-service-type, but it's not very nice) <wigust>snape: Is the current Cgit implementation provides ‘project-list’? <wigust>snape: Sorry, I mean Guix's Cgit service <snape>the string is supposed to contain the name of the file <snape>but how does the user create that file? <snape>it's cumbersome, which is what I want to improve <wigust>snape: By current I mean what is in ‘origin/master’ now <snape>well, second solution is leave it for later, and not add it at all <wigust>snape: Yes, nothing stops to push our new implementation and work on ‘project-list’ later. <snape>wigust: I think you're right <snape>but it's not a big deal to implement <snape>as you wish. Either we comment it with a TODO note, or we leave it (but the users may use it and then undergo an API change), or we do it quickly together <wigust>snape: As I understand, “we comment it with a TODO note” means no ‘project-list’ field, so the user will not switch between ‘string’ and ‘list’ implementation. Yes, I think it's the best way we could go. <snape>I'll answer now the email then <sneek>atw, amz3 says: for your load path problem, you can setup guile load path in .guile I think <atw>amz3: I've found a solution that I like. It doesn't require me to make any changes when I add new guile projects to ~/src. I forgot to say that that was one of my goals <atw>I put this on #guile, but in case it's handy to anyone else: (setq geiser-guile-load-path (f-entries "~/src")) <atw>wigust: ah good, I'm not crazy. I was easily able to find a good generation though, so not a disaster ;) <atw>I'd be curious to know what the issue is. Bad upstream emacs? One of our patches?