IRC channel logs


back to list of logs

<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
<ennoausberlin>how can I find the cause of that error?
<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>I recommend making sure you can connect to <>, so that you can download the built kernel.
<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?
<ennoausberlin>I have ethernet connected. Other substitutes work fine
<lfam>This is with the 0.13.0 installer?
<ennoausberlin>yes. I also did guix pull before starting the install
<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>Ok. I do a --dry-run and no-bootloader right now
<ennoausberlin>he is updating the substitutes list
<ennoausberlin>there are two lists printed. One list is about building one is about downloading
<ennoausberlin>linux-libre is in the building list
<Gamayun>4.12.3? I don't think there is a substitute for that yet...
<Gamayun>Ah, hmm...
<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>(define key->index
<reepca> (lambda (stmt key)
<reepca> key))
<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
<janneke>Morning Guix!
<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>morning epronk!
<epronk>good evening janneke!
<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_>janneke: Now has RS232 cable connected to qemu. =>
<epronk>I can imaging something similar happens when I put dumb-init into the mix.
<janneke>epronk just wondering why shepherd fails to start...
<rekado_>Hi Guix!
<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
<janneke>Hi rekado_!
<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.
<eiro>thanks rekado_
<janneke>epronk in the command line you posted here, it says: `.../shepherd shepherd --config bla'
<janneke>ah, that should be right...hmm
<janneke>epronk no, lose the first `shepherd' argument, that's the $0 for execl
<epronk_>janneke: well spotted that double shepherd arg. new paste =>
<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...
<janneke>*mkdir -p
<janneke>or equiv
<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.
<reepca>ACTION promptly goes to sleep
<platoxia>Is it normal to get a symlink permission denied error when running system reconfigure as a user
<rekado_>heh, shepherd on the HN frontpage:
<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> | `-{shepherd}
<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
<rekado_>I’ll give that a try
<snape> says line length should not exceed 72 / 80 chars, and .dir-locals says 78
<snape>I'm quite confused
<OriansJ>morning guix
<rain1>good morning
<OriansJ>how are things rain1?
<rain1>oh quite good
<OriansJ>good to hear, and the testing?
<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?
<OriansJ>it is already implemented in C
<OriansJ>simply make vm
<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:// && 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 ?
<rekado_>ng0: bind’s utils output
<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>*system not config
<ng0>my config did not change
<catonano>Apteryx: yeah. A debugging tutorial for Guile wouldn't be bad
<ng0>found it
<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>i use labels, etc
<ng0>all default
<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>hello guix!
<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
<mbakke>yes :P
<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 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_>so… what’s next?
<rekado_>the profile hook is probably easy;
<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>platoxia: through guix
<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 Seems it might have finally been shut down.
<rain1>oh no
<efraim>apteryx[m]: git-grep says unrar, gdsl, allegro, freeciv, guile-cairo, guile-dbi, guile-dbd-sqlite3
<Apteryx>efraim: :/
<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.
<catern>(you cansee in the Summary section here: the features that I'm capable of providing when using SET_CHILD_SUBREAPER)
<Apteryx>efraim: OK, good!
<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 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 :)
<Apteryx>just verified, it is
<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
<alezost>Apteryx: check %load-compiled-path
<Apteryx>alezost: Oh. I always think this is the same thing. Python habit I guess.
<alezost>yeah, they are different
<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? :)
<Apteryx>alezost: thanks for that!
<catern>(I will mail guix-devel regardless)
<alezost>catern: he is competent in anything :-) I don't know who else is
<alezost>Apteryx: no problem
<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: yes
<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>pretty handy
<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
<civodul>maybe, not sure
<catern>(I wrote my thing in a very careful way, and am hopeful that I can give the Shepherd similar abilities)
<civodul>"supervise" looks interesting
<civodul>using file descriptors instead of SIGCHLD is something i wanted to do
<civodul>with signalfd(2) i guess
<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.
<jlicht>woohoo, my system boots again
<jlicht>ACTION is a happy camper
<lfam>I think we need to pass '-L/gnu/store/...-cyrus-sasl' in the *.la files of openldap, some of which contain '-lsasl2'.
<lfam>I hit this issue with the latest version of ncmpcpp:
<civodul>Nix discussion of interleaved eval/build (like we do for grafts, but more formalized):
<jlicht>civodul: this looks cool
<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?
<lfam>efraim: I'd use string-take-right:
<efraim>lfam: thanks
<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 :)
<wingo>that does sound alarming :)
<civodul>jlicht: it's more about the general questions of derivations that have a "continuation"
<civodul>of which grafts are one examples
<janneke>ACTION updates npm branch
<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
<OriansJ>well I know ndisasm works
<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
<OriansJ>For example even with just hex0 you could do this:
<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: that's what i hoped!
<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.
<janneke>oh wow!
<reepca>I don't suppose we've got gnash anywhere? I happen to need to use a silly website.
<OriansJ>reepca: well kinda, but you'll have to build it yourself
<janneke>ACTION -> zZzz
<civodul>ACTION is happy Flash has almost vanished from the Web