<NieDzejkob>dejanr: SICP is fairly self-contained, so you could get away with reading only that, though The {Little,Seasoned} Schemer offer a radically different way of teaching some of the earlier parts of SICP. Either way, you can't go wrong with these books IMHO. <NieDzejkob>I'd also skim the guile manual to learn about the guile-specific extensions and SRFIs <nckx>TLS is certainly different. *nckx also recommends SICP. <nckx>NieDzejkob: Thanks. I'll report it. <nckx>guix lint: warning: while connecting to Software Heritage: host lookup failure: Name or service not known *jonsger has built a php-7.3 which should work with nextcloud :) <nckx>str1ngs: Yes, but it doesn't matter. <str1ngs>nckx: can you do lsattr ./gnu/store/06ybqkh3lb3g7c77b74izy32grglf45x-libx11-1.6.8/include/X11/cursorfont.h <nckx>str1ngs: Nothing interesting (only e). <str1ngs> and lsof ./gnu/store/06ybqkh3lb3g7c77b74izy32grglf45x-libx11-1.6.8/lib/libX11.so <nckx>Assuming you mean ‘check whether it's opened using lsof’: yes, it is, but I don't really care about that. <nckx>I care about the duplicate files or entries in the tarchive. <str1ngs>can you paste the exact error. because the unlinking part kinda makes it sound like it's in use. <nckx>That's probably it. I don't really care enough about that error to chase it down (or waste your time with it). <str1ngs>I'll see if we and read the tar header for the file someway that might help <nckx>The pasted bin is the interesting part. <nckx>str1ngs: That's the plan, just don't have time for it now. <nckx>I assume this is an invocation mistake somewhere in guix pack (calling tar c with duplicate arguments) but that's mere conjecture. <nckx>str1ngs: Install libarchive. *nckx needs to catch up on that thread, thanks for the reminder. <str1ngs>same error? or does it mention headers at all? <nckx>I mean: [GNU] tar: '--verify' cannot be used with '-t' | bsdtar: Option W requires an argument. Maybe this (libarchive's) is not the same bsdtar you intended. <nckx>I appreciate the help but can't dig into tar compatibility horribleness right now, I'll just upload the offending file. <str1ngs>nckx: I think -W is wrong for gnu tar sorry <alextee[m]>does matrix have something that lets you find which package a binary is in? <str1ngs>alextee[m]: that word require a cache of some kinda on the substitute server <str1ngs>alextee[m]: for files are already in the store you can do something like this. find /gnu/store/*/bin/bash <alextee[m]>str1ngs: i'm more concerned about the use case of trying to install a program but not knowing which package it's in <alextee[m]>guix search is a workaround that sometimes works <str1ngs>right, I figured that was the case. unfortunately the publish servers would need to cache that detail. <alextee[m]>well, sounds like a reasonable thing to include imo, but i guess guix likes to be minimal <alextee[m]>basically a guix search, but inside the provided file list <alextee[m]>maybe it's just a matter of having the package server cache this info and have a command in guix for searching it <nckx>I didn't (re-)read the whole thing but isn't that exactly what that thread is about? I certainly wouldn't support a silly index that only included /{s,}bin. That's useless indeed. <alextee[m]>yeah this thread is exactly about this. some good ideas in there <str1ngs>I think the sbin bin. was for manually adding programs to a package field I guess <str1ngs>it's tedious and probably would not stay accurate long <nckx>Oh god yes (as in oh god no). <str1ngs>I think extending nar sounds like an interesting approach <str1ngs>the issue is size. especially give how much can be built at a given time. <nckx>It would compress very well. An issue is how to include a compressed file list in a way that's not horrible. <alextee[m]>yeah i don't think size would be much of an issue, text compresses pretty nicely <str1ngs>flatten /gnu/store and put it in a traball. the package names are implied in the path namespace haha <nckx>(Note: I haven't actually tested this, maybe something really horrible does happen once the average nar exceeds a packet, this would need actual data to discuss.) *nckx sleepy for once. I think I will go to bed. Nighties all. <nckx>Totally not trying to avoid drakonis1. <nckx>drakonis1: I forgot to say: I couldn't find anything ‘wrong’ with gzdoom MIDI (I went into the menu and at least the timidity++ option worked). Could you pull and try version 4? <drakonis1>and as far as i know, gzdoom bundles soundfonts <drakonis1>nckx: fluidsynth: error: Failed to load SoundFont "gzdoom" and Failed to load patch set gzdoom. <str1ngs>that reminds me I need to fix timidity to work on foreign distro's <drakonis1>well, time to figure out how to copy these files to the correct location <Parra>leoprikler: I tried a new approach, refactoring the non-reproductible parts of my project when a Guix variable is setup and it seems it worked, I almost have it packaged right now, I still have one question, is it possible to use an input package and copy some contents of that input into the install path? Instead of having that package linked as a normal input <alextee[m]>seems that many of my patches are left for dead, kinda makes me not want to send any more (and theres a lot of music-related things i want to submit) <alextee[m]>maybe guix receives too many patches or something <alextee[m]>is there a policy btw of what should be included in guix? are all packages welcome? <drakonis1>tbf, poke some folks here to have them merged <alextee[m]>i guess i'll do that tomorrow, seems most people here an on european time <nckx>alextee[m]: No, we're just understaffed and need more people to review more patches (me included). <alextee[m]>what does reviewing involve? i could help checking licensing and stuff, but my guile skills are very low <alextee[m]>although i've made quite a few packages by now and i kinda got the hang of it lol <nckx>Well, ideally everything: applying the patch locally, sanity-checking the installed files & directory layout, making reasonably sure the programme(s) run (well), then reviewing the code and making sure guix lint passes. <str1ngs>alextee[m]: I found using emacs-debbugs helps for reviewing *str1ngs mumbles a chant for alextee[m] <alextee[m]>nckx: i could get involved with things like that for anything involving music-making (especially plugins) <alextee[m]>actually i am very interested in taking over that section lol <nckx>alextee[m]: Anyone can review patches they're interested in 🙂 A review doesn't have to be complete or end with a certain ‘LGTM’. <nckx>Ugh, I was writing half a GIT-VERSION howto in response to your VL1 Emulator patch but I see they're cut an actual release by now. Good thing we waited this long! <nckx>Could you sort the inputs alphabetically and make the description a full sentence (even if just by adding ‘The VL1 Emulator is…’)? Nitpicks but still. <nckx>You can use (commit (string-append "v" version)) if you aren't yet. BTW, seeing (commit "<an actual commit string>") in a package is almost never correct. Take a look at xss-lock for how it should have looked before the release. <nckx>I don't know enough about the situation to choose a side if that's what you mean 😛 <nckx>I think it's acceptable to ping Ricardo & ask if your argument is convincing. <alextee[m]>basically make 30ish separate packages vs a single one <alextee[m]>upstream has a meta-package for the purpose of packaging <nckx>I read your mail, but I can't very well convince Ricardo for you. <nckx>alextee[m]: Did setting CC=gcc as a make-flag not work? Also, DESTDIR=out PREFIX= is opposite from what's usually done. That's fine but it makes me curious for a comment explaining why we can't just set PREFIX=out. <nckx>And: could DISTRHO be packaged (eventually)? Or is that foolish? <alextee[m]>nckx: trying those now. no, many plugins have specific commits of it, some of them have forks of it with added functionality <alextee[m]>actually it can and i did package it (it comes with some useful example/debugging plugins) <nckx>OK. In cases where a bundled dependency is so heavily patched that it's not worth packaging on its own it's good to add that to the comment. <alextee[m]>noted. it would be repetitive though, i mentioned the full reason in one of the packages, i guess i should say "see zam-plugins for details" <nckx>So the same ‘patched’ distrho is still shared amongst multiple packages? <alextee[m]>guix build: error: mesa-timespec-test-32bit.patch: patch not found <alextee[m]>i get this when trying to build from the gnu/packages dir hmm <alextee[m]>nckx: no it's varying commits of it. plugin 1 uses version x, plugin 2 uses version y, and so on <nckx>I just meant a short ‘bundles a [heavily] patched version’ comment, not a full explanation of anything, by the way. <nckx>alextee[m]: That file was removed in December last year. I guess I recommend making clean-go & rebuilding your checkout. *nckx → AFK, hoping to have helped a little; thanks for your patches and your patience. ***spk121_ is now known as spk121
<leoprikler>Parra: is $package/node_modules really a good place to store things at? <leoprikler>I haven't looked at existing node packages to see how they are distributed tbh <leoprikler>Parra: can you patch metacall to directly refer to cherow.min.js rather than index.js? <raingloom>evolution no longer shows any emails since i upgraded it two days ago :| <raingloom>leoprikler: i have all my emails offline, so it should definitely be showing them <raingloom>mmm, older generations also don't work... might be a Gnome issue? <civodul>mbakke: looks like we'll now be able to use (git describe) in Guix :-) <mkoncek>Hi, i would like to ask whether and how you bootstrap maven in guix, do you truly build maven from sources? i tried reading maven.scm, but it is quite hard <jonsger>mkoncek: it's bootstrapped from sources otherwise it wouldn't be allowed in Guix <leoprikler>raingloom: evolution itself has not been updated since December, so maybe your config changed or one of its inputs <leoprikler>could it be related to nss-certs (updated 9 days ago)? <brown121407>Do you guys know if anyone is currently working to package one of the newer versions of the cinnamon desktop? <smithras>brown121407: If you don't get a response here maybe the guix-devel mailing list would be a good place to ask *civodul pushes a draft of a post about Guile 3 <civodul>mkoncek: i guess you could look at the output of "guix graph maven" (though it's huge...) <civodul>also, roptat has been working on it, so perhaps they can answer questions you may have! <mkoncek>we are interested in bootstrapping maven in Fedora so i would like to see how you did it <nckx>civodul: Typo: ‘and anyone who starts packaging software and anyone who starts packaging’ in the blog post you committed earlier. <nckx>civodul: ‘To be comprehensive’ sounds odd. I'd say ‘In all fairness’. <smithras>civodul: found a typo: 'and having interface for “everything” in Scheme' should either be 'having an interface' or 'having interfaces' <nckx>civodul: Does underlining (code staging, declarative modules) in a link look good? ‘most the upgrade work’ → ‘most of the upgrade work’. ‘trickled’ → ‘trickled in (or out)’. ‘change on modules’ → ‘change in modules’. ‘find themselves’ → ‘will find themselves’. ‘an in particular’ → ‘and…’. I'd write ‘Firstly,’ instead of ‘First,’. ‘Guile_3’. *nckx wasn't planning on reviewing, sorry for choosing the worst possible channel :) <nckx>‘and long live, Guile 3’ → ‘and long live Guile 3’. <nckx>civodul: Nice post (as always)! Thanks (as always). <civodul>smithras, nckx: woow, you were fast! thanks for all the fixes! <jonsger>civodul: your patch for the installer fixed the problem :) <jonsger>issues.guix.gnu.org seems to be down *jonsger found another bug in the installer :P <mjw>For Guix Days, do I need to register for dinner separately? <smithras>related question, is it too late to sign up for guix days? I didn't know if my schedule was free until yesterday <Parra>leoprikler: I'm using that location because of historical reasons, and it works, I'm not planning to change it though. Now there is one error remaining, but it's just an env var, I'm not sure if solving it from guix or from my install command, I think I will use the second one <kmicu>jonsger: does that ‘club’ have a system to automatically get x from my account? Or do I need to navigate the linked maze to figure that out? <efraim>i pay €10 in cash during Guix Days <alextee[m]>Hi, can someone look at/merge vl1-emulator followed by regrader? <civodul>mjw: for dinner we'll just book the restaurant and each one of us will pay there <civodul>it's not a Google-sponsored event ;-) <civodul>smithras: sure, you can still register! <jonsger>maybe we should ask SUSE or RedHat for sponsering :P <mjw>civodul, can do that. I'll just show up then :) <alextee[m]>can someone merge 39212, 38689 and 39213 (in this order)? <leoprikler>Parra: I don't mean changing it everywhere, I mean changing it for Guix specifically via `substitute*` <roptat>mkoncek: we have bootstrapped maven from sources, but we can't use it yet to build anything in guix <roptat>It's usable outside of guix, it will simply download the missing binary parts <roptat>I'm working on bootstrapping the build dependencies for maven projects and on a maven build system that could use them now <roptat>Basically, we ignore the pom.xml of all these dependencies, since we don't have maven yet. Most of the time it goes well, as we simply have to run javac on src/main/java ***sturm is now known as Guest69654
<roptat>To be honest, I had to look at a binary version of maven and compare results to make sure I didn't forget anything. Some packages are quite difficult to build properly <mkoncek>in our case it is even stranger because we use our own version of maven - xmvn and there are some mutual dependencies <mkoncek>the xmvn allows us to use poms without internet connection provided we built and generated the correct .jars in the system directories <Parra>leoprikler: I have seen the substitute command but I have no idea what it does, I'm just replicating the environment I have with Docker/Debian, and adapting the parts that are incompatible with Guix, can you explain me what's the usage of it? <leoprikler>substitute* rewrites a file in-place in a manner similar to the s command of sed <leoprikler>so instead of replicating your Docker/Debian amount in all detail, you can rewrite the source file(s), that depend on this particular path to refer to the actual file <Parra>the idea is: cherow is a local dependency for bootstrap.js, which is a dependency of node_loader, so it makes sense if it is on the loaders folder <leoprikler>makes sense, but with an installation it should probably be part of /lib or /share <leoprikler>I'm not sure about the where metacall loaders are installed, but aren't the put into /lib? <NieDzejkob>oh god, I just realized that civodul is Ludovic. `rev' is a good obfuscator <Parra>leoprikler: it is usually located in /usr/local/lib but it can be overwritten by an env var <Parra>I'm gonna download a new client, this one sucks on this phone <Parra>leoprikler: what client do you use for phone? <leoprikler>but if I read your thing correctly, you install the node modules into $prefix/node_modules, or did I misread? <Parra>mmm, node modules -g installs in <leoprikler>so you basically "build" index.js inside the local node_modules, which later gets installed to $prefix/lib <AndroUser2>I tried a new client, let's see if it works better <alextee[m]>like this i guess find-files file #:directories? #t <Parra>I've tried 5 clients, all of them sucks <leoprikler>IRC clients are a thing people just love to hate, it seems. <leoprikler>No matter how close they come to doing what you want, there will be just this one feature or whatever that ruins them. <Parra>leoprikler: right haha, but with this new phone the revolution irc does not work properly :( <Parra>I switched back to it though <Parra>and I will check logs from guix logs <Parra>I fear all I write gets published XD <leoprikler>I find it unlikely that I'd reveal information I later regret revealing here. <leoprikler>Discussions are about Guix/Free Software in general, nothing too controversial. <kmicu>Great one NieDzejkob ʕノ•ᴥ•ʔノ ︵λ𝛌𝚲𝝀 ***ng0_ is now known as ng0
<dongcarl>Anyone have experience working with musl on Guix? <lfam>Fun to chmod /dev/kvm to 666 in the middle of QEMU's test suite <civodul>NieDzejkob: thanks! there's a looong patch queue but one of us will get there hopefully soon <nckx>NieDzejkob: Does 39146 expect another patch to be applied first? I can't find ‘MOZ_SERVICES_SYNC=0’ in the commit log. <NieDzejkob>nckx: Ah, fsck, that's my personal patchstack interfering because the changes got to close. I'mma send a fixed patch in a moment <NieDzejkob>nckx: Sorry for that. I've sent a v2, it should reach you in a moment <alextee[m]>ping again :-) can someone look at/merge these (in this order)? 39212, 38689 and 39213 <moewe>Does i3lock{,-fancy} work for anyone here? <NieDzejkob>moewe: do you have a screen-locker-service for it in your system services? <nckx>NieDzejkob: Interesting that *FLAGS doesn't contain any -I/gnu/store-style stuff but OK. <moewe>NieDzejkob, no, is it not only a user package? <NieDzejkob>moewe: screen lockers need to be added to setuid-programs and sometimes /etc/pam.d, this is handled by the screen-locker-service <moewe>huh so I just need to add the service? <moewe>The docs say (screen-locker-service xlockmore "xlock"), but what is the difference between package and [program]? <nckx>moewe: By [program] do you mean "xlock"? <nckx>If so it's the name of the executable under /bin or /sbin (I forget which). <moewe>Is it because of workpower, or is there a certain reason why it's on 26? <moewe>i just have pulled and updated to 26.3 <moewe>oooh didn't know about that package, ty <lfam>Gah I screwed up sending a patch series 🤦♂ *nckx unhappy about missing Guix dinners this year. <nckx>pkill9: At the Guix Days in Brussels. <smithras>I'm curious to see how seating 30 people will work out ***services. sets mode: +o ChanServ
<lfam>I'm sorry to be missing them too, nckx :( <nckx>lfam: Hope you can make it next year. <lfam>Me too. I have to start planning for it really early <nckx>Same goes for everyone else, of course. *nckx understands how lucky they are to live in FOSDEM's guest room. ***drakonis1 is now known as drakonis
<lfam>Hey nckx, in what context should I run the Guix System tests with the new QEMU? Like, within QEMU? Or just on top of the git branch with the updated package? <mbakke>lfam: just "make check-system TESTS=foo" will do, where foo represents openssh, btrfs-root-os, etc <lfam>But I should run them all, right? <mbakke>running all system tests would take a long time, a few should suffice to stretch Qemu <lfam>For some reason doing them all wants mongodb <mbakke>probably because of the mongodb service test :) <nckx>lfam: Since this could affect networking I guess I'd run the network tests. It's up to you (if it were my time, I'd run them all, but mbakke's right that it's overkill). <lfam>And, is there a way to list the available tests? <nckx>lfam: I get the list of tests from grep -A1 system-test gnu/tests/*scm. <nckx>I'm sure I'm missing a nice Schemey way to do it. The test runner find them, after all. <NieDzejkob>Is there some mechanism that could allow `guix environment guix' to also pull in emacs for indent-code.el? <efraim>guix environment guix ---ad-hoc emacs-minimal <nckx>Ehm, not ‘correctly’. Adding (and perhaps documenting) ‘--ad-hoc emacs-no-x’ not good enough? <nckx>Or minimal. I wonder which one is more… that. <efraim>i think the emacs-build-system uses -minimal <nckx>minimal: 204.2 MiB, no-x: 275.6 MiB. <jackhill>This is not a suggestion, but I wonder if guile's elisp support can run indent-code.el <raghav-gururajan>Folks! So I formated my SD card and placed it in the memory card slot of my x200t. I want the contents if this card to be automatically mounted at '/home/username/sdcard'. Is it just enough to mention in 'file-systems' or do I have to mention it in 'mapped-devices' as well? <nckx>jackhill: I don't know, but Guile only provides an interpreter. indent-code.el does little more than call indent-region, save-buffer, &c., which do the real work, and are all part of the text-editing library that emacs. <nckx>raghav-gururajan: file-systems is fine. I don't know how well it deals with missing drives at boot time, though. <raghav-gururajan>nckx Thanks! Hmm, I have to try booting without sdcard and see what happens. But I usually leave the sdcard inside. <lfam>For some reason `./pre-inst-env guix environment --ad-hoc qemu qemu-minimal` didn't protect the built qemu-minimal against gc :/ <nckx>raghav-gururajan: Right. If you treat the SD card as if it were built-in file-systems will definitely do the job. You probably want (needed-for-boot? #f) to decrease the chances of things going wrong when it does go missing/corrupt. <lfam>It will be a few more hours to rebuild them <lfam>Can't we do this on ci.guix.gnu.org? <raghav-gururajan>nckx Also, how the read/write permissons for this will be? Will it be just like other hot-pluggable devices? If I mount under /sdcard instead of /home/username/sdcard, will it be writable only by root? <nckx>lfam: this = what exactly? <NieDzejkob>efraim: yeah, I am aware of that, but I was considering sending some patch that would do this by default <lfam>Run the system tests with this new QEMU, nckx <nckx>raghav-gururajan: / can have its own permissions, so once you mount it and chown/chmod /home/username/sdcard once it will be persistent. <nckx>(By / I mean the SD card file system's /, you know what I mean.) <NieDzejkob>oh, should've read the rest of chat history first <raghav-gururajan>nckx Okay. But by default /home/username/sdcard will have same permissions as /home/username correct? <nckx>Not until you change it. <nckx>raghav-gururajan: There are also uid= and mode= mount options for this but that is not Guix-specific. <NieDzejkob>lfam: consider reporting a bug for guix environment not creating a GC root <lfam>Yes, I'll consider it NieDzejkob <lfam>It's the sort of bug that's hard to report well because... I can't reproduce it <nckx>raghav-gururajan: What I mean by persistent is that you only need to change it once. Then it will keep those permissions across reboots, mounts, and even machines (assuming the numeric UID/GIDs match). <lfam>It's really just a frustrating waste of time for whoever would read the bug <nckx>lfam: Well, you have SSH access and this would be a legitimate use of that, but I get that that's probably not your point. It's a short-term solution for your lap though. <lfam>I actually don't have SSH access to any Guix infra <nckx>Oh. I really thought you did. <nckx>Honourary admin or whatnot 🙂 <lfam>I used to have access to hydra.gnu.org but I didn't try to get access when we switched to Cuirass <raghav-gururajan>nckx The 'needed-for-boot?' is '#f' by default. For file-systems mounted at '/', I should '#t' it right? <nckx>raghav-gururajan: Really? I didn't know. I wonder if Guix does magic, because I don't have it set on any of my file systems and my system boots. It should be #t for all file systems that need to be mounted in the initrd. Probably not your SD card. <nckx>raghav-gururajan: Things like /gnu on a separate file system are also implicitly (and correctly) mounted early without explicit needed-for-boot? #t. If you really want to know the specifics I suggest you look at the code, I'm sure it's clear once you find it 🙂 <raghav-gururajan>nckx This is something different. I always wondered, why guix didn't implement '/guix' instead of '/var/guix', just like a separate '/gnu'. <leoprikler>probably because there already exists a custom for /var, whereas /gnu/store was carried over from nix (/nix/store) <nckx>raghav-gururajan: I don't know & I can't look inside civodul's head. It's never been obvious to me either. I think it would make more sense to move /var/guix to /gnu/something. /var/guix/db was definitely a mistake IMO, considering how it and /gnu must be kept in perfect sync anyway. Same for /var/guix/cache: it should be /var/cache, similar to how guix already respects ~/.cache, the admin might have set special rules for caches. <raghav-gururajan>Hmm. /gnu and /guix setup would be nice though. Independent of other conventions. <nckx>raghav-gururajan: Why /guix? /gnu/something, OK, but I see only drawbacks with /guix. <nckx>NieDzejkob, raghav-gururajan: Moving everything I mentioned above would leave a mere <3 MiB of GC/profile links in my /var/guix. So yeah, they could probably go in /gnu as well. <raghav-gururajan>nckx Ah, but having 'db' (db of store) outside of store is better right? Or else it would be like putting index page in middle of the book. <nckx>More like putting the inode table of your root file system on a separate SD card. <nckx>Yes ‘we can do the parallelism now’ but you really don't actually want to. <nckx>For once, I don't care about the name. <nckx> /gnu/guix is fine, it is the Guix implementation of the GNU store package manager, or something. Make up your own story 😉 <nckx>Obviously it needs to be user-configurable. <NieDzejkob>Unrelated: A package I'm trying to package is using googletest for its tests, and it needs libtool's .la file for gtest, which is not present in the googletest output <raghav-gururajan>Would it be possible to change this in future? Or are we stuck with /var/guix.. <NieDzejkob>Even though a template .la file is provided in the googletest repo <nckx>raghav-gururajan: Compatibility is the only reason. You'd have to implement a migration feature as was done with guix pull, and like guix pull you'll be in a world of fun when it turns out to be buggy. <raghav-gururajan>nckx Oh wait. I forgot that there is sub-dir 'store' inside '/gnu'. Yeah, things like /gnu/db, /gnu/profiles .. would be good. <nckx>While I agree that it's not optimal now, I don't know if I think it's *worth* changing. <NieDzejkob>what migration was done for guix pull? "Migrating profile generations"? <nckx>NieDzejkob: Yes, that. ‘guix pull’ was completely redesigned and improved so it was worth it. <raghav-gururajan>nckx I think it is worth changing. the directories inside / are named with meaning as per FHS. Since, guix doesn't follow FHS, it would be better if guix's directory structure is non-ambigous with FHS. <nckx>I wonder if you'd run into any bugs if you built a Guix System with --localstatedir=/gnu today. <nckx>raghav-gururajan: Ah, but using /var at all was probably once an attempt to honour FHS, kind of. Just a very incomplete one. <lfam>This would certainly void the warranty <lfam>To do --localstatedir=/gnu <raghav-gururajan>Or even better, guix can generate a standard structure for it's model. Like /store, /db, /profiles etc.. <jonsger>has anyone an idea why `mysql -u nextcloud -h 127.0.0.1 -p` works on Guix system, but `mysql -u 'nextcloud'@'127.0.0.1' -p` not? <drakonis>a fun experiment would be to compose a system that follows the standard fhs <drakonis>all the same features, but everything's in the standard locations <drakonis>its good to provide compatibility with regular distributions <nckx>drakonis: On our terms, sure. You can't build a Guix that puts libraries in a global /lib. There are limits. <raghav-gururajan>I understand. But I am afraid FHS was not designed based on functional model. <leoprikler>but you could make one that symlinks /run/current-system/profile/lib to /lib <nckx>Following FHS is not an argument in itself, nor is FHS some holy grail of good ideas. Quite the opposite. <raghav-gururajan>I would be better to develop a standard directory structure for systems based on functional model. <nckx>raghav-gururajan: Guix and Nix made a great leap forward exactly by breaking the overly restrictive FHS ‘rules’. By being compatible on *their* terms. Future functional experiments will do the same with whatever λHS we come up with, or they will be stuck in boring reimplementations of Guix/Nix. <nckx>But like in Rust or whatever. <nckx>Is this the future you want. <leoprikler>Let's write our Nix daemon in Rust, because there can go nothing wrong with bootstrapping that! <raghav-gururajan>nckx Of course I do not want that future. But there is noting that limits a 'standard' to evolve. <nckx>leoprikler: Seriously: totally plausible Nix PR. <raghav-gururajan>For example, FHS can change as new things implemented in non-functional model. And xHS can evolve based on new things implemented in functional models. :-) <nckx>raghav-gururajan: I was kidding (mostly) 🙂 I just don't see any need for, or even potential benefit of, a standard at all. <nckx>Nix switching to /gnu tomorrow: 0 compatibility increase. <raghav-gururajan>nckx Standard is very important with regards to the three 'R's in science. Reliability, Reproducability and Robostness. <nckx>That's a canned line. Why? What purpose would it serve, in practice? <raghav-gururajan>When I say some thing weights 1Kg, we both are perceiving the same thing as we use a standard for what it means for something to be 1Kg. 