# IRC channel logs

## 2022-06-30.log

back to list of logs

<mbkamble>Which package do I need to make "ldd" available on my guix system?
<lhp22>gcc doesn't need it ?
<civodul>mbkamble: it's in gcc-toolchain (it's actually part of glibc)
<mbkamble>yeah. thanks civodul. I installed glibc and got it
<nikola>What do you all think about rust in the kernel
<lhp22>Same powerness of C ? With more memory management guards ? It can't be totally wrong
<mekeor[m]>hello guix! i'm trying to build/run a rust project with cargo. i set RUSTC_BOOTSTRAP=1 and added 'cargo-features = ["edition2021"]' to the Cargo.toml. but 'cargo build' still fails with "feature edition2021 is required". what's wrong?
<mekeor[m]>wait. is this due to this issue/ticket/bug? https://issues.guix.gnu.org/54509
<mekeor[m]>i don't even know what that patch is waiting for...
<nckx>nikola: The language is a good idea, but I hope they eschew Cargo and other Rusty antipatterns. No directly externally-maintained libraries in the kernel, just like they do for C.
<mekeor[m]>it's a pity that the packaged rustc does support rust-edition2021 but the packaged rust-cargo does not
<mekeor[m]>nckx: what's wrong with cargo?
<vagrantc>mekeor[m]: infinite dependencies and no way to track them sanely?
<nckx>Because of Cargo the Rust 'ecosystem' is already an unmaintainable mess in user space today, it would be a nightmare in the kernel today. Good night Guix!
<vagrantc>using the network as a filesystem?
*vagrantc waves to nckx
<nckx>*tomorrow. Me tired. Wave back & zzz!
<mekeor[m]>vagrantc: why is there no way to track deps? they are listed in cargo.toml
*mekeor[m] realizes how ugly cargo-build-system is, regarding #:cargo-inputs
<GNUtoo>Hi, is it possible to reuse an operating-system declaration for both guix system image and guix deploy?
<GNUtoo>I was thinking of spliting it in 2 files with one being a module that export the operating system with something like (define base-server-system (operating-system [...])) and the other that use base-server-system, though for some reasons that doesn't work, do I need some special quoting for that?
<vagrantc>mekeor[m]: there are ways to track dependencies, there are too many to track practically
<mekeor[m]>GNUtoo: maybe it's with packages where you can use (define-public custom-package (package (inherit another-package)))
<mekeor[m]>GNUtoo, i.e. maybe try "inherit"?
<GNUtoo>ok, I could also try -e to see if I can evaluate part of the file
<GNUtoo>I don't really see where inherit should go though
<GNUtoo>The issue is that guix system image expect an operating system while guix deploy expect a machine
<mekeor[m]>GNUtoo: i'd try (define foo (operating-system …)) (define bar (operating-system (inherit foo) …))
<GNUtoo>ahh ok
<mekeor[m]>but no guarantees, just an idea :D
<GNUtoo>I'll try that
*mekeor[m] goes bed → zZzZ
<GNUtoo>I think I managed to do it with -e, I'll paste a link here when I'll have tested it
<whereiseveryone_>Is there a guide that shows the particularities of using erlang with guix for development?
<whereiseveryone_>Any help with that is much appreciated
<vagrantc>arg. the somewhat arbitrary formatting of Copyright lines in gnu guix ... while orders of magnitude better than many projects ... are tediuous to verify :/
<podiki[m]>the manual says: "The herd rules udev command, as root, returns the name of the directory containing all the active udev rules."
<podiki[m]>this doesn't work for me, can anyone else try?
<podiki[m]>I get: "herd: service 'udev' does not have an action 'rules'"
<acrow>pokiki: Same here regarding herd rules.
<acrow>podiki:
<podiki[m]>acrow: thanks. guess I'll report it, not sure if it is wrong in the manual or something that was removed/never implemented?
<acrow>podiki: yeah, I've fiddled with it and udev just doesn't cooperate with rules.
<podiki[m]>thanks for checking
<mlan__>Hello guix.
<lilyp>nckx: It's hard to evaluate. I certainly didn't pay any extra on top of the listed price and it was cheaper than the listed price for Windows, but still...
<lilyp>It's also about the principle. Had I wanted the Microsoft OS, I'd have specified so.
<mlan__>Hello Guix, I am a new person in this guix.
<horizoninnovatio>Good afternoon Guix. I noticed wine 7.8 is now current (website) but not with "guix search wine" even after "guix pull" Am I missing something?
<acrow>I think so bc ver 7.8 is current. Maybe you've run guix pull but then run the search in a shell that did not have the updated GUIX_PROFILE?
<horizoninnovatio><acrow> "I think so bc ver 7.8 is current..." <- Good point. I'll check.
<horizoninnovatio>* I'll check. update, still 7.0!
<horizoninnovatio>* I'll check. update, still 7.0! I'll run upgrade and see what happens.
<civodul>Hello Guix!
<mlan>Hello Dr Civodul
<mlan>Dr civodul, other using Guix source, What function?
<abrenon>hi guix
<retropikzel>How can I get "javac" command? I installed openjdk but weirdly that only gives me "java"
<maximed>retropikzel: "guix show openjdk"
<maximed>Have a look at the 'outputs' line: 'out', 'jdk' and 'doc'
<maximed>By default, you only get the 'out' output.
<maximed>But if you do "guix install openjdk:jdk" instead of "guix install openjdk:out', you get the 'jdk' output.
<maximed>('jdk': the compiler, 'out': whatever you need to actually run Java things)
<maximed>horizoninnovatio: "guix show wine" gives 7.8 here
<maximed>vagrantc: What would you like the formatting to be?
<maximed>whereiseveryone_: Is rather new, maybe see <https://issues.guix.gnu.org/54796> for context?
<retropikzel>maximed, thank you very much :)
<mlan>I not idea about guix source, test n errors
<maximed>mlan: What question do ou have?
<maximed>* ou -> you
<mlan>my question, from guix source canit be modified or just to testing system? Sorry guix I am not perfect system part of this program.
<mlan>canit --> can it
<abrenon>well as with any open source software, you can tweak the source to modify your version of guix and generate whole systems with that, but you can of course redistribute your changes as patches so that the rest of the community may benefit from your improvements
<abrenon>does that help ? I'm not sure I get the meaning of your interrogation perfectly
<abrenon>are you perhaps confused by the "source" describing a system to build and the source code of the guix package itself, allowing to alter its behaviour, the list of packages it knows, etc.
<mlan_>sometimesthere is a problem, I have no idea how to continue building this OS guix
<abrenon>ok, what kind of problem ? could you tell us when it occurs ? what are you concretely trying to achieve when you say "building this OS" ? are you installing from a live CD/USB onto a new machine ?
<horizoninnovatio><maximed> "horizoninnovations: "guix show..." <- would there a reason why "guix pull" isn't updating to show 7.8?
<maximed>horizontalinnoatio: what does 'type -P guix' say?
<horizoninnovatio>maximed: "~/.config/guix/current/bin/guix
<maximed>horizontalinnovatio: Did you run "guix pull" or "sudo guix pull"?
<maximed>You need to do the former.
<maximed>(~/.config/guix/current/bin/guix looks good though)
<horizoninnovatio>maximed: only guix pull, not sudo guix pull
<mlan__>abrenon. I try a lot to use the VM method through windows 10
<maximed>What does '~/.config/guix/current/bin/guix show wine' say?
<horizoninnovatio>I was messing in "root", so type -P guix shows: /run/current-system/profile/bin/guix
<horizoninnovatio>maximed: wine 7.0
<maximed>horizoninnovatio: Looks like ~/.config/guix/current/bin/guix is an old Guix somehow.
<maximed>$USER != root? <maximed>Also, what's the output of '~/.config/guix/current/bin/guix describe'? <horizoninnovatio>maximed: genertaion 18 "date" (current) <maximed>horizoninnovatio: full output? <maximed>(in particular, including the guix commit) <horizoninnovatio>Generation 18 Jun 30 2022 14:43:32 (current)... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/5f3fcc21ba43a848dc1f8874037c04b15525c39a) <maximed>(and the branch) <horizoninnovatio>branch: master <maximed>Is ~two month old commit somehow ... <maximed>Did you pin a commit in your list of channels? <horizoninnovatio>maximed: Unlikely as I don't know how to! <maximed>horizontinnovatio: You can copy the file$HOME/.config/guix/channels.scm (to a pasta, e.g. paste.debian.net)
<horizoninnovatio>I did a system configure yesterday
<horizoninnovatio>maximed: sure, hold on.
<maximed>horizoninnovatio: Reconfigures are orthogonal to pulling.
<maximed>It (should) not be relevant.
<NaturalNumber>Oh, I finally got Guix up and running. It feels great and what a learning experience. Most of my issues ended up having nothing to do with Guix per se. I wonder if some others might be interested in some tips or if I should let them figure it out on their own.
<maximed>NaturalNumber: Please share before you end up with stockholm like many old Guix contributors and don't recognise the issues for issues anymore.
<NaturalNumber>Of course I meant Guix System
<horizoninnovatio><maximed> "Is ~two month old commit somehow..." <- How do I update the commit?
<maximed>horizoninnovatio: You are pinning the 'guix' channel there.
<maximed>because of: (commit "c026...").
<maximed>You can simply remove that line.
<NaturalNumber>maximed: Will do! Let me organize my thoughts
<horizoninnovatio>maximed: Unlikely as I don't know how to!
<maximed>horizoninnovatio: Even if you don't know how you have pinned it, it is pinned anyway.
<maximed>(commit "...") is pinning (IIUC).
<horizoninnovatio>maximed: ok, how do I unpin it?
<maximed>You can simply remove that line.
<maximed>(in a text editor)
<horizoninnovatio>maximed: Done, thank you for your help. New commits coming in!
<fps>ok, i installed geiser and paredit from "the perfect setup"
<fps>now i'm in my config.scm in emacs and i have started geiser.. if i have the point on "operating-system" and press M-. it tells me operating-system is not found
<fps>and yes, i have a guix clone and setup the paths in .emacs for geiser
<fps>hmm, and even when i open gnu/system.scm and have the point on operating-system and press M-. it tells me the same thing
<fps>hmm, the repl tells me i'm in the module guile-user while it really should be gnu/system i suppose?
<attila_lendvai>fps, you probably need to load stuff into geiser (see the command ,m). and even if that is loaded, then config.scm is not a module, so it may still not work from there.
<fps>attila_lendvai: yeah, i went to gnu/system.scm to see if i have better success there. my last comment referred to that. will check out ,m
*attila_lendvai is not a geiser expert, though
<fps>i'm just checking out this "perfect setup" to see if it can help me at all navigating the guix source ;)
*maximed Sent an update to #53163 ‘doc: Document some reason for/agaisnst git tags/commits.’
<fps>C-u C-c C-z does a lot of things and now hangs ;)
<maximed>* agaisnst -> against
<fps>oh well, i'll kill it and return to grep for now ;)
<maximed>I'd like more opinions on that (it's almost some kind of project-wide quasi-policy)
<fps>ok, a different question: the config.scm is a guile-scheme file. but it is not a module. what precisely is it?
<gabber>fps a Guile Scheme script
<gabber>which returns an (operating-system)
<rekado>I’m afraid we’ll have to revert 9078c651e8d50e08b46e3b2da1c532c15af5ddb6 and 00056eafaefed0af8535f219760fbbe01dd6f240
<fps>gabber: ok, since the operating-system call is the last thing in the script that's what it returns?
<rekado>the former commit adds r-mathjaxr, which is full of non-trivial minified JavaScript
<rekado>there’s an ongoing multi-year-long struggle to build it from source
<gabber>fps: i think so
<rekado>this is something the R team could have prevented
<fps>gabber: and it's executed in a context set up by the guix system command such that it finds the modules it needs..
<fps>ok, wrapping a (display ...) around the operating-system call and running it in guile actually outputs something
<maximed>rekado: I'll send a message to 56282@debbugs.gnu
<gabber>fps env | grep GUI should show all the relevant env vars
<civodul>rekado: i guess we'll need to notify whoever applied the patch
<civodul>and yes, we need to implement teams
<maximed>civodul: I've sent a message!
<civodul>maximed: for? :-)
*civodul is kinda under water
<maximed>for r-mathjaxr, to 56282@debbugs.gnu.org.
<civodul>ah, good
<rekado>I just wrote them an email
<rekado>I can’t revert the commits because gnu/system/image.scm is currently broken
<civodul>isn't that an ABI issue?
<civodul>like "rm gnu/system/image.go && make"
<civodul>(that has to do with changes i recently pushed in define-configuration)
<maximed>Also, WDYT of giving records a (mostly) stable ABI (with some syntactic support in define-record-type*)?
<maximed>I had some unimplemented ideas in that direction.
<rekado>yes, probably a problem on my end
<maximed>(FWIW, such a thing is already done for the <origin> record)
<civodul>maximed: stable ABI would mean no inlining, and i'm not sure it's a good idea
<maximed>civodul: Maybe not in the general case, but for (gnu system ...)?
<civodul>define-record-type* has ABI-incompatibility detection though
<civodul>yeah, dunno
<civodul>maybe optionally?
<maximed>Does (gnu system ...) benefit from inlining in those records?
<rekado>maximed: I’m a bit annoyed that I couldn’t find r-mathjaxr with the search on issues.guix.gnu.org
<civodul>actually, i think we should rebase define-record-type* on raw records/structs, so we can have inheritance too
<rekado>I suppose you found it with a local email search?
<maximed>civodul: Maybe: enable by default, disable for <package>, <bag>, ...?
*rekado thinks we need a productive mumi hackathon
<maximed>civodul: I also sent comment to: ‘doc: Document some reasons for/against git tags/commits.’
<maximed>civodul: Inheritance is supported by RnRS records, no raw records needed?
<maximed>(Unless RnRS records are non-Guile 2.0)?
<maximed>There's a bunch of ruby security fixes on guix-patches
<maximed>Someone needs to actually build-test the @2.7 update but otherwise should be fine (diff doesn't look malicious when scrolling through, hashes match with the ruby-lang.org news entry)
<maximed>something equivalent to (condition? (make-condition)) -> #false
<maximed>writing that directly -> #true
<maximed>To be minimalised ...
<maximed>oops I added a (not ...)
<attila_lendvai_>i wonder if this is due to user code, or due to some change in guile: "gnu/services/mail.scm:431:0: warning: shadows previous definition of %namespace-configuration-location-procedure' at gnu/services/mail.scm:431:0"
<attila_lendvai_>and why it's not showing up at all the other uses of define-configuration
***attila_lendvai_ is now known as attila_lendvai
<attila_lendvai>and i'm still seeing regularly this: "substitute: In procedure write_wait_fd: unimplemented"
<fps>btw: the installer produced a config.scm that guix system warns about. like using target instead of targets, etc..
<fps>is there a way to produce a nop-derivation for places where a derivation is expected?
<fps>and the same question for a package..
<maximed>attila_lendvai: I'm not seeing it in <https://issues.guix.gnu.org/search?query=In+procedure+write_wait_fd+is%3Aopen>
<maximed>I think you have mentioned it previously, but is there a bug report yet?
<maximed>(with backtraces, which command is run, etc.)
<attila_lendvai>maximed, i haven't created one, because i thought i'm not the only one seeing it. maybe it depends on the network config on my side that occasionally causes the send buffer to get full. e.g. i have QoS set up on my router, because without it the ping goes through the roof (vodafone landline in hungary)
*attila_lendvai goes on to report the issue
<maximed>attila_lendvai: You aren't the only one seeing it (I have encountered it myself I think, some time in the past).
<maximed>However, dozens of tiny reports scattered through comments #guix and guix-devel etc are a mess to work with.
<maximed>So I recommend a single, centralised location, to have the backtraces, speculation, etc, with a nice searchable subject line.
<maximed>* the -> all the
<maximed>Ruby is bundling zlib.
<maximed>(sent a bug report)
<maximed>Also, ruby@3.0.4 is reviewed except for actual build-testing.
<davidl>Im repeatedly getting the following error when building from master:
<davidl>ice-9/eval.scm:293:34: error: copy-build-system: unbound variable
<davidl>hint: Did you forget (use-modules (guix build-system copy))'?
<davidl>sorry: I found the error immediately after posting.
<attila_lendvai>maximed, there's a bug report already: https://issues.guix.gnu.org/56005 (the retitle stuff is not reflected in mumi)
<maximed>I've sent a control message again.
<maximed>It isn't reflected in debbugs either.
<maximed>oops I sent it to 56006 instead of 56005 previously
<maximed>it's corrected now, hopefully that will help future debugging
<fps>ok, interesting: if i put (kernel hello) in my config.scm guix system image doesn't complain about it ;)
<maximed>attila_lendvai: I've found why the backtrace is obscured.
<maximed>catch / #:unwind? #true strikes again.
<maximed>If that's changed, hopefully the backtrace will contain something useful!
<jpoiret>it seems i haven't received https://issues.guix.gnu.org/56316 in my inbox
<jpoiret>is that the case for others?
<attila_lendvai>maximed, do you have the commit bit to change the #:unwind #true? or who should do what otherwise?
<civodul>comrades, a refereed paper on the supply chain security work we've been doing: https://programming-journal.org/2023/7/1/
<silicius[m]>I want to set an env variable before the check phase in python-build-system. wrap-program didn't work because the wrapped file is run by directly invkoing the interpreter (python)
<silicius[m]>Oh, I guess just setenv worked. I wrongly assumed build phases are somewhat distjointed
<ncbfg36>I'm installing Guix on a system with libreboot using grub as a payload. Does the graphical installer, when choosing to encrypt a partition, use luks1 or luks2 by default?
<maximed>attila_lendvai: I don't.
<maximed>Also, converting from catch (which doesn't support #:unwind?) to with-exception-handler seems non-trivial to me --
<maximed>catch/throw uses ‘old-style exceptions’ whereas with-exception-handler uses RnRS/SRFI conditions.
<maximed>(there's some automatic conversion between the two)
<maximed>It shouldn't be too difficult but it's not ‘simply add #:unwind? #false’ either.
<maximed>attila_lendvai: FWIW, this is in a part of the daemon, and you can hack on the daemon locally
<maximed>(./configure --localstatedir=/var && make etc, stop the daemon, start it from sudo ./pre-inst-env guix-daemon --the-right-arguments-...)
<maximed>not sure about sudo before or after ./pre-inst-env
<maximed>Has been a while.
<rekado>civodul: congratulations! Good to see a new paper.
<civodul>rekado: isn't the CfP over? (June 12)
<attila_lendvai>maximed, i have this in my notes: sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
<civodul>it looked like a good idea though!
<maximed>I've found the guile-fibers issue: https://github.com/wingo/fibers/issues/61#issuecomment-1171237280
<silicius[m]>libmpv patch is almost ready but the check phase doesn't want to end at all, it just stops giving any output after one of the tests
<maximed>In case anyone likes running signal-condition! after the run-fibers instead of inside the fiber, and in case people like to start fibers in run-fibers, waiting on a condition but never succeeding (because it is only signalled after run-fibers returns and all fibers were abruptly stopped)
<civodul>maximed: how did you hit that problem?
<SAIHAZE[m]>Has Guix packed VSCodium?
<maximed>civodul: My test suite for gnunet-scheme (scheme-gnunet?) does exactly that.
<wingo>maximed: i added you to the repo fwiw, plz get review from someone before merging anything :)
<maximed>gnunet-scheme is based on Guile-fibers, so the test suite often does (run-fibers ETC), and it's a bit lazy so it doesn't make sure all fibers stop before exiting the run-fibers.
<maximed>I'll try making a patch.
<civodul>ok, interesting
<maximed>wingo: I also have another patch (not a bug fix, but the wait-for-io-readable/writable): https://github.com/wingo/fibers/pull/50
<attila_lendvai>i think this is a straightforward optimization to match-record: https://issues.guix.gnu.org/54652
<maximed>(wingo: Used by gnunet-scheme, where it seems to work nicely)
<blake2b>wow loko scheme has climbed the scheme benchmarks to surpass mit & bigloo, trailing racket now https://ecraven.github.io/r7rs-benchmarks/
<silicius[m]>I meant python-mpv eariler instead of libmpv (this one is already included with mpv). running the tests by hand has the same effect, it stops doing anything at test_wait_for_prooperty_event_overflow
<civodul>blake2b: woow, crazy
<maximed>wingo: I've sent a PR: https://github.com/wingo/fibers/pull/62
*attila_lendvai is itchy to send a patch that disables the demand of define-configuration for a docstring
<civodul>docstrings are good :-)
<efraim>I don't know what it is with SBCL but it never builds for me on aarch64-linux
<podiki[m]>before I file a bug, is there anything known about the "herd rules udev" command mentioned in the manual? doesn't work for me (service 'udev' does not have an action 'rules')
<GNUtoo>mekeor[m]: for the problem I had yesterday (sharing the operating-system definition between guix deploy and guix system), I've managed to do it with -e: https://framagit.org/GNUtoo/machines_configs/-/raw/guix/system.scm/base-server/Makefile https://framagit.org/GNUtoo/machines_configs/-/raw/guix/system.scm/base-server/base-server.scm
<GNUtoo>btw, is it possible for a given package to run a phase multiple times?
*GNUtoo would like to run the build phase for android-ndk-build multiple times, once with LOCAL_MODULE=foo and another time with LOCAL_MODULE=bar
<GNUtoo>or should I teach the android-ndk-build to do that instead?
<efraim>GNUtoo: yes, I have a couple of examples
<GNUtoo>wow nice
<efraim>the key for searching is likely '((assoc-ref %standard-phases'
<efraim>I think I made x265 do that too
<efraim>x265 isn't as fancy but it gets the job done
<GNUtoo>Thanks a lot, I'll try to do something like with keybase
<GNUtoo>Basically I need to run the build phase several times for different modules, so it's a bit similar, but in my case what changes is just the extra make arguments
<efraim>I have a bunch of more examples similar to keybase in the golang module
<efraim>I think there are more examples using the linux-module-build-system or whatever its called
<silicius[m]> https://paste.debian.net/1245759/ this hangs for me during test phase, always on the same test. My friend run those in arch and no such problem exists there
<silicius[m]>I don't really know what might be happening here. So If anyone can confirm it's not just my setup acting up
<GNUtoo>silicius[m]: it hangs in python-mpv tests?
<efraim>See if you need to patch references to xorg in python-xvfbwrapper
<silicius[m]>GNUtoo: Yes, exactly at the test_wait_for_property_event_overflow test. But earlier tests run just fine
<GNUtoo>test_wait_for_property_shutdown looks almost identical, and I'm not sure what things like "with self.assertRaises(mpv.EventOverflowError): " really do
<GNUtoo>so I've no idea here, beside trying to understand better the issue and try to understand if it's really hang or if it's just super slow
<silicius[m]>I had my friend run it on another distro and it's not slow there
<silicius[m]>I tried running xvfb like in python-pytest-xvfb but it didn't change anything
<jpoiret>SAIHAZE[m]: doubtful, since it uses electron
<silicius[m]>the python-xvfbwrapper certainly works in python repl so I think no patching is needed there
<efraim>perhaps you need to set something with DISPLAY to tell it that it is offscreen
<lfam>I'm curious if any Guix-izens have begun planning for "Rust in the kernel"?
<unmatched-paren>lfam: I've seen a small amount of chat about it, but not any concrete plans, at least as far as i know
<lfam>That's my impression as well, but I have been absent for the last few months
<lfam>I'm hoping it won't be too much of a challenge for the community
<nerthus>it wont be anything significant until the GCC frontend is done is my belief atm anyway
<nerthus>they said a while back it will be restricted to newer modules/drivers for the time being, tho they may have changed that stance
<lfam>It could be that the Linux team will stick with GCC, but who knows
<lfam>I've started a thread on the mailing list: https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00422.html
<lfam>Anyways, I hope that some volunteers will start to plan for this. I won't be able to participate
<efraim>I tried to build gccrs by inheriting from gcc-12 but wasn't successful
***aeka` is now known as aeka
<unmatched-paren>efraim: I believe they're talking about rust_codegen_gcc (something like that...) which is a GCC backend for the _existing_ Rust compiler
<unmatched-paren>GCCRS is a completely new compiler
<lfam>Ah
***lilyp_ is now known as lilyp
<nckx>jpoiret: Now you have.
<nckx>It got stuck in a lift on its way to your inbox & I was working late.
***cnx_ is now known as cnx
<podiki[m]>sneek: later ask jts I saw in the logs you mentioned packaging haxe? I was also giving it a shot, curious if you got it working
<sneek>Will do.
<silicius[m]>I managed to disable that neverending test and almost all of them passed. test_read and test_write failed while trying to access homeless-shelter
<unmatched-paren>silicius[m]: /homeless-shelter is what $HOME is set to in the guix environment <silicius[m]>(setenv "HOME" "/tmp") worked and now "all" tests pass. <unmatched-paren>because the build user obviously doesn't have a home <unmatched-paren>silicius[m]: I *think* (!) (setenv "HOME" (getcwd)) might be a better choice <silicius[m]>Is "/tmp" global for builders? <unmatched-paren>99.99% sure no. <unmatched-paren>That would break isolation. But I still think cwd might be better for$REASONS.
<silicius[m]>so why cwd might be a better choice?
<unmatched-paren>Looks like both are used in various places throughout the source code, /tmp is fine, ignore me.
<unmatched-paren>I thought using cwd was standard but apparently no.
<unmatched-paren>s/standard/semi-standard/
<silicius[m]>It works either way
<jpoiret>nckx: oh, i didn't realize that debbugs was in front of the ML moderation
<nckx>Both work, but it's a 'correctness' issue. /tmp is a hard-coded name, even though it will almost certainly work \$forever, getcwd avoids that and hence is nicer. That is all.
<nckx>jpoiret: Hush, don't advertise it :)
<nckx>It is the megasuck, yes.
<nckx>unmatched-paren: I'm 99% sure it's cargo-culted, so once /tmp pulled ahead it only reinforced that loop.
<silicius[m]>Can I submit python-mpv with one test disabled if I write a comment explaining that test never ends?
<nckx>I was about to ask: do you know what it's doing then?
<unmatched-paren>nckx: Funny how Cargo is itself cargo-culted.
<nckx>But yes, silicius[m], you can!
<silicius[m]>nckx: you asked me what the test is doing?
<nckx>My cargo-culted was a bit too strong, lots of things are coded by example in Guix, and it's fine, but hence important not to tolerate too many ugly things. You'll come back in a year and they'll have magically reproduced.
<nckx>silicius[m]: Yes.
<nckx>If you know.
<nckx>There are many way to do nothing :)
<silicius[m]>nckx: It plays the test video, sets a trap that tests mpv.eventOverflowError exception is raised in its block (the first with block). In there it waits for 0.001 and then sends a command to mpv 10k times. It appears to be nullyfying all errors in the most-inner block though
<nckx>Aiya.
<silicius[m]>Now that I took a closer look, maybe changing the amount of sent command get me at least a failed test
<nckx>Fixing the test would be ideal, but it's not a blocker if disabled selectively with a clear comment.
<silicius[m]>changing it to one didn't change much. So the problem is in the command_async command
<unmatched-paren>sorry for the slightly-offtopic question, but is there some -config tool for libintl to locate its headers, libdir, et cetera? doesn't seem to have a pkg-config file
<unmatched-paren>I'm not using autotools, only a standalone makefile
<unmatched-paren>so i can't use the autotools gettext stf
<unmatched-paren>stuff
***mark_ is now known as mjw
<unmatched-paren>Hmm, looks like it literally expects you to use autoconf, which I will do when hell freezes over.
<unmatched-paren>s/expects/requires/
<unmatched-paren>Anyone know any other translation tool?
<unmatched-paren>That doesn't require autoconf.
<civodul>hey there, challenge: who's in to "translate" this howto to Guix? -> https://flyx.org/nix-flakes-latex/
<civodul>the winner receives a beverage of their choice at the ten-years-of-Guix meeting in Paris
<nckx>civodul: I thoroughly enjoyed your supply chain PDF.
<unmatched-paren>I mean, it is TeXlive, you have to expect that.
<unmatched-paren>ulfvonbelow: I think something like:
<vagrantc>civodul: yeah, that PDF was a nice read ... not much i didn't already know, but ... nice to see it all put together in one very well worded document :)
<vagrantc>i feel compelled to read one-off licenses roughly in the same way i feel compelled when someone says "wow, that smells really awful! smell this ..." ... and i just do not resist
<nckx>Restrictions on fork names *might* be an issue (I don't actually know) and 'requested' is always a facepalm when amateurs cosplay as licence authors. It might not be free. It's definitely going to be a pain.
<nckx>vagrantc: Graphic... and relatable.
<unmatched-paren>nckx: isn't a restriction on fork names basically the same as a trademark like with Firefox?
<vagrantc>firefox doesn't put it in the license
<nckx>That.
<unmatched-paren>I see
<nckx>All names are trademarked. But I do see your point, it occurred to me as well.
<jackhill>gnuplot requires modificates to be distributed only as patch files…
<jackhill>(also has nothing to do with GNU…)
<vagrantc>that workman license ... seems to lack *clear* permission to redistribute modifications
<vagrantc>i vaguely recall the workman license coming up somewhere with a more ... thorough analysis
<nckx>I read it again. It's a very bad 'licence' (not deserving of the name).
<nckx>I'm surprised there is no issue on the repo. Do you remember whereish, vagrantc (debian-legal would be ideal, if probably fatal).
<vagrantc>struggling to find it
<vagrantc>vagueness has won ...
<nckx>What are you actually packaging, ulfvonbelow?
<nckx>It's in symbols/us.
<nckx>Dixit GitLab, anyway.
<mbkamble>Hi. After installing emacs-geiser and emacs-geiser-guile packages, the info for Geiser is missing. Is the package definition for emacs-geiser incomplete?
<ulfvonbelow>well, at some point I got the impression that I should be looking for keyboard layouts in /run/current-system/profile/share/keymaps, and I didn't see anything about workman in or below that subidrectory, so I was gonna try adding the linux_console subdirectory of https://github.com/workman-layout/Workman as a package similar to kbd-neo
<ulfvonbelow>(I'm rather new to trying out different layouts)
<ulfvonbelow>according to the manual there are three different places keyboard layouts can be specified: bootloader, console, and xorg. Do those all use the same file formats and look in the same places?
<nckx>(In case it's not clear, my main concern is if & how you can claim & licence a keyboard layout to begin with, although I know Dvorak tried. The 'official Workman repo' might be non-free, but maybe the raw data as distributed in xk-c can't be.)
<singpolyma>IANAL but no way is a keyboard layout copyrightable :P
<nckx>How did you look? Keymaps aren't distributed as <name>.xkb or anything like that. It is much different.
<nckx>And yes, everything is generated from XKB layouts. GRUB, Linux, ... it all just works, even with xkb modifiers where possible. It's really very im.ressive.
<ulfvonbelow>find -L /run/current-system/profile/share/keymaps -iname '*work*' is what I tried
<nckx>You don't need different formats of each layout packoged.
<nckx>ulfvonbelow: No, it doesn't work like that.
<nckx>Just look up the xkb name for workman (total guess: "us" "workman") and define a koyboard-layout from that. Use that in all o-s fields with a keyboard-layout field. Done.
<nckx>Packaging layouts should not be a thing.
<nckx>Apologies for the typos. I use Dvorak, clearly inferior.
<vagrantc>we welcome all typos!
<nckx>This typos?
<vagrantc>nckx: botsnack
<nckx>:)
<vagrantc>speaking of which ... my latest packaging of guix for debian revealed a few more ...
<nckx>mbkamble: I'm looking right at geiser.info.gz, it's in emacs-geiser.
<nckx>Opens with info -f, at least (I don't have geiser installed).
<nckx>guix shell --pure info-reader emacs-geiser -- info geiser also works.
<nckx>I think you might not have installed what/where you think you do.
<nckx>...or! Something has broken very recently; also possible.
*nckx pulls
<mbkamble>nckx, I don't see it. see the commands I ran to locate the package in the store and a find in that subdir: https://paste.debian.net/1245801
<mbkamble>I am using emacs channel from  "https://github.com/babariviere/guix-emacs"
<nckx> unmatched-paren: 'Shouldn't', for sure, but https://patents.google.com/patent/US2040248A/en
<mbkamble>If a given package (say emacs-geiser) is available in multiple channels (eg. guix and third-party channel), is there any command option to show which channel it uses to fetch/install the package?
<nckx>mbkamble: Asking 'Is the package definition for emacs-geiser incomplete?' is rather meaningless then. How could we know.
<nckx>mbkamble: The Guix CLI will pick the one witt the highest version, here the custom channel one. Also: guix show PACKAGE
<nckx>We're never actively hostile.