IRC channel logs
2017-06-18.log
back to list of logs
<reepca>Ah, finally, internet was out for awhile there. OriansJ`: CMOVE shouldn't zero the stuff being copied from, contrary though it may seem to its name. <jlicht>I finally got my uni vpn working on GuixSD :) <catern>is ludovic??? i never realized when talking to him :) <catern>I think I have referenced asking Ludo what he thought of something, when talking to him :) <eacces>is using guix without internet access a thing? in debian, i created a [rather large] local package mirror. in guix, i'd create a local source or substitute mirror I presume; is that a userfriendly thing to do at the moment? :) <OriansJ`>reepca: well that is an easy thing to fix <OriansJ`>reepca: also, I'll be adding a couple things so that it will automatically allocate memory space more efficiently when larger memory is given <reepca>OriansJ`: and that will involve changing up where stack bases and such are? <OriansJ`>reepca: not a problem, given that it is possible for the forth to simply lookup the total memory available and do some simple math <reepca>Aye, as long as it knows how much there is and the rules that govern it <OriansJ`>reepca: and that will be provided be the new HAL_CODE being added this weekend, along with some logic to error if it is too small <OriansJ`>(as the users can always put --memory=1K) <OriansJ`>reepca: I do wish to thank you, as you are single handedly responsible for most of the major improvements in my forth <OriansJ`>oh by the way, the CMOVE is fixed and patches are up <reepca>did you see my earlier suggestion about EXECUTE? <reepca>Basically R12 needs to be set in order to make colon definitions able to work well with EXECUTE. I propose we make EXECUTE take a pointer to a pointer to the assembly, that way we can set R12. It'll also make it work nicely with '. <OriansJ`>reepca: so put pointer in R12 and jump the to address loaded from that pointer? <OriansJ`>as R13 is the next instruction to be executed and R12 is the instruction currently being executed <OriansJ`>or more precisely, the pointer to the next address to be executed <reepca>OriansJ`: yeah, that seemed to work when I tried it like that <OriansJ`>reepca: no problem, that will be up shortly <OriansJ`>And Stage0 release 0.0.8 is now available with all of the wonderful improvements and bug fixes made possible by reepca's help <efraim>got efl updated locally to 1.19.1, now testing python-efl 1.19.0 and the other packages that use efl <jsierles>i'm trying to do a 'guix pack' and getting a strange error <jsierles>error: executing `/gnu/store/vir3lrwqy50pr8fkaf3m091dgbrja2n6-guix-0.13.0/libexec/guix/substitute': No such file or directory <jsierles>error: executing `/gnu/store/vir3lrwqy50pr8fkaf3m091dgbrja2n6-guix-0.13.0/libexec/guix/substitute': No such file or directory - guix pack: error: build failed: unexpected EOF reading a line <boskovits>guix system init, gives me a zombie, and keeps writing updating list of substitutes <boskovits>if i get this workin i will try to look into jsierles's problem. <jsierles>sorry i can't help as i don't use guix system :) <jsierles>it's any package really. I think the actual problem is that i'm mounting the store from the filesystem into a docker container <jsierles>think something is busted with that. so now trying without the mount to see if it helps <boskovits>ok, tell me if you still need assistance, it would to me a while to replicate your setup, it seem. <rekado_>jsierles: it tries to execute “substitute” to fetch binaries. <jsierles>rekado_: yes, it does, i tracked it down to 'bash' which substitute uses to run <jsierles>which doesn't make much sense. it's literally running guix fresh after unpacking it from the tarball <rekado_>I don’t know what “it’s missing from dynamic libraries” means. <jsierles>ldd reports two of bash's dependencies missing <jsierles>seems to work now i'm not mounting the volume <jsierles>so probably something to do with permissions or ownership <jsierles>i'll look into that more and report back. <boskovits>I am try a guix system init, but got a [.guix-real] <defunct> zombie process. <rekado_>jsierles: I don’t think it will be printed infinitely. <rekado_>it just prints this for each substitute query <jsierles>rekado_: so you think that would be faster if i setup a local substitute server? <jsierles>i think i asked what would be involved for that. but didn't note it :) <rekado_>a local substitute server could either be a simple HTTP mirror/cache or a build server with Cuirass. <boskovits>can we somehow see the query the message corresponds to? <rekado_>I don’t think so. Maybe by looking at the arguments to “substitute” (e.g. in ps) <jsierles>rekado_: ah right. you sent me a copy of nginx config for reverse proxy. that's probably good enough <jsierles>though running cuirass might be interesting too. how does it work for hydra? <boskovits>rekado_: do you have any idea about this [.guix-real] <defunct> zombie? <rekado_>boskovits: who started “.guix-real” or the shell wrapper? It’s the parent’s task to reap the process. <rekado_>jsierles: hydra doesn’t use cuirass, but bayfront does <rekado_>bayfront’s configuration can be found in the guix-maintenance repository <boskovits>what i am doing is a guix init system, as the last step of installation instructions. <boskovits>when i got there i will check out the process tree and report if it still persist. <boskovits>worst is, that it is not always in the same part of the process... <rekado_>boskovits: is this an actual problem? Do you get an error? Or is it just that guix leaves a zombie process? <boskovits>I will wait a little more to see if I really get past the lot of substitute messages <boskovits>Process tree looks like: guix-daemon->guix-daemon->guile <boskovits>this is currently my only process running as user guixbuild <rekado_>boskovits: is there anything special about your environment? <rekado_>boskovits: please send details to bug-guix@gnu.org <boskovits>i am doing it in a virtual machine, if that counts.. <mekeor>hello guix! any link/info/help on why `guix pull` gets stuck at "updating list of substitutes from [...] 100%" (on an freshly installed GuixSD)? <mekeor>oh, this was already asked before, today, i think <mekeor>at least, some similar question was asked by boskovits... <mekeor>boskovits: did you get past the substitute messages? <mekeor>i already let `guix pull` run over night for like ~8hours and it still hadn't finished afterwards; instead, it was still printing "updating list of substitutes [...] 100%". so i don't think that "it just prints this for each substitute query" like rekado_ said before in this channel today. <janneke>ugh, 8cc uses anonymous unions with anonymous structs inside <janneke>yet it claimes to use a minimal C (okay, C11) feature set needed to compile <rekado_>but a couple of commits back it seems fine <mekeor>rekado_: (how) can i pull a version of guix which works? :/ <mekeor>i installed GuixSD yesterday (on yet another machine) using master-version of guix, i think <OriansJ`>janneke: I'm thinking it more provides a minimal C <mekeor>rekado_: i'm reporting a bug, ok? <janneke>OriansJ`: it says: 8cc is a compiler for the C programming language. It's intended to support all C11 language features while keeping the code as small and simple as possible. <janneke>i read `simple' as: do not use esoteric language features, but i may be wrong here? <janneke>OriansJ`: i haven't been working on Mes for days...struggling to take on a next step <OriansJ`>janneke: Its ok, I've been using this week largely to work on ideas and improve the forth <janneke>OriansJ`: it should be possible now to look into removing mes.c and to replace it with annotated hex2 (or hex3) and create the <bare iron> <janneke>*<bare iron> -> <stage0> -> <mes> -> ...? thing <OriansJ`>janneke: sounds like a reasonable step in the right direction <janneke>...and i was hoping you would help me with 1) the build process to get there and 2) looking at mescc's current annotations in hex2/hex3 and give some directions of what you think we would need there <OriansJ`>1) certainly, 2) I think hex2/hex3 is perhaps a little too low level for proper auditing large programs. And hence I am going to be giving you a M0 definition file which will enable you to output commented assembly <janneke>OriansJ`: ah forgot about that -- surely i probably meant to say a M0-style hex2/hex3 file :-) <janneke>so we have another step: changing Mescc's hex output from x86 into M0 -- great <OriansJ`>you'll be able to put ADD_eax_Immediate instead of 66 05 and thus people will be able to more quickly read our commented output <OriansJ`>and you'll be able to output strings as ""Hello, Mescc!" instead of 48 65 6c 6c 6f 2c 20 4d 65 73 63 63 21 00 <janneke>OriansJ`: wow all Mescc needs in M0 -- and only 55! <OriansJ`>janneke: almost, those 55 represent the hyper majority of x86 instructions used by Mescc <janneke>the strings bit looks real simple, although it scares me a bit wrt the compiler changes that would be necessary -- i could do with an example there <mekeor>feel encouraged to classify the bug as important ;) <OriansJ`>janneke: if you would like I could make a patch for you to play with <rekado_>mekeor: Are you using Guix from git? <mekeor>rekado_: uhm, no, i just use `guix pull` but i was thinking that was pulling the master-branch of the git-repo. doesn't it? <rekado_>for a quick fix could you try pulling from a previous commit? <rekado_>for example 01049bb0c1f3f69afb8d1782f99ca5c0adaed946 <mekeor>rekado_: sure, how do you pull a certain commit? <rekado_>not quite sure about this, but I think this might work <mekeor>rekado_: that command get's stuck at updating the substitutes, too <rekado_>I noticed that the latest versions after 01049bb0c1f3f69afb8d1782f99ca5c0adaed946 seem to perpetually check for substitutes. <boskovits>I could not get past the substitute messages <rekado_>mekeor: what version of Guix are you using? <rekado_>mekeor: could you maybe use an older version of Guix from the store? <rekado_>(here it would be helpful if we had a profile instead of just a single link .config/guix/latest) <rekado_>mekeor: I guess you could also try adding “--no-substitutes” <efraim>So that shouldn't be a reason for it to hang <mekeor>efraim: can you reproduce this bug, too? <efraim>I'm not at home ATM but I didn't have a problem a few hours ago <mekeor>rekado_: the thing is that i can't use an older version of guix from the store, AFAIK, because i installed GuixSD yesterday. (and i ran `guix pull` before i ran `guix system init`, so the latest version of guix was installed on my system.) <mekeor>efraim: a few hours ago? hmm. maybe you weren't using the latest version of guix? <mekeor>i have this problem since yesterday. <efraim>Before that I ran 'guix pull' about a week before <boskovits>I have this problem with the image downloaded right from the downloads side <boskovits>i try the download again, checking the signature and trying a fresh install in a vm. <efraim>I've SSHed in and I'm running guix pull now <boskovits>Guix pull failed for me with the same phenomenon <mekeor>rekado_: i think i'm using guix-0.13.0.2. (which i found out by grepping /gnu/store for "guix" and there is only one guix-directory there. but `guix --version` didn't tell me a version number.) <efraim>I'm now at 'copying and compiling' <mekeor>efraim: let's see if `guix pull` will work after `guix pull` <efraim>I ran it last a few hours ago, the time before that was a week <rekado_>repeated messages about fetching substitutes are normal (though admittedly confusing). <rekado_>boskovits: the latest release didn’t have this problem. <OriansJ`>janneke: to kill 2 birds with 1 stone, your example will be a hex assembler (that supports # comments) with its definitions prepended <janneke>OriansJ`: the problem I still want to solve is gdb'ability of hex2 output before letting hex3 go <rekado_>mekeor: have you tried “guix pull --no-substitutes” ? <OriansJ`>janneke: have you reached out the the gdb devs for help? <rekado_>it’s just a guess. If this *does* indeed fix your problem it would be good to send that info to the bug report. <janneke>OriansJ`: good idea, no. i know that adding symbol and string tables fixes it. hmm. <OriansJ`>janneke: so lets add symbol and string tables to hex2 <janneke>OriansJ`: that's what i was thinking...but then we need to discriminate between text (functions) and data (globals) <janneke>OriansJ`: if we have these we only need a way to add a dynamic bit (these tables) to the elf header <atw>rekado_: any plans to package texlive 2017? <mekeor>rekado_: thanks for your kind help :) <rekado_>atw: I already have texlive-bin 2017 <rekado_>the texlive-tiny stuff is already using the sources from the 2017 release tag <mekeor>rekado_: will `guix pull --no-substitutes` build/compile all packages locally? that'd take very long time, i guess :D <rekado_>“guix pull” only builds the guix package. But you may need a couple of packages to build that package locally. <ng0>sneek: later tell atw: feel free to submit a patch for the Guix package. I know the homepage changed because I changed it. <sneek>Welcome back ng0, you have 3 messages. <sneek>ng0, catonano says: you can review even without commit rights. Just reply to emails, give your lgtm if you deem that appropriate <sneek>ng0, rekado says: Comments like “For possible past reviews search the guix-devel <at> gnu.org archive” make it less likely that a review will happen in time, because it takes extra time to find those past reviews. <ng0>sneek: later tell atw: but thanks for reporting <ng0>it's not like we have per-package maintainers here, changing a line is easy :) <atw>ng0: I would do it but I am away from my Guix system. Otherwise yes, I'd just do it myself <sneek>atw, ng0 says: feel free to submit a patch for the Guix package. I know the homepage changed because I changed it. <sneek>atw, ng0 says: but thanks for reporting <ng0>ok. I don't think it is that important for myself, I wanted to change it once I have figured out the best way to integrate fish extensions into Guix <ng0>even zsh extensions I use feel a bit 'anti'… if there was only a directory and not single file to point to <atw>a guix anti-pattern? <ng0>usually you just install extensions for zsh or fish though keeping them in $HOME in a directory, or through systems which follow the standards in directory layout <waynedpj>ahoy all. trying to install GuixSD and continue installation via SSH as suggested in installation instructions. however, passwd is not installed, part of shadow package i believe. trying to install binary via substitutes w/ command "guix package --install shadow" but it wants to build lots of dependencies from scratch, like the kernel? is there a way to simply install shadow as a binary package? using GuixSD 0.13 i686 <rekado_>waynedpj: binary substitutes for 0.13 should be available, but especially for i686 we are often behind in providing them. <waynedpj>rekado_: ah, you mean on hydra? OK, thanks. is it possible check the status of the available substitues? <rekado_>waynedpj: I think you can use --dry-run for that. It should show you what things will be downloaded and what things will be built locally. <waynedpj>rekado_: OK, that is what i was using to see what would be built. thanks again <ng0>atw: what I should do is redirection on the webserver. <catern>dear #guix, are there any *principled* solutions out there for the problems Guix/Nix solve, other than Guix/Nix? (fill in the blank of what problems Guix/Nix solve... it potentially solves a lot of things) <catern>I think Guix is the best of course, but it seems like there's not anything that even comes close <slyfox>i guess it depends on what problems you are interested in to solve <catern>i am happy to hear about solutions for any kind of problem :) <catern>(well, okay, except very practical ones like "working and stable desktop system with wide hardware support". I mean more theoretical ones like "software deployment" or "configuration management") <slyfox>i haven't used GNU stow myself but it sounded familiar <atw>slyfox: scooped me :P <atw>and I guess that the motivation behind container systems like docker is reproducible deployment <catern>well, docker is definitely not principled <catern>it's highly pragmatic, it just dumps a bunch of artifacts into a container image, it doesn't attempt to actually reproduce them <atw>yes. In talks, Chris, Dave, and Ludovic have stated that Docker does not adequately solve the problem <atw>if you freeze the state, you don't have to reproduce it <catern>basically I wonder if anyone other than Guix/Nix is trying to do better than Docker, though <catern>because this seems to be the only project actually trying <catern>everyone else is just building variations on "dump a bunch of objects in an image" <catern>docker, ostree, flatpak, snappy, etc. <catern>(ostree is slightly better of course) <ng0>maybe Redox OS catches up <ng0>last I checked they will rely on filesystem rollbacks <fps>with docker, how do you know what precise source versions the installed binaries come from? <fps>functional package management gives you more than reproducibility <fps>a copy of a file is reproducing it <catern>ng0: oh, well... that's a bit impractical, I don't think Redox will ever be usable for serious work, at least not for 5 or 10 years... not that there's anything wrong with that <slyfox>how do you know in guix where binary came from? <ng0>I made no point just a 'look at Redox OS' statement <fps>slyfox: you can trace its path all the way back to the bootstrapped compiler <fps>slyfox: and all sources going into it <ng0>it's sunday, I make no serious discussion points on sundays <fps>you can inspect the graph of inputs to the binary in question <slyfox>fps: AFAIU for that you need not only binary but all the related store database <slyfox>and i'm not sure you can restore original .scm files <fps>slyfox: yes, but if i tell you this is the binary from /gnu/store/......-foo-1.10/ you can look up how it's derived and if you don;t trust it, derive it yourself <slyfox>you can derive is only if you have the same .scm sources <slyfox>(if we are talking about only a single string to a store path) <fps>guix is itself an input, no? <slyfox>basically my question is. given a store path, say "/gnu/store/yxkzs7day0d4xq8dwj808pqsm1wzis5n-bash-4.4.12", how would i know which guix commit did i use to build it? or, which commits could actually produce it? <fps>i think the derivation is an implicit input to itself.. <fps>the derivation is produced from the .scm. so if you change the .scm you get a different store path.. <slyfox>.scm files clearly survive whitespace changes <fps>ok, if two .scm files only differ by changes that do not change the derivation <fps>then you get the same store path <fps>those two .scm files are completely functionally equal though.. <fps>but lemme check. i'm not sure i'm right about the derivation being an implicit input itself <catonano>catern: Look, I am a hobbyst. But I am intrigued by DAT. It's for scientific endeavours, so less general than "deployment" as it's intended in enterprise environments. It aims to reproduce not only setups but whhole computations. It versions large datasets but it also treats execuutable binaries as if thhey were data too, so it versions them and distribute them along with the data to be fed to thhe computation. I may have grossly <catonano>misrepresented something, youu can take a look at theiir website <sneek>Welcome back catonano, you have 1 message. <sneek>catonano, davexunit says: the haunt blog is in the haunt directory. I haven't gone back and deleted all the pelican stuff yet. <catonano>davexunit: thanks. I erased the folder of your stuff now, I don't remember wether it contained a "hanut" subfolder. How could I reach your haunt folder, anyway ? <catonano>catern: too bad it's done with nodes, as far as I understand <slyfox>if it's more popular maybe it's not that bad <catonano>slyfox: nodejs stuff is extremely hard to port into Guix, becauuse it doesn't adhere to the buildability guidelines <catonano>slyfox: a rant: it's a bunch of stuff crammed together in order to make the damn thing run right now <slyfox>i tried to build guile on ia64 and failed miserably <catonano>observing the sorry mess it is was the last blow in making me rreconsider the whole web <slyfox>what are "buildability guidelines"? do you have a link? <catonano>so DAT is a very interesting project with a very original cut, bt it's built on a basis that's not reproducible at all <catonano>slyfox: no I have no specific link. It's just the compatibility with the GPL: the software must be buildable. More often than not, nodejs projects are not buildable. <catonano>Mike Gerwitz might help you to clarify this <catonano>he raised the point himself a few months ago on the guuix dev mailing list <catern>catonano: it seems interesting but only for data... I am not excited or interested in commiting executables to source control - that's the Docker/OSTree style <catonano>catern: right. Thanks for clarifying. I told you I could ave misrepresented something <ng0>sneek: later tell efraim: One thing I haven't figured out in E21/Enlightenment is that one Webbrowser extension behaves very weird thinking the binary path is /usr/bin, while all other WMs/DMs are okay. <ng0>sneek: later tell efraim: Where 'are okay' means they are not amnesiac about the path, it just works with them <ng0>sneek: are you still there <catern>okay, one example of doing better than Docker but not as good as Guix: unikernels <thomassgn>Hi, trying to create a derivation/definition for fpm2. I get " source expression failed to match any pattern in form (%modify-phases phases* (add-before (quote configure) (lambda () (let ((potfiles-include (open-output-file "POTFILES.in"))) (display "data/fpm2.desktop.in\\nfpm2.glade\\n" potfiles-include)))))" and I don't understand what part of that it fails to match... The current code can be seen at <catonano>thomassgn: whhen this appens to me often it's a issing paren <catonano>thomassgn: the name of the pase is missing <catonano>the phhase you are addin should have a name <catonano>like: (add-before 'configure 'pre-configure <rekado_>thomassgn: catonano is right, you need to do (add-before 'configure 'something-else (lambda …)) <thomassgn>catonano rekado_ Thanks! Just saw the message and tried. Now onto next error :)