IRC channel logs


back to list of logs

<rekado>patches 11 to 15 of are still looking for a kind reviewer. The other patches have already been dealt with.
<civodul>rekado: i'll look at it tomorrow if nobody beats me at it
<civodul>until then, good night/day!
***grantixx is now known as grantixxx
*grantixxx looks to see if 'loadkeys' is packaged.
<grantixxx>Ah, it is -- just not many keymap files.
<sir123>What is the way to build software on a Guix system? I have downloaded the source code for a package and am trying to build the documentation of it. I need libxft. However, the configure for the package I am trying to compile, ratpoison, complains it cannot find xft in its PKG_CHECK_MODULES(XFT, xft,,noop=noop) line. I have installed the package through the Guix package manager, but I get this error. What should I do?
<sir123>That is, I have installed the libxft package.
<sir123>When I try to build the source code for ratpoison so I can get the documentation, it complained about libxft, even though it was installed through the Guix package system. What should I do?
<sir123>Okay, after some research, I found to use the guix package --no-substitutes option. I would just like to know if there is a way to control the make process of the package.
<sir123>i.e make it make a different target.
<sir123>Is ther a way to force the guix package system build a certain make target?
<sir123>*Is there a way to force the 'guix package' system to build a certain make target?
<sir123>Can somebosy give me some help on how to build a package's doc folder? Building from a downloaded source doesn't work since it doesn't understand the gnu/store system. So, how can I force the 'guix package' system to make the doc folder and not the package itself?
<sir123>Where does 'guix package --no-substitutes' store its source?
<taylanub>sir123: the channel isn't always active, sorry about that :)
<sir123>that's okay, I know the system is still growing :)
<taylanub>sir123: I don't think guix build processes store anything other than the "outputs" they generate. you might want to patch the package recipe to have an extra "doc" output or so.
<iyzsong>sir123: I think you mean 'guix build -S ratpoison' to get the source. Of course, it's in /gnu/store.
<sir123>That makes perfect sense. Sorry, still trying to learn this system.
<taylanub>ooh, didn't know of -S
<sir123>me neither. Is it documented in the info?
<taylanub>it's in the Info node for 'guix build' as well as 'guix build --help' it seems
<sir123>Okay, I just saw it myself. Helps to read all the documentation, I suppose :)
<sir123>I can't help but feel that the guix invoke is counter-intuitive.
<sir123>There is no other package manager that behaves like it.
<taylanub>it's probably intuitive once one knows the concepts on which it builds. Nix/Guix are indeed unique.
*taylanub still doesn't even know what a "derivation" is. should read the whole manual some time.
<sir123>It's definitely not for beginners. Maybe a guide on the main site would help explain the concepts? People like me (non-experts in the GNU OS) would not think of looking on info for the information.
<sir123>Or maybe when the system has more users? Something to think about, anyway.
<sir123>Either way, pulling closer to GNU alienates the common GNU/Linux user, e.g. Ubuntu user. That could be a good or a bad thing, depending on your target users.
<iyzsong>Yes, the only document we have now is 'info guix', maybe we need some wiki and faq pages :-)
<sir123>I read on the mailing list a dedicated Guix web site is being built.
<taylanub>hm, I don't think so
<sir123>I think I'm wrong on that one also.
<taylanub>well I don't know, opinions differ on how much GNU GSD itself should be branded
<sir123>Should we be working on a wiki? Seems like something Ludo himself would need to approve. And yes, it depends on the way we wish to portray GNU GSD.
<taylanub>I had a strong opinion that it should not be branded at all, and serve as a technical codeword only, but some disagree and I'm open to change my mind after all
<taylanub>Wiki are inherently user-managed and I don't see a reason anyone would object anyway, but of course if it'll be served on or some official Guix domain then you'll have to ask them
<sir123>I'm not sure. GNU GSD is a different beast from the other GNU/Linux distros, in that it seems to want to bring back a complete GNU system. This brings back the philosophical questions of how we want the system to not be cannibalized by 'open source', the way most GNU/Linux distros have ruined the free software philosophy.,
<sir123>I.E. is this the free software system Richard Stallman intended in 1983, and if so, how do we treat it?
<sir123>I think that's the root of the issues on branding. Correct me if you disagree.
<taylanub>correct, although systems like Trisquel, gNewSense, Parabola, dyne:bolic etc. are also GNU systems, and RMS doesn't want to sanction any of them as the most important. so the question is how to distinguish
<taylanub>I thought it would be best to stick to GNU branding and have these distros appear only as "models" so to say (e.g. Astra and Vectra of Opel, to make a car analogy), without their own logos or web pages, but maybe it's also fine to brand them individually as long as they make a very strong point on their homepage etc. about them being *GNU Systems* and not "Linux distros"
<sir123>True, but Guix is the first FSF-approved system to boot to "Welcome to the GNU system", weakening Linux to a package in an operating system. Plus, Guix has built its repo from scratch, unlike the other systems that have liberated branded distros. This is a first in the free software community.
<sir123>Guix presents a new opportunity to repair the damage done by the open source movement, by focusing on GNU itself.
<sir123>Well, GSD.
<sir123>I have no issues with gNewSense, Trisquel, Parabola, etc. but Guix is something different. We need to treat it differently.
<civodul>Hello Guix!
<taylanub>hi :)
<sir123>hello :)
<sir123>Of course, what I say above is my opinion. Ludo determines where this system goes.
<taylanub>sir123: indeed Guix is more independent than the others, and general-purpose (contrast to e.g. dyne:bolic), but RMS hasn't agreed to that point so far AFAIK
<sir123>GSD could be a very powerful piece in liberating our systems from those built in the name of 'open source'. That is why I say this.
<sir123>Guix has been constructed by free software hackers, not corporations (think Canonical, SUSE, Red Hat). We have a system that is a free software distribution created entirely by those who value freedom. This is a serious opportunity.
<sir123>This drives straight back to the philosophy of free software. We have a system with no reliance on 'open source' developers. We can define this according to our rules, the free software rules.
<sir123>Thus, we must be careful in our building of Guix. We need to understand that Guix can be the system without 'open source', and we must plan our moves carefully. What are your ideas on this?
<rekado_>re wiki: in my experiences wikis have the potential to mislead users unless they are exceptionally well edited, like a good manual.
<rekado_>I don't see an advantage over a well-edited manual. If something is deemed important enough to deserve mention in a wiki, I think it would also fit into a manual.
<rekado_>The manual is also available on the web, so it doesn't need to be exclusive of those who do not yet know how to use an Info reader.
<rekado_>(although I think that the Info reader in Emacs is super awesome(TM) and people really should be using it rather than web-searching everything.)
<civodul>i agree with rekado_
<sir123>This comes back to how we want to develop our user base: do we want users who understand the GNU system (including info), or the user who switches from an established distro. The user who wants to switch but doesn't understand GNU would expect some instruction online.
<civodul>if documentation is missing, let's add it to the manual
<civodul>there is an on-line copy of the manual
<rekado_>I do find that the manual probably needs a "tutorial"-like section, something that doesn't go into too much depth at once but that can be followed all the way through to get things working.
<sir123>Certainly. But the average distro-hopper wouldn't think of using info. They think of wikis. Whether you interpret that as a good thing or a bad thing is up to you.
<rekado_>I found myself skipping through many different sections (that I see more as references than introductions) when I got started with guix.
<rekado_>sir123: is the online copy of the manual not accessible enough for those expecting wikis?
<rekado_>(personally, I find many wikis to be hard to use to learn something in a structured, guided manner.)
<sir123>For instance: You come from the Windows world. You discover Linux, install Ubuntu, then find the FSF. You want to use Guix because it is entirely free software. You get stuck since there is no clear instructions on how to use the system. What do you do? You leave to something easier. Is that good or bad for the community?
<sir123>That is the question behind the wiki.
<civodul>what matters is to have good documentation
<rekado_>sir123: right now the Guix homepage at has a section "Documentation" that points to the manual
<sir123>The average distro hopper looks at info and thinks 'holy crap, this is a reference manual'. However, you can't understand the functions of Guix without reading the manual. It's a matter of strategy of who you want to target: well-established GNU users or new users.
<sir123>You also have to learn info, which usually means learning Emacs, which most users (not hackers) don't want to learn. They want a system.
<rekado_>The manual certainly can be improved to give a little more guidance to newcomers by adding a short tutorial-style section (with pictures :) !).
<rekado_>sir123: to read the online manual you do not need to know anything about info.
<sir123>Think of the average user. You may not have to use info, true, but you have to understand the structure. You do this by reading the info documentation.
<sir123>Moreover, what I'm suggesting is a quick-start. I have no issues with the manual, I truly don't, but users don't want to read that to use the sytem.
<sir123>*start to use the system
<sir123>GNU by itself is not very user-friendly. It takes time to learn how to use it. The question is: do we want to remedy this by implementing easier documentation in a place the user expects?
<sir123>That being said, it is easy to find the documentation, as rekardo_ pointed out. So can we improve it is the question.
<rekado_>improve it: yes, always. It might help us to hear some common issues when starting to use Guix, so that we know what to focus on in writing a quick-start guide.
<rekado_>As soon as I've packaged a few more audio plugins I'm soon using GNU GSD on an old Thinkpad for use with a synthesizer; I'm sure I'll run into a couple of issues then that could be addressed in a starter guide.
<rekado_>(So far I've only used Guix as a package manager alongside other distributions.)
<sir123>I have recently switched to GSD, after many hassles with getting it to install. I had to use Arch Linux documentation to understand how to create the partitions. I suggest we practice installing on a VM strictly obeying the current install process as suggested by the documentation. Maybe we could compare notes?
<sir123>Try to keep in mind the understanding of a common GNU/Linux distro hopper. Imagine the only part of GNU you may be aware of is the GNU toolchain. How would you try to install the system?
<rekado_>heh, I've installed it on the thinkpad already following only the manual and I did not have problems with partitioning as I just reused the partitions that were already there.
<civodul>sir123: i agree with you, but so far, as you noticed, the doc just suggests that the user is expected to know how to partition etc. already ;-)
<civodul>in the long term, the model for our doc should be Debian's installation manual IMO
<civodul>something like that
<rekado_>are there any text-mode installers we can adopt to simplify the initial setup (especially partitioning) somewhat?
<sir123>I know. The instructions expect someone with a knowledge of GNU/Linux. I obtained this information myself after installing Parabola a while ago.
<rekado_>or are there reasons to avoid installers altogether? (e.g. for educational reasons)
<sir123>Of course, this could be rectified with an install script.
<civodul>rekado_: depends on what the installer does
<civodul>having a "visual" partitioning tool is good, IMO
<civodul>having something that completely hides the config is not
<sir123>I have no problems with forcing the user to install herself. This is the approach taken by Arch GNU/Linux. It scares off newbies, but that's the point: get experienced users.
<sir123>However, that means this IRC will be full of people saying things like 'what's fdisk'?
<sir123>This comes back to the direction we want GSD to take.
<rekado_>(I learned most by playing with Arch. This also helped me much later when preparing for RHCE exams.)
<sir123>An installer is a good idea; would we need a new GNU project for that?
<civodul>it should be developed closely with the rest of Guix
<civodul>i wonder if alezost would have ideas on having an Emacs-based UI
<sir123>Good idea. Maybe someone could contact Ludo with this idea?
<rekado_>civodul == Ludo
<sir123>Depe(holy crap i'm so embarrased)
<sir123>Okay, was not aware of that. Civodul, you approve?
<sir123>Sorry, have to head off now. Am looking forward to a discussion on this. It's a privelege to help on this.
<civodul>sorry, do i approve what?
<rigelk>hello #guix
<rigelk>is there a way to edit the documentation ? -> to fix some errors found in it through my GSD install
<taylanub>licenses frustrate me :( ECL has a contrib/ directory FULL of different licenses
<civodul>rigelk: yes, the source of the manual is doc/guix.texi
<civodul>you can submit a patch for that
<taylanub>is the Expat license still itself if a no-advertisement clause has been added?
<taylanub>ah, comes out that's the X11 license -_-
<davexunit>hmm, we're surprisingly not as far behind arch linux in how many packages we have. they have ~5000 in their core repos (excluding AUR)
<davexunit>I would have expected a greater number.
<taylanub>Debian has 40k, correct? that's pretty impressive, but I guess most are quite obscure
<taylanub>also inflated by separation of -bin, -dev, -doc, etc.
<davexunit>we're not gonna get anywhere close to debian for a long time
<taylanub>for what purposes are "bsd-style" and "x11-style" licenses? both are non-copyleft, and bsd-4 also has the no-advertisement clause like x11...
<taylanub>I mean, what is their distinction? should I use "bsd-style" only if there's no no-advertisement clause? (meaning bsd-4 would fall under "x11-style" if it weren't simply bsd-4)
<davexunit>bsd and x11 have different license text
<taylanub>but what's the key difference making something bsd-style or x11-style? hm, BSD mandates reproducing the license text in binary distributions. x11 doesn't seem to explicitly do so. is that it?
<taylanub>some license guide would be neat :\\
<taylanub>(specifically for guix packagers that is)
<taylanub>another question is, how much does a license have to match the original to justify declaring it's that one? e.g. the following seems similar in form and effectively equivalent to ISC but uses different wording:
<taylanub>ECL is truly a license hell
<taylanub>hm, ISC and Expat seem effectively equivalent as well, to me at least, so I guess I can't go with that; no idea where to draw the line
<rekado_>civodul: yesterday mark_weaver suggested that it may be problematic to place $localstatedir under /gnu/ and mount it read-only on machines to give them read-only access to user profiles.
<rekado_>originally I only wanted workstations and cluster nodes to mount the shared /gnu/store, but then I noticed that the .guix-profile links point to $localstatedir.
<rekado_>so to give users access to their profile symlink forest they need to have read access to $localstatedir.
<rekado_>Is this a problem as long as only one machine (the one running the guix-daemon and the only one to have write access on /gnu/store) writes to $localstatedir?
<rekado_>none of the workstations or cluster nodes will have guix installed, but all will be able to mount the /gnu tree read-only.
<mark_weaver>taylanub: a license has to have identical wording to justify calling it that one. "seems similar in form and effectively equivalent" is not enough.
<civodul>rekado_: you don't want to/cannot run guix-daemon on all the nodes?
<civodul>that would be best
<rekado_>civodul: sadly, I cannot.
<civodul>hmm, really? :-)
<rekado_>it's not only nodes, though. I also want to use guix on users' (unmanaged) workstations where I cannot feasibly install software.
<civodul>i think it's OK to have --localstatedir=/gnu/var for example
<civodul>but to use guix on a node, that node must have guix-daemon running
<rekado_>what does this mean: "use guix on a node"?
<rekado_>if I only want to be able to access profiles / software on the nodes in a read-only fashion?
<civodul>i mean, if you want to be able to run "guix package -i foo" on a machine, that machine must have guix-daemon running
<rekado_>then I only need read access to /gnu, no?
<civodul>right, that works
<rekado_>yes, of course.
<civodul>but it's really read-only
<rekado_>yes. It's a bit limiting, but at this point we can only really do the common sysadmin thing: "managing" other users' software profiles.
<rekado_>we would have one machine to build software and update profiles; that's the only one with write access to /gnu.
<mark_weaver>rekado_: so the only benefit to exporting localstatedir to the nodes is to give easy access to the profile symlinks?
<civodul>ok, that's a good start anyway :-)
<rekado_>mark_weaver: correct.
<civodul>sadly we did not go further at work with that attempt to run Guix on the local cluster
<civodul>we should resume work on it
<mark_weaver>rekado_: will there be more than one profile to export to the nodes/users ?
<rekado_>mark_weaver: yes, every user will have their own profile.
<mark_weaver>well, maybe it's worth it then.
<mark_weaver>and if civodul doesn't see a problem with it. I guess I can't think of a problem.
<rekado_>thanks for validating the idea.
<civodul>well, maybe we'll discover problems later ;-)
<civodul>but yeah, i think it should be fine
<mark_weaver>just make sure it's all read-only :)
<civodul>rekado_: what's the sysadmin reason for not running guix-daemon everywhere?
<mark_weaver>it's too bad that this is undermining our "empowering users" idea though.
<rekado_>civodul: I guess it's traditional sysadmin resistance to yielding control.
<rekado_>we have more than one IT dept.
<civodul>ok, nothing technical or security-related?
<civodul>we could make the daemon accessible over TCP if that helps for such use cases
<rekado_>central IT has the final say on what happens with the new cluster and they have been very protective of their control (i.e. not even letting us install software to standard locations etc)
<rekado_>getting them to grant me space and a mount point already took me some effort.
<jxself>Heh. I just had a mental image from The Lord Of The Rings trilogy. Golem and his precious.
<civodul>rekado_: any idea what they'd say about the TCP bridge?
<rekado_>civodul: TCP access to the daemon sounds like a good idea.
<rekado_>what they are most concerned about is having "non-standard software" (i.e. software not available through CentOS core repos) be running on all nodes.
<rekado_>we had to repackage quite a few applications just because of that.
<civodul>do they use that Bright Cluster thing?
<civodul>it's terrible
<civodul>the tool basically provides a half-baked overlay distro
<rekado_>I don't think so. It's standard CentOS with SGE and a lot of "non-standard" scripting ...\\
<civodul>at FOSDEM there was a question about environment modules during the Nix talk
<civodul>and i mentioned them during mine, suggesting how inflexible it is ;-)
<rekado_>it's somewhat understandable, though, because the old cluster (which is ours to maintain now) is a bit of a mess thanks to willy-nilly installation of applications, directly compiled on the nodes, etc.
<civodul>so i got another question on that
<civodul>yeah, i see
<civodul>the argument would be that Guix is non-intrusive
<civodul>there's /gnu with "random" software, and that does not interfere with the rest
<mark_weaver>right, outside of the 'guix system' command, guix doesn't modify anything outside of /gnu, /var/guix, and /var/log/guix
<rekado_>*that* plus the benefits with building software once and running it on workstations (Fedora, Ubuntu, Debian, etc) and cluster (CentOS) alike probably convinced them to let me play with it.
<mark_weaver>(assuming here that you don't run 'make install' and that localstatedir is /var)
<mark_weaver>and as you pointed out, you can change that to "doesn't modify anything outside of /gnu" if you make /gnu/var the localstatevar
<rekado_>actually, our guix-builder host is not part of the cluster and under our (not central IT's) management, so as far as they are concerned the cluster nodes only got a new mount. That's a very cheap, agreeable change.
<rekado_>of course, writing to an NFS share isn't very fast, but it's okay for a mostly read-only share.
<mark_weaver>I suppose you could make --prefix=/gnu and then even with 'make install' everything would be neatly kept in /gnu
<mark_weaver>it's too bad that users with write access only to their home directory cannot make use of substitutes.
<mark_weaver>to address that problem, I wonder if we should consider changing /gnu/store to a longer name, long enough that it could be grafted into /home/<username>/<??> for some username of typical length.
<mark_weaver>civodul: ^^
<mark_weaver>this could help liberate more users :)
<civodul>mark_weaver: i'm not sure that could be made to work generally
<mark_weaver>the last <??> part could be a single character if needed. and since I guess usernames are usually <=8 characters, that would mean /home/12345678/g == 16 characters
<mark_weaver>civodul: what problem do you see?
<civodul>it would have to graft to the exact same length
<civodul>otherwise that'll break most binary formats
<mark_weaver>civodul: right, that's why /gnu/store would have to be changed to a longer name.
<civodul>yes, but then user names would all have to be of the same length
<mark_weaver>civodul: no
<mark_weaver>because the last directory name could be anything.
<civodul>oh you mean there'd be a "placeholder"?
<mark_weaver>so the user would have to choose the last directory name to be of the right length, such that /home/<username>/?? would be exactly 16 characters.
<mark_weaver>(or whatever length we decide)
<civodul>i see
<civodul>but i think it's preferable to find a sysadmin-compatible way to provide guix functionality :-)
<civodul>maybe the TCP bridge, maybe some other hack
<mark_weaver>well, of course it's preferable to convince sysadmins to give up some control, where possible.
<mark_weaver>there are sysadmins who won't agree.
<civodul>actually, all we need is people wearing ties, going to them and selling the thing :-)
<civodul>what rekado_ is doing is important because it can set a precedent
<mark_weaver>to me, liberating users from sysadmins doesn't mean forcing them to beg and get permission from their sysadmins. to me, that's tyranny.
<mark_weaver>s/forcing them/leaving them no choice but/
<mark_weaver>I agree that rekado_ should keep working on the sysadmins from the social angle.
<mark_weaver>but if we have the technical means to provide substitutes for users with uncooperative sysadmins, I wonder why not take it?
<rekado_>I'll do that once I can demonstrate that it's all working and there's nothing to fear.
<rekado_>the way it usually works here is that users want something and we install it anyway ... so far there have been mostly technical reasons when we refuse to install something (e.g. multiple versions required and no way to offer both, or proprietary software that cannot easily be installed at all).
<rekado_>so I have hopes that eventually we can leave the users to themselves when it comes to installing software, relegating sysadmins to the task of running guix gc once in a while.
*rekado_ leaves
<mark_weaver>rekado_: thanks for working on it! :)
<taylanub>mark_weaver: ok. then I probably have to use bsd-style or x11-style. how do I decide between the two?
*civodul wonders what happend to 0install
<rigelk>is there an established way to configure system-wide proxy setting for GSD ?
<civodul>rigelk: not really
<mark_weaver>rigelk: btw, we call it GuixSD now :)
<mark_weaver>(the name GSD is deprecated)
<mark_weaver>taylanub: I don't know, these are fuzzy concepts, and we should make them less fuzzy.
<mark_weaver>taylanub: if the license is not almost identical to BSD or X11 (expat) licenses, then probably you could use 'fsf-free' instead.
<rigelk>okay. I’ll need to setup a DNS server then : university requires us to be aware of its proxies to access to internet.
<mark_weaver>rigelk: I think it's just a matter of setting environment variables, right?
<rigelk>that’s a matter of whether guix considers them and how, mark_weaver ;)
<rigelk>if it is the common http_proxy env var, then i’ll do it :)
<mark_weaver>most programs consult http_proxy and https_proxy
<mark_weaver>including guix itself
<mark_weaver>(if using guile 2.0.11)
<mark_weaver>(if guix is built with an older guile, then it won't use proxies)
<mark_weaver>although ftp is another matter.
<rigelk>hum. won’t ftp_proxy work as well ?
<mark_weaver>rigelk: some programs probably honor it, but I don't know how widely supported it is, and guix doesn't support it yet.
<mark_weaver>afaik, guix has no support for ftp proxying currently.
<mark_weaver>wget is one program that supports ftp_proxy
<mark_weaver>rigelk: I see that curl supports the environment variables http_proxy, HTTPS_PROXY and FTP_PROXY
<mark_weaver>and ALL_PROXY
<mark_weaver>so it's a bit of a mess, I'm afraid.
<mark_weaver>(not just in Guix)
<rigelk>i’m having a « waiting for partition 'label' to appear… » error on GuixSD boot
<rigelk>i can’t seem to find a way to avoid that error. tried device path first, then uuid and now label. still the same detection problem.
<rigelk>btw mark_weaver, is there a way to setup env vars in the GuixSD config.scm ?
<mark_weaver>rigelk: when you specified the device path, did you change the title field to 'device ?
<mark_weaver>in the example config, we have (title 'label) which causes it to interpret the device field as a label.
<mark_weaver>i would try (title 'device) and (device "/dev/sdXn")
<mark_weaver>one user recently had trouble specifying the label on a system that used GPT, and fixed it by using raw device names.
<mark_weaver>rigelk: regarding environment variables: the OS configuration has a 'skeletons' field that can be used to specify the default dot file contents for new users.
<mark_weaver>the field is documented in section 6.2.2 of the manual ('operating-system' Reference), but more docs would probably be helpful.
<rigelk>mark_weaver, i had no title field when trying the path method, since it is the default behaviour
<sir123>Hi, I'm trying to get xorg to start up with xfce4, but changing .xinitrc or .xsessions doesn't work. I tried killing xorg myself (sudo deco stop xorg-server), and running startxfce4, at which point it came up with: exec: xinit: not found. I presume this is xorg looking for xinit under /bin (which it won't find because Guix packaging changes that whole design). I'm thinking I should do something with deco, but I'm not sure what. Any
<mark_weaver>rigelk: the default value of that field is (default-skeletons) defined in gnu/system/shadow.scm
<mark_weaver>sir123: welcome back!
<rigelk>as for the skeleton way, i had seen it and read it. If it is the default way, then I’ll try it. Anyhow, it might be just more convenient to have a DNS wrapper after all ^^'
<sir123>Sorry to interrupt your work, mark_weaver.
<mark_weaver>sir123: no need to apologize. I think that's a bug in the xfce4 package. let me see about a workaround.
<mark_weaver>I guess when slim (our current X login manager) runs .xsession, xinit is already in PATH, which is why it works for me. but really, startxfce4 should not depend on that.
<mark_weaver>for now, you could work around the problem by "guix package -i xinit"
<mark_weaver>(to allow you to run startxfce4 manually)
<mark_weaver>but also, I'm curious what went wrong with .xsessions
<mark_weaver>oh, but it's called ".xsession", not ".xsessions"
<mark_weaver>make sure .xsession is executable (chmod +x .xsession), and that the first line contains "#!/bin/sh"
<mark_weaver>sir123: ^^
<sir123>Yes, I forget the exact line :)
<mark_weaver>iyzsong: is there an easier way to set up an xfce session from slim than manually creating .xsession ?
<sir123>I'm reloading the .xsession file I had before deleting it. It crashed xorg when it tried to run.
<mark_weaver>iyzsong: since you were the one who improved the session support in our xorg-service, I'm surprised not to see an xfce session yet :)
<mark_weaver>should we add it, or is there a complication?
<mark_weaver>rigelk: yeah, we need a nicer way to add a few custom environment variables
<rigelk>pfff. missing initrd at the time the key boots :') does it mean the key is corrupted ?
<rigelk>mark_weaver, a hint on how one could implement that (hence where ;) ? Just being curious !
*mark_weaver goes afk for a bit
<mark_weaver>rigelk: what "key" are you referring to?
<rigelk>sorry for the delay. I’m using a usb key to install GSD on a machine.
<rigelk>I have used `dd if=gsd-usb-install-0.8.1.x86_64 of=/dev/sdX` where sdX is my usb key
<sir123>mark_weaver: following your advice, (installing xinit) leads to: xinit: unable to run server "X": No such file or directory. It gives its list of possible server names (Xorg, Xvfb, etc.) Then: xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error
<mark_weaver>sir123: rather than going down this road, I think that it would be better to get .xsession working
<sir123>I imagine so.
<mark_weaver>rigelk: hmm, missing initrd? might be an issue with your BIOS not supporting USB drives that are like hard drives. if you have a working GRUB on that machine, I can tell you how to boot the USB installer from it.
<rigelk>well… I have already had successful boot attempts (and install attempts even they where not working after a reboot) on that machine
<rigelk>with the same usb key
<mark_weaver>hmm, dunno!
<rigelk>^^' might be a slight change in the BIOS, if you think so
<mark_weaver>most USB installers are like CDROM drives, with an MSDOS partition and ISOLINUX.
<mark_weaver>ours is like a little hard disk with GRUB
<mark_weaver>some BIOSes can't deal
<mark_weaver>but if it worked before on that same machine, it seems odd that it wouldn't work now.
<mark_weaver>I'm afraid that I have to go offline soon for a few hours
<rigelk>thanks for all these infos mark_weaver
<mark_weaver>sir123: what happens if you create a file ".xsession" in your home directory with the lines "#!/bin/sh" and "exec startxfce4", run "chmod +x .xsession" to make it executable, and then "deco start xorg-server" and try logging in via the X login manager?
<sir123>Works like a charm.
<sir123>How you guys work this out is beyond me.
<rigelk>same here
<sir123>rigelk: Hope you get a working system soon.
<sir123>Getting my own install to work took me two days and lots of help.
<rigelk>sir123, i went through hardware (RAM incompatibility and slot parity) issues first. took me two days already. Having a 10y old BIOS doesn’t help too
<rigelk>so i’m only beggining :p
<rigelk>thanks though sir123 :)
<mark_weaver>sir123: nice!
<sir123>I'm fairly fortunate, I guess. My PC is lucky enough to work flawlessly with free software except for the Bluetooth, which I can live without.
<mark_weaver>sir123: after you've logged into the GUI, does "setxkbmap -layout us -option ctrl:nocaps" work and make "caps lock" into a "control" key?
<mark_weaver>sir123: it's possible that your bluetooth device is usable with free software, but guix doesn't yet support bluetooth.
<espectalll123>¡Hola, gente! How's it going?
<sir123>mark_weaver: setxkbmap works no, no fully free distro has ever supported my bluetooth card. Linux-libre rips out the blob. Still a good thing, though.
<mark_weaver>hi espectalll123 !
<espectalll123>Hi!!! :3
<mark_weaver>sir123: okay, if that setkbdmap command works, I suggest inserting it between the two other lines in your .xsession, to make it the default.
<mark_weaver>and to get in the habit of using that key as the control key when using emacs.
<mark_weaver>(just a suggestion :)
<sir123>Good idea. I have to get ready for another day of school soon. Year 12 sucks.
<mark_weaver>okay, good luck!
<espectalll123>Have a quick question. I'm gonna write an article about Guix and would like to have an .svg file for its logo (I know, I'm the laziest thing on the Earth, meow). Do you know where may I find it?
<mark_weaver>rigelk: do you have GRUB on that machine already?
<sir123>Good question. THere's stuff in the devel mailing list.
<espectalll123>It doesn't seems to come package at the source code...
<sir123>That's because there is some controversy over the way Guix should be branded.
<mark_weaver>rigelk: okay, then if you boot into grub with the USB installer plugged in, and get to the GRUB command prompt, I can help you boot into the USB installer from GRUB.
<sir123>Some people want it, others don't.
<rigelk>I’m in it. usb plugged in mark_weaver
<espectalll123>Oh wait, no problem, found the logotype
<mark_weaver>rigelk: okay, give me a minute
<espectalll123>Excuse me for asking silly things
<sir123>No problems. This IRC is for Guix, right? :)
<mark_weaver>rigelk: try typing: ls (usb0,1)/grub
<mark_weaver>espectalll123: no worries
<mark_weaver>rigelk: does it show a listing?
<espectalll123>Okay ·_·'
<rigelk>output : error: disk `usb0,1' not found. maybe i should plug it in *before* grub start ?
<rigelk>retrying anyway.
<mark_weaver>rigelk: what happens if you type: "ls (" and then hit TAB ?
<mark_weaver>you might also need to load a grub module.
<mark_weaver>we can work through it
<mark_weaver>(depends on the details of how that grub was configured, and it's not our grub)
<rigelk>oh, crap. I don’t understand that BIOS.
*rigelk has rebooted and now boots on the usb key
<mark_weaver>huh. it might be sensitive to when the USB drive was plugged in, or the USB drive might be a bit flaky, or the electrical contacts dirty, or something.
<mark_weaver>or a flaky BIOS :)
<rigelk>sorry mark_weaver, but my computer behaves like pavlov’s dog :p
<rigelk>it seems to understand commands only after a few times x)
<rigelk>okay. I’m trying your option mark_weaver : using the explicit `title 'device` in the config.scm
<mark_weaver>rigelk: if you had (title 'label) before, that almost certainly would have made it look for a partition labeled "/dev/sd??", which obviously wouldn't work.
<rigelk>mark_weaver, no i hadn’t the title field. i used the device field with the path directly.
<rigelk>wait. isn’t mkfs.ext* -L <label> what a label is ? then it should be labeled "<label>", right ?
<rekado>espectalll123: you can get all artwork sources here:
<mark_weaver>espectalll123: easier to remember, just click on the guix logo on
<mark_weaver>it'll bring you to a page with the logo sources and copyright info
<mark_weaver>rigelk: right, that *should* work, and it works for many of us, but sir123 had problems with that, possibly because he uses GPT partitions
<mark_weaver>if you're having trouble, maybe start with the raw device and then try to improve it later.
<mark_weaver>(once you have one working system, you can safely fool around secure in the knowledge that you can always boot into an older working version of the system)
<mark_weaver>(since our grub menu lets you boot into old versions of the system easily)
*mark_weaver goes afk for a few hours
<civodul>rigelk: what's the status now?
<espectalll123>rekado: Thank you! :D
<rigelk>civodul, I went a few times through the install process, but am still having failing reboots
<civodul>rigelk: so 'guix system init' succeeded, but then the newly installed system fails to boot, is that right?
<civodul>kernel panic?
<rigelk>no, it’s « waiting for partition 'label' to appear… »
*rigelk is making an install at the moment, maybe the error shall differ
<civodul>mark_weaver: regarding our earlier discussion on non-root installs, i found that 0install, which supports it, requires relocatable packages
<civodul>rigelk: after it fails, you should get a REPL prompt, right?
<civodul>from there we can do some quick debugging
<civodul>something like:
<civodul>,use (gnu build file-systems)
<civodul>(find-partition-by-label "whatever-the-label-is")
<rigelk>civodul, have you ever had a look at that page : ? A friend of mine recommended it (Geoffroy Couprie).
<civodul>yes i read a bit about it before
<rigelk>civodul, yes, i get a REPL prompt (even though i’m not used to using it ^^')
<civodul>rigelk: can you type what i wrote above?
<rigelk>only once the install completes ;)
*rigelk is waiting for `guix system init …` to finish
<rigelk>btw civodul, i’m wondering how i could use a spare disk (how to mount it so that it is best used) as I have no raid 0 controller on one of my machines…
<rigelk>oh. sounds like we’re gonna need mdadm one day :
<rigelk>civodul, I encountered a grub error :
<rigelk>error : ELF header smaller than expected. Entering rescue mode. grub rescue prompt follows.
<civodul>that's a very different issue
<civodul>could we get back to the other one? ;-)
<civodul>rigelk: could you post the OS config?
<rigelk>yup. just wait a sec
<rigelk>civodul, here is my OS config
<civodul>(apart from port 2222 for ssh...)
<civodul>you're installing from 0.8.1, right?
<rigelk>yes, but i think the 2222 port-thing is to have a non-conventionnal ssh access, hence less risky to expose
<rigelk>do you think i should use a --no-grub option civodul ?
<civodul>no, because you want it to install GRUB
<[1]cnb>could I use guix for another platform, for example netbsd, how do i create a custom repo for this platform?
<civodul>[1]cnb: the distro that comes with Guix relies on the GNU libc and tools
<civodul>it makes it difficult to target NetBSD or similar
<[1]cnb>civodil ok guix is a linux centric pkg manager then
<civodul>GNU centric, yes
<taylanub>ECL seems to expect that 'make check' is ran after installing it. can I reorder the phases?
<civodul>good night/day!