IRC channel 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?

<cocomberrr>Um...

<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>Um...

<cocomberrr>What's SLiM?

<bavier`>the default X session uses the ratpoison window manager

<cocomberrr>Yes

<cocomberrr>ratthing true.

<cocomberrr>:)

<bavier`>;)

<bavier`>C-t !

<bavier`>opens a temp shell

<cocomberrr>Ctrl+t ?

<bavier`>"exclamation"

<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>Oh.

<cocomberrr>:p

<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!

<bavier`>np

<cocomberrr>Ctrl-Alt-F2 and guix package -i xterm I guess or alike.

<bavier`>yes

<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 https://www.gnu.org/software/guix/screenshots/0.8/windowmaker+icecat+inkscape.png

<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 https://www.gnu.org/software/guix/manual/html_node/X-Window.html#X-Window

<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 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18698#20

<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.

<mark_weaver>s/pkacage/package/

<cocomberrr>:p

<cocomberrr>OK thanks! I'll try that.

<mark_weaver>np!

<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

<cocomberrr>OK

<cocomberrr>Great.

<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.

<mark_weaver>okay

<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>ok

<Sleep_Walker>I have it in different branch :(

<Sleep_Walker>I'll add

<Sleep_Walker>pushed

<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.

<civodul>ok

<rekado>I'd be happy if someone could take a look at this simple patch: https://lists.gnu.org/archive/html/guix-devel/2015-03/msg00105.html

<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>*writes

<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: gitorious.org is shutting down -> https://gitorious.org/

<taylanub>ouch

<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 https://kallithea-scm.org/ 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`: https://about.gitlab.com/2015/03/03/gitlab-acquires-gitorious/ 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 https://kallithea-scm.org/repos/ 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)

<civodul>uh

<rekado_>:( I had *almost* finished moving my repos from github to gitorious.

<civodul>bah

<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>gitlab.com 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: http://jxself.org/goodbye-gitorious.shtml may be helpful.

<jxself>Gogs seems interesting. tmm here on freenode is who is running notabug.org.

<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> https://notabug.org/explore

<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> https://notabug.org/org/xiph

<jxself>The xiph people put stuff there? Interesting.

<davexunit>I wonder how easy it is to install

<jxself> http://gogs.io/docs/installation

<davexunit>I really do not want to use whatever language specific package manager they probably insist on using

<jxself> http://gogs.io/docs/installation/install_from_source.html 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 gitlab.com 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>oof

<davexunit>:(

<davexunit>yeah

<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 ;-)

<sirgazil>:)

<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?

<bavier`>neon

<civodul>you mean 'git'?

<civodul>oh :-)

<bavier`>which incidentally isn't used in subversion 1.8

<civodul>really?

<civodul>maybe it should be moved to web.scm then

<civodul>it could make friends with the JSON libs

<bavier`>;)

<bavier`>I've given up on the perl upgrade for the time being, because of that

<bavier`>couldn't get serf to build

<civodul>serf?

<bavier`>the http lib subversion 1.8 uses; it's an apache code

<civodul>oh

<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

<civodul>true

<alxsp>greetings

<civodul>hi!

<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 setup.py file? this Recode library uses a setup.py 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>ok

<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 https://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities

<civodul>davexunit: the "high-level forms" for pipelines, redirections, etc.

<civodul>maybe

<alxsp>civodul: the debian project has now deterministic reproducible builds, it's done by recreating an environment and using virtual machines, https://gitian.org/ 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 hydra.gnu.org, 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?

IRC channel logs

2015-03-04.log