[00:02] -queuebot:#ubuntu-release- New binary: kamailio [arm64] (groovy-proposed/universe) [5.4.0-2] (no packageset)
[00:02] -queuebot:#ubuntu-release- New binary: cod-tools [ppc64el] (groovy-proposed/universe) [3.0.1+dfsg-1] (no packageset)
[00:05] -queuebot:#ubuntu-release- New binary: kamailio [armhf] (groovy-proposed/universe) [5.4.0-2] (no packageset)
[00:09] -queuebot:#ubuntu-release- New binary: enki-aseba [riscv64] (groovy-proposed/universe) [1:1.6.99-1] (no packageset)
[00:24] -queuebot:#ubuntu-release- New binary: mldonkey [riscv64] (groovy-proposed/universe) [3.1.7-2] (no packageset)
[01:01] -queuebot:#ubuntu-release- New binary: cod-tools [arm64] (groovy-proposed/universe) [3.0.1+dfsg-1] (no packageset)
[01:14] -queuebot:#ubuntu-release- New binary: librsb [riscv64] (groovy-proposed/universe) [<IP_ADDRESS>+dfsg.1-2] (no packageset)
[01:16] -queuebot:#ubuntu-release- New binary: cod-tools [armhf] (groovy-proposed/universe) [3.0.1+dfsg-1] (no packageset)
[01:16] -queuebot:#ubuntu-release- Unapproved: accepted libglvnd [source] (focal-proposed) [1.3.1-1ubuntu<IP_ADDRESS>]
[01:22] -queuebot:#ubuntu-release- Unapproved: accepted zsys [source] (focal-proposed) [0.4.7]
[02:19] -queuebot:#ubuntu-release- Unapproved: accepted pyflakes [source] (focal-proposed) [2.2.0-1~20.04.1]
[02:25] -queuebot:#ubuntu-release- Unapproved: accepted pycodestyle [source] (focal-proposed) [2.6.0-1~20.04.1]
[02:27] -queuebot:#ubuntu-release- Unapproved: accepted python-flake8 [source] (focal-proposed) [3.8.3-1~20.04.1]
[02:39] -queuebot:#ubuntu-release- Unapproved: accepted flatpak [sync] (focal-proposed) [1.6.5-0ubuntu0.1]
[03:09] -queuebot:#ubuntu-release- New binary: kamailio [riscv64] (groovy-proposed/universe) [5.4.0-2] (no packageset)
[07:17] -queuebot:#ubuntu-release- New binary: gitit [armhf] (groovy-proposed/universe) [<IP_ADDRESS>+dfsg-1] (no packageset)
[08:16] -queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu2.8 => 10.1ubuntu2.9] (core)
[08:21] -queuebot:#ubuntu-release- New: accepted kamailio [amd64] (groovy-proposed) [5.4.0-2]
[08:21] -queuebot:#ubuntu-release- New: accepted kamailio [armhf] (groovy-proposed) [5.4.0-2]
[08:21] -queuebot:#ubuntu-release- New: accepted kamailio [riscv64] (groovy-proposed) [5.4.0-2]
[08:21] -queuebot:#ubuntu-release- New: accepted kamailio [arm64] (groovy-proposed) [5.4.0-2]
[08:21] -queuebot:#ubuntu-release- New: accepted kamailio [s390x] (groovy-proposed) [5.4.0-2]
[08:21] -queuebot:#ubuntu-release- New: accepted kamailio [ppc64el] (groovy-proposed) [5.4.0-2]
[08:22] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10.1ubuntu2.9]
[08:22] -queuebot:#ubuntu-release- New: accepted librsb [amd64] (groovy-proposed) [<IP_ADDRESS>+dfsg.1-2]
[08:22] -queuebot:#ubuntu-release- New: accepted librsb [armhf] (groovy-proposed) [<IP_ADDRESS>+dfsg.1-2]
[08:22] -queuebot:#ubuntu-release- New: accepted librsb [riscv64] (groovy-proposed) [<IP_ADDRESS>+dfsg.1-2]
[08:22] -queuebot:#ubuntu-release- New: accepted libtest-hexdifferences-perl [amd64] (groovy-proposed) [1.001-2]
[08:22] -queuebot:#ubuntu-release- New: accepted libuev [arm64] (groovy-proposed) [2.3.1-1]
[08:22] -queuebot:#ubuntu-release- New: accepted libuev [riscv64] (groovy-proposed) [2.3.1-1]
[08:22] -queuebot:#ubuntu-release- New: accepted librsb [arm64] (groovy-proposed) [<IP_ADDRESS>+dfsg.1-2]
[08:22] -queuebot:#ubuntu-release- New: accepted librsb [s390x] (groovy-proposed) [<IP_ADDRESS>+dfsg.1-2]
[08:22] -queuebot:#ubuntu-release- New: accepted libuev [armhf] (groovy-proposed) [2.3.1-1]
[08:22] -queuebot:#ubuntu-release- New: accepted librsb [ppc64el] (groovy-proposed) [<IP_ADDRESS>+dfsg.1-2]
[08:22] -queuebot:#ubuntu-release- New: accepted libuev [s390x] (groovy-proposed) [2.3.1-1]
[08:22] -queuebot:#ubuntu-release- New: accepted libuev [amd64] (groovy-proposed) [2.3.1-1]
[08:22] -queuebot:#ubuntu-release- New: accepted enki-aseba [amd64] (groovy-proposed) [1:1.6.99-1]
[08:22] -queuebot:#ubuntu-release- New: accepted enki-aseba [ppc64el] (groovy-proposed) [1:1.6.99-1]
[08:22] -queuebot:#ubuntu-release- New: accepted enki-aseba [s390x] (groovy-proposed) [1:1.6.99-1]
[08:22] -queuebot:#ubuntu-release- New: accepted enki-aseba [arm64] (groovy-proposed) [1:1.6.99-1]
[08:23] -queuebot:#ubuntu-release- New: accepted enki-aseba [riscv64] (groovy-proposed) [1:1.6.99-1]
[08:23] -queuebot:#ubuntu-release- New: accepted ayatana-indicator-datetime [arm64] (groovy-proposed) [0.4.1-1]
[08:23] -queuebot:#ubuntu-release- New: accepted ayatana-indicator-datetime [ppc64el] (groovy-proposed) [0.4.1-1]
[08:23] -queuebot:#ubuntu-release- New: accepted ayatana-indicator-datetime [s390x] (groovy-proposed) [0.4.1-1]
[08:23] -queuebot:#ubuntu-release- New: accepted ayatana-indicator-datetime [armhf] (groovy-proposed) [0.4.1-1]
[08:23] -queuebot:#ubuntu-release- New: accepted ayatana-indicator-datetime [riscv64] (groovy-proposed) [0.4.1-1]
[08:23] -queuebot:#ubuntu-release- New: accepted mldonkey [amd64] (groovy-proposed) [3.1.7-1]
[08:23] -queuebot:#ubuntu-release- New: accepted mldonkey [armhf] (groovy-proposed) [3.1.7-1]
[08:23] -queuebot:#ubuntu-release- New: accepted mldonkey [s390x] (groovy-proposed) [3.1.7-1]
[08:23] -queuebot:#ubuntu-release- New: accepted mldonkey [arm64] (groovy-proposed) [3.1.7-2]
[08:23] -queuebot:#ubuntu-release- New: accepted mldonkey [ppc64el] (groovy-proposed) [3.1.7-2]
[08:23] -queuebot:#ubuntu-release- New: accepted mldonkey [s390x] (groovy-proposed) [3.1.7-2]
[08:23] -queuebot:#ubuntu-release- New: accepted mldonkey [arm64] (groovy-proposed) [3.1.7-1]
[08:24] -queuebot:#ubuntu-release- New: accepted mldonkey [amd64] (groovy-proposed) [3.1.7-2]
[08:24] -queuebot:#ubuntu-release- New: accepted mldonkey [riscv64] (groovy-proposed) [3.1.7-2]
[08:24] -queuebot:#ubuntu-release- New: accepted mldonkey [ppc64el] (groovy-proposed) [3.1.7-1]
[08:24] -queuebot:#ubuntu-release- New: accepted mldonkey [armhf] (groovy-proposed) [3.1.7-2]
[08:24] -queuebot:#ubuntu-release- New: accepted ayatana-indicator-datetime [amd64] (groovy-proposed) [0.4.1-1]
[08:24] -queuebot:#ubuntu-release- New: accepted cava-alsa [arm64] (groovy-proposed) [0.7.2-1]
[08:24] -queuebot:#ubuntu-release- New: accepted cava-alsa [ppc64el] (groovy-proposed) [0.7.2-1]
[08:24] -queuebot:#ubuntu-release- New: accepted cava-alsa [s390x] (groovy-proposed) [0.7.2-1]
[08:24] -queuebot:#ubuntu-release- New: accepted cava-alsa [amd64] (groovy-proposed) [0.7.2-1]
[08:24] -queuebot:#ubuntu-release- New: accepted cava-alsa [riscv64] (groovy-proposed) [0.7.2-1]
[08:24] -queuebot:#ubuntu-release- New: accepted cava-alsa [armhf] (groovy-proposed) [0.7.2-1]
[08:24] -queuebot:#ubuntu-release- New: accepted wlogout [amd64] (groovy-proposed) [1.1.1-1]
[08:24] -queuebot:#ubuntu-release- New: accepted wlogout [armhf] (groovy-proposed) [1.1.1-1]
[08:24] -queuebot:#ubuntu-release- New: accepted wlogout [riscv64] (groovy-proposed) [1.1.1-1]
[08:24] -queuebot:#ubuntu-release- New: accepted wlogout [arm64] (groovy-proposed) [1.1.1-1]
[08:24] -queuebot:#ubuntu-release- New: accepted wlogout [s390x] (groovy-proposed) [1.1.1-1]
[08:25] -queuebot:#ubuntu-release- New: accepted wlogout [ppc64el] (groovy-proposed) [1.1.1-1]
[08:25] -queuebot:#ubuntu-release- New: accepted jc [amd64] (groovy-proposed) [1.12.1-1]
[08:25] -queuebot:#ubuntu-release- New: accepted nvidia-settings-tesla-450 [amd64] (groovy-proposed) [450.57-1]
[08:25] -queuebot:#ubuntu-release- New: accepted nvidia-settings-tesla-450 [ppc64el] (groovy-proposed) [450.57-1]
[08:25] -queuebot:#ubuntu-release- New: accepted metamath-databases [amd64] (groovy-proposed) [0.0.0~20200715.git5b44899-1]
[08:25] -queuebot:#ubuntu-release- New: accepted nvidia-settings-tesla-450 [arm64] (groovy-proposed) [450.57-1]
[08:25] -queuebot:#ubuntu-release- New: accepted unison-2.48 [amd64] (groovy-proposed) [2.48.4-5]
[08:25] -queuebot:#ubuntu-release- New: accepted unison-2.48 [armhf] (groovy-proposed) [2.48.4-5]
[08:25] -queuebot:#ubuntu-release- New: accepted unison-2.48 [riscv64] (groovy-proposed) [2.48.4-5]
[08:25] -queuebot:#ubuntu-release- New: accepted unison-2.48 [arm64] (groovy-proposed) [2.48.4-5]
[08:25] -queuebot:#ubuntu-release- New: accepted unison-2.48 [s390x] (groovy-proposed) [2.48.4-5]
[08:26] -queuebot:#ubuntu-release- New: accepted unison-2.48 [ppc64el] (groovy-proposed) [2.48.4-5]
[09:18] <xnox> vorlon:  ack.
[09:19] <xnox> vorlon:  i think we do want to make shim builds to spit out public portion of the ephemeral cert & detached signatures of things it signed. Such that we can provide docker container with rebuild instructions to reproducibly rebuild shim for shim-review process.
[09:37] -queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.6 => 2.20.11-0ubuntu27.7] (core, i386-whitelist)
[10:32] -queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[10:35] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [<IP_ADDRESS>]
[14:01] -queuebot:#ubuntu-release- New binary: cod-tools [riscv64] (groovy-proposed/universe) [3.0.1+dfsg-1] (no packageset)
[14:08] -queuebot:#ubuntu-release- New: accepted cod-tools [amd64] (groovy-proposed) [3.0.1+dfsg-1]
[14:08] -queuebot:#ubuntu-release- New: accepted cod-tools [armhf] (groovy-proposed) [3.0.1+dfsg-1]
[14:08] -queuebot:#ubuntu-release- New: accepted cod-tools [riscv64] (groovy-proposed) [3.0.1+dfsg-1]
[14:08] -queuebot:#ubuntu-release- New: accepted cod-tools [arm64] (groovy-proposed) [3.0.1+dfsg-1]
[14:08] -queuebot:#ubuntu-release- New: accepted cod-tools [s390x] (groovy-proposed) [3.0.1+dfsg-1]
[14:08] -queuebot:#ubuntu-release- New: accepted cod-tools [ppc64el] (groovy-proposed) [3.0.1+dfsg-1]
[15:57] -queuebot:#ubuntu-release- Unapproved: base-files (xenial-proposed/main) [9.4ubuntu4.11 => 9.4ubuntu4.12] (core)
[16:07] -queuebot:#ubuntu-release- New: accepted golang-github-gcp-guest-logging-go [source] (groovy-proposed) [0.0~git20200113.6cbb518-0ubuntu1]
[16:09] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (xenial-proposed) [9.4ubuntu4.12]
[16:14] -queuebot:#ubuntu-release- New binary: golang-github-gcp-guest-logging-go [amd64] (groovy-proposed/none) [0.0~git20200113.6cbb518-0ubuntu1] (no packageset)
[16:23] -queuebot:#ubuntu-release- Unapproved: ubiquity (xenial-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[16:49] -queuebot:#ubuntu-release- New source: motd-news-config (groovy-proposed/primary) [1]
[16:50] <ahasenack> vorlon: ^ motd-news-config
[16:50] <ahasenack> vorlon: if/after that lands, then I have ubuntu-meta and base-files
[16:51] <ahasenack> if you prefer, I can upload them now, but they won't migrate
[17:18] -queuebot:#ubuntu-release- New binary: lrslib [amd64] (groovy-proposed/universe) [0.71-6] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: lrslib [s390x] (groovy-proposed/universe) [0.71-6] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: lrslib [ppc64el] (groovy-proposed/universe) [0.71-6] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: lrslib [arm64] (groovy-proposed/universe) [0.71-6] (no packageset)
[17:33] -queuebot:#ubuntu-release- New binary: lrslib [armhf] (groovy-proposed/universe) [0.71-6] (no packageset)
[17:37] -queuebot:#ubuntu-release- New binary: lrslib [riscv64] (groovy-proposed/universe) [0.71-6] (no packageset)
[17:50] <rbalint> sil2100, please merge those for glibc's next upload https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/388675
[18:00] <tumbleweed> seb128: hah, I was just about to apply that automake patch, thanks :)
[18:23] <seb128> tumbleweed, yw!
[19:09] <vorlon> sil2100: I don't see any updated autopkgtest hints for the systemd bionic SRU you accepted, could we have those marked so that future SRUs don't trip over the same things?
[19:27] -queuebot:#ubuntu-release- New: accepted lrslib [riscv64] (groovy-proposed) [0.71-6]
[19:28] <vorlon> ahasenack: I wonder if motd-news-config should be built from base-files source instead, to keep it close to the code whose behavior it modifies
[19:28] -queuebot:#ubuntu-release- New: accepted gitit [armhf] (groovy-proposed) [<IP_ADDRESS>+dfsg-1]
[19:28] -queuebot:#ubuntu-release- New: accepted lrslib [amd64] (groovy-proposed) [0.71-6]
[19:28] -queuebot:#ubuntu-release- New: accepted lrslib [armhf] (groovy-proposed) [0.71-6]
[19:28] -queuebot:#ubuntu-release- New: accepted lrslib [s390x] (groovy-proposed) [0.71-6]
[19:28] -queuebot:#ubuntu-release- New: accepted gitit [ppc64el] (groovy-proposed) [<IP_ADDRESS>+dfsg-1]
[19:28] -queuebot:#ubuntu-release- New: accepted lrslib [ppc64el] (groovy-proposed) [0.71-6]
[19:28] -queuebot:#ubuntu-release- New: accepted lrslib [arm64] (groovy-proposed) [0.71-6]
[19:28] -queuebot:#ubuntu-release- New: accepted gitit [amd64] (groovy-proposed) [<IP_ADDRESS>+dfsg-1]
[19:28] -queuebot:#ubuntu-release- New: accepted gitit [s390x] (groovy-proposed) [<IP_ADDRESS>+dfsg-1]
[19:33] -queuebot:#ubuntu-release- Unapproved: glibc (focal-proposed/main) [2.31-0ubuntu9 => 2.31-0ubuntu9.1] (core, i386-whitelist)
[19:44] -queuebot:#ubuntu-release- New: accepted google-osconfig-agent [source] (groovy-proposed) [20200625.00-0ubuntu1]
[19:51] -queuebot:#ubuntu-release- New: accepted google-guest-agent [source] (groovy-proposed) [20200617.00-0ubuntu1]
[20:01] <ahasenack> vorlon: that's a new approach
[20:02] <ahasenack> vorlon: do you prefer that?
[20:42] <vorlon> ahasenack: I do think there's less risk of things getting mistakenly out of sync if we do that.  It increases the delta vs Debian, but we already have a permanent delta and it shouldn't be problematic for merging
[20:43] <ahasenack> vorlon: ok, let me work on that. Any other comment regarding the contents, like the postinst?
[20:43] <ahasenack> which I will copy
[20:44] <vorlon> ahasenack: I haven't looked at the contents yet :)
[20:44] <ahasenack> can you, just do avoid another round trip?
[20:44] <vorlon> sure
[20:44] <ahasenack> or do you prefer I do the packaging change first
[21:11] <vorlon> ahasenack: looks ok to me if it works
[21:12] <ahasenack> vorlon: my testing was this: https://pastebin.ubuntu.com/p/JkV2ZFSVy6/
[21:15] <vorlon> ahasenack: yep, looks good
[21:15] <ahasenack> ok, thanks
[21:15] <vorlon> ahasenack: oh, what about a test of upgrading ubuntu-server?
[21:15] <ahasenack> vorlon: sounds good, it will pull in motd-news-config and force upgrade base-files
[21:17] <ahasenack> vorlon: the relationships I have in groovy are: https://pastebin.ubuntu.com/p/P8BQrSwVdS/
[21:17]  * vorlon nods
[21:17] <ahasenack> motd-news-config was v1 there, will be the same version as base-files
[21:21] <arnatious> Overseeing an SRU in proposed that caused an autopkgtest failure, anyone willing to guide me through the process of diagnosing/fixing?
[21:25] <ahasenack> arnatious: did you get to the logs yet?
[21:25] <ahasenack> arnatious: or you just got the notification that it failed?
[21:25] <arnatious> ahasenack yeah, logs are up
[21:26] <ahasenack> arnatious: can you determine if the failure is real and a result of the SRU?
[21:27] <arnatious> ahasenack yes, the SRU causes a test failure in one package, some of the others are flakey or seem unrelated (files not found when initializing the test)
[21:27] <arnatious> or just segfaulting right after saying "all tests passed"
[21:28] <arnatious> SRU is for a python package, specifically flake8, a linter
[21:28] <ahasenack> arnatious: are you the author of the sru?
[21:29] <arnatious> ahasenack ish. Its a backport of a future version
[21:29] <ahasenack> well, segfaults are bad
[21:30] <ahasenack> next step would be to try to reproduce the error locally
[21:30] <ahasenack> you can also check the history of that test, see if it was segfaulting before
[21:30] <ahasenack> btw, this belongs in #ubuntu-devel, not here, sorry for only now noticing it
[21:31] <arnatious> Ah darn sorry going off of https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
[21:31] <arnatious> Hopping over there
[23:15] -queuebot:#ubuntu-release- New binary: mercantile [amd64] (groovy-proposed/none) [1.1.5-1] (no packageset)


[00:01] <mup> PR snapcraft#1180 closed: tests: support snap directory in external tests <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1180>
[00:22] <mup> PR snapcraft#827 closed: Support setting build targets in the maven plugin. Make the maven plu… <Created by evandandrea> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/827>
[02:19] <mup> PR snapcraft#1181 opened: repo: fixup with python, not sed <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1181>
[02:19] <mup> PR snapcraft#1182 opened: meta: do not quote the command wrapper args <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1182>
[02:26] <Son_Goku> sergiusens: ping
[02:53] <sergiusens> mwhudson: hey, would this fix my problem https://github.com/lxc/lxd-pkg-ubuntu/pull/27 ?
[02:53] <mup> PR lxc/lxd-pkg-ubuntu#27: Quote $@ in the lxc wrapper <Created by sergiusens> <https://github.com/lxc/lxd-pkg-ubuntu/pull/27>
[02:53] <sergiusens> Son_Goku: pong, but you know I am more reliable on rocket ;-)
[02:53] <mwhudson> sergiusens: that looks more plausible yes
[02:54] <Son_Goku> mrrr
[02:54] <sergiusens> mwhudson: great, I guess I can propose for the use of environment and get rid of the wrapper in that branch too
[02:55] <mwhudson> sergiusens: in fact i said on the bug "This bug looks more like a $@ that should be quoted isn't rather than one that is quoted and shouldn't be." :-)
[02:55] <mwhudson> (this hasn't gone out in mail yet afaict)
[02:55] <sergiusens> ah, thanks, well I will invalidate the bug, thanks
[02:55] <mup> PR snapcraft#1182 closed: meta: do not quote the command wrapper args <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1182>
[02:55] <mwhudson> sergiusens: bash quoting is comletely insane
[02:55] <mwhudson> +p
[02:55] <sergiusens> mwhudson: when it comes to something stgraber did I sometimes just doubt myself too much :-)
[02:56] <mwhudson> haha
[07:16] <justinmcp> hey all, can I add gcc, et al., to a snap so that scripts in the snap can compile?
[07:30] <mup> PR snapd#2302 closed: asserts: implement snap-developer type <Created by emgee> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2302>
[07:46] <mup> PR snapcraft#1183 opened: First step; ruby support <Created by justincan> <https://github.com/snapcore/snapcraft/pull/1183>
[07:46] <mup> PR snapd#2752 closed: snap: add support user-sessions from snaps <Blocked> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2752>
[08:45] <mup> PR snapd#2938 closed: cmd/snap-update-ns: compute next action to transition mount profile <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2938>
[08:52] <mup> PR snapd#2782 closed: timeutil: a bunch of helpers for the scheduled refreshes <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2782>
[09:01] <mup> PR snapd#2787 closed: interfaces: add unity8 plug permissions <Created by mikix> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2787>
[09:47] <mup> PR snapd#2978 closed: cmd/snap-confine: use sc_do_umount everywhere <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2978>
[10:03] <mup> Bug #1590767 changed: Support snap installed completion scripts <isv> <snapd-interface> <Snapcraft:Triaged> <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1590767>
[10:20] <mup> PR snapd#2930 closed: tests: add systemd dependency loop failover test scenario <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2930>
[10:27] <mup> Bug #1671776 opened: snap install halt during installation <Snappy:New> <https://launchpad.net/bugs/1671776>
[10:36] <mup> Bug #1671778 opened: failover:emptysystemd test fails <Canonical System Image:New> <Snappy:New> <https://launchpad.net/bugs/1671778>
[11:22] <mup> PR snapcraft#1181 closed: repo: fixup with python, not sed <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1181>
[11:25] <mup> PR snapcraft#1011 closed: ci: use a named docker instance with proper working dir and env <Created by 3v1n0> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1011>
[11:54] <mup> PR snapd#2972 closed: cmd/libsnap: add sc_quote_string <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2972>
[12:00] <mup> PR snapd#2963 closed: interfaces: use MockInfo in tests <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2963>
[12:19] <mup> PR snapd#2986 closed: tests: specify the core version to be unsquashfs'ed in the failover tests <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2986>
[12:20] <mup> PR snapd#3008 closed: testutils: address review feedback from PR#2997 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3008>
[12:25] <mup> PR snapd#3006 closed: interfaces: updates for mir-kiosk in browser-support, mir, opengl, unity7 <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3006>
[12:31] <mup> Bug #1671776 changed: snap install halt during installation <Snappy:Invalid> <https://launchpad.net/bugs/1671776>
[13:09] <mup> PR snapd#2984 closed: interfaces: seccomp spec API tweaks for better tests <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2984>
[13:09] <pstolowski> niemeyer, thank you!
[13:10] <niemeyer> pstolowski: np, and thanks for pushing those!
[13:31] <mup> PR snapcraft#1164 closed: tests: run the master tests against the staging server <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1164>
[14:01] <elopio> didrocks: I think the title here is wrong, because they are not all desktop snaps: https://insights.ubuntu.com/2017/03/09/10-desktop-snaps-written-in-february
[14:03] <mup> PR snapd#3013 opened: cmd/libsnap: simplify sc_string_quote default case <Created by zyga> <https://github.com/snapcore/snapd/pull/3013>
[14:37] <mup> PR snapcraft#1184 opened: store: enable retries for store calls <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1184>
[14:45] <joedborg> thanks for bringing build.snapcraft.io to my attention popey
[14:47] <didrocks> elopio: agreed, I didn't write the content though, just hilighted the ones that should be in
[14:47] <didrocks> elopio: I'll pass the message, but now that it's published…
[14:49] <didrocks> elopio: thanks for noticing btw :)
[14:55] <coreycb> elopio, do you recall what the reason was for having to build python for classic python snaps?  just curious for my own knowledge.
[14:56] <stokachu> anyone know if there is a kpi dashboard for snap downloads?
[14:56] <mup> PR snapd#3014 opened: tests: add dbus interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3014>
[14:57] <coreycb> stokachu, oh hey, maybe you know the answer to my question
[14:58] <stokachu> coreycb: hey! yea there was a reason i just dont remember it, lemme look through git logs
[14:58] <coreycb> stokachu, ok thanks, no big deal really, just curious
[14:59] <stokachu> coreycb: https://github.com/snapcore/snapcraft/issues/1080; https://github.com/snapcore/snapcraft/issues/1090
[14:59] <stokachu> think those were the 2 big ones
[15:00] <elopio> coreycb: I got lost there too. I just got that zyga has more details. Sergio can explain that too.
[15:00] <elopio> it seems both have migrated to rocket chat.
[15:03] <coreycb> stokachu, elopio: thanks.  they're not in here eh?
[15:42] <niemeyer> jdstrand: ping
[15:47] <jdstrand> niemeyer: hey, I saw all your PR pings
[15:47] <niemeyer> jdstrand: Heya
[15:47] <niemeyer> jdstrand: Yeah, was really about to see if you could do a run through today by any chance
[15:48] <jdstrand> niemeyer: I'm going to try my best to get to them today, but I need to attend to a high priority item before them
[15:48] <niemeyer> jdstrand: I did almost a full pass today, and there are quite a few low-hanging fruits in there
[15:48] <niemeyer> jdstrand: Thanks, appreciated!
[15:48] <jdstrand> niemeyer: my plan was: high priority item, go through low hanging fruits PRs and go to higher and higher hanging as have time :)
[15:51] <mup> Bug #1671855 opened: snap command should provide a way to display account ID <Snappy:New> <https://launchpad.net/bugs/1671855>
[15:52] <niemeyer> jdstrand: Sounds perfect, thanks!
[16:08] <jdstrand> niemeyer: I can say I did respond to the maliit one earlier
[16:09] <niemeyer> jdstrand: Sweet, I think that one is ready to merge
[16:11] <Trevinho> I'm running snapd in trusty (with xenial kernel backport)...
[16:11] <Trevinho> and after a reboot no snap seem to work
[16:11] <Trevinho> marco@tricky:~:✗ $ snap run hello
[16:11] <Trevinho> cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_BsULNe//dev: No such file or directory
[16:12] <mup> PR snapd#2793 closed: interfaces: add maliit input method interface <Created by Elleo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2793>
[16:18] <Trevinho> ok, for some reason I had core and multiple snaps marked as "broken"
[16:18] <Trevinho> now it works
[16:18] <Trevinho> check http://paste.ubuntu.com/24152298/
[17:18] <cachio> niemeyer, hi, I am trying to create 2 snaps which use the content interface, and it is not mounting as it would expected, do you know who could help we with that?
[17:19] <niemeyer> cachio: zyga is most familiar with those details.. we're aware of one bug that he's actually working on right now that might impact that exact case
[17:20] <niemeyer> cachio: What are the details?
[17:21] <cachio> basically, 1 snap is creating slots read and write and the other plugs those and it is trying to execute an executeble in the read section
[17:22] <cachio> niemeyer, but when I run the app, I make an ls inside it and I don0t see the directory  mounted where it should be
[17:22] <cachio> basically I should see a directory $SNAP/extra-bin and it is not there from the app context
[17:26] <cachio> niemeyer, should that be affected by that bug?
[17:27] <niemeyer> cachio: Might be.. try this: stop any daemons/processes running from that snap.. type "sudo rm /run/snapd/ns/<snap name>.*", then try again
[17:31] <cachio> niemeyer, getting rm: cannot remove '/run/snapd/ns/kpi-content-consumer-tests.mnt': Device or resource bus
[17:31] <cachio> y
[17:32] <cachio> niemeyer, and there are not any process/daemon running for that snap
[17:34] <niemeyer> cachio: That probably means something is still running from that snap
[17:35] <niemeyer> cachio: Sorry, you may need to umount it actually
[17:35] <niemeyer> cachio: sudo umount it
[17:38] <cachio> niemeyer, ok
[17:38] <cachio> cannot mount /snap/kpi-content-producer-tests/x14/bin at /snap/kpi-content-consumer-tests/x24/extra-bin with options bind,ro: No such file or directory
[17:38] <cachio> I should create the dir extra-bin first?
[17:42] <cachio> niemeyer, or snapd should do that?
[17:43] <niemeyer> cachio: That directory is read-only, so you need to provide it in your snap
[17:44] <cachio> niemeyer, ok, make sense
[18:01] <Fohlen-> heya there. Is it any way possible to use a virtualenv in a scriptlet?
[18:01] <Fohlen-> seems to be buggy as hell for me
[18:02] <Fohlen-> I do want to use conan which is installable via pip, but global install seems to be even more buggy
[18:03] <kyrofa> Fohlen-, hmm, and using `python-packages` isn't working?
[18:03] <kyrofa> Oh wait, conan is a build system huh
[18:03] <Fohlen-> kyrofa: nope.When using python from a scriptlet with the python plugin it falls back to the system python
[18:03] <Fohlen-> which is quiet annoying
[18:03] <kyrofa> Fohlen-, I've never tried with virtualenvs from scriptlets, but worst case you can write a custom plugin for it
[18:03] <Fohlen-> I probably have to
[18:03] <kyrofa> Fohlen-, yeah, that makes sense
[18:04] <kyrofa> Fohlen-, I think you've reached the limits of scriptlets, heh
[18:04] <Fohlen-> apparently I did :)
[18:04] <kyrofa> Fohlen-, just put the custom plugin in snap/plugins/, you can distribute it along with the snapcraft.yaml
[18:04] <Fohlen-> kyrofa: in that case I'd have to use env variables from snapcraft, would that be feasonable?
[18:05] <kyrofa> Fohlen-, I'm not sure what you mean
[18:05] <Fohlen-> consider this,       CONAN_USER_HOME=$SNAPCRAFT_PART_INSTALL/usr/local/games/inexor conan install . --build=missing
[18:05] <Fohlen-> as a plugin
[18:05] <Fohlen-> I'd need it to install the dependencies inside the snap, otherwise it breaks when packaging up
[18:05] <Fohlen-> :|
[18:06] <kyrofa> Oh certainly
[18:06] <kyrofa> Fohlen-, when you shell out to call conan, you can set the environment right there
[18:06] <Fohlen-> that was what I did initially, and it nicely broke up on another systm
[18:06] <Fohlen-> kyrofa: how'd I do that?
[18:06] <Fohlen-> and would that work out with a plugin?
[18:07] <Fohlen-> https://github.com/Fohlen/conan-snapcraft
[18:07] <Fohlen-> is what the plugin looks like
[18:08] <kyrofa> jdstrand, any idea what's happening here? https://askubuntu.com/questions/888497/snap-confine-refuses-to-launch-application-to-avoid-permission-attack
[18:11] <jdstrand> kyrofa: it looks like snap-confine is compiled for enforce mode and installed setuid but there is no apparmor profile for it
[18:11] <jdstrand> kyrofa: this is something zyga added recently
[18:11] <kyrofa> jdstrand, someone in rocket is getting that error claiming to be running normal Ubuntu 16.04. How could that happen?
[18:11] <kyrofa> Ah, hmm
[18:12] <jdstrand> kyrofa: perhaps the profile was unloaded?
[18:12] <jdstrand> kyrofa: eg, sudo aa-status | grep snap-confine
[18:13] <jdstrand> kyrofa: there is something mvo was working on that would run snap-confine from the core snap with a path to the profile from the core snap. not sure if that landed, but if it did and it is trying to run that snap-confine but that profile isn't loaded, the same thing would happen
[18:14] <kyrofa> jdstrand, oh interesting, although I expect that would break for everyone
[18:22] <kyrofa> jdstrand, of course, he left :(
[18:22] <kyrofa> jdstrand, well anyway, thanks for the info! Not sure what's happening here
[18:24] <cachio> niemeyer, working now, that umount that I have to do should be fixed whith that bug that you mentioned?
[18:24] <niemeyer> cachio: Right, it's supposed to work dynamically.. no need to do anything else other than connecting the interface
[18:24] <cachio> niemeyer, great, thanks
[18:24] <niemeyer> cachio: If you sit here in the channel in the next few days you'll hear about the term "update-ns".. that's what this is about
[18:25] <cachio> niemeyer, great
[18:26] <cachio> niemeyer, thanks for the help
[18:27] <lutostag> if somebody can review for snap id: N6CL1Ml1gj5SmGCmyy97CSvE3vzgjfb3, would be appreciated
[18:36] <mup> PR snapd#3015 opened: interfaces: alphabetize framebuffer in base decl and add it to all_test.go <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3015>
[18:50] <mup> PR snapcraft#1142 closed: state: asset tracking - store versions of stage-packages <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1142>
[18:50] <kyrofa> jdstrand, the user came back, saying the aa-status command you gave me produced no result, which I assume means the profile was unloaded somehow?
[18:58] <alecu> jhodapp: hi! I think there might be a markup mistake in this page, because code and prose sections seem to switch place towards the end of the document: https://docs.ubuntu.com/core/en/stacks/bluetooth/doc/overview
[18:58] <alecu> jhodapp: wanted to submit a patch, but I can't the bluetooth docs here: https://github.com/CanonicalLtd/ubuntu-core-docs/tree/master/en/stacks
[18:58] <alecu> am I looking at the right place?
[18:59] <jhodapp> alecu, the actual docs are part of the bluez snap
[18:59] <jhodapp> alecu, we keep them distributed and they get pulled in with repo
[18:59] <alecu> ah, that sounds better
[18:59] <jhodapp> that makes it much easier for developers to contribute docs
[18:59] <jhodapp> let me get you the link to the docs
[19:00] <jhodapp> alecu, here you go: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez/tree/doc/overview.md
[19:02] <alecu> jhodapp: seems to be be missing  ``` in line 199
[19:48] <alecu> jhodapp: https://code.launchpad.net/~alecu/snappy-hwe-snaps/+git/bluez/+merge/319613
[19:49] <jhodapp> alecu, nice
[19:49]  * jhodapp looks
[19:50] <alecu> took me a while to figure out git in lp :P
[19:50] <jhodapp> alecu, yes it's pretty different from the way most other git web systems work
[19:50] <jhodapp> we tried to fit a square peg in a round hole there ;)
[19:50] <alecu> hahah, right
[19:51] <jhodapp> alecu, good feedback on the docs too...we'll update the readme so that it's obvious that the stack documentation is distributed
[19:51] <alecu> jhodapp: btw, do you know if bluetooth is supported on the raspi3 with core? I can't seem to get it to work
[19:51] <alecu> perhaps I should ask ogra_ about that
[19:51] <jhodapp> alecu, ask morphis or koza...I'm not sure
[19:51] <alecu> sounds good, thanks
[19:51] <jhodapp> I only have a pi2 and dragonboard and can't remember off hand
[19:52] <alecu> right, pi2 does not have onboard bt
[19:52] <jhodapp> exactly
[19:52] <alecu> alright, thanks a bunch!
[19:53] <jhodapp> alecu, not a problem!
[20:07] <mup> PR snapd#3016 opened: interfaces: add kubernetes-support interface and adjust related interfaces (LP: #1664638) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3016>
[20:18] <alecu> jhodapp: and, here's another tiny fix: https://code.launchpad.net/~alecu/snappy-hwe-snaps/+git/bluez/+merge/319620
[20:20] <jhodapp> alecu, keep 'em coming :)
[20:20] <jhodapp> alecu, are you sure it needs that? konrad assured me we have the alias on the store side in place for that
[20:22] <alecu> jhodapp: well, after sshing into the raspi and installing the bluez snap, I can't find the bluetoothctl command
[20:22] <alecu> I do find bluez.bluetoothctl
[20:22] <alecu> perhaps I need a newer snap, or edge?
[20:22] <alecu> let me try that
[20:23] <jhodapp> alecu, you might and it may in fact be going out soon
[20:23] <jhodapp> alecu, try "snap aliases"
[20:24] <alecu> jhodapp: ah! the snap on edge is rev27. The one I had from stable is rev12 !!!
[20:24] <jhodapp> alecu, yup, that's the issue
[20:24] <alecu> jhodapp: I refreshed the snap, and now I can see the alias
[20:25] <jhodapp> awesome
[20:25] <alecu> wonderful :-)
[20:26] <alecu> and, now I've learned about aliases
[20:26] <jhodapp> quite an afternoon ;)
[20:26] <jhodapp> aliases are awesome
[20:27] <alecu> certainly useful for other snaps we are preparing...
[20:27] <jhodapp> absolutely
[20:29] <alecu> and, with the latest snap on the raspi, bluetoothctl still can't find the controller
[20:30] <alecu> so, I guess I'll bother ogra_ and morphis next week
[20:30] <alecu> jhodapp: thanks a bunch!
[20:30] <jhodapp> np
[20:41] <cachio> niemeyer, hey, quick question, I ma trying to create a file socket within a snap and > I get Bad system call (core dumped)
[20:41] <cachio> If I run the python code it works properly, but if failes when I call the snap app
[20:42] <cachio> niemeyer, any idea about what could be the reason? or where I could see the logs?
[20:51] <cachio> niemeyer, this is the only I see in the syslog http://paste.ubuntu.com/24153684/
[20:52] <kyrofa> cachio, that's a seccomp filter denial. You're probably missing the network plug
[20:52] <kyrofa> (or network-bind)
[20:52] <kyrofa> cachio, you could learn more by using snappy-debug
[20:52] <jdstrand> it would also tell you to use network-bind
[20:53] <kyrofa> cachio, and run `sudo snappy-debug.security scanlog` in one terminal while running your app in the other
[20:53] <jdstrand> $ scmp_sys_resolver 49
[20:53] <jdstrand> bind
[20:53] <kyrofa> jdstrand, did you actually run that, or do you have 49 memorized? ;)
[20:54] <jdstrand> you shouldn't have to use the network-bind interface to use a unix socket, but for now you do
[20:54] <jdstrand> kyrofa: I actually did have it memorized, but I double checked myself :)
[20:54] <cachio> kyrofa, jdstrand great, thanks for the info
[20:54] <kyrofa> jdstrand, haha, nice
[20:55] <cachio> kyrofa, jdstrand I am creating a file socket for process communication, should I use the networking plugin in that case too?
[20:56] <jdstrand> cachio: network-bind should be sufficient. use snappy-debug and it'll tell you for sure
[20:56] <cachio> jdstrand, ok, I'll do it, thanks
[20:58] <cachio> jdstrand, ERROR: Could not find '/snap/snappy-debug/27/policy/17'
[20:58] <mup> Bug #27: temporary test <iso-testing> <Baz (deprecated):Invalid> <https://launchpad.net/bugs/27>
[20:58] <cachio> snappy debug is giving me that
[20:58] <jdstrand> whoa
[20:59] <jdstrand> oh, what release are you on?
[20:59] <jdstrand> zesty?
[20:59] <cachio> zesty
[21:02] <cachio> jdstrand, snapd 2.22.7
[21:03] <jdstrand> cachio: can you do 'snap refresh snappy-debug --edge' and try again?
[21:04] <cachio> jdstrand, sure
[21:04] <cachio> jdstrand, it worked
[21:05] <cachio> jd tx
[21:05] <jdstrand> cachio: np
[21:50] <jdstrand> roadmr: hey, would you mind pulling r847 into the store? it isn't an emergency. next week is fine
[21:50] <roadmr> jdstrand: sure thing, I'll put it in the pipeline and check what the deployment status is
[21:51] <jdstrand> roadmr: oh, actualy, give me a second
[21:51] <roadmr> jdstrand: sure thing, I haven't proposed anything yet
[21:51] <jdstrand> I added the code to override but I didn't add the thing to override :)
[21:51] <roadmr> haha :) who overrides the overrider?
[21:54] <jdstrand> roadmr: ok, r848
[21:55] <jdstrand> heh
[21:56] <roadmr> jdstrand: did I hear something about snapd on trusty installing systemd which then makes $SOMETHING go crazy? this may be juju-related only :(
[21:57] <jdstrand> roadmr: snapd on trusty will install a special systemd, yes. I haven't heard about anything going crazy. if you are seeing something, please file a bug so the snappy team can take a look at it
[21:57] <roadmr> jdstrand: ok, I'll dig up the comment I saw.
[22:26] <mup> PR snapcraft#1185 opened: repo: add version support for build-packages <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1185>
[23:05] <jdstrand> niemeyer: ok, I was able to get to everything you pinged my on except the mknod branch. mvo could answer on that, but I'd like to be around when that lands, so I will comment when I am back
[23:06] <jdstrand> pinged me*
[23:06] <niemeyer> jdstrand: Thanks so much!
[23:06] <jdstrand> np
[23:06] <niemeyer> jdstrand: I'll try to find some time over the weekend to merge what I'm able to
[23:07] <jdstrand> cool
[23:30] <jdstrand> niemeyer: actually, there was one I handed off to Tyler-- PR#2624
[23:31] <jdstrand> (pid-1 mount namespace)
[23:31] <jdstrand> so he'll follow through on that in my absence


[08:41] <seb128> hey there
[08:41] <seb128> what team has right to approve translations template for Ubuntu? e.g https://translations.launchpad.net/ubuntu/focal/+imports
[08:42] <seb128> I used to be able to do that but seems I'm not anymore, I wonder if the acl changed or if I expired from a team
[15:39] <mdeslaur_> I'm getting amd64 build failures with no logs...like https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/18834286
[15:40] <mdeslaur_> is something borked?
[15:46] <SpecialK|Canon> mdeslaur_: Looking into it now
[15:46] <mdeslaur_> thanks SpecialK|Canon
[15:48] <seb128> cjwatson, wgrant, did you see my question from this morning? maybe you can help there?
[15:49] <cjwatson> seb128: SpecialK|Canon is the help contact at the moment and I'm trying to steer clear rather than sniping all questions from him
[15:49] <seb128> cjwatson, makes sense, thanks
[15:50] <cjwatson> (see topic)
[15:50] <seb128> SpecialK|Canon, ^ can you help?
[15:50] <seb128> cjwatson, I though it was maybe an Ubuntu process question more than a launchpad by itself, but let's see if SpecialK|Canon knows about that
[15:52] <SpecialK|Canon> seb128: Hello! I think that's an Ubuntu process question too, but I can see the argument that the LP UI should make it clear!
[15:52] <seb128> SpecialK|Canon, hey :) even without change/fixing, I'm interested to have the info because we need those templates reviewed
[15:53] <SpecialK|Canon> seb128: I suspect you'll be best served by asking over in #ubuntu-devel or similar if you haven't already
[15:53] <seb128> ideally I would like to join (back) the team with the acl
[15:53] <cjwatson> Well, working out what team has the authority to do a particular thing in LP is an LP question
[15:53] <cjwatson> In general
[15:53] <SpecialK|Canon> Fair point!
[15:53] <seb128> SpecialK|Canon, I doubt we have anyone around with knowledge of those bits in Ubuntu
[15:56] <cjwatson> So I can walk through how to find this
[15:56] <cjwatson> If desired
[15:56] <SpecialK|Canon> cjwatson: That would be appreciated, please
[15:58] <cjwatson> So I couldn't remember exactly where this lived, and ended up doing a bit of grepping for the various status names, which led me to TranslationImportQueueEntry.canSetStatus; looks promising
[15:59] <cjwatson> That calls TranslationImportQueueEntry.canAdmin for transitions to APPROVED
[15:59] <cjwatson> Which checks the launchpad.Admin permission on itself
[15:59] <cjwatson> So off to lib/lp/security.py; AdminTranslationImportQueueEntry defines launchpad.Admin on ITranslationImportQueueEntry by forwarding to launchpad.TranslationsAdmin on the distroseries
[16:00] <cjwatson> AdminDistroSeriesTranslations defines that as either you're the driver of the distribution (which is basically ~techboard) or you have launchpad.TranslationsAdmin on the distribution
[16:03] <SpecialK|Canon> cjwatson: Thanks
[16:03] <cjwatson> AdminDistributionTranslations defines *that* as either in the distribution's translation group owner (https://translations.launchpad.net/ubuntu → https://translations.launchpad.net/+groups/ubuntu-translators → https://launchpad.net/~ubuntu-translations-coordinators), or in ~rosetta-admins, or the owner of the distribution (which is basically ~techboard again)
[16:06] <cjwatson> seb128 was in ~ubuntu-drivers up to 2011.  I'm not sure I see what else might previously have given him that permission
[16:06] <cjwatson> Might be missing something
[16:07] <seb128> cjwatson, I'm pretty sure I've been able to approve things from the queue more recently than than, I've been the one approving those import almost every cycle in recent years
[16:07] <seb128> if I had to guess I think it was still available to me in bionic
[16:07] <cjwatson> You weren't in ~ubuntu-translations-coordinators by any chance?
[16:07] <seb128> shouldn't I be listed on https://launchpad.net/~ubuntu-translations-coordinators/+members#active as expired or something if that was the case?
[16:08] <cjwatson> Yeah, would've thought
[16:08] <cjwatson> I'm pretty certain this isn't something we've changed since we hardly ever touch Translations
[16:08] <seb128> maybe it was through some other team that got removed/expired and transien membership?
[16:09] <seb128> I was part of uds-organiser and other teams that had acl for some launchpad part iirc (just guessing on uds-organiser being an example, might be a buggy one)
[16:09] <seb128> anyway
[16:09] <cjwatson> It's possible, though I can't see a likely path
[16:10] <seb128> SpecialK|Canon, cjwatson, can one of you add me to https://launchpad.net/~ubuntu-translations-coordinators/ ?
[16:10] <cjwatson> I think it would be worth getting IS to help reclaim ~ubuntu-translations-coordinators - neither of Arne nor David have been around for years, have they?
[16:10] <seb128> neither Arne nor David are around anymore
[16:10] <cjwatson> We can't do that
[16:10] <seb128> k, thanks for helping
[16:10] <cjwatson> Team changes without admin consent require IS.  If it were me, I'd suggest promoting Gunnar to an admin and adding you as another admin
[16:10] <cjwatson> Feel free to quote me on that to IS
[16:11] <seb128> right
[16:11] <seb128> maybe adding Lukasz as well
[16:11] <seb128> will do, thanks!
[16:13] <mdeslaur_> SpecialK|Canon: here's another amd64 failed build with no logs: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/18834348
[18:16] <SpecialK|Canon> mdeslaur_: Builds should be going through much more happily right now and I believe Colin kicked off retries for (many of?) the ones that failed
[18:18] <mdeslaur_> thanks SpecialK|Canon


[00:25] <jjfrv8> apologies to slickymaster for my not being around earlier to comment on his glossary suggestion
[00:25] <jjfrv8> I think the glossary idea is a bit more than I was originally considering
[00:25] <jjfrv8> my main concern was pretty much limited to the potential for Settings Manager confusion caused by there being two ways to get to it and three names for it
[00:25] <jjfrv8> would it be out of the question to just remove the icon from the bottom of the whisker menu?
[00:25] <jjfrv8> I think that would just about take care of both problems
[01:03] <jjfrv8> bbl, but not for the meeting, unfortunately
[01:38] <sml> algun lugar de ayuda en español?
[01:39] <Unit193> New xfpm upload fixes Debian #763713 with upstream commit.
[01:39] <Unit193> sml: Generally English.
[01:40] <sml> thanks
[03:33] <Logan_> Unit193: aw, I could've helped him
[04:50]  * Unit193 has been rather out today.
[05:46] <Noskcaj> Unit193, bluesabre: I've merged thunar in a bzr if you guys haven't already. I was using it as an example to teach a person trying to join ubuntu as a developer, so if we could wait a few days to see if he can merge it, that would be great
[09:52] <bluesabre> Noskcaj: np, let me know when its ready to upload/sponsor
[10:13] <ochosi> !team | Reminder: meeting in ~45 mins
[10:14] <ochosi> morning bluesabre
[10:14] <bluesabre> morning ochosi
[10:14] <ochosi> still busy php-ing? :)
[10:14] <bluesabre> drafting a study guide now
[10:15] <ochosi> for yourself or for others?
[10:15] <bluesabre> me
[10:15] <bluesabre> :)
[10:15] <ochosi> :)
[10:16] <brainwash> can we disable the pink highlight in vivid now?
[10:17] <bluesabre> will do this weekend
[10:17] <bluesabre> the code is already in xubuntu-default-settings trunk, so if you have the xubuntu-staging ppa installed in vivid, it should be gone
[10:17] <brainwash> ok, that's nice
[10:18] <brainwash> any thoughts on http://git.xfce.org/xfce/xfdesktop/commit/?id=7e8e8669606e662d1ee1e85815000f068f48acd9 ?
[10:19] <ochosi> haven't tried it yet, but it sounds like something that i'll activate in greybird once we have it
[10:19] <slickymasterWork> I can confirm that brainwash
[10:20] <brainwash> great, hopefully it's not a cpu hog
[10:20] <slickymasterWork> and morning everyone
[10:20] <brainwash> slickymasterWork: hi
[10:20] <brainwash> confirm what?
[10:20] <slickymasterWork> what bluesabre stated
[10:20] <brainwash> ok :D
[10:21] <ochosi> slickymasterWork: well, it'll only hog the cpu once when loading xfdesktop
[10:21] <ochosi> but yeah, it's something to monitor
[10:22] <slickymasterWork> yeaps
[10:22] <slickymasterWork> but as it's a testing box it's not a big deal ochosi
[10:23] <slickymasterWork> it's meant for destruction, one way or the pther :P
[10:23] <slickymasterWork> s/pther/other
[10:39]  * slickymasterWork is not sure if he'll be able to really follow the meeting properly because of the constant annoying TTLs
[10:41] <slickymasterWork> jjfrv8, not sure if I understood you correctly. Do you mean remove the Settings icon from whisker itself?
[10:41] <slickymasterWork> knome ^^ (http://irclogs.ubuntu.com/2014/10/31/%23xubuntu-devel.html#t00:25)
[10:48] <dkessel> elfy: I hope you don't mind - I extended the QA pad with an item for discussion of priorities for autopilot tests. If the topic comes up in today's meeting, that would be nice.
[10:58] <knome> dkessel, just bring it up after any other items under "discussion", or you can just simply add it to the agenda at it will be brought up
[10:59] <ochosi> !team | meeting time everyone!
[10:59] <bluesabre> o/ here~ish
[10:59] <ochosi> yeah, that would've been my next question
[10:59] <knome> i'm -ish too, but will be at least loosely following :)
[10:59] <ochosi> who's around?
[10:59] <ochosi> right
[11:00] <knome> and can comment, but not always swiftly ;)
[11:00] <slickymasterWork> trying to keep myself here
[11:00] <ochosi> just in case nobody apart from me is *really* around, i guess i'd postpone the meeting to wednesday or something
[11:00] <knome> huhu :P
[11:00] <ochosi> otherwise i'd just be talking to myself with a few folks lurking and occasionally commenting and that'd be weird :)
[11:01] <bluesabre> that's how meetings are every now and then :)
[11:01] <ochosi> alright then, so let's do this and we'll see how far we get
[11:01] <ochosi> #startmeeting
[11:01] <meetingology> Meeting started Fri Oct 31 11:01:51 2014 UTC.  The chair is ochosi. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[11:01] <meetingology> Available commands: action commands idea info link nick
[11:02] <knome> well, we can also do a "loose agenda" meeting
[11:02] <knome> where people can bring up stuff they want to discuss
[11:02] <ochosi> #topic Open action items
[11:02] <ochosi> hm sure
[11:02] <knome> and then we'll #endmeeting at noon
[11:02] <knome> i guess there aren't too many team updates
[11:02] <ochosi> knome: how about your action items?
[11:02] <knome> let me see what there was
[11:03] <slickymasterWork> at OK Corral knome? ;)
[11:03] <knome> no formal proposal yet
[11:03] <knome> #action knome to write a more formalized proposal about the QA process improvements with elfy after N days of comments/feedback for the pad
[11:03] <meetingology> ACTION: knome to write a more formalized proposal about the QA process improvements with elfy after N days of comments/feedback for the pad
[11:03] <ochosi> does anybody know about whether pleia2 contacted unixstickers?
[11:03] <ochosi> otherwise i'd carry that forward too
[11:04] <knome> the "translations important for xubuntu" list is now at the wiki https://wiki.ubuntu.com/Xubuntu/Processes#Package_translations
[11:04] <knome> she did
[11:04] <knome> let me see if i can dig that up
[11:04] <knome> it was #done in the previous meeting already
[11:05] <ochosi> #done elfy mail the -devel list to garner comment on pad https://lists.ubuntu.com/archives/xubuntu-devel/2014-October/010448.html
[11:05] <knome> for the record:
[11:05] <knome> 23:07  pleia2: #DONE pleia2 to contact unixstickers
[11:05] <knome> 23:24  pleia2: #info unixstickers has sold plenty of Xubuntu items, so we just  need to let them know what we want for the reward based QA program
[11:05] <knome> 23:24  pleia2: #info unixstickers will also be producing t-shirts soon,  production info here:
[11:05] <knome> http://www.unixstickers.com/tshirts/underground-t-shirts/the-ultimate-pirate-bay-tshirt
[11:05] <ochosi> ah good
[11:06] <slickymasterWork> #action slickymaster to start a series of run calls for "translations important for xubuntu" list defined in https://wiki.ubuntu.com/Xubuntu/Processes#Package_translations
[11:06] <meetingology> ACTION: slickymaster to start a series of run calls for "translations important for xubuntu" list defined in https://wiki.ubuntu.com/Xubuntu/Processes#Package_translations
[11:06] <ochosi> nice
[11:07] <ochosi> anything else you think we should carry forward?
[11:07] <ochosi> to me it seems like the rest is probably #done one way or the other
[11:09] <knome> yep
[11:09] <ochosi> #topic Team updates
[11:09] <knome> oh
[11:09] <ochosi> ok, if you got anything, #info it now
[11:09] <knome> #action Elfy to mail -devel re where we support testers
[11:09] <meetingology> ACTION: Elfy to mail -devel re where we support testers
[11:09] <ochosi> i'd rather move on to discussion after this and leave things open
[11:09] <knome> ^ that
[11:09] <ochosi> oh
[11:09] <ochosi> #undo
[11:09] <meetingology> Removing item from minutes: ACTION
[11:09] <ochosi> #undo
[11:09] <meetingology> Removing item from minutes: TOPIC
[11:10] <knome> hah
[11:10] <ochosi> #action Elfy to mail -devel re where we support testers
[11:10] <meetingology> ACTION: Elfy to mail -devel re where we support testers
[11:10] <ochosi> #topic Team updates
[11:10] <ochosi> fixed
[11:10] <bluesabre> #info Vivid branches for each xubuntu package/project are now open
[11:10] <ochosi> nice work bluesabre
[11:10] <knome> #info Vivid series are up on the QA trackers (which are down ATM)
[11:11] <bluesabre> #info Daily builds of xubuntu-artwork, xubuntu-default-settings, and (soon) xubuntu-docs for Vivid are up at https://launchpad.net/~xubuntu-dev/+archive/ubuntu/xubuntu-staging
[11:12] <bluesabre> #info All other daily packages across our PPAs have been updated to build for vivid as well
[11:12] <ochosi> #info Greybird already has basic Gtk3.14 fixes, ping ochosi when you notice bugs
[11:13] <ochosi> #info All other themes will still need fixes for Gtk3.14
[11:13] <bluesabre> #info upower 0.99.x landed yesterday, our packages have been rebuilt to support it... watch for breakage!
[11:13] <qwebirc11992> grrr
[11:14] <bluesabre> landed, or is landing... couldn't keep up with lp notifications :)
[11:14] <bluesabre> I think that's all I have currently
[11:14] <ochosi> yeah, pitti spammed all our inboxes :)
[11:14] <ochosi> qwebirc11992: any team updates from your side?
[11:16] <slickymasterWork> the re-write of the section about upgrading is done and already merged to the main branch
[11:17] <ochosi> could you #info that properly plz?
[11:17] <slickymasterWork> thanks for the excellent work elfy done
[11:17] <slickymasterWork> #info the re-write of the section about upgrading is done and already merged to the main branch
[11:18] <ochosi> thanks
[11:18] <ochosi> ok, let's just open the floor for everyone...
[11:19] <ochosi> #topic Discussion
[11:19] <ochosi> would be nice to get some feedback on the blueprint sprint
[11:19] <ochosi> i mean: on the result of the blueprint sprint, which is the workitems
[11:19] <bluesabre> Nice. work. everyone.
[11:19] <knome> it's a good start ;)
[11:19] <ochosi> if you feel that we've covered our basis well, or something is still missing/overlooked
[11:19] <knome> i mean, i'm happy to see that there are many work items registered
[11:19] <ochosi> or something that needs review
[11:20] <knome> that gives us a more realistic view on how much work there is to be done
[11:20] <ochosi> indeed
[11:20] <knome> even if we most likely will need to change some wording and add even more smaller blueprints
[11:20] <bluesabre> the dev blueprint is in good shape, and I'm glad to see others contributing to it
[11:20] <dkessel> I would like to have some feedback on this QA item: http://pad.ubuntu.com/xubuntu-qa-v-autopilot
[11:21] <dkessel> there is this old utopic specification with a large list of applications on the wiki - I think it would be better to have priorities
[11:22] <dkessel> like, which applications should get tests first. As I don't believe we will get autopilot tests for 30 apps done this cycle ;)
[11:24] <ochosi> hm, that is a difficult one
[11:24] <knome> i guess it's obvious, but i'd start with those which work with autopilot ;)
[11:24] <bluesabre> I think it would be a good effort for sure... haven't looked into it myself, but I'd be curious to know to what extent we are testing with autopilot
[11:24] <ochosi> i remember knome was considering to write a proposal to drop abiword and gnumeric
[11:24] <knome> yeah... i wouldn't start with those anyway
[11:25] <knome> (even if we kept them)
[11:25] <knome> catfish  parole  settings manager  run program  app finder  mousepad  screenshot  xfburn  ristretto  task manager
[11:25] <bluesabre> start with simpler apps and build a core test suite
[11:26] <knome> those are something i think might be good places to start
[11:26] <knome> and yeah, in the order bluesabre mentioned, easier first
[11:26]  * ochosi agrees
[11:26] <knome> run program should be relatively easy
[11:26] <bluesabre> agreed... xfburn might be more difficult to create a meaningful test
[11:27] <dkessel> in that order? (see pad)
[11:27] <knome> i looked through https://wiki.ubuntu.com/Xubuntu/Roadmap/Specifications/Utopic/Autopilot and thought which of the "works" items would be somewhat "essential" or "important" to xubuntu
[11:28] <knome> maybe that
[11:28] <knome> grouped things being "equally important"
[11:28] <knome> or, "pick whichever you please"
[11:29] <dkessel> sounds good for a start!
[11:29] <dkessel> thanks!
[11:29] <knome> but that's just my opinion :)
[11:29] <dkessel> what do the others think?
[11:29] <bluesabre> I agreed already ;)
[11:29]  * ochosi too
[11:29] <knome> did you look at the pad?
[11:30] <knome> i did some subordering on the items i mentioned before
[11:30] <ochosi> hm, actually, app-finder == run program
[11:30]  * slickymasterWork lost the arguments but as a matter of principle, agrees with his fellow team members
[11:30] <ochosi> and functionally == whiskermenu
[11:31] <ochosi> so i'm somewhat wondering whether we really need to test it that much, as it isn't as important anymore as it used to be
[11:31] <knome> i'd bet people migrating from other systems *cough* windows *cough* still use it a lot
[11:32] <ochosi> hm, not sure, i mean whiskermenu does pretty much all that appfinder does too
[11:32] <knome> well run a poll for users
[11:32] <ochosi> my guess would be that catfish is actually more important
[11:32] <ochosi> but either way, we don't have to do a poll to prove or disprove anything
[11:36] <dkessel> I guess that's all I need for now
[11:41] <ochosi> dkessel: great!
[11:41] <ochosi> looking forward to the tests
[11:43] <bluesabre> so, we're considering swapping evince to evince-gtk... there doesn't seem to be a functional difference, and it reduces gnome dependencies
[11:43] <knome> any downsides?
[11:43] <ochosi> yeah, i tried -gtk and it looked/behaved the same
[11:43] <bluesabre> none discovered so far... I'm thinking it might be a good idea to go ahead and switch now since we're so early in the cycle
[11:44] <ochosi> +1
[11:44] <knome> then a +1 and "go ahead" from me
[11:44] <bluesabre> and we can reevaluate at a later point as needed
[11:44] <bluesabre> got it
[11:44] <slickymasterWork> +1 from also
[11:44] <bluesabre> will do tonight/tomorrow
[11:44] <ochosi> yeah, better switching now and having more time
[11:44] <ochosi> fwiw, i don't have the feeling that people really noticed that XChat is gone
[11:45] <ochosi> the only shitstorm i saw was about the pink highlights
[11:45] <slickymasterWork> yeah, there's no public nagging about it
[11:45] <ochosi> (and even that was not very excessive)
[11:45] <slickymasterWork> about XChat that is
[11:45] <ochosi> yeah
[11:45] <ochosi> did any others of you hear anything?
[11:45] <ochosi> or: read
[11:45] <bluesabre> nope
[11:45] <knome> the next time we plan to drop something, just change the highlight color at the same time and nobody notices
[11:45] <slickymasterWork> nopes
[11:46] <bluesabre> :D
[11:47] <ochosi> :D
[11:54] <ochosi> alrighty
[11:55] <ochosi> since time is pretty much up and there aren't many new topics brought up i'd say we end today's meeting
[11:55] <ochosi> thanks to everyone for participating!
[11:55] <knome> yep
[11:55] <bluesabre> alrighty
[11:55] <bluesabre> ttyl
[11:55] <ochosi> #topic Schedule next meeting
[11:56] <ochosi> #info bluesabre to schedule the next meeting
[11:56] <ochosi> #endmeeting
[11:56] <meetingology> Meeting ended Fri Oct 31 11:56:08 2014 UTC.
[11:56] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/xubuntu-devel/2014/xubuntu-devel.2014-10-31-11.01.moin.txt
[11:56] <slickymasterWork> thanks ochosi
[11:56] <ochosi> minutes will be up in a bit
[12:09] <brainwash> ochosi: is it worth to include the qt theme selection file in xubuntu-default-settings?
[12:09] <brainwash> to fix bug 1382741
[12:10] <ochosi> iirc bluesabre already had a patch for that
[12:10] <ochosi> http://bazaar.launchpad.net/~xubuntu-dev/xubuntu-default-settings/trunk/revision/533
[12:11] <brainwash> ah nice
[12:11] <brainwash> branch should be added the report then :)
[12:11] <ochosi> sure, feel free to do that ;)
[12:11] <ochosi> meeting minutes are up
[12:15] <brainwash> bluesabre: the lp number is wrong http://bazaar.launchpad.net/~xubuntu-dev/xubuntu-default-settings/trunk/revision/533
[12:16] <brainwash> 1373887 is commit 530
[12:19] <brainwash> bluesabre: you could also add the extra keybinding for screen locking, bug 1033174
[12:20] <brainwash> "Add <Ctrl><Alt>l shortcut for screen locking (xflock4)"
[12:20] <brainwash> from upstream
[12:21] <brainwash> the launchpad report also requests "CTRL+ALT+DEL for firing the shutdown menu"
[12:21] <brainwash> not sure if we could add this too (xubuntu only)
[12:23]  * slickymasterWork needs a good serach engine to find something in the logs
[12:23] <slickymasterWork> *search
[12:24] <brainwash> bluesabre: I guess not, CTRL+ALT+DEL is triggering xflock4 atm
[12:24] <brainwash> people are used to this binding
[13:03] <bluesabre> slickymasterWork: https://www.google.com/#q=site:irclogs.ubuntu.com
[13:04] <bluesabre> brainwash: thanks, will take a look tonight
 #action Elfy to mail -devel re where we support testers
[13:18] <elfy> ummm
[13:18] <elfy> so perhaps if people in team could actually read things I send to the list - that would be awesome :D
[13:20] <pleia2> elfy: I read it!
[13:20] <pleia2> but that meeting confused me, I think we had a duplicate agenda from last meeting :)
[13:21] <elfy> :)
[13:25] <elfy> xchat suddenly appears to have decided to be old school in appearance
[13:48] <jjfrv8> slickymasterwork, yes, my suggestion was to remove the default All Settings icon from whisker: http://en.zimagez.com/zimage/menu0020.php
[13:48] <jjfrv8> with just the one way to get to Settings from the menu, all of our references to [icon]-> Settings would be unambiguous
[13:48] <jjfrv8> now that we have the searchable Settings in the category pane of whisker, I don't see any need to have the extra icon
[13:51] <knome> ochosi, bluesabre: opinions ^ ?
[13:59] <jjfrv8> gotta go, back later
[14:04] <slickymasterWork> lol, bluesabre, that I already have
[14:05] <slickymasterWork> I was just nagging with myself ;)
[14:07] <slickymasterWork> jjfrv8, right, but that goes way beyond the -docs scope so the project and the technical leads in particular and the team at large will have to have a say on it
[15:17] <slickymasterWork> hmmmm
[15:17] <slickymasterWork> knome, https://translations.launchpad.net/ubuntu/vivid/+source/ubiquity-slideshow-ubuntu/+pots/ubiquity-slideshow-xubuntu is set yet
[15:17] <slickymasterWork> *isn't
[15:17] <knome> what a shame
[15:17] <knome> ;)
[15:18] <slickymasterWork> just saying it because of the call for translation mail to -devel
[15:18] <knome> i'll set it up in a minute once i have coffee in my mug
[15:18] <slickymasterWork> I'm going to mention it and people will start complaining about an invalid link, for sure
[15:19] <slickymasterWork> ok, I'll fix the link in https://wiki.ubuntu.com/Xubuntu/Processes
[15:21] <slickymasterWork> knome ^^^ fixed
[15:21] <knome> actually..
[15:21] <ochosi> knome, jjfrv8: i don't have a strong opinion on that. i don't think ppl will really miss it there since we have the category. otoh i don't think the "ambiguity" of the docs is a really a big issue in that respect
[15:21] <knome> i think it'll show up when there's the first upload for that package
[15:22] <slickymasterWork> but the url is going to be that one, right?
[15:22] <knome> yes
[15:22] <slickymasterWork> it's not a big issue ochosi, but an issue nevertheless
[15:23] <knome> since we've had the icon already, i think it's better to keep it
[15:23] <knome> and solve the ambiguity docs-internally
[15:23]  * slickymasterWork nods
[15:23] <ochosi> slickymasterWork: btw, shall we take another look at the powerman docs sometime next week?
[15:24]  * ochosi doesnt really remember where we left off
[15:24] <knome> coffee is yummy
[15:24] <slickymasterWork> yes ochosi, I've been postponing that because of work/son
[15:24] <slickymasterWork> but things are calmer these days
[15:25]  * slickymasterWork was wondering when would ochosi poke him about that ;)
[15:25] <ochosi> :)
[15:26] <ochosi> yeah, same here tbh
[15:26] <ochosi> i was also busy and it's not on the top of my priority-list
[15:26] <slickymasterWork> lol, knome, I received that one (in the PM) during today's meeting
[15:27] <knome> yes :|
[15:27] <knome> talk about wasting bandwidth
[15:28] <slickymasterWork> :)
[16:21] <slickymasterWork> knome: about http://pad.ubuntu.com/outdated-debian-screenshots do you know if it's required some form of an account in debian to upload the screenshots?
[16:22] <knome> you should ask bluesabre
[16:23] <slickymasterWork> I'm planning to start working on it this weekend
[16:23] <slickymasterWork> bluesabre ^^
[16:24] <slickymasterWork> or Unit193 (for that matter) ^^
[16:28] <knome> anyway, don't let them not answering keep you back... if you take new screenshots, keep them somewhere until they know where to put them :)
[16:28] <slickymasterWork> yeah, that goes without saying
[16:48] <slickymasterWork> knome, thanks for adding  that item to the blueprint
[16:48] <knome> np
[17:37] <elfy> evening all
[17:39] <knome> hello elfy
[17:39] <elfy> hi knome
[17:39] <elfy> so then knome ...
[17:39] <knome> yes? :)
[17:39] <elfy> what shall we call N days then :)
[17:39] <elfy> has to be more than 14 or we've done that :S
[17:39] <elfy> D
[17:40] <knome> yeah, it's a random integer from 1 to 30 that changes every day
[17:40] <knome> and the only way to get out of this loop is that the random integer matches the day number we're on.. eg. so the deadline is "today"
[17:40] <elfy> if we postpone that till after the 6th I've got a week off and can just blast it out
[17:40] <knome> hasn't happened yet, so we're still stuck
[17:41] <knome> this weekend and forthcoming week generally look better (less busy) than the weeks before, so fingers crossed :)
[17:42] <elfy> yea - I like that deadline should just always equal either yesterday or tomorrow
[17:42] <elfy> I've got little time this weekend - and next week it's only be evenings - if I manage to find any of that elusive commodity
[17:43] <knome> yep
[17:43] <knome> let's try to coordinate some time
[17:43] <knome> tomorrow day is bad for me, but eveningish is good
[17:43] <elfy> no chance this weekend
[17:44] <knome> oh
[17:44] <knome> duh
[17:44]  * knome misread
[17:44] <knome> :D
[17:44] <elfy> :)
[17:44] <elfy> there's no rush - I'm happy to leave it till the 2nd week of November
[17:44] <knome> mhm
[17:46] <elfy> I'm more concerned about other things atm - incentive/scheduling testing/starting testing than the process page
[17:46] <knome> yep
[17:46] <knome> i'm generally interested on the process page because that's a good way to pass on information
[17:47] <elfy> I agree - I'm not *did-interested* - just less interested ;)
[17:47] <elfy> s/did/dis
[17:47] <knome> it's okay :P
[17:47] <knome> and yeah, got that
[17:47] <knome> just get used to me nagging about that page ;)
[17:48] <elfy> that's fine - I'll treat it the same way as people do when I ask for them to test images ;)
[17:48] <knome> haha
[17:48] <knome> fair deal
[17:48] <elfy> :)
[18:01] <elfy> knome: to be fair, I've done a bit more on that pad in the last N days - the draft proposal is certainly different than it was
[18:04] <knome> haven't looked at it, but judging from what you've said in this channel, i guessed it would be :)
[18:04] <elfy> :)
[18:15] <elfy> hi brainwash
[18:17] <brainwash> hey elfy