IRC channel logs

2016-06-02.log

back to list of logs

<lfam>It would be cool if we distributed Krita
<notadrop>guix is amazing
<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>^5 everyone involved with this project
<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>lfam: I have a GUI environment as well
<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
<lfam>It's just called connman-ui. Debian distributes it as connman-ui-gtk. https://github.com/tbursztyka/connman-ui
<lfam>It seems there are also some "extensions" for GNOME 3. I don't know what those are. https://extensions.gnome.org/
<civodul>Hello Guix!
<civodul>how did we handle the pypi URI change?
<civodul>i remember this was discussed but i forgot what the outcome was
<davexunit>civodul: was it with 2 source uris?
<civodul>not sure, i can't find an example of that
<davexunit>ah okay
<davexunit>perhaps my memory is faulty then
<davexunit>thought I recall you suggesting this
<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>ifur: cool, ok!
<civodul>ifur: make sure to look at https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html ;-)
<bavier>ifur: ooo, cgal!
<bavier>according to http://doc.cgal.org/latest/Manual/installation.html#secessential3rdpartysoftware we should have the required dependencies packaged already
<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
<mark_weaver>anthk_: try passing --system=i686-linux
<civodul>mark_weaver: i got a few debugging hints from people on #gcc/oftc, so i'll try that later today, hopefully
<civodul>ttyl!
<anthk_>mark_weaver, uname -r still returns x86_64
<anthk_>uname -m sorry
<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>but 'uname' is the wrong tool for this.
<mark_weaver>anthk_: "gcc -dumpmachine" should tell you also
<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
<anthk_>x86_64-unknown-linux-gnu
<phant0mas>civodul: there is -lihash in libpthread's makefile
<phant0mas>this shouldn't have happened
<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
<mark_weaver>anthk_: bug-guix@gnu.org
<anthk_>mark_weaver, done
<mark_weaver>thanks!
<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>propagated-inputs do not help here
<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
<civodul>aargh, cmake
<ifur>yeah, looking there now :)
<civodul>cmake-build-system is supposed to do the right thing
<civodul>that's what you're using?
<ifur>yeah, using cmake
<ifur>but scientific software, so cant expect much
<civodul>i'm asking about the 'build-system' field; is it 'cmake-build-system'? https://www.gnu.org/software/guix/manual/html_node/Build-Systems.html#index-cmake_002dbuild_002dsystem
<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>ijp: footnotes?
<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.
<ng0>i only saw a [4]
<adfeno>ijp: It's to avoid flooding.
<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>ijp: speaking of which, has the #emacs crowd seen that: https://goblinrefuge.com/mediagoblin/u/alezost/m/emacs-interface-for-guix/ ? :-)
<lumidragon>civodul: is it available on guix already?
<civodul>of course!
<civodul> https://www.gnu.org/software/guix/manual/html_node/Emacs-Interface.html
<civodul>it's under-publicized, but it's really great stuff
<lumidragon>kk nice :)
<lumidragon>I'll take a look
<lumidragon>always open to doing more from emacs.
<defanor>hello. does guix build everything from source?
<lumidragon>does it background the guix commands though?
<lumidragon>defanor: yes
<civodul>defanor: yes, except in cases where bootstrapping issues make it impossible
<civodul>though we're looking for ways to improve on that
<civodul>lumidragon: yes
<lumidragon>cool gtk :)
<civodul>it's connected to a Guile process via Geiser
<lumidragon>wow even more interesting.
<lumidragon>speaking of Geiser, is there a way to run it using the ./pre-inst-env ?
<lumidragon>guile in geiser I mean
<civodul>you could run "./pre-inst-env guile --listen" and then use M-x geiser-connect
<lumidragon>thanks, didn't know guile had repl sever.
<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>in guixsd*
<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.
<lumidragon>just a min
<defanor>oh, found something in section 7.2.1
<lumidragon> https://www.gnu.org/software/guix/manual/
<defanor>thanks
<lumidragon>I added the pdf version to my library :)
<lumidragon>take ur pick.
<lumidragon>that will be guix "bible" so to speak.
<lumidragon>np yw
<zacts>hi
<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.
<mark_weaver>ACTION goes afk
<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>indeed
<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.
<mark_weaver>yes, the BBB is much better
<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
<mark_weaver>zacts: both BBB and RPi are ARM systems
<mark_weaver>ACTION goes afk
<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