<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 :) <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 <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? <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>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>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? <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. <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 <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 <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>how easy is it to get an article on nature.com? :-) <rekado_>civodul: do you mean a rebuttal in paper form … and get that published in nature.com? <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 <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_>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>ACTION has a patch where "guix package --search" sorts by relevance <civodul>also, the package names accounts for more than the synopsis, which is more than the description <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" <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>So you better start working on a "software abstraction layer", so that you work on ALL the sections.. <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
<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>and yeah, +1 for getting hardware from the relevant companies/groups <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? <civodul>it's supposed to be better since yesterday <rekado_>I think IT changed something on the file server configuration <rekado_>I run “guix build bwa” and … nothing seems to happen <civodul>it could also be communication that's slower <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_>/gnu/store/apg7l48lv465m7pbx2i5795bsjkp9yin-bwa-0.7.12 ***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 <civodul>are you using GUIX_DAEMON_SOCKET=guix://... ? <rekado_>I wanted to switch, but not this week <civodul>so it's communicating over the Unix-domain socket, right? <civodul>can you try "strace -c guix build foo"? <civodul>that should give us a clearer picture <rekado_>I reran the command and it took 43 seconds <rekado_>no, but it’s what we’ve come to accept :) <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"? <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 <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 <jsierles>hello. is there a way to search IRC logs? <ng0>of this channel? not yet <ng0>manual search at the gnunet.org URL <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>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>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 <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'? <efraim>Is it used with HAM radios or more of in a 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>But, now I'm running on an SSD with several hundred spare gigabytes! Back in action! <sneek>civodul, you have 1 message. <fps>what do you think of this: <fps>bash-static-4.4.12 livin on ipfs <reepca>Hm, did sneek just fail to deliver a message to ng0?