IRC channel logs

2016-06-08.log

back to list of logs

***avph_ is now known as avph
<jlicht>woohooo!
<jlicht>found out why node v6 is broken: our patch-shebang was the culprit
<jlicht>it seems that when we call patch-shebang on a symlinked file, the symlink is broken
<jlicht>so lets say we have A -> B, with an `/usr/bin/env node` shebang: If we then call (patch-shebang 'A'), we end up with two files:
<jlicht>A with the patched shebang, and B with the original `/usr/bin/env node` shebang
<lfam>sneek: later tell emyles: If you run out of disk space in /tmp while building, you can build somewhere else on your computer by setting the TMPDIR environment variable when you invoke the guix-daemon
<sneek>Will do.
<lfam>I can't even do `guix build -S expat` to test a change to expat without rebuilding the base
<lfam>I guess that's why have a staging branch...
<lfam>Testing the VLC update
<lfam>So VLC wants us to cherry pick this commit from the Qt developement code: http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/tree/debian/patches/set_WA_OutsideWSRange_for_native_widgets.patch?h=ubuntu
<lfam> https://trac.videolan.org/vlc/ticket/16497
<efraim>lfam: I thought for vlc it was use the patch or upgrade qt to 5.6.0
<lfam>efraim: Which one do you think we should do?
<efraim>I think upgrading makes more sense
<lfam>Did anybody test that upgrade yet?
<efraim>qt-5.6 needs to have another round of /bin/sh shebang patches after configure iirc
<lfam>It sounds like you have a WIP branch ;)
<efraim>i try to keep them to a minimum, right now I only have qt-modular
<lfam>I'll try it
<efraim>sneek: later tell lfam: check out this vlc patch debian has: https://sources.debian.net/src/vlc/2.2.4-1/debian/patches/drop-check-qt-check.patch/
<sneek>Will do.
<efraim>sneek: botsnack
<sneek>:)
<rekado_>On one of my GuixSD machines Emacs no longer has any icons. There's a space where they should be, and on hover I see text, but the icons are no longer displayed.
<rekado_>that's bad for people who rely on icons.
<rekado_>is there an easy way to import *all* package modules at once?
<rekado_>we usually don't have overlapping names for package variables and the import list in my manifest is getting too long.
<efraim>nothing I can think of
<rekado_>I guess all-package-modules in gnu/packages can be of help
<rekado_>I now have this at the top of my manifest:
<rekado_>(for-each (lambda (mod)
<rekado_> (eval `(use-modules ,(module-name mod)) (current-module)))
<rekado_> ((@@ (gnu packages) all-package-modules)))
<rekado_>it feels so wrong but it works...
<emyles>Hi, why can't this environment find python?:
<sneek>emyles, you have 1 message.
<sneek>emyles, lfam says: If you run out of disk space in /tmp while building, you can build somewhere else on your computer by setting the TMPDIR environment variable when you invoke the guix-daemon
<emyles>lfram: thanks, will try that
<emyles>guix environment --ad-hoc python:out uwsgi:out uwsgi:python
<emyles>which uwsgi shows /gnu/store/haaash-profile/bin/uwsgi
<emyles>but, which -a python shows /usr/bin/python ??
<efraim>maybe try with --pure ? It unsets your current environmental variables, including $PATH including /usr/bin
<rekado_>emyles: also note that the "python" package provides "python3", not "python".
<emyles>efraim: I tried --pure but still found python in /usr/bin
<emyles>rekado_: that was the problem, on Arch Linux so I'd got used to 'python' being python3, thanks
<efraim>forgot about that part
<emyles>sneek: later tell lfram: thanks, will try setting TMPDIR
<sneek>Will do.
<emyles>sneek: botsnack
<sneek>:)
<efraim>wow finding info on cve-2016-5108 is hard
<efraim>this is about it: https://marc.info/?l=oss-security&m=146435553526717&w=2
<efraim>i'll update vlc to 2.2.4 in a little bit
<ng0>I've been thinking.. it's pointless to try to continue to contribute to gentoo portage for myself as I do right now. I am pretty sure I have what's needed to fix #355355 (aka: old as rocks guile bug on gentoo), and when I have guile fixed in portage I can fix my guix{-bin} packages for gentoo and people using gentoo can use guix, and I have less trouble maintaining stuff outside of portage which I currently try
<ng0>to get into portage, so I can just contribute this to guix and start working on what I really want, systemservices, kernel based things, etc
<ng0>the chance that portage will get reasonable safe in the future is much lower than where guix is aiming, so the more people have the option to use it, the better.
<ng0>also I'm just running an update on torbrowser 6.0.1 / 45.2.0esr, so they are moving faster with esr's now
<ng0>important for me for switching one system back to guixsd: is libgcrypt-1.7 in guix now? my newer key needs ed25519
<efraim>its still sitting in core-updates
<ng0>ah
<ng0>wayland got pretty usable. I'm using sway now and it's not comparable to awesome-wm, but comes close to what I remember of i3
<efraim>what's required to support it?
<efraim>does it get added at/near mesa and then everything magically works or does it need to be an input to a bunch of things?
<ng0>do you have a browser for accessing .onion at hand? it's also in the clear, but I can just point you to my stagit of the ebuild
<ng0>it has little deps
<ng0>ah, this is in gentoo, not guixsd.
<efraim>that also works
<efraim>yeah I have firefox go through tor
<ng0> http://p4rnmaebljj6saue.onion/n0is-overlay/file/dev-libs/sway/sway-9999.ebuild.html is what I am using (if the sync of staggit is not behind), version 0.7 is not yet in portage tree and I am working on it.
<ng0>bascically what's on github repo
<ng0>special awkwardness can be fixed with things found on archlinux wiki, like touchpad etc.. it wokrs, pointer is not so slow anymore, but I got no right click, only left atm
<ng0>compile+install time on a t400 thinkpad: 2minutes, 6 seconds
<efraim>nice
<ng0>perl is confused and wants to go home now. started this build ~1 hour ago: current merge time: 2days, 13hours, 40 minutes.
<ng0>with every terminal you open in sway, a new user is listed in `users` .. a difference to Xorg.
<ng0>or not. looks like something weird going on
<ng0>nvm me.
<ng0>iirc it depends on wcl (wlc?) and you need to pass the keyboard layout to sway before starting it, no config. maybe this is a thing for the system config of guix.
<ng0>*not in config. sway has a config, but the keyboard layout can't be set in it atm
<efraim> https://wiki.archlinux.org/index.php/Wayland says to list the keyboard layout for weston in ~/.config/weston.ini
<efraim>so it might be similar for sway
<ng0>weston is one thing, sway another
<efraim>right
<ng0>sway is just: wayland optional xwayland and then wlc and then sway
<ng0>on the page for sway it is explained how to start sway when you don't have en_US qwerty
<ng0>there's 3 or 5 other wayland libs/WMs so far, I have only tested sway as it was the only working one after weston I found, writing ebuilds for some has been on my todo for a while
<efraim>I was thinking of trying to get it working with enlightenment in guix
<ng0>sway? or wayland in general?
<ng0>you can run sway inside X.
<efraim>enlightenment on wayland on guixsd
<ng0>you need an exported XDG_RUNTIME_DIR which I did not have with awesome-wm by default
<ng0>ah :)
<ng0>I now run some applications which need to have their sourcecode config modified if you want personal configuration, like st, stagit, and most of suckless/2f30.org and similar groups developed tools. would it not be possible to pass some "check this dir for a saved config.def.h and then use it" to a guix package optionally to the actual package definition so that you can have default and if file is present use
<ng0>that to get changes and eventual patches with same behavior, or should this be limited to having your own package definitions atm?
<ng0>the dwm wm has the same expectations.
<efraim>the hash can't change, so I suppose you could have a base package and write a patch that could change, but i'm not seeing an easy way to upstream it to guix
<ng0>right.. hm. maybe that's something to think about for later
<ng0>in the meantime mention that for dwm and similar you need to copy the package locally and write your own changes inside or add patches to source from the local copy.
<efraim>ah vlc-2.2.4 failed because it couldn't find a display
<efraim>changed that test from `./vlc --run-command-that-breaks-sandbox' to `echo --run-command-that-breaks-sandbox'
<lfam>efraim: I'm working on the VLC / Qt update too
<sneek>lfam, you have 1 message.
<sneek>lfam, efraim says: check out this vlc patch debian has: https://sources.debian.net/src/vlc/2.2.4-1/debian/patches/drop-check-qt-check.patch/
<lfam>efraim: VLC has said that packagers can apply that patch only if they have patched Qt as well
<lfam>I'm working on the Qt upgrade now
<lfam>This is where they say that: https://trac.videolan.org/vlc/ticket/16497
<efraim>I switched vlc to qtbase and commented out qtx11extras since I haven't pushed that yet
<lfam>Hm, it looks like (at least one of) the files in Qt that needs to have its shebang patched is generated *during* the build phase. At least, if I stop before build, that file is not there
<efraim>really? that's going to be hard to deal with
<efraim>which module is it?
<lfam>I'm waiting for the build to fail again to make sure
<lfam>The file is qtbase/src/widgets/uic_wrapper.sh
<lfam>Maybe we should try patching qt@5.5 instead of updating, for now.
<efraim>qtbase is at 5.6 and my failed-test copy of vlc-2.2.4 worked for playing videos
<lfam>Do you know what Qt bug those patches are trying to work around?
<efraim>not a clue, never looked at it
<lfam>Okay, I have the Qt source repo. I'll try applying the patch to 5.5
<lfam>It's a bug that interferes with full screen VLC playback
<lfam> http://www.linuxquestions.org/questions/slackware-14/vlc-2-2-2-a-4175571633-print/
<lfam>efraim: So you got that message from the VLC build process about backporting I78ef29975181ee22429c9bd4b11d96d9e68b7a9c ?
<lfam>What hash is that? Why does it start with a capital 'i'?
<efraim>ACTION goes off to pick up the kids
<lfam>If I change the 'I' to an l, i, or 1, the hash is not a valid commit in either the Qt or VLC repos
<lfam>If you read some minds, you will learn that it is a Gerrit reference, apparently to this: https://codereview.qt-project.org/#/c/139066/1
<taylan>are there plans to ever make an ISO image for installation?
<lfam>Tautological question ;)
<lfam>Does anybody plan to make the ISO image?
<taylan>heh
<taylan>I wondered for a moment whether there's a reason one doesn't already exist, but I guess there is no particular reason
<lfam>I haven't missed it. Sometimes people do ask but I don't know what the unsatisfied use case is.
<lfam>Are ISOs just for optical media? I don't have any more optical media interfaces
<davexunit>yeah it's just for optical media
<davexunit>but people are rather used to that format
<davexunit>so they get a disk image and have no idea what to do with themselves
<lfam>Do they get (ab)used for non-optical media? Who are these people burning CDs and DVDs? ;)
<davexunit>yes, they do.
<davexunit>virtual machine programs and such
<taylan>lfam: some motherboards don't boot from USB
<civodul>one of these days i'll end up adding a target to make an ISO if nobody else does :-)
<civodul>even though i don't really understand why it still matters
<civodul>i think that's because of some VM tools that expect you to give an ISO, rather than due to the abundance to CD drives
<prince_myshkin>hello, what is the procedure to add a package to the distribution?
<prince_myshkin>is it like, send the patch to the mailing list?
<prince_myshkin>also, if I create a new file, gnu/packages/my-new-package.scm
<prince_myshkin>should I manually add the entry to the Makefile.something files?
<prince_myshkin>or is there an automated way of doing it?
<lfam>prince_myshkin: If you make a new file, you should add it to the list in gnu/local.mk
<lfam>But, you should check the existing package modules to see if there is already an appropriate location for the new package
<prince_myshkin>thanks lfam
<lfam>And yes, create a patch with `git format-patch` and mail it guix-devel@gnu.org, or use `git send-email`
<prince_myshkin>ok. If I mail it with git format-patch, should I do it as an attachment, or as plain email text?
<prince_myshkin>or probably it does not matter
<lfam>It's up to you. There seems to be an infinite number of methods to send the patches ;) `git send-email` takes care of all that for you
<prince_myshkin>yeah, I'll have a look at it.
<prince_myshkin>thank you lfam
<davexunit>git send-email is nice because then the reviewer doesn't need to download an attachment
<davexunit>makes it way easier to review
<prince_myshkin>I see
<lfam>And also you can be sure that `git am` will work smoothly ;)
<lfam>It handles multiple patches, threading, etc
<prince_myshkin>I'm convinced, I'll use if :)
<prince_myshkin>s/if/it
<davexunit>that said, if it becomes difficult to setup or something, just use your normal mail client to attach the patch.
<lfam>Indeed, the most important thing is to send a patch :)
<prince_myshkin>well, it is probably easier than to setup my mail client
<prince_myshkin>I didnt find a magit interface to send-email :(
<efraim>I was going to tell lfam I got vlc-2.2.4 built but he just left
<davexunit>hmm, I can't seem to add (guix build union) to the modules list for gnu-build-system
<davexunit>no code for module: (guix build union)
<davexunit>seems odd to me, the gnu-build-system imports many modules from the (guix build ...) namespace
<davexunit>a-ha! it needs to go in both #:modules and #:imported-modules
<civodul>heh
<davexunit>our boost package could use a little fixin' to make it more usable for folks that want to make tweaks via 'inherit'
<bavier>indeed
<davexunit>will take a stab at that
<davexunit>build-flags should just be exposed as the #:make-flags argument
<davexunit>then it would be easy to modify the flags. I need a statically linked build.
<bavier>I still have a lingering patch for tests in our boost package
<bavier>This article is interesting: http://incolumitas.com/2016/06/08/typosquatting-package-managers/
<davexunit>just saw that
<efraim>At least 43.6% of the 17289 unique IP addresses executed the notification program with administrative rights.
<efraim>wow
<bavier>I would be surprised it it hadn't already been exploited maliciously
<efraim>now it seems so obvious
<davexunit>lol centralized package repos where anyone can add stuff
<efraim>"i'm in your computerz, running scripts with root access"
<davexunit>yet another reason why these language package managers are total amateur hour
***Igel is now known as broski
***broski is now known as igel
***igel is now known as Igel
<kyamashita>Is anyone else having odd font problems?
<kyamashita>fc-cache -fv only scans the gs-fonts directories on my machine.
<kyamashita>Okay, so fc-cache is looking for a fonts.conf file in a directory that does not exist anymore.
<kyamashita>Okay, my FONTCONFIG_PATH was incorrect.
<bavier>kyamashita: do you know if anyone got in touch with the tor-browser developers about reproducibility/security wrt a guix package?
<kyamashita>I'm not sure. The new Tor Browser is out though, so our work wouldn't be outdated.
<kyamashita>bavier: IIRC, davexunit said he'd contact them, but I might be wrong.
<bavier>ok
<bavier>thanks
<efraim>texlive 2016 was released on the 6th
<kyamashita>efraim: That will be quite the upgrade.
<efraim>oh yes
<davexunit>I didn't say that I would contact the tor project about tor browser
<davexunit>I don't use it, so I have no interest
<bavier>davexunit: ok, np
<bavier>I can't prioritize it at the moment, but if no one else gets to it first I'll get in contact with them
<kyamashita>davexunit: noted.
<civodul>bavier: the typosquatting article is fune, indeed
<civodul>AFAICS we're immune to that :-)
<bavier>:)
<davexunit>civodul: indeed! :)
<ng0>so I solved the guile part of building guix on gentoo, now I just need to solve guix behavin weird on gentoo. i think I don't care about if my solutions is to the liking of everyone, but 6 year old bugs annoy me. It's not too offtopic if I ask for solving the last part of the puzzle on the dev list? been some months since the last try, so I think I'm better at debugging now, but in case I get stuck again..
<ng0>iirc it was something like guix did build, but build process were never started.. I suspected users now, so I changed them, see if this changes the situation
<ng0>question: can the guix application if run on top of a different host update itself, or is an update, if for example switching from 0.10 to next version, on the host level needed?
<ng0>never looked at it from this perspective
<janneke>ng0: you usually never update guix, everything will rebuild if you do that
<ng0>thought so. just wanted a confirmation :)
<davexunit>janneke: what?
<davexunit>the question and your answer are both confusing me.
<davexunit>I update guix daily and I don't have to rebuild everything
<janneke>davexunit: when on debian, i tried guix package -i guix
<davexunit>janneke: that doesn't get you a newer guix!
<ng0>what I meant was: I emerge guix-0.10 , the next release candidate happens (0.11 let's say), and I'm not sure if the update would happen on the host level or through guix, but remembering guixsd usage this question starts to sound like I am answering it myself
<janneke>now it's my time to be confused :-/
<davexunit>guix cannot package a new version of itself because that would require time travel.
<davexunit>'guix pull' updates guix
<davexunit>and that should be done regularly to keep up-to-date on security patches and other upgrades
<janneke>i never do that, I only update git
<davexunit>that's the same thing
<davexunit>the guix package within guix is always an older snapshot
<davexunit>because it's literally impossible for it to be otherwise
<ng0>logically the -$VERSION.NUMBER for us is just to point to the current tarball for the first release. it would be more interesting to have a guix-current which points to whatever is the current release
<davexunit>ng0: that's why you run 'guix pull'
<davexunit>to get the latest
<janneke>anyway, i never do guix package -i guix anymore; i stay with the release-guix and update only the content
<ng0>i know.. I'm just thinking weird right now i think
<ng0>no idea what I try to ask o.O
<janneke>i really seem to remember that world rebuilds after guix package -i guix...
<davexunit>janneke: that's still not quite correct.
<davexunit>you cannot update "just the content", which I am assuming means the packages.
<ng0>guix package -i guix wasn't what I meant.
<ng0>my view was on the outside, not the inside. ie, versionnumber and package of guix to pull in for the initial bootstrap installation changes
<davexunit>guix is the packages + build systems and other libraries. they come together.
<ng0>I think I can point out in our overlay README that the version number does not really matter and that (like I have now in postsetup notes) guix pull should be run
<ng0>oh... QA notes. I think I found my problem
<lfam>efraim: Thanks for doing VLC!
<kyamashita>lfam: What did efraim do with VLC?
<lfam>kyamashita: There was a security update that was not so simple to apply
<kyamashita>Ah.
<lfam>I was working on it earlier but I had to stop. I'm glad somebody else finished it
<kyamashita>In that case, thanks to you both!
<civodul>mark_weaver also pushed a bunch of security fixes
<civodul>thanks to you lfam, efraim, and mark_weaver :-)
<ng0>would someone know how I quit -- ^X mode (^]^D^E^F^I^K^L^N^O^Ps^U^V^Y) in vim, any keys I can hit or is it just solved with killing the process?
<ng0>sorry for the offtopic, i just wrote service for guix and want it to start, but accidentally did emacs commands in vim
<ng0>well recovered the swap file. I run into this so often i shoulkd stick to emacs
<ng0>eh... wot: guix pull: error: build failed: while setting up the build environment: cannot unmount real root filesystem: Operation not permitted
<ng0>maybe i forgot to run it as root, that's the only case I can think of..?
<ng0>I think I'll switch to a non-hardened system see if this is due to the kernel.
<kete>I don't know what this means: /mnt/etc/config.scm:8:0: error: source expression failed to match any pattern
<ng0>you have a syntax error somewhere
<ng0>could you upload the file, so someone could spot the error?
<kete>yes
<ng0>*could help you to
<kete>yeah, I didn't spot it because my change didn't help
<kete>I changed sda1 to sda, and I verified that I used my-root as the label: http://kete.ninth.su/config.scm.txt
<ng0>do you need to add (guix) in there? my old config.scm looks different
<ng0>had to do some changes, let me push to the clear net filehost.
<ng0> http://we.make.ritual.n0.is/static/pub/ there's the config-t.scm you want to curl or look at
<ng0>for a reference or comparision, i can't really help, but maybe it helps you
<ng0>tell me when you no longe rneed it so I can delete it again
<kete>ok ng0 I downloaded it
<ng0>i see luks device mapping :O that works already?
<ng0>i mean encrypted file system without lvm, just straight cryptsetup
<kete>it worked without (guix) before, just failed to install Grub because of temporary lack of full disk encryption support
<kete>ng0, this is all I know. I didn't see lvm was necessary, but maybe it is.
<kete> https://lists.gnu.org/archive/html/guix-devel/2016-04/msg00964.html
<ng0>lvm isn't available in tree yet. jookia got it working in their branch, but i haven't asked about the branch last time we had a chat. was discussed on the list or here too, but the interest in working lvm wasn't so big
<ng0>yet
<kete>I'll ask help-guix if necessary.
<ng0>I think the error I got could also be some kind of sandbox violation or whatever.. which could still be -hardened related.
<ng0>I'll try --debug