<davexunit>ACTION deleted the 40 previous generations of his profile <sneek>davexunit, you have 1 message. <xentrac>wgreenhouse: I'm glad it's helpful! but you should *test your backups* also so that you aren't left relying on the correctness of random snippets of irc :) <wgreenhouse>xentrac: yeah, I do :) but I had been (separately) making btrfs snapshots and rdiff-backup'ing that entire filesystem in its "live" unsnapshotted state <wgreenhouse>I realized that that was probably a bit riskier than taking the snapshot and copying that, especially if e.g. mail is arriving and getting indexed meanwhile <xentrac>hmm, I guess it's hard to make sure your backup procedure is stress-tested <xentrac>unless you're using a system that allows you to reproduce the system configuration on another machine (maybe a virtual one) and load-test it without fear of wasting a lot of time trying to get the configurations to match <lfam>Did coreutils-8.24 not get fixed before core-updates was merged? guix pull still gets me: builder for `/gnu/store/gw9idfh8r5pnyjg9rwvq22bik33ncb6w-coreutils-8.24' failed previously (cached) <lfam>I'm talking about armhf, btw <mark_weaver>my guess is that your build failed because your kernel lacks a needed feature that caused coreutils' test suite to fail <mark_weaver>so you'll need to clear the cache entry that remembered that the build failed <mark_weaver>sneek: later ask civodul: lfam needs to know how to clear the cache of failed builds. he enabled the caching of failed builds in his guix-daemon, and then had a build fail and doesn't know how to recover. <mark_weaver>sneek: later tell civodul: the failed build was coreutils on armhf, and I think it failed because he was missing a needed feature in his kernel <lfam>mark_weaver: I'm not sure how the caching works, obviously. But I ran guix gc and now I am downloading substitutes. So maybe it will build now that that test is disabled. I'm sick of this stupid vendor kernel, though. <mark_weaver>lfam: it looks like the failure cache is stored in the sqlite database <mark_weaver>guix-daemon has an RPC to clear failed paths, but it looks like we don't currently offer an easy way to request that <mark_weaver>for now, it's probably a bad idea to enable this caching. <rekado>This was a hard update as it would fail in the middle for LOCPATH-related issues. <rekado>after the update I couldn't open new shells, because they would just crash silently in xfce4-terminal. <rekado>it was okay in Emacs, as the process died but the buffer remained. <rekado>so I unset LOCPATH and moved on. <rekado>but I also had to reconfigure the system to be sure not to have any running software that depended on a different version of the locale data. <rekado>haven't upgraded anything on the cluster yet, but I'm a little worried about this. <rekado>Here's another thing that repeatedly annoyed me whenever I upgrade my profile: "python-2" and "python" both provide packages named "python", making it difficult to upgrade "python-2" to the latest 2.x. <rekado>I forgot to exclude "python-2" from the updates, so now I have two entries of "python 3.x" in my profile. <rekado>since we provide separate modules for python 2 and python 3, would it not be a good idea to let "python-2" provide a package named "python2", so that users could easily upgrade to the latest 2.x release? <Steap>oh yeah, I can't easily install both Python 2 and 3 iirc <rekado>you can do "guix package -i python-2.x python", but upgrades are a little more difficult. <mark_weaver>rekado: regarding "python-2", this is not just a problem for python but for _any_ package where users deliberately want an older version. I have this problem for many other packages, including gcc, clang, gnupg, and texinfo. <mark_weaver>this is really just a limitation in our "upgrade" command. I don't think we should move the version number into the package name to work around that limitation. <mark_weaver>rather, I think we should remember when you ask for e.g. "python-2" or "gcc-4.9" and record that information in the manifest so that upgrades will take that into account <rekado>I think that python is a little special, because we cater for both major versions, providing modules for both. <rekado>but sure, if the upgrade command could be made to perform a conservative upgrade, that would be nice too. <mark_weaver>I should also mention that we have a superior approach already available which avoids this problem entirely: "guix package --manifest" <mark_weaver>although it would be very helpful to have a way to create a file suitable for use with that command, given an existing profile. <mark_weaver>I recently converted to that approach, but creating the file was rather tedious, mainly because of having to look up all of the module names that I needed to import. <rekado>I actually thought that ~/.guix-profile/manifest would be suitable, but turns out it is not. <rekado>ACTION tries to cross-compile icedtea for arm+mips on x86_64 to figure out why the build fails. ***ifur_ is now known as ifur
<sneek>civodul, you have 2 messages. <sneek>civodul, mark_weaver says: lfam needs to know how to clear the cache of failed builds. he enabled the caching of failed builds in his guix-daemon, and then had a build fail and doesn't know how to recover. <sneek>civodul, mark_weaver says: the failed build was coreutils on armhf, and I think it failed because he was missing a needed feature in his kernel <civodul>i think we have no RPC to do that currently <mark_weaver>I've since discovered that there's an RPC in guix-daemon to clear the cache <civodul>and then a command-line option in 'guix gc' probably <civodul>we need the client stub for query-failed-paths and clear-failed-paths, and the corresponding command-line options <civodul>i can look into it if you don't beat me at it <civodul>(that won't be until tonight at best) <mark_weaver>I don't think there's a big rush. in the meantime, we could help lfam manually clear the entries from his sqlite database. <mark_weaver>it's probably not a great idea for ordinary users to enable the build failure cache anyway, given the number of non-deterministic test failures we have currently. also, I wonder if download failures by the substituter would be cached as failures. if so, that would be a problem <iyzsong>hydra.gnu.org is very slow for me these days, I'm happy with 'guix publish' from my VPS now. but, how to change the default substitute server? <civodul>this is because clients overwrite the daemon's settings <ennoausberlin>Hello. I tried to install guix sd besides a win 8/10 system. guix installs fine but mbr is rewritten and i can not find grub-update to fix it <civodul>ennoausberlin: try "guix package -i grub" to install it <alezost>ennoausberlin: mbr will be rewritten every time you use "guix system" unless you also specify "--no-grub" option <sneek>alezost, you have 1 message. <sneek>alezost, civodul says: it Would Be Nice to have some sort of org-babel integration; like for R source it would automatically to 'guix environment --ad-hoc r -E R' to run the thing <alezost>civodul: it would, but currently I'm not interested in it, sorry :-( <alezost>ennoausberlin: I think you installed grub as user, and are trying to use it as root <alezost>ennoausberlin: wait a second, our grub doesn't have grub-update, what is it? <alezost>ennoausberlin: are there any other grub commands? try grub-TAB <iyzsong>ennoausberlin: I think you can try 'grub-mkconfig', it will output a grub config to stdout. If it look ok, you can save it as '/boot/grub/grub.cfg'. <ennoausberlin>@davexunit: I add it now. But grub-update isnt there. Other commands are. Just a moment. Baby is crying <alezost>ennoausberlin: yeah, there is no "grub-update" (at least in our grub) <xentrac>wgreenhouse: it would be advertising if we were on a channel other than #guix :) <wgreenhouse>xentrac: well it's like the e.g. the ad for Mr. Robot while I'm watching Mr. Robot :) <wgreenhouse>but anyway, in all honesty you made a good point. I should consider keeping a second (virtual or live) system around to try restoring from my backups <xentrac>in theory Guix should make it easy to do exactly that <xentrac>and if it doesn't, maybe you should write down the specific obstacles to it so we can go about removing them <wgreenhouse>xentrac: continuously updating #otherbox's profile/system configuration could even be part of the backup job <xentrac>PITR for your system configuration :) <xentrac>Guix doesn't support asynchronous notification on profile changes, does it? <wgreenhouse>xentrac: I was imaginging something like an after-guix-package-hook <civodul>wgreenhouse: what would the hook or notifications be used for? <wgreenhouse>civodul: acting on creation of the new profile; for example in this case telling a "paired" system that it should update itself <wgreenhouse>civodul: xentrac and I were discussing a situation where guixbox2 exactly emulates guixbox1, for easier testing of backups for example <civodul>the Right Thing here would/will be "guixops", which davexunit started in the wip-deploy branch <civodul>where basically you would provide an OS configuration and deploy it on several machines <civodul>NixOS has this in the form of the "NixOps" tool <civodul>paroneayea is also going to work on "guixops" presumably <paroneayea>civodul: wgreenhouse: yes, I should be shifting my focus to that in about 2 weeks. <ennoausberlin>I added a Win 10 entry to grub.cfg and grub-install did the rest. Thanks for the hints <paroneayea>civodul: today I'm working on my guix talk for wednesday....! <paroneayea>davexunit: mark_weaver: oh man, if it weren't coming up so fast deadline-wise, we should totally get some guix stickers and hand them out at fsf 30th <civodul>paroneayea: in case it's useful to you, feel free to borrow stuff from guix-maintenance.git <civodul>paroneayea: it's the repo where we store random things, notably slides of talks <civodul>i should have mentioned it before, i thought you already knew that one <paroneayea>civodul: no worries, I'm late getting started on the talk anyway ;) <paroneayea>civodul: damn, some complicated graph drawing markup in guix-fosdem-2015.tex :) <civodul>"complicated" is a polite way of saying "ugly" ;-) <civodul>dirty TikZ hacks done not long enough before a talk <davexunit>maybe I can go and talk some sense into these people ;) <davexunit>"microservices", "cloud", "best practices". this website has 'em all. <davexunit>I'll probably get stuck working with this damn thing in 6 months. <codemac>yo - anyone ever get problems with match syntax? <codemac>source expression failed to match any pattern in form (_ . dir) <codemac>I'm trying to set an env CC variable for a non-autoconf package, and my copy-pasta skills are weak <davexunit>codemac: that error means that 'match' did not find any matching pattern <mark_weaver>codemac: probably you just want to add "CC=gcc" to #:make-flags <mark_weaver>and remove that custom phase, as well as 'gcc' from inputs which is already included implicitly <mark_weaver>so, in the arguments list, #:make-flags (list "CC=gcc") <mark_weaver>but surely you'll need to tell it where to install things. normally that's done by passing --prefix= to configure, but without a configure phase that can't happen. <mark_weaver>codemac: the reason 'match' didn't work is because you didn't arrange to import (ice-9 match) in the build environment, but anyway this is not a good way to set CC anyway. <mark_weaver>when 'match' is not imported, it is assumed to be a normal procedure, and so (((_ . dir) ...) dir) is one of its arguments, which is itself a procedure call, and ultimately (_ . dir) is an expression that is not valid scheme code, hence the error. <mark_weaver>well, (_ . dir) is a position where an expression is expected, but it's not a valid scheme expression, is what I meant to write. ***davi_ is now known as Guest18017
<codemac>mark_weaver: Ahh yes, I forget that importing a module at the top of a package != available in build rules. It makes sense but I keep forgetting. And thanks for the pointer on the #:make-flags :) <paroneayea>davexunit: counteracting that kind of direction for application packaging means we're going to have to get gnome nicely working to prove it's an alternative... at least there seems to be progress there <paroneayea>looks like vagrant is moving into packaging territory <civodul>"Otto automatically builds development environments without any configuration" <civodul>sounds like "Otto guess what's best for you!" <davexunit>they're essentially building a package manager, and I find it extremely unlikely that they will do it right. <davexunit>and when that doesn't work there's an "Appfile", which consists of some woefully inadequate DSL. <civodul>isn't it a case where the company needs a new product anyway because they've been losing market share? <civodul>we were not used to it in the free software world, but i think that's roughly what's happening <davexunit>their other products seem to have a lot of users <davexunit>but AFAIK people weren't using their tools in production environments <davexunit>they were using things like Vagrant for development <civodul>i guess more people have been using Docker for those things <davexunit>Vagrant can optionally use Docker these days. <davexunit>I don't find their tools particularly pleasant. <civodul>yes but there's a bit of functionality overlap IIUC <davexunit>because they're all erected on a shakey foundation <davexunit>Docker gets weird when you realize that it is a package manager in some sense <davexunit>and I had the same weird feeling when I read that Otto automatically installs other Hashicorp tools. <davexunit>davexunit's tenth rule applies in both cases <paroneayea>I guess its indicative in how much I see "userops" from a davexunit's 10th rule perspective :) <paroneayea>I didn't start out looking at userops type stuff from a guix perspective though <davexunit>Snappy and Project Atomic are two other such examples. <paroneayea>that term, and the problems encompassed by it, came out of a talk I gave at FOSDEM about the stresses of deploying free network services <davexunit>they have some subset of Guix/Nix features, but miss other qualities because they're built on the wrong platform. <paroneayea>but I eventually came to realize that the solutions I intended to build would reinvent guix, so I guess it might be treu <paroneayea>that that blogpost is pretty oriented towards the solutions I want to build on top of guix <paroneayea>still there are things in there that guix does not provide yet... we definitely don't have any helpers for "recoverable data" and etc <civodul>the OS config interface is a different story than the package management interface though <civodul>a temptation is to "generate" the UI using introspection <davexunit>Guix has a robust low-level language, we just need to build more higher-level abstraction layers. <civodul>similar to M-x customize and the like <paroneayea>hopeuflly less ugly than M-x customize though :) <davexunit>I'm not sold on graphical interfaces because I don't how to design such interfaces that encourage the user to hack the system. <davexunit>since no one really designs GUIs with that in mind, they typically want to hide that as much as possible. <paroneayea>davexunit: I still say that Blender is a great example <paroneayea>anyway, I'm sold on GUIs because I think network freedom will require serving users who aren't programmers (but maybe eventually will become so) <paroneayea>I'd like to have GUIs as a programming funnel :) <davexunit>Eben Moglen describes GUIs as things that lower the dialogue with the computer to "point and grunt" <davexunit>I wrote guix-web, so obviously I think a GUI has a purpose, but a GUI will always be limiting. <paroneayea>still, there's a good reason to not be condescending towards GUI users <mark_weaver>yeah, he compared using a mouse as "pointing and grunting" and said that when the way we communicate with computers is reduced to pointing and grunting, neither they nor we will grow as we should <paroneayea>Mairin Duffy drew a nice comic where she showed some users wanting to get involved, and they were basically snarked out for not being "technical enough", and so they walk over to the Apple store where sales clerks welcome them with open arms <paroneayea>and I think that's true, GUIs might not be optimal, but if you make GUI users feel unwelcome <paroneayea>you can't be surprised when they go somewhere else <paroneayea>there's 0 risk in Guix land that we'll lose the solid foundations at this point I think :) <davexunit>the GUI needs to serve basic needs, but also invite the user to really hack the system. <paroneayea>which is one of the things that others said was not necessary :) <davexunit>GUIs just don't compose like CLIs and s-expressions do. <paroneayea>I was surprised to see how nice GUIs got on lisp machines though <davexunit>so in our case, unlike most people writing GUIs, we'd want the user to outgrow it. <paroneayea>and how much symbolics machines, for as problematic as that company was from a free software perspective, did awesome stuff in terms of pioneering in artist tools <paroneayea>some people love those fishing video games for some reason :) <paroneayea>davexunit: am I getting my metaphors confused? I think the answer is now to package Free Sly Bass Fisher Pro for Guix <davexunit>paroneayea: ooh a fishing game for sly. good idea! <paroneayea>davexunit: double joke: a tutorial on learning Sly <davexunit>triple joke: a tutorial on learning Sly that steals your passwords