IRC channel logs


back to list of logs

<cocomberrr>Hi all. I've installed Guix a minute ago along with a few packages etc. I'm ready to test it now as I have a working system. I'm failing to understand though how I can use the X session and open a window or something.
<cocomberrr>Anyone that can help please?
<bavier`>cocomberrr: did you install the standalone system?
<bavier`>i.e. GuixSD?
<bavier`>or are you using Guix on top of another system?
<cocomberrr>I've burned the iso to a usb and then installed to a hard disk.
<cocomberrr>Used dd, not burned :p
<bavier`>cocomberrr: ok, great!
<cocomberrr>Ctrl+Alt+F7 though... how can I open an X window or alike? Like xterm?
<bavier`>I'm assuming you've logged into the system with SLiM?
<cocomberrr>What's SLiM?
<bavier`>the default X session uses the ratpoison window manager
<cocomberrr>ratthing true.
<bavier`>C-t !
<bavier`>opens a temp shell
<cocomberrr>Ctrl+t ?
<cocomberrr>Ctrl+t is not opening anything.
<bavier`>followed by the exclamation mark
<cocomberrr>I can't see the mouse cursor too but dmesg says mouse is OK.
<cocomberrr>One sec to check
<bavier`>otherwise, if you want a terminal for a while (you may even need to install xterm before using it in ratpoison), you can type "exit" as the username at the login prompt
<bavier`>and that will drop you out of the login manager into a tty
<cocomberrr>OK C-t and ! worked, thanks!
<cocomberrr>Ctrl-Alt-F2 and guix package -i xterm I guess or alike.
<cocomberrr>This is perfect. It works and I can see the cursor now :p
<bavier`>ratpoison is pretty nice after getting used to it.
<cocomberrr>Do I have to install a desktop in order to get that
<cocomberrr>like windows and a bar and stuff
<cocomberrr>I know gnome support is not ready yet.
<bavier`>choose the WindowMaker session at the login screen
<cocomberrr>Oh, is that a clickable thing that I missed?
<cocomberrr>Suppose so...
<bavier`>It's a keyboard press. I forget which at the moment, as I always use the default
<cocomberrr>OK I'll try to find it.
<cocomberrr>Thanks for the help, really!
<bavier`>glad you're enjoying the system so far!
<bavier`>feel free to stop by and ask questions whenever.
<cocomberrr>It's amazing. Such a nice idea to have a system like this.
<cocomberrr>Can't find the keyboard press but I found this
<cocomberrr>Maybe I can set WindowMaker as default in a configuration.
<bavier`>yes, that should work too
<bavier`>I don't have a GuixSD system on hand to check the keypress
<cocomberrr>No worries at all.
<bavier`>I need to go afk. Happy Hacking, cocomberrr!
<cocomberrr>Thanks!! :)
<cocomberrr>Hm, I'm failing to find a way to start windowmaker (I've installed it earlier) or make it the default session on slim. Any ideas guys and gals?
<cocomberrr>Couldn't find that in the documentation. The documentation though, in most cases is really good.
<mark_weaver>it might help to install 'windowmaker' into your system-wide profile, by adding it to 'packages' in your OS config.
<mark_weaver>ideally this wouldn't be needed, but there's an open ticket on this, see
<mark_weaver>if you'd prefer XFCE, I can help you set that up. I've been using that on GuixSD lately.
<cocomberrr>Right, not entirely sure of what you mean as I'm new to Guix. I just guix package installed it :) Is it easy to install XFCE?
<mark_weaver>yes, just install xfce with 'guix pkacage -i xfce' and then create ~/.xsession containing "#!/bin/sh\\n exec startxfce4", making sure it is executable.
<cocomberrr>OK thanks! I'll try that.
<cocomberrr>if i just do startxfce4 will it work? After the installation I mean.
<mark_weaver>I run it within slim. did you add (slim-service) to the 'services' section of your OS config?
<mark_weaver>I haven't tried launching it outside of slim.
<mark_weaver>if you saw the options for ratpoison and windowmaker, I guess you've already got slim running.
<cocomberrr>Slim is running yes.
<mark_weaver>after you put that .xsession file in place, you should be able to just log in.
<mark_weaver>and it should start xfce
<mark_weaver>iyzsong: would adding '%xfce-session-type' to services/xorg.scm be as trivial as I suspect?
<cocomberrr>Thanks for the help bavier` and mark_weaver. Good night to all!
<mark_weaver>good night!
<mark_weaver>(did it work?)
<cocomberrr>Installing now... :)
<cocomberrr>Have to turn this PC off though.
<iyzsong>mark_weaver: yes, it's trivial to add, but we need add 'xfce' to packages field too.
<iyzsong>Sleep_Walker: Hi, for enlightenment.scm, the module should be '(gnu packages enlightenment)', and it missing harfbuzz, could you fix it?
<Sleep_Walker>iyzsong: yes
<Sleep_Walker>iyzsong: I'll fix the name, but harfbuzz is present
<Sleep_Walker>or I don't get what you mean
<iyzsong>Sleep_Walker: oh, '#:use-module (gnu packages gtk)' should be added to get harfbuzz, sorry for confusion
<Sleep_Walker>I have it in different branch :(
<Sleep_Walker>I'll add
<Sleep_Walker>damn, there is more
<Sleep_Walker>gstreamer was missing as well
<Sleep_Walker>it builds now correctly, but I need to revalidate my local branch against that
<civodul>Hello Guix!
<iyzsong>Hi, civodul. I want to add qt to octave, but add (gnu packages qt) to maths.scm cause both qt and octave become unknow ;-(
<iyzsong>should I move octave to its own file?
<civodul>hi iyzsong
<civodul>yes, why not moving it to its own file
<civodul>OTOH it would be good to know why it breaks
<rekado_>successfully split the icedtea6 package into three outputs. The "jre" output is only 54 MB, the "jdk" output is about 400 MB. Much nicer than 3.2 GB.
<rekado_>In my original package I naively assumed everything in the build directory was required, but actually IcedTea builds three distributions with considerable overlap.
<rekado_>I'm recompiling R now to see if it still works, then submit a patch to split the icedtea6 package outputs.
<civodul>rekado_: yay for IcedTea, you're brave! ;-)
<civodul>so R depends on IcedTea?
<civodul>i didn't realize that
<rekado_>R has Java bindings. Without a JDK these bindings are not built.
<rekado>I'd be happy if someone could take a look at this simple patch:
<rekado>I'd like to package up fdupes (find duplicate files). What module would be best suited for this?
<civodul>rekado: maybe admin.scm?
<civodul>so, i think it's time to merge core-updates!
<civodul>seems like it's mostly built for x86_64
<taylanub>I wonder what happens when two users run 'guix package -i foo' concurrently when foo isn't in the store yet? (kinda afraid to try)
<bavier`>taylanub: I believe rekado_ tried that once and things didn't work out
<mark_weaver>taylanub: nothing bad happens, but effectively one of the commands becomes a no-op.
<civodul>taylanub: yeah it just works
<civodul>what rekado_ reported is when the *same* user does that concurrently
<mark_weaver>basically, each 'guix package' command builds a new profile based on the current one.
<taylanub>bavier`: mark_weaver: I think you have the one reported by rekado in mind?
<mark_weaver>oh, right, there's only an issue when the same user (more precisely, same *profile*) is modified concurrently.
<taylanub>ok, neat
<mark_weaver>with different profiles, there's no issue.
<taylanub>does one just wait for the other substituter to finish or so?
<mark_weaver>I don't know that there's a problem having two substituters running.
<mark_weaver>at worst, the same thing might be downloaded twice.
<taylanub>and when they try to write to /gnu/store/...?
<mark_weaver>the daemon manages the store, and it seems to be robust in the face of concurrency.
<mark_weaver>I could imagine two substituters asking the daemon to add the same outputs to the store, similar to guix download.
<mark_weaver>nothing write to the store but the daemon
<mark_weaver>actually, I suspect that the daemon will ensure that the substituter is only run once per derivation.
<mark_weaver>like if you try to build the same derivation twice, one will end up waiting on a lock.
*mark_weaver goes afk
<taylanub>neat, thanks
<civodul>taylanub: the two talk to the daemon, and the daemon knows exactly what's in store, what's being substituted/built, etc.
<civodul>bad news: is shutting down ->
<bavier`>hopefully the transition plan goes smoothly
<taylanub>ugh, and GitLab is not nearly as freedom respecting, is it? maybe that's why they were talking about in #emacs a while ago
<civodul>i was happy with it, and somehow, this .com thing doesn't sound as trustworthy to me
<civodul>non-copyleft code also
<taylanub>but then kallithea doesn't seem to have a central server like GitHub and Gitorious do; it's only the software from what I got
<civodul>bavier`: says one just has to click on "import"
<civodul>of course, we are their product
<bavier`>civodul: I wasn't aware of the non-copyleft code of gitlab
<civodul>seeing bkuhn as the "owner" of the repos at is quite confidence-inspiring :-)
<taylanub>"<kiilerix> IMO, the AGPL exception introduced in GPLv3 is a immoral loophole" but other than that, kallithea seems highly freedom-respecting.
<taylanub>(that's from when I asked them whether there was plans to move to AGPL)
<rekado_>:( I had *almost* finished moving my repos from github to gitorious.
<civodul>well all this sucks
<rekado_>maybe this provides enough motivation to improve savane/savannah?
<davexunit>I just don't like kallithea as much as gitlab :/
<davexunit>I don't know where to move my repos
<davexunit> runs gitlab EE, the non-free version
<davexunit>so that's not an option
<davexunit>I don't really have the time/patience for it, but I was considering starting up a gitlab CE instance for gitorious refugees.
<jxself>davexunit: may be helpful.
<jxself>Gogs seems interesting. tmm here on freenode is who is running
<jxself>The web interface also as a nice "import" feature where you plugin the HTTP address of an existing git repo and import it.
<davexunit>jxself: wow gog looks exactly like github
<davexunit>thought I was looking at github search results
<jxself>Yeah, Gogs seems rather nice.
<davexunit>it's in uncanny valley territory for me
<jxself>The xiph people put stuff there? Interesting.
<davexunit>I wonder how easy it is to install
<davexunit>I really do not want to use whatever language specific package manager they probably insist on using
<jxself> How's that?
<jxself>Need Go, not surprisingly.
<davexunit>I think we need to package the go compiler, still.
<davexunit>ah, it uses "gopm"
<davexunit>whatever, I guess I'd have to deal with that with any of the other options.
<civodul>davexunit: ooh, didn't know runs the non-free version, good to know
<civodul>unfortunately, it's clear that many clicked on the "import" button without noticing
<civodul>GnuTLS did
<davexunit>it's not obvious
<DusXMT>Interesting fact: Did you know that GnuTLS (the maintained version) isn't a GNU project anymore? The maintainers disbanded the GNU version. (this isn't to cause frowns, just an interesting fact)
<sirgazil>civodul: I haven't make any progress on the website implementation because I'm trying to get a computer to install GuixSD. (I'd like to make things for GuixSD using GuixSD :)
<davexunit>a noble goal :)
<civodul>indeed, that's the right approach sirgazil ;-)
<civodul>if it happens to be too painful, do let us know of course ;-)
<jxself>So it can be made more painful. :)
*davexunit adds bug to 'guix system'
*taylanub wonders why web.scm has packages that are just JSON libraries...
<taylanub>and YAML
<civodul>that's because Names Are Hard
<civodul>this is a lesson we've learned in this project
<davexunit>taylanub: json is typically used for web applications
<davexunit>it's one of those "it sort of makes sense" situations
<bavier`>we also have http clients in version-control.scm ;)
<civodul>do we?
<civodul>you mean 'git'?
<civodul>oh :-)
<bavier`>which incidentally isn't used in subversion 1.8
<civodul>maybe it should be moved to web.scm then
<civodul>it could make friends with the JSON libs
<bavier`>I've given up on the perl upgrade for the time being, because of that
<bavier`>couldn't get serf to build
<bavier`>the http lib subversion 1.8 uses; it's an apache code
<civodul>what does this have to do with Perl?
<bavier`>subversion 1.7 doesn't like perl 5.20
<bavier`>so we'd also need to upgrade subversion (and perhaps others)
<civodul>oh but we could keep both Perls in the meantime
<civodul>other packages might have similar requirements anyway
<bavier`>yes, I guess we could.
<bavier`>I somehow always forget that option...
*davexunit needs to upgrade ruby to 2.2.1 tonight
<davexunit>but now... time to go home!
<bavier`>I'd hate to start dealing with module incompatibilities with more than one perl around though
<alxsp>i see Guix is listed as a project for GSoC.
<alxsp>the ideas listed are already taken?
<taylanub>does anyone know how to tame a file? this Recode library uses a file to compile a program during its test suite, but it fails with "ld: cannot find -lrecode"
<alxsp>i like scheme and i have played with guix before, have not touched Guix SD yet
<alxsp>i find the guix-on-hurd repository on github, idk if it's related to gsoc projects or not
<ijp>that reminds me, I should start writing up my gsoc proposal for guile
<alxsp>i have the idea of my own but it might not fit the project's plan quite well.
<civodul>ijp: you should!
<civodul>alxsp: only a couple of people have shown interest so far
<civodul>ph4nt0mas is a likely candidate to the Hurd port
<rekado>I sometimes wish I could disable all tests when building packages on my machine instead of downloading substitutes. Some tests are really slow.
<rekado>I'm compiling a lot of stuff right now because I rebased my patches onto latest master and binaries aren't yet available for some packages.
<civodul>are you on x86_64?
<rekado>i686 on my laptop.
<civodul>we should get a subset of guile-scsh in our backend
<davexunit>what would that do?
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, daviid says: i found this link
<civodul>davexunit: the "high-level forms" for pipelines, redirections, etc.
<alxsp>civodul: the debian project has now deterministic reproducible builds, it's done by recreating an environment and using virtual machines, would be an example of such build system, it uses ruby as scripting tool and vagrant/virtualbox as VM. It would be nice to have (possible voluntary) build binary packages in guix.
<civodul>alxsp: we have a build farm at, and users can also build on their own machines
<civodul>the build environment is isolated, which facilitates reproducibility
<alxsp>civodul: the guile implementation of a deployment manager (such as chef) would be needed for that. I guess some of such functional are already present in guix.
<alxsp>civodul: is it byte-to-byte identical? would it be secure to install a package build this way from untrusted source?
<civodul>alxsp: it's not always bit-identical, for the same reasons that the Debian people identified: some packages do not build determinstically
<civodul>timestamps, use of the PRNG, etc.
<civodul>at this point we haven't tried to compare binaries on a large scale
<civodul>davexunit: BTW, what about your idea for container support?
<alxsp>timestamps are easy to reproduce, PRNG might be reproduced I guess it will cause security problems
<davexunit>civodul: oh, I'm sorry. I forgot about that email.
<davexunit>I'll write up something.
<davexunit>I get so many emails...
<davexunit>civodul: I'm reading over the email thread about containers from awhile back. do you think adding the necessary container RPCs to the guix-daemon would be the best way to go?
<davexunit>or should we shoot for writing a separate daemon written in pure Guile that can do it?
<alxsp>civodul: this debian people states that 80% of packages do build (with their patches) determenistically. So basically it doesn't matter who has built as far as the checksum matches.
<alxsp>so it would be possible to use as farm untrusted machinery (such as cloud services).
<davexunit>civodul: I guess I don't know if I should propose *how* containers would be implemented (at a high level), or to leave that up to whoever works on it.
<alxsp>civodul: is this idea legit and worth further time investment?
<pepperleekpotato>Hi guys. Is the guix-devel mailing list just for development-related discussions -only- or also for user help?