IRC channel logs


back to list of logs

<rekado>I just finished adding support for submitting issue comments on
<rekado>Will deploy this tomorrow.
<mbakke>mfg: right, I don't know how to do that, though it's probably possible
<mbakke>rekado: woah! and they will get sent to debbugs?
<mbakke>it would be neat if modify-services could delete services by name
<NieDzejkob>What syntax would you suggest for that?
<rekado>mbakke: yes
<mbakke>rekado: awesome :-)
*rekado —> zzzZ
<mbakke>NieDzejkob: good question, did not think that far
<noobly>i think my problem may have something to do with network manager, how do i stop this process permanently on guix?
<NieDzejkob>noobly: you could do `herd stop networking'
<noobly>NieDzeejkob, that killed it, thanks so much
<noobly>crossing my fingers that my problem was as simple as that
<mbakke>oh my, what happened with cross-libc on 'master'? merge conflict galore!
<mbakke>oh, commit 524a4e357cd71566841aaf405e8548fa3600b11b happened.
<noobly>NieDzejkob: looks like that did it, i owe ya one
<janneke>sneek: later tell civodul: see drafts, please edit+release if you like.
<janneke>sneek: botsnack
<vagrantc>even the bots are treated nicely around here :)
<ngz>I encounter a problem during the validate-runpath phase of a program. Build fails because a library cannot be found in RUNPATH. Yet, I added $out/lib to CMAKE_INSTALL_RPATH. Any idea about what could go wrong?
<mbakke>ngz: is the missing library present in $out/lib?
<noobly>i try to build a package but get 'no code for module (gnu packages rust-apps), how do I remedy this? rust-apps is not a package
<ngz>mbakke: It is present in the failed build directory (I built it with -K), under "lib/".
<ngz>noobly: Add #:use-modules (gnu packages rust-apps) at the top of the file, in `define-module'.
<ngz>err #:use-module
<mbakke>ngz: try grepping for RPATH in the CMakeLists.txt's, perhaps the package ignores the configure flag
<noobly>ngz, it is indeed there, my bad for not specifying. it still returns that error
<noobly>it's with a long list of other use-modules, it just gets hung up on that one
<mbakke>noobly: try deleting gnu/packages/rust-apps.go
<mbakke>noobly: you building from a git checkout, right?
<noobly>mbakke, i'm trying to build this:, i was having wifi problems earlier so i didn't clone it, just literally copied and pasted into my own local file. i'll try deleting rust-apps.go, thx
<noobly>don't laugh but i only have gnu/store, not gnu/packages
<mbakke>noobly: how are you building the package?
<noobly>`guix package --install-from-file=firefox.scm`
<mbakke>noobly: what is your 'guix --version'?
<noobly>mbakke, 1.0.1. thanks for the help
<mbakke>noobly: you'll need to 'guix pull' then, (gnu packages rust-apps) was added December last year
<noobly>ahh ok thanks so much!
<ngz>mbakke: hmm. The missing libraries appear in $out/lib/OGRE, not in "out/lib". There's "-DCMAKE_INSTALL_RPATH=" out "/lib/OGRE", but it seems to be ignored.
<mbakke>ngz: you can separate multiple entries for CMAKE_INSTALL_RPATH with ";" - not sure if that helps if it ignores the argument though
<ngz>As I see, it does set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/${OGRE_LIB_DIRECTORY}"). This basically means "la, la, la, I don' hear you".
<Parra>civodul: I've tried and it rebuilds, it always does that I don't know why
<mbakke>ngz: heh, indeed
<ngz>So, I probably need to do force the substitution right into the CMakeLists.txt file
<mbakke>ngz: or delete the line from CMakeLists.txt
<ngz>What will happen?
<mbakke>ngz: you will be able to pass -DCMAKE_INSTALL_RPATH in #:configure-flags instead
<ngz>hmmm ok. Let's try that.
<ngz>mbakke: Build process at 90%, we're soon going to know if you're great... or not ;)
<Veera>Hi Guix
<ngz>Hello Veera
<ngz>mbakke: OK. You're great.
<mbakke>ngz: lol, yay :P
<Veera>ngz: Hi
<mbakke>so I've merged master into core-updates, but a test in tests/packages.scm fails, not great :-/
<mbakke>will wait for civodul's opinion before pushing, probably should not be merging branches after midnight anyway :P
<lfam>Good work mbakke, I'm trying it on my systems now
<lfam>I think there are some spurious build failures on berlin, mbakke
<lfam>This builds fine for me:
***wxie1 is now known as wxie
<mbakke>lfam: there are thousands, most apparently due to timeouts on the sqlite db lock
***wxie1 is now known as wxie
<apteryx>rekado_: I'm a bit confused that the nfs client asks for statd to be running (on the client).
<apteryx>it says: mount.nfs: rpc.statd is not running but is required for remote locking. Either use '-o nolock' to keep locks local, or start statd.
<apteryx>There doesn't seem to be a way to start just statd?
<pkill9>so the core-updates mailing list message about what's new says that it will mean guix runs natively on the Hurd. Does this mean we will be able to replace the kernel with the Hurd?
<pkill9>or is it changes that make it technically possible, but implementation still needs to be worked out?
<xelxebar>brendyyn: Unfortunately, no, I did not save the error message. I have the irc logs, so at the very least could share the single line I previously sent here.
<apteryx>pkill9: you'll be able to run guix on the hurd natively. Lots of packages will need to be ported to make the ecosystem more useful.
<apteryx>(but given that debian has more than 75% of its package collection building for Hurd, we'll get there)
<pkill9>what kind of packages will need porting?
<apteryx>everything that needs patches to build. Could be IceCat. Could be Emacs. Could be anything, really :-)
<apteryx>rekado_: the quick and dirty thing to do would be to run the whole nfs-service on the client as well. Ideally we should be able te extract rpc.statd to stat that alone. I'll put a note on my todo.
<brendyyn>xelxebar: we both had the same error though right? we might of just had two problems coincidently at the same time
<xelxebar>It's possible. You did mention that you were getting the same error though...
<xelxebar>Just a sec, I will do a pull now and see what happens
<raghavgururajan>Hello Guix!
<Blackbeard>raghavgururajan: hi :D
<xelxebar>brendyyn: unfortunately(?), guix pull Just Worked this time
<xelxebar>Wish I could help you more. Are you trying to figure out the root cause?
<brendyyn>xelxebar: can you check `sudo dmesg'. Are there any suspicious looking errors in there?
<brendyyn>or warnings
<xelxebar>grepping for the obvious strings doesn't turn up anything suspicious
***wxie1 is now known as wxie
<xelxebar>Only something about urandom ratelimiting and pcspkr driver already being registered
<brendyyn>oh ok
<apteryx>rekado_: herd invalidate nscd is a good trick in the times we're in. Couldn't we make it more lenient by default, to flag a host as "invalid"?
<raghavgururajan>apteryx Before hacking on tests for belle-sip/mediastreamer, shall we try to finish off the linphoneqt? :-)
<GuixGuy>Greetings, I see that Linux-Libre-5.6.2 is in Guix-Master but it doesn't pulldown with guix pull?
<brendyyn>GuixGuy: it has not yet been set to the default. in gnu/packages/linux.scm you can see the line (define-public linux-libre linux-libre-5.4)
<vagrantc>GuixGuy: yeah, there are only a small number of linux-libre packages using 5.6.2 so far
<GuixGuy>Thank you guys
<brendyyn>i have set it manually and build and reconfigured with the 5.6.2 kernel already. you can either wait or you can set it in your operating system definition. i haven't tested it but you should be able do something like (kernel linux-libre-5.6)
<GuixGuy>I'll give it a go
<vagrantc>There are patches to switch the defaults
<rekado_>sneek: later tell apteryx We should add a separate statd service then. Hard to test this because server and client are the same in the system test.
<vagrantc>brendyyn: i did just disable the borked linux-libre-5.6 packages that it was accidentally building
<vagrantc>oh, i should update the patchset with that change
<brendyyn>although there are other things like linux-libre-headers that need to be set too
<vagrantc>will it pull in the wrong headers?
<GuixGuy>How do you apply a patch?
*vagrantc had kind of assumed setting the default wouldn't build all the variants
<brendyyn>why is it that the kernel is 5.4, but the headers are 4.19.56?
<vagrantc>the headers are generally backwards compatible but not necessarily forwards-compatible
<vagrantc>so building against old headers is usually fine, but vice-vera could have issues
<brendyyn>you mean forwards compatible but not backwards compatible? *headspin*
<vagrantc>depends on which direction you're looking from :)
<vagrantc>from the thing using the headers vs. the thing providing them
<vagrantc>hopefull will get some more feedback about switching to 5.6.x soon
<vagrantc>and help reviewing the configs
<vagrantc>GuixGuy: as for applying patches, see the guix manual ...are you familiar with git?
<brendyyn>GuixGuy: you would need to clone the git repo then download the patch from 40190 into the repo, use git to apply it, then build the git repo. then you can reconfiugre with ./pre-inst-env guix ...
<GuixGuy>I see. I started using git about a week ago so I will check out the manual for further info
<GuixGuy>Thanks again guys
<vagrantc>really relieved to find the RTC issue with rockchip systems (veyron-speedy/pinebook-pro)
<brendyyn>ive been running on 5.6 and so far nothings gone wrong, and my webcam works now that was broken before 5.5
<vagrantc>that's good to hear
<vagrantc>brendyyn: what did you use for a kernel configuration?
<brendyyn>i just applied the patch on the mailing list and changed nothing
<noobly>so after running guix pull, I'm now getting a `guile: warning: failed to install locale'. any idea where to look next?
<vagrantc>brendyyn: feel free to chime in about it on the bug, i guess :)
<brendyyn>vagrantc: is it useful if I simply mention it's working for me?
<raghavgururajan>sneek, later tell apteryx: For linphoneqt testing, please use new patch v7.
<vagrantc>brendyyn: even better if you mentioned that it fixed your webcam :)
<vagrantc>i dunno.
<lfam>noobly: It will go away after you upgrade everything
<noobly>lfam: sorry, but do you hav a command in mind?
<lfam>Upgrade your installed packages, upgrade the guix-daemon, and upgrade and reconfigure if you are using Guix System
<noobly>i thq
<noobly>lfam: Yes I'm using guix system. I was wrongly under the impression guix pull upgraded everything - is there a command that just upgrades all my packages and daemons?
<apteryx>rekado_: nevermind about statd being required on a client. There was a ridiculous amount of confusion going on, due to me moving a WiFi USB adapter to a different machine and my AP being configured to set the IP of that machine based on the MAC address of that adapter. Phew. Everything works perfect. Thanks a ton for the nfs-service-type!
<sneek>Welcome back apteryx, you have 2 messages!
<sneek>apteryx, rekado_ says: We should add a separate statd service then. Hard to test this because server and client are the same in the system test.
<sneek>apteryx, raghavgururajan says: For linphoneqt testing, please use new patch v7.
<lfam>noobly: To upgrade the packages your user has installed, use `guix upgrade`. To upgrade the system, including the daemon, do `guix pull && guix system reconfigure /etc/config.scm && reboot` as root
*apteryx zzzz
<rekado_>apteryx: ah, good to know!
<noobly>lfam, thanks! running the guix system reconfigure command now as root, hopefully hat upgrades and clears up the locale issue
<lfam>Make sure you `guix pull` as root or run the reconfigure command with `sudo -E`
<lfam>Otherwise it won't actually upgrade you
<noobly>lfam, oh shoot. i ran guix pull with normal permissions originally, I'll rerun it now
<noobly>on second thought i think i'll just do the sudo -E reconfiguration, thanks for the help
*jsoo finally has startx without display manager
<jsoo>i learned something about services. though i think i could still use some more knowledge.
<jsoo>what does the compute field of a service-extension mean?
<xelxebar>How can I figure out what object in the store /etc/config.scm comes from?
<xelxebar>(simple-service 'config-file etc-service-type `(("config.scm" ,this-file)))
<xelxebar>Or better yet, where should I look to figure out what this line in config.scm is doing?
<jsoo> what do you mean xelxebar?
<jsoo>does /etc/config.scm contain your system definition?
<xelxebar>Yes. And it also contains that simple-service line. /etc starts out empty and gets populated somehow, I'm trying to figure out what copies the config to /etc/config.scm and where in the store the original object is.
<xelxebar>Well, the "what" is sort of answered by that simple-service line. I'm just trying to find out where the original is
<jsoo>have you tried guix system list-generations xelxebar ?
<jsoo>that will tell you which configuration a generation was built from
<jsoo>and that will indeed be in the store
<xelxebar>Um.. perhaps that came out jumbled. The guixsd vm and iso images contain empty /etc directories by default; however, after booting /etc/config.scm exists, thanks to that simple-service line above.
<xelxebar>jsoo: Nice. That looks exactly like what I want. Thanks
<jsoo>i think there's a file in /run/current-system that also points to the current
<xelxebar>Still getting a hang of the basic ropes here
<jsoo>that's a cool idea to add the current config as a skeleton of sorts into a vm xelxebar.
<jsoo>xelxebar: you can follow the link in /run/booted-system/configuration.scm and that should have your current configuration
<xelxebar>jsoo: What about for a non-booted system?
<xelxebar>Perhaps I could point guix to a mount point or something?
<xelxebar>Yeah, I'm trying to hang together all the pieces to make a guixsd Google Compute instance.
<jsoo>there is also /run/current-system/configuration.scm
<jsoo>those will i think always be there
<xelxebar>Hrm. /run is empty though
<jsoo>i see. in the vm?
<xelxebar>In the iso image
<xelxebar>Typically, /run is populated post-boot
<jsoo>gotcha. well i probably don't understand that bit of running guix well enough to say. hopefully the guix system commands can help you out enough.
<xelxebar>No worries, thanks for the pointers so far
<jsoo>+1 good luck!
<xelxebar>Okay, here's another one, are there moral equivalents to dpkg-query -L and dpkg-query -S, i.e. I'd like to find out what files (outputs?) a package provides as well as do a reverse search on these.
<xelxebar>In particular, I am trying to figure out what packages lets one do 'herd start cow-store'
<Veera>xelxebar: dpkg -L :: guix package --list-installed=pkgname; find /gnu/store/shown/path
<xelxebar>Veera: Oh right, dpkg-query -S only looks in installed packages. I want to look for a package which provides something yet to be installed
<Veera>xelxebar: I do not know of way for that. Using Guix for a month
<Veera>xelxebar: you can git clone the guix.git repo from savannah. It has all the available current pkg definitions in it
<Veera>read info pages of guix
<Veera>Contribution section
<xelxebar>Thanks for the pointers, Veera
<efraim>I think you're thinking of apt-file
<vagrantc>xelxebar: there's not really a way to search files, unless guix data service has implemented them
<vagrantc>not seeing anything obvious exposed at
<xelxebar>vagrantc: Hrm. So say you want the ip command and don't know that it comes from the iproute2 package, is there a standard recourse?
<vagrantc>some guesswork and asking around
<xelxebar>Hehe. Fair enough.
<vagrantc>i have sometimes done ls /gnu/store/*/*bin/NAME with good luck
<vagrantc>for system things, it's sometimes already installed in the system profiles but not exposed to the user ... or possibly a build dependency of something i built earlier
<vagrantc>xelxebar: there was definitely talk of integrating it into the guix data service, but not sure if that worked out
<vagrantc>i also sometimes look at what it's installed with in debian systems i have to narrow down the guessing, as things are *usually* similarly named
<xelxebar>Okay, so the current state of affairs is that we need to use an a somewhat ad hoc collection of intelligent guessing and searching around
<xelxebar>That data service link you shared, not sure what I'm looking at. Is this a summary of the substitute builds?
<vagrantc>amoung other things
<vagrantc>there are regular posts about it from cbaines on the guix-devel mailing list
<str1ngs>it's not an easy problem to solve, definitely can only be don with guix infrastructure
<xelxebar>Thanks for the clear and on point info, btw.
<vagrantc>you basically have to build all the substitutes and then index them ... and each generation might result in different results
<vagrantc>and not everything always finishes building, etc.
<vagrantc>maybe the current substitutes aren't matching what you're running...
<vagrantc>your version is N commits behind or ahead ...
<str1ngs>maybe if there was an indexer that went thorugh the gzip lzip cache.
<brendyyn>i think it doesnt need to be so technically correct. just scan and dump the data into some guix-packages-meta-data package and use that updated monthly or so for suggestions
<vagrantc>though it seems something worth doing for each "release" ... and a lot of those files won't change
<vagrantc>brendyyn: yeah...
<brendyyn>i might work on it
<vagrantc>it would be a nice feature
<brendyyn>too many ideas in my head thoug ;)
<rekado_>we could run this on
<rekado_>as an addition to guix publish.
<xelxebar>void linux solves a similar problem with their xlocate utility. They have a special repo ( with a bunch of files of the form pkgname-version that each get populated with the build outputs.
<vagrantc>the difference is probably the sheer number of outputs
<xelxebar>populated with the *paths* of the build outputs
<xelxebar>Hrm, that repo has ~11k files in it, corresponding to that number of packages.
<xelxebar>Is that an order of magnitude less than the amount of substitutes available?
<xelxebar>The xlocate utility simply git greps through those files to find the path one wants
<xelxebar>Not that this exact design is what guix wants, but it's an amazingly straightforward solution for the void case
<vagrantc>because packages are rebuilt whenever it's dependencies change, that means a given upstream version of a piece of software may have an arbitrary number of builds
<xelxebar>Meaning that there's no reasonable sense of a global linear order, i.e. no way of choosing a "newest" build and just indexing the output paths on that?
<brendyyn>there is, thats the master branch
<vagrantc>but it's not immediately obvious what the order is ... to get the linear order you would have to build each and every commit and track the differences, because there's no incrementing version
<vagrantc>you almost have to know the answer to know what question to ask :)
<xelxebar>Well, practically speaking we just want 'guix package --find-file=bin/foo' to return 'baz-9.9' or whatever will get installed with 'guix install baz'
<vagrantc>a database that just periodically gets updated would probably be sufficient to ask "what packages have had bin/foo ever"
<vagrantc>or in a recent history, or whatever
<vagrantc>wouldn't have to be perfect, just good enough
<xelxebar>Hrm, waving hands naively, my first idea would be to have the substitute builds have a post-build hook that feeds some (commit, pkg, ver, {paths}) tuple-thing to whatever database you want.
<vagrantc>well, if you include the full paths, that embeds the package name and version ... though getting the commit out of it again might be an adventure
<vagrantc>the full paths also include the file paths, obviously
<str1ngs>aye package name is implied in the path
<brendyyn>'guix build emacs' only takes 1.5 seconds for me after emacs is already build. so for 10,000 packages thats 4 hours to scan through everything. thats starting from scratch. only 10 minutes or so if say 500 packages have been updated and the rest is cached.
<vagrantc>usually ... although there are some things in /gnu/store that aren't obviously tied to a specific package
<rekado_>instead of scanning we can compute this information when generating the (cached) narinfo files.
<vagrantc>for package in $(guix package -A ) ; do find -type f $(guix build package) ; done
<rekado_>some other process could then index the narinfos.
<rekado_>the only difficulty is that this is a centralized service. So far all of Guix works the same whether it’s run locally or on the build farm.
<vagrantc>successfully built /gnu/store/zpg0xicxynsqpcx64vg3gky32fd58bbm-linux-libre-pinebook-pro-5.6.0.drv !!!
*xelxebar high fives vagrantc
<vagrantc>rekado_: could build a package updated periodically that's shipped in guix itself ... and it's only as outdated as the last time the package was updated
<vagrantc>presuming this database is manageable in size
<brendyyn>i thought that this could be not used as a dynamic service but treated as a package. we release some think like guix-package-data version 2020-04, and that is an input to some bash completion package or GUI package manager
<brendyyn>update that once a month, not a big deal if its a bit wrong sometimes
<vagrantc>brendyyn: right
<vagrantc>rekado_: so the centralized service could produce the data set ... and if someone wanted to produce the dataset independently, presumably it woudl be possible
<brendyyn>it can be defined with a guix inferior to remain stable for a time?
<vagrantc>e.g. build all thepackages you want indexed ...
<rekado_>it would be unfortunate to have a package that doesn’t correspond to the currently used version of Guix.
<vagrantc>already have that for guix itself
<rekado_>“guix search”, for example, doesn’t ever return anything that isn’t available with the currently used version of Guix.
<brendyyn>such a package would depend on every other package in the entirety of guix
<brendyyn>and there are always failing packages, so it must compromise at some point.
<rekado_>brendyyn: not if it just packages up data that was produced on
<vagrantc>it seems like there are two options ... you cache some potentially stale data, or you use a centralized networked service ...
<rekado_>but that doesn’t look like a good solution
<rekado_>I wouldn’t want to have to install package databases for different build farms.
<rekado_>that would give much more emphasis to the particular build farm servers
<rekado_>right now we can just swap out substitute servers and nobody would notice a difference
<rekado_>so that guix sub-command should talk to the selected substitute servers and get info directly from there, for the current variant of Guix.
<vagrantc>and if the current variant isn't available? you get nothing?
<rekado_>we could then fall back to a previous version (and print a hint)
***rekado_ is now known as rekado
<xelxebar>Okay, I'm lost, what package provides the cow-store service?
<rekado>no package does
<xelxebar>Oh. Well that explains things
<xelxebar>Is it a custom service only on the installation iso?
<vagrantc>rekado: it seems like it could be useful to generate a partial cache from local builds / downloaded packages ...
<vagrantc>then at least, you wouldn't have to hit the substitute servers if you already had it in the store
<rekado>vagrantc: yeah, sounds good
<rekado>this needs some thought, which is probably why it hasn’t “just” been implemented.
<str1ngs> xelxebar it's only need with the install iso. so the computer does not run out of ram writing to the ramfs. I think it's ramfs
<vagrantc>tmpfs probably
<str1ngs>I always get them mixed up
<xelxebar>Well, I'm trying to do a manual installation, limited to a serial console. This means I cannot use the installation iso, so I am trying from a vm image.
<xelxebar>The first step is apparently 'herd start cow-start <mount-point>'; however, from the vm image of guixsd herd complains that it cannot find the cow-store service.
<str1ngs>xelxebar: how much space does the vm disk have?
<str1ngs>provided its not using ramfs and is a large disk you don't need cow-store.
<xelxebar>Okay. I thought it had something to do with pre-populating /mnt/gnu/store or something, but that's a misunderstanding?
<xelxebar>Yes, the image has many gigs available
<str1ngs>cow stands for copy or write. so with the installer io instead of writing to / which is ram it writes to /mnt/gnu . so it does not eat all of your ram.
<str1ngs>I vote for renaming cow-store to barn :P
<xelxebar>+100 for barn
<xelxebar>Okay, for some reason I just figured the salient part there was "writing to /mnt/gnu/store" instead of "avoid using up all your ram"
<xelxebar>Thanks for clearing that up
<str1ngs>no worries
<rekado>xelxebar: I’ve installed Guix on machines with only serial console in the past.
<str1ngs>xelxebar: it's nice to keep the VM image around will speed up if you need to init again or something.
<rekado>xelxebar: perhaps we should change the installer to output to the console as well if that’s not the case yet.
<xelxebar>I believe the installer doesn't. For whatever reason, the vm image does though.
<xelxebar>Also, grub going into fancy graphics mode caused me significant grief
<xelxebar>sorry to derail the "package from path search" discussion. seems like it was going somewhere nice
<bricewge>rekado: There was a discussion about that on the ML some month ago but it stalled
<rekado>yes, it’s a recurring theme :)
<bricewge>Should I try pushing it further then? By writing a patch maybe
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, janneke says: see drafts, please edit+release if you like.
<civodul>oh oh!
<janneke>hello civodul!
<civodul>hey janneke!
<civodul>how's everything?
<janneke>hey civodul: writing the blog post made me realise that we actually acchieved quite a bit the past week, which is nice!
<guix-ci>Problem: /etc/passwd has been changed on Zabbix server Problem started at 09:28:35 on 2020.04.06
*guix-vits Hi there (i'm "afk")
<janneke>civodul: is the draft something you can work with?
<civodul>janneke: i haven't checked yet, will do so soonish!
<civodul>i have to deal with work email and all
<guix-vits>janneke: do glitches are expected in qemu _without kvm_?
<guix-vits>*(question is about Hurd)
<janneke>guix-vits: kvm should "only" give you a significant speed-up, afaik...why would you run without kvm?
<rekado>I just reconfigured; that’s probably why guix-ci complained.
*rekado reconfigures again
<civodul>rekado: i'd like to reconfigure soon with support for the i18n web site
<guix-vits>janneke: no support for kvm (Pentium B960)
<efraim>does anyone know offhand how to change logging from user shepherd services so it displays a timestamp?
<rekado>civodul: sounds good
<rekado>civodul: I’m just reconfiguring to get the latest mumi with support for extra spam
<rekado>erm, I meant: with support for commenting on issues from the web interface
<rekado>(let’s hope the spam mitigations work well enough)
<bricewge>efraim: Logging isn't shepherd forte unfortunately...
<rekado>hmm, mitigations work too well… It’s probably the host name check.
<civodul>rekado: heh good :-)
<lprndn>hello guix!
<civodul>hi lprndn!
<civodul>efraim: yeah like bricewge wrote, the shepherd doesn't do much in terms of logging
<civodul>rekado: .186 is ENOSPC, could it be a problem with the mcron job?
<efraim>I saw in (modules shepherd) it uses default-logfile-date-format as part of logging
<efraim>it might be time to hack on shepherd finally. It doesn't have config file support yet and needs flags and it logs to .config/shepherd
*guix-vits +1 to rename cow-store to barn
<civodul>efraim: shepherd logs to syslog now
<efraim>civodul: not when run as a user. Then it logs to $XDG_CONFIG_DIR/shepherd/shepherd.log
<civodul>oh right!
<civodul>hi Veera!
<guix-ci>Resolved: /etc/passwd has been changed on Zabbix server Problem has been resolved at 10:28:35 on 2020.04.06
<rekado>civodul: I restarted .186, because it also had a wrong guix-daemon command line.
<rekado>looks fine now
<rekado>they have all been reconfigured via guix deploy recently, so mcron should be okay once restarted
<civodul>rekado: yay, thank you!
<civodul>is "guix deploy" nicer now? :-)
<civodul>it should be slightly faster and more verbose
<rekado>it is!
<rekado>(I saw lots of warnings about missing host keys. We should probably update the deploy script.)
<civodul>ah yes
<civodul>ideally that warning would only be printed once
<sulr70>Anyone know how to report bugs? Just send email to the mailinglist, right?
<rekado>sulr70: yes, send email to
<sulr70>BTW, how to find the maintainer of a certain package?
<rekado>there are no package maintainers.
<rekado>the collection is collectively maintained
*civodul reports an intriguing GCC cross-compilation failure
<civodul>roptat: guix-cookbook is not on the TP right? how is it handled?
<sulr70>rekado: Then how can I submit a new package? To the mailinglist?
<alextee[m]>wnereiz: using git send-email or format patch and send it manually
<sulr70>okay thanks
<alextee[m]>See here for examples
<dutchie> is also useful, if you aren't familiar with the email-based git workflow
<rekado>sulr70: please take a look at the Contributing section in the Guix manual.
<rekado>hmm, mailutils gives me a very rough error on
<NieDzejkob>that would've been a nice April 1st patch...
<NieDzejkob>ah, scrolled back a bit
<NieDzejkob>I was referring to -*- guix-vits +1 to rename cow-store to barn
<NieDzejkob>anyway, I just took a look at the CI status for core-updates and it looks like we're getting closer and closer :D
<y0an>hi !
<kmicu>I’m strongly opposed to the proposed patch ‘cuz cow‑store is called cowshed, barn is too general and confusing term‑it’s like referring to a monad as an endomorphism.
<kmicu>(If you accept that patch I will be forced to migrate back to Nix ‘cuz we cannot compromise on improtant stuff.)
<Parra>is there any example of copy-build-system? I can't even copy a single file with it, it says the folder is not found.
<guix-vits>Parra: see games.scm, neverball (and many more around)
*guix-vits "and aways check if `environment` has the same master volume level for the sound... it was LOUD"
<Parra>guix-vits: they replace install phase directly...
<Parra>but it's fine, I can use that
<rekado>Parra: there are a lot of packages using the copy-build-system
<rekado>six modules have examples
<Parra>in 1.0.1 master, I search for it and I can't find any use
<rekado>that’s because it was added after 1.0.1 came out.
<rekado>the master branch does have a bunch of examples.
<rekado>for contributions to Guix please work on the master branch
<Parra>how can I pull the master?
<Parra>or clone it
<rekado>Please see the manual:
***kensington_ is now known as kensington
<eric-guix>hi, all
*alextee[m] just realized we don't have LSP plugins
<Parra>rekado: thanks
<eric-guix>I'm trying to understand how to speedup my upgrade. Offload seems to solve the problem but my question is: Offload work in background building my config.scm package? Or it starts only when I launch "guix upgrade" or "guix install" ?
<rekado>eric-guix: offloading only means that builds (when requested) happen on a remote server instead of the local machine asking for the builds.
<rekado>eric-guix: are you downloading binary substitutes from
<rekado>generally you don’t often need to build anything locally because provides binaries.
<eric-guix>rekado: I'm using the default server for the binary, the problem that I want solve is the heavy cpu work for my x200 laptop when i launch "guix pull" or "guix update". Exist something that relay on a server to do the job on any git pull change
*kmicu is so happy that alextee[m] is packaging all those audio goodies. Thank you!
<rekado>eric-guix: “guix update” should fetch binaries, so it shouldn’t be expensive.
<alextee[m]>kmicu: 👍
<rekado>for “guix pull” you can also get binaries if you’re okay with fetching a slightly older version
<rekado>this can be done automatically
*alextee[m] uploaded an image: Screenshot from 2020-04-06 12-34-10.png (145KB) < >
<alextee[m]>this is what we is merged so far fyi kmicu ^
<alextee[m]>er, a couple of them are from my channel sorry
<rekado>eric-guix: see here for a channels file that fetches only that version of Guix that has already been built on
<xelxebar>Goodness gracious. Setting up a fresh guix system from scratch is too easy.
<xelxebar>guix system init is elixor from heaven
<xelxebar>All praise the devs
<xelxebar>Boundless life to the devs
<xelxebar>I'm florred that it Just Worked on the first try
<civodul>you didn't use the graphical installer?
<civodul>that too is praise-worthy ;-)
<user_oreloznog>Thanks again civodul and congrats xelxebar :)
<pkill9>xelxebar: did you run it on a foreign distro or from the installation image?
<xelxebar>pkill9: None of the above. Used the vm image.
<xelxebar>Trying to get guix running on a google compute vm and for Reasons couldn't use the installation image.
<Parra>rekado: I can't mate, I just want to unpack the zip into the output directory but it's not working
<Parra>it only copies some files, not all of them
<eric-guix>rekado: well, thanks! Now the last question. If I want the last version build from an other machine for my x200 there are some automatic background command?
<alextee[m]>Parra: is the zip you're trying to unpack the source?
<rekado>eric-guix: nothing will be built automatically unless you ask for it.
<Parra>alextee[m]: it's binaries
<Parra>it only copies the .so files but not others with another extension
<alextee[m]>Parra: does this help? in this package im fetching a tarball with binaries inside and i dump it in the output
<eric-guix>rekado: OK, and there is something to speedup "guix pull"?
<guix-vits>Parra: please post the definition (
<rekado>eric-guix: “guix pull” has one expensive operation, which is to compute the derivation. Only once that’s computed can it fetch pre-built components.
<rekado>(using the channel file I posted above)
<eric-guix>rekado: What I mean is can I use a server to do that for me "guix pull"?
<Parra>this ( )doesn't work at all, it installs a .so file only
<Parra>and there is a lot of .dll files
<civodul>janneke: nice post!
<civodul>i think we can maybe summarize the story of our sufferings :-)
<guix-vits>Parra: '(("." "shared/" #:include-regexp ("\\.dll$" ))))) -- it's work at all (maybe "share" without d)?
<civodul>janneke: i amend it a bit, let's discuss!
<Parra>if I remove include-regex it copies one so file into the output/shared directory
<Parra>if I leave the regex, it says folder not found, referring to the output folder
<janneke>civodul: please do!
*janneke is in a meeting right now
<Parra>"failed to produce output path"
<alextee[m]>anyone know how to fetch this source tarball?
<alextee[m]>i can't figure it out
<alextee[m]>using mirror://sourceforge/teliasopia/teliasopia/ <version> /DynamicMultiband- <version> .tar.gz
<alextee[m]>but i get 404
<alextee[m]>(also, why does sourceforge suck so much and why does anyone use it?)
<Parra>sourceforge does a redirect
<alextee[m]>oh you're supposed to put the username in "brought to you by"
<alextee[m]>this worked: victorpe76/teliasopia
<rekado>this also worked for me: mirror://sourceforge/teliasopia/Dynamic_Multiband_GUI/DynamicMultiband-0.0.2.tar.gz
<Parra>guix-vits: adding the .so regex works, but dll still not being copied
<Parra>I don't know why it does this random behavior
<Parra>are dll files excluded by default?
<guix-vits>Parra: idk (i'll download and poke it, though)
<alextee[m]>rekado: thanks
<alextee[m]>i get a different hash everytime...?
<civodul>janneke: i'm also building the image with from the latest & greatest wip-hurd-vm! :-)
<Parra>guix-vits: what do you mean?
<alextee[m]>oh it worked now, the previous link was giving a different hash each time
<civodul>janneke: i realized ext2fs now uses xattrs to store passive translators settings, so in a future interation, we can store them directly when we build the image, in populate-root-file-system & co.
<rekado>alextee[m]: maybe you got an HTML page
<alextee[m]>ah maybe
<janneke>civodul: oh, very nice -- that's a good step towards removing bash from the bootstrap!
<janneke>civodul: will that also work for /dev nodes?
<guix-vits>Parra: you'll need to refine it (to place LICENSE.txt somewhere in /share/doc ):
<guix-vits>(arguments '(#:install-plan '(("." "/shared"))))
<guix-vits>it simply unpack all under /gnu/store/blah-package-name/shared
<guix-vits>(though idk why do you need to distribute binaries in such a way.)
<Parra>guix-vits: the license thing is a requeriment?
<Parra>guix-vits: I've tried exactly that line and it does copy only one file, a .so file...
<Parra>have you tried it?
<reepca>Parra: I've got an idea what the problem is. So the 'unpack' phase that is used in copy-build-system is reused from gnu-build-system, where it runs "tar xvf <source>". It assumes this will produce a single directory, the unpacked source directory, and so it chdir's into the first directory it sees.
<reepca>but, having used wget to download the source myself and tried to unpack it, it exploded a bunch of directories and files into existence
<Parra>reepca: exactly
<Parra>there is a way I can handle that? should I rewrite the unpack phase?
<reepca>a tarball can have "multiple files", but this is actually distinct from being a directory containing multiple files
<reepca>it would make sense to do that, I think
<Parra>any suggestions in how to modify it?
<Parra>I mean, not the boilerplate of modifying a phase, but how exactly unpack it
<Parra>maybe forcing to unpack it into a folder? how should the folder be named?
<guix-vits>Parra: i used the line posted above and have a "/gnu/store/bzcm1gj54vlhil7fd4lbxpf6drlrkhwd-netcore-2.1.17", with all the files (under shared/).
<reepca>make a "source" directory or something, chdir into it, tar xvf $source, and that should be all that is necessary
<reepca>(where $source would be the variable bound with #:key source)
<Parra>guix-vits: including dlls?
<Parra>I will try again the guix-vits method, otherwise I will try yours reepca
<guix-vits>Parra: no dlls.
<Parra>I need the dlls guix-vits
<reepca>on my system the first-subdirectory procedure returns the "host" directory, which contains only fxr/2.1.17/
<Parra>I think you got it reepca
<Parra>I will refactor the unpack phase to move all files into source dir
<Parra>thanks for the advice
<Parra>netcore isn't bootstrappable right now, but if I can do a base package bootstrapped from cli seed binaries, eventually we will find how to build the seed client and bootstrap netcore completely
<Parra>this I'm doing right now is an intermediate solution to package netcore, although it isn't fully reproductible
<Parra>an option would be to build the seed cli with mono
<guix-vits>Parra, reepca: ''In procedure stat: No such file or directory: "host"'' -- strange (`build`).
<reepca>guix-vits: how'd ya get that message?
<guix-vits>reepca: (arguments '(#:install-plan '(("host" "/host"))))
<reepca>that would make sense, considering if the unpack phase is left as-is, then the current directory at the time of the copying doesn't have a "host" directory, as it *is* the "host" directory.
<reepca>since the unpack phase happened to pick it as the first directory it saw to chdir into, because it expects the tarball to contain a single directory, not multiple files. It actually chose it as the first directory because it's the lowest one in more-or-less alphabetical order.
<alextee[m]>is there a way to to do a regex on directories and copy them to a destination?
<alextee[m]>i know how to do it with find-files
<alextee[m]>is there an equivalent for directories?
<alextee[m]>oh i found it somewhere #:directories? #t
<guix-vits>reepca: (invoke "pwd") in 'install: /tmp/guix-build-netcore-2.1.17.drv-0/host . hm..
<reepca>guix-vits: aye, that matches up with expectations. It should work to just do (modify-phases %standard-phases (replace 'unpack (lambda (#:key source #:allow-other-keys) (invoke "tar" "xvf" source))))
<reepca>hm, I guess another way to make it work would be to "undo" the chdir from 'unpack' by specifying '(#:install-plan '("../" "shared/" #:include-regexp ("\\.dll$"))) (note the "../")
<guix-vits>reepca: i finally got it: in another tarballs, when i'm unpack them, i see a dir. thanks for the explanations
<reepca>guix-vits: 👍 glad to help
<guix-vits>Parra: ^^ ''..."undo" the chdir from 'unpack'..'' -- works.
<efraim_>Sounds like a tarbomb
<rekado>gah, mailutils errors are infuriating
<rekado>“Cannot send message”
<rekado>well duh! But why?
<reepca>it could be worse. It could just say "Segmentation Fault".
<alextee[m]>what's the regex for something NOT ending in something?
<alextee[m]>like (find-files "." "\\.so$"))
<alextee[m]>i want something NOT ending in .so
<reepca>I don't think there's a standard way to invert a regular expression, but you could use the optional PRED argument to find-files.
<reepca>oh wait, the PRED argument is the regular expression thing. Well anyway, turns out it can also be a procedure!
<alextee[m]>sounds complicated, i'll just copy the files manually :-)
<alextee[m]>there's 8 files
<eric-guix>rekado: I added the new channel that you suggest to me
<eric-guix>News for channel 'guix'
<civodul>rekado: oh that's bad, it worked pretty well for me (after i spent time setting debugging it)
<civodul>strace to the rescue? :-)
<alextee[m]>actually, this procedure is used for multiple packages so it would be nice to have a regex so i can just inherit, instead of copying the whole (arguments) thing
<eric-guix>but now if I try to do "guix install icacat" it try to use default channel instead of the new one
<civodul>janneke: i found why our /dev was all read-only, including /dev/null & co.
<reepca>alextee[m]: (find-files "." (lambda (name stat) (not (string-suffix? ".so" name)))) should do the trick
<Parra>guix-vits: can you explain what you mean with undo chdir from unpack?
<alextee[m]>reepca: thanks!
<rekado>civodul: it works fine on my machine, but on I think it might be a problem with the firewall … again.
<civodul>you must have a hot line to IT now? :-)
<rekado>I wish
<rekado>I’m lucky when they remember me.
<rekado>it has to pass through the ticket system, so way more people are involved than I’d like
<civodul>"oh not that guy again"
<Parra>ohhh, nice trick
<Parra>how I can debug this things?
<Parra>I mean it's really simple the change, but without knowing anything about how guix is doing things makes it so hard
<guix-vits>Parra: (idk) which things?
<Parra>for example seeing what guix is doing when executing a build
<Parra>I have no idea where is it located, what paths is it copying
<Parra>I don't know where is "." or similar
<Parra>they are simple things but it's really difficult to detect them
<reepca>Parra: builds take place in what is essentially a scratch directory of the form "/tmp/guix-build-<package>.drv-0
<reepca>(and that itself is inside a container)
<Parra>but I want a debugger to run it step by step and seeing what's happening in the folder at same time
<Parra>or something like that
<Parra>or a printf at least
<Parra>so I can print the variables or pwd
<rekado>sending from one of the build nodes works fine, though
<reepca>Parra: for that I'd recommend write, display, and format
<reepca>(all three are guile procedures documented in the reference manual)
<Parra>ok, thanks
<Parra>reepca: how do you debug usually?
<reepca>oh, and also, --keep-failed is nice
<reepca>it copies the scratch directory out from the container and puts it in /tmp
<Parra>when you say container you mean the jail guix does when building, right?
<reepca>Parra: a combination of old-fashioned print-statement debugging, going through the same steps manually, --keep-failed, and reading exactly what the build system phases are doing
<reepca>yep, that's what I mean
<Parra>I see
<Parra>it's still complex, because that kind of debugging works in cmake for example, which is much more limited than lisp
<Parra>but lisp is a complete fp language, we should have ways to intercept the function calls and inspect values
<Parra>I think it would improve a lot the development, and the learning curve for people like me
<reepca>part of the issue is that it's not really possible to interact with the build environment, by design (to increase reproducibility).
<Parra>well, opening a port with gdbserver in debug mode is fine, only for developers
<reepca>it'd be nice to have a build-environment-but-with-interaction-for-debugging-only, though.
<Parra>I think exposing a port for connecting with a guile debugger
<Parra>not sure if guile has debugger
<Parra>I've never coded with it before
<reepca>it can provide a REPL server over a socket
<Parra>oh no :(
<Parra>I don't like repls
<Parra>but it would be something at least
<reepca>providing convenient integration would require tweaking the generated build scripts, which could increase the differences in behavior between the build environment and the debugging environment
<Parra>I don't see how that could affect, because I don't know yet the whole architecture and Implementation of Guix
<Parra>but I think debug can be rolled back later on, and that's it
<Parra>I don't see how a debugger can modify the state, unless you manually modify the state
<Parra>if you are only stepping and seeing the variables.. shouldn't affect the
<Parra>the reproductibility at all*
<Parra>it's like logging each step of the execution of the build,that shouldn't affect the build itself
<raghavgururajan>Hello Guix!
*raghavgururajan 's darling (x200t) is back <3
<guix-vits>Hi raghavgururajan; great.
<mbakke>civodul: I did a merge of master into core-updates yesterday, but did not push it because one test is failing: "package-transitive-supported-systems, implicit inputs" from guix/packages.scm:397
<mbakke>can you have a look if I push the branch somewhere?
<mbakke>the test returns '("i686" "x86_64") when it is supposed to return all supported architectures
<mbakke>ehm I meant: actual-value: ("x86_64-linux" "i686-linux")
<anadon>I started on updating Django yesterday. It looks like that will end up being a minor project and a rather large patch. Should I be breaking it up? I think in this case it should be kept on a monolith.
<civodul>mbakke: is that a regression?
<civodul>it may be because one of the new packages on the bootstrap path has a restrictive 'supported-systems'
<mbakke>civodul: it passes on the current core-updates (I think -- haven't checked since the previous merge)
<mbakke>so I'm confused as to why it failed now
<mbakke>anadon: one patch per package update is preferrable
<anadon>mbakke: OK.
<anadon>One patch per package, but multiple patches per PR?
<mbakke>anadon: indeed
*mbakke double checks that the test passes on current core-updates
<mbakke>'git log -G supported-systems master..core-updates' dug up this commit that has a fairly unorthodox sha256:
<mbakke>ehh I meant core-updates..master in that command :)
<mbakke>I need either more or less coffee, not sure which
<mbakke>reverting it made no difference for the test though
<NieDzejkob>what is it about that sha256 that you're finding unorthodox? :P
<mbakke>NieDzejkob: the empty string on non-x86
<mbakke>for ccl-bootstrap input
<NieDzejkob>I assumed you meant "commit hash" for some reason
<NieDzejkob>Also, I've seen you're doing a lot of work with build failures on core-updates. Is there a way I could help with that? I tried looking at the logs from some failing derivations but the /log/ URL returns an empty response
<NieDzejkob>(on, for example
<mbakke>NieDzejkob: there is an ancient bug somewhere that causes logs to be truncated when the build daemon is under a lot of pressure
<mbakke>also, a huge amount of builds failed because of timeouts on the sqlite db lock
<mbakke>so the CI pages are nigh unintelligible atm :/
<mbakke>I'd like to restart the whole evaluation somehow
<mbakke>civodul: I can confirm that the test passes on current core-updates (commit a533c5a1835cbeafaf595c4474e2ce6adde7de8d)
<mbakke>so there is a regression on master somewhere that only shows up after merging to core-updates
*kmicu finds Guix mentioned in random places really pleasant
<civodul>kmicu: fun!
<pkill9>does there exist a guix setup so lightweight, you could bundle the source code with it and build it all from scratch with no substitutes?
<alextee[m]>just sent like 5ish patches for music if someone wants to review them
<janneke>civodul: o good!
<janneke>civodul: i like your edits a lot; more to the point and you add some enthousiasm
<mbakke>civodul: I tried cherry-picking some "suspicious" commits and found the culprit:
<mbakke>somehow that breaks the unrelated test, on the core-updates branch only!
*guix-vits just seen someone's "about me" on GitHub: ''Senior segfault engineer, PhD in printf debugging''
*guix-vits Their's Avatar:
*mbakke should update their profile to senior bisect engineer, PhD in code spelunking
<mbakke>civodul: hm, reverting that commit does not cause the test to pass however! and causes a new test failure, in "printer with location"
*mbakke is stumped
<mbakke>derp, not "printer with location", but "transaction-upgrade-entry, zero upgrades, propagated inputs"
<mbakke>civodul: to reproduce the issue, apply 190ddfe21e3d87719733d12fb9b5eb176125a49f and a187cc562890895ad41dfad00eb1d5c4a4b00936 on top of core-updates
<mbakke>NieDzejkob: if you want to help with core-updates, here are some failures from my TODO list: 'ruby-sqlite3', 'ecl', and 'behave'
*mbakke goes out in the sun for a bit
<mbakke>NieDzejkob: some hints, SQLite has been updated, and ecl appars to fail because of the new LibFFI
<mbakke>behave is in the Python ecosystem which has seen updates all over the place, including Python
<mbakke>oh, ruby has been updated too
<civodul>janneke: i'll push a few things to wip-hurd-vm
<civodul>problem is i can't stop
<civodul>this is addicting!
<civodul>initially i just wanted to have the pretty console up and running
<civodul>to make a nice screenshot
<str1ngs>janneke: regards to emacsy logging, I'll try to make it make it less noisy atleast.
<janneke>civodul: "you don't say" ;-)
<janneke>str1ngs: good!
<str1ngs>janneke: there are not many logging procs. I think I can just add a emacsy-log? variable. so it can be turned on and off. should not effect much code this way.
<janneke>str1ngs: okay, good. yes, i hope that most obnoxious "logging" is actually for debug purposes and should be removed at some point; only messages that are actually informational for a user must go to *Messages* i guess
<str1ngs>janneke: right, though it is useful. just not all the time
<str1ngs>janneke: let me know what you think. . I can push to wip if you are okay with this patch.
<lfam>Where are people applying the 1.1.0-pre translations? To core-updates?
<str1ngs>janneke: I plan to do more work on *Messages* as well. nomad has a weird bug were *Messages* can not be seen when added to *Messages* scratch I've been able to finally handle okay though.
<janneke>str1ngs: looks fine, thanks!
<janneke>please push
<str1ngs>janneke: great, thanks for the feedback.
<civodul>GCC 10 is the thing:
<str1ngs>janneke: also side note, split window is a hard problem to solve haha. I'm using emacsy windows in nomad now. but widgets are PITA :)
<janneke>str1ngs: sorry for not being more involved; thanks for picking this up
<janneke>str1ngs: yes; this frustrated me for a while, thinking it "should" be easier to solve
<str1ngs>janneke: no problem at all. I'm just cautious when making changes to emacsy. I'd rather have some code review.
<str1ngs>janneke: my solution is to keep only support single window instance for now. I added frame support aka emacs windows which helps.
<janneke>yes, we should really get this right; and that will take some effort
<str1ngs>my thought was to create new GtkTextView's for each new window. this is manageable. for <web-buffer> which is a custom buffer with nomad. I thought of creating a web controller that works on each buffers window. seems like alot of work though.
<Blackbeard>Hi Guix :).
<lfam>efraim: I saw you pushed another commit since yesterday / last night
<lfam>efraim: Anything changed I should know about?
<rekado>issues.* doesn’t reliably update the database because there are two processes competing for locks.
<rekado>guess I should use fibers instead.
*lfam reboots on core-updates
<lfam>Bytecode incompatibilty messages from the initrd
<lfam>Otherwise okay
<bricewge>I've send a request for help on the ML, I'm probably overlooking some basic Guix/Guile stuff. If someone has time it would be appreciated :)
<efraim_>lfam: I have some more changes, I'll go ahead and push them now
***efraim_ is now known as efraim
<lfam>Okay efraim
*lfam works on GnuTLS CVE-2020-11501
<dongcarl>Hi all, where do y'all think procedures like PACKAGE-WITH-EXTRA-PATCHES should go?
<dongcarl>It's currently in cross-base.scm
<dongcarl>But I think it probably belongs somewhere else
<dongcarl>(guix packages) perhaps?
<civodul>OTOH, until there's a more frequent need for it, it's ok to keep it local IMO
<dongcarl>civodul: I'm finding that I need it for custom patches in my manifests, and would like to make it public
<dongcarl>So that's why I wanted to find a good place for it to be exported
<civodul>dongcarl: then sure, (guix packages) sounds like the right place to me!
<dongcarl>sounds good!
<civodul>janneke: i've pushed some of what i have here to wip-hurd-vm
<civodul>we still get EACCESS messages and the console doesn't start
<civodul>i have more changes locally but they only make things worse :-)
<lfam>efraim: What have you done so far? I'm wondering where I could jump in after my current task
<lfam>mbakke: How's core-updates? There's a GnuTLS bug fix on the way...
<mbakke>civodul: another update on the failing test: commenting out the test added in makes "package-transitive-supported-systems, implicit inputs" pass!
<mbakke>lfam: core-updates is chugging along
<lfam>mbakke: Unfortunately the bug fix is in GnuTLS 3.6.13, so we'll need to apply a graft for core-updates
<mbakke>lfam: no worries
<lfam>Wow, there are really a lot of GnuTLS packages right now
<mbakke>lfam: I assume 3.6.13 can be grafted in place?
<mbakke>instead of extracting the security fix alone?
<lfam>mbakke: The version number is a different length :(
<lfam>We can do that on core-updates but not on master
<mbakke>lfam: that's OK, just call it 3.6.A or something :)
<mbakke>we'll need to adjust it on core-updates though
<lfam>That doesn't feel right
<mbakke>why not?
<lfam>I don't know, I just feel like it should reflect the upstream version number
<noobly>so I'm getting this eror: "guix package: error: cannot install non-package object: #<unspecified>", and I read that 'the problem is likely that the file doesn’t evaluate to a package object, but to #<unspecified>, so end it with ‘magic-enum’, which evaluates to a package object', but I don't know how to implement that advice, any tips?
<lfam>noobly: Put the text 'magic-enum' at the end of the file you are working on
<lfam>The last line
<lfam>Assuming your package is called magic-enum
<civodul>mbakke: commenting the test?!
<mbakke>civodul: there is some crazy side effect going on!
<mbakke>lfam: the store item name is not all that interesting IMO
<mbakke>OTOH a .A suffix signifies that it isn't a "normal" package :)
<lfam>I guess it's better to have the upstream package than some kind of patched frankenstein
<lfam>I sent my patch for review. If you make sure the use of package/inherit is correct I can revise my patch to use the upstream release
<lfam>For packages like gnutls-3.6.A, are we using define? Or define-public with hidden-package? What's the standard now?
<noobly>lfam: OH that makes sense, my package is not called magic-enum but thanks
<mbakke>lfam: I've used define-public for a while, but think that using just "define" is better, because it ensures manifests etc get the same version as package inputs
<nagamalli>Hi , Can I reach out to g_bor
<guix-vits>Hi nagamalli; idk
<mbakke>nagamalli: you can use the handy bot named sneek to leave a message for later
<mbakke>sneek: later tell nagamalli that sneek is really good at remembering messages
<sneek>Got it.
<mbakke>sneek: botsnack
<mbakke>the bot needs to be fed to prevent it from getting bored and leave
<guix-vits>sneek: later tell guix-vits "I'm so happy ot see you, you're the best"
<sneek>Will do.
*guix-vits test
<sneek>Welcome back guix-vits, you have 1 message!
<sneek>guix-vits, guix-vits says: "I'm so happy ot see you, you're the best"
*guix-vits i know how to hide from sneek, MUHAHA
***nikita`_ is now known as nikita`
<mbakke>civodul: making the new test fail by changing a version number lets "package-transitive-supported-systems, implicit inputs" pass ... I am kind of hoping my computer is going nuts, as I really don't see a relation between the two tests.
<mbakke>would be good if someone could try and reproduce the issue to confirm whether my computer has been ingesting illicit substances behind my back :P
<mbakke>lfam: can you try to cherry-pick 190ddfe21e3d87719733d12fb9b5eb176125a49f and a187cc562890895ad41dfad00eb1d5c4a4b00936 on core-updates and run 'make check TESTS=tests/packags.scm'?
<lfam>I sent a revised GnuTLS patch
***dftxbs3e_ is now known as dftxbs3e
<lfam>mbakke: The test 'package-transitive-supported-systems, implicit inputs' fails for me
<lfam>Do you want more detailed log output?
<mbakke>lfam: thanks :-/
<mbakke>civodul: ^
<mbakke>lfam: no, I have it locally :-)
<lfam>Basically, the actual value is just Intel compatible systesms
<mbakke>lfam: if you comment out the "transaction-upgrade-entry, grafts" test, does it then pass?
<lfam>Oh boy :)
<mbakke>lfam: out of curiosity, are you using Guile 2.2 or 3.0 for the test? check with './pre-inst-env guile --version' - I'm on 3.0.2 from 'core-updates'.
<lfam>It passed when I commented that test out
<lfam>This is Guile 2.2
<lfam>I can rebuild the checkout based on itself, to upgrade
<mbakke>lfam: no need, that's how I've been running it. somewhat reassuring that it occurs with Guile 2.2 and 3.0...
<mbakke>lfam: the GnuTLS patch LGTM
*mbakke goes AFK for a while
<vagrantc>wip-pinebook-pro updated with linux-libre 5.6
<janneke>vagrantc: very nice; i spend a tweet on how to continue
<vagrantc>janneke: it's still tobias schram's git repository, but rebased against 5.6.0 ... which also seems to trivially rebase on top of 5.6.2
<vagrantc>the kernel git repository is a bit huge, though ... so hrm.
<vagrantc>the patchset should apply to 5.6.x ... but it's a few hundred patches
<vagrantc>would be interesting to distribute a patchset as a tarball or something rather than including directly into guix master
<vagrantc>but adding a few hundred patches to master seems a bit ugly
<janneke>ouch, i mean: great that it works...
<lfam>vagrantc: We have examples of fetching patches at build-time from Git repos
<vagrantc>yes, it's good to see video output and battery status ... working off of pure mainline works fine for a very fancy headless machine
<vagrantc>i haven't looked too deeply
<vagrantc>lfam: like a git repository that contains patches?
<lfam>I mean, the skies the limit
<vagrantc>or extracting the patches out of a git repository?
<lfam>A git repo can be accessed as patches
<vagrantc>well, sure
<lfam>Check the qemu-patch procedure
<vagrantc>thanks :)
<lfam>Or how Bash patches are handled
<lfam>I never actually use the QEMU patches procedure. I think it's relatively fragile and obscure so it's not worth it. But for hundreds of patches, no, they shouldn't be part of the Guix codebase
<vagrantc>i see the qemu-patch procedure, but i don't see it used
<lfam>Yes, I don't use it
<lfam>Historically the QEMU repo was unstable
<lfam>Generating patches from Git is not really something that should get a hash, IMO. The hashes are liable to change and the Git hash should be sufficient
<lfam>But if you have to, you have to
<vagrantc>yeah, for stability, i'm tempted to just create my own git repository
<vagrantc>which maybe only contains the patches...
<marmulak[m]>I am installing guix in qemu now
<vagrantc>and then those patches can apply on top of linux-libre tarballs
<marmulak[m]>does guix have a stable branch
<vagrantc>but not quite wrapping my head around the examples attempting to do that sort of thing just yet
<vagrantc>so for bash, it's basically just downloading individual patches into the store?
<civodul>mbakke, lfam: can you open a bug for the failing test?
<civodul>i'll look at it soonish
<civodul>maybe it'll be fixed by them muahaha
<bgardner>Good afternoon guix! I'm getting a new error on a box during 'guix system reconfigure' after a 'guix pull' - and nothing changed in the config.scm. The fail message is "builder for `/gnu/store/...-etc.drv' failed with exit code 1 - the actual error in the log is 'ERROR: In procedure symlink:\nIn procedure symlink: File exists'
<bgardner>I do have two simple (extra-special-file ...) sections, and other guix boxes without these sections have no such error.
<civodul>bgardner: did you see the message related to rottlog in "guix pull --news"?
<civodul>could it be that?
<bgardner>I did not - let me check that, one moment
<bgardner>D'oh! That's my fault then, thank civodul
<bgardner>*thank you
*guix-vits -- "Is that cool, or aren't, that meson produces no error if it's "make check" was requested, but no tests were ever defined?"
<bgardner>civodul: Thanks again Ludovic, that was totally it - I forgot I had added rottlog to all my servers last week. Reconfigure now runs successfully again.
<nojr>hello everyone!
<nojr>what is the difference between $HOME/.guix-profile and /root/.guix-profile??
<nojr>shuold I export both?
<pkill9>nojr: you don't need to export both
<pkill9>they are guix profiles for separate users, the one int he root folder is for the root user
<pkill9>but not for the whole system, just the root user
<lfam>marmulak[m]: No, Guix doesn't have a stable branch
<lfam>The only branch we support is the master branch
<nojr>pkill9: I'm getting an error guile: warning: failed to install locale
<nojr>Im getting an error again guile: warning: failed to install locale
<nojr>I haven't seen that error since the day I installed guix (I'm on foreign distro)
<nojr>I noticed it after reading over the manual and running sudo -i guix pull then systemctl restart guix-daemon.service
<nojr>wario@wario:~$ echo $GUIX_LOCPATH
<nojr>echo $GUIX_LOCPATH returns /home/comp/.guix-profile/lib/locale
<joshuaBPMan>hey guix, I'm having trouble installing nightly via nix service type...Is it ok if I ask for help with that on this channel?
<lfam>nojr: When you upgraded root's Guix with `guix pull`, you also upgraded the guix-daemon. It's possible that the guix-daemon and your user are using incompatible versions of locales now
<lfam>Sure joshuaBPMan, although we might not be able to help much. We don't have a concept of "nightly"
<lfam>Unless I misunderstood!
<lfam>Anyways feel free to ask about anything Guix-related
<joshuaBPMan>lfam: well I feel bad about trying to install firefox-nightly...
<lfam>Oh, I wasn't sure what you meant by nightly
<joshuaBPMan>I'd prefer to use Icecat, but Icecat is basically un-useable for me. I can't get it to work reliably on mastadon or paypal.
<lfam>You should try Epiphany or ungoogled-chromium. They are both modern browsers with regular security updates
<lfam>Icecat gets security updates, too, actually
<joshuaBPMan>lfam: I have similar issues with ungoogled-chromium.
<lfam>I'm surprised to hear it doesn't work with Paypal although, tbh, I haven't tried
<lfam>What goes wrong?
<joshuaBPMan>It becomes really really laggy.
<joshuaBPMan>I have to kill Icecat after about 5 minutes of useage on any "javascript heavy" sites.
<lfam>Well, back to your original question
<lfam>You want to use Nix on your Guix system?
<joshuaBPMan>If I don't my computer locks up. Though I am hoping that my new earlyoom-service-type will help.
<lfam>Also what kind of computer are you using?
<joshuaBPMan>lfam: My actual goal is to use a decent web browser on Guix System.
<joshuaBPMan>I am using a T400. it is running libreboot.
<jonsger>joshuaBPMan: did you disabled all AddOns in Icecat?
<lfam>I see. That's a really old computer and it's going to struggle no matter what. I would make sure to use an SSD, though
<joshuaBPMan>jonsger: I disabled some.
<joshuaBPMan>lfam: I do have an SSD.
<joshuaBPMan>lfam: I'm not using it right now...
<joshuaBPMan>lfam: I am also running sway.
<joshuaBPMan>so it should be fairly resource light.
<joshuaBPMan>and that's weird. Disabling the add-ons in icecat did seem to help. A lot.
<joshuaBPMan>I am back to using mastodon with less issues.
<lfam>You might also try Epiphany. Like I said it's a modern browser engine but overall a much simpler package
<pkill9>does anyone know how to use downloaded voices with festival text-to-speech?
<joshuaBPMan>lfam: thanks. I'll try Epiphany
<efraim>Also apparently firefox now has an official flatpack
<lfam>rekado might have advice about festival, pkill9
<joshuaBPMan>efraim: that's pretty cool.
<rekado>pkill9: I do! It’s tricky.
<rekado>pkill9: here’s my ~/.festivalrc –>
<rekado>I downloaded a bunch of voices (cmu_us_axb_cg, cmu_us_ksp_cg, cmu_us_slt_arctic_hts, etc), but the hts voices don’t seem to work
<rekado>pkill9: but with this festivalrc you should be able to run “festival” and then input (SayText "hello there! How are you?") to get a very unenthusiastic greeting.
<rekado>not sure what needs to be done to get the hts voices to work
<rekado>(set! voice_default 'voice_cmu_us_rms_cg) gives you a much better sounding voice than the default kal_diphone
<rekado>there’s a more elegant way to add languages to the load path and make them available, but I didn’t get around to writing it.
<Blackbeard>rekado: I couldn't make the voices I downloaded to work either
<Blackbeard>But I was using Guix on top of parabola, so maybe now on guix system I could
<Blackbeard>Exactly that way, using the loadpath. I read the documentation and maybe that could work.
<rekado>did you get errors?
<rekado>all the other languages in my festivalrc do work for me
<joshuaBPMan>lfam: also, Firefox works just fine for me on my T400 machine when I run debian.
<joshuaBPMan>So I know that firefox would work
<rekado>(would be nice if festival used Guile instead of SIOD)
<Blackbeard>I did, but I don't remember now. But it is something I've been putting off for a while, I think I would try now
<rekado>note that some components that are needed for some voices are proprietary (or at least have unclear licenses)
<Blackbeard>rekado: ah yes, that scheme seems a bit austere
*rekado plays with festival now instead of investigating why the mumi mailer doesn’t work right on…
<joshuaBPMan>epiphany is doing the same thing. It weirdly starts lagging and slowing down sway.
<rekado>joshuaBPMan: how many tabs?
<rekado>how much free memory do you have when this happens?
<pkill9>rekado: ty, i managed to add a voice
<Blackbeard>pkill9: nice :)
<joshuaBPMan>rekado: I only have a few tabs open. Less than 5. Icecat just got weirdly laggly on me a moment ago. I only had the official GNU/Hurd wiki open for a few minutes.
<pkill9>rekado: i'd like eventually to be able to install them to a guix profile
<pkill9>i don't know if festival looks in any environment variable specified paths though
<pkill9>e.g. XDG_DATA_DIRS
<guix-vits>joshuaBPMan: can you check it with a new test-user?
<pkill9>and if the license is ok, package them in guix
<joshuaBPMan>That's the startup error I got when I open icecat in a terminal.
<joshuaBPMan>guix-vits: I probably can. I'm honestly not interested in trying that though. I'd have to reconfigure a lot of stuff to pull that off. If you can convince me that it would be worth the effort, then I might try it.
<rekado>joshuaBPMan: do you see the same behaviour when using “icecat --safe-mode”?
<joshuaBPMan>rekado: let me find out.
<rekado>pkill9: sounds good. We’d have to figure out how we want to write the site init file. Perhaps use an environment variable as a search path.
<rekado>pkill9: my rc file is pretty crappy. I just learned that you can do (require 'voices) and then use a bunch of nicer procedures to load voices.
<joshuaBPMan>that is the output of icecat --safe-mode
<rekado>pkill9: will play a little more
<rekado>joshuaBPMan: I meant: do is still go laggy?
<joshuaBPMan>rekado: well let me play around with pay pal really quickly, and we'll find out.
<rekado>feel free to send me money ;)
*civodul restarts cuirass
<joshuaBPMan>rekado: this is the only initial thing...but it seems to be a little laggy.
<joshuaBPMan>And sure I'll send you money. What's your bank account # and routing #? :)
*guix-vits / nick rekado_
<joshuaBPMan>rekado: Icecat does seem to be working a little better...
<rekado>pkill9: new ~/.festivalrc:
<rekado>joshuaBPMan: what’s your free memory? (use “free -h”)
<rekado>pkill9: we would only need to add a site file that splits FESTIVAL_VOICES_PATH (or similar) and adds each of them to voice-path before running (search-for-voices) again.
<rekado>then we could install voices via Guix and set FESTIVAL_VOICES_PATH (or whatever) as a search path on the festival package.
<joshuaBPMan>rekado: the used column says 869Mi "Free" says 1.5 Gib
<rekado>is this when icecat becomes very laggy?
<rekado>my guess is just that you simply run out of memory and then Linux tries to swap, moving memory contents to disk and from disk to memory.
<joshuaBPMan>rekado: I don't think memory is the issue. I thought that too. I have 8GB.
<joshuaBPMan>A second ago when the browser was laggy, I ran top
<joshuaBPMan>It should that I had a ton of memory available. Less than 1/3 of memory was being used.
<leoprikler>perhaps something is eating your CPU? Like a compilation or stuff like that?
*rekado tries to build hts_engine in festival
<pkill9>ah that is a lot nicer rekado :)
<pkill9>(the festivalrc you posted i mean)
<leoprikler>if it's just icecat/chromium on their own, then it might perhaps be muh big javascript website, but that should affect webkit too
<leoprikler>brb. restarting for rottlog
<joey>Hello. I am thinking of installing Guix again, but for my Thinkpad X200, I wasn't able to get the volume buttons to work nor the touchscreen. Does anyone know if there are some specific drivers that are needed for these actions?