IRC channel logs


back to list of logs

<jonsger>Apteryx: it has AMD PSP (it's like Intel Management Engine) and probably microcode in binary form :(
<Apteryx>jonsger: OK. Yeah, I understand that nothing is very free friendly in the modern hardware department; but at least if linux-libre could run with it that'd be something :)
<Apteryx>I'm trying to find references to ryzen microcode "blobs" but so far can't find any. Only updates to AGESA firmware (which can be done in UEFI bios) -- not free, but no blobs to load so far.
<DoublePlusGood23>Apteryx: I'm guessing it will run fine? I'm honestly OK with using microcode on a modern pc.
***t is now known as Guest43648
<jonsger>Apteryx: but otherwise, I think guix + ryzen could be fun, because of 16 Threads :)
<DoublePlusGood23>jonsger: some of those amd workstation boards are libreboot'd
<jonsger>DoublePlusGood23: yes but with older Opterons
<DoublePlusGood23>jonsger: it's not the model that counts, it's the number of threads you have in your heart :*)
<jonsger>DoublePlusGood23: yes, but ryzen has little more performance per thread then those opterons :P
<DoublePlusGood23>jonsger: anything sounds better than the duo core I use now :p
<Apteryx>Xelatex not finding the roboto font I installed with "guix package -i font-google-roboto"
<Apteryx>Do I have to run manually fontcache or something?
<Apteryx>OK, I had to run "fc-cache -f"
<reepca>So it turns out that those two store tests that were failing for me were because I hadn't re-run ./bootstrap or whatever it is that re-generates the test stuff, and had copied the repository from a different system where it was in a slightly different place in the filesystem.
<reepca>Now tests all pass for me :-)
<DoublePlusGood23>reepca: haha, I've done that a couple time :p
<reepca>Although now another issue appears ever since I added %store-database-directory - test-env doesn't make sure that directory exists prior to it getting passed to canonicalize-path, and I'm not sure what generates test-env
<reepca>Ah, in build-aux.
<reepca>Hm, I've closed down to just 12 buffers open in emacs, and yet it's still using 3.8GB. That's worrying.
<reepca>Anyway, the radeon 6450 arrived today - time to see if I can use all these displays at last... third time the charm hopefully?
<janneke>morning Guix!
<reepca>sneek: later tell ng0: It seems that the radeon hd 6450 does not work with linux-libre. Firmware fails to load, no 3D acceleration, one display output only, and a very messed up one at that. On the bright(?) side, I get to write a strongly-worded letter now.
<sneek>Got it.
<reepca>sneek: botsnack
<civodul>Hello Guix!
<catonano>Hi civodul !
<efraim>re modular texlive, i'll try to test it on aarch64 today
<civodul>modular texlive makes our lives brighter
<efraim>right now i'm building python2 and python3 from core-updates
<efraim>one more test from python3 added to the blacklist it looks like, but i haven't tested upgrading to 3.6.x yet so that can be sometime later
<civodul>efraim: BTW, if you know of reasonable aarch64 hardware we could buy, let us know
<civodul>or sponsors maybe
<efraim>sorry, i've been meaning to write a post about my experiences so far but I keep on putting it off
<efraim>I love the firefly and the emmc in it, but I'd really like to find the source for the flashing tool
<efraim>the hikey 2gb board that I have has 2gb of ram and 8gb of emmc and boots from sdcard (i believe), it might actually be the best free option with /tmp and swap on the emmc
<civodul>well just mail your recommendations to guix-devel or guix-sysadmin :-)
<civodul>as long as the thing doesn't require non-free software, that's fine
<m-o>hi civodul ! thanks for your help on guile-git. Your idea of running scm_run_finalizers, would suppose to write a C module in guile-git right ?
<efraim>what do I test for the texlive patches? texlive-tiny?
<rekado_>efraim: what do you want to test? If you just want to see if things build without errors “texlive-tiny” is a good test.
<rekado_>(I still need to make changes to the build system, though)
<efraim>rekado_: yeah that's pretty much what I'm testing
<efraim>I got error: no variable named texlive-bin in #<interface (gnu packages tex) 8b14820>
<efraim>i changed texlive-bin to 'define-public' and now it looks like its starting to decide how to build everything
<rekado_>oh, yeah, I did make that texlive-bin change locally
<rekado_>I also updated texlive-bin to the latest version, but I haven’t submitted it as I couldn’t find the updated URL for texlive-texmf
<efraim>I would prefer a more descriptive name than 'svn-checkout' :)
<efraim>ACTION goes off to do other things while it compiles
<rekado_>civodul: I think we should comment on this:
<efraim>texlive-tiny built in 5.5 minutes
<civodul>sneek: later tell m-o you could do (dynamic-func "scm_run_finalizers" (dynamic-link)) and use the FFI
<civodul>rekado_: indeed!
<civodul>we could write a rebuttal too
<civodul>how easy is it to get an article on :-)
<rekado_>civodul: do you mean a rebuttal in paper form … and get that published in
<rekado_>well… :)
<civodul>let's be ambitious ;-)
<civodul>apparently it's "Nature Toolbox", i guess it's not the "real" Nature, is it?
<rekado_>hmm, I don’t find “Nature Toolbox” among the list of journals by the Nature publishing group.
<civodul>or maybe that's just the title of the section
<civodul>"Shifter, which doesn't require full privileges, or root access, but still supports Docker images"
<rekado_>I think too many people conflate reproducibility with containers
<civodul>yes, so we must keep repeating the same story over and over
<rekado_>the advantages they mention are all about deployment
<rekado_>it’s easy to deploy software this way, but it’s still shrink-wrapped computers
<civodul>well it's "reproducible" in a way
<rekado_>“The Reprozip program, for example, assembles Docker-compatible packages by watching as software tools run and tracing the input files and software libraries that the tool requires.”
<rekado_>that’s… weird.
<civodul>yeah that one is interesting
<rekado_>looks like this really is the “real” Nature, but maybe it’s easier to get things published in one of the special sections like “Toolbox” or “Insights”.
<efraim>on ldc@0.17.4 on aarch64: ldc-0.17.4/runtime/phobos/std/math.d(1705): Error: static assert "Not implemented for this architecture"
<efraim>do we want to add postgresql-9.[2345].x? They're still supported upstream and we don't currently have an automated upgrade postgres version solution
<efraim>the 4 took 41 minutes to build on my older laptop
<civodul>efraim: did the previous ldc version work on aarch64?
<civodul>maybe you can just add 'supported-systems' for now
<civodul>rekado_: let's try, not necessarily Nature, could be CACM (pretty hard too but heh :-))
<efraim>Aarch64 is already tagged not supported
<efraim>I forgot, figured I'd try to build it again
<civodul>ah good :-)
<civodul>ACTION has a patch where "guix package --search" sorts by relevance
<davexunit>civodul: how do you rank by relevance?
<civodul>simply the number of regexp matches
<civodul>also, the package names accounts for more than the synopsis, which is more than the description
<davexunit>ah cool
<davexunit>sounds nice
<roelj>civodul: Can we then also set a threshold for relevance? :D
<civodul>roelj: good point, that may be useful!
<roelj>Or maybe "print maximum 5" works better in practice
<civodul>but you can always do "guix package -s foo | grep ^name| head"
<roelj>civodul: Great work btw!
<civodul>rekado_, roelj: section 5.2.3 of is for us :-)
<civodul>ACTION wonders what these big research agendas are for
<roelj>civodul: Cool. The whole section 5 sounds interesting, yet abstract :)
<roelj>civodul: Maybe GWL can help a little bit with 5.2.4 too
<civodul>i wonder if "i'm on section X!" automatically gives you funding
<roelj>Haha, who knows..
<roelj>So you better start working on a "software abstraction layer", so that you work on ALL the sections..
<civodul>good point!
<roelj>Oh, I got set back a day with testing the performance-related changes, as I had (somewhat accidentally) done 'guix gc', and now it is rebuilding a lot to get a 'guix environment --pure guix'.
<rekado_>civodul: Inria is a member of etp4hpc — maybe you can get extra funding?
<ng0>funding… I got a funny rejection reason yesterday, basically 'GNUnet is not used so widely and is difficult to use, that's why we voted not to fund your work in this round' ... for work on a projectwhich aims to make GNUnet more accessible. If I had this as a letter I would print it and file it under 'comedy'.
***andreh1 is now known as andreh
<civodul>rekado_: oh i hadn't noticed
<ng0>civodul: a while back you asked me about funding, did I share the link for 'renewable freedom' and advise to get in touch with them?
<ng0>oh and with regards to the arm port: iirc GNUnet got some arm devices from some arm foundation / group a couple of years back
<ng0>maybe that's something Guix could consider for the arm v8(?) build machines?
<civodul>ng0: yeah that rings a bell
<civodul>and yeah, +1 for getting hardware from the relevant companies/groups
<ng0> back in 2010
<ng0>I have literally no idea what to expect, but it can't be a total waste of time to contact them
<ng0>I have some updates for xfce4, but I have no idea how to fix the build issue I get.. do we have someone who's been working more on xfce4 before?
<rekado_>Guix + NFS performance is terrible
<rekado_>something must have changed here
<rekado_>it’s completely unusable
<civodul>it's supposed to be better since yesterday
<civodul>what commands do you run?
<rekado_>I think IT changed something on the file server configuration
<rekado_>I run “guix build bwa” and … nothing seems to happen
<rekado_>for minutse
<civodul>it could also be communication that's slower
<civodul>did you try to strace it to see?
<roelj>rekado_: what's the output of nfsstat -c?
<rekado_>yes, I’m looking at strace and it’s very slow
<rekado_>I see that it tries to write a couple of things
<rekado_>write(9, "/gnu/store/lgzr78z27vqnsd6yq9p34"..., 62) = 62
<rekado_>and then it sits for several seconds seemingly doing nothing
<rekado_>meanwhile there’s no output whatever on the client side
<rekado_>it finally finished
<rekado_>time ./pre-inst-env guix build bwa
<rekado_>real 6m37.992s
<rekado_>6+ minutes for doing notihng
***andreh1 is now known as andreh
<civodul>rekado_: presumably FD 9 is the connection to the daemon, isn't it?
<rekado_>on my workstation it takes less than two 2 seconds
<civodul>IOW, it may be RPCs that are slow, not file system accesses
<rekado_>but why would that be so?
<rekado_>it’s on the same machine
<civodul>are you using GUIX_DAEMON_SOCKET=guix://... ?
<rekado_>no, not yet
<rekado_>I wanted to switch, but not this week
<civodul>so it's communicating over the Unix-domain socket, right?
<civodul>ok so that shouldn't be slow
<civodul>can you try "strace -c guix build foo"?
<civodul>that should give us a clearer picture
<rekado_>hmm, it seems to be very variable
<rekado_>I reran the command and it took 43 seconds
<rekado_>(still slow, but more acceptable)
<civodul>i wouldn't call that acceptable...
<rekado_>no, but it’s what we’ve come to accept :)
<rekado_>that’s the output of strace -c
<roelj>Ha! I've found a reliable way to find out what's building.. "watch -n 2 ls -l /tmp" :D
<rekado_>I used “pgrep -fa builder” or similar.
<civodul>rekado_: that's still only 0.1 seconds spent in syscalls so there must be something else
<civodul>if it's possible, could you try "perf timechart record"?
<rekado_>okay, I’m trying that now
<civodul>you pretty much have to be root to do that
<rekado_>hmm, I don’t know how to read the output with “perf record”
<civodul>but then you get a Gantt chart, which i find helpful sometimes
<civodul>perf timechart report
<civodul>or just "perf timechart" actually
<civodul>that produces an SVG
<rekado_>ah, good
<rekado_>that SVG crashed emacs :-/
<rekado_>so, in the browser I see that guix-daemon is all red, i.e. blocked on I/O
<rekado_>I guess I’ll push IT to let me move /gnu to GPFS
<rekado_>this is just terrible
<jsierles>hello. is there a way to search IRC logs?
<ng0>of this channel? not yet
<ng0>manual search at the URL
<ng0> <-
<ng0>to be moved to some searchable variant later this year
<jsierles>does GUIX_PACKAGE_PATH need to include /gnu/store?
<jsierles>after changing it, guix package can't find a bunch of core modules
<jsierles>ie. `ERROR: no code for module (gnu store #{0lv48l6fb00p3c79cwwfk9dr9s5al619-build-utils}#)`
<ng0>can someone merge the one E21 patch I've sent? I've been using it for days, works for me.
<ng0>makes our E21 one bit less akward
<jsierles>also does GUIX_PACKAGE_PATH have to be relative to the client's current directory?
<ng0>in bash, I'm using just one path in GUIX_PACKAGE_PATH
<jsierles>ok. i have my modules in ./nextjournal/packages/r.scm. the module is named after this path
<jsierles>but not sure what the full path is intended to be for 'guix package' to work.
<ng0>user@abyayala ~$ cat src/ng0-config/shell/bash/variables
<ng0># src/packages: personal repository.
<ng0>export GUIX_PACKAGE_PATH="/home/user/src/packages"
<jsierles>what is your package module name?
<jsierles>mine looks like: (define-module (nextjournal packages r)
<ng0>starting from src/packages it is (ng0 packages foo) where foo is a placeholder for all files in there
<ng0> for presentation.
<ng0>ACTION has to go
<jsierles>i had it working before, but lost the commands :/
<jsierles>if i set GUIX_PACKAGE_PATH to /modules/nextjournal/packages. i still see 'no code for module'
<jsierles>i see. you have to set it to the root of the module name path.
<jsierles>possible to use manifests with 'guix pack'?
<sirgazil>sneek: later tell civodul: I saw you were working on the website blog and tags. I sent an implementation of that to bug #26006 a few days ago ( See if something there is useful.
<sneek>Will do.
<quigonjinn>any idea about which file should packages from go to?
<efraim>Is it used with HAM radios or more of in a lab setting?
<quigonjinn>efraim: lab setting
<efraim>I don't think we have a generic science.scm
<quigonjinn>i was thinking either electronics.scm or sigrok.scm. Or embedded/engineering from the existing ones
<efraim>Electronics sounds like the best one to me
<quigonjinn>maybe i should also refactor the patches i submitted with the circuit simulators, to go in there as well?
<lfam>Ahh, updating the list of substitutes for a core-updates build on a fresh /gnu/store...
<lfam>I hope I don't run out of memory for all these lines "substitute: updating list of substitutes from ''... 100.0%" ;)
<lfam>But, now I'm running on an SSD with several hundred spare gigabytes! Back in action!
<civodul>hey lfam!
<sneek>civodul, you have 1 message.
<sneek>civodul, sirgazil says: I saw you were working on the website blog and tags. I sent an implementation of that to bug #26006 a few days ago ( See if something there is useful.
<civodul>ACTION was just looking at it :-)
<fps>ohai :)
<fps>what do you think of this:
<fps>bash-static-4.4.12 livin on ipfs
<fps>points to e.g.
<reepca>Hm, did sneek just fail to deliver a message to ng0?
<lfam>Hi civodul!
<lfam>fps: Nice :)