IRC channel logs

2021-03-29.log

back to list of logs

<lle-bout>tissevert: hello!!!
<lle-bout>tissevert: not really! create another, but we'll take care of that also
<lle-bout>tissevert: I think we will be handling that also but like some time later
<lle-bout>We will upgrade NetworkManager to latest (that will be helpful)
<lle-bout>tissevert: also look at https://notabug.org/civodul/guix-explorer - also the FOSDEM talk, really interesting to find out about Polkit issues!
<lle-bout>Or other issues, in GNU Guix System configs
<PotentialUser-60>hey all, is there a virtual machine like virtual box for guix I can get running quickly
<PotentialUser-60>I am using gnu guix and need a VM to use ubuntu.iso
<vagrantc>maybe virt-manager
<vagrantc>it's got some quirks, but basically works
<apteryx>raghavgururajan: I'm not at linphone-desktop in the review! :-)
<apteryx>it's supposed to crash, right?
***atw```` is now known as atw
<pkill9>yea virt-manager
<pkill9>you need to enable qemu service
<pkill9>and make sure to set group permission on qemu socket (manual says how under qemu-service-type section)
<lle-bout>marusich: omg! thanks so much for writing!
<marusich>well, we need to pare it down a bit
<marusich>i'm just kind of writing what i think of
<lle-bout>marusich: you say release binary but until 1.2.1 there will not be any
<lle-bout>marusich: all the info is awesome
<lle-bout>thanks so much!
<lle-bout>marusich: maybe also we should say that the bootstrap code is not tested and fixed continuously so latest master of this code can be broken
<lle-bout>marusich: just gave a full read, love it!
<lle-bout>marusich: I think it's just so helpful you went in so much detail
<lle-bout>for future ports, of any kind
<marusich>Maybe...I don't know!
<marusich>The most helpful takeaway is that you have to just get your hands dirty and try it and ask questions and get someone else to help you keep your motivation up, I think :P
<marusich>I will keep adding some stuff. I think after I have added more, I'll try to pare it down.
<lle-bout>marusich: of course but this feels also great to have it all there
<lle-bout>maybe no need to pare it down
<lle-bout>Maybe re-organize information but I think it's great to talk about bootstrapping in much detail
<marusich>We'll see how it turns out! I agree it's nice to have a bunch of links and a story to follow
<lle-bout>We could call the blog post
<lle-bout>"A GNU Guix powerpc64le-linux-gnu porting journey"
<lle-bout>or something
<marusich>I still want to add a part that talks about the "path of trust" from the binary you download to ... somewhere back in time
<marusich>I like it :)
***iyzsong-- is now known as iyzsong-w
<apteryx>raghavgururajan: managed to get linphone running!
<raghavgururajan>apteryx: Yay! I think we also need to symlink {belcard}/share/belr/grammars
<raghavgururajan>lle-bout: Thanks a lot for joining the meetup, you were very helpful.
<raghavgururajan>apteryx: Any thoughts about https://issues.guix.gnu.org/47274#4 ?
<raghavgururajan>I wonder why wrapping XDG_DATA_DIRS doesn't work, as it will give access to {all-inputs}/share/stuff
***iyzsong-- is now known as iyzsong-w
*raghavgururajan is not sure how to react to the snowing at the moment
<vagrantc>was linphone not working in guix?
<Rovanion>How long is guix import nix supposed to run for? I think mine has been running for like 20 minutes now.
<apteryx>it was, we were just discussing the 4.2.5 update patch series submitted by raghav
<apteryx>where it had a small problem finding the grammar resources from liblinphone
<apteryx>raghavgururajan: phew, all done
<lfam>Hey Rovanion
<lfam>I'm not sure about `guix import nix`
<apteryx>time to head off bed
*apteryx zzz
<lfam>Did you try to import a particular package?
<Rovanion>lfam: libmilter
<lfam>Can you share the command you used?
<Rovanion> https://paste.debian.net/1191457/
<lfam>Hm...
<lfam>I'm not sure about the current state of the Nix importer. It was not really useful for a while, but maybe it's been improved
<Rovanion>The warnings aren't exactly screaming "mint condition".
<lfam>Yeah
<lfam>I would read this message: https://mail.gnu.org/archive/html/guix-devel/2020-10/msg00357.html
<Rovanion>Guess I'm back to fighting sendmails build system then.
<lfam>It doesn't look like the code has been touched since then, so we might look into removing it
<lfam>It needs this libmilter package?
<Rovanion>The sendmail "project" authors libmilter, I need libmilter for one of my projects.
<lfam>Looking at the Nix packaging, it seems somewhat annoying to package, but nevertheless straightforward
<Rovanion>Is it possible to just straight steal the Nix patches?
<lfam>And hopefully the newer release available upstream would obviate the glibc compatibility patch
<Rovanion>At least the sharedlib.patch.
<lfam>Yeah, Nix is free software
<lfam>It's good to add a note to patches that explain where they are from. So in this case, a link to the file in their Git repo
<lfam>Ideally these patches would be integrated in the newer libmilter
<lfam>If not, it might help to send them upstream while packaging
<lfam>Btw, I'm the person that asked about MAILDIR in the sendmail patches
<lfam>The sendmail Makefile describes the variable like this: "directory for .cf files"
<Rovanion>Hi Leo! Yeah, seems like its used for config files.
<lfam>I came to the same conclusion by reading about it
<lfam>I think that /etc/mail is the right choice for Guix
<Rovanion>I'll go with that then.
<lfam>The store can't hold anything that needs to be created or edited after the package is done building
<Rovanion>Hmm, so it can't be `MAILDIR = $out/etc/mail` because that is inside the store? Or is that symlinked to /etc by the system profile?
<lfam>It can't be $out/etc/mail
<lfam>Just /etc/mail is what we usually do for this kind of thing
<lfam>If we had a sendmail service, we might generate config files and put them in the store. Then, when starting sendmail, we'd give it the path of the config file. We do this for openssh, for example
<lfam>It really depends on how sendmail works, but the store can't be used as a default location for config files that users will create
<Rovanion>Hmm, now the build process either fails because there is no folder `/etc/mail` or if I try to create it with `mkdir-p` that the build is not allowed to create it :/
<lfam>I see
<lfam>Well, as long as users can tell sendmail to look somewhere else, I suppose it's okay to leave it in. Sometimes we disable this kind of ill-advised mkdir-p, but it depends on the situation
<lfam>Really venerable programs like sendmail often have the least portable and most complicated build systems
<lfam>My original objection to using the store for this variable was because I thought it was talking about <https://en.wikipedia.org/wiki/Maildir>
<Rovanion>Which is reasonable :)
<lfam>If it is just a location for an example config file, then it's not a big deal and I'm sorry for wasting your time
<Rovanion>I honestly have no idea if it is possible to tell sendmail to look of these config files someplace else.
<lfam>Well... the package wasn't very useful before, right?
<Rovanion>Can't say it was.
<Rovanion>There has been a new release of sendmail. Can I batch the upgrade into the same patch or should I split it out?
<lfam>Then, whatever you choose will be an improvement :)
<raghavgururajan>lfam: Did you get my DM few days back?
<lfam>I would fix the package in one patch, and then update it
<lfam>raghavgururajan: My last IRC DM from you is a few months old. I know I need to spend some time catching up on your recent work :)
<raghavgururajan>lfam: Oops! It must have lost in the XMPP-IRC tunnel, I wanted to inform you that I got 3 vouchers and sent-in the application.
<lfam>Oh, great!
<lfam>I'm sorry I was too slow
<lfam>It's really cool to see progress on GNOME
<raghavgururajan>Hey no worries at all.
<raghavgururajan>:)
<Rovanion>Man, the sendmail source doesn't even support building a shared library of libmilter. Both Debian and Nix have patched that in.
<lfam>If anyone was curious, the Meltdown and Spectre mitigations have no impact on Guix compile times on a Thinkpad x200s (Core 2 Duo L9400)
<raghavgururajan>sneek, botsnack
<sneek>:)
<raghavgururajan>sneek, later tell apteryx: Looks like we need to fix one last thing for linphone-desktop. The missing /lib error (https://issues.guix.gnu.org/47274#4). Currently, the app starts, but doesn't work. :(
<sneek>Got it.
<mothacehe>hey guix!
<efraim>hello!
<pkill9>hi
<raghavgururajan>sneek, later tell apteryx: Here's the fix, https://envs.sh/jP.patch :)
<sneek>Okay.
<civodul>Hello Guix!
<nixo_>Hi ludo!
<civodul>hey nixo_
<civodul>nixo_: so the Zigote patch series is ready to go, right?
<nixo_>IMHO it is, except for lint complaining a bit it seems fine. applies build and work, licenses are right too.
<civodul>awesome, i'll push it later today
<nixo_>great, I'll prepare the Plots.jl patch series then. And simon is working on the importer :D
<civodul>yeah i saw that, good work, comrades!
<civodul>BTW, thoughts on the more quiet output for downloads? https://issues.guix.gnu.org/47295
<civodul>several people suggested it before
<pkill9>i like the one-line output for each substitute download
<pkill9>i support this change
<civodul>cool, thanks!
<nixo_>civodul: yeah I like less output tool. When lzip was added, I looked at the output enjoying to see lzip being used, but that's it. I'll raise the verbosity for a week when zstd will be available :D
<civodul>heh :-)
<civodul>it *is* available!
<nixo_>wow it really is
<nixo_>guix pull just downloaded 3 gzip, 2 zstd and 2 lzip
<pkill9>what's so good about zstd?
<nixo_>pkill9: unpacking should be faster, while maintaining an high compress ratio. There are details in the blog post https://guix.gnu.org/blog/2021/getting-bytes-to-disk-more-quickly/
<pkill9>cool
<raghavgururajan>sneek, later tell lle-bout: I am revising the chart to comply with upstream GNOME 40.
<sneek>Will do.
<nixo_>did you notice that since a few weeks we are in top10 on repology for number of packages? https://repology.org/
<civodul>oh
<civodul>but so is "Rosa"; what's Rosa?
<civodul>argh, just saw the banner on that web site :-(
<raghavgururajan>nixo_: Yay! Also, look at the unique packages number, https://repology.org/repository/gnuguix
<raghavgururajan>*lets look
<leoprikler>well, many of them seem to be our unique naming conventions
<nixo_>yeah repology is a bit bugged
<avalenn>The "outdated" number is interesting also.
<tissevert>hi
<tissevert>lle-bout: yeah, it seems like I have to try guix-explorer, it looks really promizing
<tissevert>civodul: I must be missing something very obvious : I just cloned guix-explorer, tried to run ./explorer /run/current-system/configuration.scm and I got a lot of warning about failed autoloads, then I'm told that the target itself is not found
<tissevert>I'm obviously on GUIX, GUILE_LOAD_PATH is obviously set and defined properly (to its default value)
<tissevert>my shell successfully autocompleted the end of «…figuration.scm», proving that it's not a typo, and the file does exist on my system
<jlicht>hey guix
<leoprikler>does anyone here use guile-ac-d-bus? I'm trying to establish a connection, but it seems the argument to connect is invalid
<Rovanion>I may have asked this before but is it possible to know exactly which command is run in a certain phase? Looking at the source of guix it should be `python setup.py test` but that command fails when I'm in the failed build directory with environment-variables sourced.
<raghavgururajan>True!
<leoprikler>Rovanion: that command failing might be the reason the build failed tho ;) what's the difference between the output of guix build and the one inside the build directory?
<Rovanion>The guix build runs a test suite of Python unittests. Inside the directory setup.py reports that there is no test command. https://paste.debian.net/119149/ https://paste.debian.net/1191494/
<leoprikler>mhh, perhaps test is included through the setuptools shim?
<leoprikler>try formatting it like "python" "-c" setuptools-shim "test"
<Rovanion>On the command line in the build dir it says that setuptools is not defined: https://paste.debian.net/1191496/ If I replace the check phase in the package definition I get that the symbol setuptools-shim is undefined. Running `python test.py` in the build dir does work and finishes successfully. Replacing the check phase with `(invoke "python" "test.py")` fails on the other hand due to what I guess
<Rovanion>is PYTHONPATH-stuff: https://paste.debian.net/1191499/
<leoprikler>Rovanion: you need to copypasta the shim from guile
<leoprikler>s/guile/Guix/
<raghavgururajan>sneek, later tell lle-bout: Brand new chart (https://calc.disroot.org/guix-gnome.html) \o/
<sneek>Will do.
<Rovanion>leoprikler: Yup, that did it. Now I have the same failing tests in both the guix build and build dir. What I really want now though is for `(invoke "python" "test.py")` to work just as well as `python test.py` does in the build dir...
<leoprikler>raghavgururajan: that chart seems broken
<raghavgururajan>leoprikler: You mean 504 Gateway Timeout? Disroot is doing something with their webserver. Should be back on soon.
<yoctocell>Hi, I am having trouble with getting the `git-predicate` from (guix git-download) to work, it fails with "Segmentation fault (core dumped)". Minimal working example: https://paste.sr.ht/~yoctocell/3947e3c0e09bd1fe0ae977dce1ebb9110b794793
<tissevert>what do you people use in practice for development ? I started by making «default.scm» builders in each project's folder and using guix build -f or guix build environment -l but then local dependencies stroke back
<tissevert>do you have a local (gnu packages *devel-or-something-like-this*) module that references all your local projects ?
<tissevert>something else I haven't thought of ?
***ece8 is now known as ece
<yoctocell>tissevert: I usually create a guix.scm file with a package definition, then run `guix environment --load=guix.scm` in the shell.
<tissevert>ok so same, but then what do you do when guix.scm of one project needs a package defined in ../dependency/guix.scm ?
<jlicht>tissevert: I simply `(load <file>)' my local deps
<tissevert>hmmmm… so that's what (load ) is for ?
<yoctocell>tissevert: I haven't run into a situation like that yet. :)
<tissevert>so it returns what the file is evaluated to ?
<tissevert>yoctocell: lucky you ! : )
<jlicht>tissevert: pretty much, but read https://www.gnu.org/software/guile/manual/html_node/Loading.html for a more complete description
<tissevert>jlicht: just to be sure I understand : the content of those «guix.scm», they are expressions that evaluate to the package, right ? not modules or I don't know what ?
<jlicht>tissevert: I think they could be modules as well, but I'm not sure my `load' approach still works then
<jlicht>tissevert: but yes, my guix.scm files are currently not modules
<yoctocell>tissevert: If they are modules, it might be better to set GUILE_LOAD_PATH and use `use-modules`
<jlicht>^ exactly, or have a look at GUIX_PACKAGE_PATH instead
<nckx>Good morning Guixs.
<jlicht>o/
<tissevert>jlicht: thank you ! ok, so if I understand what you said + the page of the doc you linked, you set somewhere in guix.scm that uses «dependency», you have something similar or equivalent to (define dependency (load "../dependency/guix.scm")) so thate the «dependency» package exists in the scope of the main package definition ?
<tissevert>nckx: halo
<tissevert>oh yeah, I've seen those variables and they seem useful, I just don't really dare touch them yet but I thought I'd have to set them if I was going to define everything in a global .scm file
<tissevert>thanks a lot for your answers !
<bdju>is there info somewhere about installing Guix System on the Pinebook Pro? I recently ordered one and am wondering if I'll be able to enjoy Guix System on it.
<i1l>bdju: savvanah has WIP branch. vagrantc?
<tissevert>hmmm the above approach (define dep (load "../dep/default.scm")) doesn't work here
<tissevert>the variable gets loaded: I get errors when introducing unguilish noise in ../dep/default.scm or when I use the variable dep somewhere inappropriate in my file like (name dep)
<tissevert>but when compiling for good, even though I see the corresponding ghc-package (this is for haskell packages) in the compilation lines, the builder finally yells that it couldn't resolve dependency for package Dependency (with the uppercase initial showing it's considering it from the haskell packages point of view)
<tissevert>I suppose it must be haskell related
<tissevert>wondering if setting up toy bash packages as PoC would be worth the time
<yoctocell>tissevert: I am a bit lost, would you mind sharing the repo?
<tissevert>sorry for the confusing attempt at explaining ^^'
<tissevert>huh I… what I'm trying to do (with guile scripts) isn't versioned yet
<tissevert>I could share the code itself but it wouldn't be very helpful (like, I know it works, I know how to make it work with a stateful system using cabal)
<tissevert>ok I'll try with my PoCs in bash, and if that doesn't work I'll share it
<yoctocell>Ok, could paste the content of the guile stuff in a pastebin maybe?
<tissevert>oh, sure sorry ^^
<tissevert>yoctocell: the «dependency» https://pastebin.com/iQAaCAHP
<tissevert>the «main» program: https://pastebin.com/MtnSEYYm
<yoctocell>tissevert: Cool, I will take a look
<tissevert>thanks !
<tissevert>(still trying the bash PoC meanwhile)
<yoctocell>tissevert: The guile part seems to work fine on my end, it starts to download a bunch of haskell packages.
<yoctocell>Maybe the problem is with some haskell stuff?
<tissevert>maybe but as I said: it builds fine in a stateful environment (on another distro where Cabal works), my other self-contained haskell packages with no local-dependencies work fine using a similar setup, and, finally, defining those two packages in a big module with several (define-public …) work flawlessly
<yoctocell>Hmm, I'm afraid I don't really know what to do, sorry
<tissevert>don't worry, thanks for all the help you've already provided !
<everstone>Hi! I'm trying to get my audio volume, but pulsemixer says "connection refused". Am I maybe missing a group? Audio works fine otherwise
<lle-bout>tissevert: hey! did you succeed running it? try: "guix environment guix" first, then run the command in a subshell there
<sneek>Welcome back lle-bout, you have 2 messages!
<sneek>lle-bout, raghavgururajan says: I am revising the chart to comply with upstream GNOME 40.
<sneek>lle-bout, raghavgururajan says: Brand new chart (https://calc.disroot.org/guix-gnome.html) \o/
<lle-bout>raghavgururajan: aaa superb! thanks a lot!
<tissevert>I really just wanted to prompt other people to check I wasn't doing completely bad stuff, it seems you do things differently but aren't shocked either by my first attempt so I guess it's somewhere in between : )
<lle-bout>tissevert: I still can't run guix-explorer on my system configuration but I run it onto examples, the reason is that my system configuration depends on several third party channels somehow I can't manage to bring them into scope fully (specification lookups on packages included in these channels don't work)
<tissevert>everstone: I wanna say «polkit» here 'cause I have similar weird permission errors (with NetworkManager) here with a very default setup and correct groups so maybe it has to do with polkit
<tissevert>lle-bout: ohhh, I didn't see I needed that, thanks !
<tissevert>hmmm… no luck ^^' still doesn't see the file for some reason
<lle-bout>tissevert: I use GUILE_LOAD_PATH="/path/of/cloned/channel/git:$GUILE_LOAD_PATH" that works for some but it seems specification lookups still don't have that packages for those channels.
<lle-bout>tissevert: I suggest you can investigate the polkit issues still with some of the example configurations in gnu/system/examples in the guix repo
<lle-bout>Nonetheless I would really love to run it on my custom configuration with channels, I opened an issue here: https://notabug.org/civodul/guix-explorer/issues/1
<civodul>lle-bout: it just occurred to me that you could run it with "guix repl -- explore.scm ..." instead of "guile explore.scm ..."
<tissevert>thank you ! (I haven't worked on that yet, I'm still trying to fix the rest and not be too scared by the two mailing lists but I promise I'll investigate those polkit issues someday ^^')
<lle-bout>civodul: ohh!!
<lle-bout>tissevert: no rush and no need for promies - I think guix-explorer can be useful as a general resource to learn more about GNU Guix service composition which is very useful for solving ANY such issue
<lle-bout>tissevert: you may try civodul's suggestion here.. to use guix repl -- explore.scm .. just why havent I thought of it before heh..
<everstone>tissevert: I think polkit didn't help, but it maybe did. When I tried just running "pulseaudio", I saw an error related to my default.pa config. I moved it, and now it works!
<tissevert>everstone: great !
<tissevert>lle-bout: still no luck, one day I'll be able to run guix-explorer but not today : )
<lle-bout>civodul: one thing it's the (syntax-highlight) it depends on
<lle-bout>how could I bring that into guix repl's scope?
<lle-bout>civodul: "$ guix environment --ad-hoc guile-syntax-highlight -- guix repl -- ./explore.scm /run/current-system/configuration.scm" this doesnt work
<civodul>ah yes, it's not that simple
<civodul>well anyway, "something along these lines" in a broad sense :-)
<lle-bout>civodul: :-S
<lle-bout>I don't know how else, stuck
<lle-bout>when I use -L for syntax-highlight it doesnt work either (silently exits)
<lle-bout>I feel like creating a package for it will be easier
<lle-bout>Will attempt this at some poibt
<civodul>not sure
<apteryx>raghavgururajan: are you sure? I tested it yesterday, and I could place calls
<sneek>Welcome back apteryx, you have 2 messages!
<sneek>apteryx, raghavgururajan says: Looks like we need to fix one last thing for linphone-desktop. The missing /lib error (https://issues.guix.gnu.org/47274#4). Currently, the app starts, but doesn't work. :(
<sneek>apteryx, raghavgururajan says: Here's the fix, https://envs.sh/jP.patch :)
<apteryx>this is after referencing the grammar files for liblinphone
<lle-bout>"guix repl -L$(guix build guile-syntax-highlight)/share/guile/site/3.0 -- ./explore.scm /run/current-system/configuration.scm" - this exits silently
<civodul>yes, because you need to call the entry point that's in explore.scm
<civodul>the 'guix-explore' procedure
<lle-bout>civodul: ah ok!
<tissevert>yoctocell: ok, interestingly I get a very similar error trying to define two local bash packages, each one with a simple script containing a printf, and the «A» script calling the «B» script
<lle-bout>seems we can't give arbitrary expressions to guix repl like with guile -e
<lle-bout>will try modifying explore.scm
<lle-bout>not sure how to reproduce this with guix repl: exec "${GUILE:-guile}" -e "(@ (explore) guix-explore)" -s "$0" "$@"
<Rovanion>lle-bout: I've now got three sendmail related patches that all build ontop of each other. Do I attach them all to https://issues.guix.gnu.org/47435 or do I open separate issues for the two new ones?
<civodul>lle-bout: something like adding (guix-explore (cdr (command-line))) at the bottom of the file
<lle-bout>civodul: thanks didnt know about "command-line" variable, useful, like my previous attempts it says this: guix repl: error: Usage: explore FILE
<lle-bout>Rovanion: generate numbered patches using git format-patch or use git send-email and submit all a single issue, also look at using -v2 -v3 etc. arguments, the number corresponds to the revision number of the patchset
<nckx>lle-bout: Omit the cdr.
<lle-bout>nckx: yay! thanks so much!
<nckx>yw!
<civodul>fun: just now, someone on #nixos mentioned https://github.com/craigmbooth/nix-visualize
<civodul>i didn't know it but it looks interesting!
<civodul>(to visualize package graphs)
<civodul>ah but it's all static
<civodul>maybe not that helpful after all
<lle-bout>civodul: so final command, thanks a lot! From your original repo: cat explore.scm | cat - <(echo "(guix-explore (command-line))";) | guix repl -L$(guix build guile-syntax-highlight)/share/guile/site/3.0 -- /dev/stdin /run/current-system/configuration.scm
<lle-bout>tissevert: ^
<lle-bout>Probably I'll want to submit a PR instead to modify the script's shebang
<jeko>Hi Guixters !
<lle-bout>woops well that command doesnt work because relative path isnt working correctly
<raghavgururajan>apteryx: Did you test it with linphone account or other SIP account. The former didn't work, but the later did. This for missing rootca.pem. For missing /lib, multiple codecs we not loaded for any case.
<raghavgururajan>*were not
<tissevert>^^ seems awfully complicated
<lle-bout>tissevert: yes because there's it's a hack
<lle-bout>but I am making a PR now
<lle-bout>You can always choose my fork
<lle-bout>Not sure civodul will accept it for many reasons, first it's a hack, second my thing probably makes it easier to run but not develop
<tissevert>I do wonder how I can get so different results from civodul's with my very vanilla setup : ) still haven't got over my «what did I break» phase ^^
<i1l>tissevert: it happens.
<lle-bout>tissevert: see: https://notabug.org/civodul/guix-explorer/pulls/3
<lle-bout>tissevert: what are you speaking of exactly here?
<everstone>Is there a way to make my operating-system.scm source a helper .scm file? E.g. I define (my packages) for use-modules there
<tissevert>nothing in particular, just the spectacular (and scary) «file not found» I got on my first attempts
<tissevert>the tool will certainly provide meaningful insights when I start digging but I don't really have time at the moment so it doesn't really matter
<lle-bout>tissevert: for explore.scm? I don't find it that surprising that since there's no guix.scm file it's harder to reproduce civodul's dev environment
<everstone>Figured it out! Needed to change guile load path and move some files around
<jeko>Hey ! I want to create VM on-demand to host pair-programming session inside Emacs to learn Guile with friends. First time I try such thing, I am not used to VM stuff. So I would like to ask if I am going to waste my time (I feel it is pretty straight forward to ssh into the VM from the outside)
<tissevert>hmmm, true, I've been believing a bit too blindly «oooh it's guile code, it must be blessed by Guix reproducibility properties» when it has nothing to do in fact
<tissevert>sorry about that : )
<leoprikler>Is man7.org the definitive source on Linux manpages or should I reference something else?
<Noisytoot>leoprikler: I don't think there is a definitive source
<jeko>oh no my script to deploy VMs doesn't work anymore !
<lfam>What goes wrong, jeko?
<jeko>Actually, the issue seems to come from qemu
<jeko>$ guix environment --ad-hoc qemu -- qemu-system-x86_64 -enable-kvm -m 1G -net nic -net user,hostfwd=tcp:127.0.0.1:10022-:22 -device virtio-blk,drive=guix -drive if=none,id=guix,file=5jyk1a3vr6i07lpswqgrpph122vdxj9g-image.qcow2
<jeko>Unable to init server: Could not connect: Connection refused
<jeko>gtk initialization failed
<lfam>Recently we updated QEMU. Maybe it's fallout from that
<lfam>I've never seen this message, but I use Guix's VM tooling a little differently
<lfam>I always copy the qcow2 image out of the store and make it writable before trying to use it
<lfam>I also don't use that 'hostfwd' option
<jeko>honnestly I copy paste things until it works haha then I read docs about solution
<jeko>I build the VM using this script https://framagit.org/Jeko/guix-machine-os-ynm/-/blob/master/deploy-vm/deploy-vm.sh
<jeko>inspired by https://gitlab.com/janneke/deploy/-/blob/master/deploy-vm.sh
<jeko>I read discussions on the mailing list about port forwarding also
<jeko>lfam: but if you have another solution I am curious ! haha
<lfam>jeko: I've never SSH-ed into the VM, so I can't really replace your solution exactly
<jeko>ok ok
<lfam>I'll try my normal thing now, and report back on how it goes
<raghavgururajan>lle-bout: Any luck with shepherd? I am currently working on gstreamer
<lfam>jeko: I ran your command, but with a writable copy of the VM image, and it worked fine
<lfam>Another difference is that I keep QEMU installed, rather than using an ad-hoc environment
<raghavgururajan>lle-bout: Oh also, could you rebase our branch with c-u to include your php fix?
<jeko>lfam: oooh i will check the permissions thx
<kozo[m]>jeko: Not sure if related but I have my user part of libvirt group for permissions relating to virt manager and qemu
<lfam>I don't have anything like that on my end
*lfam continues trying to fix the "devel" manual for the website
<lfam>Now, I'm reading the rotated mcron logs and clearing cached build failures
<lfam>I'm clearing specific cached failures, not all of them
<jeko>👍️
<dongcarl>lle-bout, marusich: How are y'all feeling about #47349? Seems simple enough and perhaps we can get it in before v1.2.1?
<lle-bout>raghavgururajan: heyy!! hasnt had time to look at shepherd for now, yes I'll rebase, just eating now, dongcarl it was merged as https://git.savannah.gnu.org/cgit/guix.git/commit/?id=58452d08ff3e0044e9a32e6d5b3663cf185d8b33 just needs closing the bug actually
<dongcarl>lle-bout: Oh! Yay :-) I will close the bug!
<lle-bout>raghavgururajan: here and available
<PotentialUser-60>Seems b5116db5c05f662f775096ef4c105fa7aea5c8b4 (gegl update) broke gimp. It now cannot find gegl.
<lle-bout>PotentialUser-60: send an email to bug-guix@gnu.org so we can track it, thanks
<nckx>PotentialUser-60: Can you elaborate?
<nckx>How are you starting GIMP, what happens, how does it tell you etc.
<lle-bout>nckx: on startup it says: "GIMP requires the GEGL operation "gegl:introspect". This operation cannot be found. Check your GEGL install and ensure it has been compiled with any dependencies required for GIMP." in some GUI dialog
<nckx>Strange.
<nckx>But thanks for reporting.
<lle-bout>nckx: it does this only in a --pure env for me
<nckx>I'm still building one.
<nckx>Yep, same here.
<nckx>I wonder why it only happens with --pure (and now) o_O
*nckx tries b5116db5c05f662f775096ef4c105fa7aea5c8b4^
<Bumblehorse>For the past couple of days guix pull has been giving me errors like this:
<Bumblehorse>guix/ui.scm:2164:12: In procedure run-guix-command:
<Bumblehorse>Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
<Bumblehorse>substitution of /gnu/store/7s74qzkk5qagfsldfl19y21hsfam1d5g-guix-core failed
<Bumblehorse>guix pull: error: corrupt input while restoring archive from #<closed: file 7f37bf0f3d90>
<Bumblehorse>Has anyone been experiencing the same thing?
<lle-bout>Bumblehorse: use a paste service like paste.debian.net next time, and yes sorry about that, try: "while true; do guix pull && break; done" - there's actually fixes available for this but you need to update
<Bumblehorse>Ok I will try that. Sorry about the not-pasting :(
<PotentialUser-60>lle-bout: it does it after a normal upgrade for me
<PotentialUser-60>i have to lock the commit
<lle-bout>PotentialUser-60: GIMP issue?
<PotentialUser-60>yes, the gimp issue
<Bumblehorse>lle-bout: well now it is just constantly throwing errors. It has looped about five times now
<lfam>It's annoying but keep going
<lfam>We are sorry for the annoyance
<yoctocell>Is there a quick way to build all direct and indirect dependecies of a package?
<lfam>`guix environment $package`
<lfam>It won't necessarily build everything, but it will make everything available
<lfam>You could use --no-substitutes to increase the percentage of things that are built
<lfam>If you can be more specific about your goal, then people can give more specific advice
<nckx>PotentialUser-60: How did you upgrade, and how are you running, the GIMP?
*lfam notices that building the website is failing now, too
<lle-bout>yoctocell: guix refresh -l <pkg> returns the list of those so maybe pass that list to build with --check or something also
<yoctocell>Oh sorry, I meant packages that directly or indirectly depend on a package...
<lfam>lle-bout: I think that `guix refresh -l` lists dependents, but not dependencies
<lfam>lle-bout's advice is correct
<lle-bout>lfam: ah yes sorry
<lle-bout>ah then!
<yoctocell>lle-bout: Ah thanks!
<nckx>yoctocell: I use a trivial bash script that builds the output of lle-bout's command.
<PotentialUser-60>nckx: I upgraded my user profile using a manifest ... i also tried to remove gimp from that manifast and put it into my system declaration ... both lead to the same results .. I run it by typing gimp into my awesome launcher ... or by typing it into alacritty (?)...
<lfam>You can also use `guix graph` in certain ways, for example with the reverse-package method
<nckx>Generally works great.
<yoctocell>nckx: Cool, would you mind sharing? :)
<nckx>PotentialUser-60: Thanks. Weird. I can invoke the latest ‘guix install gimp’ just fine (as ‘$ gimp’), and even launch it directly from the store (/gnu/store/.../bin/gimp); it fails only in a --pure Guix environment.
<nckx>yoctocell: It's literally trivial, something like ‘guix build --keep-going --etc $(guix refresh -l "$@" | cut -d: -f2-)’.
<yoctocell>nckx: Ok, thanks!
<nckx>That's what the output of refresh -l means, after all.
<raghavgururajan>lle-bout: No worries! Never mind about rebase, I've added the php fix patch.
<nckx>I'd say it's a bug if it outputs anything unbuildable :)
<nckx>(By nature, I mean; of course the build can fail.)
<lfam>nckx, yoctocell: I also recommend adding --no-grafts to the build command, unless you need the grafts for this
<lfam>Otherwise, it might use about double the disk space
*nckx adds --no-grafts to almost everything don't tell mother.
<lfam>I use it liberally, but never for `guix package` :)
<lle-bout>civodul: somehow I received 4 copies of your reply to "terrible ux emacs upgrading in guix"
<lfam>nckx: Changing the subject, do you know if anyone is, like, "in charge" of the web presence? I'm wondering who to talk to about the build failures of the website and manuals
<lfam>If you check the recent mcron.log on Berlin, you'll see what I'm talking about
<PotentialUser-60>nckx: strange, indeed. I removed it from the manifest. pulled the latest guix. Did guix install gimp && gimp same results. Not that I'm surprised but you never know :)
<lfam>nckx: I'm considering manually updating the symlink that points to the devel manual
<lle-bout>nckx: using this: "env | while read line; do echo $line; ./pre-inst-env guix environment --pure --ad-hoc gimp -E $(echo $line | grep -Po '^.+?(?==)') -- gimp; done" - which preserves environment variables one by one, every of them fail, so it must be a combination of two or more
<apteryx>raghavgururajan: I'm puzzled as to why I can't reproduce any linphone-desktop failures here? any tip?
<raghavgururajan>apteryx: Can you try removing linphone folders in .config .local and .cache
<raghavgururajan>Also, if you run from terminal, you'll see the things related to missing /lib and codecs not found.
<apteryx>yes, but these are just warnings and they are actually enabled (the codecs)
<raghavgururajan>No, I got a pop-up dialog to download codecs.
*nckx got called away.
<lfam>I filed a bug about the website failing to build
<lle-bout>these websites issues are weird suddenly
<nckx>lfam: Not officially. It falls mainly upon Ludo's & Mathieu's shoulders, as expected...
<lfam>Yeah
<nckx>I forget if it's the same Mathieu as the other Mathieu or the other one, but you know the one.
<nckx>PotentialUser-60, lle-bout
<raghavgururajan>apteryx: Once, clearing the .dot-files, try logging into linphone account using assistant. You'll see could not send request. Then apply only rootca part of my patch and re-login. login will succeed and you;ll get pop-up to download codec.
<nckx>*: honestly, I might just punt and revert gegl. I'm in no mood for a sometimesbug today, and the old one did the job.
<lfam>I think we only have a single Mathieu these days, right?
<lle-bout>nckx: do it
<nckx>Did we lose one? Pity.
<lfam>Gegl / GIMP really need to be handled together
<lfam>And babl too
<nckx>gegl & babl yes, gimp less so.
<apteryx>I've tried with mv ~/.config/linphone{,.bak} and mv ~/.local/share/linphone{,.bak}; now my account doesn't connect but the plugins are still there, hmm
<nckx>lfam: IME that is.
<apteryx>raghavgururajan: that the account remains means I didn't manage to clear it fully though
<lfam>I'd guess the gegl update broke glimpse, too
<apteryx>raghavgururajan: I'll take your word for it and apply the patch.
<lfam>Glimpse may not really be possible to package easily alonside gimp. Time will tell
<nckx>lfam: Is that the GIMP form?
<raghavgururajan>yeah, its .cache
<raghavgururajan>probably
<nckx>*fork.
<lfam>Yes
<nckx>Never tried it.
*nckx tries it.
<raghavgururajan>apteryx: :)
<lfam>I'd like to see the UI improvments pan out, but it really depends on if the project can grow a development community or not
<lfam>I use it purely because the zoom in / out controls are backwards, IMO, in gimp
<lfam>I never got used to that
<apteryx>raghavgururajan: I don't have anything linphone related under .cache it seems
<nckx>Wow, that fork tastes a lot forkier than I expected.
<nckx>A moron in a hurry (that's me) would not be able to distinguish the two.
<raghavgururajan>I see.
<lle-bout>nckx, lfam: hey, do you think we should get a security tracker to collaboratively analyze CVE data? Or other sources of security-related notifications
<lfam>Hm, I don't know. Do you think so?
<lle-bout>lfam: yes because otherwise it doesnt scale beyond one person looking at CVE data and everyone's re-doing the work
<lle-bout>We just need a comment system on CVE entries with some labeling
<lle-bout>I am thinking we could do that by email, but also email can be tedious at times
<lfam>Debian's is great. It's actually the only part of their web site that stays up to date and reflects the reality of the distribution
<lle-bout>In that, when I handle many CVE entries at a time, sending emails to update tag information on each is tedious
<cbaines>lle-bout, I've got some plans about tracking security issues, I want to build some stuff soon
<lle-bout>cbaines: nice :-)
<lfam>So, if we do this, it needs to stay up to date and, if it doesn't, we must be fearless about removing it
<lfam>Having a stale tracker is worse than no tracker
<lle-bout>Sure
<lle-bout>I am going to feed it information for sure
<lfam>I probably won't participate very much, but I will mark things as done if I fix them
<lfam>I would point out that Guix still hasn't been able to obtain a CVE ID for the privilege escalation bug we fixed weeks ago
<lfam>I think the CVE ID system is kind of collapsing, but it's still better than nothing
<lle-bout>lfam: yeah you usually obtain the CVE ID *before* disclosing
<lle-bout>then make the CVE ID public
<lfam>No, that's not true
<lle-bout>lfam: how so?
<lfam>That is one way to do it, but it was not the norm, for many years
<nckx>lfam: I haven't heard back but nor have I bothered anyone further (I wouldn't know whom to further bother anyway).
<lle-bout>lfam: well.. only way to be sure
<nckx>So maybe that's an avenue.
<lfam>If we had chosen to wait for a CVE ID, the bug may never have been fixed
<lle-bout>This was used? https://cveform.mitre.org/
<nckx>Yup.
<lfam>Basically, at this point, the only projects that can obtain CVE IDs are projects under the umbrella of a CVE Numbering Authority
<lfam>Any project that is independent is shut out from the system
<nckx>lle-bout: That was never the usual way, it was just not much of an issue because they were responsive.
<nckx>Even now it's not a solution: if you wait now, you wait forever.
<lle-bout>Now Github provides a security thing on it's own, maybe they're a CNA
<lfam>Since MITRE stopped assigning CVE IDs via the oss-sec mailing list, independent projects have had to go through back-channels via friends at Red Hat or similar CNAs
<lfam>And I've noticed certain projects that used to announce CVEs have stopped doing it. Maybe they have stopped finding security bugs, but I doubt that
<nckx>If only there were an umbrella organisation that collected funds to work together and did.
<lfam>The Github CNA notes say this: "GitHub currently only covers CVEs requested by software maintainers using the GitHub Security Advisories feature"
<lfam>So, we could try using that mechanism
<lle-bout>It's not perfect but yep
<lfam>There is also "The GitLab application, any project hosted on GitLab.com in a public repository, and any vulnerabilities discovered by GitLab that are not in another CNA’s scope"
<lfam>There must be a copy of Guix on Gitlab somewhere
<lle-bout>NLnet labs seems to be an authority
<cbaines>I don't know a lot about the CVE stuff, but maybe Guix, GNU or the FSF should become a CNA?
<lfam>" All NLnet Labs projects"
<lle-bout>FSF should definitely become a CNA..
<lfam>I don't think Guix is an NLnet project, but we could probably make it happen
<nckx>lle-bout: If only they did useful things like that.
<lfam> https://cve.mitre.org/cve/request_id.html#cna_participants
<lfam>It's a really weird system now, but I think we all agree that it's the best system we've got
*lfam afk
<lle-bout>nckx: yeah well :-) - maybe soon
<cbaines>It looks like there's no monetary cost, just time https://cve.mitre.org/cve/cna.html#become_a_cna
<lle-bout>not sure we can become a CNA
<cbaines>Debian is, so other distros are
***sorki is now known as srk
<cbaines>Guix seems to meet the requirements on taht page
<nckx>lle-bout: Everyone I talk to with FSF on their hat is a chronically overworked volunteer, so I don't want to push it on them, but the organisation has the resources to do so if they'd choose.
<lle-bout>cbaines: alright we could try, is there some commitment requirements or..?
<cbaines>I don't know, I was just interested in whether it was an option
<lle-bout>nckx: I don't understand completely what the FSF is exactly overworked with
<nckx>Nor I.
<nckx>Want ‘Reported-by’ credit in the gegl revert, and if so to which name?
<nckx>PotentialUser-60: ☝
<bdju>has anyone taken a look at LibreWolf? Any chance it'll get packaged, or is it not the same level of free as IceCat?
<lle-bout>bdju: I was looking at it, just need to put the effort
<lle-bout>bdju: I think it's OK considering we have ungoogled-chromium
<lle-bout>LibreJS etc. is great but for now not very practical so I believe most people disable it anyway
<bdju>ah, good to know.
<lle-bout>There's so much work involved in Free-ing the ever-changing web
<efraim>I'm looking at arcticfox but having it's not ready yet
<lle-bout>cbaines: hey do you have some TODO list of your own you could share?
<cbaines>lle-bout, regarding which things? :)
<nckx>Big if true: https://github.com/aferrero2707/gimp-appimage/issues/61
<lle-bout>nckx: "$ ./pre-inst-env guix environment --pure --ad-hoc gimp graphviz -- gimp" works
<lle-bout>PotentialUser-60: ^ there we have it
<nckx>lle-bout: Yes. :)
<nckx>That was my point.
<nckx>What a very... G* error message. Sigh.
<lle-bout>cbaines: your work GNU Guix-related
<lle-bout>cbaines: or how to observe every day what you do related to GNU Guix
<cbaines>lle-bout, I have a few Wekan boards that I use for various things (Guix Data Service, Guix Build Coordinator and a general Guix one) but they're not public currently
<cbaines>There's rough roadmaps for the Guix Data Service and Guix Build Coordinator in their respective Git repositories
<cbaines>and then there's the more goal like perspective on what I'm trying to do, so improving the patch review process, the tooling for operating a substitute server, and the thing I'm looking to start around security and trust in Guix
<lle-bout>cbaines: okayy!
<cbaines>I can try to post more to Mastodon about what I do day to day if that is useful?
<lle-bout>cbaines: oh yes!
<lle-bout>I feel like you've been doing very useful stuff in almost complete radio silence
<lle-bout>I'd like to cooperate somehow
<davidl>I need help passing guix lint test regarding indentation
<davidl>lines are too long.
<cbaines>lle-bout, I do write long emails to guix-devel, although maybe not recently, expect some in the next few weeks though!
<lle-bout>cbaines: right I remember, I need to re-read them also
<davidl>I am using emacs, is there any good way or should I just go by personal taste while making sure the lint test passes?
<lle-bout>davidl: I guess your taste, what kind of line is it? if it's a long URL probably not worth fixing the lint error for example (my opinion)
<davidl>lle-bout it is a list of patches.
<lle-bout>davidl: patch name too long?
<jeko>Hey! On a foreign distro (say Ubuntu), do I configure openssh installed via Guix the same way I would configure it installed via apt (aka /etc/ssh/sshd_config)?
<davidl>llebout: yes
<davidl>lle-bout: yes
<leoprikler>I think on a foreign distro you'd probably use the foreign distro's ssh service.
<lle-bout>davidl: for this I would shorter the patch name but I've pushed stuff with such lint warning ignored because because it would've required me to split the string in two
<lle-bout>I feel like adhering to the lint by using (string-append ..) misses the point
<jeko>leoprikler: oh right
<lle-bout>but probably I should've used shorter path name
<davidl>lle-bout: the patch is not mine.
<lle-bout>davidl: you could still rename it but yeah
<davidl>lle-bout: Im unpacking a centOS rpm, with the patch inside the rpm archive.
<leoprikler>jeko: though if you must, guix uses the "-f" parameter to pass the file directly (which is a very sane way of passing config files, that perhaps more daemons should consider)
<lle-bout>davidl: are you writing a package definition or..?
<davidl>lle-bout: ok. Yes.
<davidl>lle-bout: here https://paste.debian.net/1191597/
<davidl>lle-bout: I moved the first patch to the left in the patches list in a "wrong" way but it solves the error at least. I need to leave for the evening though, sry :/
*davidl afk
<lle-bout>davidl: I think it's fine!
<lle-bout>davidl: is that a manually written package? do you plan submitting to GNU Guix or..? Does vsftpd only exist in the centos repos?
<jeko>leoprikler: I don't need to, I installed it using apt ! Thanks, sometimes I overcomplicate things haha. And I will try to keep the -f param in mind just in case
<davidl>lle-bout: it exists in Guix already. I plan to send a patch
<davidl>to update the definition to what I wrote.
<davidl>this is so that you can have TLSv1.2, email-passwords etc.
<davidl>which is not supported in the current vsftpd package thats in guix
<atuin>does guix provide clangd language server in any package?
<atuin>ahh i found it :D `clang:extra'
<lle-bout>davidl: got it, sounds cool but also I would just use SFTP instead, let's see what people say about the rather unconventional way of using an rpm as origin here
<apteryx>raghavgururajan: are you testing with plain SIP accounts, or the linphone accounts?
<apteryx>testing with SIP accounts it works at least on a 2nd Guix System as is
<apteryx>(where there was no previously installed linphone, hence no cache)
<apteryx>raghavgururajan: just re-read your message, now I understand the problem is strictly with a linphone account; I understand why I couldn't see it.
<apteryx>raghavgururajan: I pushed the commit as 6aaa8269b82d50e43405847a479ffaeb0b569fa5, thank you!
<lle-bout>raghavgururajan: that table is huge now!