<paroneayea>do we delete then add the symlink for setting up a new profile <paroneayea>I was told the latter is atomic, but the former is clearly not <paroneayea>apparently at some point joeyh tells me he was looking at nix and seeing they did the former, so it was a small hole of non-atomicity <mark_weaver>paroneayea: we rename. see 'switch-symlinks' in guix/ui.scm <mark_weaver>paroneayea: it was a good question though, thanks for bringing it up! I didn't know the answer until I just looked in the code :) <codemac>I use "libreoffice-still" with archlinux, has anyone looked at packaging it for guix? <mark_weaver>codemac: I don't think anyone has looked into it. would you like to try? <codemac>Yea, I'll probably try tonight. It's a rough one to package so we'll see ***Steap_ is now known as Steap
<rekado>I think I know why I was having so many problems with packaging jupyter: the Guix package for ipython provides version 3.x, but the latest is 4.0.0. <rekado>I'll submit patches to update this and fix the inputs (many are declared as regular inputs even though they need to be loaded at runtime and thus should be propagated). <csed>Anyone here of know of a good netbook? <rekado>ipython needs ipykernel for tests, ipykernel needs ipython for tests. :/ <Steap>rekado: disable the ipykernel tests for now :) <rekado>also: ipython seems to depend on jupyter_client for the tests, but jupyter_client depends on ipython. <rekado>I don't know in which direction the dependency actually points. <Steap>this kind of things is such a pain <rekado>so, maybe I should disable the/some tests for ipython. <rekado>"some" is probably best, because it has 500+ tests of which 8 fail. <rekado>even more cycles: ipykernel loads jupyter-client at runtime, which depends on jupyter_core, which depends on ipython, which depends on ipykernel. <rekado>I don't understand this enough to know where to cut the loop. <Steap>rekado: I don't even know how people figure this out in the first place <rekado>the more I look around the more cycles I uncover. <Steap>rekado: I had to package old versions of some packages just to bootstrap newer versions :D <civodul>rekado: aren't all these things part of the same jupyter or ipython package? <civodul>(i thought "Jupyter" was the new name of "IPython", no?) <rekado>I'm just trying to upgrade our IPython package to 4.0.0. <rekado>it depends on many new modules, so I packaged them. <rekado>the Jupyter packages are separate. <rekado>and they depend on the latest ipython package, as far as I can tell. <rekado>I don't know. They seem to be different packages. <rekado>I broke the cycles by disabling tests on jupyter-client and removing jupyter-core from the client package. Tests for ipython almost pass now. <civodul>this is terrrible, thanks for taking care of it <csed>civodul: Jupyter uses IPython. IPython is just like, the kernel for Python in Jupyter, as far as I know. <mark_weaver>civodul: did you know that andreas was adding his own armhf machine to the build farm? <civodul>mark_weaver: he told me he wanted to do that, but that he couldn't guarantee 24/7 connectivity <civodul>so that was only feasible if some other machine was available full time <mark_weaver>I first noticed because of some aborted builds yesterday, due to a permissions problem in /var/guix/gcroots/tmp <mark_weaver>no worries. obviously armhf is having trouble keeping up with only one machine (and only running with 2/4 cores enabled) <mark_weaver>the default kernels that came with the novena's I've used (mine and the one donated by sprang) were missing some features <mark_weaver>which led to test suite failures in some of the core packages <civodul>could you reply in that thread on guix-sysadmin? <civodul>i wonder if Andreas checked that already <civodul>i think he did because he's been using Guix on it for some time, but not 100% sure <mark_weaver>that particular problem may only show itself in a few packages <amz3>Ten Rules for Open Source Success (Peter Hinjens) <amz3>sorry I mean to post it to guile ***exio4 is now known as y
<civodul>the rules are well-written & interesting <davexunit>but I'll look past it for its pro-copyleft stance and "people over code" general theme <civodul>davexunit: yeah "merge first" is a bit too strong <paroneayea>depending on your community structure, it can sometimes be okay to take that route <civodul>mark_weaver: yet i'd be in favor of merging first and upgrading later; thoughts? <davexunit>paroneayea: within reason. lately we've had a contributor that wants us to a bit too much of that. ;) <paroneayea>orgmode when under bastien seems to have all sorts of crazy code flying into it all the time and it has served the project well during those periods because the userbase tests the bleeding edge so much <paroneayea>sometimes blender is this way too, though it has gotten more careful over time <paroneayea>a memorable blender conference talk by Ton Roosendaal the Blender lead dev, he said "We accept *all kinds* of terrible code by artists!" <paroneayea>usually the terrible code is the addons at the periphery <mark_weaver>civodul: I agree. let's not delay this core-updates branch any further <civodul>what concerns me is that when we merge core-updates people will realize about incompatible locales <civodul>suddenly many will get the infamous assertion failure in loadlocale.c <civodul>i think the libc people should do something about it <mark_weaver>civodul: ah, well, that's a different issue which I know nothing about. <civodul>ah yes right, that's a completely different issue <civodul>all i'm saying is that we'll get complaints <mark_weaver>civodul: if you think we should address that issue and delay the core-updates merge, I'm okay with that, but then we'll need to build out the icu4c security update on master. <mark_weaver>but this is the first I'm hearing about this locale issue, so I'm totally ignorant about it at present :-/ <civodul>mark_weaver: i do *not* want to delay the core-updates merge <civodul>i've just sent an email regarding the locale issue <civodul>at the times i didn't think of patching libc so that it gracefully handles the situation <mark_weaver>civodul: no worries, you are only one person, although sometimes I wonder how you manage to get so much work done :) <mark_weaver>similarly, I regret not finding the time to add support for compressed patches to patch-and-repack in this core-updates cycle, so that I could push out the linux-libre-4.2.1 update now. <mark_weaver>but we'd best wait for lxo to do the official release <lfam>builder for `/gnu/store/...-coreutils-8.24\\' failed previously (cached) <lfam>Is there a way to clear the cache and try again? <lfam>Or do I need to update my cache of upstream packages? It seems that hydra successfully build armhf coreutils-8.24 and I'd like to get that. <mark_weaver>lfam: caching failed builds is not done by default, and I've never used that feature. I don't know off-hand how to clear the cache. <mark_weaver>regarding the armhf builds on hydra: those are on the 'core-updates' branch. the only way to get those is to build guix from a git checkout on the core-updates branch, and then use that guix to build/install packages. <mark_weaver>they will be more easily available after the core-updates branch has been merged into 'master'. <mark_weaver>lfam: did you add an option to enable caching of failed builds to guix-daemon? <lfam>Does guix pull pull from master? <lfam>Yes, I did enable that, in the systemd service file. I misunderstood the availability of the core-updates branch. I'll wait for them to be merged into master. <mark_weaver>civodul would surely know how to clear the cache of failed builds <mark_weaver>(I could find out by reading the code, but it's more efficient to just ask him :) <lfam>It seems like that would be achievable with guix gc <lfam>But if coreutils isn't available yet on master, there's no point. It will probably be merged before my ARM board is done compiling <mark_weaver>it will want to use binaries that you don't yet have to compile 'guix'. <mark_weaver>well, I take that back. those binaries might be substitutable. ***codemac` is now known as codemac
<rekado>Has anyone here successfully used libmtp / gmtp with a Samsung Galaxy device? <rekado>(or *any* device for that matter?) <rekado>I don't have an Android device and am trying for the first time to copy files to one of these annoying devices, but I cannot seem to find a way to do this right. <umbilical>I just finished the installation process (again) described in the manual <umbilical>but I'm afraid to reboot because it always ends up reporting some error <umbilical>maybe I'm still missing something after the install <rekado>never mind, it actually works (after "chown root:users -R /dev/bus/usb/"), it's just really slow to connect. <rekado>(one reason why it may be slow is that it opens images from disk again and again rather than doing it once) <alezost>umbilical: what do you mean? with "loadkeys"? <umbilical>It was in a weird path '/gnu/store/z11w0....................' <umbilical>It'll take me time to get used to this distro I guess <alezost>umbilical: most of the time there is no need to use /gnu/store. What did you try to do? <umbilical>alezost well the usual: loadkeys /usr/share... but there's not even /usr dir <alezost>umbilical: why do you use /usr/share/...? You can just do "loadkeys dvorak" or something <daviid>there is a video presentation of the project somewhere, col to see <mark_weaver>daviid: christian grothoff of gnunet fame is one of the key people behind taler <mark_weaver>daviid: sorry, I didn't intend to address that to you <daviid>mark_weaver: it's a wonderful project, I habe been impressed by the maturity of the leader, I mean the one who presented what I've seen on the video <davexunit>mark_weaver: I noticed that shortly after I posted the link. this is really interesting to me. <davexunit>seems to avoid the issues I have with bitcoin <davexunit>paroneayea: cool. need to read later. gotta run now!