IRC channel logs


back to list of logs

<Guest40>Is guix describe not doing what I think it is?  I think it might be looking at my current generation of ~/.guix-profile, but I've migrated entirely to guix home, so my ~/.guix-profile isn't important
<snape>ieure, sure, I replied
<ieure>snape, I can make that change, but the inconsistency is the fault of upstream, who made Git tag "59" but calls the release "59.0".
<podiki>snape ieure: yeah, git checkout of the commit (tag) would be easier
<ieure>So it will just... exist
<podiki>i see tags for 59 and 59.0
<snape>ieure, yes, I know upstream is inconsistent, but with tags we have guarantee that updating the version will be enough
<ieure>Gotcha, alright. Thankfully, both tags point to the same commit.
<Guest40>Alright, I did "guix time-machine --commit=HASH -- build qutebrowser --dry-run" on two aarch64-linux machines, and obtained two different store hashes.  How is this possible?  Isn't this the point of guix time-machine?
<hydranest>Hashes is still Guix issues as point out in FOSDEM 2020 presentation as far as i know right now
<Guest40>darn it, really?  I don't think I can recompile qtwebengine + qutebrowser on a puny 3GiB RAM device...
<ieure>Still not really like... accustomed to this world where the microcontroller for my keyboard has more computing power than the first /several/ PCs I used.
<ieure>re: "puny 3GiB"
<ieure>I mean, it is. But it ain't right.
<ieure>snape, Thanks, send in a new patch.
<Guest40>if guix time-machine isn't reliable, is there a way to force "guix home reconfigure" to use a store item I copied from another machine?
<Guest40>(via guix copy)
<Guest40>It took days to build before (and probably burned a hole in my micro-sd via swapfile writed), so I'd like to just use the version I already have
<Guest40>Maybe if I just copy the generation info from /var/guix after a guix copy, guix won't know the difference?
<Guest40>oh my god it worked
<Guest40>but also, that's really dissapointing that "guix time-machine --commit=<> -- build <>" is not consistent...
<ieure>Yeah, I agree, that's very surprising to me.
<snape>ieure, thanks to you!  pushed
<ieure>snape, Awesome, thank you!
<ieure>I've been wanting to mess with emacspeak for a while, was disappointed to find the Guix package was broken.
<Guest40>I submitted a bug report just in case...
<RavenJoad>Is there something special that needs to be done to make libdwarf be found and play nicely with other development tools? Cmake ends up finding libdwarf "-- Found LibDwarf: TRUE", but cannot find any initialization functions "Looking for dwarf_producer_init - not found". When compiling, I end up with missing symbols, like Dwarf_OOM.
<podiki>ieure or snape: reminder to close the issue :)
<podiki>oh nevermind, wasn't refreshed on my end
<podiki>ieure: actually restating. looks like v2 created a new bug number, so please close the first one
<nlongitude>anyone have a general idea of how long "herd start cow-store /mnt" ought to take? been sitting there for about 10 minutes on this machine. it's been a few years since i've installed but i thought it was more or less instant
<nlongitude>solved, i think it might have been related to the system clock. it was set to a ridiculously far away date
<nlongitude>worked after setting the clock and rebooting :)
<below_turtles_>is it possible to make guix store source code seprately from the store? I want to back up only those items
<apteryx>neat, got the test suite enabled for pkgconf
<podiki>you can't run ping from within a container? (something something permissions?)
<ieure>Savannah is horked. :(
<zamfofex>Savannah seems to be back.
<apoorv569>Is there anything wrong with this? indentation, spacing, quote position, wrong escaping? I can't see anything wrong with this..
<apoorv569>Is is commented out ATM.
<apoorv569>But as soon as I add this to my `.zprofile` file `dmenu` won't show any programs installed via `guix home`
<apoorv569>AFAIR I didn't add this code this got added, actually I didn't even had a `.zprofile` file it got auto created somehow.
<apoorv569>also `guix shell mpd` for example, I don't have `mpd` accessible inside the shell, it is in the store but I can't do `mpd`
<iyzsong>apoorv569: well, you need add '-p $HOME/.guix-home/profile' to that list for `guix home`.
<iyzsong>that `eval ...` replace PATH (and some other env) completely. or you can add `source ~/.guix-home/profile/etc/profile` after `eval ...`.
<snape>podiki: oh indeed, closed now
<snape>(the other one)
<PotentialUser-22>hi! is there a way to set the value of screen brightness during boot in guix system?
<PotentialUser-22>or just not reset it to 100% after each reboot and read the last value instead
<civodul>has anyone used a Guix Docker image with GitLab-CI?
<dariqq>does anyone else get a failing test for tests/ The log says: guix system: error: package mate@1.26.1 does not support aarch64-linux. Is mate supposed to work on aarch64?
<mange>Hey Guix! Is there an easy way to define a one-shot service that waits for a usable internet connection before running? Depending on network isn't enough, because I don't have an IP address yet. If it were a proper service I'd try to solve it service-side, but I don't know what my options are with a one-shot service.
<mange>I'm hoping for something better than "sleep for a few seconds". :)
<rekado>dariqq: it could be propagated from a dependency that isn’t available on aarch64
<rekado>mange: this is something I’ve been wanting as some sort of service modifier.
<rekado>for example, the rstudio service in guix-science needs networking, but I’d use it in a container system that only gets networking well after the system has booted
<rekado>and *then* I’d like the rstudio service to come up
<rekado>I have written a horrible workaround one shot service to accomplish this
<rekado>it’s gross
<dariqq>rekado: judging by the comment in the system the test is trying to build (gnu/system/examples/deskop.tmpl) mate should/ used-to work for non x86-64. What would be the best way to look into this?
<mange>Oh wow, that is gross. Still, something that works is better than what I have right now. Thanks for that!
<jpoiret>is there a mismatch between guix-devel-mode and what's available through dir locals in the guix repo?
<snape>mange: while ! ping -c 1 -w 1 &> /dev/null; do sleep 1; done; echo ok
<jpoiret>package/inherit isn't detected and indentation is wrong then
<jpoiret>dariqq: often it's because a dependency isn't supported, not mate itself. Probably something related to rust/librsvg
<jpoiret>although detecting which dependency isn't supported is not that easy I think
<mange>I was hoping to do something similar to that, but with shepherd managing the retries, but it turns out respawn-delay isn't used when one-shot services fail. Alas.
<snape>well, the first question: is do we want to update certificates at service activation?
<snape>and only then: how
<mange>I think we do want to call certbot to renew at startup, because it's low cost (only renews if certificates are old enough) and executes the declarative intent of the config file better.
<snape>I agree
<mange>I don't think we can do so during activation, because the system isn't "up" yet, so we need to defer it to a shepherd service of some sort.
<snape>I just ask myself, would users be surprised if certbot renews certificates before they do anything
<mange>I'm surprised that certbot *doesn't* do that when I configure it.
<snape>yes by activation I meant at startup
<dariqq>rekado: you are probably right. Seems to be a librsvg/rust issue
<sham1>The gift that keeps on giving
<snape>maybe rekado's solution is better though
<snape>i don't know
<mange>Thanks snape. I'm actually trying to make something more specific for certbot now, by checking its logs for the specific connection error. That way I'm not really checking "is the network up?", but more specifically "can certbot do what I need it to?" which is really the question I want answered.
<mange>I was using the network as a proxy for this question, but I might as well try to work out a more direct answer.
<pinoaffe>one thing that surprised me about certbot was that I couldn't have several certbot services on the same system
<pinoaffe>and that the way to manually refresh certificates was not documented
<mange>Why did you want multiple certbot services on the same system?
<snape>pinoaffe, well there's a message upon activation, saying "run renew-certificates"
<rekado>dariqq: we have a procedure that should return the correct librsvg for the given architecture
<snape>mange yeah ok sounds good
<pinoaffe>mange: IIRC it was because I hosted several sites on the same sites and wanted different domains to be associated with different email addresses on the letsencrypt side
<pinoaffe>snape: oh, I never noticed that
<pinoaffe>s/same sites/same server/
<mange>Mmm, yeah, multiple email addresses isn't really possible with the current service. Although it wouldn't be too hard to add.
<mange>Also, don't notice that message now, I'm currently trying to remove it. :P
<snape>ACTION notices he's the author of that message
<efraim>looks like there's a pandoc issue with mate
<roran>still no vkdt in the main mix?
<raghavgururajan>Hello Guix!
<roran>hello, raghavgururajan
<raghavgururajan>snape: I think you can either manually run `renew-certificates` executable in /run or /etc (or) you can configure mcron to periodically run that executable.
<Berkeley>Hello guys
<Berkeley>anyone here tested the Bcachefs ?
<Berkeley>i have 3 disks - nvme 256, ssd 240 and hd 1tb, i want install guix on all, any sugestion?
<raghavgururajan>Berkeley: You mean you want to have 3 separate instanced of Guix?
<raghavgururajan>Berkeley: I don't think bcachefs is supported in Guix yet. -->
<Berkeley>No raghavgururajan i want use all
<Berkeley>One instance of Guix on all disks :)
<Berkeley>with ZFS i can do this ... but only kernel 6.1 are supported :\
<Berkeley>GTA V Online in GUIX:D >
<Berkeley>if anyone have a good suggestion for partition scheme
<raghavgururajan>Berkeley: You could give Btrfs a try.
<Berkeley>anyone here use tor system-wide?
<raghavgururajan>I do.
<raghavgururajan>I mean I run tor as a system service.
<raghavgururajan>Any application can be configured to use it as SOCKS5 proxy.
<Berkeley>but do you run curl
<Berkeley>the results are: Your real IP or the TOR ip ?
<Berkeley>tor service ok... but torify all your system? :) all browsers? i think not....
<raghavgururajan>Can be done ...
<Berkeley>Tor like vpn on all system
<Berkeley>if you can explain me pls
<raghavgururajan>Not sure about the exact steps.
<raghavgururajan>I'll let you know I figure it out.
<Berkeley>on other distros i used tor + privoxy or iptables config for torify all
<msglm>hello there, I'm trying to submit a patch to, and I'm getting denied with "Relay access denied" as the error. First time doing a patch, i'm using git send-mail on my own self-hosted email server.
<cbaines>msglm, does it work if you send the patches elsewhere, e.g. your own email address?
<msglm>It does work, yes. I sent the patch to my own email successfully. I checked the mail log as well and I believe that gnu's servers are bouncing me. Perhaps it thinks i'm a spammer?
<jpoiret>do you have spf/dkim set up?
<msglm>yes, I have both spf and dkim. DMARC as well, if that matters.
<msglm>set up was via this script:
<ieure>msg, It's your own email server causing the problem, you'll need to fix its configuration.
<ieure>ugh, should have been to msglm
<janneke>or use the email server of your isp
<ieure>msglm, In ye olde days, you could point your email at pretty much any SMTP server and use it to send email to anyone else, and this was called "relaying." Then, spammers happened, and everyone locked down their mailservers so they'd receive mail for the domain they were responsible for, and send it for the users supposed to use it.i
<ieure>msglm, So, you getting a relay error means your mailserver doesn't realize that your email is... from you, an authorized user.
<msglm>thanks for the pointers on that, will have to update my mail server. going to see about pushing that patch once it's fixed.
<lechner>msglm / please post the SMTP headers you received with the rejection
<msglm>would the headers be on the client side or the server? it's my first time using git send-mail, and I don't know where those would be found.
<lechner>msglm / where did you read the message "Relay access denied" please?
<msglm>I found it first after attempting to send a patch via git send-mail, then I checked my mail server logs and found it there too.
<lechner>do you have a local mail-transfer agent configured?
<lechner>what is your mail server software?
<msglm>I don't have a local mail-transfer agent, I opted to just use the git configuration. my mail server uses both postfix and dovecot.
<lechner>how does git send-email get the message to postfix?
<lechner>does postfix run locally?
<msglm>I think git has a native mail sending agent? I just configured it using [sendemail].
<msglm>postfix runs on a VPS I am renting.
<jpoiret>probably git defaults to sendemail
<lechner>they are gone
<lechner>jpoiret / is sendemail in Guix?
<jpoiret>probably your favorite MTA has a sendemail alias
<jpoiret>maybe they were running on a foreign distro
<lechner>you probably mean 'sendmail'
<dariqq>i have tracked down the tests/ failure from earlier today to 994817bfdccc715dccfa96366fc286a80171a7e6 adding python-jupytext to python-scipy which makes guix system throw an error when trying to build mate for aarch64. Not sure what to do with this information though.
<podiki>civodul: oh wow! will have to read later, but that replaces/adds to our rocm packages?
<civodul>podiki: yes, it complements them, though it’s currently in a separate channel
<civodul>the goal is to merge them eventually but it seemed easier to start like this
<podiki>nice. been meaning to update our rocm packages too
<podiki>that's great news and collaboration to hear
<podiki>maybe AMD can pay some people to work on guix.... i'll take that money. or maybe in exchange for actually open firmware for their GPUs
<jpoiret>dariqq: huh, that should also be problematic for gnome then
<jpoiret>is gnome supported under aarch64 for you?
<civodul>podiki: heh why not! (for both)
<dariqq>don't know about gnome. But the tests explicitly don't use gnome for non x86-64so it is not an issue (at least for the test)
<efraim>dariqq: pull again and try it out, it should be fixed
<janneke>fellow core-updates comrades, anyone had any success running
<janneke>./pre-inst-env guix system build gnu/system/examples/bare-bones.tmpl
<msglm>annoying that the web chat keeps disconnecting me. still trying to tamper with my email system to fix it lol. wish I was using guix on it. stateful configuration is killing me!
<rekado>efraim: thanks for fixing this! I had no idea scipy is somewhere among the inputs to gnome/mate
<dariqq>efraim: thanks for the fix. The test passes now again :) .
<efraim>rekado: guix graph --path is great for things like that
<apteryx>ugh, still having "IceCat is already running, but is not responding. To use IceCat, you must first close the existing IceCat process, restart your device, or use a different profile." even after re-login in
<apteryx>when following links for outside the browser (from emacs or some document, say)
<civodul>ACTION sent an invitation to meet at Au Bon Vieux Temps
<civodul>let’s see who’s in :-)
<apteryx>sounds fun! I'll join in thoughts
<janneke>ACTION is going to make an effort, at least
<rekado>I’ll only get to Brussels on Thursday evening. Have fun!
<apteryx>re icecat problem, 'xdg-open -> JavaScript error: resource://gre/modules/XULStore.sys.mjs, line 60: Error: Can't find profile directory.
<apteryx>must be something corrupted in my profile
<apteryx>ugh, it happens even in a new profile
<apteryx>something is borked in our icecat extensions, perhaps?
<apteryx>does someone else experiment problems when: 1. icecat is already running and 2. running xdg-open '' ?
<snape>apteryx: no problem at all
<snape>but the first thing I do is removing all those builtin extensions
<snape>we should get rid of them anyway
<snape>when you think there's an UPSP extension LOL
<apteryx>snape: I have no problems with the extensions, I find them useful to control which javascript I'm exposed to
<snape>how often do you go to
<apteryx>never, but I'm sure it's a tiny thing on disk that never runs unless I would visit
<snape>yeah but it doesn't make any sense
<snape>and you seem to have a problem with the extensions
<apteryx>it's not the extensions; even from a new profile with all of them disabled, it still prints that odd XULstore.sys.mjs error
<apteryx>I'll try upgrading my profile, perhaps I got a broken icecat
<snape>that error is from icecat indeed, not from the extensions
<snape>nope, I get that error in the logs too
<snape>(and I don't have it with torbrowser, same build process)
<apteryx>then I also get some popup about icecat is already running
<snape>I don't have that popup though
<apteryx>I've deleted the lock files, rebooted, created a new profile, and it persists, so now I'm upgrading the profile and wishing for the best
<apteryx>another thing which is annoying is that having GNOME installed, Epiphany is the default browser (starts unless another browser is already running)
<apteryx>not sure how to change that
<snape>Settings -> Default Applications?
<snape>"Default Applications" is at the bottom left of the Settings window
<ieure>You can also edit ~/.config/mimeapps.list.
<apteryx>right; but that's the default applications opened by IceCat itself, no?
<apteryx>I want to tell the desktop/session that I prefer a particular browser
<snape>that's the default browser
<snape>if you change it from Epiphany to Icecat it'll use Icecat
<snape>when you run xdg-open
<apteryx>so many userapp-IceCat-85VHSZ.desktop got added by icecat itself, I presume
<apteryx>maybe each time it was asking "Make this the default browser?" in the past
<snape>the gui sets https too
<snape>and application/xhtml+xml
<apteryx>I think it was these link userapp-IceCat-XXXX.desktop links that were causing the problem
<apteryx>I've sanitized that ~/.config/mimeapps.list to use just icecat.desktop everywhere, and now xdg-open is happy
<apteryx>thank you!
<snape>alright good night!
<attila_lendvai>nckx, hi! any news on your pending trim patches? i hope your laptop is back to working order... :)
<vagrantc>simply updating a hash and version number is not really sufficient for a coypright claim, no?
<vagrantc>those are both mechanical processes, without any creative work performed ....
<sham1>iirc guix doesn't require copyright assignment
<vagrantc>that is separate to adding a copyright line in a file
<lilyp>actually, copyright assigments make this easier (you only have to bump one line)
<lilyp>as for updating version numbers and hashes IANAL, but imho you don't have to update the copyright lines for those
<apteryx>why is it useful that fold-packages find packages that are not to be exposed to users?
<apteryx>was it for the CI to build them and offer substitutes for it?
<lilyp>apteryx: I think it's because fold-packages is the back-bone of `guix search' etc. – an additional filter step would probably just waste time?
<civodul>apteryx: yes, in some cases (CI, SWH, etc.) you want to see all the packages, including those marked as “hidden”
<civodul>the default #:select? predicate ignores hidden packages
<apteryx>let's take an actual example, %pkg-config; why is it useful to expose this?
<apteryx>the comment doesn't explain why that's useful
<civodul>ACTION checks
<civodul>2013, good’ol time
<rekado>looks like gcc-cross-sans-libc-arm-none-eabi 4.9 is broken
<civodul>apteryx: that’s just because we want users to be able to run “guix install pkg-config” for instance
<rekado>it’s complaining about # include_next <stdint.h>
<apteryx>wouldn't that work with the special define-syntax'd variant we use in the code base?
<rekado>ISTR that other people have also encountered errors like that with the cross compilers recently.
<rekado>(this is part of the Axoloti patcher toolchain)
<civodul>that’s on master right?
<apteryx>civodul: OK! Why is that so? doesn't the 'pkg-config' special syntax expand to a package object? It's also public.
<civodul>apteryx: no, because (@ (gnu packages pkg-config) pkg-config) is a syntax transformer, not a package
<civodul>so ‘fold-packages’ won’t see it
<civodul>rekado: looks fine, no?
<apteryx>civodul: OK! thanks. I think I've collected all the bits needed to produce a better comment :-)
<rekado>civodul: the patcher builds fine, but when I’m using it to compile a DSP patch for the axoloti board, the toolchain barfs.
<rekado>(I was going to make some music, but I guess computers have a way of pulling me back in…)
<civodul>#include_next is brittle
<civodul>so i’d check {CROSS_,}C_INCLUDE_PATH
<civodul>maybe libc appears twice or something
<rekado>ACTION nods
<civodul>we’ve had problems before
<jpoiret>podiki: are you familiar with the zink mesa stuff?
<jpoiret>we have a failing test on c-u for mutter related to it, apparently zink can't find
<jpoiret>is it looked up via e.g. dlopen?
<jpoiret>hmmm, it seems to come from vulkan-loader, which is the library that does handle discovery of "Installable Client Drivers". It seems to me that zink should probably hardcode the libvulkan dependency then
<jpoiret>don't really understand why this is a new failure though
<jpoiret>i'm not seeing any new commits that would've touched this
<rekado>was just a bad CROSS_C_INCLUDE_PATH; it had all the architecture specific headers but not the generic ones.
<jpoiret>another day, another glibc security advisor
<apteryx>ACTION has a series that should make it very easy to migrate from pkg-config to pkgconf, if we want to
<jpoiret>have you tested it extensively?
<jpoiret>and does that resolve the .private issue?
<jpoiret>so, glibc 2.39 is supposed to release in 2 days :(, between that and just upgrading 2.38 to the latest security fix, I'm not sure if there's that big of a difference
<civodul>jpoiret: has there been a glibc security issue lately?
<jpoiret>pretty big one, local privilege escalation
<podiki>jpoiret: just that we enabled zink recently. What you say sounds familiar, was it reported before? Or maybe came up here after I merged the patch to enable zink
<jpoiret>ah, maybe it happened after master was merged into c-u then!
<civodul>jpoiret: are you coming to Brussels BTW?
<jpoiret>no, couldn't make it this time :(
<jpoiret>i have a deadline around that time
<podiki>gnome and gtk using vulkan is new?
<civodul>oh too bad
<civodul>ah Qualys
<podiki>This is all ringing some bells but not sure yet
<jpoiret>podiki: it might be through the xwayland tests only
<jpoiret>that's where mesa and friends are getting pulled in i think
<civodul>their advisories are always really good
<jpoiret>yeah, i usually don't read them through but this one was nice
<civodul>the proof of concept doesn’t work for me on Guix System
<civodul>(exec -a "`printf '%0128000x' 1`" su </dev/null)
<civodul>but maybe that’s just luck?
<jpoiret>me neither
<jpoiret>doesn't seem like our su uses syslog
<jpoiret>ah no it does, and it ends up in /var/log/secure
<PotentialUser73>Quick question about sending a patch: I'm submitting a patch using my employer provided gmail email address, which has forced 2fa and does not allow me to create app passwords for git send-email. Is there any preference on how best to generate a patch for reviewers? The documentation states "Sending patches as email attachments may make them
<PotentialUser73>difficult to review in some mail clients, and git diff does not store commit metadata." I've set my client to send the message as plaintext.
<jpoiret>maybe our PAM doesn't strictly follow the behavior in the advisory
<jpoiret>PotentialUser73: in that case, attachments should be ok. I think most tools we use do handle attachments
<PotentialUser73>jpoiret: Is an attachment preferred, or should I just paste the contents of the .patch file into the plain text message? This is just a single patch submission, so not terribly complicated
<jpoiret>through the gmail web interface, right?
<jpoiret>no, pasting the patch will almost certainly break formatting
<PotentialUser73>Ok, so I'll just set the message type to plaintext and add the .patch file as an attachment
<jpoiret>yes, that should be the safest
<PotentialUser73>Great, one last question, is this the preferred way of generating the patch in this circumstance: "git format-patch -1 HEAD"?
<PotentialUser73>I'm not sure if that differs from how git send-email would do it
<jpoiret>yes, that should be okay! I didn't know about -1 and instead always used `HEAD~` or `origin/master`
<PotentialUser73>Ok perfect, thank you for your help