IRC channel logs
2016-10-14.log
back to list of logs
<catern>hmm, can Linux bind mounts cross filesystem namespaces/chroots? <bavier>reepca: the expected files are still in the store? <catern>this is a quite different question I know and seems irrelevant :) I just have a thought that chroot/fs namespace might be useful for this, somehow... <catern>mark_weaver: and I'd like some way that (somehow...) preserves the unprivileged-user-access of guix, which the directly-mutate-the-store approach you just described doesn't preserve... <mark_weaver>catern: it could be done with user namespaces, if those are enabled in your kernel. <reepca>ucode5.fw, b0g0initvals5.fw, and b0g0bsinitvals5.fw are in the store on the system in ...-openfwwf-firmware-5.2/lib/firmware/b43/ <bavier>reepca: should be alright then. the store is read-only <reepca>b43-phy0 ERROR: Firmware file "b43-open/ucode5.fw" not found <reepca>^ found that in /var/log/messages <mark_weaver>reepca: you need to add it to the 'firmware' field of your OS configuration. it does not suffice to add it to 'packages' <reepca>I did, it says (firmware (cons openfwwf-firmware %base-firmware)) in my config.scm <mark_weaver>something like (firmware (cons openfwwf-firmware %base-firmware)) <bavier>reepca: I wonder if the installation dir needs to be adjusted <bavier>reepca: you're the first to really try this ;) <mark_weaver>reepca: where is the ucode5.fw file located in your store? <bavier>reepca: in the package definition of openfwwf-firmware, change the "/lib/firmware/b43" to "/lib/firmware/b43-open" <bavier>it needs to correspond to the location the kernel is looking for <reepca>not including the hash, /gnu/store/...-openfwwf-firmware-5.2/lib/firmware/b43/ucode5.fw <reepca>Am I gonna have to recompile guix to make this little name change? <bavier>reepca: just the package and system <bavier>well, depends on where your guix is, I guess <reepca>wondering how exactly to do that... so I would put the modified firmware.scm in GUIX_PACKAGE_PATH and run guix system reconfigure? <reepca>... which reminds me that I unfortunately forgot to put my config.scm on the flash drive after installing to it. <reepca>sigh, time to reformat the other flash drive and manually mount/unmount it <sapientech>hi all, is there a reason ghc-stack is not a part of guix? is it because guix itself can subsitite for stack? <bavier>reepca: you can also copy a skeleton from /etc/configuration/*.scm on the installation image <bavier>reepca: assuming you didn't customize too much <reepca>just a bit, that should make it doable, but where am I going to find the patched firmware.scm? <reepca>where is that stuff kept anyway? <bavier>reepca: 'guix edit openfwwf-firmware' might work <reepca>"guix edit: error: openfwwf-firmware: unknown package" <bavier>sapientech: well, no one's packaged it yet ;). and yes, guix itself should substitute for many of stack's features <bavier>reepca: I need to go afk. good luck! <sapientech>bavier: sweet thanks for the response. Imma let guix do most of the work for now, and if i see a major need for stack, expect a patch :) <reepca>bavier: /etc/configuration/ examples are only included with the installer image, not with the init'ed system :/ <ng0>so node, at least locally, fails to build.. <ng0>are there fixes in core-updates? <reepca>I just went ahead and typed out what I had on my desktop system, seemed faster than installing git, cloning, and modifying. Also seemed faster than looking up how to download just one file from a git repository. <reepca>now I just need to find where firmware.scm is on this system... <reepca>according to find it isn't in the store <mark_weaver>it should be in /gnu/store/*-guix-*/share/guile/site/2.0/gnu/packages/firmware.scm <mark_weaver>but fwiw, I would recommend downloading our git repo and building it, so that you can more easily and flexibly play with guix <reepca>that firmware.scm doesn't have the patch applied for some reason <mark_weaver>it's probably old. have you run 'guix pull' or equivalent? <mark_weaver>if not, you're probably running 0.11.0, with all the package descriptions as they were at the time of release. <reepca>I haven't run guix pull on the system since installing it about an hour ago, but I init'ed it from a system freshly compiled with the patch <mark_weaver>reepca: the issue you're facing is that every version of 'guix' installs an older version of itself, unfortunately. that's because 'guix' contains the sha256 hash of the source code of every package in it. and we cannot build a source tree of 'guix' that includes the hash of itself. <mark_weaver>so, if you run 'guix system init' with guix version B, the 'guix' installed on that system will necessarily be older than B <mark_weaver>in fact, it will be the version of 'guix' bound to the 'guix-devel' variable in gnu/packages/package-management.scm <mark_weaver>which at present is commit 4420940f20a2f36f29519f686bca7b85be6be5c9 <mark_weaver>in practice, this doesn't matter, but you need to run 'guix pull' or similar anyway, to get security updates. <mark_weaver>and if you build and run guix from a git checkout, as I do, then this issue doesn't arise in practice. <mark_weaver>and I highly recommend this setup, even though it requires some initial time investment. <catern>mark_weaver: shall I attribute your proposed hack to you? :) <reepca>I'd probably switch to that setup after I've learned enough to use guix as my main system (I read somewhere that guix doesn't do dual-booting well?) and can have it on my more-reliable laptop hard drive. <mark_weaver>catern: (although to be clear, I'm not proposing to add support for this to guix itself) <mark_weaver>catern: it's just my best idea so far of how to allow you to hack it without getting burnt :) <catern>i'm just including it in a list of currently available solutions <catern>along with LD_LIBRARY_PATH and "just rebuild" and "just graft" <reepca>but the time investment doesn't seem really worth it when incorrect syntax in herd could nuke my system like it did a couple hours ago <catern>mark_weaver: is there a reason you'd use bind-mounting rather than just in-place mutation? <mark_weaver>catern: yes, it's safer. it doesn't actually mutate the store, it only mutates our view of it right now. <mark_weaver>and hopefully builds performed by guix itself would never use the hacked overlay (although I'm not sure) <mark_weaver>reepca: if you're looking for a polished, bug-free system, then GuixSD is not for you. <reepca>that wasn't meant to point out the issue with guixsd, that was meant to point out the issue with having a system on a flash drive <mark_weaver>but if our vision appeals to you, then we could use help getting there. <mark_weaver>reepca: what issue with having a system on a flash drive? I'm lost. <reepca>Okay maybe I'm just really poorly-educated about storage mechanisms, but I thought that flash drives were less stable than hard drives? <reepca>And that a kernel panic would hit them harder by the same reasoning <reepca>anyway, I just meant to say that my excuse for not cloning the git repository as of now is that my guix sytem doesn't have much permanence yet. No offense intended. <catern>mark_weaver: I just want to check that this suggestion isn't totally misunderstanding of Guix: We could completely change the direction of Guix and instead of baking-in paths with hashes, we could reference hash-less directories and use bind-mounts before running an application to construct a root filesystem which points to the right versions. <catern>not suggesting that as an actually solution <catern>(oh sorry I didn't notice you said you were going to concentrate before pasting that) <mark_weaver>catern: no, that can't work because in general a single UNIX process is built from many libraries, and it can't have all of those different views of the filesystem at once. <mark_weaver>I don't know of any system that does better in that way <catern>well... let's see. libraries are in-process so they should be able to function in the same namespace. the place where you might need to cross namespaces is when you invoke another binary. when you invoke another binary, can't you just set up another namespace? <catern>sorry I really don't want to keep you from the CVE - no need to answer :) <mark_weaver>I've thought about that, and just trust me, it would be a mess. <mark_weaver>even if you somehow changed namespaces every time control flow passed from one library to another within an executable (which would be massively expensive), you'd end up with weirdnesses like this: when you try to 'ls' a directory that's in a namespace that's different for everyone, it would be anyone's guess which view of showed you. <catern>i had one idea for briding between namespaces: you could (with some hacks I have ideas on) separate the /root/filesystem/referenced/with/absolute/paths from the current/working/directory/referenced/with/relative/paths <mark_weaver>it might show you what the system wants the 'ls' code to see, namely what it was meant to link to, etc. <catern>since programs generally look up resources in absolute path directories, and you can pass relative paths for interactive things <reepca>question... if I have a file firmware.scm in, say, /root/, and I pass --load-path=/root/ to guix system reconfigure, and in my config.scm I have (use-package-modules firmware), should it use the firmware.scm in /root/ or the one it was built with? <mark_weaver>anyway, this would be a fundamentally different design from guix, from the ground up. if you want to play around in that space, feel free, but I think you'll find it's a rats nest. <mark_weaver>reepca: you need to pass --load-path=DIR where $DIR/gnu/packages/firmware.scm contains your modified version. and $DIR should not contain any other .scm files. <mark_weaver>so using /root/ is a bad idea, better make a dedicated directory for this. <mark_weaver>e.g. create /root/guix-modules/gnu/packages/firmware.scm and pass --load-path=/root/guix-modules <mark_weaver>(in general, a module that contains (define-module (foo bar baz) ...) will be looked for in $DIR/foo/bar/baz.scm where DIR is in Guile's load path) <mark_weaver>and (use-packages-modules foo) loads the module named (gnu packages foo) <reepca>it doesn't seem to be working... I have /root/guix-modules/gnu/packages/firmware.scm, and I'm running guix system reconfigure --load-path=/root/guix-modules /etc/config.scm, wheree config.scm has (use-package-modules wm ratpoison certs firmware), and yet it's saying that it can't find a package defined in the firmware.scm given in the load-path <reepca>interesting, I set GUIX_PACKAGE_PATH to the same thing (/root/guix-modules) and now it works <mark_weaver>hmm, I guess maybe --load-path is not honored by 'guix system' <mark_weaver>reepca: you have a knack for finding bugs in guix :) <mark_weaver>emailing bug-guix@gnu.org about them would be appreciated <reepca>I may waste my life away, but by the end of it I'll have the best system in existence <reepca>reading through 7.5 in the manual it only specifically says that GUIX_PACKAGE_PATH is honored by all user interfaces, is --load-path also supposed to be? <mark_weaver>it's a "common build option", so it probably should affect "guix system reconfigure". <mark_weaver>common build options are supposed to be honored only by a subset of our commands, but I guess that's one of them. <ng0>nothing is wasted if it helps some cause.. in this case, find serious bugs in guix like the shepherd/grub one <reepca>Hm, so if I init'ed onto this flash drive from a system with a patch applied, and then I reconfigured on that system without explicitly including the patch, it would be reverted, right? <reepca>In which case I should figure out how to modify service information without recompiling (if that's possible), because ntpd freaks out without a -g flag on my laptop for some reason <reepca>bavier: I finally got it figured out and got the system reconfigured with the directory b43 renamed to b43-open in the patched firmware.scm, but /var/log/messages has this to say about my latest boot: "b43 ssb0:0: Direct firmware load for /*(DEBLOBBED)*/ failed with error -2". <reepca>I'll let you think about it while I go eat supper <reepca>I think it's free, I can't say I've examined it thoroughly, I'm just testing for bavier <reepca>But my intuition says that "openfwwf" sounds like it has a good chance of being free, though "librefwwf" would have an even higher chance in my mind <reepca>ACTION got back 15 minutes ago but forgot to mention it <mark_weaver>reepca: I would ask on #linux-libre about that DEBLOBBED message <mark_weaver>it may be that their deblobbing scripts need a whitelist entry, or something. <lfam>Maybe it's out of date but at least it might give you hints of what to check to see if it's possible to use your wifi card with free software <mark_weaver>since gnewsense is a FSDG-compliant distro, that bodes well <lfam>mark_weaver: What does the comment mean in your recent graphicsmagick update? "(let ((changeset "56c8cae") ; 3e01b" <lfam>Also, thank you for doing all those updates! <mark_weaver>it was the remaining digits of the changeset id, in case I needed more to disambiguate. I didn't actually mean to leave it there. oops :) <lfam>Ah! Well, no harm in it being there <mark_weaver>I looked into just cherry-picking the CVE-relevant commits, but there were a whole bunch of fixes in there that looked security-relevant. <mark_weaver>my other goof was a commit summary line that started with "git:" instead of "gnu:" :-/ <mark_weaver>I'm currently struggling with some critical bash CVEs <mark_weaver>the difficulty being to use grafts, while avoiding a full rebuild and dealing with all the many variants of 'bash' used in various places. <mark_weaver>some of those, e.g. 'bash-final' in commencement.scm, require inputs that have been GC'd from hydra. <lfam>I notice the patch bash43-048 in the Bash patches repo. I hadn't heard of that bug before <mark_weaver>both are fixed in 4.4, so at least core-updates is good <lfam>I had read the disclosure of CVE-2016-7543 but I forgot about it :/ I've been busier at work these past few weeks. In the future I'll ping guix-devel when I don't think I can do something quickly enough so that I don't forget about it again <mark_weaver>my aim is for my system to avoid any references to the old bash, and that's proving to be tedious <lfam>I have to admit, the prospect of grafting bash is intimidating. I don't think I know all the different bash packages we have <lfam>If you think I can help you, please let me know <reepca>I got this message building from git: "ERROR: Missing interface for module (charting)", but it seems to be nonfatal. Wonder what's up with that. <reepca>I'm having a problem reconfiguring the system using ./pre-inst-env, because pre-inst-env refuses to look at GUIX_PACKAGE_PATH and it doesn't listen to --load-path, but I need it to keep the patched firmware.scm when I reconfigure... <reepca>that works even after I've compiled, right? <reepca>ah, but when there's just one changed file, make doesn't take very long I guess <mark_weaver>it's good to run "make" after modifying things, but most of the time it will work anyway <mark_weaver>guile will notice that the *.go is older than the *.scm <reepca>not when I ran guix system reconfigure after replacing gnu/packages/firmware.scm with the patched version <reepca>but it did notice it when running make <mark_weaver>did you put ./pre-inst-env before "guix system reconfigure" ? <reepca>I tried running ./pre-inst-env guix system reconfigure /etc/config.scm and it complained that it couldn't find openfwwf-firmware <reepca>just one quick question, does the path to the patch in make-linux-libre have to be absolute? <reepca>or can I just give the name of the file? <mark_weaver>it should be something like (patches (list %boot-logo-patch (search-patch "foo.patch"))) <mark_weaver>I'm working on grafting 'bash' in master for CVE-2016-0634 and CVE-2016-7543, and am having difficulty purging all of the run-time references to the old bash. <reepca>guix system reconfigure is *still* running... I hope we manage to fix this without having to recompile the kernel again. <mark_weaver>civodul: another issue is that (package (inherit p) <overrides> ...) does not apply the same overrides to the 'replacement' field, if any, so I felt the need to add a 'package/inherit' macro for use in several places to handle grafts properly for bash. <mark_weaver>(package/inherit p overrides ...) expands to (let loop ((p p)) (package (inherit p) overrides ... (replacement (and=> (package-replacement p) loop)))) <mark_weaver>but I've hit two grafting bugs: (1) glib:bin is not getting replaced by the graft of 'gnome-session' <mark_weaver>so we end up with the grafted 'gnome-session' referencing an ungrafted 'glib:bin' which itself references a bunch of ungrafted stuff including the old buggy bash. <mark_weaver>and (2) in geiser and emacs-dash, the mapping passed to the grafting includes two entries with the same key: the same old 'bash' store item being mapped to two different outputs: one is a 'bash' with its inputs replaced but with the old 'bash' not the updated one. <mark_weaver>but CVE-2016-7543 seems to me severe enough that I feel it important to avoid it *ever* running <mark_weaver>to be honest, I haven't looked very closely at either of them. <mark_weaver>I've been focused on how to get the grafting to work <civodul>ok, let me reread what you wrote :-) <civodul>could you paste your preliminary patch somewhere? <civodul>and how you checked whether references to the old bash are retained? <mark_weaver>yes, I have been unable to purge all references to the old bash <civodul>re package/inherit, i see what you mean, but when is it necessary? <mark_weaver>it's needed for bash-minimal and static-bash, and in a few one-off 'inherit's in commencement.scm <mark_weaver>when I grafted 'ghostscript' the other day, I later noticed that 'ghostscript/x' was replaced with a non-x ghostscript <mark_weaver>if you have a better suggestion, that would be welcome. <mark_weaver>I don't see how to sanely make the generic 'inherit' do the right thing here. <civodul>if we need something more sophisticated, 'package/inherit' sounds like the right approach to me <efraim>I'm away from my computer right now, do we have any patches applied against freeimage? It popped up on the Debian security tracker <civodul>efraim: you're not away from your computer :-) <reepca>civodul: I dunno, he could have set a timer to send that message <civodul>efraim: we have "freeimage-CVE-2015-0852.patch", which is prolly not the one you want <efraim>Yeah but I don't have a git clone on my phone (yet) and I haven't installed an ssh client <reepca>I mean, technically a phone *could* be implemented 100% in hardware... you can only really classify it as a general-purpose "computer" when you try to change its function. Which actually seems pretty hard for phones as far as I know. <civodul>mark_weaver: i can give the Bash thing a try while you sleep <reepca>I need to sleep... hopefully guix system reconfigure will be finished by the time I'm awake <civodul>reepca: the immobile phone i have is indeed implemented in hardware <civodul>funny that it's becoming the exception :-) <civodul>reepca: is it building lots of things? <mark_weaver>civodul: one important question is this: why does the graft for 'gnome-session' fail to replace its glib:bin input with the grafted one? <reepca>civodul: yes. It's compiling linux-libre with a small patch to test some stuff. On a slow flash drive. That has very irregular and inexplicably long latencies. With an old core 2 duo cpu. <civodul>in other news magit-svn no longer works <civodul>mark_weaver: BTW gnome-session refers to the ungrafted glib:bin and also ungrafted glib:out <mark_weaver>you're welcome! thanks for taking the baton, and happy hacking! <efraim>so i'm not sure about cve-2015-3885, but debian has a patch for cve-2016-5684 <efraim>also, debian lists freeimage building for all architectures, so I'd like to remove the 'no-mips' supported systems flag <efraim>they also have a massive patch to remove bundled libs <thomasd>is there a convenient way to prevent store items from getting gc'ed, other than installing them in a user's profile? <thomasd>(in my case: dependencies of a package I'm working on, which I don't want to have installed in my profile, but would like to keep around after running guix gc) <civodul>i was going to suggest --gc-keep-outputs and --gc-keep-derivations <janneke>i was going to suggest guix package -p ~/.config/guix/my-wip-package install ... <civodul>thomasd, wherever you are, be sure that a solution exists <amz3`>isn't also possible to install the package in a custom profile? <civodul>amz3`: yes, that's what janneke proposes <jmd>For a nfs export service: Should we let the user make his own /etc/exports in the tradiditional way, or should we have him put a list of exports in /etc/config.scm ? <rekado>a list of exports in the OS configuration is better <rekado>we do the same for udev rules and other things that are normally found in /etc <jmd>I can envisage that for a large, complex deployment a sysadmin would want to split his /etc/config.scm over lots of files. <jmd>I used the indefinite (singular) article in my sentence (a sysadmin). So s/his/their/ would also require s/a sysadmin/the sysadmins/ in order to keep the grammar consistent. <jmd>Most linguists consider singular they to be incorrect use of english. <wingo>certainly some linguist do think that. my point was not to insist on grammar but rather to nudge us towards inclusiveness :) if you personally don't like singular they, fine, "he or she" / "his or hers" etc is not bad. but i think in guix we want to make an environment in which people of diverse backgrounds feel welcome, so we should avoid referring to our users with masculine pronouns. that's all :) <wingo>back to regularly scheduled complaints about builds not working :) <thomasd>system crash :/ It seems that inside a guix -env, make -j doesn't respect the number of cores <wingo>make -j never respects the number of cores <wingo>it's an amazing "feature" of make :P <wingo>guix already uses parallelism when you "make" in guix <jmd>wingo: ok. "he or she" then. <jmd>(Just yesterday, rms deleted a exactly those words from a draft I wrote) <thomasd>I wonder how people work on packages, when they need to patch stuff. <jmd>thomasd: If they are small patches we can use substitute* <thomasd>i mean, when working on the patches and figuring out what's needed to get it to build properly <thomasd>I usually put the tarball contents in a git repository, <jmd>otherwise one can declare a patch as part of the source. <thomasd>then I guix environment "my-wip-package" to get all the dependencies, <thomasd>and then I hammer the source/build system until it compiles without errors. <thomasd>I wonder if there's a more efficient approach :) <thomasd>are there any blog posts where other people discuss their workflow? <jmd>I'm sure there are plenty. Personally, after the hammering I would try to find minimise the patch before submitting it. <thomasd>jmd: yeah, I'm improving in this area... <thomasd>I'm currently packaging Qwt, a (3rd party) library of plotting widgets for Qt. Should that go in packages/qt.scm? <jmd>thomasd: I dunno. If currently there are only "official" qt packages there, then perhaps we should make a qt-contrib.scm or something. <thomasd>it seems like that. I'll propose it on devel list <civodul>thomasd: i usually do "guix build foo --keep-failed" and then fiddle with the build tree <jmd>civodul: I do that sometimes too. But its annoying because first one has to sudo chown the build tree. <thomasd>or even copy the build tree out of /tmp to avoid losing your work? <jmd>I'm not sure if that would work. I think there would be absolute paths in it. <efraim>If its a long build I'll add -K, normally I tweak it looking at the source online and send it through again <ng0>yeah so about libressl... <ng0>there are projects who reject it because it wasn't invented there.. but changing still works <ng0>so we have to face the fact that not everyone accepts patches and keep patches <ng0>to quote from the pull for portage tree: <ng0>They added a configuration test error to discourage people using LibreSSL. <ng0>so the longer I do this.. the more I hear about upstreaming of other systems.. the more I understand how portage tree ended up with all the patches <ng0>they try to upstream <ng0>and sometimes it works <ng0>but there are cases like mozilla... etc <ng0>and delusioned google's 'bundle the world' chromium <ng0>it's like fighting wind mills :) <ng0>About the gentoo bug we got in debbugs.. apart from VMs, I could try to get yet another laptop and install a native Gentoo-Guix there. The VMs work, but what I miss/can't debug easily (still works in a vm kind of) is hardened-gentoo etc <wingo>"cycle detected in the references of `/gnu/store/4y5dlv3cvzs6z7a6gcjmy7q07067dwwc-gtk+-3.20.9-bin'" <ng0>i think there was a bug on cycles? <ng0>I've read the subject at least <thomasd>With gnu-build-system, is there a standard method to change the directory in which "make/make install" is run? <davexunit>thomasd: you need to add a phase before the 'build' phase <civodul>wingo: i think iyzsong is working on it <mark_weaver>civodul: any progress on grafting bash? I wonder if we should commit what I've got, and then we can fix the other problems in later commits? <mark_weaver>(although if I commit now, I may feel obligated to mention in the commit log that references to the old bash still remain, to be addressed in later commits) <civodul>mark_weaver: i made progress on reproducing and debugging 24418 <civodul>however i'm at work so i had to get back to other things before i was done <civodul>i may be able to have that fixed before the end of the day <civodul>and then we need to see how this affects the specific case of gnome-session, for instance <mark_weaver>okay, thanks for the update! I'll check in again in 5 or 6 hours. <ng0>hm.. core2duo with the same speed as an i5 should be 'slower' in some performance tasks, right? <ng0>I used to have an i5 but I can not compare as I sold it a year ago <ng0>one of my build machines is a huge electricity eater... "Model name: AMD FX(tm)-4300 Quad-Core Processor" <mark_weaver>unfortunately, you can't use an i5 without also letting their "Management Engine" also run, which runs a proprietary OS with complete domination over your machine, including the ability to respond to requests over the network even when the machine is turned off. <mark_weaver>(without the host OS being able to see those packets) <ng0>well coreboot works.. that's mostly enough <ng0>i'm just considering it.. as someone offers an x220 in my part of the town <ng0>i think the t400 i have is the last relatively fast cpu without ME <janneke>just received my thinkpenguin tiny n-usb wifi adaptor, hints anyone? <wingo>doesn't it just work? like put it in and there you go <mark_weaver>janneke: one thing though: our network-manager has never worked. for now, use 'wicd-service' instead. <ng0>yeah, that's a thing which should work before 1.0 release I think <ng0>what's broken with it? is there any bug ticket? <ng0>for one thing, there' a new release <janneke>wingo, mark_weaver: that's what i expected... <ng0>i'm already procrastinating very hard, so i try to update it <janneke>i'm getting: Oct 14 17:28:48 localhost wpa_supplicant: Libgcrypt warning: missing initialization - please fix the application <ng0>janneke: that's for networkmanager? <ng0>ah, so not networkmanager <janneke>ng0: no, is networkmanager working already? <mark_weaver>janneke: to debug, stop wicd/nm and run wpa_supplicant manually, with a hand-built configuration, and passing the -D flag to output debugging info. <mark_weaver>something like: wpa_supplicant -i wlp0s20f0u2 -c wpa_supplicant.conf -D <janneke>-D is for driver name, prolly you mean -d[ddd] <mark_weaver>rfkill might also be worth checking. install 'rfkill' and run 'rfkill list' <janneke>ng0: that would be great, never got nm to work with guix <ng0>for now I'm just updating nm + nm-applet <ng0>my temporary roomie is like a busy pidgeon. touring around the country (and also in austria) with poetry slam.. I've seen him maybe 5 times in the last 3 weeks. Now he was here for not one hour until he went on the road again. busy life.. <ng0>we do want wwan support for nm-applet? <davexunit>but there's no reason for us to make packages that are lacking things <davexunit>unless there's good reasons like missing dependencies or it being otherwise broken <ng0>i just asked because I need to add something for the update to succeed <ng0>thatÄs enough info. thanks :) <bavier>speaking of "lacking things", I noticed our mpv and mplayer lack encrypted dvd support <bavier>basically, they can't find our libdvdcss package <bavier>which I think can be trivially fixed by configuring our libdvdread package differently <bavier>I know debian has gone through a lot of trouble with libdvdcss though, are we trying to avoid that by keeping libdvdcss separate? <ng0>i'm not sure, but could it be that glibmm needs to be updated (guix: 2.48, ftp gnome: 2.50) when nm-applet can't find it? <ng0>there's no version in the configure of nm-applet <bavier>ng0: is it looking for features not present in 2.48? <ng0>maybe.. i don't know this application <ng0>wwan wasn't added recently, but now it defaults to yes, so I can circumvent this with setting it to either no or try and update glibmm <ng0>for glibmm refresh: Building the following 18 packages would ensure 35 dependent packages are rebuilt: pavucontrol-3.0 amsynth-1.6.4 frescobaldi-2.19.0 solfege-3.22.2 virt-manager-1.4.0 simple-scan-3.22.0.1 termite-11 gnunet-gtk-0.10.1 telepathy-mission-control-5.16.3 hydra-20151030.1ff48da gparted-0.26.1 azr3-1.2.3 jalv-1.4.6 guitarix-0.35.1 gobby-0.4.13 ardour-5.4 patchage-1.0.0 synfigstudio-1.0.2 <ng0>wasn't hydra problematic? I don't know what exactly caused it to be broken, but a change of glibmm could not lead to broken hydra again, right? <ng0>I'll go ahead and send updates, if it breaks on hydra we can add this older glibmm for hydra back <ng0>I'll also build hydra <rekado>bavier: another thing our mpv build is missing is support for JACK. <rekado>annoys me each time I do music stuff that I have to abort everything and disable JACK just to be able to use mpv quickly. <davexunit>the jack source doesn't make it clear how you're supposed to enable jack support <civodul>i already have 3 video players installed, each with its own defects <ng0>so glibmm requires glib update <ng0>I'll disable wwan for now <ng0>I'll comment this as a reason for why wwan support is disabled for now <ng0>it's a core update thing I'd say.. updating glibmm will require updating glib and friends <rekado>davexunit: what do you mean? What “jack source”? <rekado>civodul: mpv is like mplayer but … better. <rekado>I used to use mplayer for years until I learned about mpv here on this channel. <rekado>I know that mplayer on Fedora had JACK support. <rekado>given the relationship between mplayer and mpv I just assumed that mpv also has JACK support. <rekado>mpv-0.20.0/wscript: 'func': check_pkg_config('jack'), <rekado>I guess just adding “jack-1” to the inputs should do it. <roptat>hi, I'm trying to use openbox on guix SD, but Xorg segfaults <roptat>I get a lot of "(EE) FBDEV(0): FBIOPUTCMAP: Device or resource busy" before the segfault <ng0>is someone using openbox here? I can't help <rekado>roptat: have you tried anything else other than openbox? <rekado>I’d like to know if it’s a problem with X on your machine or just openbox. <lfam>ACTION tests the libraw update from guix-devel <davexunit>paroneayea: braindump, rough outline of a blog post about config management systems today, leading into the guiding architecture for 'guix deploy' <davexunit>looking to gather up as many examples of chef, puppet, ansible, etc. sucking as possible <lfam>davexunit: Your opening line certainly grabs the reader's attention! :) <davexunit>and also the cases in which they get a particular design decision right. <davexunit>my goal is a lengthy article that goes in depth enough to make a case for why I think each tool is bad and explain what Guix does to address the problem <ng0>why everything is broken and guix is less broken :) <paroneayea>davexunit: right after "real devops rebuild all the time" I'd also point out there's a value in being able to guarantee that the version of the system you built locally and tested in a VM is the same version that'll run remotely <paroneayea>oh ok that belongs in "true reproducibility" nm :) <roptat>rekado, so I added (xfce-desktop-service) to my system, rebuilt it and rebooted, but still no good <paroneayea>I'd also point out in containers that containers can be useful as an isolation mechanism, but *not* as a packaging solution <bavier>there must be some points that could be made about why "corporate folks" should maybe still care about reproducibility <paroneayea>davexunit: also we talked about the "state management" in guixops being writing out scheme files, which I think is good <paroneayea>davexunit: though I'll also point out that I'm not sure such state management is the only way to go. One way is indeed to "track" the state of machines... but iirc propellor by joeyh has you describe the machines declaratively, and then logs into each machine and checks the state <davexunit>paroneayea: I think state files are a "bad thing" <paroneayea>davexunit: so maybe declarative is best (and in fact, if you want a command to "add things via the command line", you can have writing out scheme automaticlaly oh wait maybe this is what you meant) <bavier>I had a colleague tell me the other day about how great it was that he could launch a docker container with latex installed so that he could compile his documents on his macbook <davexunit>ansible can just query EC2 as the source of truth, for example <davexunit>same could be done with openstack, or qemu's virt-manager or whatever it's called <davexunit>let those systems be the source of truth and have a way to query them to get the current state of the world <paroneayea>davexunit: right, if anything, maybe we can cache some info on current state, but it should always be rebuildable by querying machines. <davexunit>unsolved issues: how to make this all compatible with AWS's cloudformation and OpenStack's HEAT <davexunit>paroneayea: they ultimate goal is that a team of people shouldn't have to keep shipping updated state files around <paroneayea>davexunit: right, everyone should commit to a git file. <davexunit>questions like "what servers do we have?" should be answered by the system managing those resources <paroneayea>davexunit: so, I want to use this for more than just "cloud systems"; I want to be able to update all my home machines with it, for instance, and my router and etc eventually... so writing out a list of all the machines to be updated would be a good way to go <paroneayea>davexunit: so, it might be possible to do both things. <davexunit>paroneayea: home machines is definitely a use-case <paroneayea>and then have a layer for someplace that can *fetch* a description of machines <davexunit>but in that case your config could have the info about each machine <paroneayea>and then you can both list some machines individually, and then fetch a whole bunch of info from say openstack's watever, and then build a list that has all of them appended together <davexunit>but yes, a simple adapter will allow you to do whatever <davexunit>nixops is "multi-cloud", as they say, which we would achieve too <davexunit>that prototype I made all those moons ago allowed for this <davexunit>of course the only available option was "local-vm" <paroneayea>davexunit: I might have some time to play with some of this on sunday <paroneayea>my brother is coming over and he's trying to set up an environment to do some guix hacking, and I'll be seeing if I can do a remote deployment to my new home server by playing with guile-ssh a bit <paroneayea>I don't expect anything permanent to come out of it, but maybe I'll get a better sense of how things go. Or I can look at your old prototype. <davexunit>now that we have an openssh service remote deployment should be easier <davexunit>you can use guile-ssh to connect to the unix domain socket on the remote machine for guix-daemon <paroneayea>also, nicely, my home server doubles as a gaming machine, not intentionally though ;) <davexunit>it takes a small change to the 'open-connection' procedure to allow for using an arbitrary port, though. <paroneayea>it has a better video driver than my laptop so I played some redeclipse last night. <paroneayea>(I think we need to update our red-eclipse version though. I should submit a patch...) <davexunit>my desktop machine is still in pieces right now <davexunit>haven't set it back up since the move since we don't have a real office yet <davexunit>but we finally got some solid oak tabletops delivered that I'm going to finish... hopefully this weekend. <paroneayea>huh yup... new red eclips released... yesterday :) <lfam>Does anyone know where I can see sneek's vacation pictures? Do they have a mediagoblin instance? <lfam>Wow, freeimage is a terrible bundling offender! <lfam>All the big image libraries, zlib, openexr <davexunit>I stopped depending on it in my game engine because of it <davexunit>it surely has unpatched security vulnerabilities <lfam>Just these: perceptualdiff-1.3 guile-sly-0.1 emulation-station-2.0.1 <ng0>is / was someone working on emscripten? otherwise in the context where it's needed I'd tell someone from our GNUnet team to let harmut package it <ng0>well already contacted about it <davexunit>guile-sly is not important. the new version (unreleased) doesn't use it anymore. <lfam>davexunit: It's half-way to an graphical operating system <ng0>but the question is still out :) <davexunit>lfam: I wonder if emulation-station can use something else... <lfam>Annoying considering how much work I've put into those image libraries! <ng0>you learn, even with mistakes :) <lfam>Okay, I'll send a message to guix-devel <davexunit>glad I learned my lesson and dropped the dependency <roptat>so still the same crash with xfce <ng0>can you provide a paste of your system config? <ng0>sorry if you already did, I'm working on smth else and wasn#t following <lfam>mark_weaver: I'm looking into updating gpgme to the latest upstream version (1.7.0). I'm wondering about the line you added to the package definition which passes "GPG=gpg2" to #:make-flags in e6a83df1. <lfam>Is that setting documented? <ng0>roptat: that's the system log <ng0>i meant the config.scm you configured your system with <lfam>mark_weaver: I wonder how it's affected by the fact that we made "gpg2" our default gpg <rekado>roptat: it would be helpful to see the full config.scm you use. <rekado>roptat: FWIW I don’t have xfce-desktop-service in my config at all. <rekado>roptat: for xfce I needed to add “xfce” to the list of packages <ng0>hm.. is anyone actually running openbox or was it just packaged? <ng0>I can configure a system with it and try <roptat>ng0, I packaged it like two years ago, and it worked well <ng0>was it updated in the meantime? <rekado>roptat: the error log you posted are troubling. [ 28.615] (EE) Screen 0 deleted because of no matching config section. <rekado>and then it switches to using the framebuffer <ng0>we are at 3.6.1, upstream is at 3.6.1 <roptat>I have an ati card, but it can't work with free drivers <ng0>so assume you run your modified guix with it <rekado>roptat: this should be unrelated to the segfault though. <ng0>I just have ati cards which terribly slow down without drivers provided <ng0>roptat I have an ati card, but it can't work with free drivers so there is the cause of error.. or not? <rekado>I installed GuixSD on a system with an unsupported radeon card and X obviously did not segfault. <rekado>ng0: missing driver means that the system falls back on vesa <ng0>on amd/ati: there is this new amdgpu driver, but I've read the license and I doubt we can use it. <rekado>roptat: do you have an additional log file? Or is this /var/log/Xorg.0.log? <roptat>it's already /var/log/Xorg.0.log <rekado>I’m afraid I can’t help here. This is a bug in X (or our xorg-server package). <rekado>X should never segfault, no matter what the driver situation is. <orbea>rekado: every segfault I got in xorg has been resolved with a patch I got from #xorg-devel :) <rekado>roptat: do you happen to have an older version of the system installed that you could boot into? <roptat>I could boot to the system I installed, so not that old <ng0>did you pull and reconfigure recetnly? <roptat>pull this morning and reconfigure just now <ng0>xorg is not something I have much knowledge in, I can't help there <ng0>there must be something introduced in the pull which broke something for you <ng0>that's all I can guess <rekado>roptat: and before that X would start up correctly? <roptat>I just installed guix sd yesterday night <roptat>(it's a different computer from the one I usually do guix stuff) <roptat>before that xorg was working correctly, but I used the microcode <ng0>some gpus need microcode blobs <rekado>well, I’d like to know from roptat what exactly they did. <rekado>because that would mean a custom kernel and that’s unlikely for an initial installation of GuixSD <roptat>on my previous system (not guix sd) I used a binary blob to make the radeon driver work <roptat>on my new guix sd system I can't do that, so I relied on Xorg falling back to vesa or something else <rekado>okay, so the new GuixSD system has never actually started X correctly? <rekado>roptat: have you tried starting X after the initial install? <rekado>when you did “guix system init” did you use the release version of Guix or did you “guix pull” first? <rekado>if you used the release you’d have two systems, one old (using the latest Guix release) and one new (using the latest master from git after “guix pull”) <rekado>then we could see if things broke since the latest release <rekado>another option is to reconfigure with an older version of guix <ng0>what is the 'package X was replaced by package Y' option called again? any example paclkage i need to look at? <rekado>roptat: in that case could you try booting into the first system that was installed using the release? <rekado>roptat: if X behaves differently then it might give us a clue as to what’s going wrong with the latest version. <rekado>roptat: you should be able to select the first system in GRUB <ng0>what I want to achieve: "vim" was replaced by "vim-minimal", so I can add vim-all or vim-maximal .. I know that just making vim the vim-maximal would work, but that would affect peoples profiles so I don't know how to do this wothout upsetting all the vim users here <rekado>ng0: you could also just add a vim-maximal package inheriting from “vim”, no? <ng0>but then vim would still be vim-with-almost-no-features <ng0>but maybe people search and discover it <ng0>so I'll just do that <ng0>i don't like the name -maximal, but for the lack of a better idea I go with it now <rekado>ng0: I don’t think that’s a problem. <rekado>roptat: could you please do us a favour and send a bug report to bug-guix? <ng0>i think vim-maximal is okay <ng0>it points out -maximal has more features than just vim <rekado>ng0: does “vim-maximal” have both python and ruby as inputs? <ng0>i only need ruby for the notmuch vim bindings, but i'll use the vim efraim had with only python3 support instead of py2+3 <rekado>ng0: can these things be placed in separate outputs? <ng0>i haven't even started writing this <rekado>would be good to figure out if this can be done. Sometimes it’s sufficient to just move a few files to a separate output to make references optional. <ng0>all i have now is 1/30th package with the name and inherit :D <rekado>well, the name is obviously most important ;) <ng0>so far no one disagreed with me signing the next gnurl release with just ec keys.. so I think I'll do that, and upset debian stable and slackware people <roptat>so what's the status of wayland under guix sd? :p <ng0>you'll not be able to run a full wayland without X for probably... ever <ng0>you still need xwayland for applications <ng0>i think my phone runs xwayland <ng0>i'm so very much not satisfied with it that i'll probably start porting applications next year <ng0>2.5 years waiting for something to happen is enough <ng0>looking back at it, this is what I should've done with maemo5/n900 <ng0>oops, openssl is... years behind <ng0>i wished the fairphones fair prices wasn't so incredible high that its price is at the same time fair, but also not affordable. <ng0>neo900 is the same.. starts at a price I consider much much too high <ng0>if you could only print chips already.. <kyamashita>Right? Vendor-abandoned, backdoored smartphones are no fun. <ng0>the n900 is good.. neo900 is a project which was started by those who tried to get out the first smartphones before android got big <rekado>I never found a phone I was happy with. So I abandoned phones altogether. I’m quite happy with this decision. “Smartphones”…, heh. <kyamashita>IIRC, neo900 is the most free option at the moment? Or is it openmoko? <ng0>i need a phone at least for banking <ng0>kyamashita: no there are others, but openmoko is history <rekado>I still have a SIM card and I happen to have a GSM modem in my laptop which works with linux-libre <ng0>neo900 is what became of openmoko <rekado>I should package some GSM tools so that I can send short messages from my laptop <ng0>gsm is sort of like sending a pidgeon, only more insecure. but I guess there's no harm in packaging tools <kyamashita>I thought GSM was completely out of the game security-wise. <ng0>but there's also 3G on top of that etc <ng0>i don't know memorize much about phone technology. i just know gsm has some flaws <ng0>read something, and yoz don't need it so it's difficult to quickly recall it <ng0>like I learned spanish and french but I have a hard time replying <ng0>the test suite of vim is always fun to watch.. like your editor just crashed and does things on its own <ng0>deity... poah. I think I need to update vim. https://github.com/vim/vim/issues/1070 what are those version like v8.0.0032 ? can they be used at our side or is this just pre-release? the issue reads like it was fixed in some release after 8.0 <kyamashita>It looks like v8.0.0031 is the current version according to www.vim.org <ng0>Looks good to me, a full build (of 8.0.0004) now completes with either Python 2 or Python 3. <ng0>I'll try updating vim to 0031 <jmd>When should I use shepherd-service-type and when should I use service-type ?? <rekado>jmd: services in Guix don’t have to be shepherd services. <rekado>jmd: we use services to populate /etc, for example <rekado>this doesn’t result in a shepherd service that users can start and stop <rekado>use shepherd-service for daemons that should be controllable via “herd” <rekado>hah, turns out I added JACK support to mpv in 2015! <rekado>totally forgot about this. So all I need is run it like this: “mpv --ao jack the-file” <ng0>kyamashita: but where? I see it only on github, not on their fto <rekado>davexunit: re your ops brainstorm document: I always dislike it when people speak of “Turing complete”, because it doesn’t mean much. I guess you can do computations with Puppet if you tried really really hard. <kyamashita>ng0: Vim version patches are here: ftp://ftp.vim.org/pub/vim/patches/8.0/ <ng0>oh, i quit that efore it loaded :) <davexunit>rekado: yeah, looking for a better way to describe it <rekado>I’ve only used Puppet and it’s terrible, but I think the reason why it sucks really badly is not so much that it’s not “Turing complete” but that it’s poorly designed and imperative. <davexunit>to differentiate data serialization formats from actual programming languages <rekado>I should also say that for system definitions I like a declarative approach and for my system’s configuration I hardly use any “real” programming language features. <ng0>i have no idea how the patches in bash.scm work.. I'll just include the patches up to the patch I need in the gnu/packages/patches/ dir <rekado>it only becomes a problem when you are forced to operate in an imperative setting, I think <rekado>in Puppet I absolutely hate not having proper Ruby at my disposal but only because I’m not really declaring the target state but working around the limitations of an imperative configuration management system. <rekado>I find it disgusting that I regularly have to run “puppet agent --test” repeatedly for new deployments because the order of declarations matter. <rekado>after the fourth time it usually passes without errors. <rekado>arguably that’s because our team is terrible at using puppet. <rekado>but I think that puppet makes it really easy to give up <rekado>the worst part about puppet is that I have no guarantees about the state of the system. <rekado>I cannot just “ensure” that all packages I have not declared are absent because that’s not the same as not having installed them <ng0>actually.. i think if i understood all of what bash.scm does, vim is similar. they are numbered. <ng0>but because i don't i think 5 more patches will not hurt the patches dir <rekado>it’s not reproducible and the solution to many problems is just pouring more junk over the configuration file and rerunning the agent often enough to make it pass without errors. <reepca>After finally waking up, I see that my guix system reconfigure didn't succeed because something called "gnu-ghostscript-9.14.0" was "410, Gone". I hope this doesn't mean it's going to have to rebuild linux-libre all over again... <rekado>reepca: rerun it with “--fallback” <rekado>our build farm seems to have removed a few too many of our binaries. <rekado>with “--fallback” Guix will keep going and build from source if a binary cannot be downloaded. <rekado>you won’t have to rebuild any package when you’ve already built it and haven’t changed the version of Guix since. <lfam>I wouldn't mind if '--fallback' could be passed to guix-daemon <jmd>Is it at all possible for a service to "mutate" another service? <rekado>jmd: you can extend a base service type. <rekado>dunno if this would count as mutation. <rekado>davexunit: portability is also a problem with puppet manifests. We recently dropped support for Fedora at work because the IT person couldn’t make it work… <lfam>I just built my non-graphical GuixSD system on core-updates. Soon I'll reconfigure and see if it all seems to work <jmd>I mean, if service A writes "foo" in a config file, can I change that to "bar" with service B ? <rekado>jmd: I’m not sure. There are different ways service extensions can be combined, e.g. concatenation or replacement. <civodul>jmd: no, unless A is specifically designed to be extended in such a way <davexunit>rekado: interesting. looking to collect more of these anecdotes. <rekado>davexunit: puppet just really makes me sad. I can’t stand working with it. It encourages inheritance and this means a lot of manifests stop working when others are changed. <davexunit>Chef is a little better... I think, but still bad. <rekado>puppet also has a restriction on rules so that you cannot override rules from classes your manifest inherited from. <rekado>e.g. base class defines a list of packages and a subclass wants to remove one and replace it with another. <civodul>rekado, davexunit: you should blog or something about your experience with Chef/Puppet <davexunit>civodul: above I linked to a rough outline of an article I'm working on <davexunit>trying to get enough anecdotes together to explain why I think chef/puppet/etc. suck and why we have a chance to do better with guix <rekado>since months we’re undergoing restructuring of our massive puppet repos to rip out inheritance and using mixins instead. <davexunit>(I also want to highlight some problems I see with NixOps) <rekado>I’m really looking forward to GuixOps. <rekado>even a first draft would be better than Puppet. <davexunit>my weekend hack time has been replaced with home improvement time for the most part, so, help wanted! <davexunit>I feel like probably one person should bang out a prototype <jmd>There are an increasing number of places where we have hard coded 1000 as the smallest permissible uid. If somebody wanted to change it, it could not be done by configuration. <rekado>the Makefile explicitly checks if /proc/cpuinfo mentions sse and uses SSE only when it’s supported. <rekado>so the build really shouldn’t fail on armhf. <rekado>yet for some reason the build log says that these flags were passed: -msse2 -mfpmath=sse <rekado>does the cpuinfo on the build machine claim to support SSE instructions when it actually doesn’t? I don’t get it. <rekado>It’s more than one package with failures like this. They all have the same mechanism in the Makefile to grep /proc/cpuinfo before using SSE. <rekado>*some* of them fail on armhf, others do not. <rekado>I suspect they were built by different build machines. <nckx>Hi lfam! Is my MUA on the blink or did you CC me on the freeimage bundling issue? (If so, why?) <lfam>nckx: Because you packaged perceptualdiff and it depends on freeimage :) <lfam>So I thought you might have some motivation to work on freeimage <kyamashita>lfam: I copied Debian's patch and I'm getting some undeclared variable errors. <lfam>kyamashita: Thanks for working on it! If you are stuck you could send your WIP patch with the error messages to guix-devel <civodul>lfam: i have a fix for the bug illustrated with the msmtp/gnutls grafting <lfam>civodul: That's great. I can test it if necessary <civodul>not yet for the gnome-session one that mark_weaver reported this morning <nckx>lfam: I see. OK. kyamashita: what lfam said, if you get tired of it. I'll take a look at it then (post-Sunday). <lfam>nckx, kyamashita: It's also acceptable to unbundle them one or a few at a time. We don't have to wait for the perfect patch that unbundles all of them at once. <lfam>That test keeps us from building certbot (Let's Encrypt tool) <lfam>I tried building python-cryptography with python-3.4.5 on core-updates, but then *other* packages started failing, so I made the bug report :) <lfam>The weird thing is that it fails on core-updates for both python-3.5 and python-2.7. So, either some backported bug fix broke it in both release series of Python, or the problem comes from something besides the Python interpreter <nckx>ACTION just subscribed to oss-sec, because he's too good for this world and doesn't get too much mail already. Let's see how it goes... <lfam>nckx: It's not a very high volume, especially compared to guix-devel <civodul>lfam: re dbus replacement, perhaps we could have set 'version' to "1.1012" (no dot) so make it easier to distinguish it from the vulnerable version <nckx>lfam: oh good, that was my main concern (though I guess that would have some unpleasant implications). <lfam>civodul: Can you explain more? I don't get the significance of the dot <civodul>lfam: now it's possible for a replacement to have a version number different from the original package, as long as the length is the same <civodul>here the original is "1.10.8", so the replacement cannot use "1.10.12" because it's longer <lfam>I noticed that and I discarded the draft that suffered from the wrong length :) <lfam>Would we still let version be 1.10.12 inside of (source) if we did that? <civodul>just saying that because i'm debugging grafts and staring at file names... <lfam>I can make the change if you prefer :) <lfam>Although it rubs me the wrong way to use two different version strings in the same package <civodul>it's not super important either, but in the future we might want to use different version strings systematically <civodul>and yes, i admit this is not super pleasant to the eye :-) <lfam>civodul: I'd rather work on fixing the python-cryptography build failure right now :) <ng0>rekado (? hope it was you): no, i can not split outputs in an easy way as it all ends up in one binary <lfam>Yes! python-cryptography is building on core-updates again <lfam>Heh, it wasn't much work. I should have asked upstream for advice much sooner <rekado>ng0: yup, that was me. Too bad :( <rekado>this is funny. This works: ifneq ($(shell cat /proc/cpuinfo | grep sse2 >/dev/null),) <ng0>you get some binaries in addition, but it's like with opensmtpd, they are just symlinks <rekado>but this does not: ifneq (cat /proc/cpuinfo | grep sse2 >/dev/null,) <rekado>this is why some of the gx-*-lv2 plugins fail to build on armhf <ng0>testing vim-full now if it starts.. checks were succesful <bavier>shell expressions need to be escaped in makefiles <rekado>I’ll report these upstream and patch them in our packages until there’s an upstream patch. <bavier>otherwise make will just understand it as a string <civodul>mkdir("/tmp/guix-directory.JlgpQj/real-root", 0755) = -1 EOVERFLOW (Value too large for defined data type) <civodul>does 'make check TESTS=tests/syscalls.scm' work for you? <reepca>It failed for me on a build I tried on my laptop yesterday. I think I even mentioned it earlier, I probably still have it in my erc buffer <civodul>the pivot-root tests breaks everything in tests/syscalls.scm, with Linux-libre 4.8.1 <civodul>i think the behavior changed with the new kernel or something <ng0>can one package vim extensions/plugins like we do for emacs? <ng0>so i assume it's possible <rekado>ng0: probably. Maybe you can investigate what’s needed for a vim-build-system. <ng0>this is probably easier than go-build-system.. i tried to start that, but so far it went nowhere because I need to understand more of go <ng0>I don't use vim much, used to.. I only started to use emacs because it was easier to configure and extend <rekado>because if not you could just let someone else do this <ng0>yeah I'm just suggesting it <rekado>adding packages always also means a burden to keep things up to date <ng0>we have an imcomplete notmuch <ng0>that's why I added the vim i just posted <ng0>occasionally I browse the website of packages I do not get notified of updates through lists <rekado>but notmuch doesn’t depend on vim, no? <ng0>nope, but notmuch-vim does depend on vim with ruby support <rekado>right, but that doesn’t mean our notmuch package is incomplete. <ng0>currently we do not build this, but with full vim we can <ng0>wrong choice of words. yes you are right <ng0>what I meant is, we can add vim support <rekado>will this be a separate package? <rekado>because it would be unfortunate to add vim-full as a dependency to notmuch. <ng0>okay, I can add vim-ruby as a not public variable just for notmuch <rekado>well, but even that is maybe too much <rekado>can the notmuch vim plugin be separated from the rest of notmuch? <ng0>it is inside the source of notmuch <rekado>that’s an answer to a different question :) <rekado>maybe you can discuss this with other notmuch users here. <rekado>(I’m not one so maybe I shouldn’t comment on this.) <ng0>has its own subdir, i have not read into it so much, only that it has its own build procedure <ng0>i don't know if it depends on .. but I guess so <kyamashita>I found the part of Debian's freeimage patch that's causing the build to fail. <ng0>so I think it can be achieved with an inherit <ng0>and just have a (define vim-ruby) + (define-public notmuch-vim) <kyamashita>It has to do with disabling some JPEG functions that only work with the "home-grown" JPEG library. <ng0>i keep that in mind, thanks rekado. I'm done for today :)