<OriansJ>Who wants the good news about stage0? <paroneayea>daviid: rekado_: glad you enjoyed it / thanks for the feedback <OriansJ>for those who haven't been following along, stage0 is literally a full bootstrap from a 280 byte hex monitor to a C compiler and created all of the tools needed along the way. <OriansJ>and janneke the good news is you don't have to solve the Lisp down to hex problem, since I have already implemented the hex up to the garbage collect lisp already :D <janneke>OriansJ: hi! Thanks for the ping and all the work! <OriansJ>janneke: I'm just glad that you are working on the hard part <janneke>OriansJ: that's what I'm hoping for, that our efforts can be complementary and we can work together <janneke>OriansJ: i looked a few times and saw 'LISP empty', so thanks for the pointer! <janneke>I'm about to finish and announce Mes to be self hosting (i.e: scheme interpreter written in C can run C compiler and compile itself),...almost done <OriansJ>civodul: I am well past that already ( literally a forth interpreter, a lisp interpreter, a line macro assembler, multiple hex assemblers, a text editor written assembly, etc) <janneke>that's what i mean: exciting times :-) <civodul>rekado_ should announce bootstrappable.org at the same time <OriansJ>if I can convert my lisp to be powerful enough to support the work janneke did, we could be really close <janneke>is Matt Wette from Nyacc around here sometimes? <OriansJ>even if I have to write a hundred primitives in C to get it done, I could do that in a couple weeks time <oborot>The USB install manual doesn't seem to work <oborot>I get a bad signature error when trying to verify with gpg <oborot>gpg: BAD signature from "rekado <rekado@elephly.net>" <lfam>oborot: The signature verification works for me <lfam>oborot: The SHA256 hash of the tarball is fd035a5e0662e971436541918c08896544019973dd56fdf0cd0e1cbbc8e7155f for me <oborot>Was there still issues with Node.js? <bavier1>I think the warning printed by 'guix refresh' is misleading when explicit packages are named and no updates exists <bavier1>or maybe its just the way refresh interprets the results from the github updater <Apteryx>How can I find out which profile is currently used (from the store) after I run "guix enviroment ..." ? ***Piece_Maker is now known as Acou_Bass
<rekado>OriansJ, janneke: Wow, this is great! <rekado>OriansJ: would you mind if I added stage0 to the list of projects on bootstrappable.org? <Apteryx>Hi Guix! I'm making progress on a profile hook that will generate the manpage index.db file which allows apropos or man -k to work as expected, but still need some help. <Apteryx>I'm testing for example by doing: guix environment --ad-hoc git. I then see that the generated profile contains the desired file: /gnu/store/j8hdiljyjx5fw8wzm4jh6g8g2afzdfl6-profile/share/man/index.db. Unfortunately apropos seems to be looking under $HOME/.guix-profile/share/man/index.db. <efraim>Maybe it might need tweaks to the guix environment script <Apteryx>OK. I'll try to get the base use case going at first (the main user profile). <efraim>you're doing the hard work, I'm just throwing out ideas <rekado>hmm, guile-reader fails to build on core-updates. <efraim>I haven't looked at the guile stuff yet on core-updates <efraim>Once webkit finishes building I'm going to test disabling tests on libevent@2.1.8 on aarch64 and armhf <rekado>I get this error: token-reader-lookup.c:122:1: error: conflicting types for ‘_scm_token_reader_lookup’ <rekado>the other type is: _scm_token_reader_lookup (const char *, unsigned int); <Apteryx>Do we have something already to take multiple paths and symlink all the files under into a single directory? <Apteryx>How can I recurse through all the files under a given node? <rekado>Apteryx: “find-files” gives you a list of file names <rekado>you could map a procedure over the result <janneke>is guix download ftp:// ... broken in master? for me, this fails: <janneke>guix download ftp://ftp.debian.org/debian/pool/main/f/fakechroot/fakechroot_2.18.orig.tar.gz <rekado>janneke: I think Ludo fixed it yesterday <ofosos>I want to add a package to a guix checkout, some old documentation talks about gnu-system.am, which i can't find, to let the system know that package is there, do I still need that? guix build comes back with package not found. any ideas? <efraim>Gnu-system.am became gnu/local.mk <rekado>ofosos: also make sure to use “./pre-inst-env guix” <Apteryx>Strange, I cannot find the docs for find-files. <ofosos>hmpf, ok, i see. the problem: i defined the new package in audio.scm, the ./pre-inst-env guix build simply states that the .scm is newer than the one in the default environment, but doesn't seem to do anything about it <rekado>Apteryx: it’s a Guix thing. It’s defined in (guix build utils) <rekado>ofosos: that’s just a warning. You can run “make” to compile the .scm to .go. ***atty is now known as jest_a_prank
<ofosos>i did not find anything on qjackctl on debbugs, is anybody working on it? <rekado>ofosos: I didn’t package it back in the day, because jackd works just fine for me. <rekado>I don’t think anyone else is working on it. <civodul>OrangeShark: did you have a chance to look at my recent Guile-Git patch? <civodul>OrangeShark, amz3: actually perhaps patch by email is inconvenient for you, what do you prefer? <amz3>civodul: what's the subject of the mail, I did not see the patch <amz3>patch by email, is ok, but I did not see it <mekeor>nice, efraim. what's missing about it? <efraim>mekeor: never got around to finishing it, never decided between propagating everything or substituting* absolute path names for everything <efraim>plus I ended up not using it in the end <civodul>amz3: i think i just emailed it to OrangeShark, thinking it would be unproductive to email the two of you :-) <rekado>civodul: guile-reader fails to build on core-updates <ofosos>hmm, i'm having a problem using the elpa imiporter on melpa-stable to get bbdb: guix import: error: failed to download package 'bbdb' <ofosos>this worked nicely with adjust-parens, but no luck with bbdb <ofosos>hmm, i've packaged up qjackctl, however, when i try to check if it is deterministic (--check) it simply grafts the software, when i pass build --check --no-grafts it tells me that both differ. how can i analyse this? <civodul>ofosos: try "guix build qjackctl --no-grafts --check -K" <civodul>with -K, the second build result is kept under /gnu/store/...-check <rekado>I found that sometimes “--no-grafts --check” is not enough to force a rebuild. <rekado>I’m trying to rebuild R 3.3.2 (not in Guix upstream) to see if my reproducibility patches also made 3.3.2 reproducible. <rekado>but “guix build --check --no-substitutes --no-grafts -K r@3.3.2” doesn’t do anything but return the location in the store. <ofosos>ok, basically the binaries are not identical <ofosos>but also: Binary files /gnu/store/37hyf8gkmrji64iczmj8cxf3z24vwxxj-qjackctl-0.4.4/share/man/man1/qjackctl.1.gz and /gnu/store/37hyf8gkmrji64iczmj8cxf3z24vwxxj-qjackctl-0.4.4-check/share/man/man1/qjackctl.1.gz differ <ofosos>gzip -d and diff -u tell me they're identical <ofosos>maybe some weird difference between compression options? <ofosos>i just removed the packages and gc'ed the store, trying to reproduce this <OriansJ>rekado: Feel free to add stage0 as it certainly qualifies <jest_a_prank>Hi, #guix. can `handle-lid-switch` in `elogind-service` be set as suspend *and* lock? <arunisaac>Hi, I'm trying to fix bug #25235 ( https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25235 ), and have modified guix/build/python-build-system.scm for the same. In particular, I have added #:use-module (guix packages) because I need the functions `package-name' and `package-transitive-target-inputs'. But, when I try building any python-build-system package with something like "./pre-inst-env guix build scons", I get a ("no code for module" <ofosos>nope, build just one after the other they both still differ, even the man pages differ again <rekado>jest_a_prank: I don’t think so. The available handle actions are defined in gnu/services/desktop.scm on line 585. <jest_a_prank>I want to make my laptop be suspended and locked when I close the lid. <bobpollaco>Is it normal in GuixSD that root user doesn't have guix command, and some basic commands like "ls"? <arunisaac>bobpollaco: I'm on GuixSD and my root user does have the "guix" and "ls" commands. I checked again just to be doubly sure. <bobpollaco>jest_a_prank, Is it possible that your laptop does not support the 'laptop lid closed' kernel messages <arunisaac>bobpollaco: As the root user, what is the PATH environment variable? And, is "ls" in /run/current-system/profile/bin ? <efraim>15 hours to build webkitgtk@2.16.0 <buenouanq>bobpollaco: brilliant! thanks for telling me (about the Gnome fix yesterday) <bobpollaco>you welcome buenoaunqe. aurinsaac: I have tried to log into root user in a tty instead of using "su" and there the commands are working fine <bobpollaco>I mean, the command are missing when logging root in the gnome-console <jest_a_prank>bobpollaco: My laptop does support laptop lid closed and works great. what I want to do is I want to do is locking the screen when it go suspended. <rekado>jest_a_prank: FWIW I’d like to do that, too. <rekado>(I’m not using Xfce but stumpwm.) <bobpollaco>ok, xfce4-power-manager is not responsible of that. You need to have installed a screensaver <bobpollaco>In the options of the screensaver you should have the option to lock the screen in suspend <arunisaac>bobpollaco: Ah! I use "sudo -s" to become root. <jest_a_prank>bobpollaco: I tried `xscreensaver`. I should try the others. Do you have some recommendations? <bobpollaco>I've used xscreensaver along xfce4 in other distribution and it worked fine, but I remember having lot of problems with it. It is very difficult to have it working properly. <efraim>oh if I disable tests on libeven@2.1 I have to make sure not to on 2.0 <bobpollaco>buenouanq: Do you recommend to create that alias? <buenouanq>if you use your computer like I do, yes, very much so <buenouanq>some people prolly do things different and won't want to <buenouanq>I alias things I need basically every time and always forget. <bobpollaco>buenouanq: If I have only one user so I supose that it is worthy <civodul>amz3, OrangeShark: just emailed you a bunch of patches :-) <OrangeShark>civodul: I saw the patch you sent the other day, haven't had a chance to look at it. ***atty is now known as jest_a_prank
<ofosos>civodul: the darktable patch from the bug tracker works fine (with minor modifications) i've darktable running on my guixsd, should i add anything to the bugtracker? <catonano>ofosos: if you have a new version, you should submit your version of the patch <ofosos>it's not my patch originally, the old patch just didn't apply any longer <lfam>ofosos: In your message, can you also list all the patches that darktable depends on? If I remember correctly, they were sent in separate threads so it was hard to keep track of <ofosos>lfam: as of now, only fop is unavailable, everything else worked. i removed the fop dependency and it built fine <ofosos>oh yes, and i change the llvm-x.x.x to llvm, same for clang, in the native inputs, but i didn't verify the result <Apteryx>civodul: Success for the manpage db generation :) <Apteryx>It's a bit compute heavy though; on my main profile with 67 packages installed it doubled the time required to do a package install (since it must rebuild the database from scratch everytime the profile changes). <ofosos>nope, opencl doesn't work, basically it need a libOpenCL, which is not available <ofosos>but the software itself is unaffected, i only see a complaint when i start with -d opencl <Apteryx>I'll send the patch tomorrow, after I write the changelog with a clear head. <lfam>Hey efraim, did you ever send a patch for the parallel XZ thing? <davexunit>'guix pack' is sure useful for letting you know that your dependency tree is huge <efraim>lfam: I sent it to guix patches a couple of days ago <lfam>efraim: Cool, I'm looking forward to it :) <civodul>Apteryx: awesome! maybe we can tweak mandb to use a faster database or something <civodul>davexunit: there are cases where we could do much better! <civodul>for instance glibc and gcc:lib are big currently <efraim>Building Hydra failed on aarch64 <paroneayea>civodul: no recording of the emacs shenanigans, but the oral history is all there, and lots of hand gestures ;) <lfam>Ah, the libreplanet videos! <lfam>Looking forward to watching :) <janneke>yes ~@31:50, the thing about distros starts ~@27:00 <paroneayea>the tl;dr for people here curious (though you should watch the talk) is that most free distros end up complicating the "supply chain" by introducing an intermediate distro which needs to remove all the nonfree things, and that both duplicates effort in resrource constrained environments and also results in slow delivery of security updates, etc... but guix doesn't have the middleman situation, since it starts out libre by default <lfam>It's the idea that those distros can only ever be *less* secure than the upstream distro <paroneayea>not true necessarily for some of its packages though (linux-libre and icecat), but the author makes the case that we should encourage the FSF / GNU to just focus on Guix <lfam>I think there's a social issue, too. It's hard to get large numbers of people excited about a distro re-spin whose only distinguishing characteristics is that it's 100% free. Whereas Guix is interesting in its own right. <lfam>But it's valuable to have those distro variants anyways. Some people want or need to use a familiar distro type rather than something new <paroneayea>I'm not necessarily claiming Brett is right, but in a selfish interest-validating way it was nice to hear <paroneayea>and also it was an interesting argument, since Brett is not a Guix user (yet... I think they like the design) <lfam>I've only just started the video, but I think I'll agree with him based on my reading of his slides a couple days ago ***jonsger1 is now known as jonsger
<lfam> <https://hydra.gnu.org> just started returning 502 Bad Gateway for anything I try to do. The weird thing is that it returns immediately. <lfam>Ah, now it's back to loading slowly <civodul>so far 'guix publish' seems to be doing better, or maybe it just leaks less ;-) <lfam>It probably doesn't help when I open a couple dozen jobs all at once in different browser tabs <civodul>right, though we'd like it do handle that <lfam>Yeah, it *should* not be so onerous :) <lfam>If I waited for each tab to load before opening the next one, it might take hours, so I do it this way <lfam>Well, we finally have a libgc substitute for ARM, so that's progress <civodul>ACTION tries "make assert-binaries-available" minus mips64el-linux <lfam>efraim: Can you re-send the parallel XZ patch? It got mangled when forwarded to guix-patches <efraim>lfam: I think I can, I'll try sending it from my other machine <efraim>I'm on a plane waiting for takeoff :) <lfam>efraim: It's not urgent; I was able to recreate it easily <civodul>i'd like to have it in the repo so we can make progress on this front <lfam>I can put one together, though. It shouldn't be too hard. <civodul>like a gpgme context wouldn't allow you to choose a keyring?! <lfam>Yeah, the gnupg developers think that custom keyrings are a bad idea, although I don't fully understand the issues yet <lfam>I think that for a use case like ours, it should be fine <lfam>I think their objections are for cases where end-users would find themselves trying and failing to manage multiple keyrings <civodul>"We try to deprecate the use of the --keyring option" <lfam>It sounds like it was never supported in a satisfactory way in gnupg <lfam>that it is not possible to keep a consistent vewi on the localally availabale <lfam>keys when a user is allowed to remove and add storage at will without gpg having <lfam>any control over it. You may end up with duplicated keys and gpg will only <civodul>but that's the same problem with $HOME <lfam>Anyways, the reason I didn't go and assemble the keyring yesterday is that I was confused enough by that discussion to become distracted and do something else <civodul>thanks for the pointer though, it's an interesting thread <lfam>I mean, I respect their attempt to simplify the whole GnuPG system. The complexity is overwhelming <lfam>And that means that people either use it incorrectly, or don't use it at all <civodul>for our purposes, the only reason to use it is that Git integrates it <lfam>So, I can take all the keys from Savannah. We should also include the key that thomasd used by accident recently, and keys of people who have left the project (I still have those keys). I'll also make a README explaining where the keys came from, things like that <lfam>Right now I'm measuring the effect of efraim's parallel XZ patch <lfam>The linux-libre tarballs are a good test case, I think' <efraim>If it is compressed with xz in parallel then it can be decompressed in parallel, but if it is compressed single threaded then it'll only decompress on one thread <efraim>According to the documentation it doesn't matter how many threads the compression happened on, as long as it was more than 1 <lfam>I'm going to benchmark creating our patched tarballs, and also unpacking them in advance of building linux-libre <lfam>efraim: Is it possible to check if a tarball was compressed in parallel? <civodul>lfam: and instead of a keyring in gpg's binary format, perhaps we just need to store the ascii-armored keys <lfam>Yeah, that will be better for Git <civodul>apparently it's a gpg keyring, which is what wk recommends against