<civodul>rekado: i'll look at it tomorrow if nobody beats me at it ***grantixx is now known as grantixxx
*grantixxx looks to see if 'loadkeys' is packaged. <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. <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. <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 gnu.org 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>I have no issues with gNewSense, Trisquel, Parabola, etc. but Guix is something different. We need to treat it differently. <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.) <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 <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>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 <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? <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. <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 <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) <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) <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>(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: http://sprunge.us/iFjG <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? <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? <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>sadly we did not go further at work with that attempt to run Guix on the local cluster <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>and if civodul doesn't see a problem with it. I guess I can't think of a problem. <civodul>well, maybe we'll discover problems later ;-) <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. <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>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>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. <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 <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 <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. <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. <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>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. <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 ? <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>(if guix is built with an older guile, then it won't use proxies) <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>rigelk: I see that curl supports the environment variables http_proxy, HTTPS_PROXY and FTP_PROXY <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 <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>but also, I'm curious what went wrong with .xsessions <mark_weaver>make sure .xsession is executable (chmod +x .xsession), and that the first line contains "#!/bin/sh" <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>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 <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 <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>^^' 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>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>How you guys work this out is beyond me. <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 <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. <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>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. <sir123>Good idea. I have to get ready for another day of school soon. Year 12 sucks. <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? <sir123>Good question. THere's stuff in the devel mailing list. <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 <sir123>No problems. This IRC is for Guix, right? :) <rigelk>output : error: disk `usb0,1' not found. maybe i should plug it in *before* grub start ? <mark_weaver>rigelk: what happens if you type: "ls (" and then hit TAB ? <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. <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 ? <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 <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? <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>(find-partition-by-label "whatever-the-label-is") <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>civodul, I encountered a grub error : <rigelk>error : ELF header smaller than expected. Entering rescue mode. grub rescue prompt follows. <civodul>could we get back to the other one? ;-) <civodul>rigelk: could you post the OS config? <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 <taylanub>ECL seems to expect that 'make check' is ran after installing it. can I reorder the phases?