IRC channel logs


back to list of logs

<Kabouik>I meant that appimage in particular robin
<nckx>Only delivered as a blob, mandatory ‘updates’.
<robin>nckx, yeah, it's an, uh, interesting design
<Kabouik>Is has merits though, this is one thing that made Windows-only softwares consider a Linux alternative because they could ship only one file instead of one flavour per distro
<robin>Kabouik, oic, so you really do need something like an FHS container
<Kabouik>I really don't know how I would do that
<nckx>Didn't someone have something like that? (Apologies if it's been linked before.)
<Kabouik>And having a dual boot for a cloud computing app seems like it's beating the point
*nckx fixed <> for now but don't ask me how.
<Kabouik>Searching for appimages, I see that robin themselves said that getting them to work on Guix is "hellishly difficult". Uh oh.
<Kabouik><- someone who needed 2 days to make a custom package definition for something that already existed in Guix channel.
<nckx>Does anyone else get text encoding artefacts in the first result for <>?
<Kabouik>The search shows appimages are a recurrent topic gor GuixSD but indeed I see no easy solution in the replies, sadly
<Kabouik>Except that but I have no idea how to use it and I doubt it's a end-user solution: 2021-02-24 [21:59:39] <pkill9> iis: i made a service for adding suport for things like appimages
<Kabouik>It's worth a try though, the Readme makes it looks like appimages should just run
<Kabouik>"Once your system has been reconfigured with this service added, you can run portable linux binaries, like Tar bundles and Appimages (All the ones I've tested have run so far)."
<pkill9>Kabouik: i havent tested it in ages so dunno if it needs updating but you add it as a service
<pkill9>i wanted to change it to a standalone script but didnt get round to it
<Kabouik>Oh, glad to see you here. Thanks for your work. I just added your channel and am pulling
<Kabouik>I'll try the appimage. I'm not holding my breath, there's probably a million reasons why it wouldn't work, but it's worth trying and hopefully it can work in the end.
<jacereda>wouldn't it be better to have the documentation in org? I guess org would be less of an entry barrier?
<Kabouik>Hum somehow building of pkill9-free.drv fails. This is my channels.scm:
<nckx>What does the error (or log) say?
<nckx>Get into the habit of including that too.
<Kabouik>, sorry nckx
<nckx>A lot has changed in 8 months.
<nckx>No need for sorries, just saves a question each time.
<nckx>Right, so:
<nckx>That will need to be fixed ‘upstream’.
<nckx>If pkill9 is still interested.
<jgart>how comes?
<jgart>here's my describe output:
<nckx>Kabouik: Otherwise, clone their repository to your machine, use a file:/// URL like you already do, and you can hack on it yourself. There doesn't seem to be a keyring branch so you won't have to mess about with signing, at least.
<Kabouik>I was doing that just now! Was looking at the patch
<jacereda>KE0VVT: I'm on the same boat, I've started with sddm + .config/sway/config, I'll migrate that to guix home at some point. I guess we badly need a sway-service-type.
<acrow>I've reverted my services to %base-services. Now I see that /run/users/$(id -u) does not exist. Hmmm... So, XDG_RUNTIME_DIR is pointing to the wrong place. Reading the manual I see that elogind or systemd is responsible for properly setting up XDG_RUNTIME_DIR... What guixsd service would do this if I am just running headless? Maybe I need to ask how to tell guix-home to know we are running without X. But shepherd seems to be
<acrow>unhappy without XDG_RUNTIME_DIR, so I don't understand. Can anyone straighten me out?
<nckx>jgart: I'm pulling. Machine is heavily loaded so will take a good while.
<jgart>someone earlier said they had the same revision as me and that `guix search ...` didn't fail for them like that
<jgart>so, I'm not sure why it's broken now
<jgart>might be something unrelated to the particular commit...
<mbakke>sneek: later tell notmaximed making native-inputs accessible for native builds would also solve
<nckx>jgart: It still hasn't finished but python-recutils does not look like a Guix package.
<nckx>Well, uhm, it's hardly surprising that ‘guix search‘ can't calculate the relevance of this description:
<nckx>Try #f or (if that fails) "" if you really don't feel like describing things today.
<jgart>oh.... thnx
<jgart>I'll just add a description for python-recutils
<jgart>let's see if that fixes it
<nckx>I guess we should add a ‘field sanitizer’ for this.
<nckx>If that's possible; I'm just skimming (guix records) here.
<jgart>that would be cool
<acrow>Setting up XDG_RUNTIME_DIR appears to be appropriate work for /etc/profile. At least that's my first guess.
<jgart>also, if anyone sees anything in GuixRUs that they want upstreamed feel free to take it and send a patch or just let me know and I'll add it to my TODO list to upstream it
<nckx>acrow: I don't think that's true.
<nckx>Do you have an elogind service in your list?
<jgart>If you're new and don't know what to work on for Guix development feel free to upstream things in GuixRUs that need upstreaming. Or, if you're not sure if it should be upstreamed feel free to ask me or someone else
<jgart>nckx, Do you think the license field of a package record being set to the empty string will break things as well?
<jgart>I think setting that field to #f might be safer?
<jgart>python-recutils does not have a license file
<nckx>There already is a (sanitize validate-texinfo) so either I'm barking up the wrong tree or it doesn't do what it should.
<jgart>I'm opening an issue to let the maintainers know if they'd like to add a license file to python-recutils
<nckx>#f is definitely more commonly done and hence safer.
<jgart>Yeah, I've seen #f used before in package fields
<jgart>I was just experimenting to see what worked or not
<nckx>Please do, since in a practical sense no licence = proprietary software.
<nckx>(Although we'll not get into that discussion 😛)
<acrow>nckx, no I thought that the fix for 52051 was going to solve a login problem I encountered a few weeks ago but it did not so I have backed gdm and elogind out of my system configs. This appears to be simply a ugly warning message that appears on login and generated by on-first-login but I would like to properly address it.
<jgart>python-recutils built fine with the empty string in the field but I guess it broke `guix search ...`
<nckx>acrow: Setting up /run/users/$(id -u) is elogind's job.
<nckx>jgart: Yes.
<acrow>nckx: so, I just need to add elogin-service-type back into my headless config and do a reconfigure?
<nckx>To solve this particular absence, yes.
<acrow>nckx: Thank you. I'll make that happen. One more gross conceptual error corrected!
<nckx>It's all terribly complex.
<acrow>I'm trying to imagine the ven diagram that shows what packages fall into the domains of the system, user-profile, and user-home. It's still a work in progress.
<acrow>Hmm. dumb question. Why isn't elogind in %base-services?
<nckx>It is.
<nckx>More easy trick questions please!
<nckx>No, it's just called login-service-type ☺
<nckx>Which I didn't know until I looked it up.
<nckx>So you're saying you do have it, and yet /run/users/1000 is *still* missing?
<acrow>Yeah. Well, let me do a pstree...
<jgart>nckx, here's one: Would it be possible to build a dsl or a new scheme dialect on top of guix's current API. If we think of it as a new distribution with a different syntax built on top of upstream's guile/guix VM/APIs.
<jacereda>How can I execute a certain `setpci` command as root when booting? Does that require a service?
<jgart>I'm thinking here like the relationship between gambit and gerbil
<jgart>gerbil runs on top of gambit
<singpolyma>jgart: guix bindings for other guile languages should be possible to create. Like for elisp or ecmascript or Python. It's on my infinite Todo list
<jacereda>I'm getting `FAIL: tests/` when running `make check`
<jgart>language-foo-clojure-janet-scheme-looking-thing-with-fancy-syntax-wrappers-macros-different-API runs on top of guile
<acrow>I configured %base-services but I don't see any elogind process or herd listing for it.
<jgart>I'm just thinking of New Year's wishes/dreams right now
<nckx>jgart: Guix is already a DSL. You mean a radically different language?
<jgart>singpolyma, oh so that might be the way to go about it instead of what I'm thinking of
<nckx>Oh, bindings might be the better word here yes.
<jgart>nckx, yes, a radically different scheme dialect
<jgart>with clojurisms, etc...
<jgart>like lokke
<nckx>Now I'm back to confused.
<nckx>Mainly because I don't know Clojure, Lokke, Gambit, or Gerbil.
<jgart>that link should bring you back to not confused hopefully
<singpolyma>jgart: implement it for the compiler tower and go to town, hehe
<nckx>Thanks, but I don't have time to learn yet a new thing from scratch now.
<jgart>nckx, we're just imagining that we hypothetically *do have the time* to learn yet another thing
<nckx>Oh that is fun.
<jgart>singpolyma, is that what lokke is doing?
<jgart>singpolyma, can you tell from a glance at it?
<singpolyma>jgart: no, I mean that what would be the ideal way to do it, would be to get it into the guile tower so the runtime is already the same and then it's just some glue code
<nckx>acrow: I was wrong with my glib answer. login-service-type is not logind.
<jgart>i don't fully understand the guile tree-il tower yet
<jgart>I'll have to do more homework/ask wingo
<nckx>acrow: This modern desktoppy stuff confuses the hell out of me. Sorry.
<singpolyma>jgart: for an alt scheme it should be extra easy because you don't need a new parser I would assume
<jgart>just new macros and function wrappers?
<jgart>maybe reader macros also?
<singpolyma>Yeah, something like that
<singpolyma>I've looked into the ecmascript tower the most right now, and it's about half parser half library glue
<nckx>acrow: It's in %desktop-services as ‘the D-Bus clique’ (which is the phrase I remembered and what made me take a second look‌ :). If you want/need it without %d-s, you can add it/them yourself:
<jgart>it'd be funny if racket could ffi with guile some how and the guix APIs so you can use anything in racket library/batteries included land for packaging guix packages or creating guix system definitions/services
<jgart>just for the sake of the hack
<nckx>acrow: There are valid uses to have it running on a non-desktop system but also valid uses for not having it, so it's not as easy as adding it to %base, which is supposed to be minimal.
<jgart>singpolyma, ecmacript seems it wasn't finished last I read
<singpolyma>jgart: yeah, doing guix bindings via something more like an ffi is possible
<acrow>nckx: np -- I'm in the same club. I think programmers spend a lot of time creating new things to avoid learning the older things. I think this is particularly true regarding X, which was way ahead of its time.
<singpolyma>jgart: depends what you call finished. It works
<jgart>can I write a guix package definition in ecmascript currently?
<singpolyma>Nothing is ever finished
<jgart>by calling Guix APIs
<jgart>from ecmascript
<singpolyma>jgart: ehhh. Yes, ish. It's not pretty because the entire guix API surface is macros
<jgart>how about brainfuck?
<jgart>I saw someone implemented that?
<jgart>maybe that's harder
<singpolyma>So to do it well you'd want to write a more jsish wrapper for Guix in scheme
<singpolyma>Then call that binding from js
<kitty1>Hello! Hows everyone? I think today is the day I finally clean my config.scm I havent touched in eons lmao
<singpolyma>If you do it generic enough maybe it would "just work" from python too
<nckx>I kind of expected this, but enforcing stringiness for Texinfo fields immediately fails within Guix itself:
<nckx>You are a braver kitty than I am, #1.
<jgart>then we can bring in the whole js crowd to Guix and show them how to package not like npm, haha
<singpolyma>Yeah. I did a bunch of work on guix in js a few year ago, but only got as far as understanding not making anything good
<jgart>gambit and common lisp have pretty good support™️ for python
<singpolyma>jgart: well python on guile is already a thing. I have not dug in super deep
*nckx hands jgart a ™ so they don't have to use that weird-ass thing.
<jgart>that was from gajim's emoji widget
<nckx>kitty1: And I am well, thanks for asking :) Hope you are too.
<jgart>blame gajim ha
<jgart>I'm hoping to switch to profanity soon
<jgart>I mean the xmpp terminal client
<nckx>Cool. I have yet to board the XMPP hype train.
<kitty1>xmpp is nice
<jgart>or aparte once they have omemo support:
<kitty1>havent heard of that client
<jgart>nckx, It's all hype but I'm too lazy to move right now.
<jgart>I'd be happy to just migrate to email and irc+bouncer
<kitty1>what's bouncer?
<nckx>kitty1: Something like ZNC.
<jgart>znc, pounce, soju, etc...
<kitty1>haha I don't know what ZNC is although the name sounds familiar...
<jgart>just think of it as persistent irc history
<nckx>kitty1: Pretty (well) pictures:
<nckx>ZNC is an ancient piece of C code but it's like 99% of all bouncers out there. jgart could name others; I couldn't.
<Kabouik>I personally use a VPS connected to IRC with a terminal client (Tiny) and I ed/ssh/mosh into that
<jgart>pounce and soju are simpler bouncers from what I've researched
<Noisytoot>™️ = U+2122 TRADE MARK SIGN (™) + U+FE0F VARIATION SELECTOR-16 (️)
<Kabouik>Pretty happy with it
<nckx>Ah, so U+FE0F is the make-everything-shit modifier.
<nckx>Thanks toots.
<jgart>I know someone who just has hexhcat running 24/7 on a server, bouncer shrug 🤷‍♂️️
<nckx>HexChat is too beautiful to run anywhere but right in front of your face holes.
<nckx>(No it's ugly but I love it still.)
<Kabouik>It really is
<jgart>catgirl is nice:
<jgart>guix show catgirl
<nckx>Kabouik: You meant et, not ed, right? If you are chatting to us live with ed, I want to know.
<Noisytoot>catgirl only supports connecting to one network and doesn't support plaintext
<jgart>ed and ii
<nckx>ii is truly the ed of IRC clients, which is about all I can say of it.
<jgart>I tried guix packaging the other day with ed
<jgart>was bored
<jgart>fun times
<nckx>I once tried to script something with sic, which is ii but even worse.
<jgart>maybe, I'll live stream that sometime or make an asciinema of it
<Kabouik>nckx I meant et, indeed. That's my setup right now from the phone: et to GuixSD on the left, et to Tiny on a Debian VPS on the right
<jgart>nckx, I've used sic before
<jgart>I think there is an emacs mode for ii
<jgart>emacs interface
<kitty1>jgart: ah that client looks neat, profanity I know is nice
<Noisytoot>What's et and Tiny?
<jgart>when erc or whatnot is not enough or too much
<kitty1>nckx: ooooo I wasn't aware of that, that looks quite cool
<nckx>Noisytoot: et = EternalTerminal, similar to mosh (but I think biggerful?).
<nckx>I only use mosh.
<nckx>Which has its annoyances.
<Kabouik>et stands for eternal-terminal, a fancy ssh/mosh thing that claims to be better, Tiny is a rust TUI minimal iIRC client (and easy to set up, unlike irssi and Weechat imo)
<nckx>Does et do advanced modern things like ‘scroll back’? It probably does. I should probably switch. But… habit.
<Kabouik>I think it does nckx, but I don't have a mouse right now, I'm scrolling back using keybindings and I'm not sure if that's et or kitty terminal that does it
<Noisytoot>Unfortunately tiny doesn't seem to support SASL EXTERNAL.
<kitty1>speaking of IRC, normally I use my xmpp client as an IRC client, but im just kinda playing around with dedicated IRC clients right now (currently messing with weechat, it seems pretty nice and might stick with it or go back to using XMPP for IRC), on this topic anyone know any notably good ones to try out?
<Noisytoot>weechat doesn't handle floods well
<nckx>Kabouik: It wouldn't matter. The way mosh works is there *is* no scrollback, so nothing for your local terminal emulator to keep in memory.
<acrow>Any good words concerning mosh? Is it worth setting up?
<nckx>There's very little set-up. Install it on both hosts, should work, unless UDP is firewalled.
<nckx>Apart from the lack of scrollback it's great.
<Noisytoot>It is very slow when you're in channel full of markov bots and bots controlling other bots (irc-to-irc) on pissnet.
<jgart>acrow, a friend at work uses mosh often
<jgart>I use it on and off
<jgart>not often
<Kabouik>That was the reason why I tried to replace mosh actually nckx. For IRC that didn't matter because tiny has it's own scrollback and using its own keybinding would show above history and convey it to mosh, but shell scrollback couldn't work
<nckx>Kabouik: So in a way it would be weird if et did its ‘own’ scrollback; should let the local terminal emulator do that if it can.
<Kabouik>I can confirm I can scrollback my irc history without using the builtin tiny scrollback here. Let me reconnect through mosh and compare.
<Kabouik>Yeah, confirmed. Scrollback works fine with et, and et only.
<Kabouik>Except if using my IRC client's builtin scrollback.
<phodina[m]><notmaximed> "Possibly can be..." <- Setting -rpath to cwd seems to work, though now for some reason I get
<phodina[m]>invalid linker name in argument '-fuse-ld=mold'
<phodina[m]>Any ideas how to fix that? I do see the mold binary in the root of the failed build dir
<nckx>jgart: Why did you use '() anyway? I'm going to punt on the stricter validation thing, because it's not worth breaking the very tiny number of unusual packages like
<nckx>phodina[m]: Is it in $PATH there?
<phodina[m]>* Setting -rpath to cwd seems to work, though now for some reason I get
<phodina[m]>invalid linker name in argument '-fuse-ld=mold'
<phodina[m]>Any ideas how to fix that? I do see the mold binary in the root of the failed build dir
<Kabouik>Have you tried --no-init in mosh nckx? I think allows *some* limited scrollback in I-don't-remember-which-condition
<nckx>(gcc)Link Options is interesting. It's formatted as if it's a hard-coded list (bfd, gold, lld), not a free parameter.
<nckx>phodina[m]: ☝
<phodina[m]>nckx: Yeah, that might be the issue, there's juet symlink for cc. I'll try to add the path there as well
<nckx>But maybe it's just odd formatting.
<jgart>I updated `python-recutils` and it's fixed now :tada:
<jgart>nckx, I'm not sure why I chose the empty list
<nckx>Kabouik: I hadn't. Interesting. But yeah, it's only one screenful or so.
<nckx>Then I get local left-overs.
<jgart>It was just curious if it would break anything or if it would take it just fine
<jgart>It seems it took it at first but then broke `guix search`
<jgart>not sure what else might have broken in the process
<nckx>Kabouik: It's not useful enough in practice for me to start using it, but thanks for the tip! I was unaware.
<Kabouik>nckx regarding the build-system.scm patch you linked before to fix pkill9's channel, I'm not sure where to apply it. pkill9's channel had no build-system.scm file. I found a "meson-for-build" occurrence in packages/cage.scm, which I commented out to mimic the patch, but that would have been too simple.
<phodina[m]>nckx: I do see the mold linker as an option.
<phodina[m]>Adding the mold to the PATH didn't work
<sam_>mold only _just_ got support added in gcc git
<sam_>otherwise you need to use a workaround (see the mold README)
<nckx>Kabouik: Oh, no, that patch was the patch to Guix that removed meson-for-build, as explanation.
<sam_>or wait until GCC 12 ;)
<nckx>The change to pkill9's channel should be as simple as running sed s/meson-for-build/meson/g on the thing, but I didn't check or write a patch ☺
<Kabouik>I can try that!
<nckx>Thanks sam_.
<nckx>So it is a hard-coded list.
<sam_>yeah, it's.. disappointing
<sam_>see too
<nckx>(Not just list, I'm sure more goes into linker support than adding its name to a list, no disrespect.)
<sam_>clang doens't have this issue
<sam_>you'd think that, and yet;a=commitdiff;h=ad964f7eaef9c03ce68a01cfdd7fde9d56524868! :D
<nckx>(Oh, or maybe not.)
<sam_>i'm sure there is a good reason for it but i don't know what it is
<nckx>I was trying to be all nice and understanding.
<sam_>it's probably something to do with making sure linkers have the right support for things, but uh, i've got to admit, i don't fully get it either
<sam_>on the upside that patch should be easy to backport
<sam_>i think it applies cleanly to 11
<acrow>nckx: it does appear that elogind is the process that mounts the tmpfs /run/user. the elogind service extends %elogind-file-system to do so. This is all associated with the desktop which I'm not using, but seems necessary to allow local-user-shepherd to do it's things which may or may not be desktoppy.
<nckx>acrow: A (IMO small, but no data) minority of users use user Shepherd, but good point, might change with guix home adoption.
<nckx> → hipster ▶ mark-up not searchable at least in Firefox. That is naasty.
<acrow>nckx: I'm going to do what we discussed earlier since I implemented (for no apparent reason) my own guix-home and seeing what happens when I re-enable elogind is much easier than trying to go deeper at this point.
<phodina[m]><sam_> "clang doens't have this issue" <- Do you think the tests are meant to be run with clang as well? There is the cc and clang commands. This confuses me
<sam_>phodina[m]: Sorry, could you explain a bit more? (Referring to mold there.)
<nckx>phodina[m]: Maybe the tests explicity want to test *both*?
<nckx>That would make most sense to me.
<sam_>ah, I see now
<nckx>Since they also tell you to install wild things like gcc-10-aarch64-linux-gnu as a test dependency.
<sam_>what is this the test suite for?
<sam_>mold itself?
<phodina[m]>sam_: Sure. Talking about the mold. If you take a look at the repo there is dir test/elf with scripts yo test the built linker. In the test there are commands that call cc and clang.
<phodina[m]>Do you think cc stands for gcc or clang?
<sam_>'cc' definitely won't work as gcc for now so I think the tests expect Clang right now for that one test at _least_. FWIW, I did manage to build mold and run most of the tests w/ gcc before though (I reported a bug too).
<phodina[m]>nckx: That's what I thought as well and made symlink for cc to gcc. As it does not honour the CC variable unfortunately
<sam_>I suspect that one exact test should be changed to clang for now or skip if CC is gcc
<sam_>yeah, I did a PR to fix all the CC references but not in the tests yet :(
<phodina[m]>sam_: yes
<nckx> 'cc' definitely won't work as gcc for now> Why's that?
<sam_>nckx: because it tries to do cc ... -fuse-ld=mold .. which won't work unless >= GCC 12
<sam_>so I think it should really be doing 'clang ...' or just skipping if CC != clang
<nckx>Oh, OK, but not some deeper issue.
<phodina[m]>sam_: Ok. Thanks for explanation. I'll attempt to run the tests with clang only for now
<sam_>yeah, nothing scary, thankfully
<sam_>phodina[m]: no problem! Please let me know if you get the tests passing in Guix. I'm the Gentoo maintainer for mold but I like to hang out in other channels to learn/chat/whatever. I couldn't get them entirely passing yet due to path issues, but most of them passed.
<nckx>I thought your name sounded familiar. Someone exposed you as a British operative in #libera earlier today. Your cover is blown. :(
<sam_>wait what haha
<phodina[m]>sam_: Ok, I run currently with clang-12. There is some error. In the readme they mention clang-13.
<phodina[m]>Unfortunately version 13 is not yet packaged for Guix
<nckx>I think they were a loon.
<sam_> nckx: I'd love to see the log if you've still got it, I didn't know I was famous! :D
<phodina[m]>I'll pick the failing tests and disable them for now util the newer version of GCC or Clang is ready
<jgart>deadgrep yay: gj gk
<jgart>guix install emacs-evil-collection --with-commit=emacs-evil-collection=72735fb733fa420c0e4e0ec0531c190489a0817b
<Kabouik>Did libgme get removed too? I'm trying to fix errors in pkill9's channel after 8 months of guix updates but couldn't find info on libgme
<jgart>Kabouik, `guix show libgme`?
<Kabouik>It's still here then, thank you jgart. I'm getting "(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (libgme)) (value #f))", that's why I wanted to check it.
<acrow>On activation of a guix-home environment has anyone seen this error:
<acrow>WARNING: Use of 'load' in declarative module (#{ g92}#). Add #:declarative? #f to your define-module invocation. ??
<acrow>I don't think it is wrong for me to be puzzled by that.
<Kabouik>I just removed the srb2kart.scp scheme that included ligbgme, won't use it anyway. Now I got pkill9 channel working after some slight changes, will try to enable the fsh service tomorrow for appimages. Fingers crossed.
<_ctb>Newbie question, how I do generate the sha256 for a custom package I'm writing?
<jgart>_ctb, try building it and letting it fail
<jgart>the sha256 will be printed to standard output
<jgart>make sure you're source field is correct and has the correct url etc... for that to work
<hasjplante03[m]>you could also do guix download <source url>
<jgart>_ctb, following hasjplante03[m]'s suggestion, with nnn, you could do the following
<jgart>guix download
<jgart>_ctb, `guix download` would produce a different hash that you don't want
<_ctb>Thanks, it worked :)
<gnoo_>How can i chroot into a guix system?
<vagrantc>gnoo_: you basically have to set the appropriate PATH and various other environment variables ... it's tricky.
<gnoo_>thanks, any guides on how i can do that? Or any recommendations?
<gnoo_>Oh wait, old version booted up
<vagrantc>i gave up and solved my issues through some other means :)
<gnoo_>Any idea why this very simple config refuses to let root or me login?
<gnoo_>i can boot, but not login. gdm doesnt even start and logging in with tty bails with 'Error in service module'
<gnoo_>After running guix system switch-generation 3, i can not login in tty5 so its something in that config?
<gnoo_>The only difference between 1st gen and 2nd is.(id 1002). That makes it unable to login on two tries but works on third. Then on 3rd gen, i added a group with id 1002 which doesnt let me login at all
*vagrantc blinks
<gnoo>phew, can finally login
<gnoo_>Great. Gdm doesnot start and the whole system hangs (have to use magic sysrq keys to reboot) if i try to use X
<gnoo_>And after reboot, cant login at all
<jgart>gnoo_, how did you install Guix System?
<jgart>with the graphical installer?
<gnoo_>No, with guix system init
<jgart>oh, ok via command line all the way
<gnoo_>Yeah, i wanted to use my old /home
<jgart>I think the graphical installer had some issues last time I used it. Not sure if they've been resolved
<gnoo_>Is 'error in service module' a guix thing or logind thing?
<jgart>hmmm not sure, sounds like a guix thing but maybe someone else knows better than I
<hasjplante03[m]>has anyone had any luck with the nicotine+ package?
<hasjplante03[m]>it errors out when running the executable
<jgart>hasjplante03[m], it could use an upgrade
<jgart>current version is 3.2.0
<jgart>probably some dep upgrade broke it
<vagrantc>when fixing massive amounts of typos, is it better one commit per typo, or similar commits all lumped into a signle commit?
<vagrantc> 23 files changed, 35 insertions(+), 35 deletions(-) bunch of one-line changes
<vagrantc>i would normally do one commit per, but that's a lot of signed commits
<vagrantc>mostly dealing with trailing whitespace in description/synopsis
<vagrantc>but i guess that only catches ~60% of them
<mahmooz>any idea how i can get the cow-store service on my custom iso?
<hasjplante03[m]>i managed to make nicotine+ work by updating to latest version and deleting the check phase
<jgart>hasjplante03[m], cool!
<jgart>hasjplante03[m], do you happen to know why the tests were failing?
<jgart>how many failed?
<jgart>can you paste the check phase report that is printed to standard output?
<hasjplante03[m]>this is with the check phase enabled
<hasjplante03[m]>sorry for the late reply
<jgart>cool, no worries
<jgart>can you share the current package definition?
<hasjplante03[m]>looks like its just failing because it doesn't recognize the argument
<hasjplante03[m]>its very simple, i just bumped the source
<hasjplante03[m]>it works if i remove the check phase while leaving everything else intact
<jgart>If you're going to send to upstream you can probably just call the package nicotine+
<jgart>and replace the old one
<jgart>looks like there are a lot more deps that the original packager never included:
<jgart>unless that requirements.txt file is not up to date
*jgart reads the code
<jgart>oops wrong package
<jgart>wrong nicotine
<jgart>one sec
<jgart>github and their "You have exceeded a secondary rate limit." bug
<jgart>hasjplante03[m], looks like nixpkgs has the check phase disabled also:
<jgart>might be a reason for it
<hasjplante03[m]>hmmm, i don't think nicotine+ actually has tests now
<hasjplante03[m]>ill probably send it upstream with the check phase disabled
<hasjplante03[m]>it definitely has tests
<hasjplante03[m]>i don't know why guix is unable to run them
<jgart>hasjplante03[m], looks like the reason for disabling the tests was never discussed
<jgart>for the nixpkgs pr
<jgart>hasjplante03[m], I just built the current version of nicotine+ in guix
<jgart>hasjplante03[m], tests were never actually run
<jgart>hasjplante03[m], Ran 0 tests in 0.000s
<jgart>so we never had tests for nicotine+ anyways
<jgart>hasjplante03[m], yup, just send the patch to upstream you have without tests
<hasjplante03[m]>will do!
<jgart>hasjplante03[m], how's Soulseek?
<jgart>worth checking out?
<hasjplante03[m]>jgart definitely, soulseek has no competitors when it comes to amount of lossless music.
<jgart>how about video?
<hasjplante03[m]>it is technically possible to share those things there but it is used as music-only
<hasjplante03[m]>so you will probably not find any videos/movies there
<jgart>ohh ok
<mothacehe>hey guix!
<jgart>hi mothacehe, do you happen to know if anyone is working on preparing Guix System for pinephone?
<xd1le>i think pinephone requires some blobs or something no?
<xd1le>for the radio
<xd1le>though i haven't checked in a while maybe the situation changed
<xd1le>(kernel blobs)
<mothacehe>jgart: no, i'm not familiar with the pinephone
<mothacehe>pinebook pro should work though
<jgart>thnx yup, I've seen that
<hasjplante03[m]>jgart there's this but i think it's dead
<hasjplante03[m]>(it's also just a system configuration)
<jgart>hasjplante03[m], might be useful to pair up with nix devs on this one:
<jgart>they seem to have everything packaged and in a working state
<jgart>hasjplante03[m], I started packaging software from sxmo:
<jgart>for GuixRUs
<jgart>If upstream will accept any of those early even though we don't have a working pinephone Guix System yet let me know
<jgart>Yup, I've browsed through that repo before
<vldn[m]>ehm how to use and debug guix definitions like channel and other things with guile geiser?
<jgart>They are using an alternate kernel
<jgart>vldn[m], what are you trying to debug?
<vldn[m]>my channel definition
<jgart>can you share it?
<vldn[m]>and maybe some packages later
<vldn[m]>sxmo some really cool shit!! bookmark this
<hasjplante03[m]>jgart isn't pinephone still relying on proprietary blobs to work? wouldn't that stop anything from being upstreamed?
<jgart>sxmo is definitely worth looking into
<vldn[m]>but some wayland alternative would better!
<jgart>it's my favourite pinephone distro so far
<jgart>that's swmo
<vldn[m]>sway or kiosk or something
<jgart>sway with sxmo
<hasjplante03[m]>i run sxmo on my pinephone, it's very pleasant to use.
<jgart>it exists
<vldn[m]>aaaaah nice xDD
<jgart>yup me too
<vldn[m]>super cool
<vldn[m]>i will make a distro for my old sony phone with it
<vldn[m]>so nice
<jgart>sxmo is what my dream smart phone looked like in my dream
<vldn[m]>yeah its the same way i had built it xD
<vldn[m]>already fiddled with dwm on my old nexus7
<vldn[m]>and a bunch of scripts to get all touchy
<jgart>vldn[m], if you'd like to contribute to upstream let me know. I have some packages in GuixRUs that can be upstreamed
<vldn[m]>i'll make the first entry with mobile nixos i think
<jgart>You can list yourself as Co-author if you upstream them. Just mention the original package author also
<vldn[m]>till i get more convenient with all needed packages for the uboot and such
<jgart>I think the sxmo packages in GuixRUs can be upstreamed, for example
<jgart>We have a ton of emacs packages recently that can be upstreamed also
<jgart>just have a look
<jgart>if you have any questions about building and testing the packages before sending to upstream just let me know
<jgart>vldn[m], patches can be sent here:
<jgart>hasjplante03[m], sxmo stuff is free software
<jgart>but if the kernel they rely on has blobs then that will be a no go
<jgart>haven't fully researched that yet
<hasjplante03[m]>yeah, im pretty sure the kernel contains non free blobs so it has to be a community project
<jgart>kernel would have to be put somewhere else in that case
<vldn[m]>just host them in a git repo somewhere
<hasjplante03[m]>it looks like there's no blobs in the kernel
<hasjplante03[m]>only in the firmware of the device
<jgart>that's the pinephone kernel used:
<vldn[m]>i love the mobile nixos effort, you are using it currently?
<jgart>The LTE modem on the PinePhone is a ‘black box’, and runs its own Linux system internally. This includes all the proprietary modules (blobs) needed to run the actual cellular radios.
<jgart>vldn[m], I'm not
<jgart>I'm running pmos
<hasjplante03[m]>packaging the pinephone kernel shouldn't be that hard
<jgart>with sxmo stuff
<jgart>If you'd like to package it for a community channel send a patch to GuixRUs
<jgart>We're having a meetup in January to discuss the channel in more detail
<jgart>does pinebook pro run without kernel blobs?
<mothacehe> yes it does
<jgart>maybe we can get a version of pinephone working with the modem disabled for Guix System
<jgart>like replicant does
<jgart>ignore last msg
<jgart>I'll have to reread what replicant does exactly with their modem and kernel ;()
<hasjplante03[m]>jgart i'll contribute some emacs packages that i see are missing
<jgart>I wouldn't mind running Guix System on a pinephone with a kernel that doesn't support the modem feature
<jgart>All the emacs packages in GuixRUs are missing from upstream
<jgart>so feel free to do so unless they are missing licenses
<jgart>in that case contact the authors on github, etc... and ask them to add a license so that we can upstream their package
<jgart>hasjplante03[m], GuixRUs has a channel at #whereiseveryone on network
<jgart>an irc channel, that is ;()
<jgart>vldn[m], hasjplante03[m] I have a replicant phone also (N7100)
<jgart>I had two replicant phones but i9300 RIP
<jgart>got it for $27 on ebay and flashed it
<nckx>sneek: later tell vagrantc: Especially for identical changes across many packages, I would have recommended a single commit had I been awake 😉
<sneek>Got it.
<nckx>sneek: botsnack
<mahmooz>guix system: error: integer expected from strea
<mahmooz>any idea why im getting this when running `guix system`
<mahmooz>there is an issue about it here
<nckx>Your daemon is old.
<mahmooz>i just installed it
<mahmooz>on arch
<mahmooz>how do i update it
<mahmooz>oh so its because i was running guix without sudo
<mahmooz>i see
<mahmooz>thanks guys
<jgart>maybe we should add a doc for doas users
<jgart>`doas -u root guix pull`
<nckx>Weird, my side lost their quit message.
<nckx>jgart: sudo is so common though. Are there distributions without it?
<jgart>There are distributions that don't install it for you
<nckx>Similar to how we give systemctl examples because if you use something else, chances are extremely high that you won't actually need the examples.
<jgart>so you can choose
<nckx>But wouldn't they recommend sudo to people who don't know what's what?
<jgart>depends the distro
<jgart>and the audience, I guess
<vldn[m]>someone proficient with cuirass api? i would like to know the www api url to query the evaluations with a specification AND a channel name set
<vldn[m]>i just want to get the eval of one channel (3 are in the specification)
<mothacehe> rekado: i'm taking care of rsync'ing the SAN publish cache to bayfront, that's a nice idea.
<jpoiret>mothacehe: did you send an email on the installer dump page? I only see the maintenance service, but I'd like to discuss it a bit more (I'm not sure users would always want to upload their whole syslog or dmesg, privacy-wise)
<mothacehe>cbaines: would it be possible to restore the publish server on bayfront, or could we have the nar-herder serve the /var/cache/guix/publish directory?
<jpoiret>also, for now the installer tries to log to syslog, but we could instead log to a separate file, no?
<jpoiret>i'm currently rebasing my changes on yours
<jpoiret>Also, I think i'll rewrite the current installer-abort machinery to use exceptions, so that we can pass whole exceptions along with them
<nckx>I'm a bit lost at this point *exactly* which cache and storage medium is [going to be] what, and what, if anything, is just intermediate shuffling. Is this described somewhere central?
<mothacehe>jpoiret: yes, that's something we need to discuss. I'll send a patchset for the wip-harden-installer branch
<mothacehe>i made the crash dump send optional
<mothacehe>but maybe dmesg/syslog shares too much information
<jpoiret>(by the way, the new run-command-in-installer I implemented works very well, it displays which command is going to be run, asks the user and switches to a tty for it)
<mothacehe>woo, can't wait to test it :)
<mothacehe>jpoiret: you mean the abort mechanism in (gnu installer steps)?
<jpoiret>and the main issue behind the 0G disks crashing the installer is that there isn't enough space for a GPT partition table, and we don't check if the return value of mklabel (disk-new) is non-#f
<mothacehe>if you have a look to the installer dump patch, you'll see that i had to introduce a dirty hash map to capture the current installer state
<mothacehe>if you can manage to get rid of that, would be great :)
<mothacehe>re mklabel, the > 2GiB mitigates it but it would be nice to also check the mklabel return value indeed
<jpoiret>i've added an exception there
<jpoiret>the issue is, for now its caught by installer-program and it aborts the whole installer, i'd like instead to make it only abort the installer step and display a message to the user at the same time, hence the rewriting the installer-step-abort to use exceptions
<mothacehe>ambitious task, but certainly right thing to do
<jpoiret>less ambitious now that I understand guile exceptions :)
<jpoiret>but yes, that'll mean rewriting all the places it's used at too
<mothacehe>hehe, i'll learn from that I guess :)
<jgart>nckx, wdyt?
<mothacehe>nckx: the more central place for the storage issue would be this ticket:, in particular the last rekado mail.
<nckx>jpoiret: As apparently too subtly implied (apologies), I'm not a fan of including examples for each increasingly niche alternative. I think doas users know how to use doas. But if the majority thinks it adds value the patch LGTM.
<nckx>Thanks mothacehe.
<nckx>Oops: jpoiret → jgart. More pologies.
<jgart>nckx, Ok thanks for the review. I think more people are starting to use doas on linux recently.
<nckx>I don't doubt that at all.
<vldn[m]>someone proficient with cuirass api? i would like to know the www api url to query the evaluations with a specification AND a channel name set ,i just want to get the eval of one channel (3 are in the specification)
<mothacehe>vldn[m]: you mean all the packages related to the specification X and the channel Y?
<jgart>nckx, > I think doas users know how to use doas.
<jgart>The same can be said for sudo users.
<jgart>The other alternative is to just say something like "Upgrade the build daemon with @command{guix pull} as root user" and not mention sudo at all
<nckx>And that's where I somewhat disagree.
<mothacehe>that's not possible for now. We would need for that to track which channel contribute to which package
<mothacehe>but that's an interesting suggestion
<jgart>But then the docs are less comfy with the alternative I suggested in my last msg
<jgart>less comfy for inexperienced users
***iyzsong- is now known as iyzsong
<nckx>Users who have no clue how to use sudo must still use it, because it's the de facto standard and default almost everywhere. This is far less true of doas, the vast majority of installations being by informed users who dislike sudo for whatever reason.
<vldn[m]>are you proficient with guile-json mothacehe?
<jgart>I prefer explicit docs that don't assume to much, though
<nckx>Inexperienced users don't install doas over sudo.
<nckx>But I think I've made my point, for whatever it's worth.
<jgart>like the gentoo installation handbook
<nckx>Regarding ‘the patch LGTM’, actually: I think it should add doas examples to all sudo examples, then, otherwise it's a bit ad hoc ☺
<florhizome[m]>There are plenty of instructions out there that don’t really mention sudo at all
<florhizome[m]>Your shell will just tell you that you lack preferences
<jgart>Can that be done in a separate commit and later as we go adding more docs?
<nckx>I've never lacked a preference in my life. I have one about anything.
<jgart>I guess it can be added to the cookbook instead if people prefer
<jgart>Or a blog post or mastadon tweet to be lost haha
<jgart>There's also these doc patches from the Guix Documentation Meetup if anyone has time to review them further:
<nckx>jgart: There are far fewer full sudo examples in the manual than I thought. Still, I don't see why we would single out on example for doasisation, and then omit it from e.g. (guix)After System Installation
<vldn[m]> i'm filtering the specification from the cuirass evaluation atm this way, but i don't know how to filter out all evals with a channelname
<jgart>might be nice to have something like this upstreamed at some point
<jgart>doas service ;()
<jgart>not sure what to do about pairing the doas examples with the sudo examples in the docs at the moment
<jgart>I'll sleep on it
<jgart>I think it could be encouraging for new users who would like to make a choice between sudo and opendoas
<jgart>we do have an opendoas package
<jgart>guix show opendoas
<jgart>NixOS has good support for opendoas with a service and all:
<jgart>If we end up adding an opendoas service to Guix System then it might make sense to document doas usage by Guixers more?
<jgart>anyways, I'll think more about it
<jgart>going to sleep finally
<nckx>My argument was never ‘it's not in Guix’ or ‘there is no service’.
<ss2>is there a way to keep the tmp build directory with a succesful build?
<nckx>jgart: Good night!
<nckx>La nuit porte conseil.
<ss2>good night! :)
<nckx>ss2: I don't think so, I always (add-after 'install 'punt (lambda _ punt)) or so.
<ss2>which breaks it? cool!
<ss2>copying that.
<nckx>There are default phases after 'install in most build systems but I've never had to debug their effects specifically, so I didn't bother remembering which is truly last.
<ss2>okay, I’m only hacking on a definition, and would like to see the after effects of it.
<nckx>That will most certainl do.
<jgart>nckx, mon français est merdique, buenas noches!
<asdf-uiop>Hi! Is there a way to ensure that `guix install' only uses substitutes? My understanding was that this should be the default because there are `fallback' and `no-substitutes' options, but my system seems to be building qtbase right now.
<nckx>asdf-uiop: I'm afraid not. Substitutes are always a transparent optimisation for local builds from source. --fallback means ‘build locally *even if* there was a substitute but we failed to fetch it’ (and often doesn't work in practice), --no-substitutes means ‘never even check for any’.
<nckx>* (and often doesn't work where people expect it to, in practice)
<vldn[m]>i'm working on that atm asdf-uiop
<vldn[m]>hate that too
<nckx>Did Berlin GC die a natural death today? Tentative \o/ then.
<asdf-uiop>nckx, vldn[m]: Thanks! Since I have no idea how hard it is to implement this behaviour: wouldn't it make sense to clarify the wording of the documenation for --fallback in the meantime?
<mekeor[m]>nckx: what's berlin-gc?
<nckx>‘guix gc’ on the Berlin build farm (ci.guix).
<nckx>Due to the current design, builds halt whilst it's running.
<paul_j>Morning all! I am trying out guix home, and following the basic instructions in the documentation I imported the current configuration, then reconfigured using the output configuration without making any changes. Nearly everything seems to have worked as expected, with the exception of .bashrc. The original content in my .bashrc is duplicated twice in the file in the store. Has anyone else seen this? I am just loading the guix repo to
<paul_j>start having a good look through the source to see if I can see why for myself!
<jlicht>hey guix!
<mekeor[m]>hi guix, hi jlicht :)
***aya is now known as gyara
<jpoiret>oh no
<jpoiret>i've started to really understand prompts/continuations and the like, and now I want to rewrite the whole installer to use it :(
<awb99>Should it be sufficient if nss-certs are installed onlz in the OS profile?
<awb99>I had the issue that the necessary SSL exports did not happen when I only had the nss-certs in the os profile.
<awb99>Can someone explain me how this works?
<mekeor[m]>SSL exports did not happen? what does that mean?
<awb99>SSL_CERT_DIR environment variable did not get set automatically
<Kabouik>I tried adding fhs-binaries-compatibility-service-type service as shown in your config in Gitlab pkill9 but I fumbled. This is my system.scm: pkill9-channel is enabled and guix pulled, but on guix system reconfigure to add the service, I get: "/home/mat/.config/guix/system.scm:20:11: error: manifest->packages: unbound variable. hint: Did you forget a `use-modules' form?" Not sure what I should put in use-modules on top on what
<Kabouik>is already there. It's not straightforward to me how to merge your config with mine to enable the service.
<Nazar>Hello there) i'm buliding package which depends on another, and in install phase it tries to add additional extension to other package, but got an error with Installing shared extensions: /gnu/store/zzjxddmsarnz038q5991z6ls3fk62jc3-php72-7.2.34/lib/php/extensions/no-debug-non-zts-20170718/
<Nazar>cp: cannot create regular file Persmission denied
<Nazar>any suggestions ?:)
<awb99>hi kabouiik:
<awb99>I tzpically have a test scm file,
<awb99>which I evaluate with: guix repl ./modules/awb99/test.scm
<awb99>the warnigns and error messages this way are much more helpful than if I just try to rebuild a profile.
<awb99>this is my test script.
<awb99>just a big list of includes.
<awb99>if any of the inclulded modules has an error, then I will see a much more detailed error message.
<awb99>this is my primitive version of a unit test for my guix modules.
<awb99>I hope that helps you, Kabouik
<Kabouik>Thanks awb99. So I should replace your includes with those in my system.scm, see if I get more info, or should I keep test.scm as is and somehow tell it to evaluate system.scm?
<awb99>delete my includes,
<awb99>and add the ones you have
<awb99>I try to do everything in a module,
<awb99>and ake my manifest and os-definition files very small.
<awb99>this link is an almost manifest.
<awb99>but it is a module.
<awb99>the only thing that you have to do is set the guile load path
<awb99>I have set the env var "GUILE_LOAD_PATH" to "./modules"
<Kabouik>I'm not yet fully comfortable with the Guix linguo (manifest, modules)
<nckx>sneek: later tell jgart: <doas> I swear this zimoun fellow is not some poorly-disguised sock-puppet of mine.
<awb99>module .. a scm file, it can contain any guile code.
<jpoiret>Nazar: looks like the extension installation process is basically "please copy me where it is installed". But that won't work here as all store directories are read-only, except for the one you're currently building.
<awb99>manifest .. a scm code file where the last expression is a manifest, this is essentiallz a list of packages zou wnat to install.
<awb99>to create a guix os the last expression in the scm file has to return a os defintion.
<Nazar>jpoiret yes but then this pkg should be compiled with that one ? on which they depends
<Nazar>can i build like two packages in one or ?
<Kabouik>But you said you try to make your manifest and os-definition very small and do everything you can in a module, if this is more advanced than the default, maybe I should avoid that until I better understand what I am doing
<Nazar> here is that extensions
<jpoiret>No, rather, you should patch the main package to support loading extensions through an environment variable rather than in an hardcoded location.
<jpoiret>Maybe it's already been done for php, I'm not familiar with that.
<Nazar>hm, okay, i will leave extension in that pkg, and just put the path for the extension in the conf file of php. okay let's try
<mahmooz>is i interrupt guix downloading a package
<mahmooz>if i run the same command again would it continue where it left off
<mahmooz>or would it start all over?
<mahmooz>because its taking me ages to download texlive
<mahmooz>for some reason the guix substitute server is throttling my connection or is just slow
<gnoo>mahmooz: how slow do you mean? i think 100kbps is normal for me, sometimes goes down till 29kbps :'<
<awb99>I have 2mb normally for package download. but sometimes it happens that a specific package always downloads at 100k. ungoogled/cromium/wayland is such an example. I have no idea why this is the case though.
<mekeor[m]>my wild guess is that it depends where the substitutes are downloaded from. there are two official locations. bordeaux and
<nckx>I (very quickly and no doubt sloppily) set up a caching mirror for berlin: — I wonder how that would fare in the above cases, being also hosted in Germany. Also not sure what I would do with any reported data ☺
<nckx>Anyway this will soon be handled better with real, properly mirrored goodness.
<gnoo>how do i know which module provides a package?
<nckx>‘guix show’'s location field.
<gnoo>oh, thanks
<gnoo>what can i use instead of logind in guix?
<gnoo>i'm getting some very weird behaviour with it. can't login to 2nd, 3rd and 5th generations.
<gnoo>(out of 5)
<tex_milan1>Hi Guix, let's say I have a (define %something ¨long long long text on multiple lines¨). Is it possible to put that long test to a file and include it in the scm into the %something?
<nckx>gnoo: Maybe this? Although it's reported as fixed, so maybe not, and then I can't help you:
<gnoo>nckx: that's the exact error :) i'll check if the rest is similar or not
<awb99>Is there a emacs package on guix that does keybindings config similar to spacemacs or doom or prelude ?
<podiki[m]>awb99: do they just use evil mode? or else look at what they use (I think either of those configs is just including/configuring other packages)
<awb99>evil mode is one thing, yes
<awb99>but they also bring modal menus similar to vim.
<podiki[m]>I haven't used those configs, but probably browsing some of their source or default settings/packages would help
<podiki[m]>I know some things from them (like spacemacs or doom themes) have been split off to use separately, so hopefully you can find the key binds
<ardon>Hi, I'm trying to authorize substitute servers manually on Debian as per the manual, but I get the error "mkstemp: Permission denied" with user-level privileges when invoking the command to do so.
<awb99>thaks podiki[m]
<podiki[m]>awb99: welcome, and of course any goodies you find that aren't packaged for guix, feel free to submit :)
<awb99>I will podiki[m]. But not yet. I still dont understand the guix packaging system well enough to be comfortable to do so yet. I am struggling to keeping my first public package channel running. Typically with new releases of the packages, I end up fucking up the package completely, and then perhaps after many many tries I am able to get the change going. Once I am more knowledgeable, I will do so.
<efraim>hello guix!
<nckx>ardon: You can't authorise substitute servers with user-level privileges. Hence why all examples in the manual are run as root. Can you not obtain root on this system?
<nckx>Hi efraim.
<podiki[m]>no worried awb99! some packaging is much easier than others; haven't tried emacs ones yet
<nckx>ardon: Basically, a substitute server is able to place arbitrary binaries in the shared store, so authorising new ones is a privileged operation.
<skn1>hi all!
<skn1>i'm trying to port guix to freebsd (here is a patch with local changes in /usr/ports:
<skn1>i got to this point (full log here:
<skn1>ice-9/eval.scm:293:34: In procedure dlsym: Error resolving "strverscmp": "Undefined symbol \"strverscmp\""
<skn1>how to fix such an error? if it is better to ask this question in email, then tell me which mailing list to send it to.
<ardon>nckx: I appreciate the help. The issue lies in that if I authorize the servers manually via root then the user-level commands won't fetch substitutes. I've made sure I authorized the public keys in the user's ~/.config/guix/current profile doing as you suggested.
<mekeor[m]>skn1: sounds like you need to point the compiler to the library which contains strverscmp
<mekeor[m]>skn1: guix-devel is the mailing-list to go for your question:
<skn1>mekeor[m] yes. i understand. this feature is implemented in glibc (not available on freebsd) and gnulib.
<skn1>but my knowledge is not enough to add this function to the guix (or to guile?).
<skn1>ok, i send my question to guix-devel. thank you!
<nckx>ardon: Did you also add the actual server URLs to the daemon's command line --substitute-urls= option? Keys alone don't imply or encode any preferred URL. They are purely key data.
<nckx>I don't understand what ‘authorising keys in ~/.config/guix/current’ means though. Keys are authorised if they appear in /etc/guix/acl; nowhere else.
*nckx briefly AFK.
<mekeor[m]>skn1: maybe install gnulib on your bsd?
<emsyr>Hi! I'm trying to config sddm for X11/enlightenment auto-login session but it turns to try to load wayland/enlightenment, even if I have declared the display-server to be X11. Here is my config.scm if someone can take a look to tell me what's wrong. Thanx.
*nckx nope, AFK for much longer.
<ardon>nckx: I was missing the URLs on the service definition, that solved it. Thank you for your help 🙂
<skn1>mekeor[m]: 1. of course i did. 2. as far as i understand, this is a static library, and you need to attach it using autotools. but i don't even know where exactly to add it: to guile/guix/somewhere else.
<skn1>i've tried both (guile and guix), but autotools in my hands just breaks everything. so i'm asking for help.
<mekeor[m]>skn1: i see
<Nazar>hi there again ) how i can get package path in gnu/store ?
<Nazar>jpoiret finnaly i have finished with xdebug package, now it with separate folder extensiond dir, thanks:)
<Nazar>just wrote the patch for the xdebug
<florhizome[m]>hey guix :)
<florhizome[m]>what does (compose list ...) do? and how would I use it to add multiple values?
<drakonis>florhizome[m]: ^
<jgart>drakonis, ((compose sqrt 1+ 1+) 16)
<sneek>jgart, you have 1 message!
<sneek>jgart, nckx says: <doas> I swear this zimoun fellow is not some poorly-disguised sock-puppet of mine.
<jgart>is the same as (sqrt (1+ (1+ 16)))
<jgart>oh florhizome[m]
<florhizome[m]>I don’t mean literal addition :D
<jgart>I'm just showing how it composes functions together
<florhizome[m]>in service definitions there is often (compose list var) where far is a config value
<jgart>so you can see what it does with functions
<jgart>then you can apply that idea to other functions like the ones in the Guix APIs
<the_tubular>Finally! I beat the first boss!
<the_tubular>Authenticating channel 'guix', commits 9edb3f6 to 3a60812 (13,232 new commits)...
<pinoaffe>florhizome[m]: ((compose list func) args) is *almost* equivalent to (list (func args))
<pinoaffe>in the case that func returns multiple values, however, they are each passed to list as a separate argument
<pinoaffe>thus, if func returns a single value, (compose list func) is a function that takes the same arguments as func, but returns a list containing the return value of func as its sole element
<jgart>sneek: later tell nckx: jgart is listening to Master of Puppets by Metallica while reading threads on guix-devel mailing list jk haha.
<jgart>sneek: botsnack
<pinoaffe>if func returns multiple values, (compose list func) is a function that takes the same arguments as func, but returns a list consisting of the values returned by func
<pinoaffe>thus, `(cut apply values <>)` is the (left and right) inverse of `list` with respect to composition
<jgart>pinoaffe, you could add that explanation to the guile docs with some examples if you have the time so it won't be lost
<jgart>or maybe we need a guile cookbook
<florhizome[m]>the idea is a guile for guix cookbook
<jgart>where we can go to town on explaining scheme for our mortal brains
<jgart>ah yeah
<florhizome[m]>yes pwease
<jgart>guile for guixers
<florhizome[m]>what does guix with guile
<pinoaffe>jgart: good idea, the guile docs for "compose" are somewhat lacking
<florhizome[m]>so when I want to pass multiple configuration record values instead of one what do i do.
<jgart>guixers = not PLT hermits but distro nerds in the post-functional programming era
<florhizome[m]>guile’s docs are maybe somewhat lacking ;P
<florhizome[m]>this was not my sentence though *ducks away*
<pinoaffe>florhizome[m]: I'd sadly strongly agree
<jgart>no shame in saying that. We should work on them
<jgart>There are two bottlenecks in the system: I suck at Guile *and* Guile docs suck. So, we need to fix the bottlenecks. Fixing the latter might improve the former.
<the_tubular>Talking about sucking with guile : How can I make a list of packages like base-pacakge and reference this list in my config.scm ?
<florhizome[m]>I just consumed a bunch of stuff what systemd does (good) btw
<florhizome[m]>as the first distro able to run three Unix kernels (soon*), but not systemd, that might be interesting somewhat.
*jgart shrugs
<jgart>the_tubular, jk
<jgart>the_tubular, just create a variable that points to a list
<the_tubular>I think I suck more than you do with Guile :P
<jgart>and add it to your system block
<singpolyma>jgart: unfortunately with docs only people who don't know can help fix. I had never worked with lisp or scheme before I read the guile manual and found it very good, but I expect it's because I have worked in similar places so guile doesn't hold anything new except parens
<florhizome[m]>if you are fancy you put a % in front of it
<jgart>the_tubular, do you need/want an example?
<the_tubular>Sure, that would help me!
<jgart>I think the percent thing is like guilers take on lisp earmuffs
<the_tubular>I have a list done already, but I'm unsure how to reference it
<jgart>I might be wrong so don't quote me
<jgart>the_tubular, one sec
<florhizome[m]>jgart it’s a convention, not a definitive thing
<the_tubular>I'll respect the convention :)
<jgart>I was just pointing out a similarity with earmuffs
<florhizome[m]>so how do I add multiple record values via (compose list ...)
<florhizome[m]>idk what earmuffs are :D
<jgart>the_tubular, one way is to use guix-easy's `define-tools` macro:
*jgart shitty library self promotion
<jgart>but let me show a vanilla way
<jgart>one sec
<jgart>define-tools is used like this:
<jgart>you can call it %elisp-tools if you want to be a Guiler
<florhizome[m]>guile sits in multiple places that are pretty selfreferential not to say isolated/easily biased
<florhizome[m]>* lisp
<florhizome[m]>* functional
<florhizome[m]>* GNU project
<jgart>that macro should maybe be called something else
<jgart>florhizome[m], this is an earmuff: *hello*
<florhizome[m]>the negatives of which we shall seek to overcome
<florhizome[m]>what does it in lisp?
<jgart>earmuffs out in the world:
<jgart>the_tubular, here's an example of what I was referring to above:
<jgart>from jsoo1's configs
<the_tubular>Nice, and how do I refer to those in my config.scm ?
<the_tubular>That kind on looks like what I did
<jgart>those lists could easily be added here:
<jgart>in the packages field of the operating system record
<the_tubular>Got it, let me try that
<the_tubular>Thanks :)
<jgart>no prob
<florhizome[m]><florhizome[m]> "so how do I add multiple..." <- *cough*
<jgart>the_tubular, getting comfortable with records is an important milestone to hacking Guix
<the_tubular>Yeah, well it took me like 5-6 day of work just to install guix ... I'm not at the point of hacking it too much yet ...
<jgart>and getting comfortable with scheme lists also, of course
<jgart>the_tubular, look up records in scheme
<the_tubular>Will do
<jgart>see how schemers write code with records
<karrq>hi, I just made a manifest for an environment (to use with guix shell -m manifest.scm) and I just noticed that the version of a certain python package is outdated... I'm new to guix so not sure how I am supposed to proceed...
<karrq>for refernece, the python package version in the guix channel is 0.1.16 from October 2017, latest is 0.1.41 from November 2021
<jgart>the_tubular, Guile/guix's main record syntax is slightly different from that link I shared but the concepts are the same. And that chez book explains better than the guile docs
<karrq>I think I can use `guix import pypi package` but I'm not sure where that should end up
<jgart>guile also supports that chez syntax (R5RS?) for records
<florhizome[m]>karrq : if there is a new release that fits in the way the package is declared, you might just be able to use a package transformation
<florhizome[m]>See guix install —help-transform
<florhizome[m]>otherwise you can get the package recipe with guix edit
<florhizome[m]>Or in emacs guix-list-installed
<jgart>The difference is that guile records make you declare the functions that the macro will generate. The record datastructure is usually implemented as macros in scheme.
<karrq>florihizome: yeah that last one not sure it'll work :P guix on foreign distro :) I'll try the transform... I'm not sure how I can do that in my manifest.scm tho... probably just run that inside the environment and it will update the corresponding profile, right? (I save my profiles for fast load)
<jgart>the_tubular, A macro generates code for you so you can write a terser syntax for something more verbose looking. Atleast, that's how I mostly use macros currently.
<the_tubular>I'll pretend I understood about half of that sentence lol
<the_tubular>terser syntax ..?
<jgart>terser = simpler
<the_tubular>Got it
<jgart>more sugary sweet
<akirakyle>Anyone know why running guix pull ends up building a bunch of ruby packages??
<jgart>the_tubular, If you want to see what I mean copy this macro into a guix repl:
<lilyp>Okay, so this is probably a minor concern, but why is a week old?
<jgart>Or run the following: (load "utils.scm")
<karrq>florihizome: I tried --with-latest=package_name but guix reported to do nothing... I don't think `guix edit` is what I want either... do I really need to setup my own channel?
<jgart>the_tubular, and then run the following:
<jgart>the_tubular, that will show you the code that is generated by the macro define-tools
<the_tubular>Nice I'll try it out later, I'm building a kernel for ZFS
<jgart>the_tubular, you could write the generated code by hand instead of the macro but the macro is sugary sweet
<jgart>the_tubular, It's important to understand how to code what the macro is generating. That's the vanilla guile code a guiler would normally code without the macro.
<karrq>florihizome: hmm I see now I could using `guix refresh package -u` and it will update my definition :) but I get errors ... : consider removing propagated input xyz... I guess i could run --recursive but it's gonna take a very long time
<jgart>singpolyma, if you're coming from haskell then most guile concepts should be easy to understand, yes
<karrq>and right after "permission denied mkstemp"
<karrq>hmm maybe that's what's making it fail actually
<florhizome[m]>karrq: I get that too, when running guix style. can’t help there.
<florhizome[m]>you can try modifying the package definition by hand locally if running that seems to long ;)
<karrq>hmm `openat(AT_FDCWD, "/gnu/store/fvl1zrc80d8g5d2dnh9ava7y3dplzxhk-nonguix/share/guile/site/3.0/nongnu/packages/wine.scm.gKxQ58", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)`
<karrq>(with guix style)
<karrq>well that's a different channel anyways
<karrq>just wanted to try guix style
<karrq>I get a similar error with guix refresh ... just more output
<singpolyma>jgart: ruby is more similar to guile than Haskell, but I have both as well as JavaScript and C and what have you. So it's hard for me to be objective about how the manual reads to someone without those
<florhizome[m]>That might be worth a bug report sometime
<karrq>hmm yeah definitely. I feel like it might be an issue since it's trying to open a file in the store to write, which is normally not possible
<karrq>(for example, running sudo guix style worked flawlessly)
<karrq>and I guess it makes sense, it's editing the "system" not the user styff
<vagrantc>sudo shouldn't even be able to write to the store
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, nckx says: Especially for identical changes across many packages, I would have recommended a single commit had I been awake 😉
<florhizome[m]>Well when I tried to find functions of use in guile’s posix interface I was simply blown apart
<florhizome[m]>same about guix manual just introducing monads like that
<karrq>vagrantc: yeah also bad idea for me to do sudo guix refresh... it wrote files and now I can't open some stuff when i guix pull as user
*vagrantc finds using root on guix pretty much comes down to two commands: guix system (reconfigure|init)
<vagrantc>surely someone will come up with another example... but in general sudo/root access should be used very intentionally
<karrq>example of "bad permissions" of a file that's erroring out when reading: `rw------- 21k root 30 Dec 21:54 xiph.scm`
<karrq>normal file; `.r--r--r-- 104k root 1 Jan 1970 xml.scm`
<karrq>group is both root
<karrq>so 1) access time, 2) only root
<vagrantc>the store should be mounted read-only ...
<vagrantc>so there might be deeper issues
<karrq>definitely worth investigating why guix refresh -u doesn't work when invoked as user
<karrq>(in foreign distro)
<florhizome[m]><florhizome[m]> "so how do I add multiple..." <- It’s about (define service-extension dbus-root-service-type (compose list new-service-package) but I want two packages in there
<florhizome[m]>* > <> so how do I add multiple record values via (compose list ...)
<florhizome[m]>It’s about (define service-extension dbus-root-service-type (compose list new-service-package)) but I want two packages in there
<florhizome[m]>vagrantc: it happens for me with guix style, too
<florhizome[m]>on guix system
<karrq>maybe a "guix fix" command would be useful aswell when user error screws up witht the store
<vagrantc>there is guix gc --fsck or something ...
<vagrantc>not sure if that fixes such issues
<vagrantc>on foreign distro maybe the store isn't mounted with all the safeguards...
<karrq>well I did a `sudo chown -R a+r /gnu/store` and a-w aswell and guix pull works again
<karrq>anyways, guix refresh & co still didn't seem to fix my issue, where this python package is out of date
<vagrantc>~50 trivial guix lint description & synopsis issues fixed, only ... ~650 to go
<vagrantc>if only ... 13 more people could do about the same, we'd have a cleaner release :)
<nckx>karrq: sudo guix gc --verify=contents,repair
<sneek>Welcome back nckx, you have 1 message!
<sneek>nckx, jgart says: jgart is listening to Master of Puppets by Metallica while reading threads on guix-devel mailing list jk haha.
<nckx>jgart: It's actually all just me. Every single mail.
<karrq>nckx: awesome! can you also help me do what I'm trying to do? namely, I need an upgraded version of a python package and refresh -u doesn't seem to work, ie the package stays unchanged in the file and also guix search doesn't put the new version :(
<ss2>Now I understand why the binaries are all called -real when they are running.
<florhizome[m]><vagrantc> "if only ... 13 more people could..." <- isn’t this what you have a CI for nowadays (;
<karrq>where should I report an outdated package? this is taking way longer than it should
<Noisytoot>karrq, Update it yourself
<karrq>`guix refresh -u` doesn't work properly so I need to do a bunch of package definitions by hand... I'm trying to do so but each time there's a another unsatisfied dependency
<karrq>Noisytoot: yay great if only it was doable
<Noisytoot>If it doesn't work report the bug
<karrq>literally being doing it locally for an hour after refresh didn't work
<podiki[m]>what package/ecosystem?
<podiki[m]>could be something that has a lot that needs to be updated together (like haskell stackage versions)
<karrq>well in this case it was python, but the problem is that when I run guix refresh python-ledgerblue -u it fails with permission error... and florhizome reported permission error also on guix style
<podiki[m]>are you running this from a local git checkout?
<podiki[m]>otherwise I think it will try to write to the store of the current guix version
<karrq>yeah, I think that's the point?
<podiki[m]>sneek: later tell karrq are you using ./pre-inst-env within a guix shell? (all from the manual, but just checking)
<sneek>Got it.
<podiki[m]>sneek: later tell karrq for reference, I update packages/build local guix on a foreign distro sometimes, without any extra steps compared to a guix system
<sneek>Got it.
<podiki[m]>sneek: botsnack
<opalvaults[m]>Does anyone else experience man pages that still have their groff/troff(I assume) formatting tags inside of them? Do I need to install an extra package for that?
<opalvaults[m]>or is it literally just groff/troff that I need to install? lol
<ss2>I noticed that too, but only on packages I’ve been modifying myself.
<ss2>As in things seem off in the pages? Especially headers?
<opalvaults[m]>ss2: I'm testing out if its just mandb missing groff/triff
<ss2>I kind of ignored it so far..
<opalvaults[m]>ss2: if you do 'man elogind'
<opalvaults[m]>is that formatted correctly for you?
<opalvaults[m]>or does it have the formatting directives
<ss2>nope, the formatting directives are obvious..
<opalvaults[m]>gnome-keyring-daemon also has this issue
<opalvaults[m]>so weird
<ss2>but not all manpages btw.
<ss2>say, bash is fine.
<opalvaults[m]>yeah same here
<ss2>but I thought too that it might have to do with user profiles.
***caleb_ is now known as Kolev
<opalvaults[m]>note don't install mandb, and then uninstall it as it removes your ability to use it completely lmao
<opalvaults[m]>even though it comes with the installation as a binary I can use?