<ennoausberlin>I tried to install Guix on my Intel based compute stick but I got an error message at the end <ennoausberlin>building of /gnu/store/.....linuxlibre-4.12.3.drv timed out after 3600 seconds of silence <ennoausberlin>cannot build derivation /gnu/store/.....grub.cfg.drv 1 dependencies could not build <lfam>ennoausberlin: For some reason, you ended up trying to build the Linux kernel, and this process passed 3600 seconds without printing any messages, so it was killed. <lfam>ennoausberlin: I think it will be impractical to build Linux on your compute stick. Instead we should figure out why your system didn't use a substitute <ennoausberlin>lfam: The drive i want to use for install is a /dev/mmcblk0 not the usual sdx. Canthis be a problem? <lfam>ennoausberlin: It should be fine, and it's not related to the time out issue <ennoausberlin>Are there any error logs written to see what happend in more detail? <lfam>Do you know what kind of wifi device the compute stick has? It might not have a free driver, which means that it won't work with the GuixSD installer. Is there another way to get the computer online? <lfam>This is with the 0.13.0 installer? <lfam>It looks like we have a substitute available for linux-libre@4.11.3 on the current master branch. So, you should be able to get a substitute. I would try the command again with --dry-run and see what it reports it will do. <ennoausberlin>there are two lists printed. One list is about building one is about downloading <Gamayun>4.12.3? I don't think there is a substitute for that yet... <lfam>Okay. It would be useful to see the derivation that times out. And also at what point in the build it seems to stall. <ennoausberlin>It takes a long time to build all the substitutes. I can not keep sitting in front of the computer <Gamayun>I think I've normally installed a bare-bones system first and only then run guix pull and updated.. <ennoausberlin>Ok. Its midnight here. I will start another try tomorrow. Thank you for your advice <Gamayun>Yeah, bedtime here as well. Good luck! Hopefully all goes smoothly tomorrow... ***useraaa is now known as rain1
<reepca>^ as seen in guile-sqlite3... that would explain my confusion ***Piece_Maker is now known as Acou_Bass
<bavier>I finally figured out what was causing my guix builds to fail: configure had cached the path to and was trying to use an older version of guile <bavier>but some of the guile modules were incompatible, which somehow lead to a segfault <reepca>In the coding style section of the manual, where it says "user keyword parameters for procedures that take more than four parameters", should that involve making the ones past four keyword parameters or just making everything a keyword parameter (specifically in the case where none are optional)? <eiro>out of curiosity: can guix also replace make ? <epronk_>janneke: my /sbin/init is now a simple bash script <epronk_>+ /gnu/store/q49si29djfcrpzibqg6cg8k6xixxvd2f-shepherd-0.3.2/bin/shepherd shepherd --config /gnu/store/df56ad2rw1ayjyhs1kqadskf5zsmsc5l-shepherd.conf GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread GC Warning: Couldn't read /proc/stat shepherd [OPTIONS...] ... then dump options <janneke>whats the `... dump options' bit? Does /sbin/init work better now, or does it fail? <epronk>janneke: it fails. I'll collect a bit more logs. <epronk>I can imaging something similar happens when I put dumb-init into the mix. <janneke>epronk just wondering why shepherd fails to start... <janneke>epronk if ls is not found and /proc/stat, can you verify whether the argument to --config [the config file] can be found/read? <janneke>i would expect shepherd to give a nice warning about that...but showing the HELP suggests that command line aparsing failed <rekado_>Gamayun: yes, looks like LPPL, but there’s no license version on these files, nor any more license text. <rekado_>and I’ve got to be careful not to patch any of these files. <rekado_>I already have a texlive-build-system and it builds packages fine. <rekado_>now adding more and more of the required latex packages. <rekado_>reepca: that depends on whether they are all optional <rekado_>reepca: if some of them are always required then it’s okay to leave them as positional <rekado_>reepca: but if all of them are required then you should probably use keywords for all of them. <rekado_>eiro: on its own Guix could not replace make. <rekado_>eiro: but one can imagine a system built on top of Guix that implements parts of make. <janneke>epronk in the command line you posted here, it says: `.../shepherd shepherd --config bla' <janneke>epronk no, lose the first `shepherd' argument, that's the $0 for execl <janneke>epronk: great. i'm really guessing here...are we in initrd? why is there no /var/run/shepherd <janneke>epronk: not sure if missing /proc/* is problematic at this point, but I guess it is <janneke>epronk: could not harm to mkdir /var/run/shepherd though, and see what happens... <epronk_>janneke: in grub: linux /boot/vmlinuz-4.4.0-78-generic root=/dev/sda1 ro recovery nomodeset console=ttyS0 <epronk_>janneke: and: initrd /boot/initrd.img-4.4.0-57-generic <epronk_>janneke: mmm... 57 and 78? why not same :-( <janneke>epronk_: you may want to use kernel and esp. initrd from GuixSD? <epronk_>janneke: I don't want to waste your time, but what I'm trying to do is run guixSD on an Ubuntu kernel if that works it should also work with lxd. <epronk_>janneke: It may not be possible if the boot process via shepherd is too different from distros build around an init process. <janneke>epronk_: ah sure...I'm only guessing anyway <janneke>no worries about wasting my time mate, happy to talk to you :-) having said that, /me goes afk for a bit <reepca>Posted a work-in-progress patch for guix-register. <platoxia>Is it normal to get a symlink permission denied error when running system reconfigure as a user <brendyn>rekado_: Yeah I saw that They don't want to talk about Guix, but want to talk about shepherd xD <ng0>no-systemd: yay gnu-system: nay <epronk> |-lxd---init---shepherd-+-udevd <epronk>The above lines mean shepherd can start inside an lxd contrainer and it doesn't exit. Now I need to find a way to get some logging out of it. I have no idea how far it got, or what failed. <ennoausb_>Hello. I yesterday tried to install the latest guixsd but run into a timeout during building linux-libre-4.11.3 <ennoausb_>Now I checked that the Starting phase validate run-path takes too long. Any ideas what the problem might be? <rekado_>ng0: I haven’t seen any anti-GNU statements there yet. <rekado_>I have the LaTeX distribution with all required packages ready. <rekado_>I don’t know yet how to use it, though. <rekado_>It’s possible to override the search paths for TeX files with some environment variables. <rekado_>But we probably don’t want to set the variables in each package using LaTeX. <rekado_>So we need some sort of wrapper package, maybe similar to how sdl-union does things. <rekado_>AFAIU the kpathsea stuff is only a convenience tool; we don’t actually have to use it. <rekado_>or maybe a search-path spec would be sufficent <rain1>yes, I keep working on it, nothing new to report yet <rain1>i was wondering about the plan with the VM - how would it be implemented? <rain1>that seems like a problem in terms of bootstrapping, unless we start with the vm already compiled as a bootstrap binary <OriansJ>for the sake of cross platform simplicity we are starting with the vm as an assumed bootstrap binary, which we will later reduce its bootstrap to assembly and then do the dozen steps required to start from just the hex on native platforms to finish the circle <OriansJ>98KB total assumed binary and 100KB source is certainly alot less than the 28MB of the existing bootstrap binaries and their 202MB of source <OriansJ>Which reminds me I added a few new make commands to the stage0 repo to make it even easier for developers to replicate the user experience of new developers and allow the new developers to build, verify and improve individual pieces more easily <OriansJ>now all anyone needs to do to verify everything thus far is: git pull git://git.savannah.gnu.org/stage0.git && make test which will complete in about 72 seconds on a Libreboot T60 <OrangeShark>I am trying to use guix environment --pure and I keep getting an error from bash saying tput: command not found... This is guix ontop of another distro. ncurses provides tput and I have it installed <rekado_>OrangeShark: “--pure” overrides environment variables, including “PATH”. <rekado_>OrangeShark: Unless your environment command includes the package providing “tput” it won’t be on the PATH. <OrangeShark>rekado_: this happens when I run the command, I am not even in a pure environment <ng0>where did the 'bind-utils' disappear to ? <OrangeShark>rekado_: I am doing guix environment --pure guix and it gives me the error about tput <rekado_>OrangeShark: maybe your distro’s shell is configured to use tput. <rekado_>“guix environment” starts a new shell, so the shell initialisation config files are evaluated. <OrangeShark>rekado_: I think you are right, if I just say No to not install the ncurses it eventually puts me in a pure environment <Apteryx>Is there any info on how to use the Guile debugger efficiently somewhere? <Apteryx>I cannot get ,break-at-source to work for example. <ng0>the error I thought which was a failing harddrive just happened here too... current system generation always breaks, throws me into guile repl on all computers <Apteryx>I'm doing ,break "/home/src/guix/scripts/environment" 543, expecting it to break on `guix-environment' procedure, but it says "ERROR: No procedures found at ~a:~a. "/home/maxim/src/guix/scripts/environment.scm" 543" <ng0>this worked like 1 day ago… so what changed again in the config that it breaks stuff? <ng0>my config did not change <catonano>Apteryx: yeah. A debugging tutorial for Guile wouldn't be bad <ng0>this message I do get on otherwise fine working systems <ng0>so what's up with that? <Apteryx>catonano: Also, it keeps hanging on me, but that probably is something with Geiser in Emacs. I'll try straight from the terminal. <ng0>no complicated setups.. after this commit, boom no longer bootable <ng0>I'm away now, I'll just report it as a bug <mbakke>two of my systems are unable to boot since recently, older generations are fine <mbakke>I'm getting "Could not read ISO9660 primary volume descriptor from /dev/sda2" on one machine, which is a FAT32 ESP partition <mbakke>tried reverting 203a9455c4695152fc5d0085bffeead9ce3216c2, but then I just entered a boot loop <mbakke>oddly, a newly-provisioned system is fine <mbakke>will investigate more tomorrow, on my way out now... just a heads-up! <mbakke>hah, saw ng0 just mentioned the same thing <jlicht>reading the logs, I just wanted to mention I also suddenly have the "Could not read ISO9660 primary volume descriptor from /dev/sdaX" error when booting my recently reconfigured system <mbakke>hi jlicht, the last two messages before you joined mentions the exact same thing <jlicht>oh, heh, it was reported 9 minutes ago :D <jlicht>finally have my mu4e setup with notifications. Just saw exactly this bug report being mentioned after pressing enter on my irc message <jlicht>Are labels not the Right Way to do things btw? ng0's message seem to imply this is not what people usually do? <gazon>i was seeing the same bug before 203a9455c4695152fc5d0085bffeead9ce3216c2, but the error message was garbled: that commit just fixes the error message. <gazon>i have a feeling it's the kernel GNU with Linux-Libre 4.11.3 (beta) <gazon>since if i roll back the generation to a pre-guix pull one it uses Linux-Libre 4.11 and it works. <jamesrichardson>Seems the api.metacpan.org has shutdown the v0 API and suggests the MetaCPAN V1 API should be used instead. I have fixed guix/import/cpan.scm and tests/cpan.scm accordingly. Seems to work on my system. <jamesrichardson>Should I send a patch? Not really sure if I've corrected evertying... <civodul>jamesrichardson: definitely, you should send that to guix-patches <civodul>great that you found out about this! <jamesrichardson>I'll send it shortly. Just trying to package ikiwiki. It seems to want a plethora of perl modules that haven't been packaged yet. <rekado_>I just built fastcap after removing texlive, adding all the separate texlive packages, and setting a handful of environment variables. <rekado_>the documentation was successfully built. <rekado_>what’s not so easy is how to make the replacement just work for package building <rekado_>we don’t want to have to set so many environment variables every time it is used <platoxia>Which is the better option for installing emacs packages: through emacs package or guix package? It seems most of the packages are available both ways. <buenouanq>letting programs have their own package managers was a terrible mistake <buenouanq>it might have been necessary for some things at some point, but with guix this is no longer the case <platoxia>buenouanq: I was thinking that but I just wanted to be sure. <buenouanq>would be interested if someone could come up with an example where this wouldn't be true <efraim>this reminds me, I should patch our vifm package to install vifm.vim into the path that our vim expects it <apteryx[m]>Do we have any packages depending on gna.org? Seems it might have finally been shut down. <efraim>apteryx[m]: git-grep says unrar, gdsl, allegro, freeciv, guile-cairo, guile-dbi, guile-dbd-sqlite3 <efraim>i've got freeciv atm, i'm going to try bumping it to 2.5.7 also <civodul>rekado_: for package building we could create a meta-package that covers "the typical needs"? <catern>hey guix people, I'm curious, would you ever consider using the Linux-specific prctl SET_CHILD_SUBREAPER in the shepherd? <catern>I have written a minimal supervisor based on it, and it gives a lot of really nice properties <catern>but I would much prefer using GNU shepherd :) <catern>and hacking on the shepherd to add this functionatliy <Apteryx>Observation: Using guile REPL straight from the terminal, and typing ,use (guix scripts environment), it goes on to rebuild all the .go files in my ~/src/guix. Why? IIUC, "make" uses guile@2.2, and the guile in my profile is also 2.2... Hmm. <alezost>Apteryx: check %load-path variable in the guile repl <alezost>I mean check if it contains your src/guix dir <catern>(I would also be happy to add a CHILD_SUBREAPER equivalent to Hurd if that's what's necessary to get support into shepherd :) ) <Apteryx>alezost: I have /home/maxim/src/guix prepended to my GUILE_LOAD_PATH, so I believe it should? <alezost>catern: could you please send a message to guix-devel@gnu.org about this subject <alezost>Apteryx: probably, but check %load-path just in case <catern>certainly, I was planning to, I just wanted to bring it up here more casually first :) <alezost>Apteryx: oh, wait, you added load-path, but not compiled path <catern>to see if there were immediate thoughts - or if there was a policy about this kind of stuff <alezost>Apteryx: I mean GUILE_LOAD_COMPILED_PATH <Apteryx>alezost: Oh. I always think this is the same thing. Python habit I guess. <alezost>catern: I'm afraid there are no people competent to discuss this subject on irc right now :-) <Apteryx>alezost: This is it. So I have to define GUILE_LOAD_COMPILED_PATH=$GUILE_LOAD_PATH ;) <catern>alezost: is the competent person, Ludo? :) <catern>(I will mail guix-devel regardless) <alezost>catern: he is competent in anything :-) I don't know who else is <civodul>catern: re PR_SET_CHILD_SUBREAPER, that sounds like a good idea <civodul>catern: so PID 1 would register itself as the subreaper? <civodul>the man page mentions double-forked daemons, but i don't quite see how that would work since the "subreaper" attribute isn't preserved across fork <OriansJ>Days like this make we wish that big and little Endianness of integers could be explicitly specified in the C standard, instead of forcing separate code paths. <catern>civodul: ah, see, the child_subreaper is an attributed of the process registered as the reaper, and is stored in an invisible way for all child processes. maybe that's a bit confusing. what I mean to say is, any children will be reparented to the nearest parent with child_subreaper set <catern>(it is unset on fork because most processes are not prepared to be subreapers for all their transitive children) <civodul>oh right, and PID 1 would get SIGCHLD not just for direct children, but also for grandchildren and so on IIUC <civodul>so yes, definitely doable in the Shepherd <civodul>i *think* it's enough to add the prctl call <catern>well, it may require some tweaks to the design to be used optimally <civodul>the existing SIGCHLD handler should DTRT <catern>(I wrote my thing in a very careful way, and am hopeful that I can give the Shepherd similar abilities) <civodul>using file descriptors instead of SIGCHLD is something i wanted to do <catern>yeah, I always use signalfd, real signal handlers are so painful <catern>you may have some sympathy to my ultimate goal :) ultimately, I want to be able to do really reliable process supervision with a library; probably for much the same reasons Guix is written as a library for packaging. <lfam>I think we need to pass '-L/gnu/store/...-cyrus-sasl' in the *.la files of openldap, some of which contain '-lsasl2'. <jlicht>How would this compare to guix' grafts? <Apteryx>Useful alias to use worktrees and guix from git: alias "guix-here=rm ~/.config/guix/latest; ln -s $(pwd) ~/.config/guix/latest" ;) <efraim>how do i test if the last digit of a version is 0? <gazon>is this warning sthg to worry about: collision encountered: /gnu/store/ri56wnmzkgzrajdyl5ydc55lrwy1164k-ld-wrapper-0/bin/ld /gnu/store/zq65kpvwwxgc3qqbf9apic8gyss2l0zq-binutils-2.27/bin/ld <lfam>gazon: It's alarming, but I've been assured that it's fine. The ld-wrapper is the one that we want to take precedence <gazon>lfam: ah, good. ld-wrapper is the one it "arbitrarily" chose :) <lfam>Yes, it always chooses that one :) <civodul>jlicht: it's more about the general questions of derivations that have a "continuation" <catonano> jlicht: thanks for your reply. Right now I'm a bit tired. I will read that tomorrow ! <jlicht>apologies for messing up with the help-guix thread, something went wrong on my end <jlicht>catonano: yw, I was looking into some similar stuff recently as well <OriansJ>janneke: the enhanced hex2 linker is almost ready, now supporting 255 char labels and the ability to select byte endianness <janneke>OriansJ: ah, great! I was just looking into stage0 and wondering how .o -> ELF would work <janneke>OriansJ: now with 0.7 finally out of the way, I want to suspend my tcc activities for a bit and first have mescc produce hex2 .o files <OriansJ>janneke: rather simply, the elf header simply is just hex with a couple labels <janneke>OriansJ: do objdump -d and gdb work on them? I'd hate to loose that <janneke>ah...well it's no problem to rewrite mescc's object->elf to accept hex2 and have that as an alternative linker that produces gdb'able elf binaries -- the hex2 linker is trivial, esp. in scheme <janneke>OriansJ: i could not find the ELF [symbol] tables setups and was just wondering <OriansJ>well janneke I fully admit that the hex2 format is so trivial that it doesn't have much hooks for disassemblers, especially since you can literally include the original in the hex2 file as a line comment <janneke>np, when i finally got mescc's ELF debuggable using gdb, that was very helpful <OriansJ>janneke: with hex2, you can literally put the C code being processed in as a comment <OriansJ>janneke: also you'll be able to dictate byte endianness of all references, and I'll be tossing in some bounds checking too <janneke>OriansJ: yes...i [we?] need to be looking towards producing annotated hex2 as a next step for bootstrapping mes.c as mes.hex2 from stage0 <OriansJ>janneke: that is a trivial step once you have mescc produce hex2 output files <janneke>OriansJ: also, mescc will need quite some work before it can really do something sensible with all of tcc.c [i didn't even look at the other tcc source files]; but producing hex2 will allow nice simplifications of mescc's internals and i want to do that refactoring first <OriansJ>janneke: also, I've been improving the stage2 lisp implementation, such that I'll be able to write a proper lisp compiler in lisp. <reepca>I don't suppose we've got gnash anywhere? I happen to need to use a silly website. <civodul>ACTION is happy Flash has almost vanished from the Web