IRC channel logs


back to list of logs

*vagrantc would be surprised if old hardware would gain enough optimization to make up for the extra time spent compiling
<lfam>Yeah, really depends on the particular circumstances. I guess with channels we will see what people come up with :)
<dvn>i'm surprised nobody has packaged docker yet
<lfam>dvn: There have been some discussions about it on the mailing lists. I'd search the archives to see what the difficulties were
<dvn>hmm okay
<dvn>i'm curious
<enick_219>how does one go about closing a debbugs ticket?
<lfam>enick_219: Send an email to the bug's email address but add "-done" after the numerical portion of the address
<enick_219>lfam: can I reply and do that at the same time, or do I need to send two emails?
<lfam>You can do it all at once
<enick_219>lfam: great, thanks very much
***bavier is now known as Guest308
<bavier>I'm having some trouble with the new build-output-port
<bavier>the "lz4" package (I think) sends a #\nul character to stdout, which (ice-9 regex) chokes on
<lfam>bavier: That package does print some binary data during it's test suite
<lfam>Or its*
<bavier>lfam: ok, I thought so
<bavier>I'm looking at the build-output-port, but don't see a nice way to pre-filter lines with #\nul chars
<bavier>patch sent
***mbowcutt_ is now known as mbowcutt
<apteryx>bavier: there is a bug where I had a crude fix and mark suggested a fancier way to do it
<apteryx>haven't gotten around to try it out yet
<bavier>apteryx: same bug regarding #\nul chars in build output?
<bavier>sorry, I don't always keep up with all the bug and patch emails
***mbowcutt_ is now known as mbowcutt
<g_bor>just for the record, I had another problem building wip-bootstrap.
<g_bor>hi guix!
<g_bor>hi guix
<g_bor>just for the record, I had a problem building wip-bootstrap, building libxml stuck after some mv instructions. Let it run overnight, no progress. Trying again.
***mbowcutt_ is now known as mbowcutt
<janneke>g_bor: oh...bah
<janneke>do you have an idea what packages already built?
<janneke>i'm hoping this the host/x86_64 bit and because i changed some bits it guix/build/make-bootstrap, make-libc etc
*janneke picks-up native x86_64 branch of mes
<roptat>hi guix!
<jonsger>bavier bavier` could you bring the python3 fix from 5882078e8c999c7de16e38bc7f7a293ff2ec01a8 to upstream?
<ng0>I think the fix to some of my complains yesterday was to reboot. today I have verbose output when guix package -i involves guix build without using an alias that includes --verbose
<ng0>but i did not read the git logs since yesterday, so maybe a commit made this
<civodul>rekado_: i'm rebasing wip-ui and trying to merge its functionality with what we have in master
***pkill9_ is now known as pkill9
<nly>Hi guix :)
<pkill9>hi nly
<nly>How should I declare multiple filesystems in guix config?
<nly>(file-systems (list (filesystem ...) (file-system ...) %base file-systems) ?
<nly>I missed a ')' at the end
***rekado_ is now known as rekado
<rekado>nly: use “cons*” instead of “list”
<nckx>s/list/cons*/ in this case, since %base-file-systems is already a list.
<nly>Ty :)
<georges-duperon>Hi! I'm trying to run the halt command from within a service.
<georges-duperon>I tried (shepherd-service (start #~(lambda () (system (string-append $#shepherd "/sbin/halt"))))) with (use-modules (gnu services shepherd)) at the top of config.scm
<georges-duperon>But I get Unbound variable: #{$#shepherd}# when herd starts the service.
<georges-duperon>I suppose I have to do something to get the variable referencing the shepherd derivation available at run-time, but I have trouble finding out how.
<roptat>georges-duperon: shepherd is a package defined in a module, you need to import it
<georges-duperon>roptat: I had also tried (use-modules (gnu package shepherd)), but it doesn't exist. Do you mean that the package is a submodule of (gnu services shepherd)?
<roptat>mh, I don't think so
<roptat>you can run "guix package --show=shepherd" to see in which module it is defined
<roptat>(the location field)
<snape>georges-duperon: what do you want to achieve?
<snape>I don't really understand
<snape>what does "from within a service" mean?
<georges-duperon>roptat: thanks, recompiling now. Seems to work better so far with (gnu packages admin) that --show indicated :D
<georges-duperon>snape`: I'm trying to produce a VM image that boots, runs some commands while being disconnected from the network, and halts.
<georges-duperon>snape: Input and output to/from the VM go through hdds attached to the QEMU VM.
<snape>georges-duperon: you might want to have a look at (guix build marionette)
<snape>we use it to run tests in VMs
<georges-duperon>snape: Very interesting indeed! Can it in principle run stuff in a plain QEMU emulator, instead of a hypervisor-style QEMU with shared /guix ?
<georges-duperon>I'm trying to check if I the .nar I ship is self-sufficient (i.e. stuff can be rebuilt with network off), but if the VM has access to the whole of the host's /guix/store I'm not checking much :D
<roptat>georges-duperon: guix build environments don't have network access
<roptat>if you build stuff with guix build, you know for sure they don't need any network access
<georges-duperon>roptat: good to know, but guix itself downloads stuff all the time (sources for dependencies etc.).
<roptat>sure, but that's outside of the build environment
<apteryx>could we implement a hash checker in our makefile that would rebuild only modified files instead of rewritten files? Our rebase && make flow would be much faster.
<georges-duperon>roptat: but it also means that you can ship a .nar that will contain software that cannot be rebuilt if files online disappear.
<roptat>mh... doesn't a .nar contain everything needed already?
<georges-duperon>roptat: That's what I wanted to verify.
<snape>apteryx: there is a way to do this with make, if you know which files have been modified
<snape>georges-duperon: I don't know :-)
<georges-duperon>roptat: But it turns out `guix archive --export --recursive hello > /tmp/hello.nar' on my host system…
<georges-duperon>roptat: …followed by `guix archive --import < hello.nar; guix build hello' inside a bare-bones GUIX QEMU without network access fails.
<apteryx>snape: such a scheme proposed here:
<georges-duperon>roptat: (it seems the source isn't bundled, for starters)
<snape>apteryx: interesting!
<snape>apteryx: sometimes I use 'make --touch', which is very handy
<snape>to avoid rebuilding everything when you know nothing changed
<georges-duperon>apteryx: IIRC that thread, it sounds cool but make would need to store the previous versions of the files (or their hash) somewhere, whereas comparing timestamps works without extra data (you can't tell if a hash is "newer" than another, but that works for timestamps).
<georges-duperon>apteryx: Of course if you have the working directory & Makefile under your control, it's possible :)
<snape>apteryx: if you know only foo.h changed, you can: 'make --touch', then 'touch foo.h', then 'make'
<apteryx>georges-duperon: don't we always have the working directory under control? We could add the rules in the Makefile as in and every Guix dev would benefit from it (at the expense of one 'state' file per file in our Guix repo).
<roptat>georges-duperon: you need to authorise your key to import
<apteryx>I'll play with it when I have time.
<apteryx>My CPU is so slow, waiting for Guix to build on a rebase is not very productive ;)
<roptat>I'm considering buying arm or aarch64 hardware, but I'm not sure what board would give me less trouble
<georges-duperon>apteryx: sure, I meant that this was the reason why GNU make doesn't do it by default.
<roptat>what is the reference of that pine64+ we support?
<roptat>is Pine A64 + the correct one?
<thorwil>hi! i don't get past "no code for module (gcrypt pk-crypto)". reading through the relevant thread ... updating guix and using `guix environment guix --ad-hoc guile-gcrypt` wasn't enough
<thorwil>while this: is not something i'd like to try
<georges-duperon>roptat: The import succeeds (I took care of the key stuff), it's the build that fails immediately, because it has to download some sources.
<apteryx>georges-duperon: yes, that makes sense (as to why GNU Make doesn't implement it itself)
<rekado>scikit-learn is brokne
<ng0>was it guix-patches@ or patches-guix@ ?
<roptat>ng0: guix-patches@
<ng0>version bump of gnurl to 7.61.1 sent, in case anyone wants to apply it today.
<tune>is anyone looking into the rust issue? it's been failing to build for me for a few days
<ng0>tune: make that a couple of weeks and you are right.
<ng0>at least 4 tests are failing.. could you report them?
<ng0>I don' tthink we have a bug toicket for it
<tune>I'm not quite sure which info is important
<davexunit>^ not sure if that's necessarily relevant to guix but it is a cool event! ;)
<georges-duperon>roptat: thanks for the help earlier, guix package --show=shepherd and fixing the typo $#shepherd instead of #$shepherd did the trick.
<georges-duperon>roptat: For the full story: it then complained about /var/run/shepherd/socket missing. It turns out that one is created after all services are initialized,
<georges-duperon>roptat: but detaching the process that will call halt and waiting till the file appears did the trick.
<vagrantc>should ctrl-alt-delete from a console generally be a safe way to reboot guixsd ?
<efraim>does it currently unsafely reboot?
<vagrantc>haven't done any strict analysis, but it seems to reach shutdown faster, and sometimes afterwards does a filesystem check ... seemingly more often than if i use the power button to shut down
<vagrantc>from what you're saying, sounds like it *should* be safe
<nckx>efraim: I think so.
<nckx>Hence I avoid it, hence I'm uncertain.
<civodul>vagrantc: yes i think there's a bug
<civodul>shepherd is supposed to catch it by installing a SIGINT handler
<civodul>but apparently that's not working as expected
<vagrantc>thanks for confirmation
<rekado>some Python packages fail their tests in a strange manner
<rekado>you’d expect the test suite to catch the error and display it, but instead the build phase is aborted right away and a Guile backtrace is printed.
*rekado is working on python-scikit-learn right now
<civodul>weird, indeed
<civodul>vagrantc: after rereading ctrlaltdel(8) and kernel/reboot.c, it seems that we simply miss a (reboot RB_DISABLE_CAD) call
<civodul>i'll try that
<vagrantc>great :)
<rekado>it aborts with (#<condition &invoke-error [program: "pytest" arguments: ("sklearn") exit-status: #f term-signal: 11 stop-signal: #f] 68f700>)
<rekado>“term-signal: 11” ?
<rekado>does this tell me that pytest segfaulted?
<rekado>the internet says I may want to set OPENBLAS_NUM_THREADS to 1.
<joehillen> is timing out. Is that normal?
<civodul>rekado: parallelism is overrated anyway :-)
<efraim>rekado: I got that a bit earlier when I was working on updating rtv's dependencies
<efraim>i talked to my wife about guix days and fosdem and childcare, she might need some more convincing
<rekado>efraim: would it be helpful if we looked for concrete childcare offers?
<rekado>civodul: I think it’s a common problem when using Python with OpenBLAS.
<rekado>users here often have to fiddle with OPENBLAS_NUM_THREADS when running tools using the Scientific Python stack.
<rekado>(not setting it to 1, but some other low number)
<rekado>civodul: we once had this idea to make a couple of videos on Guix features. I wonder if that would be a good Outreachy project.
<rekado>it would require rather different skills than those that we already have
<civodul>rekado: do you think that would be suitable as a project? it would be awesome, for sure
<civodul>the problem that i see is that it's not development
<vagrantc>outreachy is not development specific
<rekado>it would be suitable according to Outreachy’s mission: “Interns work remotely with mentors from Free and Open Source Software (FOSS) communities on projects ranging from programming, user experience, documentation, illustration and graphical design, to data science.”
<rekado>this would tick the boxes for “documentation”, “illustration”, and “graphical design”.
<g_bor>hello guix!
*g_bor managed to build hello on wip-bootstrap. Nice.
<g_bor>rekado: this is a great idea. I also think we discussed some quite concrete options about this video project.
<g_bor>Do we actually have any Outreachy proposals right now?
<rekado>g_bor: at this point we still have none.
<nckx>Argh. Another empty message to the list. Sorry everyone.
*nckx recently switched to a keyboard layout where C-c is... elsewhere.
*rekado fixed python-scikit-learn
<nckx>Thank you!
<thorwil>on a foreign distro, does the guix for root play any role if, after installtion, everything is done as plain user?
<janneke>g_bor: *wow*, thanks for your efforts!
<g_bor>janneke: I was pleased to help. Actually what is still needed for the merge?
*g_bor going to get some food :)
<janneke>g_bor: i think it needs a round of review, and now that you built hello i'm sure civodul will have a look when he finds the time
<efraim>rekado: I think she just doesn't think it'd be fun to take the kids with us
<g_bor_>janekke:also, how the bootstrap will interact with the rest of the stuff?
<janneke>g_bor: yes, i started looking at reproducibility ... but haven't looked at cross-compilation, hurd -- whatnot
<g_bor_>actually trying to cross compile for x86_64 the current bootstrap binaries would be nice. It also has a good chance that it just works, or need not too much tweaking...
<g_bor_>I mean use the from source bootstrapped tools to cross build for the 64 bit version.
<janneke>g_bor_: yes!
<janneke>g_bor_: what we might need is a 64 bit c library seed; so that's where i started x86_64 suppot for mes
<g_bor_>yes, also think that so. But using the current bootstrap 64 bit glibc would still reduce the x64 seed to the libc and the bootstrap seed right now. It seems low hanging fruit...
<g_bor_>I might try that...
<janneke>oohh, great!
<janneke>another thing we might try -- i already made some attempts and failed
<janneke>is to try and use newer versions of binutils/glibc/gcc for the initial bootstrap
<janneke>we now have: gcc-2.95.3/glibc-2.2.5 and binutils-2.20
<janneke>i tried targeting gcc-3.0 or 3.4 -- we also could try gcc-4.7.4 directly...
<janneke>but i'm not sure what we want here -- it may depend on support we may get from upstream once they find out what we're doing?
<uniusz>hello, can i chat about elogind here ?
<uniusz>becouse i have elogind related issue
<uniusz>anyone ?
<lfam>uniusz: Related to Guix?
<uniusz>im using Parabola OS, but i have issue with elogind
<lfam>uniusz: The elogind developers are not here, as far as I know
<lfam>Well, maybe we have had a similar issue. It can't hurt to ask
<ng0>hey.. I picked up work on docker. I had this in one of my repos and we are going to need it for a project. I'll keep you posted and send patches once it works.
<nckx>lfam: Hm. I got a stacktract when I tried removing that zsh phase... Can't remember or check what, though.
<nckx>As long as it works for you :-)
<roptat>\o/ I'm downloading a torrent now
<roptat>it's a bit slow though ^^'
<lfam>nckx: Tested the build ;)
<nckx>lfam: I expected no less. Just weird.
*nckx goes back to updating sudo.
<lfam>Hi xen1
<xen1>i am going to install guixsd
<xen1>i am getting a error during installation process
<xen1>guix system init /mnt/etc/config.scm /mnt
<xen1>where i am getting the following error
<xen1>substitute: guix substiture: error: TLS error in procedure 'read_from_session_record_port'
<xen1>Error in the the pull function
<xen1>guix: sytem: error: corrupt input while restoring archive
<rekado>xen1: this sounds like a network error.
<g_bor>rekado: I've also seen this yesterday, and it was coming back after trying again.
<g_bor>It was I guess some gcc archive, I user guix build, so adding fllback solved this for me, but istm this is not an option guix system.
*g_bor needs some sleep...
<janneke>sleep well, g_bor
*janneke ->zZzzz
<ecbrown>does this guix offload error look familar to anyone? guix offload: error: failed to load SSH private key from '/home/ebrown/.ssh/id_rsa': Unable to import a key from the file
<lfam>ecbrown: I've got no experience with offloading, so this is a wild guess. Does the key actually exist? Like, can you use it with plain `ssh`?
<ecbrown>yes, i can do passwordless ssh to the build host as root and user
<lfam>Okay. If nobody pipes up to offer better advice, I'd start reading the code to figure out what it's trying to do and why it might fail
<lfam>Might also be worth strace-ing it since it appears to fail at a point that might be handled by a syscall (reading the key file)
<ecbrown>lfam: well, as you have time and see fit, i do have alternatives :-)
<ecbrown>thank you
<lfam>I meant, "I'd start reading the code..." as in "This is what I would do if I had this problem" :)
<ecbrown>oh i see wah
<lfam>Ha, sorry
<ecbrown>i'm going to try another build server, perhaps i've just hit a weird combo
<lfam>I'm curious, who tries to read the SSH private key when offloading? Are they able to read it?
<lfam>Also, is guile-ssh available and accessible from the point of view of whatever is trying to use it?
<rekado>for offloading you need to specify a user account. Did you do that and is this user able to do passwordless SSH?