IRC channel logs

2014-11-13.log

back to list of logs

<davexunit>and thanks to the savannah admin team
<davexunit>good evening, #guix
***erdic_ is now known as erdic
***mattl_ is now known as mattl
***tschwing_ is now known as tschwinge
<civodul>Hello Guix!
<civodul>th3kent: are you testing on i686 or x86_64?
<nebuli>civodul: ping
<civodul>nebuli: pong
<nebuli>can i bother you with few bugsies
<civodul>yes, sure!
<nebuli>first: on my system (laptop) usb image refused to boot without a boot flag on the partition
<civodul>oh, ok
<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
<nebuli>so is netbase 5.2...
<civodul>ok, lemme see
<civodul>thanks for the reports!
<civodul>so you're testing from master, right?
<nebuli>yes, last commit is your fix to guix pull
<civodul>ok
<nebuli>most important is the make-device thing, since i don't want to be fixing initrd by hand on each reconfigure
<civodul>yes, and it's easily fixed
<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...
<civodul>what do you mean?
<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>oh really?
<civodul>could you try the same URL with 'guix download'?
<nebuli>momento...
<nebuli>well, that works... weird.
<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>yes, please
<nebuli> https://github.com/Nebulieu/guix/archive/master.tar.gz
<civodul>works for me with 'guix download' and GnuTLS 3.2.19
<civodul>"./pre-inst-env guix pull --url=https://github.com/Nebulieu/guix/archive/master.tar.gz" works as well
<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>how is 'guix pull' failing exactly?
<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
<civodul> http://git.savannah.gnu.org/cgit/guix.git/log/
<civodul>hmm ok
<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>ok
<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>yeah, sure
<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>In unknown file:
<jmd> ?: 0 ["The GNU Bourne-Again SHell"]
<jmd>
<civodul>what's the line just after?
<civodul>with the exception type
<jmd>ERROR: In procedure The GNU Bourne-Again SHell:
<jmd>ERROR: Wrong type to apply: "The GNU Bourne-Again SHell"
<jmd>
<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>hello guix everywhere!
<th3kent>civodul: i am testing x86_64.
<davexunit>hey th3kent!
<davexunit>thanks for testing things
<th3kent>sure thing davexunit. i am also playing with guix, and re-learning lisp/scheme. (-8
<jmd>new branch: wip-libreoffice
<davexunit>cool
<jmd>Be even cooler if it worked.
<davexunit>it will soon enough
<davexunit>that's a big task. thanks for working on it.
<davexunit>it's a very important application
<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>mark_weaver: Hi
<jmd>Is there a way I can lookup the package definition given its name and version?
<bavier>jmd: `guix package --show=...`?
<jmd>No. I mean programatically.
<davexunit>jmd: find-packages
<jmd>From within a package definition
<bavier>jmd: wasn't sure what you mean by "package definition"
<bavier>*meant
<jmd>Where is find-packages defined ?
<bavier>(gnu packages)
<jmd>Odd. Using find-package-by-name a package cannot find itself.
<bavier>jmd: what's your use-case?
<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.
<jmd>s/installed/built
<civodul>oh right, it was removed in c198872b
<civodul>i wonder why
<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.
<civodul>th3kent: oh, ok
<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>If you like.
<jmd>Easy once you know how!
<civodul>:-)
<jmd>civodul: I pushed the wip-libreoffice branch
<civodul>jmd: excellent, thanks!
<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>Will a gc fixit?
<civodul>jmd: --localstatedir mismatch?
<jmd>I don't think so.
<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>Maybe.
<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"