<lfam>Or, send a new message to the bug report I linked above? <ilit>lfam: I can't send, I've no email address currently <lfam>Okay, I will send a follow-up comment <ilit>(yeah I had gmail, deleted it muahahaaaa) <ilit>needs a 'with comments containing' (?) <lfam>I sent the comment, it should show up on the web interface with 30 minutes <lfam>I don't understand your last message <ilit>ah sorry, the Search function for the above link <ilit>seems to have search only in subject but not in comments <lfam>I search it with my email client ;) <lfam>You can download an mbox of each bug report, so there's probably a way to download an mbox of all the Guix bug reports. Then, you could search that with an email client. <ilit>oh that's nice! I thought you had to be on the list to have collected them all until then <ng0>there's also ntp access to past bug reports via gmane. <lfam>ACTION Prepares the second QEMU update of the day <lfam>Does anyone want to try to build latest QEMU (2.5.1.1) with Guix and tell me if it fails in the test suite? <efraim>lfam: did you get qemu 2.5.1.1 to build in the end? <lfam>efraim: It fails sometimes <lfam>I'm checking if parallel-tests? makes a difference <lfam>efraim: I did the update <mark_weaver>efraim: how important is the libva update? the reason I ask is that it entails about 2000 rebuilds on hydra, far more than "guix refresh -l" suggests. <mark_weaver>mesa depends on (force libva-without-mesa), a dependency that 'guix refresh -l' fails to see. "guix refresh -l mesa" will give you a better idea of the dependencies <efraim>mark_weaver: oh my, i'll go ahead and revert it, I didn't see anywhere near the 2000 number <efraim>I was just running through video.scm and updating stuff, libva didn't show a lot of stuff <mark_weaver>yeah, I didn't think of libva as having many dependencies either <mark_weaver>it actually took me a while to figure out what was forcing so many rebuilds. <efraim>i figured it was safe when I saw mesa was an input <efraim>If I just push that to core-updates it'll get reverted when master gets merged in? <cbaines>As there is not an ISO available currently, I though I would give installing Guix in a VM (hosted on BigV) though using the self contained binary, running on a Debian Live ISO a go... I'm making it up as I go, but has anyone attempted something similar? <rekado>Does anyone else have problems connecting to git.sv.gnu.org? <rekado>On "git fetch origin" I get this error: "Connection to 208.118.235.72 timed out while waiting to read" <efraim>i fetch from git.savannah.gnu.org and only push to git.sv.gnu.org <efraim>i don't remember if it was a timeout issue or because I set up a password on my ssh key for savannah <rekado>same with git.savannah.gnu.org. Cannot fetch. <rekado>I'm using a password-protected ssh key as well. <rekado>maybe the firewall settings have been changed here. <rekado>but before talking to IT about this (which is going to take a long time), I'd be happy if someone could test this on their own machine. <efraim>git fetch isn't timing out for me <cbaines>I'm trying to run guix system init, but I'm getting an error. It seems to expect /gnu/store/...-base-initrd to exist, but it does not <cbaines>I'm trying to install from Debian, and not the USB installer, could this be why this is not working? <efraim>for guix offload, /etc/guix/machines.scm is systemwide, but offload machines (and the lsh key) are per-person? <cbaines>I'm still working on fixing the error I posted above, guix gc --verify seems to know that something is wrong, as it says that the path has disappeared <rekado>cbaines: how do you install Guix? <rekado>do you use the binary installation method? <cbaines>rekado, in a manor known only to myself. I've installed guix on a live Debian system, and am attempting to use that to install GuixSD to a attached disk. <cbaines>I am kindof following the manual, but its a mixture of the binary, and system installation methods <calher>cbaines: I don't see a point in using Debian when there's a perfectly good Guix installer image. <calher>But maybe you have your reasons. <cbaines>calher, I'm trying to install GuixSD on a Bytemark (BigV) VM <cbaines>(so I don't have a way of "connecting" the USB installer) <rekado>cbaines: so you unpacked the tarball, which gives you a pre-filled store. What did you do then? <rekado>(I don't know what a Bytemark VM is.) <joshuaBPman>Hello, I just installed gnu guix yesterday via the usb installer image! I've since run guix pull. I'm having issues with my mouse. When I launch gnome or xfce, my mouse only moves up and down. NOT left to right. To fix this, I've just been rebooting. Anyone else encounter an issue like this? <rekado>joshuaBPman: I haven't seen anything like this before. Is this a touchpad or a regular mouse? USB? <joshuaBPman>rekado: it's a regular touchpad. I've got a macbook 7,1. So it's pretty old. <cbaines>rekado, followed the binary installation procedure (moving it in to place, setting up the build service, ...) <cbaines>I have mounted the disk I'm trying to install on to as /mnt <cbaines>I then copied the store to /mnt/gnu/store, and bind mounted it back to /gnu/store <rekado>cbaines: this doesn't sound bad. What do you do to install the system then? Just "guix system init..."? <rekado>joshuaBPman: there are some people here who use GuixSD on a macbook. I don't know the specifics, though. <rekado>could be that you need to install an additional package for the touchpad. <cbaines>rekado, Yep, and that is when I get the error <rekado>ACTION is unhappy that git fetch isn't working on this network. Patches need to be pushed. <rekado>cbaines: the base-initrd is not in my store either (on the Guix+Fedora machine). <rekado>what does your operating system configuration file look like? <cbaines>One guess I had, is that this is some magical part of the USB installer... <rekado>the USB installer is just created with "guix system disk-image" <rekado>hmm, odd. Even the local SMTP relay complains about not being able to deliver my email to gnu.org :( <cbaines>How would I go about just running a derivation? <cbaines>I can see one in the store, which looks like it would produce the base-initrd that I am missing <phant0mas>rekado: if your local network admin blocks the git protocol try using https instead <rekado>it's actually ssh to git.sv.gnu.org that doesn't work. <cbaines>So, guix build can apparently build derivations, but running the command just prints the name of the thing I'm trying to get it to build, but its still not in the store...? <rekado>received my second delivery delay email :( <rekado>cannot send to guix-devel nor to debbugs.gnu.org. <rekado>cbaines: prints the name or the path? <rekado>maybe something to do with the bind mount...? <phant0mas>rekado: maybe there is a problem with gnu's servers <rekado>well, it seems that other people's emails are coming through just fine <rekado>and other people seem to be able to git fetch. <rekado>cbaines: did you restart the daemon after bind mounting? <phant0mas>rekado: then it's probably something wrong with your network <rekado>cbaines: I think you should try restarting the daemon. <cbaines>rekado, unfortunately that seems to have had no effect <wingo>phant0mas: (define (foo) "this is a docstring" "this is not a docstring") <wingo>(procedure-documentation foo) => "this is a docstring" <rekado>cbaines: has the "drv" file actually been written? <rekado>guix build will only print the path when the output has been generated and it can be found in the cache/store. <lumidragon>Hi everyone is the search-paths in package definitions only meant to used with path related variables? Or can that option be used to define any type of environment variable related to the package? <bavier>lumidragon: it can be used to define any related env var <lumidragon>okay cool, my next question where can I get more info on that topic? The manual seems a bit lacking. <ajgrf>lumidragon: digging through the source is your best bet at the moment, unfortunately. it's not as intimidating as it seems though <cbaines>I ran guix gc, and guix gc --verfiy=repair a few times, and that fixed the warnings, but the issue with the base-initrd has just come back again... <lfam>Did you read gnu/system/install.scm? That's what we pass to `guix system disk-image` to generate the USB installer. I read the log and understand you aren't using the installer, but reading that file may help you. <lfam>I'm struggling to write my first Shepherd service. The service is intended to save entropy to seed /dev/urandom on reboot. So, it needs to run after the file-systems are mounted, ensure a seed file exists, send the contents of the file to /dev/urandom, and then, at shutdown, write some data from /dev/urandom into the seed file. <cbaines>lfam, I have read that file, but I don't understand all of it fully. There may be something in there which does explain why things are not working for me though. I just tried with a different version of Guix, and I get the same problem (thing in the store does not exist, and building the derivation does nothing). <cbaines>This time though, its the grub-image.resized.png <lfam>cbaines: Yeah, suggesting you read that was a shot in the dark ;) I wish I had an answer for you <lfam>Oh, did you change anything, or do you get a different "missing file" for seemingly no reason? <cbaines>Yeah, instead of using guix as is in the root profile, I picked a different guix from the store <lfam>And you have to use this particular VM host? You can't use QEMU? I can tell you how to do it in QEMU ;) <cbaines>All I am really looking for is to setup a server running GuixSD, which is actually on the internet (and not in my house behind a NAT). <lfam>Yeah, I just looked up BigV. I didn't realize it was remote. <cbaines>I'm open to any suggestions of how to do that <lfam>This is a bit of a u-turn, but I remember hearing here that serveraptor.com was asking for a GuixSD VM image they could offer to their VPS customers <lfam>They don't seem to be offering GuixSD yet, however <lfam>Sorry if you've already answered this, but can you say how you are mounting the target? It's remote, right? <cbaines>I have mounted the disk /dev/vda1 on /mnt, the store is at /mnt/gnu/store and is bind mounted to /gnu/store <cbaines>Not sure what you mean by remote, but I am working from a Debian Jessie live CD <lfam>By remote I mean: Are you working on your physically local machine, with the target mounted over the network? <lfam>Or are you installing to some local volume that you will send to the remote host later on? <cbaines>No, I'm working on the target machine (just over SSH, with no network filesystem stuff) <lfam>Oh, that sounds like it should work <cbaines>The issue with building the derivations sounds like the part that may be going wrong <cbaines>As in, for both of the missing paths I have encountered, I can see the derivation to create it, and build it, and guix build output's the path I am expecting, but there is still nothing there in the store... <lfam>Can you link to the BigV documentation? I can't figure out what technology it uses? <lfam>It sounds like they use some custom software to provide the storage over the network. I would ask them about it <cbaines>Without understanding the situation, I find it hard to believe that the problem I am having could be at that level? <lfam>I don't really understand it either, but the problem you're having hasn't manifested for me when installing to non-networked storage, nor have I heard of it happening to anyone else. <lfam>Since this one aspect is very different from all the successful installations I've done, my instinct is to look there <lfam>You could try setting up a test with your own hardware, where you provide the target device over some network storage protocol, just to see if it works. <lfam>I think it's important to get this working <lfam>system takes a command, while system* takes a list of strings that are basically (command arg1 arg2 ...) <lfam>I couldn't get the redirection to work with system* <lfam>Perhaps it should be done in Guile, but doing it in sh worked when I implemented that core logic outside of Shepherd, as a Guile script <efraim>start does string-append, do you need to return #t to lambda? <lfam>efraim: I don't know, do I ? This is why I'm asking for help ;) <lfam>I didn't find any existing services that don't take an argument. That seems to be the error described in the backtrace (also on that page) <lfam>As you might guess, I still don't really understand how to put services together. I tried to understand how other services work and adapt them <lfam>Also, since this service is only really useful at boot and shutdown, I wonder if the start action could be completely moved into the activation? ***vasile_ is now known as vasile
<joshuaBPMan>hello, I'm not bashing guix here. I'm just having some issues with using gnome. What is the best window manager or desktop environment for guix right now? in terms of stability? <davexunit>joshuaBPMan: xfce worked pretty well for me. <davexunit>gnome has been stable for me as of late, just missing some nice-to-haves <joshuaBPMan>hmmm. davexunit: I'm running into gnome not being able to open programs. <davexunit>but our gnome support is quite a bit newer than our xfce support <joshuaBPMan>like I can only open emacs in the terminal...that might be because gnome is booting in wayland? <joshuaBPMan>hmmmm. ok. I'm really wanting to help out guix at some point. There's just quite a few issues I need to address before I can use it as my main system. <joshuaBPMan>again. I think guix is awesome. Not bashing the devs here. <davexunit>joshuaBPMan: if you gather more info about the problem and post on help-guix someone may be able to help you <lfam>What do you mean by "not being able to open programs"? I've been able to open several programs in GNOME <davexunit>I know you're not bashing. things are rough. that's just how it is when you make a distro from scratch. :) <joshuaBPMan>haha. True that! It still is pretty impressive what guix is pulling off! <joshuaBPMan>and it looks like I'm the only one at #help-guix. :( <davexunit>joshuaBPMan: sorry, that was a mailing list. <lfam>I didn't even realize there was a #help-guix <davexunit>lfam: there's not, but freenode lets you join any channel you want and make new ones. <lfam>I think this channel is the help channel :) <davexunit>the mailing list is good for stuff like this that may benefit from someone who isn't on IRC all the time to read it. <lfam>Yeah, the mailing list is definitely the right choice for problems that can't be solved right away <davexunit>my biggest desktop annoyance at the moment is that icecat doesn't have a .desktop file <joshuaBPMan>Also I've installed libreoffice, but I can't seem to open it. <lfam>That's the name they chose for their executable <joshuaBPMan>running soffice in a terminal said "no protocal specified" <davexunit>joshuaBPMan: what you type into the terminal has nothing to do with your desktop environment <lfam>Weird, but I've never tried to open it that way. I open it through dmenu <joshuaBPMan>davexunit: I think I knew that what I type in a terminal doesn't affect my desktop environment. <joshuaBPMan>daveunit: if it's an X error. Should I try to go about fixing it in the X files. OR should I try to change the configure.scm. <davexunit>sounds like something is up with your X server <joshuaBPMan>I can run a guix pull again. See if that helps. I just got guix substitues from hydra working today. <lfam>We don't have a libreoffice substitute available? That's annoying... <lfam>I was going to try it in GNOME but it will take all day to build <joshuaBPMan>lfam: don't we have soffice? at least that is what it is called but guix does have libreoffice. <lfam>I meant a substitute for the libreoffice package, which includes the soffice binary. <davexunit>lfam: I think there's some explanation on the mailing list about that <lfam>I just ssh-ed into my GuixSD GNOME computer to install libreoffice so I could try running it, but it wants to build libreoffice from source. That machine will probably need ~12 hours to do that <lfam>Although, it seems like libreoffice depends on *everything*. When I need to update stuff, it's almost always in `guix refresh -l`. <lfam>joshuaBPMan: Yes, the price we pay for ... I'm not sure what. I don't use that sort of program much. <joshuaBPMan>also how often should I be running guix pull? once a week? once a month? <lfam>You should do `guix pull` as often as you want to get the latest package definitions. There are security updates very often... <joshuaBPMan>wait is gnu guix a rolling distribution like arch and parabola? <lfam>Yes, we distribute the master branch of our Git repo <lfam>`guix pull` downloads a snapshot of HEAD, builds it, and deploys it <davexunit>that's really the only sustainable way to go these days. too many security issues too often. <davexunit>I used to be scared of rolling release after breaking arch too many times <lfam>People have asked for a stable branch that only gets bug fixes and security updates. Not a bad idea if people wanted to do the work, but so far nobody has stepped up. <joshuaBPMan>which is cool. That's why I was with arch for so long and then went to parabola. <davexunit>since upgrades are transactional, you can always rollback if an upgrade goes poorly. <lfam>That's the nice thing about Guix: the trade-off between security and stability is less extreme than "traditional" packaging systems <lfam>Debian certainly doesn't! <davexunit>either the update succeeds 100% or nothing happens. <davexunit>never an in-between state because something broke half-way through. <davexunit>joshuaBPMan: it certainly cannot do it in an atomic way. <joshuaBPMan>I didn't know what atomic meant 'til now. Thanks davexunit. <davexunit>joshuaBPMan: that rolling back either works or does nothing. <davexunit>this applies to both user profiles and full system configurations <davexunit>for example, when our gnome support was really really new I upgraded to it only to find that closing my laptop lid and opening it caused an infinite suspend loop. it would immediately re-suspend as soon as I opened the lid, rendering it unusable. <davexunit>so, I rebooted and chose the previous generation of my system configuration from the GRUB boot menu <lfam>Stages of GuixSD GNOME support: really really new -> really new -> new (current) <lfam>Btw, do you have a "log out" button in GNOME? I'm still killing my gnome-session to get out <joshuaBPMan>lfam and davexunit, do either of you mind if I ask you if you contribute to gnu guix? <davexunit>joshuaBPMan: I've written a ton of packages and a few core features. <joshuaBPMan>ok. I'm thinking about maybe adding filezilla as a package. I don't know how difficule it might be to do. <lfam>Huh, I wonder what's wrong with my setup? <davexunit>joshuaBPMan: often it depends on how fickle the build system is for the software you are packaging <davexunit>software built using gnu autotools is generally easy to package. <lfam>As in, do they use a standard build system or was their software so special that they had to write their own? <lfam>Seems like a nice addition to the distribution, either way :) <joshuaBPMan>I actually haven't looked into how filezilla is made. <joshuaBPMan>I just use it a lot for my web work. I didn't see it in the distribution. <lfam>I have to go AFK for a little bit. If somebody wants to do the libarchive update, great! I think we need to graft an upstream commit onto our package. If not, I'll do it later today. <lfam>It's a nasty bug, so we should fix it quickly ***will is now known as Guest36253
***Guest36253 is now known as taken
<lfam>Can anyone suggest some packages to test the patched libarchive against? <taken>Hi. I just tried installing the guix 0.10.0 binary, but at the end of the install instructions where it finally says to run the guix command, it segfaults for me. I'm using Arch Linux. Any suggestions? <lfam>taken: Exactly which command segfaults? <taken>guix, in any variation I've tried. eg. `guix package -i hello` <lfam>taken: Does `guix --version` segfault? <lfam>And, can you tell me about your system? Kernel version and filesystem? <taken>Yep. --version, --help, anything I've tried segfauldts. Do I need to set some environment variable for it to load a libc from the store? <taken>uname -a gives me: Linux conspirator 4.5.1-1-ARCH #1 SMP PREEMPT Thu Apr 14 19:19:32 CEST 2016 x86_64 GNU/Linux <lfam>There are some helper variables you can set (described in the installation instructions), but you shouldn't get segfaults if they are unset <lfam>taken: Can you prefix the command with 'strace -f -o /tmp/guix.log' and put the log (or at least the end of it) on paste.lisp.org? <lfam>Btw, you didn't try to change any files in /gnu/store, right? <lfam>I wonder, is the daemon running normally? (Segfaults are not a consequence of the daemon not running, just curious) <taken>Well I ran with strace, but a glance at the output made me remember that I have LD_LIBRARY_PATH set to an extended search path. If I unset LD_LIBRARY_PATH then it seems to work. But it shouldn't be hitting anything in the path previous to the default locations. <taken>the daemon seems to be running fine according to systemd. <taken>Maybe I'm missing something from the default search path that is assumed when LD_LIBRARY_PATH is empty. Do you know offhand if the default includes anything more than `/usr/local/lib:/usr/lib:/lib`? <lfam>Right, Guix should *never* use executables that are not in /usr <lfam>Guix should *never* use executables that are in /usr <lfam>Guix and the packages it installs should only refer to executables in /gnu/store <lfam>Without knowing why you decided to export a special LD_LIBRARY_PATH, I'm not sure exactly what you should do. But I recommend not exporting it :) <taken>Bleh... I'm hoping guix is the solution to the original problem that made me start exporting it... <lfam>Guix is excellent at letting you install user-facing programs that depend on different versions of library foo <taken>Speaking of which, is it easy to install guix as a normal user? IE, let's say I work at a company that doesn't give me root access to my workstation (which runs an old RHEL type OS), but lets me run anything I want to put in my home directory. Does guix work well for single-user home directory based package management as well as being a system package manager? <lfam>It becomes very easy to inspect and change the dependency graph of any package <lfam>Unfortunately, you need privileges to run the daemon. It's possible to run it without root, but then it won't build packages in isolation, which is a crucial part of treating package-building as a pure function, which is the why Guix (and Nix) are so good. <lfam>But, if you can get root to run the daemon, then Guix *is* a per-user package manager. It's only on GuixSD that you are able to do system-level package management. <bavier>taken: I'm in a similar position at $dayjob. theoretically it's possible to run an unprivileged daemon, but things may break <taken>In practice if you run all builds as the same user do they muck with each other? I mean, I know in theory they can, but it seems like the build scripts would have to be adversarially written to do so. <lfam>taken: You'd end up with issues like you just had, where Guix looks in /usr <lfam>That workaround is very involved however... <bavier>you lose the build isolation, and the builds might behave unexpectedly <lfam>Consider that most upstream build systems look in /usr by default, and then you realize that pretty much everything will look for dependencies in the wrong place <taken>lfam: [about looknig in /usr] Why is that? Wouldn't a home directory install have something like a $PREFIX/gnu/store or something? <lfam>The linux kernel features that enforce the isolation require privileges <lfam>Specifically, I think the issue is that unprivileged users cannot create chroots <taken>Ok, well I'll read up on the proposed solution. I actually don't work at that job anymore, but it got me thinking a lot more about package management, since I basically hand a whole distribution built from source in my home dir since all of the OS packages were ancient. <lfam>The proposed solution is more like an inspiration for a solution. Also, I believe that person has significantly changed how they do things since that article was posted. <taken>lfam: but chroots are only for the build itself, right? Aside from doing the build in a chroot or not, the final executable should be set up to look in where ever the store is rather than just searching through /usr, right? <lfam>Right, but if the build process is not in a chroot, the wrong library (from /usr) may be linked at build time <lfam>The chroots contain *only* the dependencies you specify in the package definition. <taken>lfam: oh... I see now. That makes sense. <lfam>Nix: A Safe and Policy-Free System for Software Deployment <roelj>I've created a patch to run guix-daemon without super-user privileges. It involved disabling chrooting, because we cannot do that as a user, and disabling chowning the store directory, which you cannot do either as a user. <lfam>roelj: Does it address the issue of maintaining a pure build environment? <roelj>So, not only in theory can you do that, in practice you can too. But indeed, it isn't what we want to achieve with Guix -- fully isolated environments. <roelj>lfam: No, as chrooting is disabled. <taken>lfam: One of my constant gripes with Unix (which I love, though I want something better) is that there is no way to have something like sub-users to arbitrary depths. So we either get coarse permissions at a user level or we go a full Android and have a single-user OS again... [disclaimer: I know Android has multiple users, but I see them as somewhat of a hack] <lfam>So, your user ('taken') could have sub-roles that are isolated from each other? <roelj>lfam: Do you have any idea to get a pure build environment as a user without su privileges? I am willing to try and implement it.. <lfam>Some of the more experience Guix people might have some ideas, though <roelj>I would really love to hear them. <taken>lfam: I've worked on some experiments about how to do stuff like that, but the closest thing in industrial strength to the sort of always being able to further isolate child processes is the various sandboxing features of Racket. <lfam>taken: This isn't really what you described, but Qubes OS does some interesting things regarding isolation. Of course, virtualization is basically made of holes, but the idea is still interesting. <lfam>Do you have a link to the Racket features? I would be interested to read about them <bavier>roelj: does the guix-daemon option --disable-chroot not do what you want already? <roelj>bavier: No, you have to disable chown calls as well, otherwise the daemon stops when it cannot chown the build directory in /tmp. <roelj>bavier: But for disabling chrooting, --disable-chroot will do the job :) <bavier>roelj: ok, I haven't tried unprivileged builds in a while, so something might have changed in the meantime <roelj>bavier: Have you succeeded in bootstrapping Guix with a daemon running as a normal user? <taken>lfam: offhand I can recommend the paper "Revenge of the Son of the Lisp Machine" by Flatt, Findler, and Felleisen to describe some of it, but basically Racket has a bunch of security stuff at the language level so that you can parameterize different security-related things for any given function. Eg. you can nest different programs and each one can limit access that its children have to resources like the network, the filesystem, memory <bavier>roelj: IIRC I got as far as perl <lfam>taken: Thanks, I wish you'd shown up a few hours ago, before I went to the print shop :) I would print this out <taken>One of my motivations for doing crap like having a modified LD_LIBRARY_PATH and building things in my home directory is that sometimes I want to use the very bleeding edge of some packages. Is that easy to do with guix? From what I've seen of available packages things are pretty old. Is there anything in guix like a stability channel [unstable, stable, etc] or some such, or any plans for that? Is it easy to use the latest version of <lfam>taken: I think your message was cut off <taken>Basically, I was asking 1: is there [or are there plans for] something like in debian where you can get newer or more stable packages? <lfam>But anyways, we don't have any channels yet. When you update your Guix installation (with `guix pull`), you download a snapshot of HEAD of our Git master branch, build it, and deploy it.