<lfam>Whether packages get upgraded quickly or not really depends on whether or not anyone is paying attention to those particular packages. <taken>and 2: is it easy to get a newer version of just a couple of packages within Guix, eg. by tweaking the recipe to get the sources for the newest version rather than whatever is in the main catalog? <lfam>It's easy to create a package variant with a different version, and use that privately. Also very easy to send an update patch to guix-devel@gnu.org and let us merge it :) <lfam>Anything in particular we should update? <taken>lfam: I noted a couple things, but hopefully after I start using Guix I'll learn how to modify the recipes and I'll just patch them myself. Do you generally try to stay as current as possible on packages? <lfam>It imports 'gnu packages w3m', inherits the w3m variable, and then changes the name, version, and source. <lfam>The module path (used in define-module) must relate to the filesystem path, so I keep that file in 'leo/packages/w3m-debian.scm' <lfam>And I make it available to my `guix` command by exporting GUIX_PACKAGE_PATH=~/pkgs <lfam>Btw, ~/pkgs is arbitrary. I should have clarified that the module path is relative to the GUIX_PACKAGE_PATH <taken>Oh, also, how does guix deal with things like packages that in other systems have a script to generate a key pair or something? <lfam>Can you be more specific? <taken>For instance, I install something like ssh-server. It needs a key pair to authenticate, so most package systems will run a script to generate a key pair on first installation. Do you count on the user to generate keys before running it? <lfam>Building and installing sshd is handling separately from initiliazing the use of it. We do that sort of thing in the "service" layer. Our init system / service manager Shepherd does that stuff. We have a service for the Lsh SSH implementation, but not yet for OpenSSH (help wanted!) <lfam>The other thing is that what counts as "installation" is different here. We install software into /gnu/store when it is built. What users consider installation (making it available for use) is a further step, which usually consists of making a bunch of symlinks to put the software in the user's profile. <lfam>I guess that lsh is not meant to be capitalized <taken>lfam: Ok. Also, another annoying thing most package managers use scripts for is silly databases that several programs want to update, like man-db or icon caches or things like that. What is the guix approach to those sorts of things? <lfam>When built, every package is installed into a unique directory in /gnu/store. Man pages are typically put in /gnu/store/...-foo/share/man/man1, where ... is the unique hash. When a user puts a package in their profile, all the man pages are symlinked into ~/.guix-profile/share/man/man1 <lfam>We provide a file you should source in your login shell that makes that path available, among other things <lfam>Hmm, reading that file, I don't see any mention of the man pages. I don't remember what I did to make them available <lfam>I don't know much about icon caches but we do have them. Maybe they need some love, I'm not sure <taken>Well, I guess I mostly just need to RTFM [which I was doing until my install failed...]. But so far guix looks great. <taken>I wrote this big blog post about a year ago about all these features I wanted in my ideal package manager, then I discovered guix about a month later and it seems to tick most of the boxes. <lfam>I agree, it is great. There are still some rough edges but I prefer to package managers that mutate installed software in place <bavier>taken: I believe icon caches are currently handled via a "profile hook" <taken>and now I'm finally getting around to trying it out... <lfam>bavier: Any idea about the man pages? Why does this work on foreign distros? Is it because I source ~/.guix-profile/etc/profile? <lfam>Hm, I thought I sourced that file, but it seems that I don't! <lfam>I do on my home server, but not on my workstation <bavier>there's a MANPATH native-search-path declared <bavier>so on a foreign distro that will get set in the user's profile <bavier>I was confused for a moment, because I'm on GuixSD, and that env var is set in the system profile <lfam>I have no idea how it works on this Debian system. This is another point for GuixSD ;) <taken>lfam: man-db was probably a bad example, because man uses MANPATH, and I'm really not sure why man-db even exists (I guess it's faster if it's in man-db?), but some groups of programs have databases that need to be updated via mutation. <lfam>Yeah, nothing ever gets mutated in the store <lfam>Those programs typically let you configure the location of the mutable state at build-time, so you just make sure to configure the program to look elsewhere <taken>lfam: so far it sounds like guix just avoids them, which is what I assumed, but I wondered if there were some sort of solution on top of that. Like maybe the database was copied and modified in some way. But, yeah, the real solution is for developers to stop doing that... <lfam>In practice it's not a problem. Not much software requires the state to be in the same directory as the executable. <taken>lfam: yeah. Frankly I don't use much of that software anyway, but occasionally I see my package manager updating weird gnome databases or something. Anyway, thanks for all your answers. <lfam>Huh, when I inspect the environment of `man foo`, MANPATH isn't set. The only references to my ~/.guix-profile are in PATH and GUIX_LOCPATH <lfam>Grrr this is going to drive me crazy! <lfam>This is weird. I sent my libarchive patch to guix-devel, and it showed up in the archive, but it still hasn't been delivered to me. Something isn't right with the mailserver <lfam>Oh, I forgot that I changed my settings to not deliver to me. Never mind :) <taken>Oh, one last question! Does GuixSD have a /usr/bin/env that's always there, so I can run scripts without mucking with their #! lines? <lfam>Ah, everyone always asks this. No :) <lfam>You can make it if you want <lfam>But you will lose the "carved in stone" dependency management that is so nice <taken>lfam: Why do you have /bin/sh but not /usr/bin/env? /usr/bin/env is the one thing I really care about so I can write portable scripts that end up just getting the right interpreter as set by the environment. <taken>lfam: to me it makes more sense to have /usr/bin/env and not /bin/sh... <lfam>My opinion is that if a script is important, I care what interpreter it uses, so I want to use a shebang that points to a unique store path, rather than some random version of the interpreter <lfam>But like I said, if you don't care what interpreter is used, you can make the symlink. `env` is in the coreutils packages. <lfam>Check out 'patch-source-shebangs' in the manual for a potential improvement over `env` <taken>lfam: Well, I really think there should be a default /usr/bin/env always there for convenience, (eg so people can clone their dotfiles repo that includes a bunch of scripts that they use on all OSes), but I guess we can just disagree :) Thanks for all your answers. <lfam>Yes, /usr/bin/env has been discussed many times before. It's really easy to make the symlink. <lfam>But I hope you'll consider my point. You lose most of the advantages of Guix for whatever script you run against `env` <taken>lfam: patch-source-shebangs seems like the wrong thing to me, because then I am mutating the source of my scripts. I see that it's losing the rock-solid linking and whatnot, but there is also something to be said for being able to conveniently use scripts that are already written for maximum portability. <lfam>Okay, as long as you see the drawback, which I think you do :) <lfam>I agree about the convenience factor. <lfam>All of my personal scripts were already interpreted by /bin/sh for maximum portability, so I never felt this particular pain :) <lfam>I think somebody wrote a simple program to import scripts and run patch-source-shebang on them, but I don't remember who or how to find it. <taken>lfam: Hmm... I guess I could always trampoline through /bin/sh to get to other interpreters... but that seems like a mess... <lfam>Yes, better to make the symlink! <taken>How does shepherd compare with systemd? Since both Arch and Debian switched to systemd I've been happy to finally have all my systems (except my phone...) on the same init system. Knowing now that a switch to GuixSD means a switch of init systems again makes me want to use it less... <lfam>Shepherd is implemented in Guile Scheme (like the rest of Guix) and services are also Scheme. <lfam>As a happy systemd user, I would say that Shepherd has considerably fewer features <lfam>But the potential for system integration is much greater, since it's all in Scheme <lfam>I was totally new to Scheme when I started using Guix. I miss the ease with which you can create systemd services, but eventually I realized that you can also do simple per-user services with Shepherd, so I'm happy again. <lfam>I'm currently struggling to write a system service, and I've had to reach out for help. <taken>Hmm... well I am semi-obsessed with lisp machines, so all scheme is very appealing... <lfam>Then you will like it :) <lfam>The functions with the #:start keys, that is <lfam>You can get really complicated if you want. We have a dovecot service that is ~1600 LOC <lfam>We need more. Hopefully when I complete the one I am working on now, I will experience a revelation and add a bunch :) <lfam>There are also people using Shepherd on foreign distros. It's quite flexible <taken>If I run the guix packaging commands with nice, will the daemon build things with a nice value, or should I put nice in the service file for the build daemon? [I've been building stuff and seeing my system less responsive, which I'm not used to since I have make aliased with nice...] <taken>I guess there is probably something I set in the unit file to do that. I just haven't learned more than the minimum of how to write unit files. So I'll check that out. <lfam>I would look into those features, since systemd will make sure they work throughout the entire process tree <taken>lfam: [as an aside, I love syncthing] <lfam>Me too. I'm really looking forward to getting the Go compiler in Guix so we can distribute Syncthing <lfam>Turns out to be a rather difficult task... <taken>Yeah! Beat Debian to packaging it properly... <lfam>No, I mean we haven't done it yet ;) <lfam>Oh, you are encouraging me! <taken>Yeah, but debian hasn't packaged syncthing yet either (last time I checked, at least). So you still *can* beat Debian :) <lfam>Right, I misunderstood you at first <lfam>Syncthing is really an excellent piece of free software <lfam>I owe those programmers so many beers <taken>I agree. I think even feature-wise it beats the proprietary competition in a number of ways. <lfam>I'm looking forward to the next release (0.13). It will have a great performance improvement: partially downloaded files' chunks will be available for upload <lfam>That should make a big difference for large files <lfam>I agree about beating the competition. I whine every time a client of mine tries to send me something with Dropbox and the file is too large. Blech! <lfam>The really astounding thing is how many questions they answer on their forum. I don't know how they keep it up. I try to help out but I get so tired of answering the same thing over and over <taken>I only wish it had a nice non-web interface. I feel like I can't tell my non-technical family members "go to your web browser and go to localhost:1234 to change your settings" <lfam>What about synchting-gtk? <taken>Oh, maybe it already exists. I'll have to check it out. <lfam>I think it's a cross-platform GTK clone of the web interface. At least they don't have to type in a port number :p <lfam>It's still a bit "tech-y" regardles <lfam>Eventually, the protocol could be implemented by 3rd parties who have the resources to spend on very polished interfaces <taken>after a quick trial of syncthing-gtk, I think it is probably good enough to get my family to start using syncthing if I can get them through installing it. Really manually getting to the interface I always saw as the biggest blocker. <lfam>You have to decide if you want to become remote (SSH) tech support for your entire family ;) <taken>Aha! I would actually not mind being ssh tech support for my entire family if that meant I could get my entire family to switch away from Windows! <taken>Then I'll set them all up with duplicity running regularly and putting the backups in a shared syncthing repo that we all keep on a large hard drive, then we can all have encrypted, versioned, off-site backups, and do it all with free software and all within the family [no large soulless corporations included]. <taken>If only it were so easy to entice people away from entrenchment in proprietary software... <lfam>I think it's just human nature. Old habits die hard <lfam>People get entrenched in free software too <lfam>For example, using a free software program that is abandoned or hopelessly buggy instead of switching to a superior free software alternative <lfam>It's hard to change things <uncanny>Hi, doing 'guix pull' on booted USB stick, inside qemu, do I have to do anything else to get guix up to date before doing the 'guix system init'? <uncanny>I'm only asking because it didn't seem to get updated, even though it did compile 497 files(it said) <uncanny>Also 'guix package --update .' didn't do anything <uncanny>I would've tried 'guix system reconfigure but-where-is-usbstick-s-config.scm' ? :) <cbaines>uncanny, Why do you thing it didn't get updated? <uncanny>cbaines: great question! Because the lines that say downloading and the % are getting duplicated/spam and I've seen guix being updated in another vm, it doesn't do that anymore <cbaines>I'm just doing a git pull on my machine, and I'll post the path to Guix that I see, if that matches the path that you see, Guix should be up to date <cbaines>interesting, Guix pull does not seem to have changed the guix that I am using here <uncanny>guix --version reports 0.10.0 (and I can't start the non-qemu(Virtualbox) version of GuixSD that I know has the updated guix to see what it's version is) <uncanny>realpath `which guix` reports a hash starting with b4d41s30...guix-0.10.0-0.7611 <uncanny>I'm looking at the Virtualbox guix now... it's 9p7mf2a...guix0.8-0.10.0-8062... <uncanny>I've rebooted qemu too and it's the same b4d4...7611 , maybe I'm doing guix pull wrong... <cbaines>I have had similar issues when I have had problems with the profile directory and/or paths that I am using <uncanny>would 'herd start cow-store /gnu/store' be necessary? I'm only running it on /mnt <cbaines>I'm not sure yet what that does, but it is in the instructions? <uncanny>yup, but only necessary for the destination partition which is mounted under /mnt <uncanny>it makes the store read-write, or something like that <uncanny>it seems to be talking about /mnt/gnu/store rather than /gnu/store of the usb stick, if I'm reading this correctly <uncanny>Either way, I wasn't getting any errors for guix pull <uncanny>Actually, I might've gotten that wrong... trying with 'herd start cow-store /mnt' and then guix pull <uncanny>Any idea what config.scm was used to create the USB Stick installation ? If I find it I intend on running `guix system reconfigure that_config.scm` and hope guix gets updated this way, before proceeding with `guix system init /mnt/etc/config.scm /mnt` <cbaines>uncanny, I believe what you are looking for is in gnu/system/install.scm <uncanny>looks like reconfigure is doing some grafting and I see guix in that list, when it's done it should be build 8062... <uncanny>Confirmed. So, apparently, unless I'm missing something, a `guix system reconfigure a_config.scm` is needed after a `guix pull` or else guix won't get updated (tested on qemu booted USB stick installation) <uncanny>That being said, grub will fail right at the end; I guess it's not part of the transaction, since it failing still gets guix(and all others?) updated <uncanny>oops I mean /mnt/tmp/guix-inst/ folder <uncanny>`guix gc` just freed 1.1G and I've realized that the free space that `df` reports in /gnu/store/ is the sum of 75% of my RAM + the free space on /mnt (that explains what `herd cow-store start /mnt` does) and the 1.1G freed is freed from both /mnt and /gnu/store (unionfs?). Cool! <roelj>Is --dry-run not supposed to work with --upgrade? <roelj>`guix package --dry-run --upgrade` starts downloading and compiling packages.. <halteaugrabuge>i have a problem at the installation process. I want to add my /home partition in the configuration file. But i fail : / <halteaugrabuge>i tried to put it between the field of the root partition and %base-file-systems, and after %base-file-systems <alezost>roelj: I think it's because of grafts, I also noticed that --dry-run is not respected unless "--no-grafts" is specified as well <alezost>halteaugrabuge: could you paste how it looks like? <roelj>alezost: Ah, that explains. I still find this behavior odd. <alezost>roelj: I personally think it's a bug <roelj>alezost: I can confirm that it indeed works when adding --no-grafts. <halteaugrabuge>alezost: i had (cons and not (cons* . I had the * and it's working : ) <alezost>halteaugrabuge: I guess you used several file systems. It's a scheme question: cons is used to construct an element and a list (cons 1 '(2 3)); cons* is used to construct multiple elements and a list: (cons* 1 2 3 '(4 5)) <halteaugrabuge>i had the two elements, root partition and home partition declared in my configuration file : ) <alezost>yes and also %base-file-systems (which is a list of file systems) <random-nick>halteaugrabuge: if you do (cons 'a 'b) you get a pair with the symbols a and b in it instead of a list with a and b in it <halteaugrabuge>After the installation process, the main manual to read is the guix manual, right? <random-nick>a list is either an empty list or a pair whose cdr is a list <random-nick>the cons procedure makes pairs and the list procedure makes lists <random-nick>and cons* makes a list with the last argument being the cdr of the last pair <halteaugrabuge>i understand nothing X). But i'm sure that when i'll read the manual, i'll understand : ) <alezost>random-nick: thanks for clarifying, I wouldn't like to load halteaugrabuge with all these from the very beginning :-) <alezost>halteaugrabuge: yes, guix manual is a good point to introduce oneself to Guix(SD) <halteaugrabuge>there is nothing installed except the base system after the installation? ***jgay is now known as mrawesome
<wingo>i seem to have broke my guix ***mrawesome is now known as jgay
<wingo>when trying to download thigns it does: <wingo>substitute: ;;; ERROR: missing interface for module (gnutls) <joshuaBPMan>I'm not expert sir, can you roll back to an earlier version? <wingo>does that mean that i need to run my guix-daemon in an environment where gnutls is available or somethign? <davexunit>wingo: are your substitute urls using https? <davexunit>the substituter is indeed run on the daemon side <wingo>i thought the daemon was all c++ and it didn't care about guix paths or profiles b/c its environments were always given explicitly by the user of the daemon <davexunit>wingo: that happens to, when an origin's url redirects to an https url <davexunit>so I guess it would be good to narrow down which component has the gnutls issue <wingo>i think i had done a git pull in guix then a make from an environment that didn't have gnutls, or something <davexunit>ah, that could have happened. adding gnutls to the environment should resolve it. <wingo>davexunit: indeed it seems i need to invoke guix-daemon from within an environment that has (gnutls) in the GUILE_LOAD_PATH <wingo>i used to run it uninstalled just by doing "...guix/pre-inst-env guix-daemon ..." <wingo>pretty strange that guix-daemon would take gnutls from its ambient path! <wingo>especially considering that afaiu guix-daemon contains no guile code <wingo>ACTION learn something new every day :) <joshuaBPMan>hello, I'm trying to get my /dev/sda4 to mount into /home. I've change by configure.scm. But `guix system reconfigure /etc/config.scm` is reporting: /etc/config.scm:8:0: error: source expression failed to match any pattern. <lfam>There have been follow-up releases of the series of ImageMagick that we use: 6.9.4-1 <davexunit>joshuaBPMan: that means that your config file has invalid syntax <joshuaBPMan>gotcha. Well I commented out a line "(cons* %base-services)" now it seems to be working. <davexunit>joshuaBPMan: right, that would have left an expression that looks like: (services) <davexunit>which is invalid syntax for the operating-system record constructor <joshuaBPMan>ok. I'm assuming that %base-services is included in %desktop-services. <davexunit>joshuaBPMan: I think so, but not necessarily. could be a modified form. <joshuaBPMan>daveunit: If my config has %desktop-services, can I leave out %base-services? <davexunit>joshuaBPMan: I think so. my config uses just %desktop-services <davexunit>and you can answer this question and many more <joshuaBPMan>was that a star wars reference to encourge me to read the manual? <davexunit>I don't have the code in front of me right now and don't have time to look. <davexunit>joshuaBPMan: encouraging you to read the source code <joshuaBPMan>It sounded like a "Luke use the source code." thanks. <davexunit>the (gnu services ...) module namespace has everything service related. <davexunit>(gnu services desktop) will be what you want to look at in this case <paroneayea>maybe I should debug why autossh isn't working in guix this morning <z0d>indirectly, yes (running in a VM) <z0d>why do you think it's the SSD? <alezost>ACTION has never met "clocksource" term before <mark_weaver>the clocksource is what the kernel uses to keep track of time. I see similar messages in my kernel log, and it surely has nothing to do with halteaugrabuge's boot problem <mark_weaver>halteaugrabuge: it would help to have more information than "i can't boot on it" <mark_weaver>but probably you made a mistake in your OS configuration <mark_weaver>or perhaps you need a driver that's not included in our initramfs. hard to say without hearing more about what you see happen <halteaugrabuge>Well, my system is booting but stopped at a moment with the message : "clocksource: switched to clocksource tsc" just after a message about my keyboard. <alezost>halteaugrabuge: is there a kernel panic, or was it just stuck, or do you have a repl <alezost>halteaugrabuge: can you print something there? <mark_weaver>the relevant error message is probably earlier in the output <mark_weaver>halteaugrabuge: oh, also, I should mention that there's a lot of output *after* the login prompt, so you might have missed the login prompt. maybe try hitting "return" to see if another one is printed? <halteaugrabuge>i had another message. Something like "Reading system state. You have 31bit of entropy. Type something..." <halteaugrabuge>i type some randoms caracters, there were dots and it began to continue to boot. <mark_weaver>I don't run ssh daemon's on my laptops, so I never noticed this. <davexunit>I'm surprised no one has written an openssh service yet. <mark_weaver>well, I'm not sure I'd call it craziness to want some real entropy with which to generate a key <alezost>halteaugrabuge: not needed, it happens only once <alezost>halteaugrabuge: just press many keys, and you'll get passed <davexunit>the fact that it stops the boot process is just terrible. <halteaugrabuge>so if at the installation i comment this line, my comp' will not do that again? <davexunit>mark_weaver: I'm not sure. all I know is that in all my days of using the openssh daemon I've never had such an issue. <halteaugrabuge>it's just if i install guixsd on another comp', can i comment the lsh-service? i don't use ssh. <davexunit>halteaugrabuge: if you don't want an ssh server running on the computer, then you should delete it from the service list. <mark_weaver>davexunit: if that's because the openssh daemon generates a key with insufficient entropy, that's probably not good either <davexunit>mark_weaver: I doubt that is the case, but I can't say for sure. haven't done my homework. <davexunit>halteaugrabuge: I had assumed that lsh-service was in your configuration because you wanted an ssh server <davexunit>I run ssh servers on all of my machines so I can remotely access any machine on my local network <davexunit>sometimes I transfer files between them via ssh <halteaugrabuge>i haven't got the knowledges for that yet. But one day who knows... <uncanny>How do you transfer files outside of a qemu guix? <habs>Hi, I have this problem where if I view videos in VLC at the default (small) window size, I can see everything, but if I try to resize the window the video gets cropped, like this: http://imgur.com/a/UN3AB What can I do to debug / fix this? <habs>I'm using GuixSD / GNOME on a Thinkpad X200. glxgears seems to work fine (runs at the max of ~60fps full screen), here is the output of glxgears -info: http://sprunge.us/RLPV <mark_weaver>habs: hmm, I don't use vlc on Guix, so I don't know off-hand, but in the meantime I can recommend the 'mpv' movie player <joshuaBPman>habs: are you experiencing any other issues with Gnome? about 10 minutes after I log in, Gnome won't let me open any new programs. <mark_weaver>joshuaBPman: that's a problem I've not heard about before <joshuaBPman>mark_weaver: Well I installed with /dev/sda1 (root) at /mnt and /dev/sda4 at /home. But I ran `guix system init` when my config file DID NOT specify that it needed to mount home. I'm wondering if that has anything to do with it. <joshuaBPman>also I did not run guix pull before running 'guix system init' <mark_weaver>joshuaBPman: have you run "guix pull" and "guix system reconfigure" since then? if not, you've got a lot of unpatched security flaws. <petter>habs, i had those problems as well. I fixed it in the settings. Pretty sure it was unselecting "Resize interface to video size" that fixed it for me. <joshuaBPman>yeah. I've run guix pull a lot. But I'm think that guix system reconfigure is failing. I'll try both again now and let you know what happens. <mark_weaver>joshuaBPman: note that "guix pull" only updates guix for the user that runs it. since "guix system reconfigure" is run as root, you need to run "guix pull" as root or else you'll get old stuff. <mark_weaver>you'll also need to run "guix pull" as your normal user, for when you run "guix" as your normal user, e.g. to install packages in your user profile. <joshuaBPman>mark_weaver that makes a lot of sense! WOW! I knew you guys did seperate user profiles, but I did not know that guix pull and sudo guix pull did 2 different things! awesome! <habs>petter: Thanks, it was unchecking "Integrate video in interface" and then restarting VLC that did it for me! <petter>habs: Aha, ok, it may have been that for me too. ***pizzaiolo1 is now known as pizzaiolo
<paroneayea>is there a nice command to see "is this thing currently building successfully on hydra"? <paroneayea>so I know if it starting a build here is because it hasn't been built yet, or if it can't likely be built at all <davexunit>I've wanted that feature, but I don't think we have anything yet. <paroneayea>ok, I won't hack it now, but maybe some future time <davexunit>I don't know if we can get enough information from hydra to know right now <kyamashita>Is there a simple way to make a debug build of a package, so that debugging in GDB is easier? <bavier>kyamashita: try adding a "debug" output to the package; stripped debug symbols will be put there <kyamashita>bavier: Is that simple to add? Is it just a list with "out" and "debug" sort of like the inputs to a package? <bavier>kyamashita: yes: (outputs '("out" "debug")) <joshuaBPman>hello, I tried a `sudo guix system reconfigure /etc/config.scm` Right now it is saying "shepherd: Evaluating user expression (register-services (primitive-load "/gnu/s.."))" and it's been saying that for the last half hour. <bavier>joshuaBPman: installation might have moved on to other things since that shepherd message <lumidragon>Hi all. Does anyone know which package contains the ldd command? <bavier>lumidragon: np, let us know if you have any other questions <lumidragon>sure np, I might have some more. I made my first package submission today. Thinking to try my had at the golang compiler. Will see. ***timmy is now known as Guest51086