<dpg23>lfam: Huh, interesting. mark_weaver: I'll check that out, thanks.
<lfam>But if you "zoom out" from those minor issues, you can see difficulties with even knowing where your binaries came from, which Guix can help with.
<dpg23>lfam: Doesn't apt/dpkg, for example, solve that by signing packages from the repos?
<dpg23>mark_weaver: That was very informative, thanks.
<lfam>dpg23: Those signatures tell you that the package you are downloading was signed by somebody that owned the key used to make the signature. But, it doesn't help you understand how the package was built, or how you could rebuild it
<lfam>Those signatures are just about ensuring that malicious people don't trick apt users into downloading malicious binaries
<dpg23>lfam: So guix builds are signed to prevent malicious binaries and also proves the binary == the source?
<mark_weaver>dpg23: reproducible builds enable *anyone* to independent verify that the distributed binaries are genuine
<lfam>"Sort of" to the first part. No to the second part. All a cryptographic signature tells you is that the signed file was signed by the owner of the key. You have to decide if you trust the key's owner to not be malicious
<dpg23>lfam: Why does Guix use Guile Scheme though?
<dpg23>lfam: Is it just do to being the GNU extension language?
<ijp>probably the main reason is the civodul is comaintainer of guile
<lfam>dpg23: You should ask civodul, I don't want to speak for him :)
<lfam>But, I use NixOS a little bit on the side, and I really prefer the use of Guile over the Nix language. It's great to have the Guix domain-specific-language embedded in a full programming language like Guile.
<rekado>I get this error as I'm trying to build for an Atmega32: "avr-ld: cannot find crtatmega32.o: No such file or directory"
<rekado>it also attempts to link with -latmega32 but this library doesn't exist.
<rekado>I'm pretty sure that it should be crtm32.o.
<rekado>also not good: "avrdude was compiled without usb support."
<rekado>even though we have a patch to make it compile with libusb.
<jlicht>rekado: is avr* the stuff that is used for Arduino as well?
<ng0>i think i might have questions about the 'scripts' dir later, after some more reading, to clarify my understanding of stitching together gnunet-fs with the gnunet.git repo of guix and a gnunet-service and something in between, towards an gnunet-fs based guix pull. I have some ideas which make sense. I'll address that in an email, irc is not satisfying for me for that for long text.
<rekado>I've never used Arduinos; only plain AVR Atmega*
<ng0>well, pull and package and publish and all that.
<ng0>i did not leave, i just idle. but dpg23 left already. i think it's also nicer to not assume pronouns of other people ;)
<ng0>i know there's an english version somewhere, but i forgot the homepage.. for the people who are able to read german, this one is an interesting paper: https://gnunet.org/xrs2016 (GNUnet und informationsmacht: Analyse einer P2P-technologie und ihrer sozialen wirkung)
<rekado>looks like building avrdude with "libusb-compat" instead of "libusb" (and without the patch) are sufficient to make usb support work again.
<alezost>rekado: re building a package that requires emms: I think the best would be to modify emacs-build-system to make it look in "share/emacs/site-lisp/" dir (currently it looks only in "share/emacs/site-lisp/guix.d/<package>")
<alezost>rekado: IIUC this can be done by adjusting 'emacs-inputs-el-directories' procedure from (guix build emacs-build-system)
<alezost>I hope Federico will not object against this modification
<iyzsong>Lillo: still for 'perl-uri'? I think it should build now.
<ng0>imo everything outside of gnu.org should be merged into manual at some point to make it more explanatory on different levels of understanding.
<adfeno>-drive "file=[Where the image is, if path needs comma, double it (",,").],index=[Starts from 0, I would put the "virtual" disk device here, not GuixSD USB image],media=[ Use "cdrom" for GuixSD USB, and "disk" for the "virtual" disk device]
<civodul>but it's still the place to look for doc, and to improve it too :-)
<adfeno>civodul: I was like: "Where in the world is that page about GuixSD on QEMU, I have seen it, but I can't find"... :D
<adfeno>Then, I tried looking int he first installation sections, but I couldn't find it.
<adfeno>Then I resorted to the official QEMU documentation.
<adfeno>Actually... I looked up in the installation-related sections of GuixSD manual, not in Guix's.
<adfeno>(and now I see that both use the same manual... Sorry)
<civodul>i go to the table of contents or the index when i'm lost :-)
***Kooda_ is now known as Kooda
<ng0>civodul: manual.. I think we should expand the tor-hidden-service service explanation to point out that hidden services can have subdomains.. it's a feature which is not so well documented maybe, just learned about it last week when someone I know moved pages and services under one onion and several subdomains of it.
<ng0>I try to find a section in the tor manual or documentation to point to
<mark_weaver>cehteh: what specifically are you referring to? who's taking away other people's freedom of choice?
<Sleep_Walker>cehteh: sometimes I face it in openSUSE community - the most significant example was transition to systemd
<cehteh>just generally, thinking about the mame discussion some months ago, but also debian choice of making it rather hard to get rid of systemd, or gnomes choices to hide a lot customization because of simplicity
<cehteh>mark_weaver: i was merely responding to utbrs, as in 'even if guix has (valid) reasons to use the linux libre channel, there are reasons for a lot of people to use linus tree (even if it contains non free bits by some definition)'
<davexunit>I've been wanting to expand the automated system tests to include GuixSD containers
<lfam>In other "finally" news, I sent a patch to Pjotr last night that should makes Erlang pass --check on my machine. And the latest release of Erlang made the Erlang compiler create its ouput reproducibly. So, soon :)
<lfam>I mean, it does make Erlang pass --check on my machine.