IRC channel logs

2019-12-05.log

back to list of logs

<snape>emacs-org-contrib for example
<bandali>out of curiosity, how are they broken?
<bandali>i'm planning to switch back to using guix for my emacs packages
<snape>oh, emacs-org-contrib was fixed by Pierre
<bandali>and was wondering
<bandali>ah
<snape>it's usually just a matter of remplacing site-lisp/guix.d/package-version with site-lisp
<snape>so pretty simple
<bandali>will the broken ones be broken only if emacs is not installed in my default profile?
<bandali>snape, ah, one does that per-package?
<snape>no, only for some package that are exceptions
<snape>*packages
<bandali>ah okay
<bandali>i guess i'll keep an eye on the git logs for the next couple days :)
<leoprikler>By the way regarding org mode
<snape>I have no idea about what happens if Emacs isn't installed in your default profile
<snape>mine in installed with 'guix package -i' and it work now perfectly well
<leoprikler>Our search path specification has site-lisp after lisp, which seems to cause version conflicts if someone wants to use the version that doesn't ship with Emacs.
<bandali>nice
<bandali>hmm
<leoprikler>If you're using Emacs in another profile, you should only have to source it's etc/profile for things to work.
<leoprikler>Note that you need to install Emacs in that profile though to have EMACSLOADPATH set.
<snape>(yes, EMACSLOADPATH must be set in every case)
<bandali>right
<lfam>Has anyone else tried updating to OpenSSH 8.1 in Guix? Some annoying changes in the test suite...
<Digit>watching ohio conf talk, practical software freedom with guix. 'tis enticing to get back onto guix. especially the conf elaboration in the questions after. more configs, and elaborations on them, yes please. :) *dreaming of a whole repository of user's configs and accompanying videos of the users elaborating on the contents and thinking behind them*
***daviid is now known as Guest28721
***Guest28721 is now known as daviid
<jlicht>hey guix
<nckx>Good mornin' Guix.
<zig>o/
<g_bor[m]>hello guix!
<g_bor[m]>I have additional information on the nginx tls issue.
<g_bor[m]>I could find out that the client_header_timeout timer is scheduled on the newer versions.
<efraim>i packaged the new opendyslexic font and I didn't realize we already had the old version
***nckx- is now known as nckx
<nckx>g_bor[m]: Do you mean it was bugnored in previous nginx versions?
<nckx> g_bor[m]: Where I got y'day: running ‘guix weather’ against my substitute server reliably fails. Guix dies when nginx sends a 408 when client_header_timeout is reached. The strange thing (well, that I didn't quite understand) is that setting a ‘client_header_timeout 600s’ didn't help. nginx respects it, but guix weather still stalls. nginx waits 10 minutes & sends the 408, killing Guix
<nckx>This not the ‘TLS issue’, but it's some coincidence that we both ended up at the same place…
<roptat>Hi guix!
<roptat>I gave my talk at jres yesterday afternoon, and it went quite well :)
<Franciman>great roptat !
<roptat>So hopefully we'll see more users soon ^^
<nckx>roptat: Congrats!
<nckx>roptat: Any interesting &/or unexpected questions?
<roptat>Yes, "can I use multiple kernels with guix?"
<roptat>Whicg I didn't understand at first, but was more like "can I have the latest guix with a custom, old, kernel"
<Parra>hey guys I'm seeing that ruby package on Guix only has libruby-static.a and not a .so version, is this correct? should I repackage it if I want to use the .so version?
<roptat>Also, for researchers it'd be great to not have a git commit and a list of packages, but a sort of unique id that would identify them and maybe help identifying and citing tools used in papers
<roptat>I'm not sure how it could be done, but we have the basic tools
<nckx>roptat: Hm.
<roptat>I also met with Marc who organised the Guix days in Strasbourg and managed to convince him to write a "scheme on vim" tutorial :)
<nckx>I don't see how that could be done but perhaps I lack the imagination.
<nckx>I mean, sure, hash, but what does that give you?
<roptat>The hash (guix describe) gives you the ability to reproduce the results of a paper if you used guix
<roptat>I'm not convinced you need more than that, but that person would have liked some sort of identifier for the distro + the manifest, sort of like a doi
<leoprikler>I think you could cook up something like that if you were to host a pair of (channels.scm . manifest.scm) at some well-known location.
<leoprikler>Or you integrate the channels specification into the manifest itself.
<nckx>I meant ‘what does that give you besides the ability to verify… a commit + manifest shipped together with that ID’. Which in my mind doesn't make sense.
<roptat>Hasn't there been some work on that recently?
<roptat>Better UI?
<nckx>I guess.
<nckx>I read it as ‘central upload-yer-manifest guixhub that hands out pointers’, maybe that's not what's meant.
<nckx>But if ‘ID’ can mean a file: sure.
<nckx>leoprikler: That reminds me too much of the bit.ly links in a print book I just bought.
<leoprikler>Well, it should be more permanent than bit.ly, but the idea itself stays pretty much the same.
<leoprikler>Of course, you could print the manifest itself onto paper, but who would want that?
<nckx>Content-addressed at the least.
<nckx>$ guix share cool-manifest.scm […]
<nckx>→ gnunet://utha/teouh…, ifps://bkaeodraruce…
<Parra>how can I find if libruby.so is available in some package?
<jlicht>Parra: there is no 'index' of which packages contain which files
<jlicht>that is, not without building those packages first, in which case you might try your luck with `locate libruby.so'
<Parra>I just want to link dynamically against that lib but ruby package does not contain the dynamic version of libruby, only the static one
<Parra>maybe I have to recompile ruby, inheriting the package and modifying some compile flags
<Parra>is my assumption correct?
<jlicht>Parra: No clue, not a ruby guy :-)
<roptat>I can't check, but does ruby have more than one output maybe?
<jlicht>it only has `out'
<roptat>Ok
<Parra>I'm just installing ruby and navigating through the folders to see what it has inside
<Parra>and I couldn't find libruby.so
<nckx>Parra: Your solution is correct, although it missing a .so is unusual and possibly unintentional.
<roptat>Still in France, Marc suggested that we go to http://devlog.cnrs.fr/jdev2020
<Parra>ruby interpeter executable is built against the static lib version, but embedders need the .so version for using ruby interpeter as a plugin, instead of a standalone executable
<Parra>so maybe that's because the so isn't present, it may be built without thinking about the embedders, only thinking about the executable ruby
<nckx>Parra: Is that the recommended way to build the interpreter?
<Parra>at least it's how it is built in guux
<Parra>let me check outside guix
<Parra>in my debian I have it built with dynamic lib
<Parra>I think the common way is with the .so
<nckx>That would be the Guixy way, too, unless upstream recommends it or the static version is more performant or something.
<nckx>recommends otherwise, I mean. Anyway, would you be willing to file a bug?
<Parra>I'm not sure if it is a bug
<Parra>but I think it's recommendable
<Parra>how can I write a suggestion?
<zimoun>roptat: nice! But not too old kernel. :-)
<nckx>It's not a serious bug, but I think it's a ‘bug’ of sorts in that it's unusual and there's no clear reason for it, and that (as you noted) the .so is needed for other projects anyway and Ruby {c,sh}ould just use it.
<Parra>ok, so how can I submit it?
<nckx>Parra: bug-guix@ is fine.
<Parra>here's the deal: https://github.com/metacall/distributable/blob/65493b393388f5d66d9b466e5d49f9128fee27ea/source/metacall.scm#L115
<kirisime>Is there no package for CSFML?
<zimoun>roptat: about kind of DOI to list packages and so on, I also feel we lack something. I have tried to describe such feature here https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html Please add comment; especially this very question.
<Parra>I can't build with support to ruby if it's static
<Parra>I also don't know how to extract the ruby version but that's another history
*nckx calls that a bug. 🙂
<Parra>nckx: what is bug-guix@ exaclty? the mailing list?
<nckx>Oh, sorry, yes. bug-guix at gnu.org is a mailing list/bug tracker.
<Parra>thanks, there is any recommendations or structure I must follow for submitting a bug?
<nckx>Just send 1 message with bug subject and bug description in the body to that address, and you'll get a bug number back.
<nckx>Don't worry if it takes a while. It can take a while to get through moderation if this is your first time.
<nckx>Your bug will show up at issues.guix.gnu.org.
<roptat>Wow italic emoji is weird ^^"
<nckx>I didn't know they existed.
<roptat>Me neither
<roptat> https://files.catbox.moe/ejjma2.png
<jlicht>kirisime: I might have an old version of csfml packaged
<nckx>Ooh, ma links look all fancy-like.
<kirisime>jlicht: Can you send the package definition over if you find it? Thanks.
<Parra>nckx: okay I'm gonna send it, thanks
***sneek_ is now known as sneek
<jlicht>kirisime: https://paste.debian.net/1119616/
<jlicht>not actually sure if it works/does what it should do
<nckx>Parra: Thank you.
<roptat>zimoun: my ISP cut the link yesterday, so I can't access my home mail server anymore, which means I can't answer properly
<roptat>Can you answer by citing the relevant parts of what I said here?
<zimoun>roptat: yes I can. ;-) Maybe, instead could you send a short summary of the questions to guix-devel when you will be back?
<kirisime>jlicht: It's a start though. Thanks again.
<Parra>nckx: done
<roptat>Sure, I can do that now. I just can't answer to something precisely
<kirisime>Having to remember to add --no-build-hook to every call to guix when my local offloading machine is off is a bit of a pain...
<g_bor>kirisime: you can temporarily reconfigure your daemon with no-build-hook
<nckx>kirisime: I have a guix-toggle-offloading script that renames /etc/guix/machines.scm{,_DISABLED}, if that makes you feel better about your own life 😉
<g_bor>nckx: nice trick
<nckx>wc -l .local/bin/guix-toggle-offloading | 28
<nckx>It *might* draw an ascii-art server & laptop, you can't prove it.
<nckx>Oh, it's actually a little ascii cloud. God I'm unbearable.
<nckx>g_bor: Did you happen to see my messages about Nginx before the great netsplit?
<g_bor>I believe I got some.
<nckx>I don't know what the exact problem is but it's probably a sign you're on the right track.
<g_bor>So far I managed to find the exact commit introducing the problem.
<david-l[m]>guix pull just failed for me for commit ac1ee30, log says something like "(value "no variable bound to ~s in module ~s") (value (sbcl-iolib+multiplex (gnu packages lisp))) (value #f))
<nckx>g_bor: Could you share that? I'd like to revert it here.
<david-l[m]>so seems related to that commit
<g_bor>Also that two branch that schedules the timer has the same condition.
<g_bor>nckx: it's nginx hg revision 7584:9d2ad2fb4423
<g_bor>This modifies how the available bytes are calculated for a socket.
<g_bor>I believe what actually happens, is that nginx believes that there is nothing more to read from the connection, but there are actually bytes available.
<g_bor>nckx: also, when building nginx from a mercurial checkout you have to symlink auto/configure to configure.
<nckx>g_bor: Thanks.
<rekado_>hello Guix!
<g_bor>hello!
<g_bor>nckx: https://paste.debian.net/1119620/
<rekado_>does anyone know what’s holding back the long overdue Gnome upgrade?
<g_bor>this is the first bad version.
<kirisime>jlicht: I updated the package to 2.5 and while the program I'm trying to run still encounters an error it does manage to create a window. Thanks a bunch!
<david-l[m]>I am able to guix pull using commit 208e743 from 20hours ago, but not several other commit after the staging merge from 19hours ago.
<jlicht>kirisime: yw! I hope it works out for you!
<jlicht>I think I was trying to get https://github.com/FluffyStuff/OpenRiichi working, but never managed to get it working :/
<kirisime>david-l[m]: I had this happen when the qt package was depreciated and a second channel I was using hadn't updated yet.
<PotentialUser-67>Hey people! I'm tinkering with Guix on Arch, and upon doint `guix pull` today I get this:
<PotentialUser-67> https://pastebin.com/WYqy93Cs
<PotentialUser-67>(repl-version 0 0)
<PotentialUser-67>Generating package cache for '/gnu/store/2d87c8l73wa2cnajbh4qq1721mr9lav7-profile'...
<PotentialUser-67>(exception misc-error (value "private-lookup") (value "No variable bound to ~s in module ~s") (value (sbcl-iolib+multiplex (gnu packages lisp))) (value #f))
<PotentialUser-67>The error in the log is (exception misc-error (value "private-lookup") (value "No variable bound to ~s in module ~s") (value (sbcl-iolib+multiplex (gnu packages lisp))) (value #f))
<PotentialUser-67>This is the error in the log
<david-l[m]>PotentialUser-67 and if you run "less '/var/log/guix/drvs/kr/7099ckaisng27dbpxb6jx55jdlk874-guix-package-cache.drv.bz2'" will you have something like sbcl-iolib+multiplex in it?
<david-l[m]>right
<david-l[m]>same here
<PotentialUser-67>Glad it's not just me :)
<david-l[m]>me too :)
<david-l[m]>if you want to update to something recent, try guix pull --commit=208e743 its from 20hours ago and works.
<david-l[m]> * PotentialUser-67: if you want to update to something recent, try guix pull --commit=208e743 its from 20hours ago and works.
<PotentialUser-67>@david-l[m] Thanks, that worked!
<david-l[m]><PotentialUser-67 "@david-l[m] Thanks, that worked!"> you're welcome
<roptat>Could you report a bug to bug-guix at gnu.org?
<nckx>roptat: I'm composing a mail to Pierre.
<roptat>Ah, thanks
<nckx>Just waiting for the error output.
<david-l[m]>thanks
<davie`>david-l[m]: Hey but what if I have other local chanels?
<nckx>Would it be considered rude if I reverted this change (again…)?
<roptat>Well if it breaks, I think it's understandable
<efraim>is it failing from guix pull or from just make?
<roptat>From guix pull
<david-l[m]>When I tested it, I had a fail with and without local channels for the most recent commits. It worked for commit 208e743 after I moved the ~/.config/guix/channels.scm as to not use any other channels. It is failing directly from guix pull for me.
<efraim>i read the backlog, i see. looks like no additional channels
<david-l[m]>davie` you can specify a 'guix channel in the ~/.config/guix/channels.scm file with a specific commit, just return a list with all channels and it should work.
<davie`>david-l[m]: niice :)
<nckx>Try pulling again.
<nckx>It's *still* running here 😒
<PotentialUser-67>I'm pulling again...
*nckx twiddles thumbs.
<nckx>…is this normal in pull land?
<PotentialUser-67>It's still going, but it passed that place!
<PotentialUser-67>Well, as far as I can tell
<nckx>PotentialUser-67: Thanks. Here it finally spit out the error. Now I'm trying for success. I always repress^Wforget just how slow ‘guix pull’ actually is.
<nckx>git lyfe 4 lyfe.
<PotentialUser-67>Worked, yay!
<nckx>guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error in the pull function
<nckx>Oh Guix
<nckx>u trollin'.
<rekado_>nckx: it’s only slow when the build farm hasn’t built that version of Guix yet.
<rekado_>“guix pull” consists of a bunch of different derivations, most of which we build on every push to the repository.
<bandali>hi y’all, i’m *still* confused about when exactly i need to pull and reconfigure as root, and otherwise when doing that as my regular user is enough
<bandali>also, i think the bit about sudo and guix on this page is not correct: https://guix.gnu.org/manual/en/html_node/After-System-Installation.html#After-System-Installation
<nckx>bandali: You shouldn't need to pull as root.
<bandali>that page says `sudo guix' will use my env vars, but that doesn't seem to be the case, unless i explicitly provide the -E option to sudo
<nckx>guix system reconfigure runs as root (for 1 tiny step at the end: installing GRUB) but should normally be run with sudo -E so ‘your’ Guix is used.
<bandali>nckx, hmm, perhaps, but fwiw, on a new guis system installation last night, i had to `sudo su' and then `guix pull' and `guix system reconfigure /etc/config.scm' to be able to get past a locales related error when pulling nss-certs
<nckx>bandali: So sudo sh -c 'echo $HOME' returns /root on your system?
<bandali>one sec, let me boot up my guix system machine
<nckx>Right, work-arounds excepted; there are limitless combinations of things you can do if the main road is broken. But we should have 1 clear message: guix pull && sudo [-E, if it turns out to be needed] guix system reconfigure
<nckx>All the rest is ‘I know what I'm doing & why’.
<nckx>bandali: Thanks. Interested.
<bandali>nckx, yes, that returns /root on my new guix system installation out of the box
<nckx>bandali: I forgot I have access to a ‘stock’ Guix System now, sorry. You're right: sudo sh -c 'echo $HOME' → /root
<bandali>so either sudo's configs need updating or the manual
<bandali>and no worries :)
<nckx>All this gets discussed & changed so often and I don't understand. Everyone seems confused.
<nckx>(Which is the reason I modified my system to -E by default in the first place.)
<bandali>-_- it's i think *the* most confusing thing for guix news
<bandali>*newbs
<nckx>It's certainly up there.
<bandali>so how can i make -E the default behaviour on my system?
<bandali>and can this please be made default to match what the manual says?
<nckx>Yeah, I'd rather see this fixed once & for all (hah) in Guix, not worked around by us. bandali: I use my own sudoers file, it has !env_reset amongst all my other faves.
<nckx>Which gives you -E.
<bandali>agreed about having this fixed
<bandali>btw, are your dotfiles available anywhere?
<nckx>Nah, & no interest, sorry.
<bandali>np
<nckx>bandali: Actually looking at commit 796a4491fdaa4a0a3d669457b89356f9fbfc966e, it could have just been a typo.
<nckx>Ah, no, it then explicitly digs the hole deeper.
<nckx>It points to this: https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html
<nckx>bandali: -E should not be needed becaule $PATH includes ‘your’ current/ guix so why is that not working for you?
<bandali>nckx, i'm not sure i'll check; but for one thing, this would be annoying because `sudo guix' would use my guix, without the rest of my environment (e.g. my GUIX_LOCPATH)
<bandali>i think that's worse than the two cases of either it using all of root's stuff, or all of my stuff
<bandali>idk if we want to think about consistency with foreign distros or not
<bandali>e.g. on debian buster, sudo su -c 'echo $HOME' gives /root as well, like guix system
<nckx>bandali: While I personally agree (as was probably obvious 😛) I can see the PoV of others in that thread, too. Good that it's linked, even if just as a source comment. But I wish things were more straightforward.
<bandali>nckx, right, i'm reading that thread now. i think it should be linked from the manual page too
<alextee[m]> https://i.imgur.com/SPvOmvo.png :D
<nckx>Right, I don't *have* other-distro expectations because I've been lugging this sudoers file through all of them.
<nckx>So I shouldn't be allowed to have an opinion.
<nckx>Oh god my eyes why.
<alextee[m]>sorry :D
<bandali>yes, a word of warning would've been nice
<alextee[m]>it exists lmao https://www.amazon.com/Savaged-Systemd-Erotic-Unix-Encounter-ebook/dp/B075DYXZW1
<nckx>Worst thing is it's not the first time I've seen that book.
<nckx>Isn't it by Michael W Lucas, the rather well-respected FreeBSD book fellow?
<nckx>I will never know because I am not clicking that link and closing my client. Byesies.
<alextee[m]>lol looks like he has many similar books
<civodul>hey! ho!
<bandali>hey civodul
<civodul>howdy!
<civodul>how's the Savannah situation going?
<jlicht>o/
<mbakke>pango 1.44 breaks our unmaintained librsvg
*mbakke clears a first round of 'core-updates' patches
<bandali>civodul, the attacks seem to have subsided for the most part
<mbakke>poppler 0.83 also breaks texlive, again
<bandali>and i heard from one of the fsf sysadmins that recovery of disks (after the recent disk failures incident) seem to have gone well
<mbakke>if anyone has WIP patches for TeX Live 2019 I'd love to hear about it :P
<bandali>i think savannah should be back in good shape again now
<bandali>civodul, can we please get a section in the manual about when guix subcommands like pull, system reconfigure, and perhaps upgrade should and shouldn't be run as the root user?
<civodul>bandali: re Savannah, good to hear it's getting better
<civodul>bandali: re running the command, i think it's worth discussing on guix-devel, i would hope we're not doing that bad, but maybe we do? :-)
<bandali>:)
<civodul>i know we've have a couple of rounds of clarifications of the manual re "sudo guix system reconfigure" etc.
<bandali>civodul, i find myself constantly confused by it :(
<bandali>(see logs from earlier today)
<bandali>nckx also pointed me to https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html
<bandali>having an up-to-date and correct summary of things somewhere would be wonderful
<bandali>e.g last night i wasn't able to get reconfigure to work with `sudo -E' for the life of me last night, because of some locale-related error about nss-certs (i think there was a discussion about it last month on one of the lists)
<bandali>the only way i managed to get past that was pulling and reconfiguring using the root user
*civodul sympathizes
<civodul>bandali: i'd encourage you to share your experience on bug-guix or guix-devel, and to point out things that you find confusing in the manual
<bandali>thanks ludo :) will certainly do
<civodul>i think everyone's all for making it clearer :-), but just need to have a good understanding of what's confusing
<bandali>right
<bandali>btw which one would you prefer? the bug list, or devel?
<civodul>if you have a concrete suggestion/issue, i'd say bug-guix, otherwise guix-devel
<civodul>anyway, if that can help move Savannah and gnu.org to Guix System, we can surely find a solution ;-)
<bandali>hehe :D
<bandali>alright i think devel may be more suitable at least at this stage, to hear people's thoughts
<bandali>and then we could perhaps get actionable bug reports out of the discussion if needed
<mbakke>civodul: does 26dc630941ca70c74b4e6e2b1a01f0d046890c2 looks correct to you? :-)
<civodul>mbakke: you're playing tricks on me, that commit doesn't exist!
<civodul> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=26dc630941ca70c74b4e6e2b1a01f0d046890c2
<civodul>:-)
<civodul>mbakke: BTW, what happened to 'staging'?
<mbakke>civodul: whoops, lacked the first character: 326dc630941ca70c74b4e6e2b1a01f0d046890c2
<mbakke>civodul: staging is now in 'master' \o/
<mbakke>I'll send an update on core-updates and staging tomorrow, gtg now.
<efraim>IIRC python2-boost is the last python2 dependency for guix
<pinoaffe>how can I start a graphical program such as gparted with root privileges in the x11 session of an unprivileged user
***MinceR_ is now known as MinceR
<ScaredySquirrel>how do I specify the device file for the device in a file system block?
<ScaredySquirrel>(file-system (mount-point "/home") (device (whatistheprocedureforthefilespecificationhere "/dev/sda5" 'btrfs)) (type "btrfs"))
***sneek_ is now known as sneek
<pkill9>hello guix
<str1ngs>ScaredySquirrel: it depends what you are using for identification.
<bavier>nice blurb about Guix's bootstrapping work on https://reproducible-builds.org/reports/2019-10/
<bavier>though they're still using that outdated logo... :/
<Blukunfando>It could be worse—they could call it Guix Linux :þ
<bavier>I asked for an update on their irc channel
<ScaredySquirrel> http://dpaste.com/0V6GRKQ.txt
<ScaredySquirrel>please help me with that config.scm
<ScaredySquirrel>ok everytime just 10 lines of config.scm it break
<ScaredySquirrel>breaks
<bavier>ScaredySquirrel: what is the problem?
<ScaredySquirrel>it won't compile
<ScaredySquirrel>as I said everytime i change about 15 lines of my config.scm it breaks
<bavier>btw, reproducible-builds.org should have the updated Guix logo soon: https://deb.li/I3KV
<bavier>ScaredySquirrel: it seems to be the file-system device declarations
<bavier>I think you can remove the "target" bit and just use '(device "/dev/sda1")' e.g.
<nckx>ScaredySquirrel: Then stop changing things, it's obviously perfect.
<nckx> 19:15: error: target: unbound variable
<nckx>ScaredySquirrel: Please include the relevant error message when asking for help, ‘it won't compile’ is not very helpful.
<bavier>nckx: the message seems misleading to me; here it's an invalid/undefined record field being used.
<ScaredySquirrel>hey wow it works
<ScaredySquirrel>yep that was it
<ScaredySquirrel>the little target bit of 'btrfs 'ext4 for example was not working
<nckx>My point was that asking people to play ‘find the error, I won't give you spoilers’ in a 1.8k file will end poorly for both parties.
<nckx>Welll, mainly the one asking for help.