IRC channel logs


back to list of logs

<Apteryx>Is there anything similar to 'edebug' when hacking Guile Scheme with Emacs?
<Apteryx>The Guile REPL is nice, but I miss the one key stroke shortcuts (and source tracking) of edebug.
<daviid`>Apteryx: most of us use geiser
<paroneayea>uploading a test VM to rackspace. We'll see how this goes in a couple hours when it's done.
<Apteryx>daviid: Thanks. I'm using Geiser as well. It seems that debugging is very verbose and manual (everything is command driver from the Geiser's GUILE REPL with commands such as ,b, ,bt ,n ,s ,locals, ,finish, etc.)
<Apteryx>command driven*
<len-oba>I can not run bash scripts with ./
<Apteryx>I'd be happy to be missing something (a Geiser debug mode?) where I can make all those actions shortcut driven and see where I'm at in the source without having to print the backtrace all the time.
<Apteryx>ala edebug
<len-oba>I get bad interpreter error
<Apteryx>len-oba: what's the first line of your file?
<len-oba>is there a quick fix - ive been googling a lot without luck
<Apteryx>bash: /bin/bash: No such file or directory
<Apteryx>Seems normal under Guix
<len-oba>:) žž
<Apteryx>len-oba: if you do which bash
<Apteryx>it should tell you where it lives, from here its /run/current-system/profile/bin/bash
<Apteryx>So I'd expect that if you put this in your shebang that'd work. Not a nice solution though. Might want to ask about on the Guix user mailing list, that's a good question.
<buenouanq>note that #!/bin/sh does work
<buenouanq>this might be the quick fix len-oba is looking for
<jje>got network-manager up and running on wireless. very grateful for all the help. thanks!
<len-oba>so I would like to get zeronet running but I also have problems with python
<len-oba>I guess I will switch to debian for a while until I find time to read info very carefully
<len-oba>thanks for your help
<lfam>Wow! Great news about removing the Intel ME spy machine!
<marusich>lfam, what's that now? What news?
<marusich>I know about Intel ME, but I haven't heard the news.
<lfam>marusich: I saw this blog post in today's IRC logs:
<lfam>There was a thread on the coreboot mailing list about the initial findings a few months ago
<lfam>It's very good news!
<lfam>I can't wait to risk bricking my laptop ;)
<marusich>Has anyone used Mumble yet?
<marusich>I know ng0 packaged it, but I just tried it and it hung during the initial setup after I launched it from the command line
<lfam>marusich: I'll try it now
<marusich>When I hit the second "next" button, it just seems to hang.
<lfam>What system are you running?
<lfam>I'll try it on Debian
<lfam>Just wondering if you're on GuixSD or a foreign distro
<marusich>The only error seems to be "TextToSpeech: Failed to contact speech dispatcher."
<marusich>I'm running it on GuixSD
<lfam>marusich: I can't reproduce your issue, although I also see "TextToSpeech: Failed to contact speech dispatcher." At the point where your mumble hangs, clicking Next has no effect at all for me. I think that's because I have no audio input devices available (mic disabled in BIOS)
<lfam>I can click Next and nothing happens, but if I click Back, it does go back
<lfam>I tried clicking Cancel, and I got a dialog about certificates, clicked through, and the application appears to have loaded normally
<lfam>I see a list of servers
<marusich>Hm. Once I click "next" the second time, I can't click on back or cancel - the window becomes essentially nonresponsive, though I can move it around.
<marusich>If I hit "cancel" in the wizard, it takes me to mumble itself. Interesting. I'll see if I can poke aroun dmore at it.
<marusich>Come to think of it, I'm not actually sure if my laptop has a microphone built in.
<paroneayea>well I guess I'l write an email to the list about my "progress" on server installs with rackspace cloud later :)
<paroneayea>it's not a lot of progress, but maybe some routes eliminated.
<lfam>marusich: Is the 'second "next" button' you mentioned the same as mine? The one where you use a wizard to select an audio input device?
<lfam>paroneayea: Software development via process of elimination :)
<lfam>Anyways, it would be interesting to `strace` it, marusich
<marusich>lfam, yes. I'm not sure how to effectively debug this kind of stuff :/ I could run strace but i suspect i won't be able to understand the output
<marusich>lfam, I am not even sure if my mic is working. I think I have one. I don't usually use a mic on my GNU/Linux machines though, so I'm not very familiar with how to check if it's working.
<lfam>marusich: Yes, strace does require a little knowledge... but not too much to troubleshoot a hang. Probably the relevant info will be near the end
<lfam>You might try audacity to see if your mic is working. I think that program is relatively easy to figure out
<marusich>Yeah, I'm looking into ways to verify independently if my mic is working.
<marusich>Found this:
<marusich>Audacity might be an easy way to check, too. Thanks for the tip.
<Apteryx>Could someone tell me if the python build system executes tests for real? I've read through guix/build-system/python.scm, and it's not clear to me how/where running the tests is implemented.
<lfam>Apteryx: I believe it's in guix/build/python-build-system.scm
<Apteryx>lfam: OK, thanks! I'll look it up.
<lfam>There were recently some suprising changes in this area. It turns out that with Python < 3.5, if a test suite was not found, the test phase passed. With 3.5, this counted as a failure, and we found many packages whose tests were never run
<lfam>I'm not sure of the state of this issue with Python 2
<Apteryx>OK, so it seems this would attempt running "python test", at least for the package I'm looking at (python-tox).
<lfam>Yes, basically
<marusich>lfam, mysteriously, it works now.
<Apteryx>You are right that when no tests are found it's a pass.
<marusich>I'm not sure what I did. I installed alsa-utils into my profile, and later, I noticed that mumble was not hanging, and the microphone was working. I tried rolling back my profile, and it still works. I have no clue.
<lfam>That's weird! Maybe mumble needed some state file in order to work, and this file was created after the first run
<lfam>Apteryx: Note that many python packages require custom test phase replacements
<Apteryx>lfam: I guess. it can be tox, pytest, there are lots of options.
<lfam>Yes, tons :)
<marusich>lfam, it's very strange. If I can ever figure out how to reproduce it, perhaps I'll report it.
<Apteryx>I'm still curious about this "python test". I've never read about that way before, I'll have to research about it.
<lfam>I guess you can define the test invocation in
<lfam>I know at least one package that uses it, python-acme:
<lfam>I don't know *how* it works, but there is a lengthy test suite that runs for that package :)
<Apteryx>lfam: OK, cool! The interesting thing in the case of tox, it's that it's a testing framework and it seems to use itself for its test suite. So we'd need a some other tox to run the tox to be installed tests.
<lfam>Ah, a tox-bootstrap that does not run its test suite
<marusich>lfam, I think I figured it out. I don't know if ALSA can support multiple programs "using it" at the same time, but it seems that whenever I run qemu (configured to use ALSA for its back-end sound driver, so I can hear sounds produced by the guest), mumble hangs for me.
<marusich>Similarly, if I start mumble first, and then start qemu, qemu fails to produce sound and emits error messages related to ALSA saying "alsa: Reason: Device or resource busy"
<marusich>I happened to be running qemu at the time when I tried to set up mumble.
<marusich>And the moment I shut down qemu, mumble starts working.
<lfam>Yes, that's a limitation of "plain" ALSA, IIUC.
<lfam>It's a primary reason for the use of software mixers like dmix or pulseaudio
<marusich>Interesting, I didn't know that.
<lfam>I think our standard is that GuixSD applications should use pulseaudio.
<marusich>I'll try switching qemu to use pulseaudio.
<marusich>This reminds me, I'm sitting on a simple patch to compile pulseaudio and alsa support into qemu, since I needed it to run a guest with sound.
<lfam>JACK is another option but it's really a powerful system for audio-centric use cases, like live music creation
<lfam>Why not send it in? :)
<marusich>I will!
<lfam>Searching the web, my impression is that the expectation is that distros will configure ALSA to support multiple concurrent applications. I wonder if we should investigate this...
<lfam>I still am holding out with ALSA on my foreign distro... but it is becoming a pain when I try using Guix applications that launch a pulseaudio server which is not connected to any outputs
<Apteryx>lfam: Should I go ahead and create such a tox-bootstrap package? Any consideration? Should it inherit from regular python-tox?
<Apteryx>I should investigate why the tests are "passing" without tox currenty though, for python-tox. I'll copy the build derivation locally and run "python test" just to see what happens.
<lfam>Apteryx: I'd do the inheritance in the other direction. I think there is a working example with python-numpy and python-numpy bootstrap
<Apteryx>lfam: OK! :)
<lfam>Perhaps it's not addressing the same use case, but it should serve as a useful example
<Apteryx>Right. I'll look into that. Thanks.
<Apteryx>Also it seems that the PYTHONPATH is hardcoded in such a way that "pip install --user some_package" doesn't work as intended. I'll investigate this another day and send something to bug-guix.
<lfam>Does it try installing to /gnu/store?
<marusich>lfam, to clarify, i figured out how to make qemu work with the alsa backend, but not the pulseaudio still fails for me. And oss never worked...
<Apteryx>lfam: no, the "--user" option of "pip install" ensures that the installed package go to a local site-package directory, sowehere under ~/.local
<Apteryx>And then, by some PYTHONPATH magic builtin Python, packages found in the local site-package dir have precedence over global system installed one.
<Apteryx>Doesn't really fit the Guix way of things but I was hoping to use this as a quick and dirty fallback for when a package is missing/outdated.
<marusich>I have found that, when running the Icecat installed in GuixSD, even when I enable all javascript on a page, sometimes pages still fail to work properly. Is ther something else that is commonly the cause of this?
<marusich>My guess is that Icecat is blocking lots of nontrivial things by default in the interest of protecting my safety and privacy, which is nice, but I'm curious to know why some pages still might fail to function even though I've basically given them carte blanche to run their scripts.
<marusich>For now, I'm working around it by using GNOME's web browser, "Web", which is a bummer
<marusich>It'd be nice to be able to just use Icecat.
<lfam>marusich: Could it be a result of one of the other privacy features? Apparently is also uses Https-Everywhere and SpyBlock:
<buenouanq>I'm using the latest Icecat on GuixSD and have no problems.
<buenouanq>You're prolly just going to cancerous sites that should never have been allowed to exist.
<Apteryx>lfam: If I inherit python-tox-bootstrap, could I also use it as an "input" ?
<lfam>Apteryx: I'm not sure, try it :)
<Apteryx>lfam: OK :)
<lfam>I think so
***mbuf_ is now known as mbuf
<civodul>Hello Guix!
<buenouanq>Hello civodul!
<Sleep_Walker>ls: cannot access '/etc/ssl/': No such file or directory
<Sleep_Walker>I guess that some certs needs to be part of system configuration to get this symlink
<Sleep_Walker>hmm, nss-certs it is
<Sleep_Walker>I'd add it among default packages
<Sleep_Walker>it is possible to remove but it would improve user experience
<jmd>Sleep_Walker: That depends on the user.
<jmd>(more specifically on the usage!)
<jmd>For some applications, nss-certs would never be used.
<Sleep_Walker>so desktop-packages then?
<civodul>nss-certs takes 0.4 MiB, so we could add it to %base-packages i guess
<civodul>even if we don't use it, that should be fine :-)
<Sleep_Walker>thanks, that will be improvement
<wingo>good day
<wingo>i seem to be affected by
<wingo>wow :) so i am affected by that, but in emacs
<wingo>yay ludo for tracking that one down
<jmd>How can I ensure that network services are up before filesystems get mounted?
<rekado>frescobaldi fails to build on x86_64 and i686, but with different errors. On i686 it looks like a problem with gettext (“_” not found), whereas on x86_64 it’s a problem running X for tests.
<civodul>jmd: there's the 'dependencies' field in 'file-system', except it's supposed to contain file systems or mapped devices
<civodul>so there's no real way to do that, but it'd be easy to add
<civodul>wingo: just saw your message to bug-gnu-emacs; this %COMPAT thing is really terrible
<wingo>yeah total blah
<wingo>i thought i had that problem but i'm not sure if i did; i definitely have on some sites tho
<wingo> among them , but not! so weird
<civodul>but i guess it depends on the firewall and equipment between you and the host
<civodul>which makes it all the more terrible
<rekado>I get this error: “guix: offload: command not found”
<rekado>do I need to update the daemon?
<efraim>I got that on aarch64, I just added on --no-build-hook to work around it for now
<civodul>rekado: how do you get this error?
<rekado>just when I do “./pre-inst-env guix build python2-numpy”
<rekado>(on our central Guix installation on CentOS)
<civodul>and what changed?
<civodul>what's the value of HAVE_DAEMON_OFFLOAD in config.h?
<civodul>./configure detects whether offloading will be compiled in or not
<civodul>but here it seems that guix-daemon was compiled as if offloading is available but it's not
<rekado>HAVE_DAEMON_OFFLOAD is not defined
<rekado>I haven’t reconfigured after “git pull”
<civodul>HAVE_DAEMON_OFFLOAD_HOOK actually
<civodul>ok so you run 'guix pull' as root
<civodul>that breaks
<civodul>so yes, you should update the daemon
<civodul>because previously 'guix offload' was available, and thus support was compiled in guix-daemon
<civodul>and now it's no longer available
<rekado>BTW: on this machine at work I can never download the substitute for ruby
<rekado>it always fails complaining about corrupt input in one of the changelog files
<rekado>what’s annoying is that texlive depends on ruby (why?), so each update means building ruby and texlive from source.
<rekado>the error is always this: “guix substitute: error: corrupt input while restoring '/gnu/store/5n1g783y545mfbsbxqw8zyl3ca3by1pz-ruby-2.3.3/share/ri/2.3.0/system/page-ChangeLog-2_1_0.ri' from #{read pipe}#”
<rekado>trying to build the common python science packages with texlive-minimal instead of texlive. Hope this will make future upgrades less painful.
<jmd>It must be some optional feature. We had Texlive long before Ruby.
<civodul>rekado: good idea
<rekado>I have an old laptop with a very old installation of GuixSD. I don’t know how to upgrade it without having to rebuild a lot of things.
<rekado>“guix pull” aborts with “Unbound variable: make-session” (even though gnutls is installed and can be loaded from within a guile REPL)
<civodul>FWIW i just did "guix build ruby@2.3", which downloaded from and there was no error
<rekado>civodul: yes, I also don’t see this error on my laptop. Only on that machine on the campus network.
<rekado>maybe a firewall problem.
<civodul>rekado: could you paste all the details
<civodul>regarding 'guix pull'
<rekado>I think the key thing here is a redirection from http to https for “…”
<civodul>ok but when does that happen?
<civodul>when downloading libssh's source in a fixed-output derivation?
<rekado>I don’t understand the question. “guix pull” shows me what it will build, says “building paths” for “…-module-import-compiled” and “…-?id=a033b93…”, then says “starting download of ‘/gnu/store/kajx9..-?id=a033b93…’ from ‘…’
<rekado>(I don’t have a usable setup on that machine, so pasting the whole output is a little tricky)
<civodul>so the error is not in 'guix pull' itself, but in the process that downloads from
<civodul>so presumably changing the URL to https will fix it, no?
<rekado>yes, probably
<rekado>matplotlib’s pdf doc cannot be built with texlive-minimal :-( oh, well.
<civodul>texlive is terrible
<rekado>I’m a little confused to see that ‘a033b93’ (first few characters of the patch id) cannot be found in master.
<rekado>(maybe an old patch belonging to this old version of guix?)
<ng0>what happend to gunicorn? I just had to search this thread of patches I submitted in september because I needed pysocks, and harmut wrote that gunicorn would be added to web.scm.. but I see not contribution of any gunicorn. is it in the python branch which is now being build?
<rekado>meh, this isn’t working. I even ran ‘guix download’ on the https URL of the patch, renamed the file in the store to the expected name (yuck!), and then reran ‘guix pull’, but the derivation for this patch is still executed and it still fails.
<civodul>renamed the file?
<civodul>IIUC, it's the libssh recipe of that old Guix that refers to the broken thing
<ng0>fatal: could not read Username for '': No such device or address ... wot
<ng0>while guix build a package i have
<civodul>rekado: what you could do is retrieve the patch by hand with 'guix download', rename it locally, and then do 'guix download file://the-file.patch'
<rekado>yes, the store item is /gnu/store/kajx9…-?id=a033b93…
<rekado>when I just ‘guix download’ it gets stored as /gnu/store/…-patch
<civodul>right, so you can do "guix download -o expected-file-name.patch https://..."
<civodul>and then "guix download file://$PWD/expected-file-name.patch"
<rekado>I tried that
<civodul>(or "wget" instead of "guix download")
<civodul>doesn't work?
<ng0>oh, it's jakob not jacob.. that's why the guix build failed
<rekado>no, various errors
<davexunit>ACTION discovers the "fritzing" package
<davexunit>this is a neat application!
<rekado>when I do ‘guix download file:///home/rekado/guix/?id=…’ it says ‘regular file expected’
<rekado>maybe the ? needs escaping
<rekado>no difference
<rekado>(I guess at this point it’ll take less time to just reinstall the whole thing)
<rekado>ng0: what’s the github URL you want to access?
<ng0>it's fixed, i had a typo
<efraim>Maybe put the whole URL in quotes
<ng0>i try to contact the developer(s) of the application and see if it's still worked on and they are only slow in commits. if they still work on it, i'd like to add it as a second bitmessage client.
<ng0>uses pyqt5 and python3
<rekado>efraim: tried that too (single and double quotes), but it’s the same.
<rekado>doesn’t matter, I’ll just install this machine from scratch.
<rekado>nothing valuable on it anyway
<rekado>(this is yak-shaving: for some reason I can’t pay for my VPS any more, so I’m trying to set up a little server at home)
<rekado>numpy also cannot be built with texlive-minimal. Too bad.
<rekado>do we really need to build the PDF reference for numpy and matplotlib?
<ng0>won't this be more expensive unless it's a small oneboard computer or powered by solar/wind/water energy off the grid?
<rekado>maybe we can avoid texlive if we only generated the HTML docs.
<civodul>rekado: so use wget
<rekado>civodul: no wget on this machine :)
<civodul>to avoid the question mark problem
<civodul>or curl, whatever :-)
<rekado>but the expected name in the store is with the question mark
<civodul>so 'guix download' Should Work
<civodul>rekado: re matplotlib's PDF, ISTR Fede was strongly in favor of keeping it
<rekado>could we have a separate package for that? The build of the PDF doesn’t depend on a finished build of numpy, does it?
<civodul>no it doesn't, but i think Fede wanted to have both in the same package
<civodul>which makes sense in a way
<civodul>if our texlive package didn't such that much, it would be ok
<rekado>I’ll try to look for ways to make texlive suck less.
<civodul>the Nixpkgs folks had some success
<civodul>basically splitting it in a zillion of auto-generated packages
<civodul>then we'd need a profile hook to glue things together, probably
<civodul>but we should get inspiration from there
<rekado>yeah, I have the relevant nixpkgs pages open
<civodul>and we can provide a texlive meta-package that remains as big as the current one (Andreas will want that :-))
<efraim>On a similar vein, I thought about using a snippet to produce the source of libstdc++ so I wouldn't have to unpack it as often on my aarch64 board
<civodul>well, that's a one-time cost, so it's different
<ng0>pyqt5 currently fails to build on amd64 hardware
<ng0>mkdir: cannot create directory ‘/gnu/store/r4dkdickrr6fpkxcwwxlbriva2c8cx2s-python-3.5.2/lib/python3.5/site-packages/PyQt5’: Permission denied
<ng0>maybe some python / qt expert can fix this, I haven't looked at it too much
<rekado>hmm, I’m happy that we use Guile and not the nix language.
<rekado>I find it pretty difficult to read nix code.
<rekado>(who said it looks like Haskell?)
<civodul>people like to say it's (like) Haskell, go figure ;-)
<rekado>there’s two things that are similar to Haskell: ‘if … then … else’ and function application without parentheses or commas.
<rekado>I’ll take Scheme any day
<civodul>and lazy evaluation by default
<rekado>how does that affect the build recipes? It’s not like we’re eagerly evaluating all builds in Scheme…
<davexunit>rekado: do we have any packages for circuit simulation? I haven't been able to find any.
<rekado>davexunit: looks like we don’t.
<davexunit>okay, just confirming.
<civodul>rekado: the evaluator doesn't have to evaluate all of Nixpkgs, only the subset that is relevant
<civodul>Guix achieves the same result through a different mechanism
<rekado>davexunit: SPICE (or variants) are often used for this.
<davexunit>rekado: thanks!
<rekado>davexunit: ngSpice and gnuCAP
<rekado>both of them work well with the rest of the gEDA suite
<davexunit>I never really was able to use the gEDA suite very well.
<davexunit>just finding components is a pain. :(
<davexunit>fritzing is a lot more user friendly
<rekado>yeah, it’s not the most discoverable piece of software.
<davexunit>I feel that it's more powerful than fritzing, if I could only understand it.
<rekado>I really like the workflow with ‘gschem’ and ‘pcb’
<davexunit>I've had trouble getting gschem to produce something that pcb could work with.
<rekado>in gschem you would attach the footprint attribute to components; pcb would then instantiate them from its own libraries.
<davexunit>I think that's where a lot of this breaks down for me
<rekado>pcb comes with a lot of generic component libs (including m4 templates for components)
<davexunit>finding footprints is really difficult.
<rekado>but creating own footprints is pretty straight-forward
<davexunit>I think that's where I spent most of time, just trying to find a footprint that corresponds to the component I'm using.
<davexunit>I have several PCBs I'd like to etch myself if I can figure that part out.
<rekado>I’m also currently setting up my etching equipment
<davexunit>I was going to use the strategy that you sent to me
<rekado>I ordered photoresist film and will try to etch a few circuits with this:!--A-better-etc/?ALLSTEPS
<davexunit>rekado: yeah that's the instructable I plan on following
<davexunit>I don't know anything about the photoresist method
<rekado>davexunit: re footprints: do you know that you can browse the available footprint libraries in ‘pcb’ after hitting ‘i’?
<davexunit>I think so. been awhile.
<davexunit>the trouble I had was with the ones that are customized in odd ways like changing the name
<rekado>that’s probably the oldlib stuff using M4. They take arguments and it’s not really obvious (without reading the M4 macro definition) what they are.
<rekado>e.g. for SMT resistors.
<davexunit>can I completely avoid those?
<rekado>dunno, haven’t tried. I’m only using the M4 footprints for resistors and capacitors. Don’t need to use them for most other components.
<davexunit>maybe we should take this to PM :)
<davexunit>oh cool
<ng0>who was primarily involved in cuirass so far? anyone I could CC tomorrow if I have further questions about a setup which more or less would be equal to what has now?
<civodul>ng0: mthl (Mathieu) is the person behind Cuirass
<ng0>gnunet is interested in setting up the CI to use cuirass
<ng0>the last setup on the service thread was in october, has it been added to master since then?
<htgoebel>Hi guix
<dvc>hi htgoebel :)
<htgoebel>I just merged the python build system. :-)
<htgoebel>ACTION is happy to have this finished
<rekado>htgoebel: neat!
<rekado>I’d like to use nginx-vhost-configuratio for most vhosts on my server except for one. Is it possible/desirable to use a file as a vhost configuration?
<htgoebel>recardo: nginx seems to support "include" in "server" sections, too. See
<rekado>but our nginx-service does not, or am I missing something?
<htgoebel>I don't know if this works with the current nginx-patch
<htgoebel>I had not yet time to test the new patch
<htgoebel>but you should be able to use a test-string to become the config file
<htgoebel>But I'd appreciate a more flexible approach, too :-)
<dvc>It's simple to add a template to the guixsd installer. I'm wondering if there is a simple way to make an offline installer to avoid downloading all derivations of a template every time.
<rekado>I get two errors after reconfiguring with nginx-service that prevent nginx from starting.
<rekado>first is that /var/run/nginx/logs is not created
<rekado>the second is that /etc/nginx/cert.pem is expected (even though I’m not using ssl).
<rekado>ah, for the second thing I just need to set ‘ssl-certificate’ to #f
<efraim>commit e408ffc302f4381bcb198fbd83e210a4a1ce5dbc confuses me
<rekado>me too
<rekado>htgoebel: looks like python-zope-interface wasn’t there in the first place, so adding a comment to remove it looks wrong.
<rekado>htgoebel: also, the commit message mentions python-zope-testing, which isn’t touched at all.
<efraim>htgoebel: I want to appologize for openstack.scm, I think I was the last one to touch that file
<efraim>its on my to-do list to try to clean up the native-inputs actually needed for the tests
<dvc>if the guix installer used linux proper and linux-firmware, would guixsd still be FSDG compliant?
<efraim>i'm pretty sure linux-firmware is mostly blobs
<jmd>dvc: I have no idea.
<dvc>yep, but if we keep the linux and linux-firmware package definitions inside of gnu/system/install.scm we don't have nonfree software in our repos
<htgoebel>rekado: re, zope-stuff: Well, this was a mass change, some errors may happen.
<efraim>as a source-based distro we tachnically don't have any software, but now you're tip-toeing around debian's contrib/non-free FSDG problems
<efraim>htgoebel: it happens :) huge patch set, looks great
<htgoebel>efaim: :-) Yes, it's been quite a lot of work. But someone has to do it or we'd live with burdens of the past for long.
<dvc>yep, wouldn't work. if cuirass or hydra build the installer image then the products of the installer image would also be binary cached, so we'd be distributing nonfree software again
<htgoebel>gtg, good evening
<ng0>also, if you used linux and then did a guix pull and rebuild the system, everything would be gone
<dvc>that can be solved easily... you can just add the linux and linux-firmware package definitions to barebones-nonfree.tmpl also keepingg it outside of the guix stuff.
<dvc>but anyway, it's pretty easy to do, only takes an hour or two to figure out, so probably not worth it. maybe I'll write a blog post instead
<ng0>that would still require some diversion from master
<jmd>dvc: Please don't.
<dvc>why not?
<jmd>Even if we're not distributing proprietary software, we don't want to encourage others to.
<dvc>on a private blog unrelated to guix? why would that be a problem?
<jmd>I can't stop you doing it. I'm just asking you not to.
<dvc>99% of laptops are useless without this
<jmd>Then please use your time to help write a free replacement for that firmware.
<bill-auger>or convincing ppl to buy only the 1% of machines that do run free :)
<davexunit>what you talk about on your own blog is your own choice, but here on #guix, the guix mailing lists, and in the guix source we won't include or recommend non-free software.
<davexunit>I highly doubt that 99% is accurate. many laptops can run a fully free OS
<dvc>that's a joke right? I'll just spend a weekend writing a firmware replacement for a complicated wifi card without documentation and write a toolchain for a reverse engineered cpu architecture and then get it FCC approved * sorry for the sarcasm
<davexunit>boot firmware is a separate issue, but even before I knew much about software freedom I ran debian main on an old compaq laptop and everything worked.
<davexunit>the usual problem with laptops is intel wireless chips, but there are many laptops that use atheros chips, such as the new model of the dell xps 13
<jmd>davexunit: the other problem is video drivers.
<davexunit>most laptops don't have a discrete GPU and use the GPU built-in to the CPU.
<ng0>I actually have one very old netbook which did not start the guix installer medium at all, an amd64 one. I once ran parabola on it, but I guess the hardware became broken over the years. So I can not report it as a bug because the hardware could just be broken by now
<davexunit>I'm just saying that setting aside boot firmware and intel's management engine, you can find a laptop that will run a fully free distro without too much trouble.
<jmd>But they stil need a proprietary video driver - or at least many do.
<davexunit>intel chips? no.
<jeaye>Part of software freedom is the user's choice which software to use. It's for this reason why someone might use Skype, for example, on GuixSD.
<[df]>intel video drivers are free and nouveau is pretty good on a lot of chips
<davexunit>[df]: +1
<[df]>I don't make heavy use of 3d rendering though
<davexunit>I use intel and nouveau GPU drivers and they are pretty good.
<len2>i had to change bios on thinkpad to get atheros wifi card working on thinkpad
<davexunit>len2: same.
<jeaye>Users may want full control over what's free on their system and what's not. If I can get a completely free OS and choose which proprietary software I need or want, that's my right.
<davexunit>but there do exist laptops that just come with atheros chips
<rekado>jeaye: there’s a difference between a person using their right to use their machine for whatever they want and giving step-by-step instructions on how to use proprietary software.
<len2>now it beeps at startup but works
<jeaye>rekado: I completely agree.
<davexunit>you are free to use skype on guixsd, but we won't provide a package for it or recommend its use.
<Steap>davexunit: in the latest Intel CPUs, the integrated GPU requires a non-free firmware if I'm not mistaken
<Steap>davexunit: hope you have lots of old CPUs :)
<rekado>Guix already makes it very easy to roll your own non-free kernel package (I say this as someone who has never before built a kernel from source). Giving users who don’t know how to use these features instructions to use proprietary software isn’t empowering them, unlike improving documentation on how custom kernels can be used.
<davexunit>Steap: really? I haven't heard about that.
<davexunit>I'm using a thinkpad x220 with a core i5 and have a fully free GPU
<davexunit>I did find out, after buying one, that new AMD GPUs require nonfree firmware.
<davexunit>which was frustrating because I read several articles about which version of mesa to use and stuff to use the new fully "open" drivers
<davexunit>but Linux has a firmware blob in-tree that linux-libre removes
<Steap>davexunit: davexunit
<davexunit>that sucks
<ng0>ah, skylake
<Steap>good luck with working with only a tty
<jmd>That's the problem today. One doesn't find out that a box doesn't work with free software until after you've bought the damn thing.
<ng0>that's the other problem, the future. alternatives are being worked on, but what if they aren't available soon enough. there's still arm then.
<rekado>ng0: arm hardly helps in terms of graphics chips
<davexunit>Steap: are you antagonizing me?
<ng0>ah, graphic cards.. I just live with all the (desktop) cards I have being slow
<Steap>davexunit: not at all, I just want to know what will happen when we all follow the principles that are being discussed here
<Steap>and we can only use a tty on a $1k laptop
<davexunit>that is unlikely
<Steap>That might make writing free software harder.
<paroneayea>Steap: we aren't at that level of dystopia yet.
<dvc>sorry for bringing the topic up, my fault :)
<paroneayea>Steap: if we get there, we can talk about that then. In the meanwhile, lots of people are working to help have alternatives be possible.
<Steap>paroneayea: that's where we're headed
<rekado>I think we’re close, though. It’s one reason why I’m stuck with pretty old hardware.
<[df]>what we need to do is shout at the vendors
<Steap>tell people trying to use more free software that they cannot use wifi
<davexunit>it does seem like the GPU situation will get worse before it gets better, but there has been some improvements along with the setbacks
<Steap>do you think they'll use more free software, or will they go and buy a macbook immediatly?
<rekado>I don’t think Wifi is a problem any more.
<bill-auger>what should happen Steap is that ppl should stop buying those products and start supporting companies that make free hardware
<Steap>bill-auger: yeah, well, come on
<paroneayea>though, I did think briefly that we could run a GuixSD install fest at LibrePlanet
<dvc>and how many companies are that?
<davexunit>Steap: it's not difficult to find a laptop that works with a free driver
<paroneayea>and realized it probably couldn't happen
<bill-auger>as ng0 says they are on the way but they need community support
<davexunit>wifi driver*
<paroneayea>because most people coming in wouldn't have hardware that necessarily worked with only free components
<rekado>in our department it has happened repeatedly that IT bought hardware that we simply cannot use with free software alone.
<rekado>even though there are alternatives.
<bill-auger>it doesnt matter how many companies there are - there only need to be one
<rekado>so we brough this up with the users and now they check with me when they want to buy stuff.
<paroneayea>rekado: it's nice to hear they started accomodating there!
<[df]>hmm, maybe guixsd needs a hardware certification programme
<[df]>ubuntu has one!
<ng0>I'd like to spend money to support new products for example, but I'm at the lower level of income so that isn't going to happen.. often such products are rather expensive, but for a reason. fair prices, but above my level
<paroneayea>[df]: anything that's FSF RYF certified will probably work with GuixSD
<ng0>so I have to buy old, used ones
<rekado>ng0: blew it all on the Talos workstation, eh? ;)
<[df]>paroneayea: true, but that is more limiting
<paroneayea>I was just reading the "10 years of openmoko" blogpost
<[df]>if people are (grudgingly) willing to live with ME and non-free bioses
<paroneayea>the other day my spouse and I were talking about, we're generally pretty good at not spending money on huge things we don't use
<bill-auger>the alternative is to concede that proprietary blobs are acceptable because we simply must have faster and faster and faster machines every year
<paroneayea>and she said "You did buy that openmoko thing"
<ng0>openmoko.. ah, neo900 is another thing i'd like to support but there's no way I spent ~1000 euro on a smartphone
<paroneayea>poor openmoko, it meant well
<[df]>I wish I could justify buying a talos
<paroneayea> interesting blogpost btw
<davexunit>during my brief time at the fsf someone was using an openmoko as their main phone
<davexunit>couldn't believe it worked.
<paroneayea>davexunit: haha I know who that was :)
<[df]>I did for a while
<rekado>[df]: I wish I could make the case that we need Talos servers at the institute, but I can’t think of a convincing reason.
<davexunit>paroneayea: heh, it did all sorts of weird things
<paroneayea>I tried pretty hard to get mine out, but the really sucky thing is I got the model right before it worked at all
<ng0>I wanted to get it.. then I waited to long and got the n900 as my first phone with touchscreen
<paroneayea>they put out a replacement model immediately aftrwards
<davexunit>the volume would get all messed up and play really loud notifications
<paroneayea>that actually sort of could kind of work
<paroneayea>but mine was doomed
<[df]>rekado: well if it's servers you want there are other openpower options out there
<rekado>phones are weird. After the disappointment of WebOs I just gave up and haven’t used a phone since.
<paroneayea>so it was like $600 to nothin'
<davexunit>I haven't used my novena very much
<paroneayea>rekado: wow! no phones at all?
<davexunit>but I hope that will change now that I have some desk space to actually set the thing up on.
<ng0>i wish I could get rid of the phone I have
<rekado>[df]: well, I’d like their campaign to succeed.
<dvc>fyi: for those that haven't realized, we have nix in our repo, making the installation of non-free software trivial
<ng0>but people kinda expect to reach me
<[df]>rekado: yeah me too
<rekado>I hardly every picked up the phone anyway when I had one
<paroneayea>dvc: I think taking another hop through a package manager is different
<davexunit>dvc: you can say this about any package manager that we have
<paroneayea>you can also use python pip to install nonfree things from the python package index
<rekado>then I learned that most things aren’t really urgent
<dvc>ah ok...
<davexunit>you can download wine and run proprietary windows software
<[df]>this old argument is silly
<[df]>you can use wget and install whatever non-free stuff you want
<davexunit>so I don't think including such software is encouraging the use of proprietary software.
<rekado>(I still use the hardware of my phone as an unreliable alarm clock.)
<paroneayea>you can install librejs, but then still run turing complete css ;)
<dvc>I guess I'm kind of confused in what's acceptable and what not. why is firefox considered nonfree then? installing an addon would be hop to jump through too right?
<[df]>the point is to not legitimise non-free software
<[df]>not to pretend it doesn't exist
<ng0>firefox is a different problem, mainly the artwork which is used
<paroneayea>dvc: there's a "not advertising nonfree software" policy also for the libre distros thing
<dvc>that's an old problem, artwork is released under a free license
<paroneayea>ng0: hm that's not the only motivator for icecat I think
<paroneayea>it is for iceweasel
<paroneayea>though now debian is switching back to firefox branding I guess
<ng0>icecat rewrites some text, adds some patches, exhcnages the graphics,
<efraim>looks like its time to refresh the CPAN mirror list again
<rekado>efraim: and our perl packages too…
<ng0>removes webrtc support and firefox live or whatever it was called
<paroneayea>wait, someone in here works on icecat and I forget who it is
<paroneayea>I would be super embarassed if I replied to ng0 and told them what icecat does and it was them ;)
<dvc>haha xD
<efraim>rekado: thats what made me notice
<paroneayea>ACTION shouldn't be such an explainer
<ng0>I've read some code of it when I wanted to update the gentoo package for it and looked into packaging some modified torbrowser, that's all
<[df]>ACTION reads the talos spec again and again wants to justify spending money on it
<rekado>speaking of explaning: could someone please explain to me how to change the backlight brightness on a laptop without X and without hotkey support?
<ng0>maybe you#ve read my name in context of icecat because an email I've written ended up as a vote, paroneayea
<paroneayea>ng0: possibly :)
<paroneayea>rekado: that's going to be important when we only use ttys on our laptops ;)
<davexunit>icecat removes webrtc support? I didn't think that used any nonfree components.
<jmd>rekado: On mine there's a pair of function keys for it.
<paroneayea>yeah why would it remove webrtc?
<[df]>rekado: I think it entirely depends on the laptop, but maybe ?
<paroneayea>webrtc is fine, it's h.264 that's bad
<ng0>i'm not sure about all the features removed atm
<paroneayea>there was a big fight in the ietf webrtc group about whether or not to legitimize h.246r
<paroneayea>I sat in on some of the calls
<paroneayea>sadly they did
<paroneayea>sucks :(
<nmp>should i be worried about a bad signature?
<nmp>gpg: BAD signature from "Ludovic Courtès <>"
<nmp>gpg --verify guix-binary-0.11.0.x86_64-linux.tar.xz.sig
<dvc>I thought that patent issues aren't a problem from a free software standpoint, as long as the implementation was free?
<dvc>since it's a juristiction thing right?
<paroneayea>dvc: if only
<ng0>nmp: oh? let me check
<paroneayea>in the US at least, you can be sued for running or developing patented software, even with free implementations
<paroneayea>dvc: if that were true, we wouldn't even be talking about free/nonfree codecs... it wouldn't be a big deal
<paroneayea>and unfortunately, MPEG-LA *does* assert their patents.
<dvc>well I'm from europe, I'm not scared of a lawsuit :)
<davexunit>in guix we generally include software that is patent encumbered
<davexunit>like LAME
<ng0>nmp: some more minutes until I can verify my connection is bad, despite the stores trying to advertise optical fiber connections here lately
<ng0>* verify,
<nmp>ng0: ok, thanks
<efraim>IIRC the bad signature has to do something about the expiration date of the signature
<nmp>yesterday on another machine it was ok. So it must have expired just today
<ng0>expires 2017
<nmp>either that, or something more nefarious
<paroneayea>ACTION sends an email to help-guix on current "get guixsd running on commodity hosting" state
<paroneayea>which is, it's not working yet :)
<paroneayea>I'll try to update this thread as I go.
<paroneayea>if anyone has existing experience in this area, *PLEASE* weigh in.
<ng0>signature is good for me
<rekado>nmp: FWIW I validated the signature of the i686 image today without problems.
<davexunit>paroneayea: I have some rackspace experience, but not with making new base images.
<davexunit>I wish I had more time to investigate this with you.
<rekado>[df]: thanks for the link to acpilight; will try
<rekado>tomorrow I’ll have to say goodbye to my VPS.
<dvc>paroneayea: have you tried vultr? that works with custom isos unlike digitalocean
<paroneayea>davexunit: no worries, I suspect once we get past the initial hurdle of the base image stuff, you'll have a lot of insights :)
<paroneayea>dvc: I haven't heard of vultr, what is it?
<paroneayea>ACTION looks it up
<nmp>ng0: thanks, then it must be something on my side
<paroneayea>dvc: how do you custom ISOs, do you know?
<dvc>upload an iso and select it when creating a droplet
<paroneayea>"upload ISO feature"
<paroneayea>dvc: is that like, upload ISO for the installer?
<dvc>but I haven't tried yet. I was planning on moving my digital ocean droplet there so that I can use guixsd
<paroneayea>I should try this!
<paroneayea>wow, cheap too!
<rekado>[df]: echo 1 > /sys/class/backlight/intel_backlight/brightness worked
<paroneayea>damn, thank you dvc
<rekado>(that’s pretty much what acpilight does)
<efraim>I was thinking of moving d.o to scaleway and converting debian->guixsd in place
<thomassgn>anyone tried running guixsd on a macbook pro (few years old, metallic casing)
<efraim>I have a macbookpro 3,1 haven't worked out the EFI stuff yet
<paroneayea>thomassgn: I think tsyesika did at one point, but had some driver issues
<nmp>ng0: ok, it was a problem on my side. the file had gotten corrupted during transport.
<davexunit>I thought we solved the macbook driver issues?
<davexunit>I recall that someone fixed at least some of the issues that were brought up
<efraim>broadcom network issues?
<paroneayea>yeah it was the keyboard thing
<paroneayea>but it got resolved
<paroneayea>that's right
<efraim>02:00.0 Network controller: Broadcom Corporation BCM4321 802.11a/b/g/n (rev 03)
<paroneayea>thomassgn: so one person has. Maybe it'll work. Try it? :)
<efraim>keyboard was libreboot macbook
<paroneayea>davexunit: so I think "spinning up" and "spinning down" server instances might be a guixops feature, but not for a couple milestones out
<paroneayea>right now that whole field feels really complex to me
<paroneayea>keeping updated existing deployed servers should be the initial main focus, do you agree?
<davexunit>paroneayea: that sounds like a good first milestone, yeah.
<efraim>jxself in linux-libre wants to know if anyone with an armhf board can try out a linux-libre kernel
<davexunit>paroneayea: ultimately I think we'll need to fit in well with things like openstack's HEAT and AWS's cloudformation
<paroneayea>davexunit: yeah probably
<davexunit>they both allow declaratively specifying an entire set of stuff, not just VM instances.
<davexunit>but for now, let's just get GuixSD running on something ;)
<paroneayea>also, I think someone in here was talking about how to convert the images we generate with the usb stick feature to ISO
<paroneayea>does anyone remember what program was mentioned, so I can try it with Vultr?
<ng0>isoxor or smething
<paroneayea>that looks like it :)
<paroneayea>now, how to do it..
<thomassgn>paroneayea: Ah, great. Maybe, it's not my computer :)
<civodul>Steap: ideas/suggestions regarding ?
<Steap>"The image must be a single file in the VHD file format."
<Steap>well thanks Rackspace
<Steap>the web ui and the cli should be the same thing, but as usual, web ui kinda sucks :D
<paroneayea>some nice news: the ChicagoGLUG gets some courtesy "free resources" from rackspace, and are going to let me use that in my rackspace experiments
<paroneayea>so I won't have to bear the cost of spinning up / down servers :)
<davexunit>that's nice :)
<Steap>paroneayea: are you Christopher?
<ng0> lolpropaganda
<ng0>I'd feel bad if I had to read this for some kind of job
<civodul>paroneayea: cool!
<paroneayea>Steap: I am!
<paroneayea>Steap: you couldn't guess from my super obvious username? ;)
<Steap>paroneayea: hehe
<Steap>paroneayea: what does "glance image-list" say?
<baconicsynergy>hi gew-icks
<efraim>sounds like for a VHD image you do `qemu-img convert -O vpc guix.qcow2 guix.vhd'
<paroneayea>Steap: I dunno, I need to install glance I guess :)
<paroneayea>Steap: do you have openstack experience?
<paroneayea>efraim: yeah I did that one
<Steap>paroneayea: that is kind of my job
<paroneayea>Steap: oh really!
<Sleep_Walker>is it intentional not to have user 'nobody'?
<jmd>Sleep_Walker: No.
<Steap>paroneayea: so I do not know "swiftly", but it seems to be a swift client
<Steap>swift is the "object store"
<paroneayea>Steap: right...
<Steap>where images can be stored, if it is used as a backend for Glance
<Steap>so I think you'd need to use "glance image-create"
<jmd>we do have one
<paroneayea>Steap: ok, cool... I think that was my next step, so I'll try that next :)
<paroneayea>Steap: I'll be sure to ping you if I get stuck and you don't mind :)
<paroneayea>baconicsynergy: it's pronounced "geeks" :)
<paroneayea>though you might not guess it by "Guix" :)
<Steap>paroneayea: sure
<jmd>paroneayea: And how is "geeks" pronounced?
<paroneayea>I used to say in talks "Well, that's because civodul is French"
<paroneayea>but then I found out french speakers were saying it wrong too :)
<paroneayea>so now I don't know what to say ;)
<ng0>creative play with words
<paroneayea>jmd: it's pronounced "nerds" of course :)
<ng0>gnu user interaction xoftware
<paroneayea>jmd: wait, I should say, it's pronounced "guix" of course ;) ;)
<rekado>I’m trying to fix GCJ (which I broke in an attempt to fix it on armhf). Is it okay to specify a file:// URI for a patch in an origin?
<rekado>the problem I have is that I cannot use the ‘patches’ field in the package’s ‘source’ field, so I want to add an origin referencing the patch in gnu/packages/patches/
<Sleep_Walker>jmd: my fault, thanks for confirmation
<jmd>rekado: Why can't you use a regular patch?
<rekado>because the patch should only apply for armhf. But the source field isn’t delayed.
<rekado>so I cannot match against the system type there
<jmd>Perhaps you can design the patch so that it's a null op on other architectures.
<baconicsynergy>paroneayea: I know I just wanted to push some buttons :) hehehe
<rekado>jmd: difficult :-/
<rekado>it’s patching GCC config files and an error there only shows up after compiling half of it.
<rekado>wouldn’t be able to test this on arm where compilation takes literally more than half a week
<civodul>paroneayea: c'mon: "Guile" is pronounced with a hard G, right?
<civodul>and "Guix" is "Guile" + "Nix", essentially
<civodul>hence the pronunciation :-)
<rekado>so ‘Nix’ is actually pronounced ‘Neeks’?
<baconicsynergy>rekado: yes :DD
<civodul>how would you pronounce it? :-)
<ng0>I pronounce Nix like the german word "nix" as the nix in Unix
<civodul>ACTION still discovering subtleties of English
<civodul>ng0: how's that different from "neeks"?
<paroneayea>civodul: Really?
<paroneayea>I always pronounced it "Nicks"
<ng0>i read the two ee as an long "i"?
<paroneayea>words :)
<civodul>ok, i need to take classes now ;-)
<paroneayea>later civodul
<rekado>like the pluto satellite
<civodul>(i mean English classes)
<civodul>rekado: "Nix" is Dutch, and it's "i" like in "kitty", not like in "satellite"
<ng0>ah, os really no difference to 'nix'
<jmd>Perhaps we should start writing the name of our Os in the International Phonetic Alphabet.
<rekado>yes, not like in ‘satellite’ but like the natural satellite orbiting Pluto, which is called ‘Nix’ :)
<Sleep_Walker>are suid bits on binaries in store handled in some special way?
<jmd>Sleep_Walker: They are pronounced "sooid bits"
<jmd>(and there should not be any)
<Sleep_Walker>(IOW I updated slock, it should install binary and set suid bit but the bit is not set - should I blame guix?)
<jmd>Sleep_Walker: No. You should thank it.
<civodul>rekado: oh, right :-)
<civodul>note: "sooid", but not "gooix"
<civodul>this is all very tricky
<civodul>maybe that doesn't answer your question though
<civodul>Sleep_Walker: there cannot be setuid binaries in the store
<civodul>that would be a security issue since the store is accessible to everyone
<civodul>(via the daemon)
<Sleep_Walker>makes sense
<Sleep_Walker>so the question is how slock should work on guix
<paroneayea>let's port gnu hurd's auth server system to gnu/linux and use that :)
<paroneayea>(though maybe you could say that's what polkit is? I guess I'm ignorant enough not to know!)
<civodul>Sleep_Walker: on GuixSD slock and the like extend the "setuid service", which produces setuid binaries in /run/setuid-programs
<civodul>on foreign distros, there's nothing we can do
<Sleep_Walker>GuixSD is what I am interested in, thanks
<Sleep_Walker>so the problem is that I updated the package and installed locally as a user
<Sleep_Walker>that is not that bad
<rekado>heh, emacs-devel erupts again, this time a tangential discussion on C programmers
<rekado>at least they stopped ‘discussing’ reproducible builds for a while
<paroneayea>doesn't take a lot for emacs-devel to erupt ;)
<civodul>oh repro builds were on emacs-devel as well?
<paroneayea>I mostly saw that convo on the list-that-must-not-be-named
<paroneayea>ACTION starts packaging xorriso
<paroneayea>ACTION sees xorriso is already packaged :O
<paroneayea>ACTION wonders how he missed that
<paroneayea>ACTION notices he's spelling it "zorriso"
<rekado>oh, sorry, it was the other list, but with emacs-devel prominence :)
<civodul>right :-)
<civodul>The Other List
<mekeor>ACTION just ordered a wifi dongle (TP-Link TL-WN722N) supporting free drivers (ath9k_htc)
<mekeor>that means, i will finally install guix sd on the weekend :D
<nckx>Is guix-devel something I should subscribe to?
<nckx>Eh, guix-security, of course.
<nckx>ACTION wasn't browsing to sniff out what The Other List could be no sirree.
<ng0>no, not htat bad
<nckx>Tee hee.
<ng0>i think -security is limited to only a number of people
<ng0>correct me if i'm wrong
<rekado>security is where vulnerabilities are reported. Only the security team and the maintainers are subscribed to that list.
<nckx>That's what I suspected too.
<nckx>rekado: Thanks for clearing that up.