IRC channel logs
back to list of logs
***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>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>Also, firstname.lastname@example.org 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. <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! <attila_lendvai>maximed, do you have the commit bit to change the #:unwind #true? or who should do what otherwise? <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>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 <rekado>civodul: congratulations! Good to see a new paper. <rekado>topics include OS, administration, development — all topics that match Guix. <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 <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? <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>(wingo: Used by gnunet-scheme, where it seems to work nicely) <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 *attila_lendvai is itchy to send a patch that disables the demand of define-configuration for a docstring <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>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 <efraim>the key for searching is likely '((assoc-ref %standard-phases' <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]>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>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
***lilyp_ is now known as lilyp
<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 <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>silicius[m]: I *think* (!) (setenv "HOME" (getcwd)) might be a better choice <unmatched-paren>That would break isolation. But I still think cwd might be better for $REASONS. <unmatched-paren>Looks like both are used in various places throughout the source code, /tmp is fine, ignore me. <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? <nckx>But yes, silicius[m], you can! <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>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 <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
***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. <civodul>the winner receives a beverage of their choice at the ten-years-of-Guix meeting in Paris <nckx>'Metered connection users: Be aware that the instructions in this article download quite a bit of data from the internet.' WDYM 'translate'. <nckx>civodul: I thoroughly enjoyed your supply chain PDF. <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? <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… <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). <nckx>I found a bug report adding it to xkeyboard-config, implying it's already 'in Guix'? <nckx>What are you actually packaging, ulfvonbelow? <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>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>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. <civodul>didn't know about this channel, that's interesting <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. <vagrantc>one person's welcoming is another person's ... hostile? <mbkamble>I am not knowledgeable enough with the build system, so I posted the open ended question about incompleteness. <mbkamble>But atleast, now I can try installing the one from emacs.xyz.scm and see if it contains the info files. <nckx>mbkamble: location: emacs/packages/melpa-generated <nckx> Vs. Guix's gnu/packages/emacs-xyz <nckx>(Too) subtle but know you know.