[00:24] -queuebot:#ubuntu-release- Unapproved: s390-tools (focal-proposed/main) [2.11.0-0ubuntu2 => 2.11.0-0ubuntu2] (core)
[02:38] <blackboxsw> RAOF: awesome thanks again on ua-tools pkg to trusty!
[05:17] -queuebot:#ubuntu-release- New binary: liblv-perl [amd64] (focal-proposed/universe) [0.006-3] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: librtsp-server-perl [amd64] (focal-proposed/universe) [0.06-2] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: rust-der-parser [amd64] (focal-proposed/universe) [3.0.3-1] (i386-excludes)
[05:20] -queuebot:#ubuntu-release- New binary: rust-der-parser [ppc64el] (focal-proposed/universe) [3.0.3-1] (i386-excludes)
[05:24] -queuebot:#ubuntu-release- New binary: rust-der-parser [s390x] (focal-proposed/universe) [3.0.3-1] (i386-excludes)
[05:25] -queuebot:#ubuntu-release- New binary: openimageio [s390x] (focal-proposed/universe) [<IP_ADDRESS>~dfsg0-5] (ubuntustudio)
[05:25] -queuebot:#ubuntu-release- New binary: rust-der-parser [arm64] (focal-proposed/universe) [3.0.3-1] (i386-excludes)
[05:26] -queuebot:#ubuntu-release- New binary: rust-der-parser [armhf] (focal-proposed/universe) [3.0.3-1] (i386-excludes)
[05:28] -queuebot:#ubuntu-release- New binary: openimageio [amd64] (focal-proposed/universe) [<IP_ADDRESS>~dfsg0-5] (ubuntustudio)
[05:29] -queuebot:#ubuntu-release- New binary: openimageio [ppc64el] (focal-proposed/universe) [<IP_ADDRESS>~dfsg0-5] (ubuntustudio)
[05:53] -queuebot:#ubuntu-release- New binary: openimageio [arm64] (focal-proposed/universe) [<IP_ADDRESS>~dfsg0-5] (ubuntustudio)
[05:54] -queuebot:#ubuntu-release- New binary: openimageio [armhf] (focal-proposed/universe) [<IP_ADDRESS>~dfsg0-5] (ubuntustudio)
[07:12] <cpaelzer> uh, somebody cleaned up component-mismatches a lot, thanks to whoever that was!
[07:15] <cpaelzer> Laney: fonts-smc-gayathri for whatever reason does not get detected and link from component-mismatches page, tbh I don't know what is missing but I wanted to let you know
[08:34] -queuebot:#ubuntu-release- Unapproved: vaultlocker (bionic-backports/universe) [1.0.3-0ubuntu<IP_ADDRESS>~ubuntu18.04.1 => 1.0.4-0ubuntu<IP_ADDRESS>~ubuntu18.04.1] (no packageset)
[09:23] -queuebot:#ubuntu-release- New: accepted icu-ext [amd64] (focal-proposed) [1.5.1-1]
[09:23] -queuebot:#ubuntu-release- New: accepted icu-ext [armhf] (focal-proposed) [1.5.1-1]
[09:23] -queuebot:#ubuntu-release- New: accepted icu-ext [s390x] (focal-proposed) [1.5.1-1]
[09:24] -queuebot:#ubuntu-release- New: accepted icu-ext [arm64] (focal-proposed) [1.5.1-1]
[09:24] -queuebot:#ubuntu-release- New: accepted icu-ext [ppc64el] (focal-proposed) [1.5.1-1]
[09:24] -queuebot:#ubuntu-release- New: accepted lcm [amd64] (focal-proposed) [1.3.1+repack1-2.3]
[09:24] -queuebot:#ubuntu-release- New: accepted lcm [armhf] (focal-proposed) [1.3.1+repack1-2.3]
[09:24] -queuebot:#ubuntu-release- New: accepted lcm [s390x] (focal-proposed) [1.3.1+repack1-2.3]
[09:24] -queuebot:#ubuntu-release- New: accepted liblv-perl [amd64] (focal-proposed) [0.006-3]
[09:24] -queuebot:#ubuntu-release- New: accepted librtsp-server-perl [amd64] (focal-proposed) [0.06-2]
[09:24] -queuebot:#ubuntu-release- New: accepted openimageio [arm64] (focal-proposed) [<IP_ADDRESS>~dfsg0-5]
[09:24] -queuebot:#ubuntu-release- New: accepted openimageio [ppc64el] (focal-proposed) [<IP_ADDRESS>~dfsg0-5]
[09:24] -queuebot:#ubuntu-release- New: accepted python-caja [amd64] (focal-proposed) [1.23.0-1]
[09:24] -queuebot:#ubuntu-release- New: accepted python-caja [armhf] (focal-proposed) [1.23.0-1]
[09:24] -queuebot:#ubuntu-release- New: accepted python-caja [s390x] (focal-proposed) [1.23.0-1]
[09:24] -queuebot:#ubuntu-release- New: accepted lcm [arm64] (focal-proposed) [1.3.1+repack1-2.3]
[09:24] -queuebot:#ubuntu-release- New: accepted liblv-perl [amd64] (focal-proposed) [0.006-2]
[09:24] -queuebot:#ubuntu-release- New: accepted openimageio [amd64] (focal-proposed) [<IP_ADDRESS>~dfsg0-5]
[09:24] -queuebot:#ubuntu-release- New: accepted openimageio [s390x] (focal-proposed) [<IP_ADDRESS>~dfsg0-5]
[09:24] -queuebot:#ubuntu-release- New: accepted python-caja [ppc64el] (focal-proposed) [1.23.0-1]
[09:24] -queuebot:#ubuntu-release- New: accepted r-cran-multicool [amd64] (focal-proposed) [0.1-11-2]
[09:24] -queuebot:#ubuntu-release- New: accepted r-cran-multicool [armhf] (focal-proposed) [0.1-11-2]
[09:24] -queuebot:#ubuntu-release- New: accepted r-cran-multicool [s390x] (focal-proposed) [0.1-11-2]
[09:24] -queuebot:#ubuntu-release- New: accepted lcm [ppc64el] (focal-proposed) [1.3.1+repack1-2.3]
[09:24] -queuebot:#ubuntu-release- New: accepted openimageio [armhf] (focal-proposed) [<IP_ADDRESS>~dfsg0-5]
[09:24] -queuebot:#ubuntu-release- New: accepted r-cran-egg [amd64] (focal-proposed) [0.4.5-2]
[09:24] -queuebot:#ubuntu-release- New: accepted r-cran-multicool [ppc64el] (focal-proposed) [0.1-11-2]
[09:24] -queuebot:#ubuntu-release- New: accepted librtsp-server-perl [amd64] (focal-proposed) [0.06-1]
[09:24] -queuebot:#ubuntu-release- New: accepted r-cran-multicool [arm64] (focal-proposed) [0.1-11-2]
[09:24] -queuebot:#ubuntu-release- New: accepted python-caja [arm64] (focal-proposed) [1.23.0-1]
[09:24] -queuebot:#ubuntu-release- New: accepted r-cran-psychtools [amd64] (focal-proposed) [1.9.12-2]
[09:24] -queuebot:#ubuntu-release- New: accepted r-cran-robustrankaggreg [amd64] (focal-proposed) [1.1-2]
[09:24] -queuebot:#ubuntu-release- New: accepted ruby-rails-controller-testing [amd64] (focal-proposed) [1.0.4-1]
[09:25] -queuebot:#ubuntu-release- New: accepted rust-der-parser [arm64] (focal-proposed) [3.0.3-1]
[09:25] -queuebot:#ubuntu-release- New: accepted rust-der-parser [ppc64el] (focal-proposed) [3.0.3-1]
[09:25] -queuebot:#ubuntu-release- New: accepted vagrant-bindfs [amd64] (focal-proposed) [1.1.5-1]
[09:25] -queuebot:#ubuntu-release- New: accepted vdens [arm64] (focal-proposed) [0.1-1]
[09:25] -queuebot:#ubuntu-release- New: accepted vdens [ppc64el] (focal-proposed) [0.1-1]
[09:25] -queuebot:#ubuntu-release- New: accepted r-cran-tfisher [amd64] (focal-proposed) [0.2.0-2]
[09:25] -queuebot:#ubuntu-release- New: accepted rust-der-parser [armhf] (focal-proposed) [3.0.3-1]
[09:25] -queuebot:#ubuntu-release- New: accepted vdens [amd64] (focal-proposed) [0.1-1]
[09:25] -queuebot:#ubuntu-release- New: accepted vdens [s390x] (focal-proposed) [0.1-1]
[09:25] -queuebot:#ubuntu-release- New: accepted rust-der-parser [amd64] (focal-proposed) [3.0.3-1]
[09:25] -queuebot:#ubuntu-release- New: accepted vdens [armhf] (focal-proposed) [0.1-1]
[09:25] -queuebot:#ubuntu-release- New: accepted rust-der-parser [s390x] (focal-proposed) [3.0.3-1]
[09:45] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (focal-proposed) [2.11.0-0ubuntu2]
[10:21] -queuebot:#ubuntu-release- New binary: libjson-path-perl [amd64] (focal-proposed/universe) [0.420-2] (no packageset)
[10:21] -queuebot:#ubuntu-release- New binary: linux-signed-5.4 [ppc64el] (focal-proposed/universe) [5.4.0-11.14] (no packageset)
[10:21] -queuebot:#ubuntu-release- New binary: linux-signed-5.4 [amd64] (focal-proposed/universe) [5.4.0-11.14] (no packageset)
[10:21] -queuebot:#ubuntu-release- New binary: linux-signed-5.4 [s390x] (focal-proposed/universe) [5.4.0-11.14] (no packageset)
[10:23] -queuebot:#ubuntu-release- New binary: linux-signed-5.4 [arm64] (focal-proposed/universe) [5.4.0-11.14] (no packageset)
[11:04] -queuebot:#ubuntu-release- New: accepted linux-signed-5.4 [amd64] (focal-proposed) [5.4.0-11.14]
[11:04] -queuebot:#ubuntu-release- New: accepted linux-signed-5.4 [ppc64el] (focal-proposed) [5.4.0-11.14]
[11:04] -queuebot:#ubuntu-release- New: accepted linux-signed-5.4 [arm64] (focal-proposed) [5.4.0-11.14]
[11:04] -queuebot:#ubuntu-release- New: accepted linux-signed-5.4 [s390x] (focal-proposed) [5.4.0-11.14]
[11:39] <seb128> hey release team
[11:41] <seb128> how open would you be to skip the http://autopkgtest.ubuntu.com/packages/o/openscad/focal/s390x result to let mesa be a valid candidate?
[11:42] <seb128> something in the dri driver update is making openscad unhappy but since it seems complex to debug (could well be a compiler issue or such) and we don't support the graphical stack on s390x anyway I would rather not spend too much resources on that
[11:43] <seb128> tjaalton, xnox, ^ opinion?
[11:43] <tjaalton> +++
[11:44] <xnox> charming, as if llvmpipe on s390x is busted
[11:45] <xnox> seb128:  does llvmpipe rendering work on amd64 otherwise?
[11:45] <seb128> tjaalton, ^
[11:45] <tjaalton> sure
[11:46] <tjaalton> I mean, it's fairly widely used
[11:46] <seb128> xnox, I expect so, the same autopkgtests work on other archs
[11:46] <tjaalton> a fallback etc
[11:46] <tjaalton> *as
[11:47] -queuebot:#ubuntu-release- Unapproved: xen (eoan-proposed/main) [4.9.2-0ubuntu2 => 4.9.2-0ubuntu5] (ubuntu-desktop, ubuntu-server, virt) (sync)
[11:47] <seb128> tjaalton, right, wouldn't hurt to test the proposed mesa update with software rendering just to make sure some toolchain problem didn't screw it
[11:59] <Laney> cpaelzer: sorry I missed your message, it's stuck in -proposed so shows up on https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
[12:20] -queuebot:#ubuntu-release- New sync: python-networkx (focal-release/primary) [2.2-1ubuntu4]
[16:27] <vorlon> xnox: knot-resolver> context?
[16:38] <vorlon> seb128: well there's a new openscad in -proposed, so I'm going to retest against mesa with that version first
[16:38] <vorlon> seb128: to be clear, "skip" would mean "accept this as an autopkgtest regression in the hints", not just a one-time skip
[16:38] <xnox> vorlon:  knot-resolver does not exist on i386 yet has i386 autopkgtests requested, blocking gnutls28 from migrating
[16:39] <xnox> vorlon:  please do what you do to those with hints
[16:39] <vorlon> xnox: ok
[16:42] <vorlon> xnox: done
[16:43] <vorlon> doko: have you been doing removals today?  the uninstallability count has blown up https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt
[16:43] <vorlon> doko: (cf my previous highlights about overlooked revdeps)
[16:48] <doko> vorlon: I removed python-networkx by mistake, and the re-added it. I'll look at the python packages
[16:48] <vorlon> doko: ok
[16:52] <doko> vorlon: hmm, python3-networkx is not restored.
[16:53] <vorlon> doko: what command did you run?
[16:54] <doko> copy-package -b -e 2.2-1ubuntu4 --from=ubuntu -s focal --to=ubuntu --to-suite focal --force-same-destination python-networkx
[16:55] <vorlon> looks sane
[16:55] <vorlon> I've just run the same command
[16:55] <vorlon> did you get an email failure?
[16:56] <doko> no
[16:57] <vorlon> doko: my copy now shows as pending on https://launchpad.net/ubuntu/+source/python-networkx/+publishinghistory so I don't know
[16:59] -queuebot:#ubuntu-release- New: accepted libjson-path-perl [amd64] (focal-proposed) [0.420-2]
[17:00] <doko> ta
[17:02] <doko> vorlon: cython is fixed
[17:03] <vorlon> woohoo
[17:04] <cjwatson> doko,vorlon: The earlier sync didn't work because it ended up in NEW and nobody processed it.
[17:04] <cjwatson> https://launchpad.net/ubuntu/focal/+queue?queue_state=0&queue_text=
[17:05] <vorlon> oh, it ended up in new for the release pocket which is why I kept failing to find it
[17:05] <vorlon> sorry
[17:05] <vorlon> yeah, I did an --auto-approve on my copy-package, I guess maybe I should've mentioned that
[17:05] <cjwatson> I thought you must have done
[17:06] <vorlon> :)
[17:06] -queuebot:#ubuntu-release- New: rejected python-networkx [sync] (focal-release) [2.2-1ubuntu4]
[17:21] -queuebot:#ubuntu-release- New binary: rust-core-foundation [amd64] (focal-proposed/universe) [0.6.4-3] (i386-excludes)
[17:23] -queuebot:#ubuntu-release- New binary: rust-core-foundation [ppc64el] (focal-proposed/universe) [0.6.4-3] (i386-excludes)
[17:24] <doko> cjwatson, vorlon: chatted with xnox about ubuntuone-dev-tools. is this package still needed, or can it be removed?
[17:25] <xnox> doko:  in a meeting right now
[17:35] -queuebot:#ubuntu-release- New binary: rust-core-foundation [s390x] (focal-proposed/universe) [0.6.4-3] (i386-excludes)
[17:36] <vorlon> doko: I have never heard of the package before, and the service it's named after no longer exists
[17:36] -queuebot:#ubuntu-release- New: accepted rust-core-foundation [amd64] (focal-proposed) [0.6.4-3]
[17:36] -queuebot:#ubuntu-release- New: accepted rust-core-foundation [s390x] (focal-proposed) [0.6.4-3]
[17:37] -queuebot:#ubuntu-release- New: accepted rust-core-foundation [ppc64el] (focal-proposed) [0.6.4-3]
[17:38] <cjwatson> doko: I haven't the foggiest.  Ask #snapstore on Canonical IRC if anyone still cares about it?
[17:38] <doko> ok
[18:19] <chrisccoulson> hi, could somebody please approve the adobe-flashplugin partner uploads?
[18:21] <xnox> chrisccoulson:  still not dead ? =)
[18:21] <xnox> chrisccoulson:  i hope all of flash has a year 2038  bug
[18:24] <bdmurray> How could I retest the gfs2-utils autopkgtests w/o the new util-linux? http://autopkgtest.ubuntu.com/packages/g/gfs2-utils/eoan/i386
[18:25] <chrisccoulson> xnox, December is when it dies
[18:26] <Laney> bdmurray: self trigger
[18:28] <bdmurray> Laney: Could you elaborate?
[18:28] <Laney> bdmurray: instead of a trigger on util-linux, use a trigger on the package itself
[18:28] <Laney> copy the URL and edit it to do that
[18:28] <bdmurray> got it, thanks
[18:29] <vorlon> also, retry-autopkgtest-regressions has a --no-proposed option which mostly works
[18:30] <xnox> vorlon:  can you please do what you do to ruby-openssl:i386 ?
[18:32] <vorlon> xnox: already done
[18:33] <xnox> vorlon:  tah
[18:33] <xnox> vorlon:  sorry britney runs are slow at the moment.
[18:35] <vorlon> xnox: well I committed it 7 minutes ago ;)
[18:36] <vorlon> so you wouldn't see it until the run after the current one
[18:41] -queuebot:#ubuntu-release- New binary: libjson-hyper-perl [amd64] (focal-proposed/universe) [0.011-2] (no packageset)
[18:49] -queuebot:#ubuntu-release- Unapproved: cloud-init (eoan-proposed/main) [19.3-41-gc4735dd3-0ubuntu1~19.10.1 => 19.4-33-gbb4131a2-0ubuntu1~19.10.1] (core, edubuntu, ubuntu-cloud)
[18:53] -queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [19.3-41-gc4735dd3-0ubuntu1~18.04.1 => 19.4-33-gbb4131a2-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[18:55] -queuebot:#ubuntu-release- New: accepted libjson-hyper-perl [amd64] (focal-proposed) [0.011-2]
[19:06] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [19.3-41-gc4735dd3-0ubuntu1~16.04.1 => 19.4-33-gbb4131a2-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[19:14] <csmith> rbasak, it's probably a bit late for today, up for a cloud-init SRU that is queued for testing 19.4-33-gbb4131a2-0ubuntu1~18.04.1 (Bionic, Xenial and Eoan) per SRU bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1859725
[19:17] <bdmurray> Okay so gfs2-utils on eoan/i386 failed its own test so util-linux is not the culprit correct? http://autopkgtest.ubuntu.com/packages/gfs2-utils/eoan/i386
[20:06] <vorlon> bdmurray: yep
[20:30] -queuebot:#ubuntu-release- New binary: bind9 [s390x] (focal-proposed/main) [1:9.11.14+dfsg-1ubuntu1] (core, i386-whitelist)
[20:31] -queuebot:#ubuntu-release- New binary: bind9 [amd64] (focal-proposed/main) [1:9.11.14+dfsg-1ubuntu1] (core, i386-whitelist)
[20:36] -queuebot:#ubuntu-release- New binary: bind9 [ppc64el] (focal-proposed/main) [1:9.11.14+dfsg-1ubuntu1] (core, i386-whitelist)
[20:39] -queuebot:#ubuntu-release- New binary: bind9 [i386] (focal-proposed/main) [1:9.11.14+dfsg-1ubuntu1] (core, i386-whitelist)
[21:05] -queuebot:#ubuntu-release- New binary: bind9 [arm64] (focal-proposed/main) [1:9.11.14+dfsg-1ubuntu1] (core, i386-whitelist)
[21:18] -queuebot:#ubuntu-release- New binary: bind9 [armhf] (focal-proposed/main) [1:9.11.14+dfsg-1ubuntu1] (core, i386-whitelist)
[21:39] <xnox> vorlon:  mysql-8.0 on i386 => is that legit, and i need to fix its autopkgtests? or like do we need just mysql libraries and not the server on i386?
[21:39] <xnox> just clientlibs?
[21:48] <ahasenack> hi archive admins, could someone please let bind9 through from the NEW queue? It's a soname change
[21:48] <ahasenack> I'll then be ready to upload the no-change rebuilds for the reverse-deps
[21:50] <vorlon> xnox: it needs investigation; the preference is that the autopkgtests pass
[21:51] <vorlon> ahasenack: done
[21:51] <ahasenack> vorlon: thanks a lot
[21:52] -queuebot:#ubuntu-release- New: accepted bind9 [amd64] (focal-proposed) [1:9.11.14+dfsg-1ubuntu1]
[21:52] -queuebot:#ubuntu-release- New: accepted bind9 [armhf] (focal-proposed) [1:9.11.14+dfsg-1ubuntu1]
[21:52] -queuebot:#ubuntu-release- New: accepted bind9 [ppc64el] (focal-proposed) [1:9.11.14+dfsg-1ubuntu1]
[21:52] -queuebot:#ubuntu-release- New: accepted bind9 [arm64] (focal-proposed) [1:9.11.14+dfsg-1ubuntu1]
[21:52] -queuebot:#ubuntu-release- New: accepted bind9 [s390x] (focal-proposed) [1:9.11.14+dfsg-1ubuntu1]
[21:52] -queuebot:#ubuntu-release- New: accepted bind9 [i386] (focal-proposed) [1:9.11.14+dfsg-1ubuntu1]
[23:18] -queuebot:#ubuntu-release- New binary: ppx-optcomp [amd64] (focal-proposed/none) [1:0.13.0-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: ppx-optcomp [arm64] (focal-proposed/universe) [1:0.13.0-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: ppx-optcomp [ppc64el] (focal-proposed/universe) [1:0.13.0-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: ppx-optcomp [armhf] (focal-proposed/universe) [1:0.13.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: ppx-optcomp [s390x] (focal-proposed/universe) [1:0.13.0-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-28.30] (core, kernel)
[23:26] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-75.85] (core, kernel)
[23:26] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-28.30] (core, kernel)
[23:26] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-75.85] (core, kernel)
[23:26] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-28.30] (core, kernel)
[23:26] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-75.85~16.04.1] (kernel)
[23:27] -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-28.30] (core, kernel)
[23:27] -queuebot:#ubuntu-release- New: accepted ppx-optcomp [armhf] (focal-proposed) [1:0.13.0-1]
[23:27] -queuebot:#ubuntu-release- New: accepted ppx-optcomp [s390x] (focal-proposed) [1:0.13.0-1]
[23:27] -queuebot:#ubuntu-release- New: accepted ppx-optcomp [ppc64el] (focal-proposed) [1:0.13.0-1]
[23:28] -queuebot:#ubuntu-release- New: accepted ppx-optcomp [amd64] (focal-proposed) [1:0.13.0-1]
[23:28] -queuebot:#ubuntu-release- New: accepted ppx-optcomp [arm64] (focal-proposed) [1:0.13.0-1]
[23:32] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-28.30]
[23:32] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-28.30]
[23:32] -queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-28.30]
[23:32] -queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-28.30]
[23:33] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-75.85]
[23:33] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-75.85]
[23:34] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-75.85~16.04.1]


[09:56] <tsdgeos> Mirv: ping
[10:03] <Mirv> tsdgeos: pong
[10:04] <tsdgeos> Mirv: was speaking with Saviq about the audiorole issues with Qt 5.5
[10:04] <tsdgeos> given that QML doesn't have ifdefs
[10:04] <tsdgeos> it would be cool if we could make our vivid Qt support the new roles
[10:04] <tsdgeos> and maybe even probably the W+1 Qt 5.5 support the old roles for a while
[10:04] <tsdgeos> to have a proper deprecation process
[10:05] <tsdgeos> otherwise it's very hard for us to have code that works both in w+1 and in vivid/overlay
[10:06] <Saviq> it's not even about QML not having ifdefs, but the fact that we'd break apps setting the old property name
[10:06] <Mirv> tsdgeos: oh right, you're thinking about the dual landing aspect? but I guess changing the audio roles in vivid could be seen as a risk.
[10:06] <tsdgeos> that to
[10:06] <tsdgeos> Mirv: i don't want to change them
[10:06] <tsdgeos> Mirv: i want to add the new ones
[10:06] <Saviq> we need to support both ones
[10:06] <tsdgeos> yep
[10:06] <Mirv> tsdgeos: ok. so how to eventually drop the support for non-upstream ones?
[10:06] <Saviq> in both vivid+overlay (which won't get Qt 5.5 will it?) and wily
[10:07] <Saviq> Mirv, we'd need to follow a deprecation process like the SDK does
[10:07] <Mirv> Saviq: well in an ideal world we could upgrade vivid+overlay to Qt 5.5. after some sunny day I get to publish 5.5 to wily+1, I can create a PPA to see how it looks there.
[10:07] <Saviq> yeah I meant wily+1
[10:08] <Saviq> Mirv, sure, but that's not a target, yet, so when we land 5.5, we need to make sure stuff works there, too
[10:08] <Mirv> tsdgeos: so, I think the supporting of dual roles in qtmultimedia is actually the first thing that should be landed, so that you can continue shipping unmodified Unity 8 to both
[10:08] <Saviq> yup
[10:08] <Mirv> tsdgeos: can you come up with a patch for qtmultimedia that works on top of the current Qt 5.5 branch? maybe then we can switch the 5.4 qtmultimedia to the same set of patches (new upstream ones + yours filling up the old support)
[10:08] <Saviq> we need to coordinate with SDK guys
[10:09] <Mirv> dual landing silos can now be done for manual upload packages too, so we could have one silo to land to both wily+vivid overlays
[10:09] <Saviq> Mirv, OTOH, https://developer.ubuntu.com/api/apps/qml/sdk-15.04.1/QtMultimedia.Audio/ does not publish the Role prop...
[10:10] <tsdgeos> Saviq: what needs coordination with the SDK?
[10:10] <Mirv> Saviq: yeah, I don't think anyone is using it as it's only been there since summer
[10:10] <Saviq> tsdgeos, deprecation process
[10:11] <Mirv> in order to land to vivid overlay we'd need to not deviate wily from it, so I think first up is landing qtmultimedia 5.4.2 (wily) and 5.4.1 (vivid) and just keep the 5.5 PPA up-to-date too
[10:11] <Saviq> Mirv, tsdgeos, if it's not a public prop, maybe we don't need to jump through those hoops, but rather just backport the new patch to 5.4
[10:11] <Saviq> bzoltan_, ping
[10:12] <tsdgeos> id' we fine with that
[10:12] <Saviq> would definitely be easier
[10:13] <tsdgeos> ./usr/share/click/preinstalled/com.ubuntu.clock/3.5.364/share/qml/alarm/AlarmSound.qml:        audioRole: MediaPlayer.alert
[10:13] <tsdgeos> seems the clock at least is using it?
[10:13] <tsdgeos> ./usr/share/ubuntu/settings/system/qml-plugins/sound/SoundsList.qml:        audioRole: MediaPlayer.alert
[10:13] <tsdgeos> and ↑ whatever it is
[10:13] <Mirv> Saviq: tsdgeos: but just backporting the new patch to 5.4 would still mean we need to upgrade qtubuntu-media, qtubuntu-camera and unity8 in vivid-overlay
[10:14] <Mirv> tsdgeos: ok, I guess it was announced then somewhere and started to be used
[10:14] <Saviq> Mirv, yes
[10:14] <Saviq> tsdgeos, well, clock and settings we'd have to update
[10:14] <Mirv> sounds like the original proposal is needed, otherwise this is expanding a bit too much
[10:14] <Mirv> however you wish. if only 5.4 backport is needed, I can handle that and give you a silo to put wily+vivid unity8 etc in
[10:15] <Saviq> but indeed without a new framework we won't be able to publish a new version of them
[10:15] <tsdgeos> Saviq: i'm just scared it may be used outside "our stuff"
[10:15] <Saviq> tsdgeos, well, that's the question - if it's used without being public, not really our fault
[10:16]  * Mirv creates a silo anyway for a new dual landing
[10:16] <Saviq> we can't keep stable APIs of stuff we didn't commit to
[10:16] <Saviq> Mirv, tsdgeos, let's not do anything just yet and find out what's the real status of it
[10:16] <Saviq> if it's only been built in for internal use, maybe we can deal with that
[10:16] <tsdgeos> oki
[10:16]  * tsdgeos puts the work on this on a halt
[10:17] <Mirv> tsdgeos: fix for 5.5 anyway welcome, it's a bit annoying to edit QML files by hand
[10:18] <Saviq> yeah we can have an MP up for 5.5 compatibility anyway
[10:18] <Saviq> as that's where we wanna get in any case
[10:18] <Mirv> jhodapp should know how the audio role API came to be, is it supposed to be public and what usage is there
[10:19] <Mirv> jhodapp: mostly we're interested if we did commit to the old API already, ie do we need do keep compatibility with both the old and new one until the old one is properly deprecated
[10:20] <Saviq> Machines vs. Machines has it commented out
[10:20] <Saviq> didn't find it anywhere else
[10:20]  * Saviq emailthreads
[10:26] <Saviq> Mirv, so this output https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1493851/comments/8 is from 5.5?
[10:26] <ubot5`> Ubuntu bug 1493851 in qtubuntu-media (Ubuntu) "Port to upstreamed versions of Audio Role patch" [High,In progress]
[10:26] <Saviq> FWIW they don't advertise the role property in upstream 5.5 docs either http://doc.qt.io/qt-5.5/qml-qtmultimedia-audio.html
[10:27] <Mirv> Saviq: yes, or strictly speaking it's a backport of Qt 5.6's upstream patch that we was submitted by us. the point is that it's better to switch earlier than linger it later... one option of course would be to postpone it and remove the patches until 5.6. but by then we might have more usage of the old API..
[10:27] <Saviq> oh right
[10:27] <tsdgeos> i think the best would be supposrt both for 5.5
[10:27] <tsdgeos> since technically it's not there yet
[10:28] <tsdgeos> and then remove it for 5.6
[10:28] <tsdgeos> but yeah needs input from bzoltan_ & SDK
[10:28] <Saviq> tsdgeos, so what got renamed actually? the enums?
[10:29] <tsdgeos> Saviq: yep
[10:29] <Saviq> ack
[10:29] <tsdgeos> ah no
[10:29] <tsdgeos> both enum and property
[10:29] <tsdgeos> role instead of audioRole
[10:29] <Saviq> rly http://doc-snapshots.qt.io/qt5-5.6/qml-qtmultimedia-audio.html#audioRole-prop ?
[10:30] <tsdgeos> hmmm
[10:31] <tsdgeos> ok i guess what happenend is not that the audioRole is now part of 5.5 import
[10:31] <tsdgeos> not of 5.4 import
[10:31] <tsdgeos> that's going to be a mess
[10:31] <tsdgeos> we need the 5.0 import to still work for vivid
[10:32] <Saviq> so for 5.0 and 5.4 we'd need to support the old enum values
[10:33] <Saviq> and leave 5.5 be
[10:33] <Saviq> but then we can't make 5.4 forward-compatible
[10:33] <Saviq> so we need a new framework for 5.5 anyway
[10:49] <Saviq> it seems for as long as we want to support vivid/5.4 we'll need to make the 5.0 and 5.4 imports work
[10:51] <Saviq> no need for new enums in 5.0 or 5.4 import, though
[10:53] <Saviq> /food
[10:56] <tsdgeos> Mirv: ping#2
[10:57] <tsdgeos> Mirv: unping for now
[11:07] <Mirv> hmm
[11:07] <Saviq> greyback_, please merge lp:~dandrader/qtmir/mousePointer in multimonitor
[11:08] <greyback_> bah conflicts
[11:10] <greyback_> Saviq: conflicts resolved, prob ok, but will build to make sure
[11:12] <tsdgeos> Mirv: ok, ping again, i can't seem to install silo 12 and get a bootable phone
[11:12] <tsdgeos> Mirv: have you tried lately?
[11:13] <Mirv> tsdgeos: "did you read the manual"?
[11:13] <greyback_> Saviq: yeah builds ok
[11:13] <tsdgeos> Mirv:  probably not
[11:13] <Mirv> tsdgeos: https://wiki.ubuntu.com/Touch/QtTesting
[11:14] <Mirv> tsdgeos: and yes, yesterday I think the last time
[11:15] <Mirv> tsdgeos: because of wily overlay pinning is now needed on wily too.. plus using it makes the 012 less likely to break. but citrain tool won't (ever) work.
[11:57] <Saviq> greyback_, tx
[11:58] <Saviq> Mirv, robru just tried a different approach in citrain tool (sent email around last night), still won't work?
[12:05] <Mirv> Saviq: yeah I think robru's new method should work (I checked the MP), so once it's in archives I can update the instructions
[12:05] <Mirv> since apt install without archives being disabled should also install the new depends, and citrain already does pinning
[12:06] <Saviq> yup
[12:27] <jhodapp> Mirv, as long as the new roles map to the same old role inside of pulse audio it doesn't matter
[12:37] <tsdgeos> Mirv: i have a black screen following the instructions on an areale
[12:37] <tsdgeos> ah because notifications
[12:37] <tsdgeos> obsiously
[12:52] <Mirv> jhodapp: ok, you can reply to Saviq's e-mail too to make the answer as verbose as possible. the thing is we have at least internal apps that use the old API that would break if not updated or if both API:s would be supported together for some time
[12:52] <Mirv> tsdgeos: obviously
[12:53] <Saviq> dandrader, hey, can you please merge lp:~gerboland/qtmir/multimonitor → lp:~dandrader/qtmir/surviveEmptyTexture → lp:~dandrader/qtmir/multimonitorNext
[12:53]  * greyback_ really wants a staging branch
[12:54] <Saviq> greyback_, it wouldn't help that much this time, too many projects involved
[12:54] <jhodapp> Mirv, sure, moving to the new API is fine as long as they use the equivalent new role...but yeah I'll reply
[12:56] <Saviq> greyback_, at least half of MPs in silo 22 depend on other projects to go with, which means they shouldn't be staged
[12:56] <greyback_> Saviq: unless those projects also had a staging branch..
[12:57] <Saviq> greyback_, no, because at that point you introduce a requirement for both stagings to get released at the same time
[12:57] <greyback_> which the train could do
[12:58] <Saviq> greyback_, not what I mean, if one of the projects' staging could not be released for whatever reason, the other one's blocked
[12:59] <greyback_> Saviq: I'm not meaning a general staging branch for other projects, but unity8 could have a  qtmir-staging branch, with only the changes qtmir needs
[13:00] <Saviq> greyback_, not sure what's the difference between individual MPs at that point
[13:00] <Saviq> but maybe
[13:00] <greyback_> Saviq: no need to chain branches
[13:00] <greyback_> that's the only benefit
[13:00] <greyback_> not major, but might help for these mammoth silo situations
[13:01] <Saviq> greyback_, you need to chain stagings ;)
[13:01] <Saviq> because unity8/staging will conflict with unity8/qtmir-staging
[13:01] <dandrader> Saviq, done
[13:01] <Saviq> dandrader, thanks
[13:02] <greyback_> Saviq: we'd only release one at a time. I try to only release unity8 & qtmir changes combined
[13:02] <Saviq> dednick, can you please merge lp:~dandrader/qtmir/multimonitorNext → lp:~nick-dedekind/qtmir/remove-dpkg-CMAK_INSTALL_PREFIX → lp:~unity-team/qtmir/touch_tracing
[13:02] <Saviq> greyback_, well, that's not the case in this mammoth silo, we're releasing everything for unity8 and qtmir together
[13:04] <dednick> Saviq: hm. thought i did that already
[13:04] <Saviq> dednick, you did, but we had a change up the chain
[13:04] <Saviq> that we need down the chain...
[13:04] <Saviq> ok I can't flash mako over usb any more :[
[13:04] <dednick> Saviq: ah. k
[13:05] <dednick> Saviq: i don't see any conflicts.
[13:06] <Saviq> dednick, nope
[13:06] <dednick> Saviq: ah. didnt think that was necessary if no clnflicts
[13:06] <dednick> Saviq: done
[13:06] <Saviq> dednick, there are some down the chain, but couldn't get bzr to comply
[13:06] <Saviq> ltinkl, ↑ you can merge wheelEvent
[13:23] <ltinkl> Saviq, against what?
[13:25] <Saviq> ltinkl, against the prerequisite
[13:25] <Saviq> ltinkl, lp:~lukas-kde/qtmir/wheelEvent
[13:26] <ltinkl> Saviq, lp:~unity-team/qtmir/touch_tracing  right?
[13:26] <ltinkl> (that's the prereq currently)
[13:27] <Saviq> ltinkl, yup
[13:27] <Saviq> ltinkl, that should have the fixed MouseButtons bit
[13:27] <ltinkl> Saviq, ye, on it
[13:37] <ltinkl> Saviq, merged
[13:38] <Saviq> ltinkl, ack
[13:43] <tsdgeos> Saviq: Mirv: commented at https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1502883
[13:43] <ubot5`> Ubuntu bug 1502883 in qtdeclarative-opensource-src (Ubuntu) "Impossible to pull to refresh scopes with Qt 5.5" [Undecided,New]
[13:44] <tsdgeos> i'd say we just wait for Qt 5.5.1
[13:44] <Saviq> tsdgeos, ack
[13:44] <tsdgeos> since once i updated the files regarding the flickable it went back to normal
[14:53] <Saviq> ltinkl, GAH, you got green CI, how'd you do it!? ;)
[14:53] <ltinkl> \o/
[14:53] <ltinkl> waiting for https://code.launchpad.net/~lukas-kde/unity8/fixLogin1Tests/+merge/272493 rebuild
[14:53] <ltinkl> hopefully it will also be green :)
[14:54]  * Saviq tempted to rebuild just to see if you cheated
[14:54] <ltinkl> Saviq, btw is there a CI job that runs on trunk?
[14:55] <Saviq> ltinkl, we can trigger one on demand
[14:58] <Saviq> ltinkl, we could trigger it on push to trunk, but that's too late, 'innit ;)
[14:58] <ltinkl> ye
[14:58] <Saviq> I hope at some point we'll have them run in silo
[15:06] <tsdgeos> yeah
[15:06] <tsdgeos> that's particularly useful for MRs that require unity-api
[15:06] <tsdgeos> where CI is all failures
[15:07] <Saviq> tsdgeos, oh for that we need smarter CI that can take prerequisites from other projects into account
[15:08] <tsdgeos> Saviq: or just run on silos :D
[15:08] <tsdgeos> so at least we can run all the tests in a silo
[15:08] <Saviq> tsdgeos, sure, we need both, really
[15:14] <ltinkl> having a CI-enabled would also prevent breakages that don't happen in isolated MPs
[15:14] <ltinkl> like, 2 individual MPs might be fine but when combined together it would fail
[15:16] <Saviq> bbl
[15:17] <Saviq> whoo Mir 0.17 landed, means we might even think of landing 22 tomorrow
[15:27] <Mirv> tsdgeos: thanks, 5.5.1 should be fiiinally out tomorrow, hopefully. hopefully it fixes ~everything, but at least that bug..
[15:27] <tsdgeos> Mirv: are there many issues?
[15:32] <Mirv> tsdgeos: still unresolved some UITK, some FTBFS:s, https://bugs.launchpad.net/bugs/+bugs?field.tag=qt5.5 - and no-one else besides me has tried it out or filed bugs so there might be more (and probably is)
[15:34] <tsdgeos> i see
[15:51] <tsdgeos> Mirv: regarding https://bugs.launchpad.net/ubuntu/+source/u1db-qt/+bug/1447182
[15:51] <ubot5`> Ubuntu bug 1447182 in u1db-qt (Ubuntu) "u1db-qt FTBFS with Qt 5.5" [High,Triaged]
[15:51] <tsdgeos> $ LC_ALL=C apt-cache policy u1db-qt
[15:51] <tsdgeos> N: Unable to locate package u1db-qt
[15:51] <tsdgeos> ?¿
[15:52] <tsdgeos> ah it's not the name of the pacakge
[15:52] <tsdgeos> my fault sorries
[18:18] <dandrader> greyback_ greyback__ sorted out the surface resize threading issues. but it will need tripple buffering
[18:18] <dandrader> greyback__ only way I see of doing it with double buffering is using a non-threaded qsg renderer
[18:18] <greyback__> dandrader: that's not ideal
[18:19] <greyback__> but I can see why that would be an option
[18:19] <dandrader> greyback__, or using a "crop or pad" resize method
[18:20] <greyback__> which no-one else in the world does, and we don't do either
[18:20] <dandrader> greyback__, this is actually what unity 7 does
[18:20] <greyback__> dandrader: who needs to be triple buffered, the compositor and/or client?
[18:20] <dandrader> greyback__, but it's worse. it's more like a "crop or pad with random memory"
[18:21] <dandrader> greyback__, client
[18:21] <greyback__> dandrader: ok, well doing better than unity7 would be best
[18:22] <greyback__> dandrader: could you document your reasoning please?
[18:22] <greyback__> this is something where looking at code won't obviously explain your approach
[18:22] <greyback__> and a picture or two would help a lot
[18:22] <greyback__> duflu could have insights on this too
[18:29] <robru> Saviq: Mirv did you try the new tool? I think it's not perfect but I think I know how to make it perfect, will experiment more today
[18:43] <Saviq> robru, I replied to the CFT email
[18:43] <robru> Saviq: thanks
[19:23] <dandrader> greyback__, branches are up for review: https://code.launchpad.net/~dandrader/qtmir/surfaceItemFillMode/+merge/274449


[00:06] <mhall119> jcastro: dude, that's going to be a great success story
[00:06] <mhall119> are you going to set them up to scale on-demand when they get high traffic and everthing?
[00:17] <bkerensa> jcastro: lol no worries
[00:17] <bkerensa> jcastro: saving OMG how?
[00:18] <bkerensa> I wonder why they didnt redirect their DNS to a splash page somewhere :P
[00:18] <bkerensa> with a 301
[00:18] <bkerensa> OMG is going to taking a SERP beating
[02:06] <nigelb> mhall119, jcastro - http://www.peppertop.com/greys/2010/02/ubuntufied-flying-object/
[02:14] <mhall119> nigelb: lol
[02:15] <nigelb> quick! change the tag line!
[03:03] <popey> woah, link to my blog at the end of that
[03:19]  * nigelb blinks
[03:21] <nigelb> ha
[03:32] <jcastro> mhall119, almost done
[03:32] <jcastro> man
[03:32] <jcastro> what a horrible mess
[04:01] <nigelb> jcastro: what happnened?
[04:18] <jcastro> he migrated hosts
[04:18] <jcastro> and like, had no clue how to set it up
[04:18] <jcastro> so we just deployed it on aws using juju
[04:19] <nigelb> o_O
[04:19] <nigelb> anyway, epic juju win
[04:19] <jcastro> man
[04:19] <jcastro> our wordpress and mysql charms are for chumps
[04:19] <jcastro> we need to optimize them
[05:03] <bkerensa> jcastro: He didnt know how to do a Wordpress Install?
[05:03] <bkerensa> seriously
[05:03] <bkerensa> :(
[05:04] <bkerensa> epic so bad
[05:04] <bkerensa> jcastro: ^ yes they are
[05:04] <bkerensa> jcastro: Uhh you might want to have him Submit a rdns request :P
[05:05] <bkerensa> http://ec2-23-21-149-239.compute-1.amazonaws.com/ <-- omg
[09:24]  * popey wonders what he'd have to do to get jcastro to jujuify the ubuntu uk podcast website ☺
[11:56] <jussi> can anyone explain to me the idea that bug 958384 is invalid because it needs discussion? I dont think the fact it needs discussion means it isnt a bug...? :/
[11:56] <ubot2`> Launchpad bug 958384 in libreoffice "Libre office default style settings are poor." [Undecided,Invalid] https://launchpad.net/bugs/958384
[12:37] <czajkowski> jussi: it's an opinion then
[12:41] <jussi> czajkowski: I dont think the fact of it is disputed by anyone, just that how to solve it needs discussion.
[12:45] <czajkowski> jussi: but the discussion is pointed to a ml
[12:45] <czajkowski> which imo is a better place than bugs tbh
[13:36] <AlanBell> yeah, but it is nice for the bug to exist so it can be fixed by a commit at some point
[13:57] <AlanBell> nigelb: do you know about boot to gecko?
[13:57] <nigelb> yeah
[13:58] <nigelb> you can clone gaia and run it on your browser.
[13:58] <nigelb> probably only nightly though.
[13:58] <AlanBell> how about on my galaxy s2
[13:59] <nigelb> oh, you can probably run the whole thing. I don't know how far it is though.
[13:59] <AlanBell> ok
[14:00] <nigelb> I can check with someone on monday
[14:02] <AlanBell> looking at the roadmap it might still be a bit early to jump in
[14:07] <mhall119> jcastro: are you going to guest-post on OMG about getting them back up?
[15:40] <jcastro> mhall119, I just blogged it on mine
[15:40] <jcastro> and will syndicate on cloud.u.c
[15:40] <jcastro> and probably make an OMG! specific one
[16:09] <nigelb> jcastro: hey, how did you copy the data around?
[16:09] <jcastro> rsync
[16:09] <nigelb> of the mysql data files?
[16:09] <nigelb> I'm surprised it took that long then.
[16:10] <nigelb> oh wait, it's between a different provider and aws. Nevermind.
[16:18] <jcastro> yeah
[16:21] <cjohnston> what happened to OMG
[16:21] <cjohnston> did I miss something?
[16:21] <nigelb> It was down for 3 days. jcastro called on the power of juju to fix it. :D
[16:21] <cjohnston> ic
[16:40] <jcastro> mhall119, hang with me here
[16:40] <jcastro> mhall119, ok so he's working on the charm now
[16:40] <jcastro> and we'll redeploy to m1.smalls
[16:41] <jcastro> do you know if you can move a bucket from one person to another?
[16:43] <mhall119> jcastro: I don't, sorry
[16:55] <mhall119> jcastro: what is the juju bootstrap node for?  Surely you don't need a dedicated instance just to use juju
[16:55] <jcastro> it runs the zookeeper
[16:55] <jcastro> but we can move that to run on the same instance as the proxy
[16:55] <jcastro> we just can't right now until next week
[16:55] <jcastro> as the feature hasn't landed
[16:56] <jcastro> but once it lands you could run everything on one node if you wanted like how AlanBell would want
[16:57] <AlanBell> I would be interested to know if things are actually faster or slower on one node vs 4 nodes
[16:58] <jcastro> one big node vs. 4 smalls?
[16:58] <jcastro> yeah
[16:58] <AlanBell> think I would bet on a single node being faster than having a database on a separate node to the application, and without an extra proxy jump
[16:59] <AlanBell> or all on one small vs all on 4 smalls
[16:59] <jcastro> I am reasonably confident that this will be cheaper than his colo set up
[16:59] <jcastro> the problem for OMG being on only one (or say, one large or medium) is then we wouldn't be able to grow and shrink on demand
[17:00] <jcastro> The biggest issue right now is apache serving up all those images
[17:00] <mhall119> AlanBell: I'd expect better performance with MySQL on a separate node
[17:00] <jcastro> and getting that to S3 asap
[17:01] <AlanBell> mhall119: depends how chatty the database and the application are I guess
[17:02] <AlanBell> the main thing to do is avoid using the database at all and use wp-supercache or something
[17:03] <AlanBell> if you are hitting the db, you want it fast and close, so multiple network requests to get stuff doesn't sound like a good plan
[17:04] <mhall119> I think Wordpress defaults to MyISAM, which is pretty darn fast
[17:04] <mhall119> plus MySQL does query caching
[17:05] <mhall119> jcastro: Elastic Load Balancing costs $0.025/hr, and supposedly does auto-scaling too, which might work better for them than haproxy
[17:06] <jcastro> yeah ryan pointed that out to me
[17:07] <mhall119> you might have to make custom OMG images though, for that to work
[17:07] <mhall119> it would be awesome if Amazon supported juju charms for this stuff
[17:07] <jcastro> yeah plus, I'd like to give him some options to not be AWS specific
[17:08] <jcastro> we have to be AWS specific on the storage for now
[17:08] <jcastro> but it'd be nice to say ... in a year he finds a nicer price on rackspace or a local ISP for instances
[17:08] <jcastro> and just redeploys there.
[17:08] <jcastro> or bare metal if he wants to colo again
[17:08] <mhall119> true, being able to quickly redeploy somewhere else is a nice option to have
[17:09] <mhall119> though not all will support S3, so that's something to consider in your wordpress-omg charm
[17:09] <AlanBell> I would love to build servers using juju as a standard practice, but it just chews up too many instances
[17:10] <jcastro> one more week
[17:10] <jcastro> one more week
[17:10] <jcastro> i've been aching for it too
[17:10] <jcastro> an extra instance is a deal breaker.
[17:10] <jcastro> especially since you also can't say "juju I want an m1.small for you, an x1.large for wordpress, and an m1.medium for mysql" yet.
[17:10] <jcastro> but next week we get all of that.
[17:11] <jcastro> unfortunate timing
[17:11] <nigelb> I want to say, here's an m1 server. Install wordpres, mysql, and apache on it.
[17:11] <nigelb> Not spam 4 servers for that.
[17:12] <AlanBell> exactly
[17:12] <jcastro> right
[17:12] <nigelb> *spawn
[17:12] <jcastro> We don't do that until next week
[17:12] <nigelb> one week!
[17:12] <AlanBell> then one day when that isn't enough, split it out smoothly
[17:12] <nigelb> I'll take that as win.
[17:12] <jcastro> right.
[17:12] <jcastro> believe me no one is aware of this pain more than juju folks
[17:12] <nigelb> I will check this out when precise releases.
[17:13] <nigelb> I expect all of this would be fixed then.
[17:13] <jcastro> indeed
[17:13] <mhall119> one more week?
[17:13] <AlanBell> if we can do a juju based openerp install on one instance, that can be scaled up to lots of instances then that would be a big win
[17:13] <nigelb> finally a tool that's not in ruby.
[17:15] <jcastro> AlanBell, actually just last week someone submitted openerp
[17:15] <jcastro> mhall119, yeah, the feature is called "constraints", it's all reviewed and ready to land.
[17:17] <AlanBell> so they did, old version though
[17:17] <jcastro> no worries
[17:17] <jcastro> we can easily make that pull trunk
[17:17] <jcastro> in fact that's what marco's working on for the wordpress charm
[17:17] <jcastro> it stupidly pulls the archive version
[17:17] <jcastro> which is basically shipping the old one that doesn't upgrade ootb
[17:18] <jcastro> boo...
[17:18] <AlanBell> openerp 6.1 has slightly different install routine as the webserver now runs in-process
[17:19] <jcastro> would you be comfortable reviewing the charm?
[17:20] <AlanBell> yeah, or I might hand that over to TheOpenSourcerer
[17:22] <jcastro> nod
[17:23] <nigelb> I don't even know why we should have wordpress in the acrchive.
[17:24] <jcastro> the juju charm store isn't active yet, so it's not obvious to people
[17:24] <jcastro> that with charms
[17:24] <jcastro> you don't have to care about the archive
[17:24] <jcastro> we'll have fresh wordpress for the life of 12.04
[17:26] <jcastro> mhall119, how typical
[17:26] <jcastro> the comments on facebook are talking about unity.
[17:27] <marcoceppi> nigelb: I said the same thing :)
[17:27] <nigelb> jcastro: obviusly. facebook crowd isn't known for maturity :)
[17:28] <nigelb> marcoceppi: It is a bigger security hole :P
[17:31] <AlanBell> I totally don't get Facebooko
[17:42] <s-fox> o/
[17:50] <jcastro> ok let's do math
[17:50] <jcastro> ~16gb of traffic so far since last night
[17:50] <jcastro> so, 12 hours worth
[17:51] <nigelb> wtf, 16GB in 12 hours?
[17:51] <nigelb> no wonder you want his images moved to s3.
[17:51] <jcastro> it's only a cent cheaper
[17:51] <jcastro> still
[17:51] <jcastro> at 11 cents, it's $100 a month
[17:52] <jcastro> that's $316 a month
[17:53] <nigelb> how much did he used to pay?
[17:53] <jcastro> lol
[17:53] <jcastro> 200 pounds
[17:53] <jcastro> which right now translates to
[17:53] <jcastro> $316 a month
[17:53] <marcoceppi> ha!
[17:53] <nigelb> hahaha
[17:53] <jcastro> that's sunday traffic
[17:53] <jcastro> let's assume he's busier
[17:53] <jcastro> and double the traffic
[17:54] <jcastro> it's $416
[17:54] <jcastro> ah bummer
[17:55] <jcastro> the price only goes down to .09 a gig when he tops 10TB.
[17:55] <jcastro> ok am I reading this wrong
[17:56] <jcastro> the data out of S3 is the exact same price as EC2, 12 cents
[17:56] <jcastro> that can't be right
[18:22] <AlanBell> gosh
[18:23] <nigelb> I bet rackspace is cheaper.
[18:24] <AlanBell> this is what most of our hardware is http://www.hetzner.de/en/hosting/produkte_rootserver/ex5
[18:24] <nigelb> ha, hetzner :)
[18:25] <AlanBell> we slice those up using KVM into quite a few VMs, about 10 per host
[18:26] <nigelb> Manually?
[18:26] <AlanBell> yeah, we wanted to use the eucalyptus stuff but that required an additional host as a manager
[18:27] <nigelb> nice
[18:27] <AlanBell> so it is just KVM, and I use the virt-manager thing to poke at them and spin up new ones etc
[18:29] <AlanBell> would love to do it in a more buzzword compliant manner, but cloud stuff is massively more expensive
[18:29] <nigelb> heh, yeah.
[18:32] <cjohnston> What makes AWS better than say rackspace?
[18:33] <nigelb> AWS has more features
[18:33] <nigelb> Also been around longer
[18:33] <nigelb> and more datacenters
[18:33] <AlanBell> it is from a company that real people have heard of too
[18:34] <nigelb> lol
[18:34] <cjohnston> When did AWS come out?
[18:35] <nigelb> 2002.
[18:35] <cjohnston> I know that there is no direct price comparison because the sizes are different, so I'd have to do math
[18:37] <marcoceppi> I've also never gotten along with anyone from Rackspace
[18:37] <cjohnston> lol
[18:37] <cjohnston> I have a few good friends who are with Rackspace.. They all started with Slicehost.. but are now at RS
[18:37] <nigelb> soren is a nice guy AFAIK.
[18:37] <cjohnston> to me, when looking at AWS to setup, it seems overwealming
[18:38] <nigelb> but then he no longer works at rackspace.
[18:38] <nigelb> cjohnston: It's dead simple actually.
[18:38] <marcoceppi> cjohnston: juju, duh :)
[18:38] <cjohnston> lol
[18:38] <cjohnston> juju is brand new
[18:39] <nigelb> cjohnston: the button clicks are not too complicated.
[18:39] <cjohnston> but for me, I run everything on a 1gig cloud server at RS.. $0.06/hr... I don't need multiple isntances or anything like that.. I run multiple blogs on it, I get IP addresses as needed..
[18:39] <nigelb> RS is *too* simple for me to run anyhting on it professionally.
[18:40] <cjohnston> I guess I like the fact that its nice and simple
[18:40] <nigelb> I'm talking about DBs that are 20 GB in size. etc.
[18:40] <marcoceppi> Each provider has it' use case
[18:40] <nigelb> For personal use, I'd probably trust rackspace than amazon.
[18:41] <nigelb> It is cheaper.
[18:41] <cjohnston> I'm just trying to figure out, because I *have* to learn to use amazon, should I learn it and move my stuff over..
[18:42] <cjohnston> RS seems to have more DCs.. they have 8
[18:43] <cjohnston> a little less spread out.. but still comparable
[18:43] <nigelb> huh?
[18:43] <nigelb> does RS let you select which data center to use?
[18:44] <cjohnston> hrm.. I guess for cloud servers they are still in DFW
[18:45] <jcastro> among traditional hosts Rackspace (at least in the US) is one of the more dominant ones
[18:45] <jcastro> if anyone can compete with AWS it's them
[18:45] <jcastro> but they needed openstack for that
[18:45] <nigelb> YEah
[18:45] <nigelb> Not yet there.
[18:45] <nigelb> I waiting for them to have openstack.
[18:45] <jcastro> they have a cloud thing
[18:45] <jcastro> but it's not openstack
[18:45] <nigelb> not as great as amazon yet.
[18:46] <nigelb> not as many features.
[18:46] <jcastro> It's pretty much a monopoly
[18:46] <nigelb> yeah, sadly.
[18:46] <jcastro> however HP's Public cloud is in beta
[18:46] <jcastro> as openstack matures everyone will just start selling instances
[18:46] <jcastro> the same way they sold VPSes and shells
[18:46] <nigelb> oooh. that should be interesting
[18:46] <nigelb> is the HP thing openstack?
[18:46] <jcastro> It is
[18:47] <jcastro> on ubuntu
[18:47] <nigelb> \o/
[18:47] <jcastro> if openstack had an equivalent to s3 stuff that was solid
[18:47] <jcastro> like a storage solution
[18:47] <jcastro> we could then have juju just generically support storage
[18:47] <jcastro> and the charms wouldn't need to be s3 specific
[18:48] <nigelb> there's still stuff that can do something like that
[18:48] <jcastro> then you could just move to whatever hosting provider you want
[18:48] <nigelb> glusterfs?
[18:48] <jcastro> gluster and ceph
[18:48] <jcastro> I expect storage to be the big topic this year in openstack
[18:54] <popey> jcastro: I am getting a tomcat message from omgubuntu.co.uk
[18:55] <jcastro> DNS is out of date for you then
[18:55] <popey> ah
[18:55] <jcastro> try privacy mode in your browser
[18:55] <jcastro> and try again
[18:55] <jcastro> you might be caching the old 301 redirect
[19:01] <Daviey> jcastro: you are kidding, right?
[19:02] <Daviey> jcastro: opnestack has swift for file storage.. It's what rackspace uses in production called "cloudfiles"
[19:02] <Daviey> predates openstack.
[19:02] <jcastro> Daviey, oh sweet so I can just point juju to it and get the exact same thing I can with s3?
[19:02] <Daviey> jcastro: that is the plan!
[19:02] <jcastro>  right, the plan
[19:03] <jcastro> but doesn't help me right now.
[19:03] <Daviey> (there is also a ceph object storage component, but not experimented with it myself)
[19:03] <jcastro> yeah, for now his charm will be S3-specific
[19:03] <Daviey> jcastro: Canonsistack doesn't yet provide S3.
[19:03] <jcastro> but the idea of being able to redeploy on openstack is awesome, I will actually try it too
[19:04]  * AlanBell ponders a performance faceoff with a multi-tier juju rig vs an all in one on a VM setup
[19:04] <jcastro> Daviey, oh so what you're telling me is that limitation is our deployment specific? And that everything is fine in upstream?
[19:04] <jcastro> "fine" as in, will be working
[19:05] <Daviey> jcastro: Well, swift is largely regarded as the most stable component
[19:05] <jcastro> man, I am delighted to be so wrong.
[19:05] <jcastro> Daviey, someone should put you in charge of stuff
[19:05] <Daviey> there is a shim which proxies to s3 in nova.. it's not /well/ tested, compared to the rest of it.
[19:06] <Daviey> jcastro: hah
[19:07] <jcastro> man I am kicking myself for the xlarges
[19:07] <nigelb> Isn't he already incharge of stuff? :D
[19:07] <jcastro> marcoceppi, it was getting late and I was getting inpatient
[19:07] <jcastro> should have texted Clint way earlier
[19:07] <nigelb> also, seeing Daviey on IRC on a weekend.
[19:07] <nigelb> I'm shocked beyond belief.
[19:08] <jcastro> $60 dollar mistake, that's like a nice steak.
[19:12] <jcastro> popey, clearing the cache do it?
[19:22] <jcastro> man there's tons of things we can optimize here
[19:22] <jcastro> these pages are heavy
[19:22] <jcastro> and the images are like, being resized in html
[19:22] <jcastro> http://cdn.omgubuntu.co.uk/.../Screen-Shot-2012-03-12-at-17.03.47-50... is resized in HTML or CSS from 500x295 to 150x88. Serving a scaled image could save 183.2KiB (91% reduction).
[19:22] <jcastro> a whole bunch of these right on the homepage
[19:23] <jcastro> I bet we can easily slim down the amount of things he needs to serve on top of what we're doing
[19:25] <bkerensa> jcastro: He needs to smush his images and use image polish to dynamically resize on the fly
[19:25] <jcastro> I think WP does this in the newish version
[19:26] <jcastro> the new charm will just use upstream wordpress so he can update on his own schedule
[19:26] <bkerensa> jcastro: there is a wordpress Yahoo SmushIt plugin... it will resmush all his images
[19:26] <bkerensa> as for Image Polish only Cloudflare offers this atm
[19:26]  * jcastro notes that
[19:29] <czajkowski> cjohnston: should I be seeing http://summit.ubuntu.com/uds-q/track/community/
[19:29] <AlanBell> jcastro: I would be interested in a funkload report of a default (unoptimised) wordpress install on a single small instance compared to a 3 instance setup
[19:30] <cjohnston> czajkowski: no
[19:34] <Daviey> nigelb: Are you kidding?
[19:34] <Daviey> nigelb: I'm on most weekeneds
[19:35] <cjohnston> Daviey: since your around and all.. want to help me with an error that I came across with summit ;-)
[19:35] <cjohnston> hehe
[19:36] <Daviey> cjohnston: oh?
[19:36] <cjohnston> Daviey: http://summit.chrisjohnston.org  <-- click login
[19:37] <cjohnston> a google search gave me 3 results, which didnt help. :-/
[19:38] <Daviey> cjohnston: Are you  missing a *kwargs?
[19:38] <cjohnston> i don't think I changed anything that would effect login...
[19:39] <cjohnston> it works locally too
[19:40] <Daviey> cjohnston: is production summit running 1.3 now?
[19:40] <cjohnston> yes
[19:42] <cjohnston> https://code.launchpad.net/~chrisjohnston/summit/action-item-links and https://code.launchpad.net/~chrisjohnston/summit/new-meeting-stuff plus a little css is what was merged in
[19:43] <Daviey> cjohnston: Hah, https://bugs.launchpad.net/software-center-agent/+bug/873244 suggests a missing kwarg's aswell
[19:43] <ubot2`> Launchpad bug 873244 in software-center-agent "custom openid_render_failure has wrong signature" [Undecided,Fix released]
[19:45] <cjohnston> hrm
[20:07] <cjohnston> Daviey: I've looked back through the code, and unless I'm missing something, I don't see it. :-/
[20:22] <Daviey> cjohnston: I suspect it's that you are lacking relevant data on your devel site
[20:22] <Daviey> Perhaps don't have an admin user, a UDS object created, or something like that.
[20:22] <cjohnston> the devel site was working prior to the merge as well
[20:25] <Daviey> Oh, NFI then
[20:25] <Daviey> sorry :)
[20:25] <cjohnston> ok
[20:25] <cjohnston> ty
[20:25] <Daviey> cjohnston: Have you reverted the merge?
[20:26] <cjohnston> i just did.. it has an issue with the undoing the migration
[20:26] <Daviey> who merged a migration that doesn't allow a reverse? :
[20:26] <Daviey> :)
[20:28] <cjohnston> it has an inconsistant migration history
[20:33] <nigelb> Daviey: NFI is now my standard response to summit :D
[20:49] <Daviey> :)