[02:32] <ximion> Laney: I pushed all the changes I wanted to make, rebuilding Debian's DEP-11 data now
[02:32] <ximion> gn8 :)
[06:13] <hikiko> hi
[07:16] <pitti> Good morning
[08:11] <robert_ancell> seb128, hello
[08:22] <alexarnaud> flexiondotorg: hi !
[08:23] <alexarnaud> I'm working with Compiz for Mate and configuration
[08:24] <alexarnaud> Do you know when in the init process the environment session DESKTOP_SESSION is defined to "mate"?
[08:24] <alexarnaud> hello seb128 robert_ancell :)!
[08:25] <robert_ancell> alexarnaud, it's in /usr/share/xsessions/mate.desktop
[08:25] <robert_ancell> key is "DesktopNames"
[08:26] <robert_ancell> alexarnaud, hand on, "DESKTOP_SESSION" is done by LightDM - it's the name of the .desktop file
[08:39] <alexarnaud> robert_ancell: OK, thank you :)
[09:00] <robert_ancell> willcooke, hi
[09:00] <willcooke> morning all
[09:00] <TheMuso> Hey willcooke, robert_ancell.
[09:00] <willcooke> hi chaps
[09:01] <seb128> hey robert_ancell alexarnaud willcooke TheMuso
[09:02] <flexiondotorg> alexarnaud, o/
[09:03] <Laney> hi
[09:04] <pitti> hey Laney!
[09:04] <seb128> hey Laney pitti
[09:04] <pitti> bonjour seb128!
[09:04] <seb128> pitti, ça va ?
[09:04] <pitti> seb128: ça va bien, et toi ?
[09:04] <seb128> ça va bien aussi !
[09:05] <pitti> le dernier jour du sprint de CI train
[09:05] <seb128> Laney, had a nice trip back from Brussel?
[09:06] <Laney> hey seb128 et pitti
[09:06] <Laney> trip was good thanks
[09:06] <Laney> although we went for crepes then got late and had to take a taxi to midi
[09:06] <Laney> was worth it though!
[09:07]  * pitti fails to see the problem there -- you had crêpes !
[09:07] <Laney> how are you?
[09:07] <seb128> :-)
[09:07] <seb128> I'm good thanks
[09:07] <Laney> having a good vsprint pitti?
[09:07] <seb128> hum, autopkgtests are a bit grumpy
[09:07] <pitti> Laney: a bit ropy, but ok
[09:07] <seb128> apport aptdaemon software-properties are blocking gtk
[09:08] <seb128> I wonder what's going on, that's not due to gtk for sure
[09:08] <pitti> cloud images are currently broken, have to work around that; machinery is now catchign up
[09:08] <seb128> apport was forced
[09:08] <seb128> still aptdaemon seems an issue, iso-codes hit it as well before so not specific to gtk
[09:08] <seb128> can we override those?
[09:08] <pitti> seb128: aptdaemon has a hint
[09:08] <seb128> oh, right
[09:08] <seb128> what about apport?
[09:08] <pitti> Should wait for aptdaemon 1.1.1+bzr982-0ubuntu14 test, but forced by pitti
[09:08] <pitti> Should wait for ubuntu-release-upgrader 1:16.04.4 test, but forced by pitti
[09:09] <andyrock> morning all
[09:09]  * pitti retries gvfs
[09:09] <seb128> hey andyrock!
[09:10] <pitti> seb128: meh, no idea what's wrong with that, I'll hint it for now
[09:10] <seb128> thanks
[09:10] <seb128> test_add_gpg_key (tests.test_dbus.TestDBus) ... gpg: failed to create temporary file `/home/ubuntu/.gnupg/.#lk0xe3e4c0.adt.7304': No such file or directory
[09:10] <seb128> is software-properties
[09:10] <seb128> can we hint that as well? ;-)
[09:11] <robert_ancell> Laney, hey, did you see that question about appstream + PPAs - do you know what I'm asking?
[09:11] <Laney> hints are the new fixes?
[09:11] <Laney> robert_ancell: no
[09:11] <Laney> and hi
[09:11] <robert_ancell> Laney, hi
[09:11] <Laney> oh you hid it below the links
[09:11] <seb128> Laney, no, if gtk was breaking something I would fix it, but those were there before and not concerning it
[09:11] <pitti> seb128: hm, this passed until two days ago
[09:12] <robert_ancell> Laney, so I was wondering what happens with PPAs - if you have a PPA with a variant of an existing package there will be metadata for G-S to show, but if you have some entirely new package there will be no metadata
[09:12] <pitti> seb128: I'm fine with hinting gtk+ itself, but not bad-testing software-properties
[09:12] <seb128> Laney, ideally we would fix all the issues, and I know you prefer that, but ETOOMUCHTODO
[09:12] <robert_ancell> I'm assuming there is no solution for appstream for completely unknown packages
[09:12] <pitti> seb128: it occurs in several -proposed packages, and it looks like one of it is responsible as it worked until two days ago
[09:12] <seb128> pitti, k, fair enough
[09:13] <seb128> pitti, you updated gnupg but it was more a week ago
[09:13] <pitti> gtk hinted
[09:13] <seb128> thanks
[09:13] <seb128> I'm having a look to softrware-properties, see if I can reproduce the error
[09:16] <Laney> robert_ancell: sorry, I'm not sure, maybe ximion has a smart idea
[09:16] <robert_ancell> Laney, I'll ask him tomorrow, thanks
[09:17] <Laney> robert_ancell: maybe a case for a plugin, but if the data is going to be crappy then we want to distinguish them in the UI by a badge or something probably
[09:18] <robert_ancell> Laney, G-S just hides everything without data, so I guess we want to add data from the apt cache for PPAs. But then we also have to decide which packages to show (i.e. the applications) rather than every libfoo.
[09:19] <Laney> does s-c do something smart there?
[09:20] <robert_ancell> Laney, trying it now, not sure exactly what it does. Seems to be showing broken entries for libs for me right now
[09:21] <robert_ancell> Laney, is it possible for a third party to set up an appstream that integrates somehow?
[09:21] <Laney> robert_ancell: you just have to give it in your archive
[09:22] <Laney> not sure Launchpad wants to maintain this service though
[09:23] <Laney> also it's kind of inefficient for that usecase currently
[09:39] <hikiko> hello
[09:56] <willcooke> hi hikiko, how you doing today?
[10:00] <alexarnaud> hello hikiko TheMuso willcooke didrocks !
[10:00] <hikiko> hi willcooke, better than yesterday, thanks :) you? there were some blackouts in the morning and I couldn't connect to the internet
[10:01] <seb128> pitti, do you know if I'm doing anything stupid there, http://paste.ubuntu.com/14876289/ ?
[10:02] <seb128> oh, gtk migrated
[10:02] <seb128> thanks :-)
[10:03] <pitti> qemu: could not load PC BIOS 'bios-256k.bin'
[10:03] <seb128> well, I don't have a "qemu" command
[10:03] <pitti> seb128: hmm, no idea about that -- bug in the i386 QEMU package?
[10:03] <seb128> should that be qemu-i386?
[10:04] <pitti> seb128: qemu-system-i386, yes
[10:04] <pitti> but they all call themselves "qemu" in logging
[10:04] <seb128> FileNotFoundError: [Errno 2] No such file or directory: 'adt-virt-qemu-system-i386'
[10:04]  * seb128 scratches head
[10:04] <pitti> nono, adt's backend is called "qemu", it'll call qemu-system-$arch
[10:04] <seb128> oh ok
[10:04] <pitti> seb128: your command line is right, qemu seems broken
[10:05] <pitti> seb128: you can try in LXC or LXD, or maybe the test even runs in schroot
[10:05] <pitti> seb128: which it ought to; try "--- schroot xenial" instead? (assuming you have a xenial schroot)
[10:05] <seb128> I don't
[10:05] <seb128> but ok, let's try to create one
[10:05] <pitti> seb128: otherwise I can walk you through LXD, it's super-easy
[10:06] <pitti> (and faster than creating a schroot)
[10:06] <seb128> do you have a wiki page?
[10:06] <seb128> I don't want to waste your time
[10:06] <pitti> "man adt-virt-lxd" describes it
[10:06] <seb128> I was following http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
[10:06] <seb128> thanks
[10:07] <hikiko> willcooke, Trevinho, I wanted your o[inion on something:
[10:07] <pitti> seb128: right, and QEMU is still the closest to what we do in production, so that's still right
[10:07] <pitti> seb128: $someone should fix qemu on i386 I figure
[10:08] <pitti> $ dpkg -S bios-256k.bin
[10:08] <pitti> seabios: /usr/share/seabios/bios-256k.bin
[10:08] <pitti> seb128: do you have that instaslled?
[10:08] <seb128> yes
[10:11] <hikiko> should I add 1 extra dependency on unity for the ezxoom plugin or is it fine the current zoom in the opengl plugin (since unity depends on the opengl plygin already and it will be only 1 extra variable)?
[10:12] <hikiko> :s/is it fine/is it fine to store/
[10:12] <seb128> also "qemu-system-i386 adt-xenial-i386-cloud.img" doesn't give me that error
[10:12] <seb128> but it doesn't boot the image either
[10:15] <pitti> seb128: when did you build that image? at that time qemu must have worked still
[10:16] <seb128> 1h ago
[10:17] <seb128> didn't touch the system since
[10:17] <pitti> ok, then it must be something else
[10:17] <pitti> adt-buildvm-ubuntu-cloud needs QEMU too
[10:17] <pitti> seb128: adt-run software-properties -d -U --apt-pocket=proposed --- qemu --show-boot -d adt-xenial-i386-cloud.img
[10:17] <pitti> seb128: ^ can you run that, and pastebin the output?
[10:17] <pitti> ah, maybe add log file:
[10:17] <pitti> seb128: adt-run software-properties -l /tmp/log -d -U --apt-pocket=proposed --- qemu --show-boot -d adt-xenial-i386-cloud.img
[10:18] <pitti> and cat /tmp/log|pastebinit
[10:21] <seb128> pitti, http://paste.ubuntu.com/14876356/
[10:21] <seb128> DBG: find_free_port: all ports are taken
[10:21] <seb128> hum
[10:21] <pitti> find_free_port: all ports are taken
[10:21] <pitti> oh
[10:22] <pitti> seb128: /run/lock/adt-virt-qemu.port* ?
[10:22] <pitti> seb128: it uses flock() on those, so something actually holds a lock on all of those
[10:22] <seb128> $ ls /run/lock/adt-virt-qemu.port*
[10:23] <pitti> ok, then I suppose it's not really locked, but something else
[10:23] <pitti> seb128: ls -ld /run/lock
[10:23] <seb128> drwxr-xr-x 6 root root 140 févr.  4 11:23 /run/lock
[10:23] <pitti> meh -- b00g
[10:23] <pitti> should be 1777
[10:24] <pitti> same here in fact, seems I botched that in the recent tmpfiles change
[10:24] <pitti> seb128: sudo chmod 1777 /run/lock should get you going
[10:24] <seb128> k, still buggy
[10:25] <seb128> but that feels like a glib issue now
[10:25] <seb128> adt-virt-qemu: DBG: Forwarding local port 10023 to VM ssh port 22
[10:25] <seb128> (process:20593): GLib-WARNING **: /build/glib2.0-Q50eE3/glib2.0-2.47.5/./glib/gmem.c:483: custom memory allocation vtable not supported
[10:25] <seb128> adt-virt-qemu: DBG: expect: " login: "
[10:25] <seb128> I wonder if it gets confused by the glib warning
[10:25] <pitti> seb128: can you run with --show-boot again?
[10:25] <seb128> that was it ^
[10:25] <seb128> http://paste.ubuntu.com/14876375/
[10:25] <seb128> I bet it doesn't like the glib warning
[10:26] <pitti> wow, why does mine work even with /run/lock as 755
[10:26] <pitti> I don't get that glib warning either (but amd64)
[10:27] <seb128> http://paste.ubuntu.com/14876384/
[10:27] <seb128> is with old glib ld_preloaded
[10:28] <seb128> pitti, anyway, it's out of the components you maintain at this point, seems a qemu issue, thanks for helping!
[10:28] <seb128> pitti, want a bug report about the /run/lock permission?
[10:28] <pitti> seb128: but we found the /run/lock  bug
[10:28] <pitti> seb128: if you want to track it, please
[10:28] <seb128> against what component? systemd?
[10:28] <pitti> seb128: so I suggest using lxd or schroot (of which lxd is the faster/simpler one)
[10:28] <pitti> seb128: yes
[10:28] <seb128> I'm going to try lxd
[10:29] <seb128> I wanted to play with it for some time
[10:29] <pitti> it's awesome
[10:29] <seb128> it's the opportunity
[10:29] <pitti> on btrfs is super-fast, on ext4 it's the usual speed but still very pleasant to use
[10:29] <Laney> I should try that too
[10:30] <Laney> qemu has just been too easy for me ;-)
[10:30] <Laney> but it isn't that fast to get results
[10:30] <pitti> http://www.piware.de/2015/12/whats-new-in-autopkgtest-lxd-maas-apt-pinning-and-more/
[10:30] <pitti> and the manpages
[10:30] <Laney> mass apt pinning
[10:30] <seb128> thanks
[10:30] <seb128> pitti, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1541775
[10:30] <ubot5`> Launchpad bug 1541775 in systemd (Ubuntu) "wrong /run/lock permissions" [Undecided,New]
[10:30] <pitti> seb128: merci
[10:30] <seb128> de rien !
[10:31] <pitti> erk, seems the instructions are wrong
[10:31] <pitti> since I wrote it, deb-src got removed from lxd images
[10:31] <pitti> so if you want to run a thing like "adt-run libpng", you now need to use adt-build-lxd (which will add deb-src)
[10:31] <willcooke> hikiko,sorry, forgot to answer... Trevinho will need to make that call.
[10:31] <pitti> or run a .dsc or --unbuilt-tree
[10:31] <Laney> I could probably improve my workflows too
[10:32] <pitti> I'll adjust the docs
[10:32] <Laney> like use ephemeral/snapshot/whatever containers for installing random -dev packages
[10:32] <pitti> I mostly use schroot for that
[10:32]  * Laney currently has xenial-lxc with *-dev installed
[10:32] <Laney> it would be cool to be able to fork that, mess it up, then blow that away
[10:32] <Laney> lxc-start-ephemeral did already exist for this
[10:33] <pitti> well, schroot does that
[10:33] <seb128> willcooke, btw I reverted the confusing fileselector behaviour in the gtk update that just landed in xenial, let me know if it works for you
[10:33] <pitti> containers are great for running packages with init scripts etc.
[10:33] <willcooke> thanks a lot seb128
[10:34] <Laney> I could set up a schroot with useful tool installed
[10:34] <Laney> but it'll be annoying when I want to use some services
[10:34] <Laney> containers are just better for this
[10:34] <pitti> *nod*
[10:35] <Laney> open schroot, install packages, <wait>, vim /some file, ARGH I FORGOT TO INSTALL VIM, etc
[10:35] <pitti> $ time lxc launch adt/debian/sid/amd64 sid1
[10:35] <pitti> real0m1.924s
[10:35] <pitti> that is clone AND booting
[10:35] <pitti> on !btrfs it'll probably take more like 10s, but still okay
[10:35] <Laney> yeah, lxc launch laneyscoolxenialcontainer gstreamer-test-1
[10:35] <Laney> then I can edit around in /usr seb128 style too
[10:36]  * Laney pew pew pew
[10:36] <Laney> ;-)
[10:36] <seb128> lol
[10:36] <seb128> willcooke, yw!
[10:36] <pitti> oh, seb128 doesn't use dput, but sudo vi /usr/.. ?
[10:36] <Laney> I admit it is quite convenient for some types of changes
[10:36] <Laney> like fixing python stuff
[10:37] <pitti> sure, we all do that
[10:37] <Laney> would be better to do it in a scratch environment though
[10:37] <Laney> apt-get install --reinstall ♥
[10:59] <Trevinho> hikiko: I think is fine
[11:01] <hikiko> thanks Trevinho
[11:18] <willcooke> tkamppeter, thanks for the bug
[12:00] <pitti> seb128: how is lxd going?
[12:33] <seb128> pitti, lunch went in the way, looking at it now ;-)
[12:40] <seb128> pitti, thanks for the lock fix!
[12:42] <pitti> thanks for spotting it :)
[12:50] <willcooke> damn it Laney.  Now I can't get "Hello.  That's a nice Tnetennba!" out of my head
[12:51] <seb128> lol
[12:51] <pitti> a WHAT?
[12:51] <seb128> willcooke, and no, I didn't see that one yet :-)
[12:52] <willcooke> pitti, a Tnetennba, as in.. "Hello.  That's a nice Tnetennba"
[12:53] <willcooke> https://www.youtube.com/watch?v=lsFAokXCxTI
[12:53] <Laney> haha
[12:54] <Laney> good old Moss
[12:54] <pitti> oh, IT crowd?
[12:54] <Laney> yyyyyyyyyyyyyup
[12:56] <pitti> oh dear, I forgot this one
[13:11] <Trevinho> seb128: did you see my nautilus branch?
[13:16] <Mirv> with 14.04.4 planned for next Thu, what's up with the wily HWE stuck in -proposed? (I've been running it on broadwell and haswell + radeon 7750 problem free myself)
[13:25] <seb128> Trevinho, no, thanks for pointing it out
[13:25] <seb128> Mirv, that's a question for tjaalton I guess?
[13:34] <Mirv> seb128: probably yes, although maybe also stable release updates team might know
[13:35] <seb128> Mirv, right, that not really desktopish though ;-)
[13:35] <Mirv> yes yes :)
[13:36] <seb128> it feels like point updates used to be better organized though, with remainers before, a push to landed wanted changes etc
[13:37] <tjaalton> infinity should know
[13:46] <seb128> Sweet5hark1, hey, how is that libreoffice update going? you said you had it ready like 10 days ago, did I miss the sponsoring request or did you hit issues on the way?
[13:52] <Sweet5hark1> seb128: hit an issue. I did a testbuild on all arches (mostly to make sure armhf is happy) ...
[13:53] <Sweet5hark1> ... and then ppc64el stumbled over itself in the most weird way.
[13:53] <Sweet5hark1> (armhf is fine as are all other platforms)
[13:54] <davmor2> Sweet5hark1: do we even ship ppc64el?
[13:54] <Trevinho> seb128: I've some problems with wallpaper in the current 3.14 nautilus... Is that something you're still working on?
[13:54] <Sweet5hark1> davmor2: we did have ppc64el in wily.
[13:56] <Sweet5hark1> seb128, davmor2: That said, I found this: https://github.com/LibreOffice/core/commit/8d1a24dae03690b576310e3539369916f31ac475 -- an epic tale of toolchain and C++ madness and suspect it will fix this.
[13:56] <Sweet5hark1> strange though to see this only break on ppc64el.
[13:58] <Sweet5hark1> but yeah, if this is more complex, I would ask if we really need to build ppc64el ...
[14:02] <seb128> Trevinho, what sort?
[14:02] <seb128> Sweet5hark1, let me know how that patch goes
[14:03] <Sweet5hark1> seb128: sure, this should be quickish hopefully.
[14:04] <Sweet5hark1> (I shouldnt say that. Hope is the field where fools graze.)
[14:57] <ximion> Laney: all bugs in gnome-software and other components that I had on my todo list are fixed now :)
[14:58] <ximion> I will make an AppStream release today, after cleaning up a few more things, and already uploaded a PackageKit version with the removal-issue fixed to unstable
[14:58] <Laney> hi ximion
[14:58] <Laney> what's up?
[14:58] <ximion> Laney: can you pull the dep11-generator code again? ;-)
[14:59] <ximion> you will see a massive amount of added info-type hints, since it is now using package descriptions for long descriptions, which isn't nice ;-)
[14:59] <Laney> ximion: I need a firewall fix so that it can actually download screenshots
[14:59] <Laney> and connect to github...
[14:59] <ximion> ah, that is the reason for the missing screenshots :)
[14:59] <Laney> yeah, proxy fun
[15:00] <Laney> does the description thing mean we don't need this gsettings override now?
[15:00] <ximion> gnome-software still has some weird quirks, e.g. it doesn't show our favourite testcase "robocode" now because it fails to find/load a pixmap
[15:00] <ximion> while the pixmap is clearly there
[15:01] <ximion> that is the only remaining issue I have, the rest is fixed
[15:03] <ximion> Laney: we can't use the gsettings override, because upstream dropped that particular code
[15:03] <ximion> so adding the package description was the second-best option
[15:03] <ximion> still, people should really write metainfo files
[15:04] <Laney> nod
[15:04] <Laney> or write description with software centers in mind
[15:11] <GunnarHj> Hi Laney, do you possibly have time to help with bug #1539885?
[15:11] <ubot5`> bug 1539885 in trusty-backports "Please backport svtplay-dl 0.30.2016.01.10-1 (universe) from xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1539885
[15:16] <seb128> pitti, so, the software-properties issue is due to your gnupg update, trying to figure out what changed exactly
[15:26] <Laney> GunnarHj: alright, just going to lunch though
[15:27] <GunnarHj> Laney: Great, TIA and have a nice meal. :)
[15:27] <Laney> I was thinking last night about fixing backports
[15:27] <Laney> it's stupid to have two active people trying to deal with the whole thing
[15:27] <Laney> we should just open it up
[15:28] <GunnarHj> Laney: Do you mean so all ubuntu core members could upload?
[15:29] <Laney> GunnarHj: something like that
[15:30] <GunnarHj> Laney: Makes a lot of sense to me.
[16:07] <willcooke> seb128, should I log a but for passwd depends on init-system-helpers (>= 1.18~); however:
[16:07] <willcooke>   Version of init-system-helpers on system is 1.14.
[16:07] <seb128> willcooke, yes please
[16:07] <attente> seb128: hey, do you want me to backport the patch for the unity-greeter indicators?
[16:07] <seb128> attente, oh, it got reviewed? good :-) If you want to, sure, otherwise I was going to do it
[16:08] <attente> no worries, i'll do it
[16:11] <seb128> thanks
[16:12] <willcooke> seb128, FYI: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1541914
[16:12] <ubot5`> Launchpad bug 1541914 in init-system-helpers (Ubuntu) "passwd depends on init-system-helpers (>= 1.18~); however: Version of init-system-helpers on system is 1.14" [Undecided,New]
[16:13] <seb128> willcooke, thanks
[16:13] <seb128> pitti, ^ do you know if that's a known issue?
[16:18] <pitti> err, what? we have 1.26ubuntu2
[16:19] <pitti> willcooke: do you have the full log? we need to know why init-system-helpers wasn't upgraded
[16:19] <seb128> pitti, it's trusty to xenial upgrade
[16:19] <willcooke> pitti, I'll send you some links
[16:19] <seb128> pitti, https://platform-qa-jenkins.ubuntu.com/view/Upgrade/job/upgrade_ubuntu-trusty-xenial-basic-amd64_qemu/73/console
[16:20]  * pitti in meeting and vsprint, will look later, sorry
[16:21] <pitti> dpkg: considering deconfiguration of init-system-helpers, which would be broken by installation of upstart ...
[16:21] <pitti> dpkg: yes, will deconfigure init-system-helpers (broken by upstart)
[16:21] <pitti> looks like some circularity somewhere
[16:21] <willcooke> oh yeah
[16:23] <seb128> pitti, btw I found the issue with the software-properties autopkgtest but I've nfc how to solve it
[16:24] <seb128> pitti, the new gnupg seems to try to create a temp file on ~/.gnupg and displays a warning if the dir doesn't exists
[16:24] <pitti> seb128: ah, and it doesn't mkdir that dir?
[16:25] <seb128> no
[16:26] <seb128> pitti, doing mkdir "$tmpdir/.gnupg"; export HOME="$tmpdir"
[16:26] <seb128> in run-tests
[16:26] <seb128> makes it work
[16:26] <seb128> but it's hackish/not a fix
[16:27] <pitti> seb128: yeah, I figure we should quiesce the warning in GPG instead, and just make it silently not create the socket
[16:29] <pitti> $ HOME=/tmp/h gpg -c /tmp/index.txt
[16:29] <pitti> gpg: Verzeichnis `/tmp/h/.gnupg' erzeugt
[16:29] <pitti> gpg: Neue Konfigurationsdatei `/tmp/h/.gnupg/gpg.conf' erstellt
[16:30] <pitti> sorry, c'est allemand
[16:30] <pitti> seb128: it does seem to create ~/.gnupg here, but it blabbers about it; I guess you mean that?
[16:30] <pitti> seb128: oh, I get a "fatal" if $HOME doesn't exist at all
[16:31] <seb128> pitti, no, I can't reproduce running the command manually
[16:31] <pitti> for a test $HOME ought to exist
[16:31] <seb128> unsure why
[16:31] <seb128> the script runs
[16:31] <seb128> "/usr/bin/gpg --no-options --no-default-keyring --no-auto-check-trustdb --trust-model always --keyring /build/software-properties-0.96.17/tests/aptroot/etc/apt/trusted.gpg --secret-keyring /tmp/tmpohq9ksnp/secring.gpg --quiet --batch --import /build/software-properties-0.96.17/tests/data/testkey.gpg"
[16:31] <pitti> $ LC_ALL=C HOME=/tmp/noexist gpg -c /tmp/index.txt
[16:31] <pitti> gpg: fatal: can't create directory `/tmp/noexist/.gnupg': No such file or directory
[16:31] <seb128> which returns the warning and err 2
[16:32] <seb128> but the same command started manually works without warning and returns 0
[16:32] <pitti> seb128: try with HOME=/tmp/foo ?
[16:33] <pitti> so, why does that thing not have a $HOME -- does it change $HOME or change UID or so?
[16:35] <seb128> pitti, well, HOME=/tmp is enough, it fails if .gnupg doesn't exist
[16:35] <seb128> pitti, it fails with my user if I mv .gnupg away
[16:36] <pitti> interesting, a simple gpg -c mkdir's ~/.gnupg, but fails if $HOME doesn't exist itself
[16:37] <seb128> pitti, I opened https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1541925
[16:37] <ubot5`> Launchpad bug 1541925 in gnupg (Ubuntu) "Tries to create temp files under ~/.gnupg but doesn't create the dir" [Undecided,New]
[17:45] <qengho> seb128: is the problem that it doesn't expand "~"?
[17:46] <qengho> Ah.
[17:46] <seb128> qengho, not that I know, ~ is not used in the command line
[17:50] <attente> what about setting GNUPGHOME="$tmpdir"?
[17:57] <qengho> What do you use, if anything, to keep your gpg keys seperate from your machine? I have /home/me/.gnupg as a symlink to /media/me/somedevicename/aribtrarycontainer/gnupg . When device is not plugged in, it doesn't try to create arbitrarycontainer and fails in a predictable way that lets me know I forgot to plug in my secret storage device.
[17:57] <seb128> attente, I guess that would work, but it's still a workaround, we should probably just fix gnupg to mkir the dir in this case or create another dir rather than erroring out, it's an implementation detail from gpg not an user fault
[17:59] <attente> qengho: i use subkeys, keeping the master key on a few luks-encrypted usb flash drives, only the subkeys are on my machine
[18:00] <attente> seb128: yeah, sounds reasonable
[18:01] <attente> qengho: and then when you have to use the master key, mount and set GNUPGHOME=/media/whatever when using gpg/gpg2
[18:03] <qengho> attente: thanks. I also have subkeys only on the device that fits in my pocket. I'm aiming to have keys un-leakable except when I need them used.
[18:03] <qengho> seb128: so, I hope the solution isn't deref symlink and then "mkdir -p". That messes me up.
[18:04] <seb128> yeah
[18:06] <attente> qengho: maybe i'm not paranoid enough :)
[19:01] <willcooke> tjaalton, just assigning the omap bug to you so that TI can see that we're doing something with it
[19:01] <tjaalton> ok
[19:01] <willcooke> I see you've already logged u/s - thank you
[19:02] <tjaalton> fyi, i'll send a CFT tomorrow about the new xserver (1.18), packages built at https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging
[19:02] <willcooke> thx tjaalton
[19:03] <tjaalton> nvidia already supports it in the main archive
[19:03] <willcooke> I'll pimp on G+ etc
[19:03] <TheMuso> Hey folks.
[19:04] <willcooke> morning TheMuso, you're up early
[19:04] <TheMuso> willcooke: A combination of things results in this being the case. :)
[19:04] <TheMuso> But yes, I am indeed. I am actually usually up at this time, but not usually at my computer.
[19:10] <TheMuso> willcooke: Hrm so turns out that the UI I was referring to last night that could be used to turn on/off the accessibility profile indicator is present in vanilla GNOME 3.18 control center, but not in ours. :) The universal access panel in vanilla GNOME is also layed out differently.
[19:11] <TheMuso> So I guess its time to work out how to squeeze that back into our universal access panel somehow...
[19:11] <willcooke> they layout of ours is pretty terrible tbh
[19:12] <willcooke> e.g. the typing pane is a mess of text and buttons
[19:12] <willcooke> not especially accessible
[19:12] <TheMuso> Yeah, at least in terms of universal access, I find the pure GNOME layout to be easier to navigate.
[19:12] <TheMuso> i.e one big table list of settings with headings, as opposed to notebook pages.
[19:12] <willcooke> heh
[19:13] <willcooke> I was about to say...
[19:13] <willcooke> how about another notebook tab
[19:13] <TheMuso> Thats what I was thinking, and if we do that, I may as well look into listing the profiles there an dallowing them to be activated/deactivated if I have time, because one page with one single switch will look pretty empty.
[19:13] <TheMuso> Which is what I was thinking in the first place anyway.
[19:14] <TheMuso> I'll see what I can do.
[19:14] <willcooke> thx TheMuso
[19:38] <willcooke> right, time to go
[19:38] <willcooke> g'nigth all
[19:49] <ximion> Laney: I profiled the dep11-generator, it looses most of the time in getting file-lists from .deb files also wastes a fair bit of time in urlopen()
[19:49] <ximion> when processing many packages, the time needed reading the contents file isn't that much
[19:50] <ximion> so, if the Contents.gz file would be more reliable and would e.g. contain information about the package versions, we could speed up the generator drmatically
[20:57] <ximion> robert_ancell: hi! If you want to, upgrade packagekit, appstream, appstream-glib to the versions I uploaded to Debian unstable today
[20:57] <ximion> this should make your life much more pleasant by fixing gnome-software bugs ;-)
[20:59] <robert_ancell> ximion, hi, we've decided there's too many risks updating PackageKit for 16.04 and are looking at an apt backend to GNOME Software. It's in the wip/rancell/apt branch on GNOME git
[20:59] <pitti> robert_ancell: that's aptdaemon, or session-installer, or something new?
[20:59] <pitti> (just OOI)
[21:00] <robert_ancell> pitti, yeah, using aptdaemon for install / remove
[21:00] <pitti> well, session-installer is also aptdaemon, but its API is closer to PK AFAIK
[21:01] <ximion> robert_ancell: I don't like that, but whatever works for you is fine - creating a new plugin is by far the much better approach to it than the previously discussed "let-aptd-pretend-to-be-packagekit" thing
[21:01] <robert_ancell> pitti, is there any reason to use session-installer over aptdaemon
[21:01] <robert_ancell> ximion, yeah, the whole aptd PK thing is a big mess
[21:02] <ximion> pitti: sessioninstaller is aptds reimplementation of the PackageKit session interface, which is normally provided by GNOME Software, GNOME PackageKit and Apper
[21:03] <ximion> the PK session API is very high-level and is normally what is used by applications which just want to install something without having to create own GUI dialogs
[21:03] <ximion> so, not something you'd want for GS itself
[21:04] <ximion> robert_ancell: having a version of packagekit in Ubuntu which is 2 years old and completely unsupported would be a risk as well
[21:04] <ximion> I fixed some security issues a long time ago, not sure if those made it to Ubuntu
[21:04] <robert_ancell> ximion, it is, but we want to disconnect the goal of replacing gnome-software from updating PackageKit
[21:05] <ximion> okay, splitting it seems like a good plan if you have deadlines
[21:05] <robert_ancell> ximion, We can still update PackageKit as long as it works in parallel with aptdaemon. Which should be possible afaik.
[21:05] <robert_ancell> (dropping the aptd PK support in the process)
[21:05] <robert_ancell> yeah, deadlines :(
[21:06] <ximion> sounds like a good plan to me, actually :)
[21:07] <ximion> robert_ancell: the PK update I pushed to Debian fixes the removal bug larsu resolved, the appstream-glib update solves some asglib-doesn't-follow-appstream-or-dep11-spec issues, and the appstream update makes the APT integration work a bit better
[21:07] <robert_ancell> ximion, cool, thanks
[21:07] <ximion> together with the changes in the generator, the experience is pretty smooth here
[21:08] <ximion> although there is one bug, where GS says it can't find/load a pixmap, although the icon pixmap is clearly there
[21:08] <ximion> an example for this would be robocode
[21:09] <ximion> just so you know this is known, in case you run into it - I have no idea yet why this happens, it seems to just hit a few apps and not all of them