IRC channel logs

2020-04-26.log

back to list of logs

<rekado_>the warning is about the “delete” syntax rule, which only matters inside of modify-phases
<bricewge><rekado_ "the second one looks like a mism"> sirmacik Have a look in the manual about kernel-loadable-modules and kernel-module-loader-service-type.
<GuixGuy>Greetings, can someone assist me with getting git patch-format setup please? or let me know of another way I can submit code
<vagrantc>you can just run "git format-patch origin/master.." and then attach the generated patch(es) to an email
<GuixGuy>OK, thank you
*vagrantc likes the second opportunity to review before sending using the usual mail client rather than figuring out git's email interface
<vagrantc>but everyone has their own preferences :)
<GuixGuy>I'm just going by what the manual says
<GuixGuy><shrug>
<vagrantc>sure
<vagrantc>it's not wrong, just figured i'd suggest a simple option
<emys>the link to the guix cookbook (entirely on one page) is broken https://guix.gnu.org/cookbook/en/
<GuixGuy>I appreciate the suggestion as I was also hoping for an easier method =P
<vagrantc>or maybe I should just file a bug regarding libdbusmenu
<jonsger>vagrantc: I saw them as well
<mbakke>vagrantc: it's because the initrd currently uses Guile 2.0 due to some bootstrap changes, I expect to push a fix tomorrow
<mbakke>(the weird boot warnings)
<vagrantc>mbakke: thanks
<thePiGrepper>hi, quick question. shutdown nor poweroff work(or exist), how do I shutdown the system?
<GuixGuy>Do you have halt?
<thePiGrepper>yeah. thanks, it worked
<GuixGuy>=]
<thePiGrepper>btw, do you have a good guide/tutorial for the package manager?
<GuixGuy>What package manager?
<thePiGrepper>guix
<GuixGuy> https://guix.gnu.org/manual/en/guix.html#Invoking-guix-package
<GuixGuy>Is that what you are looking for?
<GuixGuy>Hey, I am using emacs to auto format my code but guix lint keeps reporting that "yarn.scm:16:0: yarn@1.22.4: tabulation on line 16, column 0"
<GuixGuy>What does that mean?
***jonsger1 is now known as jonsger
<Gooberpatrol66>how do you handle a case where one package needs to write into the directory of another package?
<ryanprior>Gooberpatrol66 we patch the package(s) so that they no longer require that.
<ryanprior>Gooberpatrol66 somebody might be able to offer a more specific idea if you explain the context of your example :)
<Gooberpatrol66>ryanprior: i'm trying to package webp-pixbuf-loader
<Gooberpatrol66>ryanprior: it wants to write into /lib/gdk-pixbuf-2.0/2.10.0/loaders
<Gooberpatrol66>ryanprior: (under gdk-pixbuf)
<Gooberpatrol66>ryanprior: so...i need to make gdk-pixbuf look in a location that webp-loader can write to
<Gooberpatrol66>ryanprior: and make webp-loader write under its own directory
<ryanprior>I don't know how to handle that kind of case, hopefully somebody who's hit that kind of situation can explain
<ryanprior>You can definitely patch webp-loader to write under its own directory, and I might be able to help you do that too.
<ryanprior>The part I don't know is how you get gdk-pixbuf to look there, maybe there's a way to get it to put a link somewhere or somthing? Dunno.
<KE0VVT>bandali: I don't have a keyboard for the new PC. :-(
<bandali>KE0VVT, ah.. that's inconvenient. can you ssh into it and/or use it remotely for the time being?
<KE0VVT>bandali: I will be doing an install, etc.
<KE0VVT>bandali: It still has Windows on it.
<bandali>KE0VVT, ah. maybe you could use an on-screen keyboard? though i'm not sure if the curses-based guix installer has that
<KE0VVT>bandali: I've been using on-screen keyboard in Windows 10 to download ISOs.
<bandali>right
<raghavgururajan>sneek, later tell janneke: Regarding #40753, I accidentally sent the wrong patch that missed some things. So sorry. I have send another patch to the email thread to append the previous commit. Could you please push it as new commit. Thanks!
<sneek>Got it.
<raghavgururajan>Folks!
<raghavgururajan>During install phase, I get "mkdir: cannot create directory ‘//etc/spacefm’: Permission denied".
<raghavgururajan>What should I do?
<apteryx>seems the sysconfdir is not being set right. The solution depending of the build system. When using the gnu build system it is taken care of via passing --sysconfdir to the configure script, I believe.
<apteryx>actually, the gnu build system leaves it alone, but it sets --prefix
<apteryx>I think it defaults to '${prefix}/etc' in autoconf generated configure scripts.
<apteryx>raghavgururajan: ^
<raghavgururajan>apteryx Yes, I tried setting sysconfdir to out/etc. But the default sysconfdir in configure script is prefix/etc. But prefix is already set correctly by gnu-build-system. I wonder why it doesn't work without explicitly setting sysconfdir.
<raghavgururajan>Explicity setting sysconfdir works though.
<apteryx>perhaps a bug in their autotools configs that causes a variable to net be expanded correctly depending on prefix. There was something similar recently in the btrfs-progs package, that was fixed by Marius. You might want to have a look.
<raghavgururajan>apteryx Thanks you!
<rowhit>apteryx: Hi. I am trying to install pyinstaller. I get the following error: "AttributeError: module 'sys' has no attribute '_MEIPASS'". Could you suggest as what may be wrong?
<apteryx>rowhit: how? from pip? we do not have a pyinstaller package in Guix yet.
<rowhit>apteryx: Thanks a lot for the response. I created a guix package file using guix import pypi -r pyinstaller.
<rowhit>apteryx: And then modified it to get all the dependencies. And ran guix package --install-from-file=python-pyinstaller.scm
<rowhit>apteryx: I am not sure how to attach the file here.
<rowhit>apteryx: Here is the link to the file: https://pastebin.com/F2niMULm
<apteryx>rowhit: there's no need to; if you want to contribute to Guix, it should be formatted to follow our coding guidelines (see: info '(guix)Contributing') and submitted to guix-patches@gnu.org, one package definition per commit.
<rowhit>apteryx: I am trying to set the environment variable _MEIPASS but I guess guix ignores all the shell variable. I need to add it somewhere in the package definition with (arguments phases etc"
<rowhit>apteryx: But it is not building yet, How do I contribute? Can you submit a broken package?
<apteryx>ah, sorry, I had misunderstood. Now I understand that you have problems with this approach (I thought you changed your approach after my original question).
<rowhit>apteryx: No worries, I am new to guix. I have been a long time nix user (never contributed much as I always found a package that I ever needed). But I find guix to be much cleaner and trying to make a switch.
<apteryx>I don't think you need that python-dis3 package, as we're on Python 3.7 on the master branch. 'dis' is included from Python3.5+, whatever it is.
<apteryx>unfortunately the pypi importer doesn't consider versions, so it adds blindly everything the setup.py lists as dependencies.
<apteryx>it's currently up to the packager to spot these and remove them manually.
<apteryx>that doesn't resolve that weird MEIPASS issue though (I could reproduce it here).
<jfred[m]>whew, trying out core-updates and I'd forgotten how much of a performance boost gnome 3.34 was
<rowhit>apteryx: I am trying to setenv _MEIPASS in the modify-phases step but it is still failing.
<apteryx>Why do they attach that variable to sys? That's a core python module.
<apteryx>seems it occurs while attempting to run the tests
<rowhit>apteryx: I am sure we can disable pytest but then during normal operation it may create issues?
<rowhit>apteryx: "Why do they attach that variable to sys? That's a core python module. " Really not sure.
<apteryx>yeah, I'm not suggesting disabling the test, but it should point us where to look at. Perhaps the tests expect some state before being run.
<apteryx>rowhit: this goes further but seems to fail all the functional tests (so far, it's running) https://paste.debian.net/1143049/
<Blackbeard>Hello :)
<sneek>Welcome back Blackbeard, you have 1 message!
<sneek>Blackbeard, thvk-ivgf says: I'm OK, but that temperatures are bad thing. I start to dream to move to Yakutia, or elsewhere North.
<apteryx>rowhit: from there I'd suggest running the build with -K (--keep-failed), then go to the build dir saved under /tmp, and iterate directly in the source until the tests pass
<plasma41>The TLS Certificate for guix.gnu.org expires on Friday. Please renew asap.
<apteryx>rowhit: just running the test suite with my modified version yields: == 3 failed, 259 passed, 15 skipped, 11 xfailed, 8 warnings in 46.01 seconds ===. Not too bad.
<apteryx>some guidance to run the tests is found here: https://github.com/pyinstaller/pyinstaller/tree/develop/tests
<reepca`>hmm... I find myself in a position to really want to use the name of a fiber (so that temproots filenames can take the form <pid>.<fiber-name>), but it seems that although guile-fibers provides a way to get a fiber from a name, it provides no way to actually figure out what the name of a fiber is in the first place.
<reepca`>I guess I could use fold-all-fibers to search for the name of the current fiber, but it seems odd.
<KE0VVT>which keys does guix inst req? my kbd broken
<KE0VVT>typ w onboard rn
<KE0VVT>bc no kbd
<raghavgururajan>Okay, so if the source tarball has both "configure" and "configure.ac", how to make gnu-build-system to use .ac via autoconf, instead of configure?
<reepca`>raghavgururajan: see ~/.config/guix/current/share/guile/site/3.0/guix/build/gnu-build-system.scm line 176, the bootstrap phase will by default do nothing as long as configure exists. You could either replace the bootstrap phase with one that doesn't make that check, or you could put a phase before it that deletes configure.
<raghavgururajan>reepca. Thanks.
<reepca`>👍
<KE0VVT>reepca` hw u typ emoji?
<raghavgururajan>reepca I also have makefile and makefile.am in multiple directories. So how to invoke automake, instead of directly using makefile?
<raghavgururajan>KE0VVT Hey o/
<KE0VVT>raghav-gururajan hi
<reepca`>KE0VVT: with emacs, via M-x insert-char (or, alternatively, C-x 8 RET)
<KE0VVT>reepca` u memo u+nnnn?
<reepca`>I just type in the name. So for example M-x insert-char <RET> THUMBS UP SIGN <RET>
<KE0VVT>reepca` r chars bw or clr?
<reepca`>in emacs they show up as whatever color the text does. So not black-white per se, but monochromatic. In ERC messages that I send are red, so they show up as red to me.
<KE0VVT>gnu needs full emoji
<reepca`>raghavgururajan: that I'm not so sure about. Usually automake is invoked indirectly by the bootstrapping process, right?
<raghavgururajan>reepca Removing configure file worked. But I am getting "AM INTL SUBDIR is m4_require'd but not m4_defun'd".
<reepca`>¯\_(ツ)_/¯ I'm afraid my experience with autotools is rather shallow yet. But if you get errors when you try doing the bootstrapping yourself, perhaps you're meant to use the provided configure instead of regenerating it?
<raghavgururajan>KE0VVT How's your cognitive dissonance (guix <---> trisquel)? xD
<raghavgururajan>reepca That's okay. No worries!
<KE0VVT>raghav-gururajan huh?
<Blackbeard>guix-vits hi
<raghavgururajan>KE0VVT You mentioned a while ago that you are stuck choosing between trisquel and guix?
<KE0VVT>raghav-gururajan yes. willl try on this new pc
<raghavgururajan>Cool!
<ryanprior>use guix on trisquel imo. trisquel installer is really nice.
<KE0VVT>u do this?
<KE0VVT>ryanprior
<guix-vits>Hi Blackbeard
<apteryx>raghavgururajan: there are lots of examples in the code about reboostrapping the build system with autotools.
<apteryx>You need to add automake, which includes M4 macros for autoconf, IIRC.
<ryanprior>KE0VVT I use guix on elementary OS, last time I used trisquel was before I'd started using guix
<raghavgururajan>apteryx Yes, I did add ac and am as native-inputs. Will have to look into code base more.
<KE0VVT>ryanprior why not at least just reg ubuntu
<apteryx>raghavgururajan: internationalization would be provided by gettext I guess
<ryanprior>I adore elementary OS and am working on building packages to bring some of the things I like about it to guix. You can follow my progress here: https://github.com/ryanprior/guix-packages/blob/master/testing/elementary.scm
<KE0VVT>ryanprior freedom issues w eos
<ryanprior>KE0VVT yes, they are inherited from Ubuntu. All elementary software is free.
<KE0VVT>ah
<KE0VVT>ryanprior eos seems to look like macos but lack its function
<ryanprior>I'm happy to talk about it in #elementary if you're interested :)
<KE0VVT>ryanprior ping
<ryanprior>pong 👋️
***calher is now known as KE0VVT
***apteryx is now known as Guest79284
***apteryx_ is now known as apteryx
<apteryx>Blackbeard: I've packaged hackneyed-x11-cursors :-)
<apteryx>it looks nicer than whiteglass
<apteryx>I'll submit the patch tomorrow
<olivuser>hello guix!
<olivuser>I have a question regarding guix channels. I am using a channel that is hosted on gitlab. Since some time, I am not able to pull from it. The error message is something along the lines of "too many authentication requests or redirects". Does anyone else have (had) such a problem?
<roelj>olivuser: That sounds like you also cannot do "git pull <the-gitlab-repository>". Perhaps you are missing an SSH key to authenticate with?
<olivuser>@roelj, thanks for the suggestion. actually I didnt even know that "guix pull" was actually just an alias to "git pull". I will try that later on. But is it normal that you need a ssh key for authentication in the case of a public repo? I am also asking because it has been working for months, and only now after I reinstalled my system it has started not working.
<olivuser>I at first thought that the problem was related to tor, but the problem persisted even after I removed tor through config change and reconfigure
<roelj>olivuser: "guix pull" is not an alias to "git pull". Could it be that the URL of the gitlab repository uses the SSH-based URL? Try changing it to the HTTPS-based URL.
<olivuser>@roelj, no, the url is https-based
<roelj>olivuser: Alright, then I don't know what's going on :)
<olivuser>@roelj, thanks for the help anyway. I will try if doing a "manual pull" works out
<raghavgururajan>Hello Guix!
<raghavgururajan>So how to build a python-based package that does not have setup.py file but only install.py file?
<str1ngs>hello raghavgururajan
<raghavgururajan> https://sourceforge.net/p/diffuse/code/HEAD/tree/tags/release-0.4.8/
<jlicht>hey guix!
<mekeor>hello guix, hello jlicht :)
<jonsger>hmpf. icedove doesnt build reproducible :(
<jonsger>oh and guix doesnt keep the other built, so waiting 1,5h again :(
<mbakke>jonsger: you forgot to use --keep-failed to inspect differences? :/
<jonsger>mbakke: does it save then both results?
<mbakke>jonsger: yes
<jonsger>the manual advises to use `guix archive`
<mbakke>jonsger: for what? link?
<jonsger>to the manual?
<mbakke>oui
<mbakke>or the relevant section for what you are trying to do
<jonsger>7.1.1 Common Build Options -> --rounds=N
<mbakke>jonsger: I don't see any mention of `guix archive` there? it does mention --keep-failed though.
<jonsger> http://guix.gnu.org/manual/en/guix.html#Common-Build-Options "Note that, currently, the differing build results are not kept around, so you will have to manually investigate in case of an error—e.g., by stashing one of the build results with guix archive --export (see Invoking guix archive), then rebuilding, and finally comparing the two results. "
<mbakke>oh, I was looking at guix-daemon options (!)
<mbakke>that seems outdated
<mbakke>jonsger: can you file a bug (or patch :-))?
<jonsger>can do
<mbakke>great :)
<efraim>16 hours to build guile-3.0 using guix on my G4
<jonsger>efraim: built times on non-JIT plattforms went about for Guile 3.0 :(
<efraim>the laptop being 15 years old didn't help
<jonsger>mbakke: http://issues.guix.gnu.org/issue/40867 only a bug
<mbakke>jonsger: thanks!
<jonsger>efraim: do you know if I can emulate powerpc32 on powerpc64le?
<efraim>jonsger: from hanging out in #gentoo-powerpc I'm pretty sure you can
<jonsger>so the question, will it be faster then your G4 :P
<efraim>I wouldn't be suprised if it were
<efraim>I assume it could also have more than 1 core and 1.5GB of ram
<jonsger>16 cores and 16GiB RAM shouldn't be a problem, to run in the background
<jonsger>efraim: If you have some instructions I could jump int
<efraim>i'll have to look around to see if I can figure it out
<jonsger>efraim: I can only allocate 2G and 1 core due the "machine" g3beige restrictions
<clodeindustrie>hi there, trying to install GuixSD on a VM following the guide, however when the install runs it fails with a "/gnu/store/xxxxxxx/module-import-compiled.drv': no such file or directory
<clodeindustrie>no idea what's going on there, I have downloaded the last image and used mostly default setting for the installation
<jsynacek>Hi, where do I find the system configuration file in the guix-1.1.0 vm? There's no /etc/config.scm there.
<lprndn>jsynacek: I think it's /run/current-system/configuration.scm ;)
<jsynacek>lprndn: I can't find it there.
<lprndn>jsynacek: hum... then I don't know :/
<jsynacek>It seems to be missing entirely.
<guix-vits>jsynacek: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/examples
<jsynacek>guix-vits: Thanks!
<catonano>sneek later tell emys did you manage to get your patches through ?
<sneek>Will do.
<mroh>jsynacek: this has been added/fixed a week ago, see commit 9d0b9c7c6c from ludo. so you might try to recreate the vm with a recent checkout.
<jsynacek>mroh: Thanks for the pointers.
<raghavgururajan>jonsger Icedove in guix? o.O
<pinoaffe>is there a way to set up an authenticated mpd server in guix? (preferably without putting the password in the system conf :) )
<rekado>you can run arbitrary code in a system configuration, including commands that would look up the password at reconfigure time.
<rekado>you’d still end up with a password in the store, though, unless mpd has a way to save just a hash.
<pinoaffe>right, but I don't see an option for a password in the docs: https://guix.gnu.org/manual/en/html_node/Audio-Services.html
<jsynacek>Running 'guix environment guile' doesn't set up autoconf, automake and probably more tools needed to actually build guile from git. Is that a bug or am I misunderstanding something?
<rekado>jsynacek: since the “guile” package in Guix does not have autoconf, automake, etc as inputs (because it’s building from a release tarball) “guix environment guile” also won’t give you these tools.
<rekado>you can add them with “--ad-hoc autoconf automake libtool”
<jsynacek>rekado: Oh, I missed that. Thank you for the clarification.
<raghavgururajan>Folks! What build-system should I use for https://sourceforge.net/p/diffuse/code/HEAD/tree/tags/release-0.4.8/.
<raghavgururajan>I tried python-buid-system, but setup.py is missing.
<guix-vits>raghavgururajan: replace or remove 'build ?
<guix-vits>and 'install, heh. copy-build-system?
<guixer>Hi Guix! I am trying to reconfigure my system. When building zutils, the process fails because of failed tests. Does anybody know how can I either fix this or how I exclude zutils from the reconfiguration?
<bricewge>guixer: There are several way of doing this. Try to install it in your user profile and remove it from the system profile
<bricewge>Or you could create a zutils package with “#:tests? #f”
<bricewge>The best would be to fix the package and submit a patch for every user to enjoy
<bricewge>Guix, is there a simple procedure to put a local file in the store in a directory?
<bricewge>I'm trying to put a custom EDID file into /lib/firmware.
<guixer>bricewge: Thanks. I'll go for the user profile path for now to move on. But I'll look into it if I run into build errors again.
<guix-vits>..though copy-build system will not care about all that PYTHONPATH things
<pinoaffe>I want to add support for passwords to the mpd-configuration record, should I add a new mpd-password record?
<pinoaffe> https://linux.die.net/man/5/mpd.conf < mpd allows you to specify multiple passwords, each with their own set of permissions
<pinoaffe>alternatively, I could just make a passwords entry in the mpd-configuration record that takes a list of strings of the format hunter12@read,add
<pinoaffe>and why are port numbers often specified as strings in guix configs? just for ease of further processing, or is there something else I'm missing
<str1ngs>pinoaffe: probably because they are saved as strings. there is need for int types in that case.
<str1ngs>if I have your context right.
<str1ngs>you could use ints but the you would have to convert to string anyways so it's kinda pointless.
<str1ngs>no need*
<rekado>the new reproducibility problems with R 4.0.0 stem from encoding inconsistencies.
<rekado>building the package twice I see that one produces UTF-8 encoded files and the other uses ASCII.
<rekado>the problem becomes worse when running (setlocale LC_ALL "en_US.utf8") (setenv "LC_ALL" "en_US.utf8") before the build phase.
<rekado>7.8T free on ci.guix.gnu.org after continuous manual intervention to clean out garbage
<bricewge>rekado: Looks like a Sisyphus task
<bricewge>Thank you for keeping ci.guix.gnu.org afloat.
<Blackbeard>Hi
<Blackbeard>apteryx awesome :)
<bricewge>o/
<mbakke>janneke: do you remember what the problem with building libstdc++ from GCC 7 in (gnu packages make-bootstrap) was? ref commit 25bc0f34c6c059394f546f29a203c2cb9b7cdcf6
<mbakke>I'd like to extract out package-with-relocatable-glibc and gcc-static, and would rather avoid "hard coding" GCC 5.
<mbakke>it can be parameterized of course if it is really necessary for bootstrap, but I'd like to provide a comment for future reference in that case
<pinoaffe>does someone know a sensible name other than "users" for a list of password/permission pairs?
<rekado>credentials?
<pinoaffe>that sounds good, thanks!
<dlowe>street-cred
***Guest80763 is now known as benny
<efraim>vdirsyncer failing on core-updates
<cbaines>Seems like berlin could be having offloading issues http://ci.guix.gnu.org/jobset/guix-master
<cbaines>A few of the failure messages mention timeouts or "corrupt input while restoring archive"
<lfam>mbakke: Is it still possible to update tzdata in this core-updates cycle?
<sneek>Welcome back lfam, you have 1 message!
<sneek>lfam, raghavgururajan says: Any update regarding #40659 (v3) please? Thanks!
<NieDzejkob>Huh, I can't find the thing about gnu/local.mk containing the list of files anywhere in the contributing manual.
<lfam>raghavgururajan: I still don't think it's a good idea to add icons as dependencies unless the program can't find them in the user's profile. We don't want icon changes to trigger rebuilds of packages
<NieDzejkob>(also, why is that necessary? Wouldn't it be simpler to generate it on the fly with find or something?)
<mbakke>lfam: preferably not! it would set back the branch by a couple of weeks
<mbakke>I hope to merge it in a few days, then we can start rolling the staging branch again
<lfam>mbakke: It would take a couple weeks to rebuild the affected packages?
<mbakke>lfam: on armhf and aarch64, yes
<lfam>Wow
<lfam>I didn't know that
<lfam>Okay!
<lfam>NieDzejkob: I think the Contributing section is intended as a "getting started" guide or a high-level introduction. Those can come out in the code review process
<lfam>Ultimately it's intended to get patches in the queue
<vagrantc>ouch, tzdata updates has a lot of dependents?
<lfam>I looked into making tzdata changes more lightweight, mbakke, but it's a tricky problem due to libical and how it works
<mbakke>lfam: even with the upstream patch?
<lfam>I intend to keep working on it but it won't be an easy solution
<lfam>Yes
<vagrantc>tzdata is one of those packages where you'd *think* it wouldn't need to be updated vrey often, and yet...
<lfam>It actually should be updated upstream more than it is
<lfam>Even if we updated instantly, people all over the world would still have incorrect clocks
<vagrantc>right
<lfam>It's just a really complicated problem
<vagrantc>that suggests there's something wrong in the world :)
<lfam>In the past, before standardized time zones, clocks would be different in towns that were only miles apart, by a few minutes
<vagrantc>that timezones change so often...
<lfam>I disagree :)
<lfam>Timezones are already quite heavy-handed
<vagrantc>indeed.
<lfam>I think it was better in the past but industry demanded that life mold itself to business
<lfam>Oh well!
*vagrantc nods
<lfam>I notice a go-build-system commit on staging. So far I've been doing Go stuff on master since there are still not many Go packages
<efraim>does anyone know of a way to add a package to a manifest but specify a different system?
<efraim>i'm trying to add syncthing for armhf-linux when the manifest is run on aarch64
<mbakke>I have a 'guile-static' based on Guile 3 for use in the initrd on core-updates, but am facing circular module dependencies if I put the package definition in (gnu packages guile), because it uses 'package-with-relocatable-glibc' from (gnu packages make-bootstrap) with depends on (gnu packages guile).
<mbakke>I tried moving 'package-with-relocatable-glibc' into (gnu packages base), but that just moves the circular dependency to a different module
<mbakke>I wonder if there is a better place for this special 'guile-static' variant
<kraai>Hi. I've tried to install via the instructions in the Binary Installation chapter and Application Setup chapter on top of Debian 10 Buster, but the locales don't seem to work.
<lfam>kraai: Hi, in what way aren't they working?
<kraai>I've installed glibc-utf8-locales and set GUIX_LOCPATH to $HOME/.guix-profile/lib/locale.
<kraai>lfam: `guix package -I` outputs `guile: warning: failed to install locale`, for example.
<mbakke>efraim: perhaps (parameterize ((%current-system "armhf-linux") (list syncthing))) ?
<lfam>kraai: We'll also need to make sure locales are setup correctly for the guix-daemon. Can you share the systemd service file for the guix-daemon on <https://paste.debian.net>?
<lfam>kraai: Also, what is the result of `realpath $HOME/.guix-profile/lib/locale`?
<kraai> https://paste.debian.net/1143181
<kraai>realpath produces /gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29/lib/locale
<lfam>kraai: Try removing the "LC_ALL=en_US.utf8" part from the Environment line of guix-daemon.service, and then as root, `systemctl daemon-reload && systemctl restart guix-daemon`
<lfam>Also, kraai, make sure that '/var/guix/profiles/per-user/root/guix-profile/lib/locale' does contain the locales. That's root's Guix profile
<efraim>it didn't like my dangling if statement to drop git-annex from aarch64
<kraai> /var/guix/profiles/per-user/root/guix-profile/lib/locale doesn't exist.
<lfam>kraai: Okay, you can either install the locales for the root user, or change that path to point to your own user's locales
<bricewge>lfam: I have merged wireguard-linux-module with wireguard-linux-compat as you requested at https://issues.guix.info/issue/40683
<lfam>Thanks bricewge!
<bricewge>Using it, we end up with /run/current-system/kernel/wireguard.patch
<kraai>I ran `guix package -i glibc-utf8-locales` as root and it seemed to be successful.
<kraai> /var/guix/profiles/per-user/root/guix-profile/lib/locale now exists.
<bricewge>lfam: Is there a better path to put it? Or the root of the package is good enough?
<kraai>I restarted to make sure the service file was reloaded.
<lfam>bricewge: It shouldn't end up there
<kraai>`guix package -I` still prints the same warning.
<lfam>kraai: Did you reload as well kraai?
<lfam>And remove the part I suggested you remove?
<lfam>bricewge: I would put it in its own output
<kraai>I removed 'LC_ALL=en_US.utf8' from the service file.
<bricewge>Of course! I forgot about outputs.
<bricewge>lfam: Is patch output for the patch correct and out for the module correct?
<kraai>lfam: I also ran 'sudo systemctl daemon-reload && sudo systemctl restart guix-daemon'
<lfam>Yeah, it used to be in a 'kernel-patch' output when there was only one wireguard package
<lfam>I think 'kernel-patch' is good
<bricewge>Will do, thanks.
<lfam>kraai: Okay, to summarize, both users have the locales installed, your user has GUIX_LOCPATH set correctly, you reloaded and restarted the guix-daemon, and your user has logged out and back in?
<kraai>Yes to all of those.
<lfam>And what locale do you intend to use
<lfam>?
<kraai>en_US.utf8, I guess.
<lfam>Hm
<kraai>I don't really care.
<lfam>Maybe try restoring that LC_ALL bit to the systemd service file, reload and restart the service again?
<kraai>lfam: OK, will do.
<lfam>It's not clear to me when that part is necessary. Sometimes things break with it, sometimes without it
<lfam>Beyond that, it should all work
<lfam>And if it doesn't please send a bug report
<lfam>This locales issue is a long-standing UI problem that we have slowly been chipping away at
<janneke>is avahi-daemon working for you? I get: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!; avahi-daemon[9680]: Failed to acquire D-Bus name 'org.freedesktop.Avahi'; exiting
<sneek>Welcome back janneke, you have 1 message!
<sneek>janneke, raghavgururajan says: Regarding #40753, I accidentally sent the wrong patch that missed some things. So sorry. I have send another patch to the email thread to append the previous commit. Could you please push it as new commit. Thanks!
<kraai>lfam: I restored the LC_ALL setting in the service file and ran 'sudo systemctl daemon-reload && sudo systemctl restart guix-daemon'. When I run `guix package -I`, it still produces the same warning.
<kraai>:(
<kraai>I'll file a bug report.
<kraai>lfam: Thanks for your help.
<lfam>Okay, thanks. Sorry it's such a pain
<lfam>In any case, everything should still work. It's just a warning
*vagrantc waves to kraai
*apteryx buying a 5 GHz adapter for my desktop has been the most worthwhile investment as of late. Everything is zippy again.
<mbakke>kraai: did you install guix 1.1.0? or is the daemon older, using a different glibc?
<vagrantc>kraai: presuming you're running on a debian-ish system, i've packaged guix 1.1.0 and it more-or-less works: https://salsa.debian.org/vagrant/guix
<vagrantc>kraai: needs a bit more work before trying to upload to Debian
<vagrantc>needs some test suite fixes and a "bit" of copyright review ... but otherwise good to go
<apteryx>nckx: I just noticed, my middle click button seems generally finnicky, which explains the pasting issues I've had (I just realized when attempting to middle click on links in Icecat). Now wondering whether it's hardware or not.
<guix-ci>Problem: Too many processes on hydra-guix-119 Problem started at 20:37:03 on 2020.04.26
<jonsger>apteryx: but it requires non-free firmware or?
<lfam>jonsger: There are some dual-band wifi chips that use free software
<lfam>From places like Think Penguin
<lfam>I think even when limited to 802.11n, 5 GHz is just faster due to lower congestion
<guix-ci>Resolved: Too many processes on hydra-guix-119 Problem has been resolved at 20:41:03 on 2020.04.26
<lfam>The free software movement really needs free 802.11ac drivers though. It will be a huge problem for adoption in the future
<jonsger>lfam: I'm with you
<jonsger>lfam: https://github.com/open-sdr/openwifi is the most promising approach I'm aware. In that direction
<apteryx>jonsger: its firmware is free!
<lfam>Could it be adapted to existing hardware jonsger? Or is it just for SDRs?
<jonsger>yes but its not ac
<lfam>I think we need drivers for "normal" wifi, like in laptops
<jonsger>lfam: I talked to them at FOSDEM. ATM its only for FPGAs (starting at 800$) but in the longterm they wanna built an ASIC
<apteryx>no, it's wifi N. Currently connected at a speed of 216 Mb/s to my AP.
<apteryx>jonsger: 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network Adapter (PCI-Express) (rev 01)
<apteryx>jonsger: it's this one: https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-dual-band-pcie-card-gnu-linux-tpe-n300pcied23-w-full-low-profile-bracke
<jonsger>apteryx: I know
<lfam>Eventually these old Atheros cards will not be acceptable to the masses
<jonsger>yes
<dissoc3>so i just tried to write my first guix service but it failed. is there a workflow for this that allows the use of the geiser repl?
<cbaines>dissoc3, I often use a system test, in combination with guix system vm for debugging.
<cbaines>What service are you writing, and what failure are you seeing?
<apteryx>Perhaps the industry will loosen their grip on AC (in the form of releasing firmware sources) after it starts to decay and they've moved their focus to the newer, better thing that'll come. Or not.
<apteryx>anyway, sorry for the OT disgression.
<lfam>I hope so apteryx, especially since I don't see any interest from free software hackers in writing drivers
<dissoc3>cbaines: i'll have to look into that. im pretty new
<dissoc3>cbaines: im writing a service for zerotier vpn. I get an unbound variable error but i'm not really sure why
<cbaines>Ok, when do you see the error?
<janneke>hmm, after restarting dbus-system, avahi-daemon starts
<pinoaffe>is "how to contribute to documentation" documented somewhere?
<dissoc3>cbaines: when I reconfigure system. I push to channel repo. guix pull, and then system reconfigure and that's the point that it fails. But if I load the service buffer there are no unbound variables (at least i think)
<cbaines>dissoc3, are you trying to define this service your own channel, or within the guix Git repository?
<dissoc3>cbaines: error: exception caught while executing 'eval' on service 'root'
<dissoc3>cbaines: in my own channel for now
<kraai>mbakke: 1.1.0.
<cbaines>dissoc3, first I'd figure out a way to run guix system build on your system, without having to git push and guix pull. If the files for your channel are on your GUILE_LOAD_PATH, then it should work.
<kraai>vagrantc: Great!
<dissoc3>cbaines: haha yeah. i've been thinking there has to be a better way
<dissoc3>im just so close to getting it to work. it has been a bit of a battle
<kraai>Is there an AWS AMI for Guix?
<cbaines>kraai, there is some stuff on creating one here https://github.com/ofosos/guix-packer
<kraai>cbaines: Thanks!
<kmicu>[Jokin’] Always nice to see some nice Guix reviews https://invidious.13ad.de/watch?v=IKsXecNJ_nE Fortunately in Deutch so no one will watch it 😺
<jonsger>kmicu: good that I understand. Will notice all issues he's mentioning
<apteryx>Blackbeard: pushed hackneyed-x11-cursors as b58a22e5b7
<kmicu>Fortunately I forgot all 12 years of learning German. ;) ‘Deutch ist daine chance fur bessere Zukunft’ they said.
<kmicu>(They should teach me Esperanto instead. We can use Guix System in Esperanto. That’s useful.)
<Blackbeard>apteryx: wonderful :D
<terpri>guix is certainly the #1 gnu/linux distro when it comes to esperanto support :D
<mroh>that video is funny, ty for sharing (and the invidious instance). we should make this guy a config.scm ;)
<pinoaffe>kmicu: he's reviewing it the way one would review ubuntu
***kraai_ is now known as kraai
<jlicht>I feel so much empathy for the poor guy when he notices the "| less" thing
<ruffni>there's no ack in packages?
<civodul>jlicht: hey, honoring $PAGER has been proposed, let's do that!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, raghavgururajan says: Would you be able to push #40785 please? This is regarding `guix edit` and nano. Thanks!
<civodul>raghavgururajan: sure, i'll take a look, thanks!
<civodul>(unless someone beats me at it :-))
<jlicht>civodul: I'm a happy camper ever since INSIDE_EMACS has been honored, I just recognised the "where is my output?" -> "oh there is a hint here" -> "oh it does the thing I wanted"
<efraim>hmm, the copyright in the man page for vdirsyncer says 2014-1970
<jonsger>hm, diffoscope gets killed when comparing two icedove builds
<drakonis>does guix support lojban?
<drakonis>kraai: i dont think there might be an AWS AMI
<drakonis>seems like it runs against the principles of the whole thing
<drakonis>there is guix deploy though
<drakonis>and if you look at the mailing lists, there is someone who has done such a thing
<ruffni>is there no guile3.0 package?
<lfam>I don't think we need to block creating an AMI
<ruffni>also: doesn't guix 1.1 run on guile3?
<lfam>ruffini: It's named 'guile-next'
<lfam>Sometimes we use this naming scheme when we don't want people who've installed Guile (for example, Guile 2.2), to get the new version from `guix upgrade`
<lfam>Usually because we don't think it's ready yet
*pinoaffe posted a file: audio.scm (8KB) < https://pixie.town/_matrix/media/r0/download/pixie.town/amTyZTdOQwjUtqslcyVHbLxa >
<pinoaffe>whoops
<ruffni>makes sense :) thanks for clearing that up
<ruffni>wait... not ready yet? guile3?
<lfam>I don't know the details of this case :)
<lfam>It usually takes a couple bug-fix releases to get new major versions of Guile ready for automatic deployment
<mekeor>hello. :) i'd like to understand what makes gnu guile so special and why it's nice and possible to configure gnu guix in guile and how they are parsed and what it means that package- and configuration-declarations are just scheme-expressions and whether the "eval" function is relevant to this. is there a text explaining this? :)
<ruffni>i'm just curious because the speed advantage was mentioned in the release notes..
<lfam>ruffni: Guix 1.1 is based on Guile 3
<lfam>But it doesn't mean that the Guile you might install for your own use matches what Guix is based on
<ruffni>makes sense. like git is installed -> for the system <- but not for a user to execute, right? unless it's added to the system
<ruffni>mekeor: "Structure and Interpretation of Computer Programs" is what answered most of your questions for me
<mekeor>ruffni: the book from 1985? :O omg i thought an article might be enough… xD
<jonsger>Its awful to work with debbugs, I hope the search of isssues.guix.gnu.org will be working soon again...
<bandali>jonsger, do you use emacs?
<jonsger>bandali: no
<bandali>okay. if you did, i would've said the Debbugs package makes dealing with debbugs considerably more pleasant
<sammich>bandali: is there an emacs debuggs interface?
<lfam>If you have some specific issues I might have advice, jonsger
<jonsger>lfam: ?
<lfam>About using debbugs
<bandali>sammich, there is an emacs-debbugs package
<bandali>it's available on GNU ELPA as debbugs, and packaged in guix
<sammich>hot effin dog
<jlicht>bandali: any tips/scripts on magically applying debbugs patch series to fresh guix git worktrees? :-)
<vagrantc>efraim: nice regarding the curious manpage dates ... sounds like something that might respect SOURCE_DATE_EPOCH and the author is using the build date assuming it's in the future
<cbaines>jlicht, if Patchwork https://patchwork.cbaines.net/ processed the emails successfully, it might have been applied to a branch in the guix-patches repository I have
<efraim>i was fixing building the man pages on core-updates and I saw the copyright was basically 2014-$(date +%Y)
<vagrantc>efraim: auto-generating copyright assertions from the build time has always seemed wrong to me
<efraim>yeah, i'm pretty sure that's not how it works
<vagrantc>you can build softwre without modifying it at a later date, doesn't *actually* change the year of the copyright
<cbaines>jlicht, I do something like this in Mu4e https://octodon.social/@cwebber/102355534187718966
<vagrantc>there are a lot of projects that do that ...
<bandali>jlicht, if you use Gnus, you can hit | on a message to pipe the message into something, namely a git subcommand to apply the patch
<jlicht>thanks cbaines, bandali; I do something similar already in notmuch right now (also bound on "
<jlicht>|
<bandali>i'm pretty sure the | key works in the emacs-debbugs buffers too, since iirc it makes use of some gnus machinery behindt the scenes
<bandali>right
<bandali>cheers
<bandali>jlicht, if you use notmuch, you can define a git alias like:
<bandali>nmam = "!f() { notmuch show --format=raw $1 | git am -; }; f"
<bandali>and use that from the terminal
<jlicht>the link between patch series (and later on possible v2, v3...) is a bit of a hassle to manually manage. Take the rust-based packages that usually include like 100+ patches
<cbaines>For Hartmut's latest series of 94 patches, the stuff I setup managed to generate a branch with those patches applied: https://git.cbaines.net/guix/patches/log/?h=series-3683&qt=range&q=base-for-series-3683..series-3683
<cbaines>I assume it's worked correctly (although all kinds of things can go wrong with trying to extract patches from email)
<jlicht>cbaines: this is _exactly_ what I would love, but locally
<bandali>jlicht, btw, that git alias trick for notmuch is courtesy of bremner, the notmuch maintainer
<jlicht>thanks bandali, I think it'll make applying patches from the ML a bit less of a hassle
<bandali>jlicht, cheers :-)
<civodul>cbaines: neat!
<NieDzejkob><lfam> I notice a go-build-system commit on staging. So far I've been doing Go stuff on master since there are still not many Go packages </lfam> I decided to push it to staging since the package that requires it is still blocked on upstream licensing issues
<NieDzejkob>so there was no incentive to push directly to master
<lfam>Okay
<bricewge>lfam: I have send v4 of #40683 with the proper output.
*jonsger makes the night of the bugs :P
<lfam>bricewge: I replied with a small revision. Can you make sure it still works for you?
<leoprikler>Does zimoun hang out in IRC or do they only post to the MLs?
***leomd is now known as leomd_
<bandali>leoprikler, i've seen them around, but not in the last couple of weeks
<leoprikler>hmm, okay
<bricewge>lfam: It's good with me!
<guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 23:49:16 on 2020.04.26