<vagrantc>hrm. pinebook pro with Guix System on nvme ... partially successful ... u-boot loads the kernel, initrd, etc. just fine, but ... hello initrd guile shell, displaying helpfully partly to serial console and partly to a screen that doesn't yet have all the right modules loaded :/
<nckx>Guest89: They are overwhelmingly different pieces of software. ‘A unix’ only describes a general approach to writing operating systems, a vague description of basic principles (‘e.g. lots of things are files’). It does not imply compatibility.
<vagrantc>hah. i think u-boot leaves the nvme is a borked state. well isn't this a catch-22
<ecbrown>rndd: depends on your needs. if you need a general distro then debian.
<vagrantc>yup, when i don't initialize nvme from u-boot, i can read the nvme from my installed microsd system. when i do initialize nvme from u-boot, neither the microsd or nvme system can detect the nvme. beautiful.
*ecbrown wonders if there's known uid/gid mismatch problems when adding/subtracting daemons willie-nillie
<dstolfa>nckx: BTW: i will have time this weekend so if you want to give me work...
***iskarian is now known as Guest5048
***iskarian is now known as Guest9859
<flatwhatson>crazy idea: a guix-build-system which clones the project and uses its guix.scm to get the actual build steps
<dstolfa>flatwhatson: crazier idea: modify GNU make to be able to export information on the stuff that would be read/configured at runtime and then write a guix plugin that will use that information to generate the build steps in a guile EDSL
<oriansj>a slightly easier crazy idea: a makefile parser in guile
<dstolfa>oriansj: would that work? i don't know 100% how gnu make works, only bsdmake and there are certain things that are loaded at runtime and can't really easily be figured out without reimplementing make itself in the parser
<oriansj>a batshit crazy idea: autotools to guile scripts
<dstolfa>oriansj: yeah, it does. i was thinking more of a build system in guile as an EDSL that can handle anything cmake/meson/autotools/etc can in theory and that we could generate it out of makefiles, but a Guile make sounds good to me too
<oriansj>pkill9: out of 91 bootstrapping steps, only 13 are needed to get from hex0 to GCC, the rest are for autools.
<dstolfa>(would even be willing to lend a helping hand)
<oriansj>I already did one build system to solve the guix bootstrap (kaem-optional-seed in 737bytes); I feel no need to write another. Another linker, assembler and compiler; now those might actually be fun.
***terpri is now known as robin
<apteryx>ecbrown: oh you are right, I think I hit that problem in the past when attempting to build natively on childhurd
<apteryx>perhaps it could be cross-compiled though
*raghavgururajan wasn't aware how tired he is and started typing `guix search` on web search engine
<tissevert>yeah there's surprisingly few people here today
<kitzman>ecbrown: (i'm far from an expert or regular user). never tried the gui installer. shouldn't guix system image work and then you just dd it? idk if you can pop up a terminal, try C-M-F2. i guess in that case you can run guix system reconfigure (or whatever the installer runs). and I would use socat to send data (or just the pubkey so I could ssh; seems way easier that way)
<ecbrown>kitzman: well i am thinking about it a little more and i think the point is moot
<ecbrown>if i e.g. reformat the disks i need to put in the uuid's etc
<ecbrown>i dunno, i can do it with the console too
<ecbrown>just have been some occasions where i wish i could insert some services that i don't want to type in
<ecbrown>i think it can be hacked prior to installer reaching that step
<ecbrown>oh well waiting for backup to complete and scheming
<kitzman>well i guess easiest would be to do the regular install then reconfigure
<ecbrown>kitzman: the problem i have is that i have observed some uid/gid issues when reconfiguring daemons/services
<ecbrown>i would like to "punch them in" right from the start so for this experiment i want to take a "perfect setup" and just do it from the start
<yoctocell>abcdw: what's the current plan for merging guix home? There are a few things left in the TODO file, i think we are close to ready :)
<munksgaard>I can't actually find anywhere in the Contributing section of the guix manual that describes how to write commit messages other than a reference to ChangeLogs and "look at the history of commits to figure it out"
<munksgaard>Perhaps it would be nice to have something a bit more fleshed out. I recently struggled with understanding how it's supposed to work.
<yoctocell>i have a few services in my local config, but i think will wait for guix home to get merged before i submit them, so i don't pollute guix home with too many services
<yoctocell>munksgaard: there is an etc/committer.scm script which can generate commit messages for adding a new package, or doing a simple update (update hash and version)
<munksgaard>yoctocell: Oh! See that would be nice to have mentioned in the manual somewhere.
<roptat>would it make sense to have a guix-daemon package that builds only the daemon? right now the guix package is taking a lot of time to build for my reconfigure (armhf...), so I'm thinking it would help to build only a subset?
<munksgaard>I notice that a lot of files have extraneous whitespace (for instance etc/committer.scm). Am I the only one who thinks it's a bit unfortunate that there's no linter or anything to catch this?
<yoctocell>munksgaard: where does etc/committer.scm have extraneous whitespace? it looks fine to me
<roptat>munksgaard, would you like to send a patch for the manual?
<yoctocell>abcdw: hmm, it didn't work /gnu/store/m1dgn3mmgibksp7i6ppavka296wj56al-home/activate:3:4360: definition in expression context, where definitions are not allowed, in form (define changed-files (map (lambda (file) (check-file file)) tree-file-files))
<yoctocell>i think it needs to be wrapped in a (begin ...) form
<yoctocell>abcdw: do you have an example on when it would be useful to check /profile for triggering some event?
<Guest45>Hi, I'm new to Guix, I'm coming from Void Linux. I'm having a little trouble regarding python, its ctypes module and jack library. The jack library for python tries to find libjack.so through ctypes.utils.find_library('jack'), but the return path is empty (it means it couldn't find libjack.so). I have jack libraries installed under my own profile,
<Guest45>but it seems find_library doesn't check there, even if I manually set LD_LIBRARY_PATH to $GUIX_PROFILE/lib. If anyone has experience with python, could you give me directions of what to do in this situation? I can even create a package like python-jack if necessary. Thanks in advance.
<yoctocell>abcdw: ignore my last message, i just saw /profile/share/fonts ^^
<yoctocell>but traversing /profile would be pretty expensive
<apteryx>civodul: for the "guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet." problem, fetching the /gnu/store/x9sbkfhm1f3qpq526i2cfvidczqcafyq-libreoffice-22.214.171.124.drv derivation seems to trigger it more often than not
<apteryx>for me, and I think mdevos had the problem as well
<abcdw>yoctocell: As I mentioned, we do not need to traverse all the files in /files, neither in /profile, we can use files/directories names provided by extensions to home-run-on-change. So it will be relatively small amount of files. Also, we don't need to compare files with cmp, we can just look at symlinks.
<civodul>apteryx: i've not experienced it since before the 1.3.0rc days
<yoctocell>is /profile/share/fonts itself a symlink to the store, or does it contain files that are symlinked to the store?
<yoctocell>if the latter is true, we would have to compare all the files in the directory before we know whether or not the directory is the same
<apteryx>civodul: OK! Perhaps all I need is a reboot ;-). Will do so a bit later.
<abcdw>yoctocell: it's just a directory. It shouldn't be terribly expensive to compare symlinks value. Some other optimizations can be also done in case we will face any perfomance issues (but we don't have to ;)
<jackhill>I the archival checker message "Disarchive entry refers to non-existent SWH directory <hash>" somthing to be concerned about?
<yoctocell>abcdw: ok, thanks for clarifying. Time to start hacking :)
<civodul>apteryx: i've replied there on how to further test things, we'll see
<civodul>jackhill: not your fault, there's not much you can do about this lint warning
<roptat>Guest45, are you using a jack python module from guix, or are you getting it in another way? If it's from guix, it's a bug, otherwise, you should create a guix package for it, and maybe hardcode the location of the jack library in the result
<roptat>the actual library is in an unguessable directory in /gnu/store, it's not in $GUIX_PROFILE/lib unless you explicitly install jack too
<roptat>Guest45, if you don't get an answer here, you can also try to send an email to email@example.com (first message is moderated, so it can take up to 24 hours to accept, following messages go through directly)
<yoctocell>abcdw: I noticed that I already have a ~/.guix-home/profile/share/fontconfig directory, and it already has a bunch of files. Would it make sense to configure fontconfig to use that directory?
<ecbrown>civodul: this is a nice application in your blog!
<yoctocell>abcdw: The ~/.guix-home/profile/share/fontconfig directory already exists for me and contains a bunch of file, whereas I don't even have a ~/.guix-home/profile/share/fonts directory. The `add-fontconfig-config-file' procedure in (gnu home-services fontutils) sets the font config directory to ~/.guix-home/profile/share/fonts instead of ~/.guix-home/profile/share/fontconfig.
<abcdw>You don't have share/fonts, because there are no fonts yet in your home profile.
<abcdw>share/fontconfig contains configurations, which are not very useful as font files, so, no, we don't need to change the directory) Just install some font- packages and call fc-cache -fv
<yoctocell>abcdw: ah indeed, the fonts directory shows up now
<yoctocell>abcdw: BTW, I think I got directory comparison to work for the `run-on-change' service
<yoctocell>but only if the directory itself is a symlink, not if it contains files that are symlinks
<Guest45>roptat Thank you. I'm not familiar with packaging yet, but I'll try soon. I also want to bring other packages to Guix :). For now, I guess I'll rewrite my program in C++ just for temporary use, I need it for my sound system to work.
<abcdw>yoctocell: Good news!) what is the problem with non-symlink directories?
<yoctocell>abcdw: if the directory just contains files that are symlinks, I have to check every single file in the directory before I know if the directory has changed, so I still have some work to do I guess :)
<abcdw>yoctocell: Yep, that's right, you have to traverse the directory. Perhaps, there are some code snippets in symlink manager you can reuse or at least study as an example.
***marwan8 is now known as marwan
<civodul>ecbrown: yes, i find it rather fun to address problems in this Guix-y way!
<ecbrown>i was also interested in the structure of your guile
<Guest69>GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy bloc
<roptat>civodul, mh, guix-daemon package says it'll use /var/guix/profile/root/current-guix/ for that, so I guess it would work?
<roptat>I replaced the guix field in the guix-configuration, and I can't see anything suspicious in the way the acl is created, it doesn't use the guix package, it just uses some modules
<roptat>uh? I replace guix-daemon with "1", expecting it to return an error, and it does, but it's weird: Wrong type to apply: #<package firstname.lastname@example.org gnu/packages/package-management.scm:137 1729a00>
<roptat>I would have expected 1 to be of the wrong type instead