IRC channel 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

IRC channel logs

2016-06-02.log