<mark_weaver>we have GNU IceCat, which is a slightly modified firefox-esr, in Guix. Unfortunately, at present, due to lack of developer time, IceCat has not yet been updated to ESR 45. It's still based on 38.8, so it has unpatched security flaws and is currently not safe to use.
<mark_weaver>at present, the best modern browser we have is 'epiphany'
<mark_weaver>I agree this is not a great situation. There are discussions in progress to solve the developer issues with GNU IceCat
<mark_weaver>I forgot that upstream Firefox now includes support for DRM. that would need to be removed before it could be included in Guix.
<mark_weaver>So, if this is a problem for you, then I'm afraid Guix is not for you.
<mark_weaver>so GNU IceCat is supposed to be doing the job of modifying Firefox to comply with our requirements. it just needs more help.
<mark_weaver>anyway, on the plus side, it's quite easy to maintain local packages, or even arbitrary modifications to Guix itself.
<mark_weaver>it's very easy to run Guix directly out of a git checkout. I myself always run Guix out of a private branch, with my own local modifications. I periodically rebase this branch on the upstream master branch.
***Digitteknohippie is now known as Digit
<mark_weaver>(alternatively, you could merge upstream master into your branch)
<jlicht>balduin: on a side note: you inquiry pushed me to try my hand at building atom
<jlicht>there is some good and bad news: building from their repo seems to work with our bundled node package :D
<jlicht>but the build process pulls _a lot_ of packages from the npm registry, which contain minified and/or transpiled sources :/
<jlicht>so it might take a good amount of time before atom might be bundled with guix (if there are no license issues that prevent atom from being included anyway)
<balduin>Maybe there is a way to compile Firefox without DRM support, add LibreJS and the other GNU IceCat plugins and put it into GUIX. This is just an idea.
<mark_weaver>balduin: yes, it is certainly possible to do that. we'd need to change the branding as well, because Mozilla's trademark policy would require it, and a few other things. this is precisely the job of the GNU IceCat project.
<lfam>balduin: If they don't have any sort of versioned release system, then I guess we will have to package an arbitrary Git revision. Check the manual section 7.6.3 Version Numbers for an example of how we handle this
<mark_weaver>balduin: if there has never been a release, then I would recommend starting the version string with the date of the git revision, in the form YYYY.MM.DD
<balduin>is it enough to just use: #:use-module (guix packages) and specifiy the package in the input section?
<mark_weaver>balduin: you need to 'use-module' the module that contains the package in question, and then use the scheme variable name (the identifier after the 'define' or 'define-public') as the name after the comma in the input entry.
<lfam>Is anyone going to finish the tox packages and send them in?
<balduin>@OrangeShark did a pretty good job. I hope he will send his package definition in.
<Sleep_Walker>can anyone review '[PATCH] gnu: asciidoc: Use local docbook-xsl package.', please?
<Sleep_Walker>(besides space between file name and '(variable-name)') :)
<cehteh>mhm full disc encryption with a /boot doesnt work?
<mark_weaver>cehteh: not unless you're running Libreboot or coreboot with GRUB as payload in your boot flash. The reason is that /boot is where GRUB is located. GRUB is able to mount a LUKS volume, but a typical BIOS is certainly not able to mount a LUKS volume.
<mark_weaver>cehteh: this is not GuixSD-specific. if your BIOS is not capable of mounting an encrypted volume, then obviously the bootloader needs to be unencrypted.
<cehteh>mark_weaver: i meant the 'usual' way with a unencrypted /boot partition
<mark_weaver>oh, if /boot is a separate, unencrypted partition, then it should work. I haven't tried it myself, but it has been reported to work by others.
<cehteh>i made a small /boot mounted it, grub is installed, but it erorrs out lacking something from the store
<rekado>yay, bluetooth audio via pulseaudio works now. At the very least we will need to provide a pulseaudio service to simplify this, I think. The rest is messing with bluetoothctl, pairing, connecting, then using pavucontrol to redirect the audio stream to the bluetooth audio device.
<janneke>mckinley_: assuming that eclipse a linux-fhs executable, you need to use patchelf to set the dynamic linker
<rekado>BTW: we should update pulseaudio to the latest version. In core-updates?
<davexunit>rekado: is that having bluetooth devices play audio on machines running pulseaudio?
<davexunit>or sending pulseaudio output to bluetooth speakers?
<bavier>otremblay: but if you use guix's go package and notice anything wrong, let us know
<otremblay>Well I'm considering the usage. Usually I'd be halfway through wiping my computer right now, but in a fit of random panic at some point I decided it would be a great idea to encrypt my whole drive and now I'm not sure it's gonna be so easy to do the "partial wipe" dance I'm used to.
<Petter>Thinking loud. Maybe you can use one temporary partition for your current stuff. Encrypt a partition for your system, get it working, copy stuff to it, delete data partition, expand encrypted partition.
<Petter>Memory fails a little, but I believe I tried expanding an encrypted partition with success.
<Petter>If I recall correctly you can only expand the end of an encrypted partition, so put this partition first on the disk and the "old stuff" partition last.
<otremblay>Is it possible to use the partitions I have right now, even though they're encrypted?
<otremblay>Also, as an aside: I just realised there's a guile-emacs package in GuixSD
<otremblay>Are the emacs users in here using that or the regular emacs?
<lfam>I see two options. 1) I can rebase onto master and re-sign the 11 commits from core-updates-next. If we do this, I'd like for someone else to double-check that I have not modified the commits that I've re-signed. 2) Temporarily disable the hook and push the result of `git checkout core-updates-next && git merge master`, which I have prepared locally.
<lfam>And of course, there may be other options which are superior
<lfam>I don't really like 2, because I had to resolve dozens of merge conflicts. I think I resolved them correctly, but that's a lot of opportunities to make mistakes.
<mark_weaver>itorres: bah, it looks like artanis' Makefile is kind of a mess :-(
<mark_weaver>well, thanks for working on it. I'll look more closely later.
<lfam>mark_weaver: Okay, I'm going to try pushing a copy of master as WIP-core-updates to Hydra, just to check that that works with the hook. If it works, I will then cherry-pick the commits to the branch. Then, I will ask for review
<mark_weaver>we should also incorporate the available updates from GNU, e.g. gcc-4.9.x, glibc, and maybe some others
<lfam>There are lots of patches in my Guix mailbox that will end up on this core-updates branch once it's ready. For now, I just want to get these 11 commits onto current master on Savannah
<lfam>I meant that I will push to Savannah, not Hydra