<fps>but my bspwmrc is not getting executed <lfam>mark_weaver: Why does messaging.scm #:select a subset of licenses when importing (guix licenses)? I see that you introduced it in 8b3099cf0. <mark_weaver>lfam: because both (guix licenses) and (gnu packages compression) export bindings for 'zlib'. in one case, it refers to the zlib license, and in the other case it refers to the zlib package object. <mark_weaver>and I had to add (gnu package compression) to the import list in 8b3099cf0 <lfam>mark_weaver: This is the same problem that is sometimes addressed by using a license prefix, right? <mark_weaver>probably we should just standardize on always using the license: prefix <lfam>Whenever my changes to messaging.scm are ready, I'll change how it works in that module <mark_weaver>unless you need the 'zlib' license, it's probably best to leave it <mark_weaver>such a change should not be incorporated into an unrelated commit <lfam>Fair enough. I would do it separately in any case. <efraim>I decided to try again with gccgo-5. Actually taking notes this time. Last night was 6.5 hours compiling, failed at validating paths, it tried to link against glibc <efraim>hydra took 42 minutes to build gccgo-4.8.5 <efraim>I really need a more powerful computer ***tschwing_ is now known as tschwinge
<fps>is there a way to make a guixsd i have on a partition not mount a particular filesystem without booting and reconfiguring it <fps>09:41 < fps> is there a way to make a guixsd i have on a partition not mount a particular filesystem without booting and reconfiguring it <fps>it would otherwise mount the home i'm livin in right now ;) <fps>and two OSs mounting the same fs smells like trouble.. <civodul>i don't quite understand the question <civodul>GuixSD mounts all the specified file systems when it boots <fps>ok, yes. guixsd lives on /dev/sda1. it mounts /dev/sda2 to /home <fps>right now i have booted ubuntu and it mounts /dev/sda2 to /home <fps>now if i start sudo qemu -hda /dev/sda it will mount /dev/sda2 to its /home <fps>which is not good :) <civodul>"sudo qemu" sounds like a bad idea no matter what <fps>but: i can of course mount /dev/sda1 and edit the system config to not mount /home.. but that won't do any good since the config isn't authoritive but the generated os is <fps>civodul: it does? for what reason? <fps> /dev/sda is a file.. :) <fps>but you're right. i'm just lazy and should just create a new image to play with while confined to ubuntu :( <civodul>i wouldn't want qemu to fiddle with my raw disk devices <fps>yeah, it's probably a bad idea for a reason i'm not aware of.. <fps>civodul: but there's a more general question though: on a traditional linux system the fstab is kind of transparent.. you can change its state from the outside <civodul>if you know what you're doing, it's probably OK, it just rings an alarm in my mind ;-) <fps>i.e. change the OS's behaviour/config without booting it <civodul>ideally, you would change the OS config and reconfigure so that the changes take effect on the next boot <civodul>but it's necessarily on the next boot, since the file system cannot be unmounted if it's in use <fps>but isn't this maybe a problem where hardware has changed and you cannot boot the system as is to reconfigure it? <fps>would (in general) booting an installer image be of help? i.e. mount the root fs to /mnt and use system reconfigure in a smart way from the installer be of use? <fps>you see what i'm getting at and why it could be useful to have such a method? <fps>server on a remote box where a harddisk failed and you need to change things in the config without booting it or something similar? <civodul>that's not specific to GuixSD, is it? if you remove the hard disk that the OS tries to mount, then it will fail to mount it <fps>yes, but with some imagination you can come up with scenarios where the system as it is won't boot and you need to "fix" it <fps>from another system boot.. <civodul>i was thinking of having a "rescue" entry in the GRUB menu <fps>that might help in some cases, but not all. like networking failures which need reconfiguration before the system will become usable. no console access and no net access.. <fps>i.e. no grub access ;) <civodul>you mean you've lost access to the machine? <fps>but there are other thinkable scenarios <fps>but yes, it boils down to: cannot boot the machine as it is, need to reconfigure it without booting it <fps>but can boot another system like the installer image or something else.. <civodul>but we need to assume you have access to it somehow, right? :-) <fps>well, you have access to the partition it lives on <fps>i.e. you can mount the root fs.. <civodul>and you can boot the "rescue" entry, too <fps>no, no access to grub <civodul>i don't understand that use case :-) <civodul>you have physical access to the machine, but you cannot reboot it? <fps>ok, i'll give you a scenario: <fps>vm is shut down in a state where it won't have useful network access since you changed the config in a bad way <fps>it has no vnc/serial console access <fps>booting it won't help you since it still won't have good networking. it runs, but is not accessible.. <ecraven>can't you normally directly access the console with virtualbox or vmware? <fps>if you have configured serial console in grub/the kernel, then yes :) <fps>use your imagination people :) <fps>have you never had a box where all you had left was access to the root fs via its device from another system boot? <ecraven>some days I'm quite happy not to be a sysadmin :) <alezost>fps: just to mention: I use fstab on GuixSD <fps>alezost: you do? interesting :) <fps>is it generated by reconfigure? <alezost>I use it just for the following use-case: instead of "mount -o many,options,here /dev/sdX /mnt/foo" I can use "mount /mnt/foo" <fps>ecraven: aren't you the sysadmin of at least one system? ;) <ecraven>fps: yea, but this one always has a hardware console that works <fps>alezost: good point. maybe there should be a operating-system stanza for this: file system entries that are available to mount at will <alezost>fps: IMHO the best will be to have 'etc-files' operating-system field, where you can specify your own additional /etc/ files and override the default ones (like /etc/profile) if you don't like them <efraim>i'm looking at the go build instructions, its basically "chdir src/; ./all.bash", with all.bash running make.bash and run.bash <fps>alezost: that rings a bell. wasn't there a discussion on the ML about exactly that pushed by you? :) <civodul>adding an 'auto-mount?' field, basically <fps>civodul: shall i file a ticket? <civodul>ideally fstab should mirror what the config says, IMO <fps>alezost: re: the socket thing: the normal usecase is to open a tmpfile and keep the fd around, but rm the original file. this keeps the file live and yuo keep access to it through the fd <fps>once you let go of the fd the file "really" disappears.. <fps>alezost: so, put the fd into a closure that disappears when emacs exits? <fps>but there's the problem that two "processes" [fuzzy on emacs internals] need to access the fd for the socket.. the normal usecase assumes just one <fps>oh, that should work. you start guile --listen=/tmp/foo. it keeps the fd even if you rm the file <fps>then in emacs you open the tmpfile and keep its fd, then rm the file <fps>the file is then no longer visible in the fs via ls, etc.. <fps>once both processes let go of the fd it's gone for good.. <alezost>fps: yes, but I will not remove the socket, because it's not a normal use case for me, as I often want to connect to Guix REPL to debug it or something <alezost>I think removing it after Emacs exit is fine <fps>the nice thing about the keep-the-fd-but-rm-the-file use is that there's no chance of stale files being left around <fps>no chance on earth. another process might even create another tmpfile with the same name and it will never conflict :) <alezost>fps: as I said, I'm not going to do it :-) <alezost>I need a way to connect to guix repl <roelj>Does python-build-system use python 3 or python 2? <roelj>Ok. When I want to explicitly want to use v2, could I: (build-system python-build-system #:python 2) ? <efraim>you keep (build-system pyton-build-system) but add `#:python ,python-2` to arguments <roelj>(arguments `(#:python ,python-2)) ***tschwing_ is now known as tschwinge
***jgay_ is now known as jgay
***jgay is now known as jgay-tmp
***jgay-tmp is now known as jgay
<rekado>the bioconductor URLs for DESCRIPTION files are behind basic authentication (username and password are "readonly"). <rekado>does http-fetch support basic auth? Should it? <civodul>but it's software, so it could be made to do so ;-) <civodul>the question is whether it's easier to convince the bioconductor sysadmins to change their policy <bavier>any good guile-ish ways to get a list of directories matching "libs/*/test"? <davexunit>bavier: file-system-fold is the general-purpose tool for these sorts of things <davexunit>you could a procedure to do such a targetted query in terms of that <mark_weaver>bavier: 'find-files' in (guix build utils) can do it <bavier>mark_weaver: but I think the find-files on the current master branch doesn't do directory name patterns <mark_weaver>something like (find-files "libs" (lambda (file stat) (and (eq? 'directory (stat:type stat)) (string-suffix? "/test" file))) #:directories? #t) <bavier>mark_weaver: that's what I mean ;) I'll give it a try <roelj>I'm packaging libvirt, but even when I have installed libnl, it complains in the configure phase with: 'configure: error: libnl-devel >= 1.1 is required for macvtap support' <roelj>Should I set some shell variable first? <bavier>roelj: it depends on what configure check is failing <roelj>bavier: Twice 'checking for LIBNL... no' <roelj>I just double-checked that I have it in the list of native-inputs. <bavier>roelj: is there a configure log with more detail on what check failed? <davexunit>roelj: might not be relevant, do you have pkg-config in native-inputs? <roelj>bavier: Where should I look for that? <roelj>davexunit: I have not. That's worth a try indeed. <bavier>roelj: if it's an autoconf package, then config.log in the build directory <bavier>btw, libraries typically belong in 'inputs', rather than 'native-inputs' <roelj>bavier: Ah, indeed.. it's also a runtime dependency.. <the-nsa>ummm python-pip does not quite work with the guix layout <roelj>I looked at the configure.ac, and I think it failed because it misses pkg-config. It's building now.. so I hope that will work. <davexunit>the-nsa: there's probably an environment variable you need to change' <davexunit>but I don't know what it is because I install all python packages via guix <the-nsa>yes probably, I'll have to check the dox <davexunit>I wrote a script yesterday that creates a binary bundle for running a particular program <davexunit>I think it revealed some missing bits in the container implementation <davexunit>booting the Guile REPL resulted in some GC warnings about missing files <lfam>That's pretty cool. So, it comes with its own store? <davexunit>since it contains the full set of dependencies <lfam>Because they include their own libc, compiler, etc? <davexunit>the compiler wouldn't be present unless the store item maintained a reference to it <lfam>Yes, but that way you KNOW it will work at the game jam! <lfam>Hey davexunit, what's the latest blog-post type thing about your game engine? I have a friend who might find it interesting? <lfam>The second sentence is not a question <lfam>Well, I suppose it is. But I didn't mean to write it that way ;) <lfam>first paragraph: s/input even handling/input event handling/ <lfam>s/live codinng environment/live coding environment/ <efraim>cups-filter from yesterday is 1.4.0, so comparing it with the debian version it should be safe from CVE-2015-8560 <bavier>I should read more CVEs, they're interesting <fhmgufs>If I want to install guix as my main system on an architecture not supported by GuixSD (armhf): Which base distribution should I use and how much should the base system contain? <davexunit>use whatever distro you like, guix doesn't care. <fhmgufs>Ok, now I'm interested in the second part of my question. <davexunit>guix uses its own everything, so it doesn't matter what the host system has <fhmgufs>Would it be enough just to install a kernel and install guix from another machine? <davexunit>I'm confused as to what you're trying to do. <davexunit>to use Guix, not GuixSD, you need to pick another GNU/Linux distro to use a base. which one it is doesn't matter much. <fhmgufs>I would like to have possibly all tools managed by guix. How much do I need to run guix? <efraim>do you mean to use a wm from guix also? <davexunit>for that to be non-painful, you'd want to use GuixSD. <davexunit>which means finishing up support for it on ARM <fhmgufs>In which state is the development of GuixSD for ARM? <davexunit>I think the remaining blocker is that we need GRUB for ARM <davexunit>which is in an as-of-yet unreleased version of GRUB <davexunit>and then there's the issue of the wide variety of tweaks that need to be made for various ARM machines <davexunit>for example, the Novena requires a specially patched uboot <efraim>I think most arm machines need a custom uboot <fhmgufs>But there are distros like arch linux arm which have one repository for all machines of one architecture. <efraim>for uboot, it could just be a (define uboot, and (define-public novena-uboot (package (inherit uboot)... )) and some custom templates for each machine <davexunit>fhmgufs: we have that, too, but booting these devices requires special software usually <efraim>as i understand it, they have a kernel that works for all, and the actual booting is board dependant <davexunit>and GuixSD takes of managing the bootloader, too <fhmgufs>So the bootloader is the only big problem as I understand it. <fhmgufs>And I think I'm able to install a bootloader manually. Is there no possibility so unset the bootloader field? <efraim>there's a `--no-grub` or similar flag <davexunit>yeah, you can pass --no-grub to 'guix system' <davexunit>I don't know if just managing the bootloader manually would be enough to make GuixSD work <efraim>updating cups involves rebuilding qt and gtk+, how much pain am I in for? <efraim>uboot gets rebuilt each time the kernel changes, right? <davexunit>we don't have a uboot package in guix, do you mean in general? that I don't know <fhmgufs>davexunit: I also have to define some custom packages (kernel, the special bootlader, firmware ...). I'll try it if I have some time. <bavier>efraim: `guix refresh -l cups` says 292 packages <efraim>yeah, but the packages I'm building to test involve rebuilding gtk and qt <bavier>I believe that's included in the 292 <lfam>fhmgufs: If you want to see how to put together a system on a variety of ARM boards, check out armbian.com. They integrate bootloaders for a variety of ARM boards with mainline Linux as well as the branched vendor kernels. Mostly for Allwinner but also some Freescale stuff. At least, you can see how all the parts come together to make a working system. <bavier>I'm trying to get tests running for our boost package, but I'm finding that its tests aren't all that clean <bavier>would it still be useful to run tests even if many of disabled/skipped? <lfam>bavier: I've noticed lots of packages that skip some tests. Of course, the best thing to do would be to make the tests pass, and second best would be to understand why they don't, and leave a FIXME comment explaining the situation <civodul>bavier: at least that lets us know "where we are" <civodul>though i understand it can be frustrating, too <bavier>yeah, I don't necessarily want to start importing dozens of patches from upstream boost <bavier>maybe first thing would be to update to 1.59.0. <fps>i guess every uncomment test skip is a TODO ;) <fps>i guess every skipped test without an explanatory comment is a FIXME <civodul>bavier: maybe yes, it seems that past updates have been relatively painless