IRC channel logs

2023-10-19.log

back to list of logs

<snape>I don't think it's good that guix-patches@gnu.org is the default, because people don't expect it
<user363627>It's unexpected for what?
<snape>I mean, if I use the wrong command (--reply-to instead of --to for example), the mail will go to guix-patches@gnu.org and open a new ticket
<snape>not really what I would expect from a simple "git send-email"
<snape>that I could even want to send to anyone else not related to the list
<mirai>you can override git configs
<snape>well I can override literally everything in guix
<user363627>I've not used git send-email often and the few times I did, I only used it to prepare the patch and sent it manually via my mailclient
<snape>I didn't know this was possible
<lilyp>Feature request for ci.guix.gnu.org: Distinguish deactivate and delete :)
<geoduck>rekado: any pointers for `guix shell -D $faied_package`, I'm also curious
<lilyp>geoduck: start from `guix build $faied_package`, it should give you a more verbose error
<nckhexen>geoduck: What kind of pointers?
<nckhexen>nutcase: /etc/guix/acl is empty and you should guix archive --authorize < some public keys if you want to use substitutes at all (you're currently not). ~/.config/guix/current/share/guix/{bordeaux,ci}.guix.gnu.org are good starters.
<mirai>Is this `map' idea for defining record-types in bulk sound? <https://paste.centos.org/view/d5da4545>
<mirai>I'd like to avoid copy-pasting the thing
<lilyp>mirai: I guess there's a reason not to alias it?
<mirai>the upstream docs have it as separate entities and the current guix service mirrors this by defining them separately
<mirai>so perhaps?
<mirai>semantically they're different things so it makes sense to me
<lilyp>you could do a (define-syntax-rule (define-listener-configuration name extra-fields ...) (define-configuration name your-fields extra-fields ...))
<mirai>haha, this is reminding me of how much I've yet to learn about scheme's syntax workings <https://paste.centos.org/view/746e0c0e>
<TehBoss>how do i make icecat not the default browser
<TehBoss>i wanna make a different browser default, and i clicked the make default button in it, but links always open in icecat anyway
<mirai>I'm suspecting that it might actually be impossible to use a plain `map' call for this kind of thing
<bienjensu>Does anyone who works with common lisp (& sbcl, sly) got it working with direnv? Would prefer not to install lisp packages into a global profile.
<mirai>it has to be something something #`(... #,@(map ...) ...) (i.e. quasisyntax trickery)
<TehBoss>bienjensu: you could ask the nix guys, they do lots of direnv things with shell.nix
<bienjensu>TehBoss: thanks for the advice, just asked on #nixos too.
<porcupirate>qiskit is licensed under Apache 2.0 and contains a part that contact someone else's computer (specifically IBM's) to have it prepare calculation results. Is it considered completely free, or does whoever intends to package it need to delete the part that contacts a someone else's computer for calculations because that's a part of the algorithm considered nonfree?
<nckhexen>If it's Apache, I don't see what the problem would be?
<porcupirate>The "cloud computing" part is in question I guess. There's a nonfree part of the algorithm, but it isn't touching the user's hardware. I figured it was worth asking even though guix already has packages with similar functionality.
<porcupirate>It could equally be compared to rust-rspotify, which seems to be completely free, or to the parts of ungoogled-chromium that are specifically ungoogled (except the end user intentionally sends a payload to someone else's black box rather than it being a built-in side-effect that cannot otherwise be so easily avoided).
<nckhexen>Yep.
<geoduck>lilyp, nckhexen: after `guix build -Kf ants.scm` fails, trying to get a shell with devel inputs like `guix shell ants` gives "error: ants: unknown package". I currently just paste in what I have for (native-inputs) onto shell like `guix shell cmake insight-toolbox ...`
<jaeme>What was the rationale for having gdm be the login manager in the %desktop-services variable?
<jaeme>Over other login managers?
<jaeme>Because I noticed that guix didnt always use gdm
<mirai>GDM works alright with both wayland and X11?
<mirai>the wayland support for SDDM is (was?) a lie
<jaeme>mirai: like launching wayland and X11 sessions?
<mirai>like the login manager actually starting in that mode
<jaeme>mirai: I thought sddm could run on wayland
<mirai>it has the option and stuff but it's non-functional
<mirai>or at least was, the last time I used it
<jaeme>I see, same here
<jaeme>I remember reading that SDDM was going to be integrated into the KDE project
<jaeme>And that they would drop X11 support in the coming years
<mirai>had me going in circles when I explicitly toggled wayland and the thing didn't wanted to cooperate
<jackhill>as I understand it, GNOME's desktop session really wants to be started from GDM while the others are more agnostic, so it makes sense so GNOME users can have a good experience too.
<jackhill>also, I think the login manager before GDM was Slim, so GDM was a less niche choice at the time.
<apteryx>lilyp: there's no delete ;-)
<lilyp>apteryx: quoi?
<hako>Zambyte: (Re: Hugo) You have to add SSL_CERT_FILE and SSL_CERT_DIR to security.exec.osEnv, here's my configuration: <https://github.com/rakino/ultrarare.space/blob/trunk/config/_default/security.toml>
<bdju>gdm caused me enough problems (with wayland, specifically) that I stopped using %desktop-services entirely. would be awesome if something else became the default, though I'm doing alright now with my current setup
<bdju>sad to see yamagi-quake2 is not playable out of the box. I guess it must need extra files added somewhere. the description mentioned support for unofficial retexturing so I thought maybe it could launch with unofficial textures kinda like xonotic
<isaneran>yeah it's meant to run the actual quake 2 files I think
<civodul>Hello Guix!
<nutcase>nckhexen: thank you, I'll try that, although I think I didn't have that warning in the past.
<futurile>morning everyone
<civodul>o/
<efraim>o/
<nutcase>nckhexen: maybe the problem appeared when my disk was full during an system reconfigure attempt
<nutcase>nckhexen: however, the message is gone now. `%default-authorized-guix-keys` are included in my `authorized-keys` of my `guix-configuration` right?
<abrenon>hi guix
<futurile>morning abrenon
<abrenon>futurile: o/
<efraim>ath9k-htc-firmware produce only firmware! I'm adjusting the package
<PotentialUser-68>hello, I just installed guix and I have encrypted my hard drive, why it takes about a minute when Im unlocking it and why I have to do this twice?
<abrenon>PotentialUser-68: one minute does indeed sound like a really long time to open and mount a ciphered hard disk
<abrenon>unsure what you mean by having to do it twice
<abrenon>do you mean that it doesn't replace the regular login phase in your Desktop Manager ?
<stikonas>PotentialUser-68: tjat
<stikonas>PotentialUser-68: that's a limitation of guix
<stikonas>PotentialUser-68: once unlocking has to be done by grub
<stikonas>and then later by Linux kernel
<stikonas>and limitation is that on guix you can't securely pass passphrase from one to another
<stikonas>at least not in a way this is normally done in other distros
<abrenon>I usually just encrypt my home, and with pam-mount I type my password only once, both to unlock the volume and enter my session
<abrenon>stikonas: interesting, what's preventing us from doing so? (what do other distros do?)
<stikonas>create a 2nd slot key for LUKS decryption, store it in initramfs and make sure chmod is not world readable
<stikonas>abrenon: in guix initramfs has to be world readable because it is it /gnu/store
<abrenon>ooooh thanks
<futurile>anyone using Hertzner or DigitalOcean as a remote host to build packages (my local laptop just isn't fast enough). Any views on a good VM provider?
<abrenon>I had no idea, they actually alter the existing keys! that sounds weird
<abrenon>no, I build everything locally (but I don't build a lot, I usually wait for substitutes to be available before upgrading)
<stikonas>not alter existing keys, you add 2 key slots during installation, one for passphrase decryption, one for automatic passwordless unlocking
<stikonas>well, at least those distros that encrypt /boot
<stikonas>a lot of them don't bother and just encrypt rootfs
<rekado>we can copy the initrd out of the store and modify the copy, on?
<rekado>*no
<gabber`>rekado: i guess the sky is your limit? but if you want to boot from that you'd need to (manually) adjust your boot medium (which can get quite hard, depending on your target/setup)
<rekado>I don’t understand. Some parts of the system installation already include modifying resources outside of the store.
<gabber`>ACTION is not sure what rekado's intentions are and probably lacks the relevant expertise
<gabber`>maybe you want to tell us what you're trying to do?
<snape>hi, how can I put `guix repl` in a shebang?
<gabber`>i think you'd shebang guile and have a (use-modules (guix)) or similar in there
<lilyp>snape: you don't. Instead use #!/bin/sh\nexec guix repl …\n!#
<snape>thx, but now emacs thinks it's a shell script
<civodul>you can add “-*- Scheme -*-” somewhere in the file to placate Emacs
<snape>well or maybe it's just a bad idea
<snape>because people don't have to use emacs
<lilyp>it's not a bad idea, it's a honking great idea
<civodul>you can also pick a file name in .scm
<lilyp>If your editor can't do emacs modelines, get yourself an editor that can :)
<snape>the file is etc/teams.scm
<snape>(^ context)
<lilyp>but teams.scm is already well running as an executable?
<snape>no because you need (git) and (guix ui)
<snape>which you may have if you use guix system
<snape>but other people don't have
<lilyp>guix shell -D guix no work?
<snape>it does, and 'guix repl' works too
<snape>better, that is
<snape>(because `guix shell -D guix`, importing git, will hide my local git send-email, whereas `guix repl` won't)
<lilyp>that should probably be reported as a bug of its own instead of trying to work around it
<lilyp>git should see all git commands on your PATH
<efraim>hmm, tried to do `guix system image --image-type=mbr-raw os-config.scm --target=powerpc-linux-gnu' and got grub for i686 as the installed grub :/
<nckhexen>nutcase: They are included after you (re)generate /etc/guix/acl with ‘guix system reconfigure’, at least.
<nckhexen>So maybe that file got emptied somehow.
<gabber`>the kernel panics: "No working init found". can i assume that the right Guile to run from kernel at startup is the one in a -guile-static-stripped store-item?
<nckhexen>geoduck: I think you're confusing ‘guix shell -D’ and ‘guix shell’. Whether foo fails to build is irrelevant to ‘guix shell -D foo’, because it never builds foo.
<gabber`>(i'm trying to get some aarch64 device to boot after $(guix system image ..) )
<nckhexen>And if you need -f for ‘guix build’, how would ‘guix shell’ know how to find ants without -f?
<snape>lilyp: GIT_EXEC_PATH belongs to the git package.  So `guix shell git` sets it and it overrides the previous value
<snape>it's not a colon separated list, it's really one value
<snape>I don't think `guix shell` makes any promise regarding the environment preservation so I don't think it's a bug
<lilyp>yeah, it's more of a bug with our packaging of git really
<snape>it preserves the environment when it can, but in this case it can't because GIT_EXEC_PATH is not a comma separated list
<lilyp>like a PATH variable not being a real search path???
<lilyp>but the fix here is simple: guix shell -D guix git:send-email
<lilyp>maybe we should document that
<lilyp>or add it to the development manifest
<snape>`guix shell git:send-email -D guix` rather
<snape>no need to pull git:send-email deps
<lilyp>possibly both
<lilyp>potato potato, you can swap it around
<lilyp>-D only affects the next item
<snape>oh, i didn't know mb
<snape>thought it was all items on the right
<snape>anyway my solution would be to prepend `guix repl` to the calling of the script
<snape>so that there is no need to add doc about it and so that it works for everyone
<lilyp>OTOH does etc/teams call git by itself?
<rekado>the static output of the protobuf package is empty
<snape>lilyp: yes, it requires (git) and (guix ui)
<lilyp>I think this is gnarlier than it needs to be and adding too much "smart" stuff has already bitten us with our current config
<snape>i agree (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66605)
<lilyp>it uses libgit, that doesn't mean it calls git
<snape>it uses guile-git yes
<snape>all this is a foreign distro issue btw
<snape>because guix system people already have more stuff in their environment
<lilyp>sure, but we should support foreign distros
<snape>indeed
<lilyp>fixing this in the config is the right place; fixing it in teams.scm directly would not be
<snape>agreed
<lilyp>I disagree with installing the config unasked still, but what can you do?
<snape>I disagree too, particularly setting guix-patches@gnu.org as the default email address is too strong IMHO, without the user knowing about it (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66618)
<snape>we are programmers, we know how to automate things, but too much unasked automation leads to weird behaviors that nobody expect
<snape>there was a recent thread on HN about git send-email and most of the crowd there was complaining about how difficult to use it was.  I was defending it, explaining how simple it was to use and configure.  But in the same time i was having this weird guile crash upon typing `git send-email`... hoping nobody would try it on a guix project
<lilyp>oh, it's just the guix project itself IIUC – other channels should not be affected
<snape>it's guix project after you type "make"
<civodul>efraim: hey! should i submit a merge request for https://issues.guix.gnu.org/66525 prior to rust-team in the end?
<efraim>I'd like to get rust-team merged, at this point I think I'm just waiting on the aarch64 builders and maybe bordeaux to build a bit more
<civodul>oh ok; from your last message, i thought you wanted to wait a bit longer after possibly changing how tests are handled
<efraim>no, it's something we can address later
<civodul>ah, good
<civodul>then i’ll rebase my stuff on top of ‘rust-team’ or ‘master’ when it’s done
<nutcase>nckhexen: yes, it looks like something went wrong during my last guix system reconfigure attempts (disk full, manual abortion due to too long compilations, etc)
<nckhexen>The failure modes around 0 bytes free aren't great.
<Zambyte>hako: Nice! adding that config file worked for me. Do you know if that file is compatible with non Guix systems also? This is a shared project I'm working on.
<geoduck>nckhexen: thanks! makes sense. I got excited I missed an ergonomic way to shell into /tmp/guix-build* w/depends for debugging
<mirai>snape: once you get used to it, git send-email can be seen as easy to use for sending (duh)
<mirai>but on the receivers side, what are they to do with it when they're not cli/email power-users?
<mirai>there's no “download attachment” or anything intuitive of the sort
<civodul>cbaines: https://qa.guix.gnu.org/issue/66573 shows 118 “blocked”; shouldn’t they be “unknown”? (apparently they’re scheduled, not failing)
<snape>mirai: the whole debate was about people sending patches more than people applying them I believe
<snape>I agree it's easy (when it works)
<mirai>I wonder if adding a section on using '--in-reply-to' to the manual would make things feel even more overwhelming to the beginner
<mirai>efraim: I think I've figured out the perl-xml-xpath issue
<gabber`>how does U-Boot set up the initrd and tell the kernel which init process to use? U-Boot seems unhappy when i try to load our initrd.cpio.gz and pass it to the `booti` command directly
<gabber`>is there some kind of magic going on within Guix where the OS definition somehow makes U-Boot use the right env vars and such? i can't find the relevant parts in guix source....
<zamfofex>Random thought: Would it be reasonable for search paths to be honored across profiles somehow? E.g. I have ‘gcc-toolchain’ installed with ‘guix home’, but then I use ‘guix shell libfoo’, but libfoo’s ‘/lib’ and ‘/include’ aren’t added to the compiler’s appropriate search paths, so I need to instead do ‘guix shell libfoo gcc-toolchain’ in order for it to work as expected.
<hako>Zambyte: It's the default value + two environment variables, I don't think there's compatibility issue. However it seems that the default value has been changed since my configuration, so the following can be used instead:
<hako>'(?i)^((HTTPS?|NO)_PROXY|PATH(EXT)?|APPDATA|TE?MP|TERM|GO\w+|(XDG_CONFIG_)?HOME|USERPROFILE|SSH_AUTH_SOCK|DISPLAY|LANG|SSL_CERT_(FILE|DIR))$'
<nckhexen>zamfofex: I think the answer is how reasonable the actual semantics & implementation turn out to be once you think through all the implications (I haven't, but if it turns out to be a mess, that's a probable no.)
<zamfofex>I guess the unfortunate thing is that I don’t think package definitions (which are what include the information about search paths) are actually kept in profiles. If they were, it should be (somewhat) trivial to use a variable like `$GUIX_PROFILES` including each profile used.
<nckhexen>gabber`: What's ‘magic’? https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/bootloader/extlinux.scm#n29
<apteryx>lilyp: it was about the deactivate vs delete for cuirass specifications in the web UI; I don't think there's a delete action yet
<apteryx>I just deactivate them when not needed and recreate them when I do
<cbaines>civodul, regarding those blocked builds, the data service doesn't have a "blocked" status for builds (it uses the Cuirass statuses still) so they remain scheduled
<cbaines>civodul, if you click on the "Scheduled" bit though, that page should show you the blocking builds
<cbaines>e.g. arpack-ng-openmpi on x86_64-linux https://data.qa.guix.gnu.org/gnu/store/d1j7g82jxq8msi2v3k722a6wsvza7s6j-arpack-ng-openmpi-3.9.0.drv
<cbaines>clicking on scheduled shows a failing build https://data.qa.guix.gnu.org/build-server/2/build?build_server_build_id=5adaaf71-161e-487a-a99d-b49c5bba0f22
<cbaines>(actually a couple of failing derivations)
<apteryx>are we able to raise a condition on the build side and reraise it on the host side?
<civodul>apteryx: “structured” conditions (records) cannot be passed around like that, so no; “key + args” conditions could, but it probably wouldn’t be helpful
<mirai>a heads-up for reported CVEs on Apache: <https://issues.guix.gnu.org/66641>
<elevenkb>ugh wireshark doesn't seem to work at all on wayland..
<elevenkb>let me try to fix this one.
<gabber`>nckhexen: magic usually is what i do not (yet) understand (:
<gabber`>elevenkb: i worked around that by capturing packets through tshark with sudo and looking at those in wireshark
<gabber`>a fix would be great, though
<elevenkb>gabber`: hmm, I can't even start wireshark with no arguments. The command `wireshark` doesn't open a window for me. Were you able to get it to open a window at least?
<elevenkb>I'm a n00b so I get my packets from tcpdump.
<gabber`>wireshark opens fine on my
<gabber`>system (i am on sway)
<elevenkb>bizzare, i too am on sway. :D
<nckhexen>Doesn't work here.
<nckhexen>Y'all sure you're not running it on Xwayland?
<nckhexen>[GUI WARNING] -- Could not find the Qt platform plugin "wayland" in ""
<nckhexen>Available platform plugins are: offscreen, vnc, minimal, minimalegl, vkkhrdisplay, linuxfb, xcb, eglfs.
<elevenkb>yep.
<elevenkb>i get that error nckhexen
<elevenkb>with a little gdb, shouldn't be too hard to fix no. even for a haskell programmer :D.
<gabber`>i guess i am on Xwayland, then
<nckhexen>Likely.
<nckhexen>You can set DISPLAY= or try the xeyes trick (if the eyes follow you inside a window, it's an X window).
<elevenkb>also maybe check in your sway config. it's probably at ~/.config/sway/config
<civodul>cbaines: thanks for explaining! since i saw “scheduled”, i assumed everything was fine and didn’t understand why they were considered “blocked”
<civodul>now i do :-)
<gabber`>EXTLINUX fails to boot: "RD image overlaps OS image (OS=0x200000..0x2910000)" -- is there a go to way i handle such a situation from within my guix/bootloader config(s)?
<hako>mirai: (Re: ToaruOS) Sorry that I didn't see the message... Interesting project! Haven't heard it before, thanks for telling me :)
<tux1c>hi all, is anybody having troubles with the cursor staying black on emacs-29.1?
<hako> <https://guix.gnu.org/en/manual/devel/en/guix.pdf> and <https://guix.gnu.org/en/manual/devel/es/guix.es.pdf> still show "404 Not Found", what happened to them?
<mirai>would be interesting to see GNU/Misaka
<hako>😆
<voroskoi>is there any particular reason for not presetting CC env variable in Guix or guix shell?
<lilyp>why should we set CC?
<voroskoi>it is quite common to refer to c compiler as cc, i have seen it many times
<voroskoi>in Makefiles and such
<nckhexen>But why should Guix set it?
<voroskoi>why not? :-)
<nckhexen>I don't think Guix is the right tool to set arbitrary user environment variables.
<nckhexen>At least not guix shell.
<podiki>....in --emulate-fhs we have a symlink /bin/cc -> gcc .....
<podiki>ACTION ducks
<nckhexen>It will make it very hard to remember which variables are voted into this whitelist and which aren't.
<nckhexen>ACTION shoots.
<podiki>to be fair, the point of emulate-fhs, as the name might suggest, is to be as un-guixy so as to look like someone else
<podiki>someone by the initials of FHS
<voroskoi>is it possible to set env variables is a manifest file?
<nckhexen>I don't think so, although you could probably hack something together with fake search-paths if you really wanted to.
<civodul>podiki: Fred, Hilton, and Sophia?
<podiki>:-)
<redacted>I'm trying to debug my certbot config in a guix vm. guix system vm <filename> runs fine, but certbot doesn't show up as a shepherd service in herd status output, and I find no sign of it in /var/log/messages.
<redacted>I expect my current config to fail – I just don't know how to see what's happening exactly.
<gabber`>redacted: would you mind sharing your configuration so we could glance over it?
<mirai>redacted: it's not supposed to
<mirai>not every service is a _shepherd_ service
<mirai>what the certbot service does is extend (i.e. add a job to) mcron
<snape>ACTION thinks the whole "service" naming is confusing for newcomers
<mirai>it is
<elevenkb>fyi for some odd wireshark4.2.0rc2 needs speexdsp to build.
<elevenkb>snape: what are some alternatives to "service" that come to mind?
<mirai>'facility' ?
<mirai>subsystem?
<elevenkb>hmm yah.
<mirai>etc., it depends on the context
<elevenkb>the first one that popped into my head is worse: syscog
<redacted>mirai AH, I see. That clears up a lot.
<redacted>Thanks
<mirai>right now 'service' is used to talk about various disparate things
<mirai>np
<apteryx>civodul: structured conditions do not have a serialized on-disk representation?
<apteryx>s/on-disk//
<apteryx>it'd be nice if they could serialize back to their source code to be re-evaluated in another context
<apteryx>there's a 'pickle' standard library in Python that can be used to serialize basic exception types for example: https://stackoverflow.com/a/49715949
<ieure>Pickle has a lot of gotchas.
<civodul>apteryx: but then that means any data structure can be forged, something worth avoiding
<civodul>in Guix, we have explicit serialization procedures where it makes sense
<civodul>that addresses additional concerns such as versioning
<civodul>but anyway, cross-stage exceptions are not obviously helpful in our context
<civodul>(Hop had done interesting things with cross-stage backtraces, but it’s a different context)
<apteryx>I think it'd allow us to have a nicer interface when there are errors on the builder side
<apteryx>we could present the error more naturally and with more details than some cryptic backtrace, hopefully
<civodul> https://inria.hal.science/hal-01580582/en briefly mentions challenges related to cross-stage debugging
<civodul>apteryx: how would the error be presented?
<apteryx>I was looking as an example as the last message in bug#42146
<apteryx>ice-9/eval.scm:387:11: In procedure eval:
<apteryx>ice-9/eval.scm:387:11: Throw to key `srfi-34' with args `(#<condition &message [message: "substit ute: install.sh: pattern failed to match: -xf"] 11aa480>)'.
<apteryx>builder for `/gnu/store/wdyzzh7rkg47hfp434w72ly9nay1yva1-mes-boot-0.22.drv' failed with exit code 1
<apteryx>I'm just thinking out loud, but I was pondering whether we could more natively expose the (guix produced error, but on the builder side) errors more natively, like:
<apteryx>error [builder]: substitute: install.sh: pattern failed to match: -xf
<apteryx>with ideally the source location from where it occurred
<civodul>apteryx: for this one, i’d add a top-level handler for the substitute call, like we did for &invoke-error
<apteryx>so exceptions thrown by Guix, whether on the builder or host side, could be handled similarly
<civodul>with the goal that the build log should be “clean”, human-readable
<apteryx>OK, I'll look at that example, thanks
<civodul>(wasn’t mirai looking into ‘substitute*’ as well?)
<apteryx>maybe? that's an old patch I've picked
<apteryx>mirai: are you? :-)
<civodul>we discussed this topic a couple of days ago i think?
<apteryx>it was here I think
<elevenkb>Hello there, do you have to compile a QT app with qtwayland so that it can link support the "wayland-egl" platform?
<mirai>apteryx: I suggested it here recently (yesterday?)
<apteryx>are you working on it?
<mirai>but that's it, I wasn't planning on digging into it (yet™)
<mirai>nay
<apteryx>ok! I've been trying to polish bug#42146 so that it can go to core-updates
<apteryx>rewriting it in a functional style and with the annotated regexp* type
<apteryx>currently in loops ^^'
<apteryx>think I've found why
<snape> https://issues.guix.gnu.org/66436
<snape>is it me or several bugs are mixed in the same thread?  I don't understand
<snape>at least 3 unrelated bugs
<apteryx>I'm running tests/build-utils.scm, and getting: actual-value: #<&compound-exception components: (#<&error> #<&origin origin: "match"> #<&message message: "no matching pattern"> #<&irritants irritants: ()> #<&exception-with-kind-and-args kind: match-error args: ("match" "no matching pattern" ())>)>
<apteryx>why is there no source location info? I'm left guessing
<apteryx>the test simply calls (guix build utils)'s substitute*
<civodul>srfi-64 test-* macros swallow exceptions, and thus you don’t get a backtrace
<civodul>one trick to see the backtrace is to lift the test out of the (test-… …) form
<civodul>(ugly trick, i admit)
<elevenkb>How can one check why a profile (such as my ~/.guix-home) depends on a certain package?
<apteryx>civodul: ah, something to fix in srfi-64, thanks
<civodul>elevenkb: you can try: guix graph --path -t references $(readlink -f ~/.guix-home) the-package
<civodul>apteryx: so far srfi-64 was taken as “read-only” because we’re downstream
<elevenkb> thanks civodul. I've managed to try something like that but i just find out that my home depends on its profile which depends on the-package. :D :p.
<civodul>ah! annoying
<apteryx>we could contribute an upstream fix then :-)
<civodul>yes, it’s just that it’s old code portable to a whole bunch of Schemes
<civodul>but sure, that’d be ideal
<civodul>elevenkb: maybe try with ~/.guix-home/activate?
<elevenkb>civodul: no path found.
<civodul>elevenkb: then again, if the package is in your profile, what else do you want to know? :-)
<apteryx>civodul: I've seen that; we can fix just the guile 3 code in a pinch
<apteryx>leave the other scheme communities to fix theirs
<elevenkb>civodul: if you must know.... wireshark is broken on wayland (doesn't launch at all).
<elevenkb>so i'm trying to install qtwayland@6 in my profile, i'm hoping that that'll get the latest development version to work....
<elevenkb>i might just rebuild it with qtwayland@6 as an input.
<apteryx>where is the 'srfi's upstream?
<apteryx>do they have a repo?
<civodul>should be reachable from srfi.schemers.org
<apteryx>since the tests/ files are not real modules, perhaps we should just use (use-modules ...) at the top? would be easier to copy paste
<civodul>why would it be easier to copy/paste?
<apteryx>in a Geiser REPL at least, if you copy paste a dummy module definition, all hell break loose
<apteryx>(it stops knowing about Guile's core definitions)
<f3n1x>heya!...while using guix-home, 'guix pull' hangs while trying to build a given package (due to lack of reources, in my old hardware) ... How can i instruct Guix not to try to build it locally but to download it ? thanks, thanks, thanks
<apteryx>civodul: hm, or maybe that's only true of C-c C-a, for some reason
<apteryx>which does ,m (test build-utils)
<apteryx>OK, I've managed to get the source location: ice-9/boot-9.scm:1676:22: In procedure raise-exception:\n Throw to key `match-error' with args `("match" "no matching pattern" ())'.
<apteryx>not super useful ^^'
<apteryx>ah, but the backtrace is
<apteryx>on ,bt
<snape>f3n1x: you can pull an older guix
<apteryx>shows that it happens in (guix build utils) in my newly introduced (match->pattern _) procedure
<snape>and check on ci.guix.gnu.org for when it was last successfully built, so to make sure you'll have substitutes
<f3n1x>snape: umh... and older guix ? don't get it
<snape>guix pull --commit=<an older commit>
<f3n1x>oh... is was thinking about, rings me a bell... , something like downloding a pre-built package, somehow ? do they call it ...'derivative' ?
<f3n1x>i might be missing some very basics here
<snape>a substitute
<f3n1x>thX, a subsititue !
<f3n1x>apparently my system tries to build them locally... rather than getting the substitute. How to reverse that ?
<f3n1x>should i reconfigure the given channels for or something like ?
<snape>well you first need to authorize them
<apteryx>civodul: would ,re work for a non-module?
<apteryx>to reload imports
<apteryx>currently I have to kill the REPL session, and paste anew the fake module def to refresh them
<snape>f3n1x: there are 2 main servers serving substitutes: ci.guix.gnu.org and bordeaux.guix.gnu.org
<f3n1x>thX, snape... trying to authorize channels for , now !
<snape>maybe you can look at https://guix.gnu.org/en/manual/devel/en/guix.html#Substitutes
<f3n1x>sure... i'm reading it now
<f3n1x>super guix doc
<snape>it's a bit annoying that /etc/guix/acl is not human readable
<snape>i'm not sure how to know who i authorized
<nckhexen>It's all human-readable here. Did something change?
<snape>compare to ~/.ssh/authorized_keys nckhexen
<nckhexen>It would be nice to be able to label entries, but there's an (IMO weak but nonzero) argument to be made that naming keys reduces security.
<nckhexen>ACTION looks.
<snape>ssh is secure
<nckhexen>It's in the same, snape.
<nckhexen>*name
<elevenkb>civodul: it turns out that wireshark works okay, it's just that my home profile conflicts with it.
<snape>yep ;)
<nckhexen>What's your point?
<elevenkb>if you install qtwayland that is.
<snape>my point is that I can't see who I authorized with guix acls
<snape>whereas I can with ssh
<nckhexen>See my reply above. ‘SSH is secure’ doesn't address that.
<snape>because of the lack of labels
<nckhexen>What's the point of the ‘tag’s anyway? Never got that.
<nckhexen>Was it supposed to serve this purpose one day?
<snape>you want to know if machine foo is authorized, you look, you search for foo
<snape>now i want to know if machine bordeaux.ci.something is authorized, I can't, at least without some extra software
<snape>I could have been able to tell the person I'm helping: plz check your ACL if you have ci and bordeaux in there
<nckhexen>The tag doesn't do any of that though.
<nckhexen>I don't see how the rest wouldn't be addressed by ‘It would be nice to be able to label entries’.
<snape>It would be nice to be able to label entries
<snape>that's all I say
<nckhexen>And I agreed. But do you know the purpose of the ‘tag’ field?
<nckhexen>Is it a ‘usage’ field or was it just intended as metadata for humans?
<apteryx>mirai: I have it working in a functional style, I'll CC you if you want?
<apteryx>(substitute* erroring on no match)
<snape>nckhexen: it's a comment
<snape>not used for anything, but convenient for the user to identify the key
<snape>this is what we miss, I believe
<nckhexen>(Well…)
<nckhexen>How is (tag (guix import)) convenient?
<snape>i'm talking about the ssh key
<nckhexen>I never was.
<nckhexen>I'm talking about Guix's ACL.
<snape>i'm comparing the guix acl to ssh authorized_keys
<snape>ssh authorized_keys has some comment humans can use to identify the key
<snape>guix ACL don't
<nckhexen>Correct.
<snape>I'm glad we understand each other
<nckhexen>I don't think we do.
<snape>I understand the word "Correct" at least
<nckhexen>Baby steps. Do you know the (intended) purpose of the tag field?
<snape>I have no clue what tag you are talking about
<nckhexen>Look at your ACL.
<snape>ok yeah, (tag (guix import
<snape>they are all the same
<nckhexen>I've never seen anything but (guix import).
<snape>indeed
<snape>Maybe your point is that the purpose of this tag is to identify the key?
<nckhexen>Honestly, my point was nothing but my original ‘It would be nice to label’ answer, before this whole SSH tangent.
<nckhexen>I'm just wondering if the tag could serve this purpose, but it seems not, it's a ‘key usage’ specifier in (guix pki), even though I don't think we ever had any other key types.
<nckhexen>‘Someday we may want to have name certificates and to use subject names instead of complete keys.’ Heh.
<snape>Well I agree with your original point
<nckhexen> https://theworld.com/~cme/spki.txt mentions a ‘name’ field.
<alxsim>seems the latest guix binary download is broken https://guix.gnu.org/en/download/latest/ any workaround to get it?
<nckhexen>Or are these ’subject’s. Sigh. This is why I drink.
<nckhexen>ACTION ☕
<f3n1x>ACTION ^^ did the sudo guix system reconfigure /etc/config.scm --substitute-urls='... AH
<apteryx>civodul, mirai I've sent a fresh series to bug#42146, without the adjustments commits that wouldn't apply cleanly
<apteryx>forgot to tag it with v2
<elevenkb> Is it posible to obtain the derivation for a guix home profile?
<nckhexen>elevenkb: If you haven't built it yet, -n. Otherwise, I don't think so, but missing -d support is arguably a bug.
<nckhexen>s/bug/unexpected unfeature/
<elevenkb>I just consult-ripgreped in /gnu/store for the right drv file.. since I could figure out the profile's output directory.
<nckhexen>I do that more often than I should.
<mirai>apteryx, civodul: re srfi-64, see <https://yhetil.org/guile-devel/0eccfb2e-c6c8-43f8-a33b-c6b3358fdd49@makinata.eu/T/#t>
<mirai>in one of the replies there's a mention of some SRFI-64 bug found & fixed by Taylan but it looks like it fell through the cracks
<mirai>this linked thread: <https://lists.nongnu.org/archive/html/guile-devel/2021-05/msg00007.html>
<elevenkb>nckhexen: if you remember that discussion about wireshark,
<elevenkb>env QT_PLUGIN_PATH=$(guix build qtwayland)/lib/qt6/plugins wireshark
<nckhexen>I, surprisingly, do.
<elevenkb>works for now.
<nckhexen>Nice.
<nckhexen>You should, if I may be so forward, open a bug report about that.
<elevenkb>hmmm.... I don't really know if this is a bug or stuff just working properly and me having a bad home configuration.
<elevenkb>tbqh.
<elevenkb>thanks for being forward though...
<nckhexen>I'm quite ignorant about Qt [packaging] but I see that qtbase(@6) has that directory and variable as a native-search-path.
<nckhexen>(The only Qt application I ever use is Linux's make xconfig…)
<nckhexen>Anyway, that implies that there's a way to make this work, although it might involve installing qtbase or something else silly directly into the profile.
<nckhexen>+ qtwayland.
<nckhexen>Guix should then make them kiss.
<ulfvonbelow>apparently iceauth switched to using xz instead of bz2, so iceauth-1.0.9.tar.bz2 can't be accessed anymore
<ulfvonbelow>also, apparently when the automatic mirror fallback reaches ftp.piotrkosoft.net, it just hangs forever
<nckhexen>The release notes do not imply that iceauth-1.0.9.tar.bz2 ever existed.
<nckhexen>Botched Guix bump?
<nckhexen> (https://www.spinics.net/lists/xorg/msg60516.html — ‘instead’.)
<ulfvonbelow>then that is rather puzzling, because somehow *someone* got an sha256 hash of it...
<nckhexen>Yeah…
<nckhexen>I wonder what I did there :)
<nckhexen>Oh, not update the hash, simples.
<ulfvonbelow>ah, yeah, the whitespace change hid it
<nckhexen>I'm often tempted to cull those ftp:// mirrors with some prejudice, although I've managed to restrain myself so far.
<nckhexen>Fixed; sorry; thanks.
<ulfvonbelow>👍
<nckhexen>This new ‘remote:’ trigger is nice but verbose.