IRC channel logs


back to list of logs

<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.
<NieDzejkob>nckx: Also happens on my side
*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
<nckx>Is this known?
*jonsger has built a php-7.3 which should work with nextcloud :)
<str1ngs>nckx: are you decompressing in / ?
<nckx>str1ngs: Yes, but it doesn't matter.
<nckx>Happens anywhere.
<nckx> /gnu/store's writable.
<str1ngs>nckx: can you do lsattr ./gnu/store/06ybqkh3lb3g7c77b74izy32grglf45x-libx11-1.6.8/include/X11/cursorfont.h
<str1ngs>Im assuming that file exists?
<str1ngs>lsattr -l is more useful
<nckx>str1ngs: Nothing interesting (only e).
<str1ngs>sounds good right
<nckx>Sounds peachy 🙂
<str1ngs> and lsof ./gnu/store/06ybqkh3lb3g7c77b74izy32grglf45x-libx11-1.6.8/lib/
<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.
<str1ngs>hmmm ther's no bsdtar in guix :(
*rotty has stumbled upon the "parameterized packages" discussion (being a new lurker on guix-devel), and wonders about if it makes sense to relate those to Rust crate "features" (
<nckx>str1ngs: Install libarchive.
*nckx needs to catch up on that thread, thanks for the reminder.
<str1ngs>nckx: can you try with tar tvfW
<str1ngs>that should verify the headers IIRC
<nckx>str1ngs: bsdtar?
<nckx>That also doesn't work.
<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.
<nckx>Yes, it's huge; sorry.
<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?
<alextee[m]>(also, where's `dig`?
<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
<nckx>alextee[m]: Does it? News to me ;-) Long thread:
*alextee[m] sent a long message: < >
<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
<alextee[m]>like str1ngs said
*alextee[m] reads more
<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
<nckx>M-hm :)
<nckx>I liked that too.
<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.
<str1ngs>one huge flat file haha
<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.
<drakonis1>hey ho
<nckx>Totally not trying to avoid drakonis1.
<alextee[m]>er, so anyway what package is "dig" in? lol
<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>i'm doing that right now
<nckx>alextee[m]: bind:utils.
<drakonis1>and as far as i know, gzdoom bundles soundfonts
<alextee[m]>nckx: thanks
<drakonis1>if you check the prebuilt deb
<drakonis1>nckx: fluidsynth: error: Failed to load SoundFont "gzdoom" and Failed to load patch set gzdoom.
<drakonis1>they're missing and should be included
<str1ngs>that reminds me I need to fix timidity to work on foreign distro's
<str1ngs>well alsa plugins really
<drakonis1> err
<drakonis1>this is what i did on nix to get it working
<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?
<alextee[m]>or just the "known" or "necessary" ones?
<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]>oh you're still up :-)
<alextee[m]>i see nckx
<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.
<nckx>Stuff like that.
<str1ngs>alextee[m]: I found using emacs-debbugs helps for reviewing
<alextee[m]>str1ngs: vim guy here
<str1ngs>I will pray for you :)
*str1ngs mumbles a chant for alextee[m]
<alextee[m]>str1ngs: XD god have mercy on me
<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
<alextee[m]>there's so many things missing from guix there
<alextee[m]>im stacking packages in my channel for now
<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’.
*alextee[m] will start hanging around in
<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!
<alextee[m]>nckx: im actually packaging that right now!
<alextee[m]>just updated the version actually
<alextee[m]>gonna send it over
<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.
<alextee[m]>nckx: do you have any comment on this?
<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.
<nckx>He's just very busy.
<alextee[m]>basically make 30ish separate packages vs a single one
<alextee[m]>upstream has a meta-package for the purpose of packaging
<alextee[m]>ah okay
<Parra>I think I almost have it:
<nckx>I read your mail, but I can't very well convince Ricardo for you.
<alextee[m]>does Ricardo hang around on IRC?
<nckx>alextee[m]: As rekado.
<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)
<alextee[m]>i'll submit that soon
<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>Urf. OK. Nice.
<nckx>I just meant a short ‘bundles a [heavily] patched version’ comment, not a full explanation of anything, by the way.
<alextee[m]>oh okay that's probably better
<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.
<alextee[m]>thanks for the help/reviews!
***spk121_ is now known as spk121
<Parra>leoprikler: finally:
<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 :|
<leoprikler>but your accounts still exist?
<raingloom>leoprikler: i have all my emails offline, so it should definitely be showing them
<raingloom>trying previous version with time machine
<civodul>Hello Guix!
<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
<jonsger>mkoncek: maybe you found something on
<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
<brown121407>smithras: thanks, will do
*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
<civodul>oh nice!
<civodul>here's the dot file:
<civodul>(best browsed with xdot)
<civodul>this post mentions discussions about Maven bootstrapping:
<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> seems to be down
<civodul>jonsger: yay!
<civodul>(well, not for issues.*)
*jonsger found another bug in the installer :P
<jonsger>new bug should show up here:
<mjw>For Guix Days, do I need to register for dinner separately?
<kmicu>Euro euro
*kmicu could give 5 euro a month for Guix on e.g.
<jonsger>kmicu: there is Guix Europe, a club where you can become a member
<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
<mjw>smithras, I believe you can just add your name here and show up:
<smithras>mjw: thanks for the tip!
<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]>Actually the helm patch too. Let me rephrase:
<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
<Parra>ah, I see
<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
<leoprikler>even better than rot13
<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
<leoprikler>yeah, so $prefix/lib
<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?
<leoprikler>I'm on PC, thankfully
<Parra>mmm, node modules -g installs in
<Parra>usually /usr or /usr/local
<Parra>$prefix is usually*
<leoprikler>ahh, I see
<leoprikler>so you basically "build" index.js inside the local node_modules, which later gets installed to $prefix/lib
<leoprikler>alright, I misunderstood that phase
<AndroUser2>leoprikler: exactly
<AndroUser2>I tried a new client, let's see if it works better
<AndroUser2>Im gonna try to implement NetCore now
<alextee[m]>should find-files work on directories too?
<alextee[m]>doesn't seem that they get picked
<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
<leoprikler>guix logs are a wonderful resource.
<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.
<NieDzejkob>Any committers feeling like reducing the closure of IceCat by 1 GiB?
<kmicu>Great one NieDzejkob ʕノ•ᴥ•ʔノ ︵λ𝛌𝚲𝝀
***ng0_ is now known as ng0
<civodul>cbaines: there's something wrong on data.guix:
<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
<lfam>"Step on the gas!"
<NieDzejkob>I don't really use nim, but here's a patch of mine that fixes compiling nim programs. It would be nice to have this merged:
<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
<raghav-gururajan>Hello Guix!
<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>ah ty
<NieDzejkob>the [] mean it's optional
<NieDzejkob>if package name == binary name
<moewe>aah exit
<moewe>sorry ignore the exit
<moewe>so uh
<moewe>guix is like the emacs os
<moewe>Is it because of workpower, or is there a certain reason why it's on 26?
<drakonis1>isnt it on 27 already?
<moewe>i just have pulled and updated to 26.3
<drakonis1>ah right, i'm running emacs-next
<moewe>oooh didn't know about that package, ty
<drakonis1>the current emacs release is 26 not 27
<lfam>Gah I screwed up sending a patch series 🤦‍♂
*lfam fixes it
*nckx unhappy about missing Guix dinners this year.
<pkill9>guix dinners?
<nckx>pkill9: At the Guix Days in Brussels.
<smithras>I'm curious to see how seating 30 people will work out
<nckx>smithras: ‘Cozy’.
<nckx>pkill9: Very.
***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 :)
<lfam>That would do it!
<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>Oh, I am psychic.
<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>A point to -minimal.
<nckx>minimal: 204.2 MiB, no-x: 275.6 MiB.
<lfam>2 up minimal
<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.
<jackhill>ah, of course
<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 :/
<lfam>Or the full qemu
<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.
<nckx>lfam: Oh noes ☹
<lfam>It will be a few more hours to rebuild them
<lfam>Can't we do this on
<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
<raghav-gururajan>nckx Thanks for that tip.
<NieDzejkob>maybe a concept of dev-dependencies?
<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>No, probably not.
<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
<raghav-gururajan>nckx Thanks!
<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
<lfam>Infrastructure, that is
<nckx>Oh. I really thought you did.
<nckx>Honourary admin or whatnot 🙂
<lfam>I used to have access to 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.
<raghav-gururajan>nckx Yeah, I was wondering the same.
<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>I see.
<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.
<NieDzejkob>I'd say keep it all in /gnu
<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.
<raghav-gururajan>Hmm, /gnu/guix should be also work I think.
<nckx>For once, I don't care about the name.
<raghav-gururajan>*should also work
<nckx> /gnu/guix is fine, it is the Guix implementation of the GNU store package manager, or something. Make up your own story 😉
<nckx>So is /gnu/db.
<NieDzejkob>/gnu/store-db? store.db?
<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..
<nckx>Oh no mah warranty.
<raghav-gururajan>* directory structure
<drakonis>a departure from nix.
<jonsger>has anyone an idea why `mysql -u nextcloud -h -p` works on Guix system, but `mysql -u 'nextcloud'@'' -p` not?
<drakonis>a fun experiment would be to compose a system that follows the standard fhs
<raghav-gururajan>drakonis "Guix not Nix" :-D
<drakonis>all the same features, but everything's in the standard locations
<raghav-gururajan>^ Exactly :)
<raghav-gururajan>* not in fhs, in idealised new 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.
<nckx>s/puts/& all/
<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
<leoprikler>of course in a read-only manner
<raghav-gururajan>leoprikler Yes, I believe that can be done via FHS-service-type.
<nckx>Following FHS is not an argument in itself, nor is FHS some holy grail of good ideas. Quite the opposite.
<raghav-gururajan>^ +1
<raghav-gururajan>I would be better to develop a standard directory structure for systems based on functional model.
<raghav-gururajan>*It, not I
<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.
<leoprikler>Yes, there is. It's called a committee.
<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.