<mark_weaver>kete: hmm, (console-keymap-service "en-latin9") *might* work, but I'm not sure <defanor>(console-keymap-service "en-latin9") works here <mark_weaver>we should probably document that the argument can simply be a string <lfam>defanor: You can pass any OS configuration file to `guix system disk-image` <lfam>gnu/system/install.scm just happens to be an OS declaration that creates or installer <defanor>is it planned to stick to syslog in guix? and will the programs that require systemd journal not get packaged in guix, or will there be some compatible library? <lfam>defanor: Out of curiosity, what programs require journald? <defanor>lfam: probably not many, i only have some of my programs (in-house ones, as work) in mind <lfam>Anyways, I don't think we really have anything against systemd. One of our contributors created elogind, which is basically a standalone logind for things that require it. IIUC that's one factor that lets us have GNOME <lfam>Your programs can't just write to stdout? <defanor>lfam: nope, relying on custom fields there <defanor>(though those could be put into text, and then grepped, but it's much less handy + slower) <lfam>I do like journald. I have no idea what it would take to get something compatible in GuixSD. <lfam>I do think it's kind of lame if a program can't write to stdout, but that's just me ;) <defanor>yup, generally it's nicer to make dependencies optional. but i'm mostly aiming debian and centos there, so it won't really be used anyway <lfam>You should add some structured logging support to the Shepherd, or a separate program that the Shepherd can talk to :) <defanor>maybe, if i'll figure how it all works. currently just skimming random sections of the info file <marusich>I'm finding all kinds of neat packages recently in Guix. Just the other day I discovered someone added pioneers, and I played a game with a friend of mine :) <marusich>I'm failing to understand how the (((? option? o) args ...) part works <marusich>I see in the Guile manual ((guile) Pattern Matching) that (? predicate pat_1 ... pat_n) will match "if predicate true and all of pat_1 thru pat_n match". <marusich>However, I am confused about the structure of the code in ui.scm. I expected to see it as (((? option? o args ...) or something, but instead it is (((? option? o) args ...) <marusich>Clearly, I'm missing something. What am I missing? <marusich>I see that option? is a procedure which takes a single argument and tells me whether or not that argument (a string, ostensibly) begins with "-" <marusich>I don't see how the (? option? o) part fits in with the pattern matching <marusich>I think I understand what's going on for other clauses, but not that one. For example, for the ("help" command) clause, I believe it's saying that if args is a two-element list whose first element is the string "help", then we should run the matched command with the "--help" parameter. <marusich>"(? predicate pat-1 ... pat-n): In this pattern, predicate must be an expression evaluating to a single argument function. This pattern matches if predicate applied to the corresponding value is true, and the subpatterns pat-1 ... pat-n all match." <marusich>I think I'm missing something obvious here, and if someone could clarify things for me, that would be super awesome. <marusich>Ah, I get it now, I think. I did some experimenting. I guess that the pattern matching mini-language interprets the pattern ((? predicate a) b) to mean the same thing as the pattern (a b), with the added restriction that (predicate a) evaluates to true. <marusich>At least, that's how it seems to be when I do my experiments. If I'm wrong, please correct me. <marusich>so ((? option? o) args ...) is meant to match any list where the first element is a string that is also an option <ifur>any examples of how to deal with downloading additional data files in a package? <iyzsong>ifur: you can pass <origin> objects to inputs (eg: openjdk6-src, ratposion.desktop). <defanor>how it one supposed to run pioneers? i've installed them with `guix package -i pioneers`, and tried to just run `pioners` – but getting an error that says that it can't find a pixmap file. also a couple of warnings before that <defanor->getting this error when installing or removing packages: "Directory '/gnu/store/wbh2hzgnz4bgcjm8zxink8dgvsf7258w-xdg-mime-database/share/mime/packages' does not exist!" <mark_weaver>defanor-: did you delete files from your store manually? <defanor->doesn't work without sudo, trying with it <iyzsong>that's a normal error (warning?), and will happen when there is no package in profile provide mime files (eg: shared-mime-info). <defanor->"guix gc: error: build failed: you are not privileged to repair paths" <mark_weaver>defanor-: you're right, you have to be root to do the 'repair' thing <defanor->"reading the Nix store..." "checking path existence..." -- that's with sudo, and quits <mark_weaver>defanor-: oh, okay. actually, forget this. listen to iyzsong :) <iyzsong>yep, maybe I should redirect it to /dev/null :- <defanor>i quite like guixsd by now, but can't figure where to apply it. are there any common uses yet, aside from guix poking and development itself? <alezost>defanor: the use for several (or maybe many) people is to use it as the main OS :-) <defanor>alezost: ah, of course. that might be tricky for me though – a bit stuck on my current one <defanor>i could install it on a netbook, but i rarely use it. would be great if i had to move between computers with my own system often, but i don't do that <defanor>or at least if i had to install the same pre-configured system on many servers, but it's probably too early to use in production <defanor>also rolling release scares me a bit. btw, does guixsd restart the services that depend on updated packages? <defanor>when a kernel or shepherd itself gets updated, does it ask for a reboot? <wingo>ACTION perplexed, i did "guix environment -s i686-linux guile" and it hardly installed anything, and configuring a package detects me as being in x86-64 still <mark_weaver>wingo: unfortunately, it seems that "guix environment" might ignore the -s flag :-( <mark_weaver>wingo: here's a suggested workaround: $(guix build -s i686-linux guix)/bin/guix environment guile <mark_weaver>you'll probably need to add --pure as well, actually, to avoid mixing x86_64 stuff in there <wingo>well anyway that's doing its thing, it seems <wingo>so i will use that environment to do a fresh Guile build <wingo>so could i instead "build" guix from my git repo? <wingo>that would then install different versions of the packages i guess <wingo>maybe that doesn't work as i would need the checksum of the guix version i am working from <wingo>which is master from a few days ago <mark_weaver>do you use "guix pull" or do you run guix from a git checkout? <wingo>i just do what you told me to do ;) <mark_weaver>well, you'd need a working "guix environment -s" to do that easily <wingo>anyway, it doesn't seem to be downloading a new gcc so maybe the guix package version isn't too outdated <mark_weaver>but it probably doesn't matter. you shouldn't need a very fresh guix to set up a suitable build environment for guile <mark_weaver>it will use the 'guix-devel' package from your git checkout to build the i686 guix, and that should be new enough <mark_weaver>and as a bonus, that version of guix should be already built on hydra <wingo>$(guix build -s i686-linux guix)/bin/guix environment --pure guile <mark_weaver>within that environment, what does "gcc -dumpmachine" report? <mark_weaver>looks like config.guess looks at uname -m, which reports info on your kernel <wingo>do you happen to know what's the right thing to do here? specify some argument to configure? <wingo>$ setarch i686 ./build-aux/config.guess <wingo>so maybe i configure under setarch and build too under setarch, or something <wingo>ACTION wants to get this rolling so he can do some errands :) <lumidragon>Hey all. question is there a way to to tell from script/cli if it's running on GuixSD? <mark_weaver>will that setarch setting propagate to subprocesses? I guess it must <mark_weaver>ah, we're getting burned by /bin/sh being at a fixed location here <mark_weaver>and in your case, that's an x86_64-linux version of sh <wingo>so if you invoke config.status via the shell's sh... hmm <mark_weaver>there are SHELL and CONFIG_SHELL environment variables that could be set <wingo>i think it's a kernel thing tbh <mark_weaver>all of our i686 binaries in guix are built on machines with x86_64 kernels <mark_weaver>wingo: well, one thing you could do to get things rolling is this: <wingo>yeah but i want a proper git repository <wingo>i don't like developing against failed guix builds, i find it really painful <wingo>are you sure? i ran via "sh ./build-aux/config.guess" and still got the x86-64 result <mark_weaver>config.guess is calling uname -m, which is a subprocess <mark_weaver>so, if the setarch setting didn't propagate to subprocesses, then setarch i686 config.guess would still report x86_64 <mark_weaver>right, uname -m talks to the kernel, but apparently it honors the personality setting of the processing asking. <wingo>i just made super-mega-clean in the wrong checkout <mark_weaver>the fact that "setarch i686 config.guess" reports i686 tells us that the personality is propagated to subprocesses, and that "uname -m" returns a result that depends on the current personality <wingo>yeah i seem to remember ludovic saying something like that <mark_weaver>build-aux/config.guess has a #!/bin/sh shebang on top <wingo>welp, i'm going to rebuild my proper guile first :) <wingo>ttyl, that will take an hour or so <mark_weaver>so, regardless of your i686 environment, it's going to use your x86_64 shell <mark_weaver>maybe I should just give you access to one of my boxes with i686 guix installed on it <mark_weaver>actually, I'm a little surprised that "setarch i686 ./build-aux/config.guess" reports i686-pc-linux-gnu, because I'd expect it to honor the shebang on top of that config.guess script <mark_weaver>oh, I see. the setarch(8) man page says "setarch currently only affects the output of uname -m." <mark_weaver>wingo: I suspect that passing "--build=i686-unknown-linux-gnu" to ./configure might be sufficient <wingo>i think that the setarch call worked, i have both things building now <mark_weaver>it seems that setarch won't help with anything beyond that, anyway <wingo>b/c setarch caused configure to choose i686-linux <anthk_>with "guix pull" I'll get those changes :) ? <mark_weaver>lumidragon: /usr/bin/env doesn't exist on GuixSD, and it exists on just about every other system, so you could check for that. <lumidragon>anthk_: if "those changes" you mean the latest package updates/changes. Then yes. <mark_weaver>lumidragon: but in general I would discourage logic that tries to determine which distribution you're on <mark_weaver>GuixSD doesn't put programs at fixed locations in the filesystem, in general. we make an exception for /bin/sh only, because it would be too painful otherwise. <lumidragon>I'm mostly exploring ways to make my zsh and emacs config more portable. <mark_weaver>putting programs/libraries at fixed locations in the filesystem is incompatible with our basic design, which allows any number of versions of the system to exist together on the same filesystem. <jmd>mark_weaver: I don't understand why it would be too painful. Anything which needs a sh should have had its reference to it substituted when it was built. <mark_weaver>well, the pain comes when you try to do development, which usually involves building things by hand from pristine sources, where #!/bin/sh is extremely common <mark_weaver>there has been some pressure to make another exception for /usr/bin/env for similar reasons, and NixOS did exactly that, but here in Guix land we're trying to hold the line <lumidragon>then what would be a good shebang when scripting on guix then? <lumidragon>awesome my emacs-helm package is in, hopefully go@1.4 won't be far behind :) <mark_weaver>well, ideally, scripts would proper guix packages in your profile, and we should provide tools to very easily import a simple script, rewriting the shebang as needed to reference something in /gnu/store directly <mark_weaver>but in the meantime, if you need a shebang other than #!/bin/sh, I would suggest #!/run/current-system/profile/bin/python or whatever <lumidragon>ah so every project should be guix package then? <mark_weaver>but I think that the easy-script-import proposal is the Right Thing (TM) <mark_weaver>one of our design goals is that if a program from a given profile works today, it should work tomorrow. if you update your system and something breaks, you should be able to roll back and the old version should work, as it did before. <mark_weaver>and that depends on programs relying principally on immutable items in the store <mark_weaver>shebangs that refer to things like #!/bin/sh that will change work against that goal <mark_weaver>and make it more likely that roll-back will fail to work in some cases <mark_weaver>and things like #!/usr/bin/env work against that goal in a deeper way, by searching for programs in your PATH <davexunit>/usr/bin/env only gives the illusion of portability anyway <lumidragon>so I should just turn my script projects into guix packages? <mark_weaver>so let's say you have a python script that works today. by rewriting the shebang to refer to a specific immutable version of python in /gnu/store, that helps ensure that it won't break someday when you update the version of python in your system profile <davexunit>I think that we need is a procedure that takes two arguments, a script file and the desired interpreter package, and returns a package object for it <lumidragon>for the shebang? or something independent of the script? <mark_weaver>davexunit: sounds good to me! that would be sufficient to easily add scripts to a manifest as used by "guix package -m" (which is the best way to maintain a user profile, IMO) <davexunit>mark_weaver: yeah, that's how I'd envision it being used. <mark_weaver>we'll probably want to find a good solution for people who don't use "guix package -m" as well <davexunit>yeah there could be a CLI for it for one-off jobs <mark_weaver>maybe some syntax for specifying such a script as an argument to "guix package -i" <davexunit>maintaining a package manifest in a git repo has been really helpful <davexunit>for the first time I have a canonical list of the software I use regularly that I can easily bring to any machine <lumidragon>That's what I'm looking to transition to, at least for my emacs config. <lumidragon>at least helm and projectile are now available. :) <davexunit>this week I just decided that I've had enough of package.el <davexunit>and packaged everything that I use regularly <lumidragon>and just use el-get if i'm on a machine without guix. <davexunit>if I'm on a machine without guix, the first thing I do is put guix on it :) <davexunit>like at work I was given an ubuntu workstation <davexunit>but there is a binary tarball for bootstrapping guix on a new foreign distro easily <lumidragon>but yeah I just have el-get as a fall back, so I can have my emacs running even if guix isn't present. <lumidragon>hopefully I'll get a chance to move the rest of packages I use soon. <lumidragon>oh question, if I want to add an npm package should I wait for node npm build system? or just go ahead and write one? <davexunit>lumidragon: building that is part of a GSoC project <davexunit>it's one of the more complicated systems to figure out <davexunit>because of the generally low standards for npm packages <lumidragon>I know I was looking at the gulp dependency graph the other day. OMG! <davexunit>and there's lots of circular dependencies if you want to run test suites <davexunit>so, it's going to be a difficult project. I think that jlicht, the student doing the work, will make some good progress <davexunit>it might be good if we can think of some applications that are written in nodejs that we could work towards <davexunit>just packaging random libraries doesn't do too much good if we don't have actual applications that use them. <davexunit>yeah, those dev tools would be good candidates <lumidragon>cool, I'm looking to transition to career in that direction. :) <lumidragon>mostly looking getting serious about rails and clojure. <davexunit>web dev work has a fairly low barrier to entry <cpjjl>(hi 'guix-people), since I did ln -s ~/whatever/guix-git ~/config/guix/latest, my system is kind of weird <cpjjl>like for example, i've got a lot of "source file guix-git/something newer than compiled file" <cpjjl>my emacs guix repl doesnt work anymore <cpjjl>and I have this weird message <cpjjl>unknown meta command: geiser-no-values <mark_weaver>including me. it works well in practice, I find, as long as you make sure to keep that git checkout built and in a good state <cpjjl>I did git pull a few hours ago <mark_weaver>but the emacs guix repl needs to be told where to find things, iirc <mark_weaver>cpjjl: see section 4.1 (Emacs Initial Setup) in the guix manual <mark_weaver>specifically, the bit about "If you did not install Guix at all and prefer a hacking way" ... <mark_weaver>alezost is the author of the emacs guix stuff, so he's the best person to ask if you have problems with that <mark_weaver>also, I'm assuming that you built the git checkout. if not, you'll have lots of problems. <cbaines>I have a package which attempts to install during the check phase, and fails as it cannot write to the directory, I guess as its not there? <cbaines>I'm not sure how to work around this, is there a common approach? <cbaines>Would moving the install phase before the check phase help? <mark_weaver>cbaines: if it fails to install because it can't write, that suggests that the problem is that you need to tell it the right place to install. separating the check and install phase wouldn't help for that. <cpjjl>mark_weaver, after building, it all works perfectly thanks again <cpjjl>now I have another question :p <mark_weaver>for projects without a proper ./configure script, typically this is done by adding PREFIX=... to #:make-flags <cpjjl>say I don't want to update libreoffice everytime I upgrade my packages <mark_weaver>cbaines: see the 'tree' package in admin.scm for an example <cpjjl>is there a way to install a specific generation of libreoffice? <cpjjl>a version that was installed previously <mark_weaver>cpjjl: you can do something like: guix package -u . --do-not-upgrade libreoffice <cpjjl>and that is still in my garbage collector <mark_weaver>so it will upgrade everything except for libreoffice <cpjjl>but right now libreoffice is uninstalled <cpjjl>(because at the time I didn't know this) <cpjjl>and if I install it, it'll start building gigs of stuff <cpjjl>what I need is somethink that says: "guix package install this garbage collected version of libreoffice, generation 73" <cpjjl>well, maybe the easier would be to <cpjjl>and then use the --do-not-upgrade option <cbaines>mark_weaver, had another look, and using mkdir-p (rather than mkdir) solved it, so the output directory was not there, but could be created, so it now works :) <mark_weaver>sneek: later tell cpjjl: you can also do something like: guix package -i /gnu/store/...-libreoffice-5.0.5.2 <mark_weaver>sneek: but either way, beware that if you don't keep things up-to-date, you'll end up with a libreoffice that has security flaws. <mark_weaver>sneek: later tell cpjjl: but either way, beware that if you don't keep things up-to-date, you'll end up with a libreoffice that has security flaws. <mark_weaver>sneek: later tell cpjjl: even if the security flaw isn't in libreoffice itself, if there's, say, a security flaw in libxml2 or something, then if you don't update libreoffice you'll keep one that continues to use the old unpatched libxml2. <ng0>hm.. my message regarding trustable guix pull on debbugs did not arrive? <ng0>ah, it was just slow <kete>How do I visit the gnu system module? <mark_weaver>I'd prefer to see an answer from kete, rather than guessing <ng0>I was just guessing, an answer would be better though <mark_weaver>in general, module (foo bar baz) will be located at DIR/foo/bar/baz.scm, where DIR is in the load path <mark_weaver>in this case, look in gnu/system.scm within the guix source code <kete>thanks, is that unavailable on the installation media? <mark_weaver>kete: you want to browse the guix source code from the USB installer? <kete>was that a trick question? <mark_weaver>it just seems a rather odd thing to do. the USB installer is a rather minimal system, not really meant for development. <mark_weaver>in there, you'll see the name of the /gnu/store/...-guix directory that contains guix itself <mark_weaver>and within that directory, look in share/guile/site/2.0/gnu/system.scm <ng0>is my understanding of hydra correct that its jobs need to be nix or guix based (depending on which one you use) or could I throw gentoo based buildjobs at it? <yoosty>so I /finally/ have a bit of a "New Users - Quick Setup" guide written in contributing.texi, how might I go about getting that patch added to the repo? <ng0>create a patch against the latest master, send it to guix-dev list :) <yoosty>allrighty, just need to send to guix-dev list then :) ***catonano is now known as catonano_
<ng0>yeah I think buildbot is what I should use.. a hydra which could do ebuilds would be nice. <notadrop>new iceweasel package seems to be broken. where do I report this? <notadrop>how can I roll back? I've never had to before. <notadrop>I'll be reading the docs in the meantime <notadrop>I only need to rollback one package, icecat <notadrop>civodul: is this not the same as what "info guix" has? <notadrop>civodul: I've skimmed the docs on package management, but I can't find anything on rollbacks. Could you help me out? I know it has to be documented somewhere <notadrop>i'd prefer to just roll back one package, but if I have to roll my user's config back to the previous one, that is okay as well <catonano>notadrop: "guix package --list-generations" will show you all the generation and the list of packages that each generation had installed in it <davexunit>notadrop: roll backs happen on a generation level <notadrop>Okay, this is WEIRD. Icecat won't work if launched from XFCE or from the shell by "$ icecat" but it DOES work if I Ctrl+Click a link in the shell, to open it in browser. ?_? <civodul>notadrop: in "Invoking guix package", search for "--roll-back" <notadrop>I will try installing CUPS, see if that fixes it <notadrop>even if it does, IceCat shouldn't be breaking because I don't have CUPS installed. <notadrop>How to mount a USB flash drive in GuixSD? <efraim>gcc-5.4.0 is out, wonder how that'll work with arm <notadrop>does anyone know how to mount a flash drive in GuixSD? <notadrop>the usual mount /dev/sdX /foo/bar doesn't work. gives error: <notadrop>msdos partition table, fat32 fs... I'm not sure why it won't work <marusich>You mount in GuixSD the same as in any GNU/Linux distro <notadrop>marusich: well, that isn't working, hence why I am even asking <marusich>I'm not sure what error yo'ure getting, notadrop, but you should be able to mount as root and mount it where you need it. <marusich>What's the error message, though? I'm not sure what "msdos partition table, fat32 fs..." means - is that what mount outputs? <notadrop>mount: wrong fs type, bad option, bad superblock on /dev/sdb, <notadrop> missing codepage or helper program, or other error <notadrop>i'll try re-doing the part table and fs in parted, one sec <marusich>Let me see if I have a FAT32 FS on a USB stick here <marusich>It seems I don't have one available, and I can't find a mkfs tool to make FAT32 file systems on my GuixSD installation, so I'm not sure how to test <marusich>FWIW, /proc/filesystems does not list fat32 <marusich>I wonder if fat32 isn't available right now in GuixSD? <marusich>mkfs is around. you might need to install it <marusich>I'm not sure how to add it, but I'll bet this is the cause of your problem <notadrop>okay, time to dual boot GuixSD with non-beta software <marusich>Perhaps you can add figure out how to add it and submit a patch? ;) <marusich>guix package --search=fat32 shows nothing, so i'm not sure anyone has added anything yet <civodul>marusich: isn't fat32/vfat available as a kernel module? <marusich>so notadrop , if you already have a fat32 fs on the usb stick, maybe you can mount it using the "-t vfat" option to mount <notadrop>ugh does anyone know the type code for EXT4 in fdisk? <marusich>Do you mean the number associated with the partition that indicates its type? I am using 83 (Linux) with no problems using ext4 file systems <marusich>Although, to be honest, I'm not entirely sure when that number is significant <marusich>Doesn't that just indicate the type of partition table being used? <efraim>there's a patch for gparted on the mailinglist <marusich>notadrop, parted is also available if you prefer that. <notadrop>where is the "clear" shell command? I miss it