IRC channel logs

2014-11-28.log

back to list of logs

<cmhobbs>is guix designed to replace existing fsf endorsed gnu/linux distributions or is it just another parallel project?
<_`_>cmhobbs: https://lists.gnu.org/archive/html/gnu-system-discuss/2014-11/msg00002.html I think this thread addresses that question.
<cmhobbs>thanks
<cmhobbs>_`_, well that turned into a depressing argument... i do appreciate the insight, though
<tadni>It's weird to see people argue , that the point of the GNU project is not to provide a fully Free and useful Operating System.
<jmd>tadni: Who was arguing that?
<tadni>jmd: Towards the beginning of the top of the earlier linked thread.
<tadni> https://lists.gnu.org/archive/html/gnu-system-discuss/2014-11/msg00002.html
<tadni>" The priority of the GNU project has always been to free users, not to develop the GNU system. Since we have a free system, our priorities are to work on furthering the goal of freedom for all computer users.
<tadni>"
<tadni>I mean, in a way, that's right.
<tadni>But that's not the original intent.
<tadni>And I think it weakens GNU, by not being under GNU officially.
<tadni>As-in, having an OS/Distro that we could deem cannonical.
<tadni>It's not as if Trisquel, Parabola, gNewSense, Etc, have any grand workforce behind them right now as-is.
<tadni>Nor do I see their capacity to grow in any grand way, a realistic expectation.
<jmd>Since I know that this channel is logged, I'm reluctant to comment.
<tadni>At least under the GNU name and doing something fairly radically different from other distros, GNU Distro would be doing something that may possibly unite the /very/ limited efforts of said other Distros, to have one, solid, experience, we could point users to. I really respect the work of the literal one serious Trisquel Dev that works very hard to provide such a thing. The less than 3 serious devs for Parabola and gNewSense,
<tadni>respectively, too -- just as much. But there is no real growth factor there.
<tadni>I'm not sure if there is with GNU Distro, but it seems more likely. And if that means it has to in-part cannibalize other Free-Software distros to have one really strong all free-software system we could point to, I'm willing to take that risk.
<tadni>I think GNU Distro is probably, the most important GNU project right now, next to maybe Mediagoblin; Seriously.
<tadni>We are REALLY lacking in general man-power for any of the all-foss listed distros on GNU's suggested page.
<tadni>jmd: You can pm me, if you think it's too risky. I could probably tell you how "out there" and/or polarizing it may be. I'm pretty open about such things, obviously. :^P
<tadni>civodul: o/
<tadni>civodul: I have a friend that is interested in running an instance of Hydra in the nearish future for Guix, fyi. :^)
<civodul>Hello Guix!
<civodul>tadni: yay!
<civodul>would be nice
<tadni>He's doing a startupish thing, and wants to see if he can manage on GNU Distro.
<civodul>ok
<tadni>He was relatively shocked how little web-tech is packaged as of yet.
<tadni>That being said, I very much doubt many are using GNU distro and/or generally Guix, for any deployment for anything right now.
<tadni>Very, very few, probably have it installed on a dedicated machine at all. :^P
<tadni>So, RMS arguments seems to boil down to, in "When can we expect a version 1.0 of the GNU Operating System?" -- that the GNU Distro does not currently support the HURD and they don't want to downplay other GNU variants.
<tadni>Both of these seem very fixable.
<tadni>Hurd is in-route to being supported in the nearish future, and the downplaying can be negated by making sure it is known somewhere noticeable that there are variants and provide links to them.
<tadni>This thread though, seems to be really up in arms about trivial terminology.
<civodul>yeah
<tadni>Keep "The GNU Operating System" as a nebulous notion, and have the "GNU Distro" be the official Distribution of such a project. Not the "actual" GNU Operating System.
<tadni>There are too many strongly established mixed interests already, to have a agreed upon GNU Operating System.
<tadni>A distro, is a generalized implementation of relevant tech in a specific way.
<civodul>yeah, perhaps
*civodul goes grab coffee to get started
<tadni>And, too, if we provide a framework that makes it easy for people to set up their system in a very personal way (such as what Guix and the general GNU Edsl currently does and will only get better at doing) -- we don't have to make everyone happy right out of the gate. Something, in the realm of the GNU project, I don't think it is possible anymore to make everyone happy in the community with such a system. But give them the tools to
<tadni>easily configure a system to their needs, and that goes a long way.
<tadni>Really, it's about generally finding that balance of how to make the most people happy. Providing a minimal image, with a ton of config files one can edit in an install is a good way to appease more technical users. And providing a "full" image for GNOME and other relevant software like Libreoffice, etc, is a good catchall for everyone else and/or the average user. Sane but, highly configurable defaults are important and something we
<tadni>really need to focus on -- me thinks.
<tadni>We're on the right path though.
<tadni>Anyways, I'd love to continue this conversation ... but I really should head to bed, so I don't sleep all day.
<tadni>I'll be back at some point, probably, later today. o/
<alezost>I'm trying to build guix from the GNU|Guix system, but no luck. I tried to install all tools in my profiles but was stuck at "configure: error: C compiler cannot create executables"
<alezost>Inside "guix environment guix" the process went much further, but also failed on "configure: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README'."
<alezost>config.log has "guix_cv_libgcrypt_usable_p=no"
<alezost>oh, libgcrypt can't be dynamically loaded. What to do with that?
<civodul>alezost: did you use --with-libgcrypt-prefix?
<alezost>civodul: no
<civodul>you'll probably have to do that, so that Guix knows where to find it
<civodul>otherwise you'd have to add it to LTDL_LIBRARY_PATH or similar, but that's Bad
<alezost>should it be /gnu/store/…-libgcrypt-1.6.2/bin/ ?
<civodul>without /bin
<alezost>it helped! thanks!
<civodul>yoo!
<civodul>so how do you like your GNU|Guix|whatever system? :-)
<alezost>it's awesome!!! I am enjoying!!!
<alezost>The only bad thing is my nature: I try to configure every little thing instead of concentrating on important ones. That's why my contributing to guix is paused right now but I'll continue soon :-)
<civodul>heh, cool :-)
<Sleep_Walker>substitute-binary: guix substitute-binary: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable
<Sleep_Walker>what is this error saying?
<Sleep_Walker>(well, warning)
<nkar>Sleep_Walker: I don't know what needs to be done, but try to search the manual and email archives for "access control list"
<alezost>Sleep_Walker: you need to authorize hydra
<alezost>Sleep_Walker: guix archive --authorize < hydra.gnu.org.pub
<Sleep_Walker>nkar, alezost: thanks, it seems it helped
<nkar>np
<davexunit>good morning #guix
<Sleep_Walker>good afternoon :)
*davexunit recovering from thanksgiving dinner and the subsequent party
<davexunit>civodul: read a bit about the --with-libgcrypt-prefix stuff, I should really do the same for one of my projects. right now my guix environment recipe tweaks LTDL_LIBRARY_PATH.
<Sleep_Walker>I'm confused - I prepared configuration looking like this http://sprunge.us/ZcIQ but `guix system init /path/to/config /guix' doesn't prepare root fs as I expected
<Sleep_Walker>there is new filesystem created but for example /guix/bin is empty..
<davexunit>that dir might not be populated upon install
<davexunit>from what I remember, the only thing in the /bin directory is sh, a symlink to bash in /gnu/store.
<Sleep_Walker>but there is not even that one
<davexunit>might be created on first boot
<davexunit>I dunno.
<Sleep_Walker>I wanted to chroot inside to install more packages
<Sleep_Walker>but again, I may have wrong expectations
<davexunit>well not having /bin shouldn't stop ya
<davexunit>is there a current-system directory?
<alezost>Sleep_Walker: do not chroot there; just reboot into it and hack on the fly :-)
<davexunit>heh, my cat just jumped up on the couch with me. cat in the hack.
<civodul>Sleep_Walker: 'guix system init' should create /bin and leave it emtpy, among other things; see (gnu build install) for the details
<civodul>and then, /bin/sh is created when it boots, see (gnu build activation)
<civodul>but yeah, as alezost says, just reboot and watch ;-)
<civodul>davexunit: do people in the US have a day off today as well?
<davexunit>depends on your job. I have the day off.
<civodul>in France, people often have "bridges", meaning if there's a day on Thu, then they'll also take a day off on Friday
<civodul>the boss "unions" don't like that :-)
<davexunit>people in the service industry, restaurants and stores, are working.
<davexunit>I took wednesday off as well so that I'd have a nice little break.
<civodul>nice
<alezost>civodul: not a bug, but just inconvenience: I used to use some scripts with "#!/bin/bash", so perhaps it would be acceptable to make another link (/bin/bash) along with /bin/sh. WDYT?
<Sleep_Walker>OK, I'll set up grub and give a try :)
<Sleep_Walker>civodul: you use '(gnu build install)' for pointing me to documentation - how can I interpret that?
<Sleep_Walker>the only documentation I'm aware of is online
<alezost>Sleep_Walker: (gnu build install) is a guile module: "…/gnu/build/install.scm"
<Sleep_Walker>aha
<civodul>Sleep_Walker: ah sorry, it was meant as a suggestion in case you want to see the details
<civodul>it's no substitute for the documentation, though :-)
<civodul>alezost: yeah, could be
<civodul>NixOS people ended up adding /usr/bin/env, but i'd like to avoid that
<civodul>(answering before you ask ;-))
<alezost>:-)
<Sleep_Walker>civodul: I'm very surprised how well readable the code is so I understand the process now
<Sleep_Walker>and have to make adjustments myself
<Sleep_Walker>I assigned LVM partition for guix and grub was complaining that it can't read /boot, I have separate /boot partition so I can fix it manually
<Sleep_Walker>do you support separte /boot partition at all?
<Sleep_Walker>grub.cfg is full of paths to another filesystem (gnu store with grub)
<Sleep_Walker>moment of truth
<Sleep_Walker>omg
<Sleep_Walker>guile interpreter as fallback
<nkar>Sleep_Walker: iirc, the manual says that lvm is not supported
<nkar>but I don't know the details
<jmd>Sleep_Walker: Great! Isn't it?
<davexunit>guile as fallback?
<nkar>davexunit: recovery shell
<nkar>or whatever it's called
<nkar>it's like ludo's boot-to-guile, I think
<davexunit>for grub? I haven't noticed that
<nkar>after grub
<davexunit>booting to guile is pretty neat
<jmd>How can I find out the dependencies of a package which is not installed?
<taylanub>we have a Guile shell as a fallback when something in the boot process goes wrong or what?
<nkar>jmd: search for 'guix-prefetch' on the mailing list
<nkar>basically, by traversing the list of dependencies
<Sleep_Walker>jmd: I believe it's great once I learn enough
<nkar>taylanub: yes
<davexunit>I guess we should have a 'guix package --list-dependencies foo' command or something
<nkar>yes, that'd be useful
<taylanub>wow, that's neat :)
<nkar>there's dry-run, of course, but it's doesn't list all of them
<davexunit>oh yeah, dry run
<davexunit>but yeah, not the same use case as just simply listing dependencies
<davexunit>I had envisioned listing only the direct dependencies
<nkar>yep. having that in a machine readable format would be neat
<davexunit>instead of traversing the whole graph
<Sleep_Walker>is there a way how to alter linux-libre kernel configuration?
<taylanub>users who aren't Guile or Scheme savvy might actually prefer a bourne shell as fallback though; maybe a hint that they can run (system* "bash") would be nice.
<nkar>well, I disagree
<Sleep_Walker>taylanub: thanks for hint
<jmd>taylanub: Perhaps. But where do we stop? do we do something similar for csh fans?
<taylanub>triggering the fallback is surely an error situation anyway, so "shouldn't ever happen" to normal users, but errors happen, and the ratio of unix users who know their way around in sh to those knowing their way around in Scheme is probably quite big...
<jmd>or zsh zealots?
<jmd>What about MSDOS refugees?
<taylanub>jmd: csh and zsh are not nearly as standard as sh/bash
<taylanub>we obviously want to attract (at least, not annoy) typical unix users, no? and I'm talking about just giving them a simple hint :)
<jmd>Running ./configure I get:
<jmd>checking if (json) is available... ./configure: line 7146: 1765 Segmentation fault $GUILE -c "(use-modules (json)) (exit ((lambda () 0)))" > /dev/null 2>&1
<jmd>no
<jmd>checking whether /gnu/store/f4dvdrfccibqm2s43dvgyay7dkdr3962-guile-2.0.11/bin/guile provides feature 'regex'... ./configure: line 7164: 1791 Segmentation fault "$GUILE" -c "(exit (provided? '$guix_guile_feature))"
<jmd>no
<jmd>configure: error: /gnu/store/f4dvdrfccibqm2s43dvgyay7dkdr3962-guile-2.0.11/bin/guile does not support feature 'regex', which is required.
<jmd>
<jmd>Is there some flag I have to set to make guile aware of its module path?
<Sleep_Walker>taylanub: I'm afraid that it wouldn't help anyway as it seems that there is no shell in initrd...
<Sleep_Walker>maybe in later stages of boot
<taylanub>heh, guessed as much. personally I'd go as far as adding a shell there if purely for those who would prefer it. not sure if bash would significantly increase the initrd size though...
<jmd>civodul: How did you say I should work around this problem: ?: 0 [scm-error misc-error #f "~A ~S" ("unknown CPU endianness" "armv7l") #f]
<civodul>jmd: depends; remove --target in Guix Makefile.am, if applicable, as we discussed a couple of days ago
<civodul>Sleep_Walker: separate /boot might boot, but i haven't really thought about it
<civodul>so feedback is welcome if you try it!
<jmd>civodul: Right. Thanks. I forgot.
<Sleep_Walker>civodul: I'm trying that for some time already
<Sleep_Walker>grub files are not copied and should be
<jmd>Here we go again ....
<Sleep_Walker>besides that it seems to work
<jmd>ice-9/boot-9.scm:106:20: In procedure #<procedure 516740 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
<jmd>ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: "libgcrypt", message: "file not found"
<jmd>
<civodul>davexunit: re --list-dependencies, try "guix package --show=coreutils | recsel -p dependencies"
<jmd>What file is it actually looking for? and what variable should I set to keep it happy?
<civodul>jmd: libgcrypt.so; ./configure didn't really pass, did it?
<jmd>Yes. This time it really did!
<jmd>I didn't even force it.
<jmd>LD_LIBRARY_PATH should satisfy it?
<civodul>Sleep_Walker: the (gnu build install) module runs 'grub-install', which should copy whatever is needed to /boot, no?
<jmd>no. Maybe GUILE_LOAD_PATH
<civodul>jmd: LTDL_LIBRARY_PATH, perhaps
<jmd>No. That doesn't work either
<alezost>during "./pre-inst-env guix system reconfigure" I get "guix system: error: system locale lacks a definition". What does it mean?
<civodul>alezost: congrats, that's the brand new thing!
<civodul>the brand new error, that is
<civodul>alezost: please tell me if the "Locales" node helps you find out how to fix it :-)
<alezost>civodul: ok, with what package does this node come?
<alezost>I also often get "sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)" in a console output; perhaps it is related
<civodul>alezost: in guix.info
<civodul>the other issue is not related
<civodul>it's just that you have the "crippled bash" in $PATH
<civodul>"guix package -i bash" will fix it
<civodul>(and with the locale support in core-updates, that problem will be gone)
*civodul has to go
<civodul>ttyl!
<jmd>Better to have a crippled bash, than a bashed cripple.
<Sleep_Walker>I live again
<Sleep_Walker>can guix prepare sources for package and stop?
<jmd>What do you mean "prepare sources" ?
<Sleep_Walker>I mean - get tarball, expand, patch
<Sleep_Walker>like in Gentoo `ebuild <file.ebuild> prepare'
<Sleep_Walker>useful state for generating patches in case of something broken
<jmd>I don't know gentoo
<Sleep_Walker>`quilt setup <file.spec> ; cd <newdir> ; quilt push -a' for RPM distros
<taylanub>Sleep_Walker: 'guix --help' will show you that there's a subcommand 'build'. so 'guix build --help'
<Sleep_Walker>taylanub: I already checked that, but none of those options looks like the one I mean
<jmd>Sleep_Walker: If you can explain what you mean, then perhaps someone can answer your question.
<taylanub>Sleep_Walker: oh I see, a full 'guix build' will go as far as "installing" the package (in its isolated directory), and you just want the sources ... correct? I imagine one could somehow tell guix to stop after a given "phase" of a build process, but probably no such interface exists yet.
<Sleep_Walker>right!
<jmd>guix build -S will stop after fetching the source.
<jmd>What I do, if I want it to stop after, say, unpacking - I just put #f at the end of that phase.
<Sleep_Walker>jmd: imagine there is bug in package mc, you know how to reproduce it and would like to check the code, write fix and create patch that would be applicable on top of current sources
<jmd>Sleep_Walker: I think the guix environment command is supposed to help with that.
<davexunit>jmd: yes, guix environment works very well for this.
<Sleep_Walker>aha
<davexunit>I was having issues with guile-sdl's test suite, so I used 'tar xf $(guix build -S guile-sdl)' to fetch and extract the source, and then 'guix environment guile-sdl' to spawn a shell with everything needed to build.
*taylanub notes guix build -S
<taylanub>(also, I can't read apparently :P)
<davexunit>it might be nice to write a helper to encapsulate this operation if it becomes a common enough practice, which seems likely.
<davexunit>say, 'guix environment -S guile-sdl' or something
<Sleep_Walker>it's common task for package maintainers :)
<davexunit>I didn't even think of this use-case when I wrote 'guix environment', but it's a good one.
<davexunit>I had my eyes set solely on development environments when working with git checkouts.
<davexunit>s/git/<whatever vcs>/
<jmd>davexunit: Maybe you can test out guix-environment by debugging the wip-libreoffice branch!
<davexunit>jmd: are you not able to do that? would be good to have more people using it than just myself.
<davexunit>I have my sights set on one-upping vagrant and docker.
<jmd>davexunit: Right now, I'm lacking time and resources.
<davexunit>I see.
<davexunit>I just have so many other projects on my plate.
<jmd>... like all the rest of us ...
<davexunit>yup
<davexunit>currently trying to spend a little time on my pet project.
<davexunit>trying to get over a major roadblock that's really hampered its development.
<Sleep_Walker>which dev filesystem guix rely on in initrd?
<Sleep_Walker>oh devtmpfs
<Sleep_Walker>was there any reason for not supporting LVM?
<davexunit>no one has done the work to add support for it yet.
<Sleep_Walker>ok
<Sleep_Walker>how are /gnu/store/*init and /gnu/store/*linux-modules created?
<Sleep_Walker>it doesn' seem to be package
<Sleep_Walker>I have new kernel image with alternative configuration and I'd like to trigger recreation of this part...
<Sleep_Walker>civodul: how are /gnu/store/*init and /gnu/store/*linux-modules created? I have new kernel image with alternative configuration and I'd like to trigger recreation of that...
<Sleep_Walker>it doesn't seem to be package...
<Sleep_Walker>hmm, probably parto fo guix system - I found linux-initrd.scm, which is loaded from system.scm
<Sleep_Walker>s/o fo/ of/
<civodul>Sleep_Walker: it's all created from your OS config when you run 'guix system'
<civodul>so "linux-modules" comes from (gnu system linux-initrd)
<civodul>and the other (gnu system)
<civodul>i think?
<Sleep_Walker>it seems so
<Sleep_Walker>...getting closer...
<jmd>Building guix-dev I get: ;;; WARNING: compilation of /gnu/store/1n5fhw8f1v76wpd6i7q9isjkciy4wg8n-guile-2.0.11/bin/guild failed:
<jmd>;;; ERROR: failed to create path for auto-compiled file "/gnu/store/1n5fhw8f1v76wpd6i7q9isjkciy4wg8n-guile-2.0.11/bin/guild"
<jmd>guix/build/download.scm:122:17: warning: possibly unbound variable `make-session'
<jmd>guix/build/download.scm:122:17: warning: possibly unbound variable `connection-end/client'
<jmd>guix/build/download.scm:130:8: warning: possibly unbound variable `set-session-server-name!'
<jmd>
<jmd>Folowed by misc-error
<Sleep_Walker>I'm facing problem with missing libahci kernel module (and probably more), it's hardcoded in linux-initrd.scm...
<Sleep_Walker>another kernel rebuild
<civodul>linux-initrd.scm normally makes sure libahci is in the initrd, and gets loaded at boot time
<civodul>isn't it the case?
<Sleep_Walker>in my case I have custom made kernel only with hardware support for really present hardware
<Sleep_Walker>so either it is compiled in as used or disabled
<Sleep_Walker>but I altered my config to provide those modules
<Sleep_Walker>(but it would be nice if configuration would be separated (or separable))
<Sleep_Walker>(sorry if it is and I didn't find out)
<civodul>ok
<civodul>was the default kernel unsuitable?
<civodul>the chief kernel config person is jxself, in case you want to complain ;-)
<Sleep_Walker>well, I'm trying unsupported scenario - with LVM
<Sleep_Walker>so I don't feel like blaming anyone but myself
<Sleep_Walker>and with separate /boot partition
<civodul>ouch, indeed ;-)
<civodul>separate /boot is probably doable, but LVM sounds like more work
<Sleep_Walker>well, I'm not sure yet why
<jxself>Isn't this kernel module already specified in linux-libre-x86_64.conf linux-libre-i686.conf?
<jxself>er there was supposed to be an "and" there :)
<Sleep_Walker>yes
<Sleep_Walker>that is the file I replaced to build my kernel
<Sleep_Walker>it may have been unnecessary
<Sleep_Walker>but I had my config proven to work so it was good start for DM & LVM related stuff
<jxself>So is the module enabled in your .config? Or is it the case that it was left out?
<jxself>I'm not sure why it'd be missing if it was enabled.
<Sleep_Walker>in my configuration were those modules missing
<jxself>Ah ha.
<Sleep_Walker>proper SATA driver was compiled in, PATA ommited completely
<jxself>Oh I misread that to say they were missing.
<civodul>Sleep_Walker: the initrd does have PATA modules by default
<Sleep_Walker>I think I have to adopt how to work with guix first, and complain after :)
<civodul>:-)
<civodul>good night/day!
<Sleep_Walker>gn, and thanks!
<Sleep_Walker>