IRC channel logs
2015-06-02.log
back to list of logs
<vmlinuz88>Is it possible to install GuixSD onto another hard drive partition from Debian? similar to how debootstrap works? *davexunit aaaalmost has user namespace working in container <vmlinuz88>I was thinking of something like that; however, I recall that on the installation cd for GuixSD, there is a command that must be run 'deco start cow-store /mnt'. How would I initialize the gnu store on my Debian host without the deco service running? <davexunit>that's so that the limited size of the ramfs doesn't cause installation failure <rekado_>good news, I think: I was invited by the cluster admins of a new bioinfo institute in Berlin to discuss software management with Guix. <Steap>rekado_: do you think you'll end up working with them ? :p <amz3>Héllo, I'd like to rertrieve passwords from gnome keyring, has anybody tried to install GNOME's seahorse <rekado_>amz3: I have, but I wasn't successful in retrieving passwords via python2-gnome-keyring yet. <rekado_>Steap: I already *am* working with an institute that's using Guix. Their cooperation is close so I might actually end up supporting software on yet another cluster. <Steap>rekado_: so, is part of your job actually installing Guix on clusters, packaging the scientific packages they need, etc. ? <rekado_>Steap: yes, packaging stuff for Guix has become part of my job. <rekado_>sadly it's not the only thing I'm doing. <Steap>rekado_: well, if you can be paid to do cool stuff, even 1/10th of the time, that's cool ! <Steap>civodul: isn't Andreas doing something similar ? <amz3>that a good news for guix <amz3>rekado_: is there somewhere a gnome-keyring.scm I can have a look at? <rekado_>amz3: gnome-keyring and seahorse are both defined in gnome.scm. <davexunit>civodul: shall we add a rule to .gitignore for "doc/*.1" or something? *davexunit pushes 'wip-container' branch <amz3>what is the localstatedir of GSD? <daviid>davexunit: wrt this container work you're doing, assuming we'd have guile-gnome[clutter] in guix[sd], does that mean i could, 1 day, expect my apps to run on other [terrible] OSs that i won't tell the names ? :) <amz3>daviid: you mean ship container instead of sources or binaries? <davexunit>so if your OS doesn't use Linux as its kernel, it won't work. <amz3>IIRC it's possible to run GUIs in containers <davexunit>but the term "container" has many possible interpretations <daviid>i must have miss understood some of the very breif reading i've done about docker/containers then <davexunit>the key thing to keep in mind is that they depend on a Linux-based host system. <davexunit>other kernels have other methods. the HURD, being a microkernel, can do much more fine-grained virtualization than Linux can. <daviid>davexunit: i thought the container would run guixsd, the user OS specific docker would run the container... then my guile-gnome[clutyter] apps would run anywhere <daviid>as a replacement of VM, which is nice and a nghtmare :) <amz3>docker is a jail container or improved chroot they can not run another architecture or OS, VM are basically eemulators, so they do whatever they want :)) <amz3>daviid: it can run on the same/compatible kernel you compiled the container <davexunit>containers take away the emulation layer, which can be great for certain use-cases. <davexunit>also keep in mind that Docker is just a single container implementation. <davexunit>they all use the same underlying kernel features <daviid>i see, ok thanks [both] for these clarifications <civodul>amz3: on GuixSD, Guix uses /var for its state data <daviid>davexunit: so the advantage of a container would be [still tremendous] that i packe everything kisê needs in a container and then any linux, any distro can run my app? <daviid>kisê or any guile-gnome/clutter app <DusXMT>daviid: yes, but your "app" is basically an independent system <DusXMT>So it's almost like downloading a Live CD to use a single program, imho <davexunit>it's the "wrong" way to use a container, IMO. <DusXMT>It's the Windows approach at package management... <davexunit>since we'll achieve cross-container deduplication via the store. <davexunit>daviid: you *could* use containers that way, but I don't think it's healthy for distributions. <daviid>I want to build something that contains guile, guile-gnome and any apps, then people grab it ruin it <daviid>[ users are totally unable to compile guile-gnome these days ] <davexunit>containers provide isolation of system resources <DusXMT>daviid: the correct way would be to write a program, and then approach distribution maintainers to package it and add it to their distribution <davexunit>for example, we ship a binary tarball with guix that users can just extract and run. <daviid>DusXMT: that's what i want to avoid <DusXMT>daviid: And why exactly? What's wrong with that approach? <davexunit>daviid: we think distribution integration is better than the wild west of shipping full system images for each piece of software <amz3>daviid: it's handy to distribute containers, GNOME is looking at it too, but it's not healthy for the econ-system <daviid>what i dont want is to rely on debian [for example] because it will take 2 years they get guile-gnome back in their stable distro, so <amz3>ask users to install guix instead :) <davexunit>yeah, users can install guix on top of their host distro and 'guix package -i guile-gnome' <davexunit>trying to circumvent distros isn't a great idea. <amz3>daviid: btw, guile-clutter works? <daviid>davexunit: i understand the future is guixsd <daviid>so i think, imo, perfect idea to pack something that runs <davexunit>but then you duplicate a million libraries that people already have on their host system <daviid>and if that is, now, a guixsd all-in-one :) on top of what ever distro the user has, for me it is perfect <davexunit>with guix, we can make containers and such a lot friendlier via the store <davexunit>which provides all the deduplication that a distro needs <amz3>daviid: I think that shipping container or at least making easy to create container with guile-gnome will be helpful for people. <daviid>davexunit: i understand that in a perfect world they would be no duplication. the problkem wee face, now is that nobody uses ant of our apps and almost nobody develop using guile-gnome clutter <DusXMT>daviid: And duplication isn't the only program; your libraries will age with time; in a distribution, not only will the libraries get updated, but you (or the maintainer for your project) will have to adjust your program, evolve it, to make it work with the new versions. <daviid>alright, i understand you're somehow against it, i trying to find a solutio right now... <daviid>DusXMT: guile-gnome is 30 version behind the latest gnome libs... <amz3>you are right, it help guix to ship container even for development <daviid>the siolution , even if duplicating, will always demand maintaince, _but_ I would do it, once, for the entire world <alezost>civodul`: Hi. Sorry, I don't understand what you mean by "adding pcomplete support for the guix commands" <daviid>anyway, thanks all, will think about all this slowly *daviid needs to start to try/use guixsd <civodul`>alezost: i mean that, when in shell-mode, git sub-commands are nicely completed <civodul`>it Would Be Nice if the same happened with guix sub-commands <alezost>civodul: ok, it's clear now. git sub commands are not completed for me; did you do some special configurations there? <daviid>i'd just need kvm to run/try guixsd right? [they say qemu/kvm but in my debian testing i would just ned kvm? <rekado_>daviid: you don't need kvm when you run GuixSD on hardware ;) *wingo should port svg rasterization to use guile-rsvg instead of inkscape <ijp>huh, I thought gitorious was shutting down at the end of may <daviid>ijp: write access has been closed mid may <paroneayea>ijp: archive team took over or is taking over to preserve it as read-only iirc <civodul>alezost: i don't know how it works, but it turns out that 'git' commands are nicely completed here <mthl>civodul: I guess you have installed bash-completion emacs package <mthl>civodul: Does it work for you with "emacs -q" ? <alezost>if I have a feature request, should I report it to <bug-guix@gnu.org>? <civodul>alezost: oh and yes, that's the right thing to do :-) <bavier>could 'guix system init/reconfigure' create user home directories if they don't exist? <alezost>bavier: IIRC "guix system init" created the home dir for me <civodul>bavier: they are created at "activation time", ie., when booting <bavier>alezost, interesting, that didn't seem to happen for me... <alezost>bavier: sorry, it was at activation time, as civodul says <bavier>After an init, I couldn't log in to the user account because of the missing home dir; needed to log in to root and create it first <bavier>(I did a fresh install a bit ago, and I'm now just looking back at my notes of issues ;)) <bavier>well, for those who can't type, it might be nice to validate the filenames in e.g. the grub device <civodul>in (gnu build activation) we do pass --create-home to useradd <davexunit>I had an issue when booting a container that /home needed to be created first <civodul>bavier: re grub, normally 'guix system init' fails when 'grub-install' fails <civodul>davexunit: i think useradd creates both no? <civodul>but actually /home is normally created by guix system init <bavier>civodul: yes, it fails, but only after quite a bit of other installation work, and there's some non-trivial recovery work that needs to be done before attempting the 'guix system init' again <bavier>I had missed the leading '/' on "/dev/sda" for the grub device <bavier>the installation continued with a bunch of downloads from hydra, and only after about a half hour did grub-install finally run and fail <civodul>and you had to delete the store before you could rerun 'init', right? <bavier>according to my notes, after I fixed the /dev/sda, I needed to remove /mnt/var, /mnt/grub, and /mnt/gnu/store before rerunning 'guix system init' <civodul>it should be possible to reuse the store <civodul>i don't think we really want to try to validate GRUB's arguments <civodul>however, we do want to make it possible to rerun guix system init without redownloading everything <bavier>I think the store items that were downloaded were still cached somewhere, but it otherwise complained about already existing directories <mark_weaver>hmm, "guix refresh -u" is not working for me. I've tried it on both 'sharutils' and 'gnu-pw-mgr', both of which need updates. in both cases, the command produces no output and returns status 0. <mark_weaver>"guix package -i sharutils" also fails to detect that there's a newer version, so I guess that's where the problem is. <civodul>first, note that both are maintained by the same person ;-) <civodul>second, gnu-pw-mgr has a subdirectory called gnu-pw-mgr-1.1, and that fools our code <mark_weaver>well, no. sharutils seems to have a conventional layout on ftp.gnu.org <mark_weaver>huh? there are subdirs, but the sharutils tarballs are in the standard place, no? <mark_weaver>does the existence of su-4.14.2 or REL-* directories confuse the code? <mark_weaver>oh, I see. if there are any subdirectories at all with numbers in their names, it looks in there. <mark_weaver>rather than trying to make this smart enough to try to decide whether to look in subdirectories, it would probably be better to start adding such information to the package objects. <mark_weaver>it would be great if we could incrementally add 'check-package-freshness' support to non-GNU packages, starting with packages that could be handled with the same code but a different ftp URL. <mark_weaver>well, this is not a high priority though. no need to do it now :) *mark_weaver will update these packages manually