*davexunit wonders how to generate a container a la 'guix system vm' <mark_weaver>davexunit: I'm looking at your 'call-with-container' code, and have a few comments/questions. <mark_weaver>regarding (symlink "/proc/1/fd" (in-container "/dev/fd")) and the others like it, I think it should be /proc/self/fd, no? <mark_weaver>regarding (symlink "/dev/ptmx" (in-container "/dev/ptmx")), I don't see how that can work. <davexunit>mark_weaver: yeah, it might be. I haven't properly tested it yet. <davexunit>I've simply followed a specification document from the Docker project. <davexunit>I haven't gotten anything to boot enough to really test <davexunit>but yeah, that symlink will break after the chroot, so maybe they really meant bind-mount <davexunit>for the record, I'm currently stuck trying to write a build script for producing container scripts to keep in the store <davexunit>'guix system vm' someone creates a read-only VM image <davexunit>I don't know how to do a similar thing with containers <davexunit>need some throw-away disk space or a ramfs or something. ***boegel|quassel is now known as boegel
*civodul just realized that in a non-Emacs terminal GCC 5 uses colors by default *civodul attempts a switch to gcc 4.9 in core-updates, crosses fingers <rekado_>since a very recent update cc1plus crashes with a segfault. <rekado_>I'm building powertabeditor for which I was just going to submit patches. But now that the compilation segfaults I'll have to delay that. <rekado_>I just rebased my patches to latest master. <civodul>if it's just a week of commits, that should be doable <civodul>uh i have a program that segfaults in QGLWidget::glDraw <civodul>is there anything we need to do for GL stuff? *davexunit wishes <local-file> objects "just worked" in the hosts-file field of an <operating-system> *rekado_ sobs uncontrollably as he sees the impressively fragile custom build system for blast+. <civodul>davexunit: yes i think we'll do that, now that we also have <plain-file> <davexunit>it will keep users from having to understand monads right away :) <bavier>I installed GuixSD on my work machine and used it very happily for a day or so, but IT seems to have put stricter policies in place since the last time I checked. :( <civodul>bavier: you mean you're no longer allowed to use it? <bavier>civodul: unfortunately not; they shut up that operation pretty fast <civodul>i always find it weird when IT wouldn't let you use what you deem appropriate, as long as it gets the job done <davexunit>and you're a freakin' distribution maintainer! <Steap>Don't they just want "controlled" environments to prevent users from spreading malware and stuff ? :p <davexunit>if bavier is doing programming work then it's silly for IT to get in the way. <cmhobbs>is guix stable enough for regular use yet? <davexunit>I run it on a laptop and a desktop and everything pretty much just works <davexunit>I need to figure out why icecat doesn't go webgl and I want the xfce power manager to get packaged. <cmhobbs>i'm pretty sure $new_job is buying me one of the gluglug rigs <cmhobbs>figured guix would be great if it was ready for regular usage <davexunit>it's still alpha, but you could give it a shot if your needs are modest. <cmhobbs>in a few months i hope to have contracts wound down enough to start to get into packaging <cmhobbs>i've tried to package a couple of things, mostly as a learning exercise <davexunit>the more software we can package the more users we can attract <cmhobbs>i should try to get it in a vm or on my spare rig at home <cmhobbs>i just use the package manager portion right now on top of jessie <mark_weaver>davexunit: OT question: how is video playback performance on the Novena? someone on #libreboot is asking, and mine is headless for now. <davexunit>mark_weaver: well, not great right now with the software renderer <davexunit>haven't yet used the hardware accelerated graphics drivers <bavier>if I run into packages that 'guix import hackage' is unable to import, would a bug report be in order? <civodul>mark_weaver: do you think we should start getting Hydra build core-updates, with the "core" set? <mark_weaver>civodul: so, there are two more things I'd like to get in: passing --build by default in gnu-build-system, and I'm also thinking now that armhf should require neon support in the processor. <mark_weaver>the reason for the latter is that it turns out that neon is a common requirement for optimized assembly code written for ARM, in things like ORC, video codecs, etc. <mark_weaver>and it turns out that the reason Debian armhf made their requirements slightly less than Neon was to support a couple of pieces of hardware that may have been important at the time, but probably not so much today. <civodul>to me, building core is just to get notified when we introduce regressions <civodul>i think the branch will remain open for a while <mark_weaver>civodul: sure, I don't think we should long delay getting that feedback about regressions, but maybe it's worth waiting a short time to get these two changes in before building, dunno. <civodul>let's say we wait a couple of days before starting it? <civodul>and so if you have time to work on these things by then, that's perfect <a_e>How about starting just the core packages now already? <a_e>There is not much else to do for hydra right now. <civodul>i guess it depends on how frequent rebuilds are <civodul>at the same time there's no rush so i'm happy to wait for the other patches <mark_weaver>civodul: so, I'm a bit uncertain of how to add the --build option by default without breaking cross-compilation. I don't have a clear picture of how cross compilation is handled. any hints you could give me would be appreciated. <a_e>Can I push libreoffice? It looks like a very ordinary package now after the xmlsec tarball simplification. <civodul>mark_weaver: the 'configure' phase simply checks for #:target, and adds --host based on this <civodul>a_e: just replied to the message, sorry for the delay <a_e>No problem. One day is hardly a long delay... <civodul>writing tests for verify-store is harder than expected