<lfam>Why would you use RAID across a single disk? What improvement could you be hoping to achieve? <davexunit>so --disable-multilib doesn't seem to help :/ <mark_weaver>davexunit: I assume you meant that removing it doesn't help? <davexunit>from my searches, I've seen other people use that flag when compiling avr-gcc without any bad consequences <davexunit>now I'm not sure what direction to head in. the package recipes for gcc are complicated. <davexunit>mark_weaver: there was an article posted about the 0.9.0 release. is this for something else? <davexunit>no comments, though, so I don't know if many people read or cared about it. <mark_weaver>it's the lead story in the "Distributions" section of LWN this week. <mark_weaver>there's also a lead story about Guile in the "Development" section of the same LWN :) <paroneayea>mark_weaver: davexunit: lwn doesn't seem to mind occasionally sending subscriber links, so <fps>hmm, on a system install i cloned the guix repo and did "guix environment guix" <fps>fps@raksha ~/guix [env]$ ./bootstrap <fps>+ exec autoreconf -vfi <fps>./bootstrap: line 5: exec: autoreconf: not found <efraim>fps: doesn't look like you have autoreconf <efraim>er, nvm i see the [env] now, so it has to be guixsd <fps>and i recently guix pulled <efraim>right, but autotools is normally only for developing, so it likely isn't installed by default <fps>efraim: that's why i did guix environment guix <fps>i'll repull, reconfigure and try again <efraim>try guix environment guix-0.9.0.43c082b <efraim>guix package -s guix shows different dependencies for them <fps>package not found.. hmm <efraim>i just tried guix environment guix-0.9.0 and its pulling guix-0.9.0.43c082b as the guix version <fps>then my system is out of date i suppose <fps>i'll pull and reconfigure <alezost>do you set your env vars in ".bashrc"? <fps>alezost: nope. nothing yet <fps>or rather: it's the installed default <alezost>fps: look at the output of "env" in the guix enviroment shell <fps>dependencies: bzip2-1.0.6 emacs-no-x-24.5 geiser-0.8.1 gnutls-3.4.5 guile-2.0.11 <fps>+ guile-json-0.4.0 gzip-1.6 libgcrypt-1.6.3 pkg-config-0.28 sqlite-3.8.11.1 <fps>whols guix package --show=guix output <alezost>fps: hm, there is no "autoconf" there; is it for "guix environment guix-0.9.0" or "guix environment guix"? <fps>guix environment guix <alezost>fps: try "guix environment guix-0.9.0-43c082b" as efraim suggested <alezost>I thought that "guix environment guix" is for the devel version, but apparently it is for a 0.9.0 tarball; so you have to use "guix-0.9.0-43c082b" <alezost>oh, now I noticed "<fps> package not found.. hmm" <alezost>fps: sorry, then you need to "guix pull", then "guix environment guix-0.9.0-43c082b" should work <mthl>seems like a bug in the documentation <fps>fps@raksha ~/guix$ guix --version <fps>guix (GNU Guix) 0.9.0 <fps>possibly too old in the end? <fps>09:21 < fps> package not found.. hmm <fps>fps@raksha ~/guix$ guix environment guix-0.9.0.43c082b <fps>guix environment: error: guix-0.9.0.43c082b: package not found <alezost>mthl: yes, perhaps something changed recently, I vaguely recall that "guix environment guix" worked for the devel version in the past <alezost>fps: I think alternatively you can do "guix environment -e '(@ (gnu packages package-management) guix)'" ← it should work even without "guix pull" <alezost>efraim: no, look in (gnu packages package-management) module: there is (define-public guix guix-devel) there <fps>alezost: yes, it worked just fine on other installs i have <fps>oh, but interesting there's a package called guix-devel. didn't notice that before <fps>in package-management.scm <fps>and opposed to the package guix it does have the autoconf input <alezost>fps: yes, guix-devel is exactly that "guix-0.9.0.XXXXXXX" package (43c082b in the latest snapshot) <fps>the pull will take a few hours. and i have a date to attend to <fps>will try again later :) <efraim>oh, remember tilda? I pushed it on the 16th and on the 17th they released 1.3.0, so now it probably doesn't need vte-0.36.5 any more :) <alezost>ACTION doesn't understand the question (and blames his English) <MatthewAllan93>haha sorry the bare-bones.scm or desktop.scm that can be used during the installation of guixsd, what programming language are they written in? <efraim>i forget who I was talking to about it yestday, but I've got an answer about booting armboards, uboot+kernel doesn't switch to a "new OS kernel" that it boots, and debootstrap doesn't install a kernel (or grub) by default <MatthewAllan93>thanks alezost :), just want to edit one of those files for my next installing on my netbook :) <iyzsong>civodul: hi! yes, great article about services composition :-) <iyzsong>I want use SXML to config xorg, something like '(Section "Files" (ModulePath "...")), then transform it to xorg.conf. but then I noticed it have to refer package object, so it's really about transform GEXPS? maybe gexp-append and SRV:send-reply* (for gexp) is all I want? <iyzsong>I think transform SXML to config files is more readble than append strings directly. this is what I have get: http://paste.lisp.org/display/159908. I don't know how to handle references to packages (SXML contains gexps) yet. <civodul>iyzsong: i think you'd rather used plain sexps, or even records, to config Xorg, no? <civodul>SXML can be verbose, and since we don't need XML here, maybe it's better to avoid it <civodul>maybe you could do a <section> object with a name (like "Files") and an alist <iyzsong>ah, ok, I just think pass a extra sexp is more readble than pass a extra string. and making reconds or object for the various options is a too big work :- <iyzsong>and I'd like an interface for (xorg-configure-file #:modules (list xf86-video-intel xf86-input-libinput)), which should get the "Files" section, and the $pkg/share/xorg/conf.d/*.conf into the final xorg.conf. <civodul>iyzsong: in that case plain sexps would work: (section "Files" (ModulePath "Foo") ...) <iyzsong>civodul: ok, I just have some simple idea now, will try later :-) <davexunit>I upvoted that HN post without thinking while I was on the bus. hopefully we didn't trip the voting ring detector again. <civodul>i'm happy to rediscuss it later if you want <civodul>davexunit: but maybe we did because i don't see it on gwene.com.ycombinator.news <davexunit>hopefully there will be some discussion there <iyzsong>maybe we should send an email about it to nixos? I believe it will interest many people. <MatthewAllan93>stupid question but you know because stuff linked in different places than usual and i wanted to create an additional partition for my home folder. would i need to something else after creating partition <civodul>iyzsong: dunno, i don't want to spam them more ;-) <civodul>MatthewAllan93: so what's the question? :-) <iyzsong>MatthewAllan93: before install GuixSD? then I guess you should add a file-system entry for it to your config.scm <MatthewAllan93>i tried that yesterday but couldn't get use to config.scm file but i want my folder on another partition but would i need to do anything stuff thats linked to the home folder <MatthewAllan93>or do you think i am best reinstalling altering the config.scm during the installation to include the home folder on another partition <iyzsong>MatthewAllan93: suppose you made a partition '/dev/sdaX', and want to mount it as /home, then (file-system (title 'device) (mount-point "/home") (device "/dev/sdaX")) should be add to the file-systems. <civodul>davexunit: are you saying the article oversells the thing? ;-) <davexunit>I want to take a stab at a service that puts ssh keys in home directories <iyzsong>MatthewAllan93: no, you can do that after install GuixSD, (and I consider this more safe), and do a reconfigure, also check /etc/fstab to see if is what you want. <civodul>davexunit: i would suggest having it produce a dmd service that depends on 'user-file-systems' <civodul>the service would simply copy the files to /home/foo or whatever when it is started <davexunit>I wonder if the data structure should be user name strings -> list of public key strings <davexunit>or user account record -> public key strings <davexunit>what if an invalid user name is put into the former? <MatthewAllan93>ok created the home partition on /dev/sda3, but where is /etc/fstab because i can't find it <civodul>davexunit: more generally, i think the data structure should be given a file-like object, a file name where to copy it, along with the owner and permissions <civodul>and maybe a Boolean stating whether to overwrite existing files <davexunit>civodul: okay, that way it's not an ssh thing at all <davexunit>I'm starting to see direct analogs between Chef "resources" and our new service system. <iyzsong>MatthewAllan93: oh, sorry. my mistake, we don't have /etc/fstab. <civodul>davexunit: looks similar, at least to the "file ... do" construct <davexunit>*everything* in chef is managed this way, imperatively. <Steap>davexunit: could we replace chef/ansible/puppet with Guix ? :p <davexunit>I want Guix to have all the necessary features to replace them <MatthewAllan93>didn't think so because i checked yesterday when i installed to see if i could create it and then add it to /etc/fstab. thats why i wondered is there a way to still mount the new home partition on boot <Steap>davexunit: I won't bother learning puppet then <davexunit>with Chef, people write tons of new resources for various pieces of software <davexunit>and many of Chef's resources aren't needed because we can have the package management system <iyzsong>MatthewAllan93: after adding the file-sytsem entry and do 'guix system reconfigure', during next boot, the partition will be mount by dmd during boot (hopefuly) <davexunit>civodul: do we have pre-existing examples of how we'd like users to specify file permissions? <civodul>davexunit: i would say with #o755 and similar no? <civodul>the directives above 'populate-root-file-system' do that <yakh>Is anubody here using guixSD as his/her default OS here? <MatthewAllan93>iyzsong: ok, so when i use that .scm file, would i just do 'guix system reconfigure' then? <yakh>I want to know is in a situation to be use someway <iyzsong>MatthewAllan93: yes, but you definitely want to custom it for your own need. <yakh>I mean can I use it for dailly usages? <yakh>civodul: web surfing, a little python programming, training bash scripting, watching movies, music <civodul>yakh: that may work, but to read the above page to get a clearer idea <davexunit>some people are *really* adamant about the FHS <xd1le>well nixos doesn't follow fhs either right? <davexunit>it's incompatible with functional systems management <taylan>("right" would have been most unambiguous I think) <xd1le>i guess the dealkbreaker was systemd <xd1le>just asked the same question <davexunit>systemd is very polarizing, more so than FHS fundamentalism. <taylan>I suppose we could populate the FHS locations with symlinks to /var/current-system? but maybe that would be counter-productive. applications shouldn't hardcode paths... <davexunit>we have a discussion on the mailing list about adding /usr/bin/env <davexunit>I don't want a /usr at all, but I've also found myself wanting /usr/bin/env so that I can use scripts that other people wrote without modifying them. <taylan>so some script containing /usr/bin/imagemagick for some reason works ... but that's not a good script in first place. it could be in /usr/local or /opt. <MatthewAllan93>iyzsong: do you just "guix system reconfigure" or include that with config.scm? <taylan>well a script could traverse the usual locations like /bin, /usr/bin, /usr/local/bin, etc. to search for an executable. I don't have a concrete use-case in mind but I can imagine it being arguably useful... <mark_weaver>I think the better solution is to have an easy way to easily import a script and add it to your profile. shebang rewriting would be handled automatically as part of that. <davexunit>or ways to do it as a one-off that isn't added to any profile <mark_weaver>MatthewAllan93: "guix system reconfigure config.scm" <xd1le>yeah, where the 'script' command basically figures out the appropriate shebang <mark_weaver>I want the shebang to refer to a specific item in /gnu/store, so that e.g. if I have a python script, it cannot be broken by a subsequent python upgrade without me being able to roll-back to the earlier profile generation with the known-working script. <mark_weaver>things like /usr/bin/env or even having the shebang refer to some dynamically changing path like /run/current-system defeats the reproducibility and roll-back features, in my mind. <mark_weaver>and, I want to be able to take my scripts with me to another machine as part of my manifest file. <xd1le>mark_weaver: you mean like modify the original script? <civodul>OTOH some people may want to still have a way to do "quick hacks", and /usr/bin/env fills that gap <mark_weaver>xd1le: in an automated fashion, yes, the same way that our build processes do with scripts in packages that we build. <xd1le>mark_weaver: ah but not the original /file/, which is good. <mark_weaver>the existence of /usr/bin/env means that we're going to end up with packages that rely on that, without anyone noticing. <mark_weaver>and then reproducibility and roll-back may no longer work. <civodul>mark_weaver: patch-shebang already replaces "#!/usr/bin/env foo" with "#!/gnu/store/.../bin/foo" <civodul>so packages cannot really rely on it <mark_weaver>civodul: sure, but there are other cases where the package's build system includes a script that generates scripts. <mark_weaver>as things stand now, we generally notice those things and patch the script <mark_weaver>but the more things like this we add, the more likely things like that will go unnoticed. <xd1le>mark_weaver: yeah that's a great catch <mark_weaver>well, that's my take on it, anyway. I worry that compromises like this are a slippery slope, and each step will make it less likely that a /gnu/store/.../bin/foo that works today will necessarily continue to work tomorrow. <xd1le>and thereby defeating the entire purpose of guix, potentially <mark_weaver>bah, it seems that deleting the 'security-updates' jobset on Hydra has resulted in all of the build logs now being inaccessible via the web interface :-( <mark_weaver>MatthewAllan93: do you already have a working GuixSD, and this is for "guix system reconfigure" ? <MatthewAllan93>mark_weaver: this is for guix system reconfigure and for in the future for my netbook :) <mark_weaver>MatthewAllan93: in general, when running "guix system reconfigure config.scm", you needn't worry about it so much. if there's a problem, you can always boot into the previous generation of the system via the GRUB menu. <mark_weaver>it's mainly when doing the first install via "guix system init" that errors can result in a lot of wasted time. <mark_weaver>it's not easy for me to comprehensively look at an OS config looking for possible problems. if you haven't already found that it causes an error, it's not an efficient use of my time, I'm afraid. <MatthewAllan93>ah ok, makes sense. its just because when i do "guix system reconfigure" with that config.scm file. its says end of file in string constant <mark_weaver>okay, knowing the error makes it a *lot* easier to spot the problem. "/home/matthew" is missing the end quote. <mark_weaver>and paste.lisp.org's syntax highlighting also makes it easier to see <xd1le>MatthewAllan93: in fact you can see it in the syntax highlighting of the site <xd1le>and this is another reason why you shouldn't worry /too/ much, syntax <xd1le>errors will be caught before attempting to run anything <MatthewAllan93>ok thanks everybody :), just trying to get use to this distribution. so learning a lot all of the time :) <davexunit>I like being free to try out new system configs that will potentially not work <mark_weaver>MatthewAllan93: I recommend always keeping a known-working backup of your config file, or better yet, put it in a version control system. <MatthewAllan93>mark_weaver: thanks for the advice :), i will be defintely be putting it on notabug very soon :D <paroneayea>btw, as an aside... if it's possible, it might be better in the future to have blogging happen on guile's and guix's sites themselves <paroneayea>I don't know how possible that is, but maybe post-hautntification, it's possible? iirc it's a bit hard sometimes to update the site or something <davexunit>I was thinking that it would be good to scrape savannah <paroneayea>the reason I say this is because the theming on those sites looks really good <paroneayea>and visiting a blogpost is also encouragemnet to explore the rest of the site <paroneayea>exploring savannah is not as useful for getting interested in guile/guix as the homepages are <davexunit>scrape savannah and re-render the post in the nice guix site theme <paroneayea>davexunit: that's possible (though it does lead to two semi-canonical links) <xd1le>MatthewAllan93: yw, glad to see someone from fp trying out guix! <civodul>paroneayea: we could do automatic rendering of the RSS feed and store it on Guix's site <civodul>that's what you had in mind, right? ;-) <paroneayea>civodul: I think that's similar to davexunit's suggestion <paroneayea>civodul: an important thing would be that we'd work on sharing those links, rather than the direct ones <civodul>"[Allan] Day posits that deeper cloud integration may be part of the refocused vision for GNOME", argh <paroneayea>civodul: I've thoguht about blogging about why I'm really worried about free software distributions heading down this direction <civodul>instead, we'll focus on cloud disintegration! <paroneayea>civodul: I thought you were talking about the other GNOME post in there <davexunit>GNOME is making all sorts of really bad decisions <davexunit>does anyone know any of the developers personally? I really like GNOME and it's a shame to see it head down this road <paroneayea>davexunit: I know some people who are pretty well GNOME connected <davexunit>but I feel like if I voiced my concerns it would just sound like one of many post GNOME 3 complainers. <paroneayea>I was a big defender of GNOME 3 when it came out <wingo>i'll just declare gnome 3 to be in the age of decadence again, that should sort it out :P <wingo>i have been trolling for many years now :P <civodul>contrast it with the constant level of satisfaction of ratpoison users over the last decade! <davexunit>if GNOME still had any real connection to GNU, there'd be a chance of convincing them that xdg-app is very flawed and that Guix provides a better way. <davexunit>but GNOME wants to ship its own distro, with its own package manager and graphical package manager frontend <wingo>davexunit: xdg-app has many good things about it tho :) <wingo>respectfully, you haven't looked with an open mind, then <davexunit>this is the old bundling argument, essentially. <wingo>the fit in the mid-term/long-term goals but they are making progress in an area that guix hasn't looked at seriously <davexunit>I don't think that's true. application sandboxing is on my radar, and I think it's on ludo's and mark's too. <davexunit>call-with-container provides the foundation, and now we can experiment with say, sandboxing icecat. <wingo>haha, not while you have X in the loop :P <davexunit>the GNOME folks have hacked on it more, sure. <wingo>yeah and that's what i don't appreciate about the xdg-app negativity, they focused on their thing and fine for them, so what? we'll steal ideas, code, and implementation as we do our own thing <paroneayea>wingo: I think the bigger problem is that this is likely to go down a direction similar to what our situation is with npm <paroneayea>where it could become very difficult to install gnome applications outside of that system, and to package them using traditional distro tooling <wingo>i doubt we will have build-from-source problems <wingo>which is what i understand the npm issue to be <civodul> https://wiki.gnome.org/Projects/SandboxedApps gives two goals: the first one, read with my close mind ;-), equates to "we wanna run Abrobat Reader and Steam and 'apps'", and the second one is in line with what a "guix environment --container"-ish approach can provide <paroneayea>wingo: having spent enough time in the web development world <paroneayea>I'm worried that once these kinds of things get introduced, it becomes easiest to give developers instructions to deploy from bundles of tooling that aren't introspectable or that are really hard to piece apart <paroneayea>wingo: and I say this as someone who runs a big project with precisely these problems :\\ <paroneayea>it's hard to escape what the "ecosystem" encourages. <paroneayea>wingo: I agree that the sandboxing work is great <paroneayea>I hope to see that proceed in a way where guix and gnome / * could work on shared tooling there <MatthewAllan93>hey, just tried that guix reconfigure again. tried installing another program and got "substitute: guix/scripts/substitute.scm:399:10: Throw to key `match-error' with args `("match" "no matching pattern" #<eof>)'. guix package: error: build failed: substituter `substitute' died unexpectedly" and also stuff about the catch. <civodul>MatthewAllan93: could you run "ps aux| grep guix-daemon" and check the version that shows up in the /gnu/store file name? <civodul>sounds like you've downgraded to an old Guix or something <civodul>what does "ls -l ~root/.config/guix/latest" say? <civodul>so, can you: 1) run "sudo rm -rf /var/guix/substitute/cache", and 2) run "guix pull" as root, with HOME=/root? <MatthewAllan93>i did do that before but i think it was because i redid a reconfigure before doing a guix pull again <civodul>"guix pull" creates ~root/.config/guix/latest, if run as root <et8>hello, is it possible to use guixSD with non-free drivers? I have a binary printer driver here that the manufacturer gave me and don't have access to the source <mark_weaver>if you build and run Guix from a git checkout of its source code, you can make arbitrary modifications in a private branch. however, GuixSD as we provide it includes only free software. <mark_weaver>if you have the means, I would suggest acquiring a printer that doesn't require non-free software. <et8>mark_weaver: yeah, unfortunately its difficult to find this kind of printer with drivers for linux at all, let alone non proprietary ones :-( <et8>mark_weaver: also the company I work for purchased the printer, not I. but if this is the case it should be sufficient for me to install guixSD, after all there is only one truly crucial proprietary blob that I need to use <Digit>"you shouldn't worry /too/ much, syntax errors will be caught before attempting to run anything" <- could be more prominent in the docs. ^_^ that first run was scary. i didnt know then. <mark_weaver>avoine: it's possible. I think it's seldom used and probably not extensively tested. could you email bug-guix@gnu.org about it, including the config and error output? <avoine>It's probably just checking if the device is not a string and calling uuid->string if thats the case <jchmrt>I'm on GuixSD and when I run sbcl, it can't find the .core file it needs. I can resolve this by setting the environment variable SBCL_HOME to the directory of the lib directory of the package "/gnu/store/<hash>-sbcl-1.2.8/lib/sbcl/", but this seems quite fragile since this directory would change with each update. Is there a better way to set this environment variable to the correct value? <fps>this is not my login dialog <fps>thank god, i didn't automatically send the pw along, too <taylan>jchmrt: after installing SBCL in a profile, e.g. ~/.guix-profile, you could set SBCL_HOME to $the_profile/lib/sbcl <taylan>I think it was me who packaged SBCL, so I'll take a look why it doesn't work out of the box... <taylan>jchmrt: when I run /gnu/store/<hash>-sbcl-1.2.8/bin/sbcl it starts up fine <jchmrt>taylan: how exactly would i set $the_profile/lib/sbcl? When I try export SBCL_HOME=$the_profile/lib/sbcl, it just gets set to /lib/sbcl <jchmrt>(I'm kindof new to guix, so excuse my stupid questions) <jchmrt>taylan: maybe I missed a step in installing sbcl, I just ran guix package -i sbcl and then tried to run it <taylan>jchmrt: $the_profile was meant to be meta-syntactic :) <taylan>e.g. SBCL_HOME=$HOME/.guix-profile/lib/sbcl if you install SBCL in your user's guix profile, or SBCL_HOME=/run/current-system/profile/lib/sbcl if you use a system-installed SBCL <taylan>jchmrt: hmm, when I package -i sbcl and run it, it also fires up fine into the REPL. are you trying to start it in a specific way, or is SBCL_HOME set to something else, maybe the empty string? <taylan>"env | grep SBCL" should tell whether anything of that sort is set <jchmrt>taylan: oh, that's what you mean of course. Thanks adding that to .profile works :) <taylan>jchmrt: I think it should also work without though. can you confirm that the bug is reproducible when you run "unset SBCL_HOME" in the shell prior to running "sbcl"? <jchmrt>turns out, there was already one set, with the total directory ("/run/guix/<hash>-sbcl-1.2.8/lib/sbcl") <jchmrt>but for some reason using that one it doesnt work <jchmrt>maybe it's because i have installed it multiple times or upgraded it or something? <jchmrt>oh, i am sorry, i mistyped that direectory <taylan>no problem. ok then, it was probably indeed due to an update, since the hash changes. <jchmrt>Is there any way to reload that environment variable? <taylan>into which process? (every unix process has its own environment, though normally it's inherited from the parent process) <taylan>if into a running bash session, then "source ~/.profile" might do it (though ~/.profile is just code and can theoretically do anything) <jchmrt>hmm okay, it's running now and I assume the proper hash will be set upon the next restart. Thanks for your help! <taylan>I have some horrible horrible hacks on my system to allow me to have an M-x reload-environment command in Emacs. one of the annoying things in unix... ***dmcp_ is now known as dmcp
<bavier>currently, the links point to master, so the line numbers may become out of sync if there have been changes since the page was generated <davexunit>taylan, jchmrt: perhaps SBCL_HOME should be added to sbcl's native search paths? <taylan>davexunit: it actually works without setting it <jchmrt>yeah, I just think I did something wrong in installing it, because the variable is actually set, but it's set to the lib of another instance of the package with a different hash <davexunit>civodul: is "dmd" a typo in gnu/services/base.scm:1139? <civodul>davexunit: i don't see "dmd" on that line <davexunit>I'm sort-of poking at something when I have a spare minute