IRC channel logs


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>vmlinuz88: 'guix system init'
<vmlinuz88>davexunit Thanks, I will try that.
*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>vmlinuz88: that doesn't need to run
<davexunit>that's so that the limited size of the ramfs doesn't cause installation failure
<vmlinuz88>davexunit Ah I see
<davexunit>socket activated containers, cool!
<civodul>Hello Guix!
<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.
<civodul>rekado_: excellent!
<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_>it's awesome.
<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 ?
<civodul>Steap: actually no :-)
<Steap>What is he waiting for ? :p
<civodul>heheh :-)
<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?
<davexunit>amz3: /var
<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 ? :)
<davexunit>daviid: no
<davexunit>at least, I don't see how.
<davexunit>these are Linux containers.
<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
<amz3>docker 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.
<civodul>davexunit: re .gitignore, yes
<davexunit>they all use the same underlying kernel features
<davexunit>which different UIs
<civodul>oh, yay for wip-container!
<daviid>i see, ok thanks [both] for these clarifications
<davexunit>civodul: will be rebased heavily ;)
<civodul>i can imagine :-)
<davexunit>but I wanted to make the work public
<civodul>amz3: on GuixSD, Guix uses /var for its state data
<civodul>yes, that's good
<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
<civodul>(which sucks)
<DusXMT>So it's almost like downloading a Live CD to use a single program, imho
<davexunit>yeah, what civodul said.
<daviid>which is even better
<davexunit>it's the "wrong" way to use a container, IMO.
<davexunit>the GuixSD way will be much better.
<DusXMT>It's the Windows approach at package management...
<davexunit>since we'll achieve cross-container deduplication via the store.
<daviid>ah, I'm lost now
<davexunit>sounds buzzwordy :)
<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
<davexunit>you could do that without containers
<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
<daviid>i'm confused
<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 :)
<amz3>over debian
<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.
<davexunit>it's a very "enterprise" school of thought
<amz3>daviid: btw, guile-clutter works?
<daviid>amz3: yes
<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>s/even if not duplicating/
*daviid needs to start to try/use guixsd
<civodul`>alezost: ah ah, it worked! :-)
<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
<wingo>there is code here if anyone gets to it before me:
<ijp>huh, I thought gitorious was shutting down at the end of may
<davexunit>it's read-only now
<daviid>ijp: write access has been closed mid may
<alezost>civodul: I'm confused. It looks like what you describe doesn't work without a special Emacs package. At least that's what I've got from <>.
<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
<civodul> might be relevant
<mthl>civodul: I guess you have installed bash-completion emacs package
<mthl>civodul: Does it work for you with "emacs -q" ?
<civodul>doesn't work with -Q
<civodul>i have auto-complete installed
<civodul>could be that
<alezost>civodul: ah, now I see, thanks
<alezost>if I have a feature request, should I report it to <>?
<alezost>reported :-)
<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...
<civodul>mark_weaver: quoth "Both ARM and ARM64 are now supported in upstream GRUB - both are available in the grub 2.02 betas"
<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 ;))
<civodul>ah, oh?
<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
<civodul>in (gnu build install)
<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
<civodul>ah ok
<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>i see
<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>ok yeah, that's the problem
<civodul>it should be possible to reuse the store
<bavier>yes, that would be nice
<civodul>could you file a bug?
<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
<bavier>sure, I can send a bug
<civodul>yeah, that needs to be fixed
<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>does anyone else see this?
<civodul>indeed, something is wrong
<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.
<mark_weaver>although I saw a brief message that it was checking
<mark_weaver>(for a newer version)
<civodul>this is interesting
<civodul>first, note that both are maintained by the same person ;-)
<mark_weaver>heh, indeed.
<civodul>second, gnu-pw-mgr has a subdirectory called gnu-pw-mgr-1.1, and that fools our code
<civodul>well, gpw-1.1
<civodul>let's see
<mark_weaver>(check-package-freshness sharutils) also fails
<mark_weaver>maybe for similar reasons
<mark_weaver>well, no. sharutils seems to have a conventional layout on
<civodul>yes, it's the same code
<civodul>sharutils also has a subdir
<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
<civodul>mark_weaver: i pushed a fix
<mark_weaver>civodul: thanks!