IRC channel logs
2016-06-02.log
back to list of logs
<lfam>It would be cool if we distributed Krita <notadrop>why does anyone use a different package manager? <notadrop>the option for install is -i !!! it seriously cannot be more of a pleasure to use <notadrop>What daemon, program, or whatever is used to manage (wireless) networking in GuixSD by default, from the shell? <lfam>notadrop: I think that wicd has a console based client <lfam>notadrop: There is also connman, and it's program connmanctl. I actually prefer connman although learning to use connmanctl is not that easy if you only have a console <lfam>Actually, I see that Debian's connmanctl man page is not as bad as I remembered... <notadrop>i'll check out connman... clever name... <lfam>There is a graphical interface for it — connman-ui-gtk. But we don't have it packaged... yet <civodul>how did we handle the pypi URI change? <civodul>i remember this was discussed but i forgot what the outcome was <civodul>not sure, i can't find an example of that <ifur>civodul: w.r.t. cgal i'll keep a todo list, can do a pull request for physics.scm along with that fix when i get further along <ifur>still plowing through a rather long list of tools and dependencies :S <civodul>roelj: FWIW i'm looking at IpOpt right now <civodul>if you already have it, i'm interested! :-) <mark_weaver>civodul: sorry, I don't have time to investigate the armhf gcc bootstrap problem <mark_weaver>it's too bad, I was eager to update to gcc-5 for arm, because gcc-4 has a code generation bug on arm that I had to workaround in the openssl package, and who knows how many other places the bug shows up <mark_weaver>another thing I don't have time to investigate now is whether our gdk-pixbuf needs a security update. <anthk_>hello, can I create 32 bit cointainers on x86_64 <civodul>mark_weaver: i got a few debugging hints from people on #gcc/oftc, so i'll try that later today, hopefully <anthk_>mark_weaver, uname -r still returns x86_64 <mark_weaver>anthk_: uname reports the kernel version. try using 'file' on of the executables within <anthk_>guix environment -N --system=i686-linux --ad-hoc --container gcc@4.9.3 glibc coreutils sdl2 clang yasm mesa mesa-headers bash -- bash <anthk_>in theory I could compile some 32-bit only software <mark_weaver>or just compile a little program that prints the size of a pointer <mark_weaver>but if you include 'file' in there, then you can run it on the programs to find out <mark_weaver>for 32-bit, it should report "i686-unknown-linux-gnu" <civodul>anthk_: use the 'gcc-toolchain' packages instead of gcc/glibc/binutils <phant0mas>I have a really strange problem, which suddenly appeared now <phant0mas>when building cross-libc for Hurd, even though libihash.a is in CROSS_LIBRARY_PATH I get undefined references to funtions from libihash <civodul>phant0mas: is there -lihash on the link command line? <anthk_>ander@antelope ~/Desktop/git/NFSIISE [env]# gcc -dumpmachine <phant0mas>civodul: there is -lihash in libpthread's makefile <civodul>anthk_: indeed, it seems that -s is ignored; could you email bug-guix about it? <anthk_>civodul, bug-guix@ which domain? <phant0mas>civodul: I cannot find any change that may have caused it <phant0mas>I will use an older glibc version that surely worked and see what happens <ifur>have this software package here that comes with a c/c++ interpreter that depends on gcc and libstdc++ but even putting into propagated-inputs doesn't let it validate runpath, it seems to be just libgcc and libstdcc++ missing.... <ifur>is this when i need to wrap? <civodul>ifur: that's due to a missing -Wl,-rpath=/path/to/gcc/lib <civodul>'validate-runpath' simply ensures that every lib a shared library or executable refers to can be found in its RUNPATH <civodul>(RUNPATH is a shared lib search path embedded into ELF files directly) <ifur>so just add that to make flags? <civodul>it depends on the package's build system <civodul>if you grep for "-Wl,-rpath" in gnu/packages/*.scm, there are several examples <ifur>cmake, but there is still autotools being phased out <ifur>yeah, looking there now :) <civodul>cmake-build-system is supposed to do the right thing <ifur>but scientific software, so cant expect much <ifur>civodul: yes, its cmake :) but the package still works with autotools AFAIK (not tested) as they are moving towards cmake <adfeno>I just had a complex debate on #gnu. It seems some people are refusing to educate society on the real importance of free software. [4] <ijp>where does #emacs keep its footnotes? <ifur>the double meaning of free is what really needs to go away :( <ng0>footnotes in irc, i mean? <ijp>I was just noting that adfeno finished their sentence with "[4]" <ng0>irc has no support for footnotes. <ifur>#emacs may have a solution, hehe <ijp>whoops, maybe #guix isn't as familiar with my humour as #emacs is <adfeno>Also, I pause for some seconds to also avoid flooding. <ng0>just assume that no one can read sarcasm and humor where it is supposed to be, some languages don't transport it as well and text makes it difficult :) <ng0>well not like that... but close to this <ijp>humour is about knowing your audience, and mine is in another buffer <ifur>the audience you know you mean, have an adventure and explore a new one :P <civodul>it's under-publicized, but it's really great stuff <defanor>hello. does guix build everything from source? <civodul>defanor: yes, except in cases where bootstrapping issues make it impossible <civodul>though we're looking for ways to improve on that <civodul>it's connected to a Guile process via Geiser <lumidragon>speaking of Geiser, is there a way to run it using the ./pre-inst-env ? <civodul>you could run "./pre-inst-env guile --listen" and then use M-x geiser-connect <ifur>civodul: found a -Drpath=ON option w.r.t. low expectations *fingers crossed* <defanor>is there fstab in guix? what will `mount -a` do, is it patched to handle the system config? <defanor>ah, looks like the system config just adds entries into fstab <defanor>i can't see ifupdown among packages. is it called differently, or is it just not included? <defanor>and how do you configure network in guixsd? <lumidragon>defanor: maybe someone can elaborate further if need be, but everything system wide goes to your /etc/config.scm. Then you run guix system reconfigure /etc/config.scm. <defanor>lumidragon: thanks. is it documented in the info file somewhere? <lumidragon>you see the manual it has lost of info on using guix system reconfigure <defanor>(i'm just building the system now, can't quite poke it) <lumidragon>you either use info guix, or the web let look up the link for you. <defanor>oh, found something in section 7.2.1 <zacts>mark_weaver: I'm wondering if Gnu GUIX SD supports the beaglebone black (even if not pre-built packages) <zacts>mainly because they just released the full schematics to the BBB as Creative Commons Share Alike <zacts>and I'm trying to see if the FSF can verify that it meets the Respects Your Freedom certification <zacts>if it does meet the RYF requirements, it might be an idea to discuss. dont' know. :-) <zacts>mark_weaver: I can also donate a full beaglebone black with the case and everything to the project <zacts>I can't currently donate financially though, due to weird logistics in my country, but I can send mine out to you guys. <civodul>defanor: on GuixSD, /etc/fstab is generated based on the OS config <mark_weaver>zacts: thanks for the offer, but BBBs are quite cheap and not useful as a build slave. <mark_weaver>Guix should run on a BBB, but at present it needs to be running on top of another OS. GuixSD doesn't yet support any ARM system. <mark_weaver>iirc, although the BBB can run a fully free OS, there are components, e.g. its GPU, that can't be used without non-free software, so I don't think it could meet the RYF requirements. <ng0>same goes for raspberry pi, following the discussions in #libreboot <zacts>mark_weaver: thanks for the info <zacts>mark_weaver: for some reason I thought that the BBB was a RISC architecture <mark_weaver>the raspberry pi is much worse: it can't even boot without an entire non-free OS running inside its GPU first. <zacts>I'm supporting the bbb over the rpi <mark_weaver>or at least that was the case with the original RPi. not sure about the newer one. <zacts>maybe I can get a local startup to build a new version without the devices that contain blobs <zacts>I know of some hardware geeks <ng0>the newer one is said to be reverse engineered, but it is basically unusable <ng0>for libreboot purposes at least <zacts>I might look into a BBB without blobbed components for a RYF certification <ng0>the free rpi can do uart only i think <zacts>if my geek friends can afford it or something, maybe I could start a kickstarter