IRC channel logs


back to list of logs

<zacts>how will dmd deal with systemd crap?
<zacts>and how did a former Gnu project, gnome, become a systemd red hat project?
<zacts>and are there plans to have a different default wm for guix? =)
<alezost>zacts: AFAIK dmd has nothing to do with systemd and systemd is not used in GNU Guix distro
<DusXMT>alezost: I think he's asking about programs which expect systemd, like Gnome 3.8
<alezost>ah, indeed, sorry for misunderstanding
<DusXMT>Unless we find a way to emulate systemd, I think things like Gnome 3 will simply not be available. Not that a lot of people like it, either (or perhaps I'm wrong?)
<ijp>people who are vocal $foo basically never represent the majority opinion of $foo
<civodul>Hello Guix!
<ph4nt0mas>hey civodul
<ph4nt0mas>I wanted to ask you, have you checked any of the emails about glibc/hurd and crossbase?
<ph4nt0mas>from like one month ago :P
<ph4nt0mas>and good morning btw :)
<civodul>hey ph4nt0mas!
<civodul>yes, i know!
<civodul>i feel guilty
<civodul>i owe too many people too many things ;-)
<ph4nt0mas>haha okay then :P
<civodul>sneek: later tell davexunit yay for the F-Droid talk! :-)
<sneek>Got it.
<alezost>How are emacs packages (installed with Guix) supposed to be used? I mean I need to add some "/gnu/store/.../share/emacs/site-lisp/" dir to `load-path' variable to be able to load a package in Emacs or is there another way?
<civodul>alezost: yes, add ~/.guix-profile/share/emacs/site-lisp to `load-path'
<alezost>civodul: hello, it's strange as I don't have a link to "~/.guix-profile/share/emacs/" here
<Svetlana>civodul: Hi. I added a note on the screenshots page -- they're licensed freely and you can reuse them if you like.
<civodul>alezost: you should see it if you install Emacs, Paredit, or something like that
<civodul>Svetlana: thanks, i've pushed the fix BTW
<alezost>civodul: thanks, I have installed geiser and paredit, but not emacs (installing it now)
<Svetlana>Where is it -- in git I think? Is there a next image or are those only for releases?
<DusXMT>Svetlana: you can build it with $ guix system disk-image ~/.config ~/.config/guix/latest/gnu/system/install.scm
<DusXMT>oops, without the first '~/.config'
<DusXMT>or you can also get that last file from git
<DusXMT>or at least I think so (that this is how to make the USB image), I'm not 100% sure
<civodul>Svetlana: it's in git; you could rebuild the image if you install it on your other distro
*civodul now sees DusXMT's reply
<civodul>i should read further before replying :-)
<Svetlana>i have plenty of questions on understanding what that does (like "does git:// contain guix pkg manager or also the linux-libre stuff? or does `guix system disk-image` download it from somewhere? where does it save the disk image to? why should ~/.config/guix/latest/gnu/system/install.scm path work if i don't have such file?")
<Svetlana>meaning that I'm a little lost
<Svetlana>need to read relevant sections of the manual at a point, I was lazy and skipped them
<civodul>don't be lazy :-)
<DusXMT>Svetlana: The file would be at that path if you did a guix pull, if you only installed from git, and have the package manager working,you'll find the file in where you cloned the git repo
<DusXMT>that is ${GUIX_GIT_ROOT}/gnu/system/install.scm
<DusXMT>that file contains an operating system declaration for the USB image, I'm pretty sure
<DusXMT>and guix system disk-image creates a disk image of that operating system
<Svetlana>yeah I didn't install it, I only cloned it, I'll read a few, install it and use the command you gave
<mark_weaver>civodul: should the 'gettext-upgrade' and 'bug-17853' jobsets be deleted on hydra? might that free up some space there?
<mark_weaver>hydra seems to be hung up at the moment. for several hours, every job has been waiting for the GC lock.
<mark_weaver>(e.g. libxcursor on x86_64 has been "building" for over 12 hours)
<taylanub>would it be useful to offer my T61 thinkpad with little spare CPU, memory, and bandwidth to be part of thy hydra farm? it's on pretty much 24/7 and otherwise runs Freenet, Tor, I2P, and if I'm actively using it IceCat and MPlayer
<civodul>howdy mark_weaver!
<civodul>mark_weaver: jobsets cannot be removed, only disabled and hidden
<civodul>how did you find out about them? :-)
<civodul>taylanub: actually jxself contributed a very nice machine that i haven't finished to prepare
<civodul>i may complete today, at last
<civodul>so i think it's ok, but thanks!
<civodul>actually the main issue now is with the front-end...
<taylanub>if the overhead isn't too big, half a dozen cheap machines might still be useful? we will only get more packages after all. there would need to be a mechanism to determine what machine can build what though; I can't build Firefox with my 2G of memory half of which is usually already in use
<DusXMT>taylanub: swap is magic: I was able to compile icecat on a pentium 3 computer with 6gigs of swap enabled
<civodul>taylanub: there's some overhead in setting them up currently, and it's also a bit problematic if the machines/network is unreliable
<DusXMT>And it only needs the memory when it's linking libxul, and libxul is the only library that I know of that is a gigantic memory-whore to link
<civodul>DusXMT: how long did it take to build icecat on that machine? :-)
<DusXMT>civodul: 15 hours, more or less. It goes faster when you let it build throught he night :)
<civodul>ahah :-)
<DusXMT>It's definitely faster than trying to bootstrap a guix setpu (just installing the package manager and making it independent of the system) without substitutes, this thing's been going on for 3 days already (but it's already at the point where I'm just updating the packages on it to the newest)
<taylanub>but by the time they're updated, new versions will be out! :P
<DusXMT>heh, probably. But good news is: software doesn't deteriorate, so it's not a big deal if I update every day, once a week or once a month. Of course serious bugs make an exception to this, but still
<mark_weaver>civodul: the "actions" menu at http::// includes an item "Delete this jobset". I did that for my 'file-implicit-input' jobset, and it worked.
<mark_weaver>it took a while, but eventually 'file-implicit-input' no longer appeared in, but I still see 'gettext-upgrade' and 'bug-17853' there.
<mark_weaver>(though I only see them if I'm logged in)
<mark_weaver>civodul: may I attempt to delete the jobsets 'gettext-upgrade' and 'bug-17853' from hydra?
<mark_weaver>(also note that now reports "Jobset 'file-implicit-input' doesn't exist")
<jxself>civodul: Maybe move the frontend to wildebeest too?
*jxself shrugs
<DusXMT>phant0mas: In the past, you've mentioned that you were working on making guix work on the Hurd. Just out of curiosity, how is it going/did it go?
<phant0mas>DusXMT: It's still going, just more slowly cause I am working on some university procjets
<phant0mas>gnumach headers, mig, hurd headers are already part of guix,
<phant0mas> we have managed to cross build glibc / hurd through guix (working together with the hurd guys and especially youpi) and I am awaiting Ludo's review on the last 2 patches I sent.
<phant0mas>after the patches are merged I will continue with packaging gnu mach, hurd and so on
<phant0mas>there are 4 patches at total, waiting to be merged about glibc/hurd
<phant0mas>DusXMT: the patches with the order they were sent
<phant0mas>[PATCH] gnu: hurd: Add Hurd Minimal
<phant0mas>[PATCH] gnu: base: Add Glibc-Hurd Headers.
<phant0mas>[PATCH] gnu: base: Add Glibc-Hurd
<phant0mas>[PATCH] gnu: cross-base: Add libc/hurd cross-toolchain.
<phant0mas>we are getting there :-)
<DusXMT>phant0mas: thanks for the update :)
<civodul>mark_weaver: oh, you can attempt to remove these jobsets then
<civodul>i thought it was impossible
<civodul>jxself: the problem with the front-end is that it needs Hydra, and it'd be really great if that thing were packaged first
<tadni_>Guix hackathon tomorrow night. :^)
<tadni_>gr8: o/
<gr8>what is the difference between and (without -linux)?
<gr8>hi :)
<tadni_>gr8: To my knowledge, nothing.
<gr8>tadni_: given that for the first there is no signature, you may be right.
<mark_weaver>gr8: I believe one is just a link to the other. as I recall, the reason we have two is because some docs had the wrong name.
<gr8>my eyes fell out some minutes ago when I read that there is an installable system version of Guix. xD
<tadni_>I mean, eventually I suspect the -linux suffix will have more meaning once we have hurd installable. :^)
<tadni_>gr8: Yeah, it's stlated to become the "official GNU distro".
<gr8>that's awesome. just Hurd is missing then
<gr8>or maybe you can stay flexible which kernel to choose
<gr8>Minix, Linux etc
<DusXMT>I'm pretty sure Minix is more than just a kernel
<tadni_>DusXMT: Minix 3 is a whole operating system, but they have a modern Microkernel implemented.
<gr8>Linux is becoming more than a kernel, too ^^ with systemd and alike
<gr8>just like Emacs is more than a text editor. btw. maybe you could use guix to put some transparency into Emacs package management
<tadni_>gr8: There is already slated Emacs interaction with Guix, if that's what you mean.
<tadni_>Guix.el is a frontend, similar to package.el's interaction method -- so one can manage system packages there. Too, any packages, packaged by guix for Emacs -- will ideally be autoloaded, like package.el handle it.
*tadni_ might play around with Emms during this upcoming hackathon.
<gr8>tadni_: no, I meant the other way around: use Guix to manage emacs packages from ELPA etc, so you have a uniform interface for system packages and Emacs packages
<tadni_>gr8: It's possible I think, but would need to be worked on. One big thing, would probably just be the generation of a "emacs-build-system" but too -- a general interface, to translate code to the guix dsl.
<gr8>sorry. did I miss something?
<tadni_>gr8: Nah, was just waiting till you got back to post that.
<mark_weaver>gr8: guix has some emacs packages: magit, geiser, paredit, emacs-w3m, emacs-wget. I'd like to add more.
<tadni_>mark_weaver: I might try to add Emms tomorrow. It'd be cool if guix.el could make a seperation between Emacs and System packages.
<gr8>mark_weaver: right, like that. shouldn't be too hard to translate all emacs packages automatically into guix packages, right? it's just files and a version number
<mark_weaver>tadni_: what kind of separation, and to what purpose?
<tadni_>gr8: I mean, for the most part dependencies wouldn't be an issue --- but one still would need a website, description, synopsis, esc.
<mark_weaver>gr8: hmm, dunno!
<gr8>tadni_: could you just pull descriptions from melpa? website is the according wiki site or github ...
<tadni_>mark_weaver: If we want to make it a possible replacement for package.el, I think it would be nice to be able to view all Emacs packages at once. Maybe have a filter key and select a menu for emacs?
<mark_weaver>if we felt the need for something like that, I'd suggest something more general, like maybe a list of keywords attached to each package and then a way to filter based on keywords.
<tadni_>So like what (keywords "emacs audio music") or something?
<gr8>oh btw. does Guix seperate packages into distinct directories, like Nix?
<tadni_>gr8: Like in nixpkgs, or the installed system?
<gr8>ehm ...
<gr8>I was thinking of the system, NixOS
<tadni_>gr8: In /gnu/packages/ in the git repo, no all packages are sharing the same directory. We don't have seperate directories for applications, desktops, development, games, shells, etc.
<tadni_>Once installed, packages are stored in /gnu/store/ in your root directory.
<gr8>I meant all files of firefox are in /somedir/firefox/*, instead of /bin, /etc, /usr ...
<tadni_>gr8: Either in your /gnu/store/xxxxxxxxxxxxxxxxxxx-firefox/ or what have you in your ~/.guix-profile/
<gr8>alright, like Nix. thanks.
<tadni_>mark_weaver: If I do Emms, you think I should add a a media player (mplayer in this case as a depend) or leave it to the user?
*tadni_ also considers whether to put in emacs.scm or should put it in a seperate module.
<alezost>tadni_: I think it should be put in emacs.scm and mplayer should not be a dependency as other players may be used by EMMS instead
<tadni_>alezost: Yeah, I suppose. Thanks.
<DusXMT>Successful guix deployment reported, running on top of Debian Wheezy
<tadni_>civodul: Wb.
<tadni_>DusXMT: Congrats!
<civodul>DusXMT: you mean installation of the package manager, right?
<DusXMT>civodul: yup, but because of this computer being a pentium 3 and substitutes not working, it took around 3 days :-)
<DusXMT>(I did a full bootstrap, so it doesn't depend on debian)
<civodul>ah right, that one :-)
<civodul>well, congrats then!
<DusXMT>next step: write an OS definition and get an actual system running
<civodul>'guix system init' should come in handy for that
<tadni_>alezost: So will guix.el eventually/ideally be shipping with guix propper and/or emacs -- or will it just be in guix's repo or elpa?
*tadni_ plans to play with guix.el tomorrow.
<DusXMT>Guix, nor I seem to be able to download ; wget reports `Error in server greeting.'
<mark_weaver>tadni_: guix.el will soon be in the core guix repo
<tadni_>DusXMT: I just wget'd it and everything seems fine.
<tadni_>mark_weaver: Oh, neat!
<DusXMT>hmm. The server must not like my ISP then. `guix download' from another source worked...
<jxself>dusxmt: You could manually connect to there & see what sort of greeting you get.
<jxself>telnet is your friend. :)
<jxself>To the FTP control port.
<DusXMT>jxself: "The name server used by cannot convert your network address to a host name. Therefore, will not accept the connection."
<DusXMT>So it is an ISP issue, or at least I think
<jxself>dusxmt: Seems like a lack of reverse DNS.
<gr8>so, I've installed the GNU system using guix which worked mostly fine. but there is one minor problem: not all programs (and info manuals, etc) that reside in /gnu/store/ are detected. so, for example, the 'info' command. many others, too. how do I fix that? is there a way to rebuild my guix profile or sth?
<gr8>I need that answered before going to sleep :P (which is hopefully soon ...)
<DusXMT>gr8: you should be able to just do guix package -i
<DusXMT>that will add the package into your profile, building it if it isn't in the store yet
<mark_weaver>gr8: first go "guix pull" and then "guix package -i guix"
<DusXMT>do what mark said first, I almost forgot the old guix bug
<gr8>mark_weaver: so what does that do? re-install the guix program?
<DusXMT>gr8: update it, as the USB image installs an old version
<mark_weaver>gr8: it updates to the latest packages and installs guix 0.7
<gr8>sounds perfect
<DusXMT>hmm, does guix pull not update guix itself?
<mark_weaver>authorizing substitutes from is probably also a good idea
<mark_weaver>it updates most of the components of guix, but not all
<gr8>mark_weaver: is that something I need to do prior to the updating? I had the impression that substitues were already used during installation, as it sometimes said I should turn that *off* if something fails ...
<civodul>gr8: substitutes are used during installation, but not afterwards, by default
<mark_weaver>it depends on your operating-system config, but by default substitutes are disabled on the installed system, even if you had them enabled on the usb stick.
<DusXMT>if I'm not mistaking, if one does "guix pull" and then installs guix from the repository, doesn't he need to run "guix pull" again as it replaced the new package files with 0.7 ones?
<mark_weaver>no, installing a new guix does not overwrite the directory that 'guix pull' populates.
<gr8>DusXMT: hehe you're not that used to ports trees, right?
<DusXMT>gr8: I'm just new to Guix, that's all. I make assumptions as I go, and some of them, like this one, are wrong.
<gr8>DusXMT: today I heard the first time about guix, so, yeah, welcome :)
<mark_weaver>civodul: do you mind if I switch the core-updates jobset on hydra to build all packages (not just core), in preparation for a merge into master?
<jxself>Hopefully wildebeest has been included so as to help with such building.
<mark_weaver>I'm also open to other ideas about how to do this...
<mark_weaver>hmm, just saw this in a hydra aborted job log: guix offload: error: failed to load machine file '/usr/local/etc/guix/machines.scm': (unbound-variable #f "Unbound variable: ~S" (jxslef-i686) #f)
<mark_weaver>notice "jxslef-i686" looks like a typo
<mark_weaver>civodul: ^^
<gr8>btw, during installation, sometimes I got "server unresponsive" messages about hydra ... is there a known problem?
<jxself>Hydra? Yes. Hydra is, well, hydra...
<jxself>Often up and down all at the same time...
<jxself>More is needed.
<gr8>that could confuse beginners, as sometimes the download started, and got stuck, which resulted in NOTHING happening at all after then ... you should work on that ;)
<jxself>You think it's not? :)
<gr8>now at least that mystery is solved to me
<mark_weaver>if you don't mind building everything on your own machine, you can pass "--no-substitutes" to the commands that build packages.
<gr8>it's gonna be ok
<gr8>now that I know what is the problem
<gr8>concerning build reproducibility of binary packages (somewhere mentioned in the manual), see . I may post that on the ML in the next days
<mark_weaver>civodul: if you look at you'll see that all of the x86_64 build slots are stuck at 20 hours plus each.
<jxself>I think thiat topic was also covered at DebConf14.
<gr8>ok see you
*civodul looks
<civodul>that machine is just dying, grrr
<civodul>try "free", if you manage to log in at all...
<civodul>we need to get rid of "hydra"---the front end and the software
<civodul>i wonder which one is easiest
<mark_weaver>hydra is responding again
<civodul>yeah i've killed a bunch of processes, and progressively restarted them
<civodul>this is terrible
<civodul>if anyone would like to help, one thing we (may) need is a Hydra package
<civodul>i think the machine hosting that VM has become overloaded too
<civodul>good night/day!