IRC channel logs

2021-06-11.log

back to list of logs

<dstolfa>and the disagreements don't stop in the kernel. the shells are different and often incompatible with each other, configuration files have different formats, etc
<nckx>‘C == portable’ meme means ‘C compilers exist for every system’. It doesn't mean your code magically runs on more than one without human effort.
<dstolfa>as for C being portable, a language is only as portable as its compiler allows it to be. C is notoriously bad to port to certain archs
<dstolfa>nckx: beat me to it
*nckx didn't say *good* C compilers exist for every system, to give dstolfa their credit.
<nckx>Apparently #ifdefs are hella portable and magic, though.
<nckx>The more the better.
<dstolfa>heh
<Guest89>When I write functional programming, 99% of my code should work in every platform. Maybe this 1% should be done my the compiler
<dstolfa>nckx: there's a fun notion of what C semantics are, should be and what the de-facto semantics are
<dstolfa>for example, people like to assume that two bitwise equal pointers can't be different from each other, but the spec allows that, and without it you couldn't have alias analysis
<nckx>Problem is, the 1% is stuff like ‘reading from the file system’ and ‘putting something on the screen that isn't a line of text’. Stuff people notice very muchly.
<dstolfa>also the whole business of casting pointers to uint64_t and back, and expecting to be able to use them
<dstolfa>:)
<Guest89>or maybe a solution should be to use electron in all operating systems
<Guest89>electron is fast and good
<nckx>Electron is extremely slow.
<dstolfa>nckx: i think they're being sarcastic, but it doesn't translate well over IRC :)
<Guest89>but it is working faster than my emacs
<nckx>Dammit.
<nckx>I can't believe I fell for that.
<ecbrown>try emacs-native-comp
*nckx needs to catch all the z's but can't yet.
<Guest89>my problem with emacs is rendering time
<Guest89>it is very slow to scroll
*dstolfa will hopefully get to pick up an ath9k device tomorrow and can finally finalize his guix install on the laptop with 100% libre
<Guest89>ecbrown does emacs-native-comp have fast scroll?
<ecbrown>yes
<Guest89>ecbrown it is very good. Because I was using VS Code because I hate slow scroll
<ecbrown>i'm scrolling like silly on the full list of guix packages in emacs-guix
<nckx>dstolfa: \o/
<Guest89>dstolfa , what is the difference between all these kernels. Just the config file to compile them?
<Guest89>Or are they in different repositories?
<iskarian>is there an equivalent for guix download but for git sources? (other than manually doing git clone / guix hash -rx)
<nckx>Not that I'm aware.
<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 :/
<vagrantc>time to play module whack-a-mole
<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.
<rndd>hi guix!
<rndd>i've been thinking about running hurd in vm. which (hurd) distro should i use (debian, arch, guix)? this is something really new for me.
<nckx>vagrantc: ‘Partly’ o_O
<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
<ecbrown>my gitolite belonged to colord
<dstolfa>nckx: i was away, thanks for answering their question
<nckx>I don't know if they saw it.
<dstolfa>well, the channel is logged so they can find it :)
*dstolfa feels weird about going from 256 gigabytes of space on a laptop to 4TB of M.2 space on alaptop
<dstolfa>it feels... liberating in a way
<ecbrown>now you need to host a gnu mirror
<dstolfa>ecbrown: i mean, if it's necessary i could ask around to host one at the university/department
<dstolfa>i won't make any promises but it's worth an ask
<leoprikler>ecbrown: gdm is a notable one
<ecbrown>i was being sarcastic -- whenever i get a new storage upgrade i fill it up with random stuff
<dstolfa>ah :D
<dstolfa>i basically set it up in raid0 with btrfs with raid1 metadata and am very happy with it
<rndd>ecbrown: okay, thank you
<ecbrown>leoprikler: that scrambles up uid's?
<leoprikler>if you drop gdm for some other service then decide to go back, gdm won't have the same uid
<leoprikler>there's an activation script to fix issues arising from that
<ecbrown>i'm beginning to wonder if i should treat guix as more of add-only for services :-)
<ecbrown>things run great until i start tweaking and redistributing
<dstolfa>hah
<dstolfa>Works For Me (TM)
<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
<flatwhatson>you're right, that is definitely crazier
<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
<pkill9>why is that crazy?
<oriansj>dstolfa: and what is wrong with a version of make written in guile? seems possibly useful
<oriansj>pkill9: have you seen the crazy shit we have done to solve the autotools bootstrap shit-wheel circlejerk?
<pkill9>nope
<pkill9>has anyone run guix on a pinephone?
<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.
<pkill9>huh
<pkill9>why so many required?
<oriansj>not to mention the autotools, autoconf and libtool crap that goes with it
<oriansj>pkill9: really short version autotools depends on the latest version of autotools to build from source.
<oriansj>and the latest version of autoconf and libtool too
<oriansj>which each depend on the others at the latest version and the developers didn't bother on several releases to actually enable previous versions to be able to build the latest version.
***iskarian is now known as Guest6161
<pkill9>when yous ay 'autotools to guile scripts', where you saying have autotools configure the guile scripts used to bootstrap the system?
<oriansj>pkill9: fuck no. Find a way to murder autotools from GNU software
<dstolfa>LOL
<pkill9>so replace autotools with guile scripts?
<dstolfa>yes
<dstolfa>not the other way around
<vagrantc>/27/27
<dstolfa>vagrantc: again? :)
<oriansj>atleast bootstrapping guile will be an easier problem than freaking autotools;
<vagrantc>dstolfa: apologies for the noise, but that's probably never going to change :P
<dstolfa>vagrantc: hah, no need to apologize (imo at least), i just find it amusing because i tend to do this, but with different ssh sessions instead of irc buffers
<dstolfa>rebooting wrong machines and so on (much more destructive...)
<oriansj>dstolfa: molly-guard is what you need to prevent such reboots
<vagrantc>dstolfa: hah
<dstolfa>oriansj: i actually have it set up on a few boxes, but these are disposable test machines that go through minimal setup so it's not too bad :D
<flatwhatson>an EDSL to produce autotools builds ie. autogen.sh, configure.ac, Makefile.am
<flatwhatson>we've come this far, another layer can't hurt, right?
<vagrantc>pkill9: hope to test guix on the pinephone before too long ... so many projects!
<oriansj>flatwhatson: if you can't build your program with make, (or Cmake if you have cross-platform build requirements) then you don't have a build problem but a common sense problem.
<pkill9>i wanted to do something simple on android and was annoyed icouldn't
<pkill9>wanted to stream a video file
<dstolfa>autotools made sense when they were first written
<pkill9>just a simple http URl
<oriansj>dstolfa: well that is certainly up for debate as when it was written very few programs needed to be built for multiple unix systems.
<flatwhatson>oriansj: wouldn't this be a first step on the path of replacing automake in packages, perhaps?
<dstolfa>oriansj: well, keith and the berkeley lab certainly saw the need for it
<dstolfa>at least according to kirk (IIRC, i think i heard it from him)
*dstolfa wonders what will end up happening with autotools after that lengthy mailing list discussion
<oriansj>dstolfa: let us assume for a second that was true. Is it still true today?
<dstolfa>no
<dstolfa>absolutely not
<dstolfa>lol
<oriansj>ok, so if something doesn't add much of value and comes with a great deal of problems. why would we continue to recommend such thing?
<dstolfa>oriansj: i didn't say we should :)
<dstolfa>i'm with you in scrapping it
<oriansj>or replacing it with guix build scripts assuming someone gives guix trivial builds a better syntax
<dstolfa>++
<dstolfa>i'm all for that
<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
<raghavgururajan>GuixWeb ™️
<flatwhatson>raghavgururajan: i liked your "replace version.go" trick from a couple days back, you were joking but i think it's a legit solution
<flatwhatson>are there any current efforts to package gtk4?
<jackhill>flatwhatson: looks like raghavgururajan is working on gtk4: https://issues.guix.gnu.org/48554
<apteryx>oriansj: what is problematic about autotools from a bootstrapping point of view?
<raghavgururajan>flatwhatson: I ended-up doing this (https://paste.debian.net/plain/1200810), as leoprikler suggested.
<raghavgururajan>flatwhatson: gtk4 is almost ready. Need help with enabling/fixing tests.
<jackhill>whoh, https://github.com/pjotrp/guix-notes/blob/master/HACKING.org is awesome. I wonder if we can incorporate that into the official documentation somehow
<jackhill>In other news, can someone remind me how to apply patches from emacs-debbugs?
<jackhill>ah, I rememberd: M-x cd RET, <enter path to repository>, <navitate to first patch to apply>, C-u <number-of-patches-to-apply |, git am
<iskarian>I've just been learning this whole ecosystem the past couple weeks and that page has been so helpful for me as well
<flatwhatson>raghavgururajan: maybe i can help, is that the wip-gnome branch?
<Church>Welp that doc is good to know jackhill
***iskarian is now known as Guest830
***iskarian is now known as Guest8211
***iskarian is now known as Guest5657
<tissevert>hey guix
<PotentialUser-2>Hello, does anyone have Guix installed with full disk encryption? I think my grub.cfg is missing something
***Kimapr0 is now known as Kimapr
***Kimapr3 is now known as Kimapr
<ecbrown>since i'm lazy as a mofo is there a way to bring in a custome "/mnt/etc/config.scm" in the gui installer?
<ecbrown>maybe i could use a virtual terminal and scp it in, then something in nano?
<ecbrown>(almost seems like as much work as console install ;-)
*ecbrown hums "it's midnight at the oasis..."
<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
<ecbrown>(i said that twice, sorry)
<kitzman>interesting, what issues exactly? for example, the service does not run as the desired user?
<kitzman>(never used guix-only system, so i don't know ^^)
<ecbrown>for example, if i add gnome desktop services then want to downgrade to base services
<ecbrown>or vice versa, for this concete example: colord owned my gitolite folder
<ecbrown>there is no way that i chowned that
<kitzman>i guess that has to do more with packaging itself. but i think these kind of problems will disappear in time
<ecbrown>not to be an "apologist" but if i were smart i would have made a perfect vm then installed on hardware
<kitzman>for my next setup, i'm planning to use qemu to directly work on the partition (I think one can do that in qemu)
<brendyn>how can i build a package from in guile ?
<kitzman>brendyn: guix package -f, or best, add it in your own channel then use -L option when you install
<brendyn>that is not guile
<kitzman>ah I see. idk i would look in the source
<kitzman>guix/scripts/...
<brendyn>monad stuff confusing me
<brendyn>there is a procedure called build-package... that returns a procedure, which requires some "state"?
<ecbrown>brendyn: you can set up emacs geiser and emacs-gui
<ecbrown>x
<ecbrown>you can eventually get keychords `C-c . b' so you can build the guile of what you are looking at in source
<brendyn>a meta command in the repl is still not code tho
<brendyn>i want to go through a list of packages trying to build them and then accumulating the results
<ecbrown>i am new to the guix-in-emacs experience, so forgive me -- you don't want ,use type stuff and you want to place point after a scheme form and C-x C-e?
<brendyn>basically yes
<ecbrown>(i'm sure someone knows the answer exactly, sorry for my noise)
<ecbrown>and that fnction is your own looper-aggregator
<ecbrown>brendyn: also pjotr has a page on this very thing
<ecbrown>there is a "singleton" looking thing that (define s ...) memory escapes
<ecbrown>(define s (open-connection))
<ecbrown> https://github.com/pjotrp/guix-notes/blob/master/HACKING.org
<ecbrown>that is the "state" iiuc
<avalenn>Hello Guix.
<ecbrown>avalenn: o/
<tricon>PotentialUser-15: I use full disk encryption.
<PotentialUser-15>wrong keyboard layout was the issue, i'm trying with unencrypted boot now.
<tricon>PotentialUser-15: You've got this. You have so much... potential...
<PotentialUser-15>Now on to the next challenge, make an UEFI bootable USB stick
<ecbrown>can't be done
<abcdw>hello guix!
<sneek>Welcome back abcdw, you have 1 message!
<sneek>abcdw, ixmpp says: to be fair, there might be some merit to keeping guix-home out of guix. Keeps at least one major channel outside, encouraging federated work rather than the nix model
<thorwil>hi! i used `git commit` to write a 2-line message, to then notice that `git semdmail` will put the whole message in the subject.
<ecbrown>thorwil: this is #guix, i think you want #git
<thorwil>neither `--subject "foobar"` nor `--subject="foobar"` seems to actually change the subject. what am i doing wrong
<munksgaard>thorwil: The first paragraph of your commit message should preferably only be a single line, I think?
<thorwil>ecbrown: well, the only reason i even touch git semdmail is guix, and this is about a patch i just send
<yoctocell>abcdw: o/
<ecbrown>oic, sorry
<thorwil>munksgaard: so it should be "[PATCH] gnu: Update caps-plugins-lv2." then _2_ linebreaks before "* /gnu/packages/audio.scm: Update caps-plugins-lv2 to <snip>"?
<munksgaard>thorwil: Yes, exactly :)
<thorwil>oh, all those details! 8-}
<thorwil>thanks, munksgaard
<munksgaard>And I don't think you need the [PATCH] bit in the commit message? I may be mistaken.
<ecbrown>i don't think you need patch either
<ecbrown>two linebreaks
<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?
<munksgaard>yoctocell: https://git.savannah.gnu.org/cgit/guix.git/tree/etc/committer.scm.in#n298 and a few lines forward
<munksgaard>roptat: I'm not sure I'll have time over the weekend, but perhaps.
<yoctocell>munksgaard: ah, now i see
<munksgaard>yoctocell: I've only touched a few files so far (guix/import/cabal.scm, guix/import/hackage.scm), but they all seem to have this problem.
<abcdw>yoctocell: Hi, I just finishing the last important update and ready to start upstreaming. Will need to cleanup some stuff and make few small breaking changes, but I think we already can send emails for commit access: https://guix.gnu.org/manual/en/guix.html#Commit-Access
<munksgaard>Huh, maybe I was just unlucky. A random sample of other files in guix/import doesn't have extraneous whitespace.
<civodul>roptat: there's already a hidden 'guix-daemon' package, for use by (guix self), aka. 'guix pull
<roptat>could it be used by the system configuration, instead of the whole guix package?
<civodul>no, because it also needs bits of the rest: guix substitute, guix perform-download, etc.
<civodul>that said, what we could do is arrange to use a 'guix' package built in the same way as with 'guix pull'
<civodul>(that's what we do on foreign distros)
<yoctocell>abcdw: cool, i guess i will have to find three vouchers for me :)
<roptat>oh, it would be nice to share some parts with what guix pull already does
<roptat>although, that can't be the same guix revision, so nevermind
<roptat>I wonder if it's a good idea to install the guix package in the system profile... that's dangerous
<abcdw>yoctocell: I pushed new activation flow, please check if it works on your setup.
<yoctocell>abcdw: ok, will check
<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
<abcdw>yoctocell: Ok, will fix in a minute
<yoctocell>hmm, that didn't work either ...
<abcdw>yoctocell: Nested defines are not allowed anywhere except function body IIRC, wrapped it in a let, should work now.
<yoctocell>abcdw: ugh, now i get this error: unknown location: ...: bad use of '...' syntactic keyword in subform ... of ...
<yoctocell>it doesn't tell me where the error ocurred though...
<pineapples>> ready to start upstreaming; abcdw: Awesome!
<apteryx>I think I have this issue where nscd is aggressively caching host name resolution failures.
<apteryx>It's specific to a Jenkins instance (perhaps it's under high load and thus has a tendency to be 'seen' unreachable?)
<apteryx>I keep having to 'sudo herd invalidate nscd hosts' every 30 minutes or so.
<abcdw>yoctocell: Building some updates from guix channel, will take some time, before I can debug it.
<abcdw>pineapples: ;)
<yoctocell>abcdw: ah, ok, the ... seems to have something to do the the (match-lambda* ...) form in the `flatten' procedure, not sure why this would be a problem though.
<abcdw>yoctocell: Yes, I used another flatten implementation and it works.
<yoctocell>abcdw: so everything works on your machine?
<abcdw>yoctocell: BTW, as I mentioned in the thread, we don't need file-tree-list in proper implementation and therefore flatten
<abcdw>yoctocell: Yep, I pushed a commit with another flatten implementation.
<yoctocell>abcdw: file-tree-list ? i don't see any reference to that variable
<yoctocell>abcdw: now it works for me too!
<abcdw>yoctocell: I mean tree-file-files. I was referencing this message in the thread: https://lists.sr.ht/~abcdw/rde-devel/patches/22290#%3C5c49ad975bfb35aa38dccab08bc2269837502160.1622921967.git.public@yoctocell.xyz%3E-132
<yoctocell>abcdw: ok, i haven't read that yet :)
<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-6.4.7.2.drv derivation seems to trigger it more often than not
<apteryx>for me, and I think mdevos had the problem as well
<raghavgururajan>Hello Guix!
<apteryx>raghavgururajan: o/
<raghavgururajan>> flatwhatson‎: raghavgururajan: maybe i can help, is that the wip-gnome branch?
<raghavgururajan>Yes, thank you. :)
<civodul>apteryx: bah :-/
<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>abcdw: ah yeah
<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
<civodul>it's "just FYI"
<jackhill>civodul: ok, that's fine, I was just worried that the disarchive database had bad info in it or something
<abcdw>yoctocell: you are welcome) BTW, if you need some help or want to pair programming on something, I will have some time in the second part of the next week. Just let me know)
<civodul>jackhill: no, it just means that it lacks info about this particular tarball
<jackhill>civodul: cool! I look forward to the day when it appears
<yoctocell>abcdw: cool, i will work on it a bit during the weekend, we will see how it goes :)
<roptat>Guest45, did you get an answer?
<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 help-guix@gnu.org (first message is moderated, so it can take up to 24 hours to accept, following messages go through directly)
<apteryx>civodul: thanks!
<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?
<yoctocell>instead of ~/.guix-home/profile/share/fonts
<civodul>new post! https://guix.gnu.org/en/blog/2021/reproducible-data-processing-pipelines/
<Guest45>roptat
<roptat>yes?
<Guest45>roptat I obtained python module with pip: pip install JACK-Client. I also have jack and jack2 packages installed with guix.
<roptat>ideally, you should install with guix instead, because the library location is not guessable for pip or other package managers
<Guest45>The jack module for python doesn't exist in guix repos. Should I create one?
<abcdw>yoctocell: Can you elaborate?
<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
*raghavgururajan rebased wip-gnome with master
<roptat>Guest45, if you can, yes that's the easiest way to get it to work
<roptat>well, I'm probably saying that because I'm familiar with guix packaging ^^'
<roptat>pip works well for pure python packages, but otherwise, it's not so great
<roptat>it makes some very reasonable assumptions on the system that are wrong on the guix system
<raghavgururajan>Also, pip assumes FHS, IIRC.
<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
***jess is now known as j
<ecbrown>(i.e. "how to do things")
<abcdw>Have a good evening, Guix!
***j is now known as jess
*raghavgururajan summons nckx
<drakonis>i see guix home will be suptreamed soon
<drakonis>at last.
<PotentialUser-15>is there any way to change the keymap for the grub luks cryptomount password input?
***terpri_ is now known as robin
<PotentialUser-15>or more specific any way to do it within guix
<roptat>PotentialUser-15, no, that's an issue for me as well
<vagrantc>efraim: well, i've got debian running on a hifive unmatched ... so i could probably follow your lead and get guix running on it :)
<roptat>PotentialUser-15, the only solution I found was to add another password and enter it with the same key sequence, but in qwerty
<roptat>(I mean the same physical key as my keymap, but with qwerty)
<PotentialUser-15>yea i guess i'll do that as well
<PotentialUser-15>thanks!
<roptat>arg, I'm getting gc warnings while building guix: GC Warning: Failed to expand heap by 8388608 bytes
<roptat>"guix build guix" is taking 99% of my memory by itself
<roptat>GC Warning: Out of Memory! Heap size: 2571 MiB. Returning NULL!
<roptat>that heap is larger than my memory ^^'
<Guest42>My Guix is not working when I am trying to use it on NixOS
<Guest42>it restart my graphical interface
<Guest42>I tried to use TTY and change the kernel version
<roptat>ouch
<Guest42>nothing works
<roptat>anything suspicious in your logs?
<Guest42>I don't understand very well the logs
<Guest42>what should I try to find there?
<roptat>I don't really know, something related to the kernel or interface around the time you tried to use guix
<Guest42>maybe it is because NixOS doesn't have files in the default place
<Guest42>because I believe that Guix works in other operating systems
<roptat>I don't really expect guix to fail so badly though
<roptat>if it was a missing file, it would return an error, not crash your session
<roptat>but I guess nixos is doing something unexpected here
<Guest3440>I am back, using Guix made me restart the graphical interface now
<roptat>maybe have a look at /var/log/messages
<roptat>well, "journalctl" on nixos I suppose
<Guest3440>like `journalctl | tail -n 100`?
<roptat>yeah
<roptat>I'd open journalctl, and press 'G' to go to the bottom
<Guest3440>maybe, there is a little probability of it being my fault. I am removing some of my NixOS config files and I will restart to computer to see if it worked
<roptat>ok
<Guest69>it was not my fault. I removed the parts that I configured
<roptat>ok, did you find anything relevant in the logs?
<Guest69>This is red
<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>doesn't seem super related
<roptat>I don't think guix uses dbus directly
<roptat>does something like "guix --help" crash your session?
<Guest69> http://pastebin.fr/92254
<Guest69>another paste bin with some yellow parts
<roptat>I think this is when your session restarts, after the crash
<Guest69>guix --help doesn't crash
<Guest69>it is when I use `guix pull`
<roptat>can you try to stop the guix-daemon first, and then try "guix pull" again (it won't work, but does it crash your session?)
<roptat>for the log, I'm looking for something maybe 10 seconds before the paste
<Guest69>the daemon, I am initializing it by hand
<roptat>oh, how so?
<Guest69>`~root/.config/guix/current/bin/guix-daemon \
<Guest69> --build-users-group=guixbuild`
<roptat>as root? with sudo?
<Guest69>as root
<roptat>ok, can you stop that process and try "guix pull"?
<Guest69>guix pull: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused
<roptat>great, so the crash happens after connecting to the daemon
<Guest69>\ /gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
<roptat>the warning is just that: a warning, you can ignore it for now
<roptat>what if you run the daemon, and "guix build hello"
<Guest69>I found in the logs what happened
<Guest69>I will paste it
<Guest69> http://dontpad.com/guixlogs
<roptat>yeah, looks like it
<Guest53>`guix build hello` restarted it
<Guest53>does this log help?
<roptat>I think calling the daemon somehow violates a polkit policy, it freaks out and kills your session?
<roptat>I'm really not familiar with this part of the system, so I can't say for sure what happened
<Guest53>I don't understand polkit policy
<Guest53>Is pollkit related to what? Because even with TTY, it doesn't work
<Guest53>maybe it is from systemd, kernel?
<roptat>you might have more luck sending a message to help-guix@gnu.org, with that log, or maybe to whatever nixos uses for help
<roptat>a lot of these things are managed by systemd, it might not like the fact you're running the daemon manually from your session or whatever
<roptat>but I don't really understand how policykit gets involved
<Guest53>I will try to ask in Reddit
*dstolfa finished velcroing a fly net to the back of his laptop lid and is now waiting for the glue to dry overnight so he can have a little "pocket" in his laptop for devices
*nckx pops genielike out of raghavgururajan's backlight. You rang?
<nckx>Mind you, I have the mental faculties of an asparagus and am about to fall asleep. Simple questions & words.
<civodul>roptat: re memory exhaustion, what platform is this on?
<yoctocell>apteryx: you there?
<roptat>civodul, armhf, 2GB memory, and no substitute
<civodul>hmm!
<civodul>that's a recent 'guix' package?
<civodul>built with Guile 3.0.7?
<yoctocell>sneek: later tell apteryx have you seen https://issues.guix.gnu.org/issue/48934 ? Sometime ago you mentioned that the generated docs for service configurations had a different style compared to the hand-written ones. This should fix that.
<sneek>Got it.
<solene>what git branch should I follow if I want to track the most bleeding edge development? core-updates?
<dstolfa>has anyone noticed that gnome-weather doesn't start from the calendar applet and when the icon is clicked, but does from the shell?
<dstolfa>i saw that someone hit this back in 2020, but it's still here
<roptat>civodul, yes
<roptat>I pulled it a few days ago and didn't notice it was stuck
<roptat>at 93% the process stops doing any work (CPU is at 2%), but keeps using all the available memory
<roptat>last time I built guix was last month, I can't say how much memory it took, probably close to 100% too, but leaving just enough of free space to let the process finish
<roptat>could be that we have much more code now, or that guile requires more memory
<roptat>is there any way to prevent that? maybe splitting the build in smaller chuncks?
***iyzsong- is now known as iyzsong
<civodul>roptat: that's the 'guix' package, right?
<civodul>(guix self) splits package modules in a couple of chunks, but these are still big chunks
<civodul>solene: 'master'; 'core-updates' is not something you'd use, rather something to hack on
<roptat>civodul, yes, I'm building it because it's required by the system
<raghavgururajan>nckx: Oh we can talk tomorrow then. Sleep tight. o/
<nckx>Yeah, I'd fallen asleep.
<nckx>o/
<roptat>I can't reconfigure because of this
<raghavgururajan>> Guest53‎: I will try to ask in Reddit
<raghavgururajan>Use free software (https://guix.gnu.org/en/packages/giara-0.3/) to do so. ;-)
<roptat>raghavgururajan, but with guix not working that'll be difficult :p
<solene>civodul: ok
<civodul>roptat: we could arrange so "make" splits in a way comparable to what (guix self) does
<roptat>civodul, yeah, sounds good
<roptat>civodul, would it be possible to use the guix-daemon package instead of the whole guix package in the system declaration?
<roptat>or would that package be missing some important parts?
<roptat>mh... I replaced guix with guix-daemon in my guix-service-type, but reconfigure still tries to build guix
<roptat>I don't understand where that comes from
<vagrantc>guix comes from the internet
<roptat>the derivation has no referrer, which makes it even harder to understand
<civodul>i think vagrantc is right
<civodul>but maybe 'guix' is pulled by the activation snippet or something
<civodul>code that initializes /etc/guix/acl, for instance
<civodul>roptat: like i wrote earlier today, 'guix-daemon' alone won't work; it needs 'guix substitute', 'guix perform-download', and so on
<raghavgururajan>roptat: Oh, I didn't know that. Never mind, Guest53.
<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 guix@1.3.0-3.50dfbbf gnu/packages/package-management.scm:137 1729a00>
<roptat>I would have expected 1 to be of the wrong type instead
<roptat>oh, nevermind