<ng0>I'm deleting checkouts.. did I just post dbacl and asked for help, or is someone working on that? <ng0>i know i got a reply to the licensing question, but I just have no time to ask fsf about that. so deletion of files is my sledgehammer option <ng0>conversation requires spending time on writing, emailing back and forth and not letting it drown in the flood of emails I get.. so if there's a shortcut I always take that first <ng0>but if I can avoid yet another discussion, I do so <ng0>i think as no one replied to my idea of replacing the content of the file, I take it as a yes and go ahed <ng0>because that was 2+ weeks ago <ng0>i think the replies about gpl translation were clear <ng0>so replacing content with added comment is okay for me <ng0>I'll rebase, send the patch for review and then I can sleep <paroneayea>davexunit: got wip-deploy rebased and working :) <ng0>alright, I'm done. listening to bohren & der club of gore now.. good night <marusich>I've noticed that the following file systems are mounted in my GuixSD system: <marusich>this guy: /dev/sda1 on / type ext4 (rw,relatime,data=ordered) <marusich>and this guy: /dev/sda1 on /gnu/store type ext4 (ro,relatime,data=ordered) <marusich>How is it possible for /dev/sda1 to be mounted at two separate mount points? <marusich>I guess that isn't my question, really; I can imagine how that is possible. But what I don't understand is how /dev/sda1 can contain both the root fs and simultaneously the /gnu/store file system; it seems impossible <mark_weaver>marusich: it's a read-only bind mount. essentially, it's not the root filesystem of /dev/sda1 that's mounted on /gnu/store, but rather a subdirectory of /dev/sda1 that's mounted there (and with different mount flags) <mark_weaver>e.g. search for "bind mounts" in the documentation for "mount --bind" <paroneayea>davexunit: I had to a couple of small things but yeah, it's good! <paroneayea>an import moved and some autotools stuff moved around <paroneayea>I asked if someone else wants to merge my brother's patch <paroneayea>I guess I did review it? that's probably good enough? <paroneayea>though, I'm a bit unsure about if we made the right decision to include all those patches I guess. <paroneayea>ACTION flipflops on the floor like a fish, or cartoon politician <paroneayea>well there's an error in the patch which I just noticed ;) <reepca>Question... in the GRUB boot menu, does the time/date next to a configuration mean "when that configuration was effected" or "when that configuration stopped being in effect"? Asking because I'm trying to figure out which configuration I should use to reproduce that "--load-path not being honored by guix system" thing <atw>is there a good way to search the channel logs? <paroneayea>atw: well, there are logs that are public, but I don't knwo about searching them :) <atw>lol, yeah, I can't find the silly question I asked earlier about suspending in guix. Can't find it in my bash history either, sooo...if someone could enlighten me (again) :P <orbea>does guixsd have pm-suspend? <orbea>ACTION notices he is late to the suspend question anyways <atw>orbea: I think my installation doesn't, hence why I went looking <ZombieChicken>I'm having troubles connecting to websites with it and just wanted to know if someone else might be having the same problem <phant0mas>alabd14313: get a debian/hurd vm and try to build guix master on it, tell me where it fails :-) <wingo>building "gnome" currently fails in core-updates: <wingo>"xmllint --valid --path "." --noout ./Locations.xml <wingo>./check-timezones.sh ./Locations.xml <wingo>Invalid timezones in ./Locations.xml: Asia/Rangoon <wingo>make[1]: *** [Makefile:828: check] Error 1 <wingo>guix system: error: build failed: build of `/gnu/store/sjahwvddwr2akss635wvyh2v9wgbhdbn-gnome-3.20.4.drv' failed <jmd>Do we know why it fails? <civodul>wingo: 'gnome' itself doesn't do anything beyond propagating things, so it must be one of its dependencies ***orly_owl_ is now known as orlyowl
<domenkozar>Hmm, I wonder how does Guix achieve purity (restricting all IO operations during the build)? <jmd>domenkozar: Namespaces <domenkozar>jmd: what about before building in namespaces, like fetching sources, etc? <jmd>I think it fetches in one namespace then switches to another for the buld. <domenkozar>so in that case, fetching namespace still needs to check hash for example, how does it enforce that on the language level? Or does it take all the things fetched and hash them? <domenkozar>civodul: hey man, sorry for mention-bot spam, hopefully it will be fixed soon :) <wingo>domenkozar: i think that the fetcher knows what hash it's looking for <wingo>so it fetches and then verifies before adding to the store <wingo>so that hash is part of the command line or derivation or whatever that's running in the fetcher <wingo>i didn't know that guix's fetchers use namespaces tho, but i am very ignorant there <domenkozar>yeah I'd like to read more about how purity here is achieved with general purpose language with libs like http fetching <domenkozar>civodul: are there any docs resources about that? ***tschwing_ is now known as tschwinge
<ng0>how would we go ahead if we want to change slim to gdm as the default (well currently only) login screen/manager? <ng0>or even sddm or lightdm or whatever has a concept of more than en-us <ZombieChicken>Hrm. So apparently disk-image builds in /gnu/store. That is rather painful <ng0>oO which archaic group do I need to add myself to so that Guix does detect the DVD I need to burn an .iso to as valid? <civodul>domenkozar: Guix achieves isolation pretty much like Nix, except that there's no /bin in the build environment <civodul>ACTION has to go offline for a moment <ng0>so our Brasero is limited to burning CDs... <ng0>and we have no `crecord' providing application, and no k3b. what can I use to burn an iso to DVD here? <ng0>these are last tiny bits where I think, hey I think I'd rather run GuixSD in a VM on a system I know until I have fixed what I think is missing <ng0>I think I will try dual booting with gentoo hardened for a while.. I'll be back in a couple of days <dale>I can't add new users; running config GUI complains no accounts-service. Have guix package -i accountsservice but still no joy <quigonjinn>sorry for spamming. i messed up while cleaning my keyboard <civodul>domenkozar: sorry for the latency; did my earlier reply make any sense? :-) <rekado>ACTION is working on ant-build-system again <domenkozar>civodul: so my question would be, how do you prevent someone from using Guile readFile function (however it's named, a function that returns contents of the file) and pass it to the derivation? <civodul>domenkozar: same as Nix i guess: chroot + resolv.conf etc. <civodul>so anyone can make and build a fixed-output derivation <civodul>but that derivation cannot do more than what the user can do <domenkozar>so guile is always executed within the derivation? What about the code that glues derivations together? <civodul>that code is Guile code (instead of Nix-lang code) and it runs as the user <civodul>so in a build farm context running untrusted "host side" code, one has to be careful <domenkozar>and the whole guile code is ran inside some namespace? <civodul>no, there's no reason to do that usually <domenkozar>so that code could access something locally and introduce side-effects potentially <domenkozar>civodul: I'm probably missing something here, bare with me <civodul>domenkozar: right, that code can do anything the user can do <jmd>domenkozar: I think you mean "bear" with me. <civodul>domenkozar: that's why i'm saying that it's not great in a build farm context <jmd>Unless you wish civodul to engage in naturism with you. <civodul>but compared to the Nix language, it's easier to do things like I/O etc. <domenkozar>ok so Habitat is similar, except it builds in Docker and uses bash <domenkozar>at least "purity (referential transparency)" wise <civodul>though in a build farm context where users of the build farm are untrusted, you'd want to run code, even Nix-lang code, in some sort of a sandbox <civodul>so Habitat support referentially-transparent builds? <domenkozar>yeah Hydra does the same for Nix to restrict it as possible <civodul>domenkozar: okay, that's what i thought :-) <davexunit>civodul: do source derivations use any isolation at all? <davexunit>seems like they could isolate just as much as any other derivation, but just share the host network namespace. maybe that's exactly what they already do, in which case ignore me ;) <civodul>davexunit: yeah fixed-output derivations run in a chroot, but in the host network namespace <civodul>the other namespaces are always separate <civodul>i mean it's the same as any package management tool <domenkozar>civodul: the point is, they download files and check hashes <davexunit>is this a hashicorp tool? those folks are hilarious. <bavier>oh, looks almost like the bash-based package manager I work at $work :) <sneek>Welcome back bavier, you have 1 message. <sneek>bavier, reepca says: it looks like either something's messed up with the package and we're missing firmware (currently only have b0g0bsinitvals5.fw, b0g0intivals5.fw, and ucode5.fw) or something bizarre is happening with linux 4.8.1. I'm gonna try manually building it and see if I get the same files as output <domenkozar>davexunit: I think what is horrible is betting your million $ startup on that <davexunit>ACTION uses chef every day, right now in fact <reepca>bavier: disregard that, I was an idiot, the firmware seems to work with just changing b43 to b43-open <domenkozar>2 years ago, Chef folks were laughing on my blog <civodul>domenkozar: someone at ICFP said "you can't value something you don't understand" <reepca>bavier: yeah, I wasn't using ifconfig -a and was just using ifconfig to list available interfaces. Felt really stupid once I figured that out. <davexunit>people just keep trying this "start from a blob base image and run bash" method of config management <civodul>domenkozar: and i think we have to show Chef users how we'd do the same thing using NixOps & co., and what it would bring <civodul>and we have to show it many times ;-) <bavier>reepca: cool, I'll work on cleaning it up to commit then <civodul>bavier: so BigCorp, Inc. works on a Bash-based package manager? interesting :-) <reepca>bavier: would it be added to %base-firmware then, or still have to be included by the user in config.scm? <bavier>reepca: idk. civodul, what do you think? <bavier>civodul: actually, I wrote it myself, and afaik I'm the only one who uses it. I needed something much saner than "modules" <davexunit>who would design a tool in 2016 that used bash as its programing interface? <domenkozar>davexunit: the same people who were born with it? <domenkozar>but I'll shutup now since I don't want to break code of conduct :) <davexunit>I feel like I can trash Opscode a bunch because I have spent soooo many hours using their software. <davexunit>to their credit, I get stuff done with it, but it sure isn't a pleasant experience. <bavier>reepca: I think we could include the b43 firmware in the base image since its only 36k <civodul>a good thing, because it means it's slowly coming to a declarative approach <efraim>729 minutes later, I can confirm that julia FTBFS on my machine <sneek>efraim, lfam says: Lots of onionshare's dependencies are failing on core-updates. Maybe you want to try fixing them? :) <davexunit>ACTION tries to think of something pronouncable for "FTBFS"... footbuffs! ... <rekado>efraim: some of the tests fail again <thomasd>I'm wondering where the suggested paths in guix --search-paths come from <thomasd>and related: I have packaged a C library with a python wrapper, and wonder if there's a way to help the user set the appropriate $PYTHONPATH to use it. Is there a way to specify those things in your package definition? <bavier>thomasd: packages define "native-search-path"s <thomasd>I was under the impression those would be used at build time <bavier>thomasd: in the case of a python wrapper, if its installed somewhere that the python package has declared as a native-search-path, then it will be found <bavier>thomasd: the search-paths are "native" in the sense that they're native to the package itself <thomasd>so that's quite different form native-inputs? <bavier>thomasd: to correct myself, a package may also define a "search-path" <thomasd>originally I had done that, to no effect <thomasd>with native-search-path, I get the suggestion to add ~/.guix-profile/lib/python... to my PYTHONPATH when I install the pacakge <thomasd>so what's the difference exactly? I don't find it in the manual (in the manual, it seems like both variables are the same) <bavier>thomasd: "search-path" seems to be used only for cross-building <thomasd>you got that from the source? maybe I'll submit a patch to the documentation if/when I understand this better <adfeno1>Do we have a contact/addressbook manager suporting vCard/VCF files? <adfeno1>I mean: direct editing of these files. ***adfeno1 is now known as adfeno
<wingo>icecat build failure on core-updates: <wingo>ld: ../../xpcom/components/nsComponentManager.o: relocation R_X86_64_PC32 against protected symbol `end_kPStaticModules_NSModule' can not be used when making a shared object <wingo>ld: final link failed: Bad value <wingo>collect2: error: ld returned 1 exit status <wingo>i expect this is just an error on x86-64, dunno <jmd>Why is xlock setuid ? <wingo>it requires you to enter your password <wingo>but i don't know a more nuanced answer <jmd>Oh so it's just to prevent anyone grabbing it from memory I suppose. <lfam>sneek: later tell adfeno: Khard can be used to edit VCF files <joshuaBPman_>.Hello, I am currently logged into guix (Gnome) as root. As my normal user, I can log in to a tty, but I cannot log into Gnome. Anyone have any ideas how I can fix this? <lfam>joshuaBPman_: What happens when you try logging in as your user? <jmd>I've noticed something wierd with the slim service. <jmd>If I attempt to login with an invalid password, then on the subsequent attempt (with a valid password) it always logs in with WMmaker session regardless of what I've selected with F1 <bavier>joshuaBPMan__: did you set a password for your user account? <jmd>in fact, F1 doesn't even give me a windowmaker option. <lfam>jmd: Yes, that's a known bug. It should be reported in the bug tracker if there is not ticket for it <davexunit>it's been around for as long as I've been using GuixSD <lfam>It's not a great user experience... especially considering that entering an incorrect password is something a new user is likely to do <davexunit>I think windowmaker is hardcoded as a fallback session or whatever slim calls it <joshuaBPMan__>bavier: I am currently dual booting. I should probably try reconfiguring my current scheme OS file. <lfam>This bug needs a champion :) <davexunit>we only used it because it was the easiest thing to get running <davexunit>but nowadays we should be able to use GDM or something <jmd>lightdm or whatever it's called is not such a beast. <civodul>lfam: i have a variant of the recutils patch i posted ready! <paroneayea>I STR that GDM uses a systemd specific way of specifying different session options now <civodul>ACTION wonders who's gonna talk about Guix at LibrePlanet this year <paroneayea>I think I bumped into this because stumpwm didn't show up as an option despite it showing something <paroneayea>davexunit: I've thought about it... I'm not sure what new things to say for an LP audience though <davexunit>I haven't made any real progress since last year I guess... <paroneayea>it might be interesting to talk about Guile's role in GNU <civodul>+1 for the dynamically typed duo! :-) <paroneayea>and also thinking about how in a sense, "the emacs of distros" is kind of because emacs was a "poor man's lisp machine" immersed in a *nix'y environment <davexunit>"welcome to the lisp machine" is my favorite pink floyd song <joshuaBPMan__>Yeah your guy's talk was awesome! I just watched it again this morning. haha. <paroneayea>but the real dream of guile in gnu is bringing a lot of that dream together, fusing the hackability of lisp machines with the... well, widespreadness of posix :) <davexunit>paroneayea: guixsd just kind of makes the solution more concentrated <paroneayea>I'm also thinking of giving a talk at LP on an update on federation, esp since activitypub will hopefully be out by then <paroneayea>and standardizing a decentralized, free web is maybe an interesting talk <paroneayea>I want 2017 to be the year of guixsd deployment though :) <paroneayea>and then in 2018, we can be like "see how we talked about all this stuff? IT'S HAPPENINGGGG" <paroneayea>some day maybe I'll give a potentially heretical talk <paroneayea>"What would GNU be like if it started as a lisp machine?" <paroneayea>which, I know there are reasons it didn't, and rms documented them (basically, *nix was portable at least well understood-ish, and it was unclear they'd make the right decisions in a lisp machine) <paroneayea>anyway, yeah, Guix + Emacs, and you can get closer to something resembling that dream by the day ;) <joshuaBPMan__>paroneayea: RMS I believe said that the LISP machine was pretty poor at seperating user space applications and system specific applications. I'm no lisp machine expert, but I think he claimed that *nix was more secure. <paroneayea>the great things about fictional history is you can be smugly right about all the things that would happen the way you want them to and pretend that all the downsides don't exist ;) <paroneayea>joshuaBPMan__: hm, I"d be interested to see where he said that <paroneayea>I'm somewhat skeptical that security was rms' reason at the time <joshuaBPMan__>I'll do a quick google search and see what I can find, but it was just something I vaguely remember hearing. <paroneayea>given that at that point he was very pro "everyone has access to teh whole machine" <paroneayea>though of course, unix style security isn't very good either. <paroneayea>but one of the "cool things" you could do in lisp machine systems is shove objects between processes, which is pretty awesome, but yeah not secure. <paroneayea>we'd all be way better off if we were using capability style security systems though <paroneayea>I guess the Hurd tried to fuse the capability + posix worlds. I remember there being some writeup in that famous hurd critique paper that this was hard to do though. <joshuaBPMan__>It is kind of a shame that the Hurd development is a bit slow. I really admire the developers, but I image it gets hard trying to do the awesome things they try to do. <joshuaBPMan__>also I did find this "At first, I thought of making a Lisp-based system, but I realized that wouldn't be a good idea technically. " <paroneayea>I think his big worry was at that time it wasn't very portable <paroneayea>lisp machines were very tied to their hardware, at the time <lfam>Hm, python-file is somehow broken on core-updates, breaking diffoscope. <rekado>finished packaging supertuxkart and then realised that the graphics chip in my X200 is inadequate. <rekado>only supports OpenGL 2.1 but I need 3 for supertuxkart. <lfam>In the diffoscope tests: E OSError: /gnu/store/bak3z26x0whlxgm97g9swqamksjaikh5-file-5.28/lib/libmagic.so: cannot open shared object file: No such file or directory <lfam>lrwxrwxrwx 21 root root 17 Dec 31 1969 /gnu/store/bak3z26x0whlxgm97g9swqamksjaikh5-file-5.28/lib/libmagic.so -> libmagic.so.1.0.0 <lfam>How strange! It's obviously a bogus error message <paroneayea>rekado: I wonder if my thinkpenguin mini machine can handle it... <reepca>rekado: if you want to be able to play it with low framerate, you could always install one of those cpu-emulated opengl drivers mesa has <reepca>not so useful for smooth performance, but great for testing and developing on low-spec machines <reepca>you compile mesa to use something like llvmpipe <paroneayea>> At first, I thought of making a Lisp-based system, but I realized that wouldn't be a good idea technically. To have something like the Lisp machine system, you needed special purpose microcode <paroneayea>joshuaBPMan__: yeah, so that's him commenting on lisp machines at the time being tied to specialized hardware <reepca>I did it on my lubuntu install on my laptop, and it worked out for the simple tests I did. I had to keep setting some linker environment variable, though. <joshuaBPMan__>ok. I'm not sure where (or if) I did hear him say that then. <rekado>reepca: I’ll give that a try. Thanks! <rekado>if that’s possible I’d just force the runtime linker to load my variant of mesa with LD_PRELOAD <reepca>I've looked at Mezanno insofar as I've heard of it and checked out the github page. Haven't gotten around to trying to boot it in a vm or anything yet. <paroneayea>CompanionCube: yeah I saw it... it wasn't totally clear to me, is it running with lisp as its kernel too? <CompanionCube>I've never actually used it, but I recall it not having a seperate kernel a la the lispms <CompanionCube>doesn't seem to have a seperate kernel but didn't find enough docs really <paroneayea>CompanionCube: I met someone who had written something like this which was a combination of sbcl + stumpwm + a bunch of other things, and I saw a live demo of it, but he was against it being it properly free software <paroneayea>a mistaken view that "copyright is bad, so thus the only way to fight it is to make the only way to use my software to 'pirate' it, and that's how we'll fight copyright" <CompanionCube>ACTION is a particular fan of Smalltalk which is moderately related <CompanionCube>paroneayea: you can actually emulate a lisp machine on your standard x86 box <lfam>Lol. That's like saying "I ignore politics, so they don't affect me" <reepca>lfam: I really, *really* wish that was how it worked... <lfam>It works until it's too late <paroneayea>lfam: yeah... well, he was going to go move to some other country and set up some kind of Galt's Gulch type thing too which I didn't think would work out on the politics end either <lfam>I would sincerely wish that person good luck. Seems like a fine thing if you can manage it <lfam>Hm, when I add --single-version-externally-managed to python-file, then diffoscope fails in a different way. Progress! <lfam>(I noticed the python-file egg was a zip file) <lfam>As long as the egg is cracked open <jmd>If you plaguerise it from anothe project, then it'll be poached. <lfam>Python-file on master (with Python 3.4.3) is not zipped. But on core-updates (Python 3.5.2), it is zipped. <lfam>I hope not all the Python packages are zipped eggs on core-updates <lfam>That would sure be annoying <jmd>I'm not a python person, but what's the big problem with zipped eggs? <lfam>The store references can't be found by scanning the build output, since they are obscured in the zip file <lfam>So the garbage collector takes too much <jmd>Can't there be a better way of finding such references? <rekado>something about scanning build output always seemed inelegant to me. <bavier>based on mark_weaver's recent investigations, a similar thing seems to happen to compiled packages whose references are embedded in inline code <rekado>bavier: but there’s a compiler flag to avoid this <bavier>rekado: right, but we haven't made that a default flag yet, or have we? <lfam>I wonder if there is a better method than scanning? It seems that, ultimately, you want to see what is _actually_ theere <lfam>Of course, scanning doesn't work if the references are obscured somehow <jmd>When a package is built, the builder knows the outputs, yes? <lfam>What do you mean by "knows the outputs"? <jmd>That is to say, everything that the output references. <rekado>naively I’d say that scanning could be used as a sanity check, but references could be the same as inputs. But maybe there’s a reason I’m not aware of. <bavier>I'm not a Nix expert, but I think it doesn't make the same distinctions between input types as Guix does <jmd>So there could be a build stage which stores all the references in a file . <lfam>What about when a package refers to a native-input, against the desire of the packager? Should native-inputs be registered as references, or should the package break after garbage collection? <bavier>which might be one reason scanning is done <lfam>Obviously that's a packaging error, but still seems like something that should be handled <lfam>What should I say in a commit message for a commit that only adds '("--single-version-externally-managed" "--root=/") to a package's configure flags? <lfam>I guess I don't really understand what those flags do... <lfam>I guess I'll use "Don't create a compressed egg." <bavier>wasn't there a patch on the ML recently that made those flags default in python-build-system? <lfam>I know that Hartmut and Marius are working on a total rewrite of the Python build system, but we decided to use it after this core-updates cycle <bavier>ok, that's probably what I'm thinking of <lfam>Apparently those flags are what you are supposed to use when making "system" packages <paroneayea>something verrrrrrrrrrrrrrry strange has happened. <paroneayea>I did a guix gc recently, I'm not sure if that's related. <paroneayea>efraim: right... do I need to re-run that occasionally or something? <efraim>no clue, is it in your profile? that was the answer on the mailing list recently <lfam>paroneayea: It's the obscured store references bug that Mark reported <ng0>so dualbooting takes a bit longer... just need a gentoo hardened machine again to run some gentoo packaging on, on bare metal again. ... I think what I want to make 2017 is to get guix hardened, finish up uclibc-ng (I'll get back to that use-flags like post civodul had in 2015 I think) and get as close7far as possible as I can get with my current knowledge on guile and advance on the distributed updates etc <lfam>paroneayea: There is a potential compile-time workaround later in the discussion <bavier>I think I fixed the slim-starts-wmaker-session-after-failed-login-attempt bug <lfam>Oh, that would be great! <lfam>I think that would be a big user experience improvement <bavier>lfam: agreed. I think everyone's been bitten by it before <lfam>paroneayea: I was thinking of -fno-builtin-strcpy as a more permanent solution <lfam>Although that would mean a full rebuild <paroneayea>lfam: thanks for staying so on top of things lfam! <lfam>Lol. I'm not on top of things these past few weeks. Work is very busy. I'm idle at work right now! <bavier>so, with what I have now, a login fail will retain the previously-selected session. do we care whether the "press F1 to switch" message remains? <lfam>bavier: I think that message is nice to have, but not loading the wrong WM is more important <lfam>Regarding the store references bug, I guess we'll need to set that option in the gnu-build-system? <ng0>if it's about F1 in general: there's a lack of... everything gdm and others would offer. so without that message you'd be wondering "ok... a login screen... and now what?" <civodul>lfam: not sure about -fno-builtin-strcpy <civodul>we should try to see how frequent the problem is <paroneayea>civodul: I dunno, is any level of frequency safe? <lfam>I think the alternative is to set it per-package <paroneayea>this time it was a font thing, what if it was something more fundamental? <ng0>ideally the frequency is 0 <ng0>so anything which works towards 0 should be advised? <rekado>built a variant of mesa with "--with-gallium-drivers=i915", "--enable-gallium-llvm", and "--with-dri-drivers=swrast", then loaded them with LD_LIBRARY_PATH, but the reported OpenGL version is still 2.1 :-/ <civodul>paroneayea: no of course it's unsafe, but the solution is likely to depend on the frequency and context <civodul>like we should check if __builtin_strcpy is the only thing that does such optimizations <paroneayea>ACTION vaguely paranoid now that this is also related ;) <civodul>seems like a separate issue, but a real issue :-) <paroneayea>civodul: hey, blaming all bugs encountered on the most recently documented bug is a time honored tradition ;) <paroneayea>in happier news, I came to realize that my old package attempt at autossh actually worked all along <paroneayea>(Debian applied patches that required one less flag, but that's not matching with upstream) <civodul>weird that it fails on mips and not elsewhere? <efraim>then again I have a wierd failure with python2-efl that took an extra 2 weeks to manifest on x86_64, and still hasn't showed up on python-efl <efraim>and by wierd I mean weird that it took this long to show up 