<gazon>say i'm looking to copy a package definition so i do: find /gnu/store -type f -name services.scm; and I get several hits including two /gnu/store/...-guix-latest/gnu/services.scm; presumably one of them is the real guix-latest, but how to tell? <gazon>or to put it another way, how to find the most recent package definitions? <davidl>gazon: the file dates aren't different? (ls -al) <gazon>davidl: those particular files have the same date, and content. <ng0__>can I put software which absolutely depends on each other into one commit? <rain1>ok, finished my research: pcc cannot build gcc 4.7 <ng0__>I think I can, I have seen similar commits in the past <ng0__>oof, many dependencies for xfce-panel <OriansJ>rain1: we knew there might be a few more steps between us and our immediate goals but the journey awaits <rain1>ive created a debian VM to try compiling various C compiler <rain1>pcc is able to build tcc! trying to build gcc using tcc just now <OriansJ>rain1: you might want to document on the wiki, what compilers can be compiled by what compilers ***Piece_Maker is now known as Acou_Bass
<OriansJ>rekado: we might take you up on that offer, so that we don't spam up our current mailing list with updates. <OriansJ>janneke: you don't have to support anything in MES unless you want to. Not to mention we can abuse the shit out of astyle to force all code to fit our desired pattern <OriansJ>bavier`: thank you for taking the time to look at stage0 and I appreciate the feedback on the SHA256SUMS :D <OriansJ>And sorry about not responding sooner, I got some inspiration for cross platform porting that I am playing around with <bms_>What actually is this wiki? <OriansJ>bms_: a wiki to collect information about bootstrapping and projects of interest/value in that regard. <rain1>it's actually really interesting, we have the source code of all this stuff but we cannot build it without binaries (yet?) <bms_>Huh... cool! Can I try to help? I've never actually worked on a wiki before. <rain1>of course bms_, you can create an account <OriansJ>bms_: we are always welcoming to people who want to help :D <bms_>I've had a large idea/project in my head for a while and I've never really tried to implement it. I think it fits well into this topic. <rain1>well please tell us about it? :D i would love to hear <bms_>Okay... here goes. It's not quite original and I've gathered inspiration from a lot of places. I'm also probably not qualified to undertake it, but I like to learn as I go. It's also not completely fleshed out in my head, but the plan goes something like this: <bms_>Tell me if at any point I say something wrong, by the way. <bms_>So, I start with a (very) small implementation of Scheme in Assembly (this has been done before, of course. The most recent thing of this sort that I've found is no longer online). I only add the very basics required to adhere to the standard. <bms_>In this Scheme, I write an assembler to assemble the interpreter. (It's kind of a chicken-and-egg thing). From there, I write a VM, also in Assembly (or if possible, my Scheme) for a simple processor and instruction set of my design. <bms_>Of course, that's a lot to undertake, but just so I can make it even harder, I need to implement this processor in hardware. (Preferably discrete parts and ICs, but that could take years so maybe just with FPGA boards I still need to look into th <bms_>Now, and I should have said this before the CPU part, I need to write an OS in Scheme and Assembly to run on my CPU. <rain1>yes it sounds great! a lot of the parts of that could be very useful to bootstrapping guix too <bms_>It's a huge project, probably one that I'll never finish, but I like to try those sort of projects. <bms_>That's true. Even if I don't finish it, this wiki would probably be the best place to put my research and document my progress. If I do get anywhere, I want to keep some sort of journal for future reference for myself and others. <bms_>I've had this idea for a while and I've been terrified to actually try it. But I think this prompted me to start. <rain1>have you seen the mes project janneke started? <rain1>there is qquite some overlap, he has been implementing a scheme implementation and not an assembler in it but a c compiler <bms_>I'd like to see if I can implement R7RS-small. <rain1>you certainly could, although a lot of it would not be needed - it's okay to implement a subset of the spec <bms_>Yeah, that'll probably be what happens. I'm going through it now just to sort through what I need and don't. <OriansJ>bms_: I love the assembler in scheme idea <bms_>I don't think I'll be able to complete this alone. I won't ask for help, just going to say that if anyone ever wants to help, I'm open. <OriansJ>bms_: if you take the time to make it work with octal instead of hex, you'll rather easily have a basic x86 assembler <rain1>ive learned very very much just from reading some of OriansJ's code, thank you <bms_>I've never looked at octal at all... hmm. <OriansJ>rain1: oh, I'm improving the stage0 notes on the wiki <OriansJ>bms_: basicly instead of supporting 0x00 through 0xFF, you need to support 000 through 777 <OriansJ>(actually less because you only need to accept 0 through 255 but I forget the octal for 255) <OriansJ>bms_: plus writing it in scheme should actually allow the supporting of vastly superior macro definitions <OriansJ>hence, I am excited to see you work on that :D <bms_>I'm excited to work on it. <OriansJ>bms_: please keep me updated, I'm rooting for you <OriansJ>bms_: as for the hand made computer using discrete logic, are you open to collaboration? <bms_>Yes, I am. That's the part I'm really unsure of myself with; I'm not all that experienced with hardware in that sense. What do you mean by collaboration? <OriansJ>bms_: well, I was planning on implementing the stage0-vm spec in hardware. (Verilog->FPGA->Circuits->TTL->DONE) and I needed someone to sanity check my work along the way. <OriansJ>bms_: I really want you to achieve your goal, since it looks like it shares a lot with mine. But I must be honest, right now my goal is finishing the path to the GCC bootstrap. So, hardware development might be a bit slow. <bms_>That's fine. I'm not nearly to hardware development so you're already ahead of me. Thanks for the support too! <rain1>right now my very rough picture... <rain1>hexassembler -> macro based assembler -> .... -> mes -> .... -> gcc <rain1>i think there will be a short chain of 2 or 3 C compilers leading up to gcc <OriansJ>bms_: Always here to help and if you see anything that might help with the hardware development please throw it my way <rain1>and we may need to implement an interpreter for the knight VM in x86 <OriansJ>rain1: we already have an interpreter, but right now it is written in C <OriansJ>rain1: porting it to assembly is about 44 hours of work if my math is right <OriansJ>hence the request for others to review it and see if we can make improvements or if I missed anything important <rain1>but yes overall it is really exciting, to see how to bootstrap the GNU os from a very very tiny core <OriansJ>rain1: Ideally a core that can be bootstrapped on a lot of arbitrary hardware platforms with moderate effort and nothing advanced <OriansJ>rain1: fyi hex0, hex1 and hex2 support both # and ; for line comments (So that I can avoid that argument with people who write assembly) <rain1>well i have just been working towards a x86 implementation of hex2 in hex2 - ive got .bss section sorted and am reading in labels, almost there <OriansJ>rain1: minor note, librejs does complain about viewing the site. <brendyyn>Who should I report corrupt hydra substitutes to? <reepca>Hmm, is there a way to install the radeon implementation (or whatever it's called - the one for AMD stuff) of mesa instead of llvmpipe? <reepca>err radeonsi, that's the one I think <reepca>Oh, according to Wikipedia that requires proprietary microcode. Never mind then. <reepca>Now I wonder which vendors don't require proprietary microcode... <OriansJ>reepca: sadly that list is growing smaller by the day for high performance chips, however is a wonderful growing list of FPGA designs that are becoming available <reepca>I don't suppose it'd be feasible (ignoring legal for a moment) to try to reverse-engineer it? <OriansJ>reepca: actually it is entirely legal to reverse-engineer it, however you would require a separate person who has never inspected the binary to write the replacement based on the spec that you write while reverse-engineering it <OriansJ>reepca: it also probably could be done with a couple months of work <OriansJ>there are hundreds of blob free, reverse engineered firmwares for graphics cards made by the community. Usually when the vendors ignore or snub linux developers who want to use the hardware they paid for. <reepca>any for the AMD stuff from about 3 years ago? <janneke>hi OriansJ! Yeah, possibly we want to do something on tcc, fork, whatnot. <janneke>you have `seen' that Mes now has two ascci output stages, a preprocessed (and parsed) ast, and the object style lambda's? <OriansJ>janneke: which by the way should help debugging <OriansJ>although honestly I'm still trying to figure out the best way to attack the performance problem. <janneke>OriansJ: when I last looked at your assembler.hex2 output, i looked too briefly and saw x86 with labels <janneke>but it's labels+your VM codes, right? <OriansJ>janneke: actually it is labels + any hex you want <OriansJ>it also supports two types of line comments ; and # <OriansJ>it has 16bit relative (@), 16bit absolute ($) and 32bit absolute (&) support <OriansJ>I've taken rain1's advise and will be adding a few extra features to help it work better for x86 instructions <OriansJ>I've further been looking into guile and we might save ourselves some trouble by adding a couple minor steps <OriansJ>With it, having MES will allow you to get guile and having guile will allow you to have MES. Thus you can focus on the fun work <janneke>Great! So I can work on changing this -> ("main" <janneke> (lambda (f g ta t d) (list #x55 #x89 #xe5 #x83 #xec #x40)) <janneke> (lambda (f g ta t d) (list #xb8 #x3 #x0 #x0 #x0)) ... <janneke>OriansJ: hmm, I didn't grasp you meant the guile eval.c target as such a pragatic one <janneke>you mean that if mes can compile eval.c, we can run bootstrap/run guile? <OriansJ>janneke: the advantage of Hex2, is you don't even need to resolve references in your C compiler, so you can output fun things like 48 c7 c0 &my_pointer <OriansJ>janneke: correct, as eval.c is the heart of the guile bootstrap <janneke>yeah sure, the c compiler can get *much* simpler-->must be done <OriansJ>janneke: do you mind if I add a directory to MES to include some bootstrapping tools that would be required on Linux? <janneke>OriansJ: what kind of tools would be in there? <OriansJ>minimal tools required by the guix bootstrap, designed to buildable by MES <janneke>OriansJ: ah yes, I haven't given that any attention yet; it's another important step to close the loop <OriansJ>more, a text editor, tar, mkdir, execute_enable, xz and possibly a trivial enough bash replacement to allow the bootstrapping of bash <janneke>OriansJ: actually, that's a great idea -- if we are taking actual steps towards actual Guix bootstrapping that could create/enable much easier involvement of others <OriansJ>janneke: plus by having MES only having to focus on leveraging guile, MES should get a lot simpler of a bootstrap which should allow faster development and less waiting to get started <janneke>wow, i just see what bms_ wrote -- scheme in assembly, that's very much like Mes! <OriansJ>janneke: it is exciting times, more and more people seem to want to build the very things we are working on. <janneke>sneek: later tell bms_: wow! hi! would be nice to chat some time (soon). i don't really care all that much about the current Mes Scheme intepreter prototype in C; it could stay like this, could be changed into annotated assembly, will most probably be rewritten to be a Scheme compiler in LISP -- but you gotta start somewhere! <OriansJ>janneke: speaking of which, you'll have some patches to pull from me shortly <OriansJ>Some of the first changes I'll be making are to the build process, eliminating the binary blobs and update the .gitignore to prevent accidential addition of binary files <janneke>OriansJ: sounds great...but if you do that you'll want to look at my wip-tinycc branch <janneke>i'm building everything using two extra stages now, -E and -c <janneke>the build process is currently only targeted at pragmatic mes development/hacking, that may need to change :-) <OriansJ>hmmm, I might need to do some rework then but no worries <janneke>the `mesmes' binary is a halfbaken attempt at bootstrapping anyway -- and i/we should eliminate the need for read-0-32.mo [probably simply include reader.c in the Mes build too] <OriansJ>However, since we are just going to use guile as the interpreter for simplicity. Shouldn't we make the lisp source files have the standard scheme extension (.scm) ? <janneke>OriansJ: i'm not sure what you mean there; currently all of mes (.mes/.scm) runs with Guile and Mes alike; I guess we want/need to support both at least until we have Guile bootstrapped <janneke>we need to support running with Mes, and want Guile for hacking <janneke>having said that, yes the .mes extension was a mistake <janneke>but there's the (mes-use-module ...) vs (define-module () #:use-module) thing that would need to be resolved first? <janneke>OriansJ: included your first commit, added GNU style changelog to commit message <janneke>been working on a 4y-dead repo without checking :-) <amz3`>how do you compute the hash of git repository? <rekado>amz3`: with “guix hash -r -x dir” <amz3`>I am trying to package guile-wiredtiger <amz3`>and maybe I will bump wiredtiger to 2.9.2 <amz3`>I have this error when trying to build my package: <amz3`>fatal: reference is not a tree: 809d300d649f0f7ceaa5a9ba1269de31b77dc918 <amz3`>it's ok i by passed the error <amz3`>now I get a permission denied when using substitute* <amz3`>ERROR: In procedure mkstemp!: Permission denied <amz3`>btw I don't like the fact that my builder is not a procedure, I don't know where are coming from the %build-inputs and other variables <rekado_>amz3`: why don’t you use the gnu-build-system? <amz3`>because it's not a based on autoconf <rekado_>gnu-build-system does not include autotools <rekado_>it’s for the usual ./configure, make, make install. <rekado_>if you don’t have ./configure then just delete the configure phase. <rekado_>oh, I see. Your Makefile actually only consists of “make check” <rekado_>it would be nicer to have the compilation and installation in the Makefile. (Since you’re upstream…) <rekado_>amz3`: with other build systems (other than trivial-build-system) build phases are just regular procedures. <amz3`>I will put compilation and installation in Makefie <rekado_>the error you get is from trying to modify a file in the store that is not available at build time. <rekado_>amz3`: it’s there but you cannot modify it. Everything in the store is immutable. <rekado_>since you’re checking the source out from a repository and that’s the result of a derivation, the source tree ends up in the store <rekado_>the trivial-build-system does the least amount of work, which is why it’s a bit difficult to use it properly. <amz3`>so you recommend to compile and install with the Makefile <amz3`>and substitude the dynamic link path using the package definition in a custom phase? <amz3`>I've been procrastinating on this stuff for so many months <slyfox>if the targall is packed by lzip. does lzip need to be specified in native-inputs? <rain1>unfortunate: gcc 4.7 is NOT compiled by tcc <brendyyn>slyfox: Other packages use it, so the answer is probably yes <amz3`>I am experimenting with packaging like rekado explained to me above with a simpler package <amz3`>and I get the following error: <amz3`>This is Ian Price's r6rs packaged version of miniKanren, which deviates <amz3`>slightly from miniKanren mainline. <amz3`>guix build: error: build failed: derivation `/gnu/store/gqj31aaph5qw5c2gvy358458pdhvaakm-guile-microkanren-20170527.af005ffc-checkout.drv' has incorrect output `/gnu/store/7m8knxvfhyvg58i39i8qav734kgq4npw-guile-microkanren-20170527.af005ffc-checkout', should be `/gnu/store/f9zxsfa6pqgp7z34pr3s7z1fzqiajsh9-guile-microkanren-20170527.af005ffc-checkout' <ijp>amz3`: what's the deviation, just that it is slightly out of date? <ijp>amz3`: I'm just trying to remember if I made any purposeful incompatible changes to it <amz3`>ijp: I guess you speak about microkanren vs minikanren <amz3`>ijp: microkanren is another implementation, a smaller implementation that is not fully documented yet <amz3`>it's not compatible with minikanren <amz3`>I forgot about the hash thing <epronk>Hello. My name is Eddy. I'm new to guix. <epronk>I got this error: cannot build derivation `/gnu/store/i3gbiskv59j5pcxcl68bjp1nvchjppb0-subversion-1.8.17.drv': 1 dependencies couldn't be built <epronk>I installed guix from binary on Ubuntu. I forgot step 7 in the docs so it started building instead of pulling binaries. <rekado_>epronk: there’s more output than this, isn’t there? <amz3`>epronk: can you paste the full output of the command please? <epronk>phase `check' failed after 189.9 seconds builder for `/gnu/store/61ck646jl3sb57v154ixixcb5nsbwl5p-coreutils-8.26.drv' failed with exit code 1 cannot build derivation `/gnu/store/i3gbiskv59j5pcxcl68bjp1nvchjppb0-subversion-1.8.17.drv': 1 dependencies couldn't be built guix package: error: build failed: build of `/gnu/store/i3gbiskv59j5pcxcl68bjp1nvchjppb0-subversion-1.8.17.drv' failed <amz3`>epronk: use dpaste.com or something and copy/paste the terminal output in the textarea, submit and paste the link that is provided by the website <rekado_>epronk: this means you’re building coreutils from source and that failed. <rekado_>epronk: it’s probably better to use binary substitutes from our build farm. <janneke>epronk: you can [re]do step 7 any time, like now <epronk>yes, but then there's that voice that wants to know what failed first. <OriansJ>rain1: sorry to hear that tcc couldn't build gcc, keep searching otherwise we might have a bigger job on our hands <rain1>yes.. it has been done in the past (it says on wikipedia). I've asked the tcc mailing list if they know <janneke>OriansJ, rain1: ouch, i missed that. which gcc version did you try? <rain1>4.7.0 based on the recommendation from bootstrappable.org <rain1>perhaps a slightly older one will work though <rain1>also I confirmed that pcc can build tcc <OriansJ>janneke: thinking further, when I modify the makefiles I'll create 2 separate build paths. One using MES.c to bootstrap everything and another using guile to help people get productive much faster. That way those who want the minimal dependency have it and those wishing to make MES a better C compiler can get started faster <janneke>i made the mistake of using a different extension for both <OriansJ>janneke: or we could simply only use the .mes extension for files only needed by the mes.c bootstrap <rekado_>epronk: “File name too long at -e line 2” <rain1>yes it is not looking good... so far no compilers can build gcc. <rain1>but maybe it can be done with just the rigth configure flags or something <rain1>and tcc was not able to build pcc <janneke>yeah, i was thinking about that, what about gcc-1.3 or so? <ng0__>I have a question about this agetty topic and kernel-arguments we talked about 2 months ago. I'm writing a config right now for the server which requires this. when I need to pass more speeds(?) - link coming in ext mesage - do I just append it comma separated to the kernel-arguments? <rain1>it's a little scary.. i think this is an aspect of free software that has been overlooked and a lot of dust accumulated there.. <ng0__> "/sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt102" needs to be passed <ng0__>'("console=ttyS0,115200n8 gfxpayload=text earlyprintk=serial,tty,115200")) these are the arguments I currently have <ng0__>do I jus tappend the other numbers after the 115200? <OriansJ>janneke: GCC has gone through some major compatibility changes over time <OriansJ>rain1: I think, that it probably was something ignored for too long and now we might have to suffer slightly to start fixing it <ng0__>and what's this console=ttyS0,115200n8 what is the n8? <ng0__>leo gave it to me as an translation of what I wanted <rekado_>ng0__: “n” is probably “no parity”, 8 is number of bits. <ng0__>ah.. okay, I have no idea about baud. I just know what the provider tells me to use. <ng0__>how do the other rates fit into the picture? <ng0__>I could share the config I have now <rain1>janneke: I'm not sure how to get a version that old, seems to stop at 2.95 <OriansJ>rain1: you might end up needing to make a table, just to keep track of the C compatibility <rain1>Where `machine' is something like `vax', `sun3', `umax', etc. <OriansJ>rain1: I don't recommend going before 2.95 for GCC due to major changes that occured (also older versions didn't support linux) <OriansJ>hence EGCS existed as a fork of GCC to enable support for linux <rain1>I feel like the current best shot is making pcc (which includes a C++ compiler) build the latest gcc, the idea of using an older gcc was good but doesn't seem to be helping <OriansJ>rain1: worth a shot, we just need to then find the minimal requirements for making pcc <rain1>yeah its unfortunate that tcc wont build pcc, but this may be fixable <rekado>rain1: which qcc / tcc are you using to test this? Are they installed manually from source? <rekado>rain1: which qcc / tcc are you using to test this? Are they installed manually from source? <rain1>these are the results so far, with the versions and so on <OriansJ>today is going to be a long day of assumption checking by the looks of it... rain1 is checking our gcc build assumptions, I'm checking janneke's MES build instructions (I am really tempted to go old school for reducing the build complexity) <rain1>possibly of interest: TENDRA, Cint (interpreter), clang <OriansJ>rain1: I am trusting you to chase down that rabbit hole and find that narrow path of GCC bootstrap that makes janneke's MES job easier <OriansJ>although worst case we find nothing and end up having to turn MES into a world class compiler, which might be fun too :D <rain1>it seesm more and more likely... <OriansJ>I'm sure janneke would appreciate the help, not to be the leader of the most advanced C compiler written in Lisp on the planet. <ng0__>and 20 years from now, janneke was only known as 'bootstrap bill'-janneke :) <OriansJ>ng0__: more like hardcore lisp fanatic janneke, the man who knew lisp was better than C and certainly went about proving it... <ng0__>tales and songs will be written :) <OriansJ>ng0__: preferably in s-expressions :D <OriansJ>(Who-proved-lisp-better-than-C? of all else who tried) => janneke <OriansJ>but all joking aside, janneke is the only free C compiler in Lisp and the other C compilers in lisp where all written in Machine Lisp in the 1980s <lfam>OriansJ: So that there are not lots of old copies of the stage0 Git repo online, I took my fork off of GitHub. Now, it's just on my local machine, backed up for posterity :) <lfam>Thanks for making the pull request anyways! <OriansJ>lfam: thank you for valuing my work :D <lfam>It's really great :) I'm glad to see all this work at the bottom of the stack! <lfam>ng0__: Any luck with the console boot parameters? <catonano`>Arun committed my patches for Tryton. Pheew, it took an insane amount o time!! Abandoned packages, upgrades of Guix, many things conspired to delay this ! <ng0__>lfam I'm trying to find the missing parens :D <ng0__>after I'm done with that, it's crash and burn :) <ng0__>all parens are closed, yet guix system complains that it's not closed <lfam>They must not be closed all the way ;) <lfam>Maybe you have to add a smiley face -> :) <ng0__>super parens were okay.. it's the one thing I missed in lispf4 <ng0__>bosch-lisp had them apparently <ng0__>I wish I could afford a lifestyle where I'm living in the summer very far up north and in the winter closer south.. or at least somewhere with a decent relatively stable climate zone. <catonano`>ng0__: I was born on the shores of the Mediterranean. I discovered that i LOVE the Berlin winter and in summer I prefer the areas around the Mare Nostrum. So it's the other way around for me :-) <ng0__>I liked the times I spent in northern europe and on isle de la reunion <ng0__>I just dislike this sudden cold warm cold warm ping pong <lfam>I'm from a place without seasons. I like the wild changes I get in the North <ng0__>Is my spectrwm/scrotwm patch alright? I've been using it for some days now without finding a bug <ng0__>I picked it back up, indirectly. I'm learning this shepherd service system <ng0__>I wanted to be finished in january, but understanding is in the way. so be assured I'm working on it, I just had to sort some things out <ng0__>I have this darkhttpd and a gopherd service to test my skills on so that I can continue to debug the gnunet-service. Maybe it makes no sense, but I need to understand the behavior of services better. gnunet I understood on Gentoo. <lfam>Can somebody do me a favor? Please find and download the source of libtiff 4.0.8, and then paste the SHA256 or `guix hash` here <lfam>I'm asking because it's distributed over an unauthenticated protocol and there is not integrity checking mechanism available <ng0__>brendyn: in theory, and from out Gentoo service, some binaries must be suid'ed. so a service should work this problem out. <ng0__>I think I will test the service with gnunet from HEAD because I refuse to deal with 3 year old problems.. just hope that in the next 5 months the release happens. <brendyyn>I'm still just trying to get GNUnet to work in any form to learn to how it works ;) <ng0__>but in general it should be fine with 0.10.1, becaiuse it needs to start <brendyyn>Did you write guix-env.scm in the gnunet git? <lfam>brendyyn: Can you google it? :) <brendyyn>lfam: I don't know if you want tar.gz or .zip? <ng0__>yes. but I added a comment later on that I maintain more recent guix modules outside <brendyyn>0419mh6kkhz5fkyl77gv0in8x4d2jpdpfs147y8mj86rrjlabmsr <ng0__>so when you checkout my packages repository, which should move in location once the server is done setting up, you'll get gnunet, gnunet-gtk and others from git <ng0__>I haven't had the time to think of a multi-repository aware solution for gnunet.org git <ng0__>maybe just #f for hash check <brendyyn>ok, I was just wondering if it is the best way to build gnunet-git on guix <ng0__>it should work. but my repository hsa multiple variations.. like "all tests" "full dependencies and all tests" "no tests" etc <lfam>brendyyn: Thanks, that's what I got too. This is not a "real" check, but at least it helps raise the bar for a simple MitM attack <janneke>OriansJ: haha, and in a year's time there will be 3 lines of code left in Mes that janneke wrote ;-) <brendyyn>I disabled the flags like --enable-gcc-hardening and others since one/some of them was causing memory leaks <brendyyn>lfam: you could always check hashes in packages for other distros <lfam>brendyyn: Yes, although the distro I like to check (Debian) doesn't have this version available yet <lfam>It was released just a few days ago <ng0__>the build in the repo of gnunet is intendend for developers as far as I understand. <ng0__>alright, crash and burn.. reconfigure now :) <ng0__>ERROR: In procedure getaddrinfo: Servname not supported for ai_socktype <ng0__>or mabye I had it and forgot to document it <brendyyn>I don't thin I have any of the dht services for some reason <ng0__>maybe I can just copy stuff back and redo the reconfigure until it fails <ng0__>at least net is back.. open device surgery :) <ng0__>what could be missing when I do: <ng0__>mv /etc /etc-old2; mkdir /etc; cp /etc-old2/{passwd,group,shadow,gshadow,mtab} /etc/; rm /etc/mtab; cp -R /etc-old2/guix /etc/; cd /etc; ln -s /proc/self/mounts mtab <ng0__>and I get the above quoted ai error <lfam>ng0__: What program produces that error message? <ng0__>guix system reconfigure. on debian at 1984 vservers it worked flawlessly <lfam>Are any programs able to work over the network? <ng0__>well ssh still works for one <lfam>Can you read '/etc/services'? <ng0__>I need to copy this back, I have restored the old state of /etc <ng0__>there is no /etc/services (yet), it comes from guix, right? <ng0__>oh, no it is in the old etc of debian <brendyyn>Oh great, my GuixSD systems clock is 20 minutes out of sync <ng0__>lfam: should I copy this into the new (pre reconfigure) /etc ? <ng0__>now I get an getaddrinfo related error <lfam>brendyyn: By default, NTP won't make large clock adjustments. You'll need to force it to make the adjustment <lfam>ng0__: There should be an '/etc/services' file, created by GuixSD <ng0__>maybe copy back old state, do guix system init instead of reconfigure and then fix what's left over <ng0__>where it fails is at the /etc/ssl already existing.. I know I might've missed documenting something <cbaines>I've been trying to package discount, a markdown implementation. The markdown binary it installs seems to not link against the shared library correctly, as I get an error: /gnu/store/criv9h98djbl454jirg6nyd4bq8hpm77-discount-2.2.2/bin/markdown: error: depends on 'libmarkdown.so.2', which cannot be found in RUNPATH <cbaines>The Makefile does $(CC) $(CFLAGS) $(LFLAGS) -o markdown main.o pgm_options.o -lmarkdown <brendyyn>lfam: how does one do that. I tried ntpdate -s time.nist.gov but nothing happened <cbaines>I'm not too familar with C, any advice on how to make it work? <ng0__>I think I might've skipped something and the /etc is already an combination of debian and guix etc. <lfam>cbaines: For examples of how to deal with C runpath issues, grep in 'gnu/packages' for '-Wl,-rpath' <cbaines>lfam, great, thanks I'll take a look <lfam>brendyyn: You can allow ntpd to make large adjustments in the GuixSD configuration if you think this will happen again. Otherwise, by default, when you request a clock adjustment with ntpdate it will happen slowly, since big time jumps can wreak havoc with many applications. <ng0__>arghhhh. whatdididothefirsttime >.< <brendyyn>I just downloaded a file over GNUnet woohoo! <ng0__>maybe I just symlink the missing bits <ng0__>I don't understand how this worked on 1984. <brendyyn>40KiB/s over a direct ethernet connection... hmmm i set -a 0, but maybe it's actually routing through other computers anyway <ng0__>in the beginning it takes a while until you get connections.. your node must advertise itself <brendyyn>Oh right, I didn't publish it anonymously <ng0__>which is why I want to make use of pubsub for gnunet-fs distribution <brendyyn>which means I published with anonymity 1, and downloaded with anonymity 0 <brendyyn>which means im requesting directly, and but the laptop uploading is going out of its way to route via various other computers <brendyyn>ironically, making this LAN transfer explicitly less anonymous <ng0__>if you use two devices running gnunet in thesame network, no <brendyyn>these laptops are connected directly with an ethernet cable <brendyyn>I followed grothoff's guide to set 'SERVERS =' and have no bootstrap nodes, but it connected to other nodes anyway somehow <ng0__>still, there is something (occupied elsewhere) which makes only one pick up all the connections and the other gets them <ng0__>I need to work on the /etc issue <ng0__>yeah, I'm no constructive help right now. <brendyyn>Alright, direct transfer is working, but still only 200KiB/s <brendyyn>And also downloading from lots of other nodes for some reason <ng0__>maybe initi won't throw any errors.. myglc2 recommended it <ng0__>if all breaks I can still ask for reset o.O <ng0__>yhm.. the /etc pieces of debian are still there <ng0__>hurgh.... our disk-image is full qemu and can be used by kvm and just expanded, right? I think there is something special about in-berlin vservers and I should send them the disk <OriansJ>and a major upgrade to the stage0 build process for the lazy. The roms builds are new included in the makefile and a simple make all will now build EVERYTHING <lfam>ng0__: What do you mean by "full qemu"? You can run it in QEMU <lfam>I tried using the disk image on serveraptor, and it did work, but it was impossible to reclaim the partition used by the disk image without some "out of band" storage management tools, which that service lacks. <lfam>This is why I pushed for us to release a vm-image <OriansJ>now the process of starting to hack on stage0 has been reduced to git pull, cd stage0 and make all which completes in under 30 seconds on even older P4s <ng0__>ah, great the machine is crashed. <ng0__>Well in-berlin told me they could also grab an disk-image I build and use that for the server <ng0__>I used the method I documented roughly in the link for 1984hosting <ng0__>should've worked for in-berlin aswell because of their minimal debian <ng0__>my out of band console says crashed server <ng0__>fails because of some files existing in /etc, like I thought <ng0__>so don't follow the advice to do init when you only have one disk <lfam>I'll say that initializing from the disk image worked fine on serveraptor. The only real problem was the loss of space used by the disk image. <ng0__>I'll mail them now if I recall the qemu offer correctly <ng0__>works once, but seems to be highly individual. <ng0__>I did only see the system def. for it <lfam>ng0__: Yes, in the last release <lfam>In the same place you can download our other release files <lfam>I'm still waiting to hear back from serveraptor since the release <lfam>Yes, we should advertise it there. I need to finish testing changes to the website <lfam>I forgot we hadn't done that yet <lfam>I just filed a bug to help me remember <ng0__>did you have the option to have separate mount-points on serveraptor? <ng0__>I could just ask in-berlin to do that temporarily for me. <cbaines>I've now got an error about not being able to find -lmarkdown: <cbaines>gcc -Wno-return-type -Wno-implicit-int -I. -g -fPIC -Wl,-rpath=/gnu/store/gpc2d2pjx6k701agkky9qs82qdhd3v10-discount-2.2.2/lib -o theme theme.o pgm_options.o -lmarkdown <lfam>ng0__: What do you mean by "separate mount-points"? <ng0__>well, not just /dev/vda1 but the install-image elsewhere, and /dev/vda1 being the "target" <ng0__>just rtying to understand an easier method than 'borg' :) <lfam>ng0__: I don't remember the exact situation now. But, I remember that that would have required them to change their system, because it expects a "ready-to-run" image, and not an installer image. <ng0__>so serveraptor just take the vm-image as a base <OriansJ>lfam: so basicly, one needs to do the full install locally and then use the resulting system image? <lfam>OriansJ: In another distro, yes. But Guix offers the wonderful tool `guix system vm-image` :) <lfam>I guess that counts as a full local install. But it's very easy :) <ng0__>there is the problem with passwords.. which can be set to 'off' as long as copying in ssh keys is no option <OriansJ>lfam: last I checked, it only worked on guixsd and not say guix on debian <lfam>OriansJ: It does work on Debian. I use it often <OriansJ>lfam: I guess, I'll have to take another look at it then <lfam>ng0__: I punted on that issue for the 0.13.0 vm-image. You are expected to set a password from the web-based console before setting up networking. <lfam>I like how AWS does it: you provide an SSH key and they insert it into the VM image before it comes online. But, AWS is way more sophisticated than a simple VPS hoster <ng0__>that requires having a webbased console :) <ng0__>my "webbased console" is a smart access via an external server to the kvms running <ng0__>but I'll describe the situation to them, see what I can do <lfam>ng0__: We should try to use the vm-image on a few different VPS services, and then try to improve it in these areas <lfam>I didn't really have time to invent good solutions to the password / SSH key problem within the 0.13.0 release timeline <ng0__>to be able to use openssh keys in the system config would be what IN-Berlin wants <ng0__>this is how they create their debian images <ng0__>you pass on the openssh pub key, and you get to log in <lfam>ng0__: Right, that would be best. But, how do we (Guix) do that in a release image? <lfam>And how does IN-Berlin do it for their Debian images? <lfam>Do you upload the key to a web page, and let them put it in the image? <ng0__>i think it is scripted, or with a one time login <lfam>Right, web or email. Something out of band <lfam>Serveraptor specifically asked for the image to have no root password, and no networking. They expect you to set it up in the web console on first boot. <ng0__>I think a way to just log in with a password would be good. and you are pressured into changing it after connecting <lfam>I don't think we can put a known password in the image and then expect people to run that on the internet, though. Is that what you mean? <ng0__>as far as I understood the image creation, I can put an openssh key in the /root/ directory... so that should work and should be scriptable <ng0__>guix system disk-image --ssh-key=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA <ng0__>the --ssh-key before disk-image ofc <lfam>So, that would be for services that expect the customer to give them the image? <ng0__>there are some of those, yep <ng0__>it can be used on the provider side <lfam>Ah, so they generate the image on-demand? <ng0__>you give them the key and they run the generation <ng0__>shouldn't be no different than pacstrap etc <lfam>That's what I'd prefer :) We should start our own service offering this, IMO! <ng0__>you outsource the trust anyway <lfam>Upload a config.scm and a key, and we give you a GuixSD server <ng0__>there is no way you can compete, investment is hopeless <lfam>Yes, the margins are extremely small in the VPS market. But, this service could be spun-off from an internal tool used by another business ;) <ng0__>I have no time to work on this, but if someone else is interested I could upload my thoughts on it if I come to the conclusion that I am really not able to do this <cbaines>lfam, I think adding -L has helped :) <cbaines>On another subject, as you two are talking about it, how close is a ISO installer? <lfam>cbaines: Not done yet, but several times people have dumped their research on guix-devel. We "just" need somebody to finish it <cbaines>I saw some things about ISO... file systems that looked promising <lfam>What I don't understand is why the industry is still standardized on ISOs, when optical devices are really quite rare at this point. <cbaines>I guess you'd have to ask someone who operates a VPS provider <lfam>Yeah, I'm just ranting. I know the answer: it works for us <cbaines>I'm interested in Bytemark, and you mentioned Serveraptor, both of which support ISO installers <ng0__>I have 2 more formats I don't understand, maybe some sysops here heard about them. from a datacenter in Sweden and a hoser in iceland outsourcing them to a cloud format. need to buy some food now. <lfam>cbaines: Actually, Serveraptor takes a raw QEMU image. <cbaines>I did once try and install Guix through a Debian installer with a Bytemark/BigV VM, it didn't work, but I think I was close <cbaines>I've never used Servraptor, I was just reading the homepage: "You can install OS of your choice by yourself using ISO disk from our library." <ng0__><lfam> ng0__: I punted on that issue for the 0.13.0 vm-image. You are expected to set a password from the web-based console before setting up networking. <ng0__><lfam> I like how AWS does it: you provide an SSH key and they insert it into the VM image before it comes online. But, AWS is way more sophisticated than a simple VPS hoster <ng0__>> that requires having a webbased console :) <ng0__>> my "webbased console" is a smart access via an external server to the kvms running <ng0__>> but I'll describe the situation to them, see what I can do <lfam>cbaines: I guess they are using "ISO" in the colloquial sense. Our USB installer image works, and they confirmed they don't need a "real" ISO standard image <ng0__>8Our cloud serivce is based on our sister company GleSYS cloud. I would recommend that you reach out to GleSYS directly in this matter to get access to the control panel which I feel is going to be useful for you. :) <cbaines>Does anyone have an opinion on what provider currently offers the easiest setup of a GuixSD VM? I know people have posted guides for different providers. <ng0__>a rather big one, 1 million customers according to onapp themselves <ng0__>1984 was a flawless debian -> GuixSD transition <ng0__>if you are willing to pay the fair price <ng0__>aldso I heard hetzner dedicated is okay <lfam>Soon, Serveraptor will offer GuixSD "out of the box" <lfam>Otherwise, I think you have to do `guix system init` from another distro. <ng0__>I hope that IN-Berlin works out, they kinda date back to the times of mailboxes :) I don#'t want Hetzner.. <ng0__>if someone can pay for 1984 to test the vm-image and give them feedback that would be really good. I can't pay them next month, but they are really looking forward to include GuixSD in their default set once we offer an iso <ng0__>and plain qemu can be used aswell right now (if I don't mix them up) <ng0__>no. iso will be added, but qemu can be dd'ed at the moment. <sneek>bms_, janneke says: wow! hi! would be nice to chat some time (soon). i don't really care all that much about the current Mes Scheme intepreter prototype in C; it could stay like this, could be changed into annotated assembly, will most probably be rewritten to be a Scheme compiler in LISP -- but you gotta start somewhere! <ng0__>lfam: I forgot a paraentheses in florence? <ng0__>so it must've been when I did some last change <lfam>The way the patch was attached was kind of weird, so maybe it got lost there <lfam>ng0__: I think the difference is that the attachment had a MIME type of 'application/octet-stream' instead of 'text/x-patch', so mutt displayed it differently. But, that shouldn't drop the last character, which would have been a newline and not a parentheses. <ng0__>oh.. I used the web interface of my mailserver for a while. <ng0__>I kind of expected a question why I do not build the documentation. I did not comment that the documentation building would require some kind ofdocumentation tracking application, graphical, to be installed <reepca>Question... was there supposed to be an easier way to set up GPG than manually figuring out where to put gpg-agent.conf and how to make it know which program to use for pinentry? <lfam>reepca: You'll want this line in gpg-agent.conf: <lfam>pinentry-program /home/you/.guix-profile/bin/pinentry <reepca>yep, found that out one minute ago <lfam>ng0__: I figured it was something like that <rain1>janneke, OriansJ, I got a nice reply on tinycc mailing list <rain1>if i am reading this right, pcc can be compiled via awk ? and then it can build tcc which may be able to start the bootstrap of gcc <janneke>gcc-2.95, there's a nice sound to it in a way, no idea how many steps till 4.7 though <rain1>i will try to verify thath right now <rekado>brendyyn: in GuixSD you can tell the ntp service to make large adjustments <rekado>“gcc 4.7.4 can be compiled again by TCC” <— excellent! <efraim>just need the 1000+ line patch for aarch64 support ;p <efraim>i take it back, debian's patch is ~57k lines <rekado>technically, that’s still 1000+. <OriansJ>efraim: cross platform support can be dealt with later, we have a major ladder to the fully trusted bootstrap <OriansJ>janneke: after a couple hours to trying to figure out your build steps from your Gnumake file, I have to admit you are much much better at it then me. That being said, if you want people to hack on small pieces of it, you really need to make it trivial to understand the build process. Like so: http://git.savannah.nongnu.org/cgit/stage0.git/tree/makefile <bms_>You may have seen: I started a wiki page yesterday. Currently, I'm figuring out a bit of a plan of how I'll go about doing it. And researching. <OriansJ>bms_: the best step is to do what seems obvious and easy to do <bms_>I did that yesterday with the Wiki page. :P <bms_>I'm still trying to process the chicken-and-egg-ishness of it. <OriansJ>bms_: then do the next easiest step, and it'll probably help you solve the next one or at least get you thinking in the right direction <OriansJ>bms_: don't try for perfect, simply take something that works and move in the correct direction <OriansJ>Thanks to Turing Completeness, any Turing complete instruction set can implement a lisp given sufficient memory and time <OriansJ>bms_: If you want advice on short term tasks to achieve that goal of yours, I'll need to know what technical work you think is most fun. <bms_>I love writing things in LISP (Scheme is what I've know) so that's probably the most fun part for me, but there's barriers to that in this project. I enjoy C and AT&T Syntax Assembly too. Those are the languages I know best, if that's what you mean. <bms_>I also tend to like computer history, which isn't particularly relevant, but is the inspiration for some of this project. Particularly the hacker culture of the 70s. <bms_>Otherwise, I like seeing things come together from small pieces. I like doing things from the ground up. It makes the end result more satisfying. <bms_>I'm unsure of whether I should really write my own simple Lisp or if it would actually make more sense in the long-term, even if it's going to be more difficult at first, to bootstrap a simplified Guile. <OriansJ>it is a really primitive but easy to understand lisp and it should be really easy for you to extend to suit your needs <rain1>build success! used latest tcc mob to build gcc 4.7.4 <reepca>How does one make it so that the display doesn't turn off after a certain amount of time on guixSD? I would expect that would be an xorg thing <rain1>it may be possible to compile like this: mes |> ack |> pcc |> tcc |> gcc 4.7.4 |> gcc later version... up to modern <rain1>(but binutils needs to be compiled at some point too) <OriansJ>rain1: the binutils question can be answered after we address the question of if MES can't do tcc, what compilers can <OriansJ>we also have the option of going the ugly route to solve the tcc bootstrap question <rain1>i was able to build tcc using pcc <Apteryx>I'm experimenting with a change the search-path-specification record. When I attempt to "guix environment guix", it seems like some Guix from the /gnu/store rather than the one I modified in my git checkout is used. Why is that? I've got /root/.config/guix/latest -> /home/maxim/.config/guix/latest. <OriansJ>rain1: indeed I am just curious if we can now get janneke an easier target to bootstrap <rain1>this ACK compiler might be easier!