***erdic_ is now known as erdic
***mattl_ is now known as mattl
***tschwing_ is now known as tschwinge
<civodul>th3kent: are you testing on i686 or x86_64? <nebuli>can i bother you with few bugsies <nebuli>first: on my system (laptop) usb image refused to boot without a boot flag on the partition <nebuli>second: my root partition is sda9 <nebuli>how about (when (< i 16)) in make-disk-device-node in linux-boot.scm <nebuli>civodul: and currently i'm 'system building' from currentish guix without subs; lsof 4.87 source is MIA <civodul>so you're testing from master, right? <nebuli>yes, last commit is your fix to guix pull <nebuli>most important is the make-device thing, since i don't want to be fixing initrd by hand on each reconfigure <nebuli>i tried making a branch on github and guix pull on that but ssl i borked :-} <civodul>oh just set GIT_SSL_NO_VERIFY=true... <nebuli>no, downloading branch archive... <nebuli>want to do it 'right' and not work from git checkout <nebuli>guix pull freezes on archive download with github uri <nebuli>it creates zero sized temp file and stops <civodul>could you try the same URL with 'guix download'? <civodul>grr, occasionally hippie-expand crashes Emacs <nebuli>fight with bleeding edge, die by the bleeding edge <civodul>actually it's not even bleeding edge <civodul>it's been this way for some time, but it's hard to reproduce, and so i never reported it <nebuli>if you want to test it yourself i can give you thar github url <civodul>works for me with 'guix download' and GnuTLS 3.2.19 <civodul>could it be that you're using an older GnuTLS? <nebuli>yes 'guix download' works here too but not 'guix pull' with 'guix pulled' fro git checkout... <civodul>did you use the same command as above? <civodul>nebuli: i've just pushed 4 commits that should address the problems you reported <nebuli>like i said it creates zero sized temp file and just sits there until i ^C <nebuli>perhaps, don't worry about that for now <nebuli>must be some really fine interaction <nebuli>i'll try to collect more information later (after guix system build finishes) and if it still doesn't work, i'll bother you on irc or e-mail my notes <civodul>anyway, thanks for the precise reports, they are invaluable! <nebuli>for now i'm patching in ~/.config as i go <nebuli>civodul: btw would using --bootstrap prevent 'guix pull' from rebuilding from scratch? <civodul>by default 'guix pull' ensures Guile is built so it can use it; --bootstrap tells it to use the bootstrap Guile, so nothing needs to be built in that case <civodul>normal operation is without --bootstrap <nebuli>well, i'd rather not spend a night on every 'only several minor commits' guix pull <nebuli>but as i'm working from within hardware booted gnuixos i'd like to do it 'correctly' and not use guix build ftom git checkout on some random user profile <nebuli>those circular/bootstrap dependencies surely need some ironing out if guix is ever to be mere mortals friendly <civodul>but building Guile is normally one-shot <civodul>and with substitutes enabled, it's not so much of a problem, i think <civodul>also, the complete OS also comes with Guile pre-built <civodul>dunno, i may well be overlooking something, that's why reports like these are so useful *nebuli nods: so many moving cogwheels... dizzing. <jmd>I'm getting this whenever I try to build: <jmd>In guix/build-system/gnu.scm: <jmd> 95: 2 [replacement] <jmd> 143: 1 [replacement] <jmd> ?: 0 ["The GNU Bourne-Again SHell"] <jmd>ERROR: In procedure The GNU Bourne-Again SHell: <jmd>ERROR: Wrong type to apply: "The GNU Bourne-Again SHell" <civodul>looks like bash.go uses the wrong ABI and needs to be rebuilt <jmd>Hmm. Then I get a similar problem with the different file. Probably all will need to be rebuilt? <civodul>yes, make clean-go && make, if this is from a git checkout <civodul>it would be nice to handle these incompatibilities gracefully... <jmd>I have just merged from a rather old checkout. <th3kent>sure thing davexunit. i am also playing with guix, and re-learning lisp/scheme. (-8 <jmd>new branch: wip-libreoffice <jmd>Be even cooler if it worked. <davexunit>that's a big task. thanks for working on it. <jmd>Its just starting to get too big to build on my modest hardware. <davexunit>having that and gnome software running on guix would be a great step towards making guix accessible to non-hackers. <jmd>Is there a way I can lookup the package definition given its name and version? <jmd>No. I mean programatically. <jmd>From within a package definition <bavier>jmd: wasn't sure what you mean by "package definition" <jmd>Where is find-packages defined ? <jmd>Odd. Using find-package-by-name a package cannot find itself. <jmd>file needs to depend on a native version of itself. <jmd>and exactly the same version. <civodul>jmd: then you can use 'file', directly <civodul>or, there's a special self-native-input? field for that, but i plan to remove it <jmd>Someone already has removed it. Consequently file can no longer be cross compiled. <jmd>Using ,file directly used to work, until a second version of the package came along. <jmd>Now, it no longer works, because ,file refers to any version. <jmd>Hence building file-5.19 Guix thinks its fine, because it already has a native file installed. <civodul>oh right, it was removed in c198872b <jmd>However the build will fail, because its the wrong version. <civodul>,file refers to the variable named 'file' <civodul>so if you want to fix that in file-5.20, you need ,file-5.20 <th3kent>civodul: to your question a while ago, i am testing on x86_64. <jmd>I was kindof hoping I could do (string-append "file-" version) or something. <civodul>jmd: here, to facilitate things and avoid a rebuild, you can just add (self-native-input? #t) in 'file' <civodul>i can do it, if you want, while i'm at fiddling with these things <jmd>Easy once you know how! <jmd>civodul: I pushed the wip-libreoffice branch <jmd>Will that get built by default, or will it have to be manually triggered? <civodul>someone needs to make a new jobset on Hydra *civodul looks for someone <jmd>I'm getting this problem again: "guix package: error: build failed: path `/gnu/store/1r60y38nv0igm2510d1w7yg177cbd7r6-indent-2.2.10' is not valid" <jmd>I only have one localstatedir <civodul>yes, but did you reinstall with a different localstatedir? <jmd>So far as I'm aware I didn't. <jmd>GUIX$ ./config.status --config <jmd>'TEXINFOFLAGS=--force' '--localstatedir=/usr/local/var' <civodul>ok, and could it be that there's another dir that was in use before, like /var/guix or something? <jmd>Would it help if I restart the daemon? <civodul>or it could be that your profile refers to this thing, but this thing was GC'd, which is impossible unless at some point Guix was (re)installed with the wrong localstatedir <civodul>no, restarting the daemon won't help <jmd>If the profile refers to it, then "which indent" should show something. <jmd>I seem to have a lot of differnt profiles which I don't use. How can delete them all? <civodul>to delete all generations of a profile but the current one, use "guix package --delete-generations" <civodul>to delete a profile, "rm the-profile"