[00:57] -queuebot:#ubuntu-release- New binary: scram [armhf] (zesty-proposed/universe) [0.11.4-1] (no packageset)
[00:59] -queuebot:#ubuntu-release- New binary: scram [arm64] (zesty-proposed/universe) [0.11.4-1] (no packageset)
[02:15] -queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-106.153~precise1] (kernel)
[08:04] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-106.153~precise1]
[08:23] -queuebot:#ubuntu-release- Unapproved: accepted crash [source] (trusty-proposed) [7.0.3-3ubuntu4.5]
[08:27] <xnox> pitti, can upstart be migrated ignoring tests? the only change is use upstart in less sessions.
[08:27] <xnox> and i hope to remove it completely
[08:27] <xnox> it is racy. i had to rebuild armhf/arm64 twice to succeed the build on buildds.
[08:28] <pitti> xnox: yes, we've been bumping the force-badtest for a long time anyway
[08:28] <xnox> excellent! thanks.
[08:29] <pitti> (done)
[08:41] -queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.2 => 3.168.3] (ubuntu-desktop, ubuntu-server)
[08:43] <rbasak> tjaalton, slangasek: FYI, still working on reviewing MAAS IPv6 SRU pieces in Xenial - cloud-init, ifupdown, initramfs-tools, isc-dhcp, open-iscsi.
[08:44] <rbasak> Almost there now.
[08:47] -queuebot:#ubuntu-release- Unapproved: update-notifier (yakkety-proposed/main) [3.175 => 3.175.1] (ubuntu-desktop, ubuntu-server)
[08:58] <xnox> pitti, please RM google-mock gtest
[08:58] <xnox> as they are superseed by the https://launchpad.net/ubuntu/+source/googletest which builds all the binaries the previous two did
[08:58] <xnox> as the two projects merged upstream.
[08:59] <xnox> pitti, ^
[09:00] <pitti> xnox: *flush* done
[09:06] <xnox> tah
[09:27] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.6 => 0.122ubuntu8.7] (core)
[10:53] -queuebot:#ubuntu-release- Unapproved: accepted deja-dup [source] (yakkety-proposed) [34.2-0ubuntu3.1]
[10:54] -queuebot:#ubuntu-release- Unapproved: accepted deja-dup [source] (trusty-proposed) [30.0-0ubuntu4.1]
[10:56] -queuebot:#ubuntu-release- New binary: cloud-initramfs-tools [amd64] (zesty-proposed/main) [0.33ubuntu1] (edubuntu, ubuntu-server)
[10:59] -queuebot:#ubuntu-release- New: accepted cloud-initramfs-tools [amd64] (zesty-proposed) [0.33ubuntu1]
[10:59] -queuebot:#ubuntu-release- New: accepted dcm2niix [armhf] (zesty-proposed) [1.0.20161101-1]
[11:00] -queuebot:#ubuntu-release- New: accepted dehydrated [amd64] (zesty-proposed) [0.3.1-1]
[11:00] -queuebot:#ubuntu-release- New: accepted node-is-unc-path [amd64] (zesty-proposed) [0.1.2-1]
[11:00] -queuebot:#ubuntu-release- New: accepted node-pkg-up [amd64] (zesty-proposed) [1.0.0-1]
[11:00] -queuebot:#ubuntu-release- New: accepted node-resolve-pkg [amd64] (zesty-proposed) [0.2.0-1]
[11:00] -queuebot:#ubuntu-release- New: accepted ocplib-simplex [arm64] (zesty-proposed) [0.3-1]
[11:00] -queuebot:#ubuntu-release- New: accepted qtltools [amd64] (zesty-proposed) [1.0+dfsg-1]
[11:00] -queuebot:#ubuntu-release- New: accepted qtltools [armhf] (zesty-proposed) [1.0+dfsg-1]
[11:00] -queuebot:#ubuntu-release- New: accepted qtltools [powerpc] (zesty-proposed) [1.0+dfsg-1]
[11:00] -queuebot:#ubuntu-release- New: accepted dcm2niix [arm64] (zesty-proposed) [1.0.20161101-1]
[11:00] -queuebot:#ubuntu-release- New: accepted icingaweb2 [amd64] (zesty-proposed) [2.3.4+fix-1]
[11:00] -queuebot:#ubuntu-release- New: accepted node-resolve-from [amd64] (zesty-proposed) [2.0.0-1]
[11:00] -queuebot:#ubuntu-release- New: accepted ocplib-simplex [armhf] (zesty-proposed) [0.3-1]
[11:00] -queuebot:#ubuntu-release- New: accepted qtltools [i386] (zesty-proposed) [1.0+dfsg-1]
[11:00] -queuebot:#ubuntu-release- New: accepted qtltools [s390x] (zesty-proposed) [1.0+dfsg-1]
[11:00] -queuebot:#ubuntu-release- New: accepted scram [arm64] (zesty-proposed) [0.11.4-1]
[11:00] -queuebot:#ubuntu-release- New: accepted scram [i386] (zesty-proposed) [0.11.4-1]
[11:00] -queuebot:#ubuntu-release- New: accepted scram [ppc64el] (zesty-proposed) [0.11.4-1]
[11:00] -queuebot:#ubuntu-release- New: accepted willow [amd64] (zesty-proposed) [0.3.1-1]
[11:00] -queuebot:#ubuntu-release- New: accepted dcm2niix [powerpc] (zesty-proposed) [1.0.20161101-1]
[11:00] -queuebot:#ubuntu-release- New: accepted node-vinyl [amd64] (zesty-proposed) [2.0.1-1]
[11:00] -queuebot:#ubuntu-release- New: accepted qtltools [ppc64el] (zesty-proposed) [1.0+dfsg-1]
[11:00] -queuebot:#ubuntu-release- New: accepted scram [armhf] (zesty-proposed) [0.11.4-1]
[11:00] -queuebot:#ubuntu-release- New: accepted scram [s390x] (zesty-proposed) [0.11.4-1]
[11:00] -queuebot:#ubuntu-release- New: accepted node-load-grunt-tasks [amd64] (zesty-proposed) [3.5.2-1]
[11:00] -queuebot:#ubuntu-release- New: accepted scram [amd64] (zesty-proposed) [0.11.4-1]
[11:00] -queuebot:#ubuntu-release- New: accepted qtltools [arm64] (zesty-proposed) [1.0+dfsg-1]
[11:00] -queuebot:#ubuntu-release- New: accepted scram [powerpc] (zesty-proposed) [0.11.4-1]
[11:00] -queuebot:#ubuntu-release- New: accepted bcal [amd64] (zesty-proposed) [1.4-1]
[11:00] -queuebot:#ubuntu-release- New: accepted dcm2niix [amd64] (zesty-proposed) [1.0.20161101-1]
[11:00] -queuebot:#ubuntu-release- New: accepted dcm2niix [ppc64el] (zesty-proposed) [1.0.20161101-1]
[11:00] -queuebot:#ubuntu-release- New: accepted hdmi2usb-fx2-firmware [amd64] (zesty-proposed) [0.0.0~git20151018-1]
[11:00] -queuebot:#ubuntu-release- New: accepted ixo-usb-jtag [amd64] (zesty-proposed) [0.0.0+git20160908-1]
[11:00] -queuebot:#ubuntu-release- New: accepted ocplib-simplex [i386] (zesty-proposed) [0.3-1]
[11:00] -queuebot:#ubuntu-release- New: accepted ocplib-simplex [ppc64el] (zesty-proposed) [0.3-1]
[11:00] -queuebot:#ubuntu-release- New: accepted r-bioc-mergeomics [amd64] (zesty-proposed) [1.2.0-1]
[11:00] -queuebot:#ubuntu-release- New: accepted casacore-data [amd64] (zesty-proposed) [1.0]
[11:00] -queuebot:#ubuntu-release- New: accepted dcm2niix [s390x] (zesty-proposed) [1.0.20161101-1]
[11:00] -queuebot:#ubuntu-release- New: accepted ocplib-simplex [amd64] (zesty-proposed) [0.3-1]
[11:00] -queuebot:#ubuntu-release- New: accepted ocplib-simplex [s390x] (zesty-proposed) [0.3-1]
[11:00] -queuebot:#ubuntu-release- New: accepted dcm2niix [i386] (zesty-proposed) [1.0.20161101-1]
[11:00] -queuebot:#ubuntu-release- New: accepted ocplib-simplex [powerpc] (zesty-proposed) [0.3-1]
[11:00] -queuebot:#ubuntu-release- New: accepted itamae [amd64] (zesty-proposed) [1.9.10-1]
[11:00] -queuebot:#ubuntu-release- New: accepted tendermint-go-rpc [amd64] (zesty-proposed) [0.0~git20161021.0.e6e3853-1]
[11:01] -queuebot:#ubuntu-release- New: accepted tendermint-go-config [amd64] (zesty-proposed) [0.0~git20160626.0.e64b424-1]
[11:01] -queuebot:#ubuntu-release- New: accepted zendframework [source] (zesty-proposed) [1.12.20+dfsg-1ubuntu1]
[11:02] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (yakkety-proposed) [3.175.1]
[11:05] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (xenial-proposed) [3.168.3]
[11:08] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-intel [source] (trusty-proposed) [2:2.99.910-0ubuntu1.7]
[11:11] -queuebot:#ubuntu-release- New binary: zendframework [amd64] (zesty-proposed/none) [1.12.20+dfsg-1ubuntu1] (no packageset)
[11:20] -queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (trusty-proposed) [2.10.95-0ubuntu2.5~14.04.1]
[11:24] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (trusty-proposed) [1:2014.1.5-0ubuntu8]
[11:43] -queuebot:#ubuntu-release- Unapproved: open-iscsi (xenial-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu3.2 => 2.0.873+git0.3b4b4500-14ubuntu3.3] (ubuntu-desktop, ubuntu-server)
[11:43] -queuebot:#ubuntu-release- Unapproved: open-iscsi (yakkety-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu8.1 => 2.0.873+git0.3b4b4500-14ubuntu8.2] (ubuntu-desktop, ubuntu-server)
[12:23] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-106.153] (core, kernel)
[12:24] -queuebot:#ubuntu-release- New binary: linux-signed-lts-vivid [amd64] (trusty-proposed/main) [3.19.0-78.86~14.04.1] (kernel)
[12:40] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-vivid [amd64] (trusty-proposed) [3.19.0-78.86~14.04.1]
[12:40] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-106.153]
[12:41] <slangasek> tjaalton: what was your standard of review for the apparmor SRU that I see has been accepted?
[12:42] <slangasek> infinity, bdmurray, stgraber: fyi ^^
[12:45] <stgraber> slangasek: not sure if infinity forwarded that comment to you, but shortly after you left yesterday, we figured that this actually needs to be tested with 3.2, 3.13 and 4.4 as precise is technically still supported, so someone may well be upgrading from 12.04 to 14.04 (possibly on the way to 14.04) and so will wind up running the new apparmor userspace with a 3.2 kernel, albeit briefly
[12:45] <stgraber> so need to ensure that we won't be getting LTS upgrade failures as a result of that
[12:47] -queuebot:#ubuntu-release- New binary: apache2 [ppc64el] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
[12:47] <tjaalton> slangasek: it was the newer upload, and didn't see anyone disapproving the backport itself
[12:48] <slangasek> tjaalton: ok, I'm asking what your standard of review was; because there was some discussion here at sprint about some of the potential problems with this SRU, so I want to understand what review you've already done and what if anything we should catch up on
[12:49] -queuebot:#ubuntu-release- New binary: apache2 [i386] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
[12:50] -queuebot:#ubuntu-release- New binary: apache2 [amd64] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
[12:51] -queuebot:#ubuntu-release- New binary: apache2 [s390x] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
[12:53] -queuebot:#ubuntu-release- New binary: apache2 [armhf] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
[12:53] -queuebot:#ubuntu-release- New binary: apache2 [powerpc] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
[12:53] <tjaalton> slangasek: the discussion should've been added to the bug, and/or package dropped from the queue again until a clear concensus was reached. the package diff itself wasn't reviewable as it was a backport. I'll remember not to touch core package backports anymore ;)
[12:54] <tjaalton> also, why do some diffs have also changes from the security uploads in them?
[12:54] <tjaalton> again makes reviewing changes harder than it should be
[12:55] <rbasak> Launchpad doesn't know what to diff against, AFAIK.
[12:55] <rbasak> We have some plans to make reviews from the unapproved queue much easier using the git importer. I just need to implement.
[12:55] <tjaalton> ok
[12:55] <rbasak> Then you can view a diff against anything
[12:58] <slangasek> tjaalton: I am asking you what your standard review has been *so that I know what we need to do to take it from here*.  It was a realtime discussion at the sprint and we did not get a chance to record anything in the bug
[12:58] <slangasek> so I'm asking now what you've done, so I don't need to duplicate effort
[12:59] <slangasek> I'm not saying you did anything wrong by reviewing it to your satisfaction, I'm saying we have additional context and want to get up to speed
[12:59] -queuebot:#ubuntu-release- New binary: apache2 [arm64] (zesty-proposed/main) [2.4.23-8ubuntu1] (ubuntu-server)
[13:02] <tjaalton> hang on
[13:02] <tjaalton> having network issues
[13:06] <tjaalton> browser froze :/
[13:09] <tjaalton> slangasek: looked at the bug, noticed it mentioned #1628285 and that the older upload was dropped because of changes for that bug, and a new one uploaded once it was decided those were not good for 1404
[13:13] -queuebot:#ubuntu-release- New: accepted apache2 [amd64] (zesty-proposed) [2.4.23-8ubuntu1]
[13:13] -queuebot:#ubuntu-release- New: accepted apache2 [armhf] (zesty-proposed) [2.4.23-8ubuntu1]
[13:13] -queuebot:#ubuntu-release- New: accepted apache2 [powerpc] (zesty-proposed) [2.4.23-8ubuntu1]
[13:13] -queuebot:#ubuntu-release- New: accepted apache2 [s390x] (zesty-proposed) [2.4.23-8ubuntu1]
[13:14] -queuebot:#ubuntu-release- New: accepted apache2 [arm64] (zesty-proposed) [2.4.23-8ubuntu1]
[13:14] -queuebot:#ubuntu-release- New: accepted apache2 [ppc64el] (zesty-proposed) [2.4.23-8ubuntu1]
[13:14] -queuebot:#ubuntu-release- New: accepted apache2 [i386] (zesty-proposed) [2.4.23-8ubuntu1]
[13:14] -queuebot:#ubuntu-release- New: accepted zendframework [amd64] (zesty-proposed) [1.12.20+dfsg-1ubuntu1]
[13:24] <slangasek> tjaalton: ok, thanks
[13:24] <tjaalton> slangasek: I'll double-check the diff now
[13:44] <xnox> Laney, i believe there was a dual intent in those s390x removals. it was not just about uninstalability, and not just about upstart, but to exclude/prevent ubuntu-desktop & ubuntu-touch because we do not support, nor want to build that, on s390x.
[13:44] <xnox> slangasek hopefully can clarify that on https://code.launchpad.net/~xnox/unity-greeter/no-s390x/+merge/312912
[13:44] <xnox> slangasek unless you want unity-greeter:s390x ?!
[13:46] <slangasek> xnox: do not want
[13:46] <slangasek> xnox: is that the answer you needed?
[13:48] <slangasek> xnox: however - do not want but would not block
[13:49] <xnox> Laney, ^
[13:52] <Laney> ubuntu-desktop is already not built
[13:52] <Laney> I don't think you want to go down the road of doing this at the individual package level
[13:52] <Laney> (or if you do, don't pick on one package at a time)
[13:53] <xnox> Laney, it's not in zesty, i do not want unity-greeter be stuck on bin new.
[13:53] <xnox> i'm not creating the change to remove s390x; i'm maintaining the status quo compared with yakkety.
[13:53] <xnox> (trying to)
[14:23] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-31.33] (core, kernel)
[14:50] -queuebot:#ubuntu-release- New source: sgt-launcher (zesty-proposed/primary) [0.2.1-0ubuntu1]
[15:47] -queuebot:#ubuntu-release- Unapproved: swift (yakkety-proposed/main) [2.10.0-0ubuntu1 => 2.10.0-0ubuntu1.1] (openstack, ubuntu-server)
[16:06] <infinity> xnox: There's some disagreement on the correctness of the status quo. :P
[16:23] -queuebot:#ubuntu-release- Packageset: 568 entries have been added or removed
[16:24] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.9.0-10.11] (core, kernel)
[16:38] -queuebot:#ubuntu-release- Unapproved: swift (xenial-proposed/main) [2.7.0-0ubuntu2 => 2.7.0-0ubuntu2.1] (openstack, ubuntu-server)
[17:39] -queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.7]
[17:40] -queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.7]
[17:44] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.6 => 0.122ubuntu8.7] (core)
[17:47] -queuebot:#ubuntu-release- Unapproved: isc-dhcp (xenial-proposed/main) [4.3.3-5ubuntu12.5 => 4.3.3-5ubuntu12.6] (core)
[18:15] -queuebot:#ubuntu-release- Unapproved: accepted ifupdown [source] (xenial-proposed) [0.8.10ubuntu1.2]
[18:21] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.8-49-g9e904bb-0ubuntu1~16.04.2]
[18:23] -queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (xenial-proposed) [2.0.873+git0.3b4b4500-14ubuntu3.3]
[18:31] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.7]
[18:32] -queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (xenial-proposed) [4.3.3-5ubuntu12.6]
[18:33] <rbasak> roaksoax, lamont, smoser, cyphermox: FYI ^
[18:44] <lamont> rbasak: WOOT!
[18:44] <lamont> thanks
[19:52] -queuebot:#ubuntu-release- New sync: libphp-jpgraph (zesty-proposed/primary) [1.5.2-13]
[20:07] -queuebot:#ubuntu-release- New sync: lnav (zesty-proposed/primary) [0.8.1-2]
[20:08] <elopio> slangasek: bdmurray: I'm sorry but Sergio is telling me from his holidays to ping you about the snapcraft SRU. It's ready, can you give us a hand releasing it?
[20:08] <elopio> https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1646993
[20:16] -queuebot:#ubuntu-release- New sync: opensips (zesty-proposed/primary) [2.2.2-2]
[20:22] -queuebot:#ubuntu-release- New sync: ciphersaber (zesty-proposed/primary) [1.01-2]
[20:25] -queuebot:#ubuntu-release- New sync: acorn (zesty-proposed/primary) [4.0.3-1]
[20:28] <slangasek> elopio: sorry, we don't release SRUs on Friday to avoid getting into the situation of having a regression that no one is around to sort out; and on this particular Friday I'm flying back from a sprint in the morning so it would be an especially bad idea
[21:43] <flocculant> xnox: xubuntu lost indicator-plugin since your change today, bug 1648889


[00:10] <sem> I'm testing out hexchat in lubuntu 24.04 and I cannot reproduce the typing bug
[00:17] <sem> how do I start Discover from the terminal? I am trying to test why it isn't opening in lubuntu 24.04
[00:20] <sarnold> try execsnoop-bpfcc in a terminal, click whatever it takes to launch discover, and see if you can spot an execution that looks like it
[00:23] <oerheks> 1st answer ... https://www.google.com/search?q=lubuntu+start+discover+from+terminal
[00:23] <oerheks> or ... try bing?
[00:26] <sem> you are good at searching. I just searched "lubuntu discover"
[00:26] <oerheks> and why starting a gui program from terminal..
[00:27] <sem> because it wont start from the GUI and I'm trying to find out why it is not working
[00:28] <sem> looks like it is called plasma-discover
[01:00] <sem> who is 'lubot' ?
[01:04] <oerheks> xliberabot ?
[01:05] <sarnold> lubot is an automaton that teward keeps chained up in his server rack
[01:05] <oerheks> some unofficial lurker, i guess
[01:05] <sem> sorry I should specify, lubot is a registered liber user
[01:05] <sem> libera
[01:05] <sem> ok :)
[01:06] <sem> In the liveISO environment, if you login to quassel with all the recommended settings, it tells you that lubot owns the nickname 'lubuntu'
[01:07] <sarnold> hah
[16:20] <lotuspsychje> falkon working again


[09:13] <Berge> maswan: well, UMU is more familiar to me than KTH is, probably due to that name being exposed here and there in DNS
[09:25] <maswan> yup, but it is awful that something under umu.se is not properly vetted information from the university itself
[09:26] <maswan> the university vision is a sterile glossy pamphlet of university wonderfulness
[09:26] <maswan> and not a living virtual campus with all the beautiful weird stuff that students and staff can come up with
[10:37] <Berge> maswan: This reminds me of my local uni's change some years ago, where they wouldn't give network connectivity to student orgs anymore, since "the ntnu.no name would appear in traceroute"
[14:03] <Teridon> trying to mirror focal and bionic repos. it has worked successfully in the past (though it's been ~ 3 months since I've tried), but now I'm getting a GPG key error for all mirrors.  e.g.:   https://dpaste.org/jpO5Z
[15:35] <Teridon> FWIW, the problem I have is on focal.  I switched to running aptly on a bionic system and it's working without issue.  I'd still like the fix the issue on the focal server.
[17:40] <sarnold> Teridon: the openpgp community has basically abandoned the sks keyservers after https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
[17:42] <sarnold> Teridon: try grabbing them from keyserver.ubuntu.com ; I doubt that'll actually help, but that's running a newer keyserver software that's less annoying
[17:58] <Teridon> I did try that.. (see dpaste ).  It says "not changed"
[18:02] <sarnold> ah sorry I only saw the sks-keyserver and jumped to conclusions from that


[06:42] <Christoffer12345> Hi, I'm having some trouble setting up active directory sign in. I upgraded from 22.04 LTS to 23.04 to test it. To install and configure I used "sudo apt install libpam-aad libnss-aad", "sudo pam-auth-update --enable mkhomedir", and "sudo nano /etc/aad.conf". After rebooting I can only sign in as my previous user "rfids". There doesn't seem to be
[06:42] <Christoffer12345> any way to click on something for "change user" or "cannot see your user?". Does anyone know if I did something wrong or maybe the feature isn't ready yet?
[06:42] <Christoffer12345> This is what I found in the logs
[06:42] <Christoffer12345> rfids@rfids-c60150020:~$ sudo journalctl | grep _aad
[06:42] <Christoffer12345> [sudo] password for rfids:
[06:42] <Christoffer12345> Jul 04 15:15:02 rfids-c60150020 sshd[1722]: pam_aad(sshd:auth): try to authenticate "rfids" from cache
[14:04] <lubDock> hi
[14:05] <lubDock> I have an issue, I'm trying to mount the virtualbox share folder but I can't, any link or idea ?


[03:02] <LPCIBot> Project devel build #1,010: STILL FAILING in 4 hr 5 min: https://lpci.wedontsleep.org/job/devel/1010/
[03:32] <nigelb> Just when I thought I had great success in not breaking a truckload of tests with an MP, it fails buildbot.
[03:39] <wgrant> jelmer: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1313/steps/shell_6/logs/stdio <- your fix yesterday may be flaky.
[03:39] <wgrant> Forcing.
[03:58]  * wgrant vomits
[03:58] <wgrant> httplib2 has its own certificate store.
[04:05] <wgrant> What is wrong with being sensible :(
[05:21] <stub> wiki says wgrant or gmb is review bitch. Any chance of https://code.launchpad.net/~stub/launchpad/pgbouncer-fixture/+merge/73283 ?
[05:21] <nigelb> heh, review bitch.
[05:22] <wgrant> stub: Hm, changing to TCP connections?
[05:23] <wgrant> Ah, I see, you don't want to overwrite the config.
[05:23] <wgrant> We really need to fix lazr.config to not suck for this.
[05:24] <wgrant> stub: Why are you overriding PGHOST?
[05:24] <stub> wgrant: Because otherwise it will connect using UNIX sockets, and fail as the pgbouncer package does not (yet) set unix_socket_dir so they don't work.
[05:25] <wgrant> stub: But you've set host=localhost in the connection strings.
[05:25] <wgrant> stub: So setting PGHOST=localhost sounds redundant.
[05:25] <stub> wgrant: I probably won't bother changing it either, as this better represents production
[05:25] <stub> wgrant: It might be redundant now, yes.
[05:25] <wgrant> stub: Also, you can hopefully use self.useFixture instead of self.addCleanup and setUp.
[05:26] <stub> That sounds good.
[05:26] <wgrant> I think the base Fixture from fixtures should support that.
[05:26] <stub> Do you want me to pull the PGHOST bit if it is redundant, or leave it since it might be useful in the future if I do what I don't think I'm going to do?
[05:27] <wgrant> stub: I think you should pull it out.
[05:27] <wgrant> We have more than 650KLOC already. Let's not add more.
[05:28] <stub> pypi has terrible google juice
[05:28] <wgrant> py* has terrible lots of things.
[05:29] <wgrant> stub: I don't think this is going to interact stunningly with PgTestSetup.
[05:29] <wgrant>                 # Stash the name we use in the config if a writable config is
[05:29] <wgrant>                 # available.
[05:30] <wgrant>                 # Avoid circular imports
[05:30] <wgrant>                 section = """[database]
[05:30] <wgrant> rw_main_master: dbname=%s
[05:30] <wgrant> rw_main_slave:  dbname=%s
[05:30] <wgrant> Why yes, that is revolting.
[05:31]  * stub wonders how it is working atm
[05:31] <wgrant> Possibly PGHOST :)
[05:31] <stub> ahh... yes :-)
[05:32] <wgrant> 213	+ # Database is still working.
[05:32] <wgrant> 214	+ assert self.is_connected()
[05:32] <wgrant> s/still working/working again/
[05:40] <stub> Pushing with those changes.
[06:14]  * stub wonders why the ec2 image doesn't upgrade its own packages
[06:18] <stub> Anyone around setup to update the ec2 test image?
[06:18] <stub> Just need launchpad dependency packages updated
[06:22] <jtv> stub: I thought it did upgrade… anyway, I should be able to do that.
[06:23] <wgrant> It doesn't :(
[06:23] <wgrant> stub: What needs updating? It was last rebuilt a week ago.
[06:23] <jtv> Meanwhile, does anybody have any idea what the current crop of codehosting buildbot failures is all about?
[06:23] <stub> Seems simple enough, but I don't want to run an hour long process right at the moment and might not have perms on ec2 either.
[06:24] <stub> wgrant: Just pull in the newly build launchpad dependencies
[06:24] <wgrant> jtv: I poked jelmer about them, as they might be related to the stuff he's landed recently.
[06:24] <stub> c/build/built
[06:24] <stub> launchpad-developer-dependencies
[06:24] <jtv> wgrant: he may have landed something unfinished… I also noticed a lot of recent lint in his name.
[06:24] <wgrant> stub: pgbouncer needs a list of users to let through?
[06:25] <stub> wgrant: yes
[06:25] <wgrant> stub: What about *_ro and read?
[06:25] <wgrant> stub: Or are we just going to hope no test that uses them ever goes near the fixture?
[06:26] <stub> wgrant: I'll need to add them too.
[06:26] <jtv> StevenK: your AMI rev. 519 is the current, valid image?
[06:26] <wgrant> jtv: He's on leave, but yes.
[06:26] <wgrant> It was created last week.
[06:26] <jtv> thanks
[06:27] <stub> read isn't a user though, so don't need that one added.
[06:28] <jtv> BTW, why do we use a 64-bit AMI?  I can't imagine any of our test processes needing more than 3GB address space, and I thought x86 was likely to be faster than amd64 for python.
[06:29] <stub> Because we run 64bit on production
[06:30] <wgrant> Right, production is mostly amd64.
[06:30] <wgrant> i386 tests are quite a bit faster, because RAM usage is roughly halved.
[06:30] <wgrant> So you get tonnes of extra cache.
[06:55] <jtv> wgrant: looking into gina domination a bit more.  Do I understand correctly that we want to mark SPPHs that have been superseded by newer publications of the same package as superseded, even if the package has subsequently "fallen out of" the Debian Sources lists?
[07:00] <wgrant> jtv: Ideally. But that's probably only a problem for the first time, so we could do it as a one-off.
[07:00] <jtv> Well it happens to be what the dominator already does.  It's just buried among heaps of other code.
[07:01] <jtv> It also looks like it could be made much faster if it had to.
[07:04] <jtv> wgrant: by the way, it looks like you're OCR today.  In which case: https://code.launchpad.net/~jtv/launchpad/bug-836743/+merge/73267 plz?
[07:04] <wgrant> The archivepublisher dominator should take <5s per context now.
[07:04] <wgrant> Once we finish denorming SPN onto SPPH it will be trivial time.
[07:05] <wgrant> jtv: However, we already know what's not published any more, so I think using the dominator in the normal case is pointless.
[07:06] <wgrant> jtv: Looking at that review now.
[07:06] <jtv> Except we still need domination done—might as well.
[07:06] <jtv> Thanks.
[07:06] <wgrant> jtv: Why?
[07:07] <wgrant> Apart from the initial run, the algorithm is as I outlined in the bug.
[07:07] <jtv> Because we don't want to keep keeping Debian SPPHs in unjustified active statuses.
[07:07] <wgrant> The dominator will not match what Debian does.
[07:07] <jtv> In what way?
[07:08] <wgrant> Debian does not handle superseded packages quite as Ubuntu does.
[07:08] <wgrant> Superseded sources are kept around in the indices until they are unreferenced.
[07:08] <wgrant> By binaries, that is.
[07:09] <jtv> Yes, but doesn't that mean they're still superseded?
[07:09] <jtv> There is a difference between "superseded" and "deleted" after all.
[07:09] <wgrant> That's something that is not clear.
[07:09] <wgrant> Julian argues that anything in the indices is by definition not superseded.
[07:10] <LPCIBot> Project devel build #1,011: STILL FAILING in 4 hr 7 min: https://lpci.wedontsleep.org/job/devel/1011/
[07:12] <wgrant> Soyuz currently works under the assumption that (in the indices == published).
[07:12] <wgrant> I've argued that that should be changed, to allow us to gain Debian's enhanced supersededness stuff. But I don't think now is the time to be violating or changing that assumption.
[07:13] <jtv> Isn't that what we have pockets for?  I imagine it's a valid assumption for ubuntu exactly because we don't do it that way.
[07:13] <wgrant> We want to do it that way.
[07:13] <wgrant> There's a critical bug for it.
[07:13] <wgrant> It's unrelated to pockets.
[07:15] <wgrant> jtv: Branch looks good.
[07:15] <jtv> Thanks.  So in the future we want to keep multiple SPPHs "published" for the same source package name, distroseries, and pocket?
[07:17] <wgrant> We want to keep multiple SPPHs with the same context (archive, distroseries, pocket) and name in the indices. It's not clear whether that means we should leave the status as Published.
[07:18] <wgrant> I've traditionally argued that we shouldn't leave the status as published, but it has been a point of significant contention.
[07:20] <wgrant> jtv: Does anybody use launchpad_langpack on staging these days?
[07:21] <wgrant> # - Run Langpack ((re)-create a langpack DB that the
[07:21] <wgrant> #   translations team can use for testing.
[07:21] <jtv> That's very very old, and we used to use it even for production tarballs sometimes.  Today, we may still want it for Q/A.
[07:22] <wgrant> That sounds within tolerances of "no".
[07:22] <jtv> I don't know because I've been on Soyuz feature "rotation" since two interglacials ago.
[07:22] <wgrant> Megafeature :)
[07:23] <jtv> Scope creep.  It's the difference between your burndown rate and your burnout rate.
[07:23] <wgrant> Well, it also should have been split into at least three separate features from the start :(
[07:24] <jtv> In a way, it was.  They just kept being piled into the same feature rotation.
[07:24] <wgrant> Well, yes, that's what I meant.
[07:25] <jtv> Anyway, about the superseding of source publications: what would determine for Ubuntu whether a package is still in the Sources list?  Where would that information be kept?
[07:25] <wgrant> datepublished IS NOT NULL AND dateremoved IS NOT NULL
[07:27] <wgrant> Actually, probably datepublished IS NOT NULL AND datemadepending IS NOT NULL
[07:27] <wgrant> (datemadepending is the date it was scheduled for deletion, not the date it was made pending, because 2005 hates us)
[07:29] <adeuring> good morning
[07:29] <jtv> hi adeuring
[07:29] <adeuring> hi jtv!
[07:30] <jtv> wgrant: it sounds to me then as if domination should be fixed to handle that uniformly for debian, ubuntu, and derivatives; and gina should merely be updated to set those date fields.
[07:31] <wgrant> jtv: Possibly, but that is feature scale work.
[07:32] <jtv> Possibly, but then I don't see why I should solve that problem for just Debian right now in a short-term branch.
[07:33] <wgrant> I don't think it makes sense to run a dominator over an imported archive, since it is archive publishing logic. The imported archive has the information we need right now. When we remove the (in indices <=> published) invariant, that may have to change.
[08:25] <jml> http://flossmole.org/content/everything-you-ever-wanted-know-about-software-forges-code-forges-june-2011
[08:25] <jml> interesting link
[08:25] <nigelb> that's a long URL.
[08:25] <nigelb> (twss, yeah I know)
[08:27] <nigelb> Ooh, interesting cloud.
[08:28] <wgrant> LP apparently doesn't have announcements.
[08:28] <nigelb> It does. Right?
[08:28] <nigelb> The RSS thing that pops in the right corder of a project.
[08:28] <wgrant> Yes.
[08:29] <wgrant> Intriguingly, Trac is included as a feature in the feature matrix.
[08:29] <jelmer> wgrant: hi
[08:30] <wgrant> Hm, I thought we still provided DOAP.
[08:30] <wgrant> Maybe we dropped that.
[08:33] <mrevell> Hello
[08:34] <nigelb> Wasn't someone talking about having javascript OOPSes?
[08:34] <nigelb> I just saw this http://errorception.com
[08:35] <nigelb> I don't know how it works, but apparently some kind of OOPS system. Paid for though :|
[08:38] <jml> mrevell: hi
[08:52] <jelmer> wgrant: it looks like the failing test was one that was flapping earlier, which supposedly should be fixed by the introduction of the newer Twisted
[09:00] <wgrant> jelmer: Yeah, I thought it could have been that :(
[09:01] <wgrant> But since you'd touched that area recently, I thought I might as well see if you had any thoughts or fault :)
[09:01] <bigjools> wgrant: thanks for the utf8 fix
[09:02] <bigjools> not sure wtf the extra blank lines are coming from but it's not exactly important
[09:02] <wgrant> bigjools: The iterator probably stops at the start of the next entry.
[09:03] <wgrant> bigjools: You can probably sensibly just call strip() on the changelog string.
[09:03] <bigjools> as for the person/date line... that would need a change in python-debian methinks.
[09:03] <bigjools> yeah, I was considering using strip but it might also be in the template
[09:03] <wgrant> bigjools: python-debian doesn't give you access to the various components of the entry?
[09:03] <wgrant> bigjools: gina does it somehow.
[09:03] <wgrant> Although it has its own parser.
[09:03] <bigjools> gina has its own parser
[09:04] <wgrant> Heh.
[09:04] <bigjools> it's do-able, but the right place is in python-debian
[09:04] <bigjools> aha
[09:04] <bigjools> I can do block.changes() I tihnk
[09:05] <wgrant> bigjools: You could also set _no_trailer on the block.
[09:05] <wgrant> Then __unicode__ won't include that line.
[09:05] <wgrant> Hah.
[09:05] <bigjools> unicode?
[09:05] <wgrant> Rather than using the utf-8 stuff, use unicode() instead of str()
[09:05] <wgrant> Its __str__ just calls __unicode__
[09:05] <bigjools> unicode... what unicode :)
[09:05] <bigjools> which python-debian do you have?
[09:06] <wgrant> Ah, I'm on oneiric.
[09:06] <wgrant> Let's see lucid...
[09:06] <bigjools> ;)
[09:06] <wgrant> Package `python-debian' is not installed.
[09:06] <wgrant> Huh.
[09:06] <wgrant> Oh.
[09:06] <wgrant> We still use the one in sourcecode/
[09:06] <bigjools> :(
[09:07] <wgrant> We should update that and use proper unicode :)
[09:07] <wgrant> Although that one does still support _no_trailer.
[09:07] <bigjools> I love the way that the API expects you to poke private variables to change behaviour
[09:08] <wgrant> You're not meant to poke them from the outside.
[09:08] <wgrant> We're just doing unexpected things.
[09:08] <wgrant> I'm not sure about your use of _raw_version either, but meh.
[09:08] <bigjools> well, quite
[09:08] <bigjools> the api is a bit rubbish
[09:09] <bigjools> looks like I can just set _no_trailer then
[09:19] <bigjools> wgrant: instead of decoding the utf8 in fetch_information it seems to make more sense to do it in aggregate_changelog
[09:23] <wgrant> bigjools: Probably.
[09:23] <wgrant> bigjools: I just did it there to get it unbroken.
[09:23] <bigjools> np
[09:38] <henninge> AFICT wer are in a good position for a stable deploy, aren't we?
[09:38] <henninge> both rollbacks have landed.
[09:39] <wgrant> henninge: Yes.
[09:39]  * henninge goes about starting that.
[09:39] <wgrant> Once danilos' QA is done.
[09:39] <danilos> wgrant, was it not done?
[09:39] <wgrant> Not a few hours ago when I last checked the deployment report.
[09:39] <henninge> danilos, wgrant: all green
[09:39] <wgrant> So it is.
[09:40] <nigelb> hmm, I should do QA!
[09:40] <wgrant> doit
[09:40] <nigelb> or should I?
[09:40]  * nigelb didn't didn't see a tag show up.
[09:41] <wgrant> nigelb: It should be there in 20 minutes or so.
[09:41] <wgrant> Actually, I'm behind. May have been there 10 minutes ago...
[09:41] <nigelb> Ahh.
[09:42] <wgrant> Revision 13818 can not be deployed: needstesting
[09:42] <wgrant> Assignee: nigelbabu
[09:42] <nigelb> *whee*
[09:42]  * wallyworld just got power back on after a 90 minute power outage :-(
[09:42]  * nigelb QAs
[09:42] <nigelb> FUUUUU
[09:42] <nigelb> I wasn't subscribed.
[09:42] <nigelb> Why does assigning the bug to myself not auto-subscribe me :x
[09:44] <wgrant> You won't be explicitly subscribed, but you'll still get notifications.
[09:44] <nigelb> Ha, 13 minutes ago.
[09:44] <bigjools> wgrant: can you think of any good reason why I should not make makeChangelog return a unicode changelog?
[09:44] <nigelb> No wonder.
[09:44] <wgrant> bigjools: No.
[09:45] <wgrant> bigjools: There's little place for bytestrings in LP.
[09:45] <bigjools> good answer :)
[09:45]  * bigjools does the file encoding trick
[09:45] <wgrant> Hm?
[09:46] <bigjools> # -*- coding: utf-8 -*-
[09:46] <wgrant> Why?
[09:47] <StevenK> That's an emacs hint
[09:47] <bigjools> no it's not
[09:47] <nigelb> isn't that a vim hint?
[09:47] <wgrant> Python hint.
[09:47] <bigjools> it's a PYthon hint
[09:47] <wgrant> That's the critical bit.
[09:47] <wgrant> However, it's probably overkill.
[09:47] <wgrant> What do you think you are up to?
[09:47] <nigelb> QA'd
[09:47] <bigjools> I've had this conversation before
[09:48] <bigjools> If I want to type human-readable unicode in Python source I need that
[09:48] <wgrant> bigjools: Oh, this is for a test?
[09:48] <wgrant> I guess that's OK then.
[09:48] <bigjools> in factory.py
[09:48] <bigjools> but yes
[09:48] <bigjools> see the top of test_ppauploadprocessor.py for example
[09:49] <lifeless> wgrant: A hint for you with fixtures: useFixture is the bomb.
[09:49] <wgrant> lifeless: Didn't I just suggest that to stub? :)
[09:49] <lifeless> I may have missed that
[09:49] <wgrant> 15:25:55 < wgrant> stub: Also, you can hopefully use self.useFixture instead of self.addCleanup and setUp.
[09:49] <lifeless> I was going off of the MP thread.
[09:49] <wgrant> I am not guilty.
[09:49] <wgrant> Ah.
[09:50] <wgrant> I felt some of the issues needed discussion, so did it on IRC instead.
[09:50] <lifeless> something I like doing after IRC discussion is to paste that into the MP
[09:51] <wgrant> Probably should have, yeah. Will do so in future.
[09:53] <wgrant> bigjools: You prefer using coding: utf-8 over \N{SNOWMAN}?
[09:53] <bigjools> hell yes
[09:53] <wgrant> Bah.
[09:56]  * jelmer wonders how you would type non-ascii characters on a UK keyboard
[09:56] <lifeless> ♯
[09:56] <nigelb> buy a new keyboard!
[09:56] <nigelb> Actually there's a character map thing somewhere you can use :)
[09:56] <wgrant> jelmer: Compose keys solve everything.
[09:56] <wgrant> Except for in oneiric, where I can't work out how to configure one...
[09:57] <wgrant> GNOME 3 wins.
[09:58] <jelmer> OTOH, the special keys handling dialog in GNOME2 excelled in being complex and confusing...
[09:58] <wgrant> Yeah.
[09:58] <wgrant> But I can't find anywhere to configure keyboard layouts at all any more.
[09:59] <cjwatson> it *was* originally an Emacs hint.  Python just appropriated it.
[09:59] <wgrant> In fact, the new gnome-control-center seems to take GNOME policy to the extreme and delete most of the options.
[10:00] <jelmer> wgrant: yeah
[10:01] <wgrant> Or perhaps Ubuntu's Language Support button has replaced the GNOME 3 regional settings one or something.
[10:03] <nigelb> Meh. I should just stop. Not helping.
[10:04] <jelmer> nigelb: hmm?
[10:04] <wgrant> #launchpad, I presume.
[10:04] <nigelb> YEah.
[10:04] <wgrant> cheater is right, our UI is terrible, and attempting to argue otherwise is probably silly :)
[10:04] <wgrant> LP was designed in a different era, and was never pulled out of it.
[10:04] <nigelb> heh, I agree with that. BUt its not /that/ terrible.
[10:05] <wgrant> It is to people who haven't used it before.
[10:05] <wgrant> And even to those that have it is cluttered and awkward.
[10:05] <nigelb> Also, I'm trying to say how the UX is different from other similar services.
[10:05] <wgrant> And does not provide dashboards or anything else that contemporary social applications have.
[10:05] <nigelb> I failed at that spectacularly.'
[10:05] <wgrant> It is a good point, but difficult to argue successfully.
[10:06] <nigelb> What would it take to build a dashboard like approach?
[10:06] <jelmer> dashboards would be really nice, especially given we track not just stuff on launchpad but elsewhere as well.
[10:06] <wgrant> Ahahah
[10:06] <nigelb> Besides lots of crying.
[10:09] <nigelb> btw, no StevenK these days?
[10:09] <wgrant> StevenK is away this week.
[10:09] <nigelb> Or is he using perl to delete large parts of launchpad in secret.
[10:09] <wgrant> Well, not away, but not meant to be here.
[10:09] <nigelb> wgrant: Like you were a few weeks back.
[10:10] <wgrant> Shh.
[10:22] <nigelb> Bad metaphors need to be shot down.
[10:22] <jml> nigelb: shot down from where?
[10:22] <StevenK> jml: WRT Facebook and Google+, congrats!
[10:23] <jml> StevenK: thanks :D
[10:23] <nigelb> jml: oh yeah! Congrats!
[10:23] <jml> nigelb: cheers :)
[10:23] <StevenK> jml: Pictures of the ring are *required*
[10:23] <nigelb> jml: I'm adding my comments to the discussion in the other channel.
[10:23] <nigelb> StevenK: haha, I just realized, I did pictures of the ring with which you proposed :D
[10:23] <StevenK> nigelb: You did?
[10:23] <jml> nigelb: was being witty, "shot down" is itself a metaphor
[10:24] <nigelb> jml: haha. Damn. I fail at my own joke :)
[10:24] <jml> or maybe that's what you meant
[10:24] <nigelb> StevenK: Yeah, #ubuntu-women ^-^
[10:24] <nigelb> back then.
[10:30] <bigjools> I need unicode help :(
[10:30] <bigjools> whenever I have to do unicode in Python, I get frustrated
[10:31] <bigjools> wgrant: do you know the appropriate runes to get makeChangelog working with a unicode changelog? the librarian addFile keeps blowing chunks on me
[10:32] <jml> bigjools: Python makes it really hard.
[10:32] <bigjools> jml: it does :(
[10:32] <wgrant> bigjools: You'll need to encode the changelog before you pass it to makeLFA
[10:32] <jml> bigjools: you should see the insane stuff mgz has done to get testtools have proper unicode handling.
[10:32] <bigjools> wgrant: I am, it still bitches
[10:32] <wgrant> bigjools: Bitches how?
[10:32] <bigjools> UnicodeEncodeError: 'ascii' codec can't encode character .... blah
[10:32] <wgrant> jml: Python 3's sort of much better, though.
[10:32] <wgrant> bigjools: What is your .encode invocation?
[10:32] <bigjools> jml: I can well imagine
[10:33] <jml> wgrant: yeah. it's the cross-Python support that makes it hard. Would be better with actual real honest-to-goodness types, and banning the word "string"
[10:33] <bigjools> content=changelog.decode("utf-8")
[10:33] <wgrant> bigjools: encode.
[10:33] <bigjools> ffs
[10:34] <wgrant> jml: Yeah, I think they designed stuff like the bytes backports to 2.6 just to make everyone's lives hell.
[10:34] <wgrant> I use "backports" loosely.
[10:34] <jml> heh. yeah.
[10:34] <wgrant> I end up mostly resorting to casting everything to bytearray instead.
[10:34] <wgrant> Which actually has consistent behaviour...
[10:35] <bigjools> this is just utterly confusing
[10:35] <wgrant> bigjools: Oh?
[10:35] <wgrant> bigjools: You were going completely the wrong way before.
[10:36] <bigjools> encode/decode/unicode etc
[10:36] <wgrant> That's not Python, it's just people being stupid and not using Unicode everywhere.
[10:36] <bigjools> I'm confused about whenI need to use encode and decode
[10:36] <wgrant> If your data is not binary or UTF-8, you are wrong.
[10:37] <wgrant> bigjools: Librarian files are bytestreams. You need to encode before you put data into an LFA, and decode once you get it out.
[10:37] <wgrant> Because Python 2 doesn't do text files.
[10:39] <wgrant> jml: How's the world of app development, anyway?
[10:40] <wgrant> Hopefully not too much Python unicode support.
[10:40] <jml> wgrant: fun! I have a spec :)
[10:40] <jml> wgrant: https://blueprints.launchpad.net/developer-portal/+spec/automagic-binary-packaging
[10:41] <jml> unicode support only matters insofar as a testtools release would help me and many others at Canonical get things done faster
[10:41] <wgrant> This reminds me... I must work out what is up with poppy-sftp's logging tomorrow.
[10:41] <wgrant> bigjools: Have you touched that at all?
[10:41] <wgrant> bigjools: It's completely screwed.
[10:42] <bigjools> wgrant: no, not at all
[10:42] <nigelb> So, codeswarm for Launchpad was fun watching.
[10:42] <wgrant> bigjools: Normally doesn't log anything, except when you log something explicitly, then it starts logging everything 50-60 times.
[10:42] <wgrant> and you can actually see exceptions that occur.
[10:42] <wgrant> After three recursion depth exceeded errors in the log handler.
[10:42] <bigjools> I remember that happening when I was adding ftp support, then it went away
[10:43] <bigjools> never got to the bottom of it
[10:43] <nigelb> jml: Hows your day job? :)
[10:44] <StevenK> nigelb: Do you have it for Launchpad?
[10:44] <wgrant> jml: So we're going for widespread package-all-the-things before we have sandboxing, or are we hoping sandboxing will be practical before this is mature?
[10:44] <nigelb> StevenK: Yes.
[10:44] <StevenK> nigelb: Can haz?
[10:44] <nigelb> StevenK: http://www.youtube.com/watch?v=9Pe70fw83Zs
[10:45] <jml> wgrant: more the latter
[10:45] <nigelb> Lots of lifeless floating around ;)
[10:45] <jml> wgrant: for commercial apps, which is my focus for now, we are already operating without sandboxing in much the same way that we do with partner or the things currently in the software center
[10:46] <wgrant> jml: Yeah, but I don't think that can scale while maintaining responsiveness.
[10:46] <jml> wgrant: agreed.
[10:46] <nigelb> jml: I love your work, except for the bits where its limited to one arch :(
[10:46] <nigelb> (well, for now)
[10:46] <jml> nigelb: we're moving up to two!
[10:46] <nigelb> oooh \o/
[10:46]  * bigjools weeps at having 4 cores which doesn't help when everything bottlenecks on disk
[10:46] <jml> wgrant: I think sandboxing is the next step.
[10:47] <wgrant> jml: It should have been the next step for about 15 years, but yeah :)
[10:47] <nigelb> heh
[10:47] <wgrant> bigjools: tmpfs + LXC + 6 parallel test runs makes good use of cores.
[10:47] <cjwatson> sandboxing's already nearly practical - see arkose
[10:48] <cjwatson> (I'm sure jml knows about that already)
[10:48] <wgrant> Yeah, it's getting there.
[10:48] <jml> yeah, I do.
[10:48] <bigjools> wgrant: I used to run parallel tests using kvm but really, everything bottlenecks on disk.
[10:48] <cjwatson> it's good enough for skype, which is pretty damn good
[10:48] <jml> Although haven't had the play with Arkose that I'd like to.
[10:48] <cjwatson> (the above is not to be taken to mean "skype is pretty damn good")
[10:48] <bigjools> I know tmpfs is supposed to help but I still struggled to speed it up
[10:48] <jml> Might do that today, actually, since most of it's consumed by long weekend email recovery
[10:49] <nigelb> cjwatson: I can see the tabloids "Ubuntu developer says skype is damn good!"
[10:49] <wgrant> bigjools: Which is why I implemented the LXC-based system that lifeless and I have tested. Have a single base chroot, then start 6 COW guests using aufs on tmpfs.
[10:49] <wgrant> bigjools: All writes go to tmpfs, and the chroot cache is shared between all of them.
[10:49] <wgrant> It was entirely CPU bound when I tried it.
[10:49] <bigjools> excellent
[10:50] <nigelb> I need a new machine.
[10:50] <nigelb> 2 cores is now old.
[10:50] <bigjools> my 4 core is a Phenom, a bit old
[10:50] <nigelb> Buddy of mine got an 8-core. Runs gentoo one it and says he has great build times.
[10:50] <bigjools> the i5 feels quicker, even though it only has 2 (although has the pseudo extra 2)
[10:51] <nigelb> (I repllied with "I use Ubuntu, no build time on my laptop at all!")
[10:51] <bigjools> gentoo users are weird people :)
[10:51] <nigelb> haha
[10:52] <nigelb> jml: that spec looks scary - so.many.items!
[10:53] <jml> nigelb: I like having lots of small items.
[10:53] <jml> nigelb: gives me illusions of control and progress.
[10:53] <nigelb> Ah, they're small.
[10:53] <wgrant> Far easier to feel that you're making progress that way.
[10:53] <nigelb> I have like one item from UDS that's going to take 2 cycles to do.
[10:54] <nigelb> Hmm, https://myapps.developer.ubuntu.com/dev/ looks slick. Except I had to read about it on Rick's blog.
[10:54] <nigelb> I wish ISD blogged on the planet.
[10:55] <G> anyone got a second to talk about a bug, and a possible bug?
[10:56] <G> err a possible patch that is :)
[10:57] <nigelb> "patch" - the magic word!
[10:57] <nigelb> G: Actually, you should just talk about it and someone will respond
[10:57] <G> nigelb: yeah, well my fingers were a timezone behind my brain :)
[10:58] <nigelb> I know that feeling well :)
[10:58] <G> Anyway, I spotted https://bugs.launchpad.net/launchpad/+bug/837290 last night and thought "that looks wrong", I took a look/poke at the Javascript tonight, and think I have isolated the issue
[10:58] <_mup_> Bug #837290: When there is no "Other bug subscribers" incorrect descriptive text is displayed <Launchpad itself:New> < https://launchpad.net/bugs/837290 >
[11:00] <G> What I seem to have isolated it to, is in lib/lp/app/javascript/subscribers/subscribers_list.js the function combines a set of config variables passed to it, with defaults if not set elsewhere
[11:01] <G> (~ line 75 of current devel branch)
[11:01] <G> but the SubscribersList function/module gets called using the uncombined config parameters
[11:01] <G> which results in items such as 'subscribers_label' ending up, undefined
[11:03] <nigelb> That's a real narrow situation. Nice catch :)
[11:03] <bigjools> wgrant: can you sanity check please: http://pastebin.ubuntu.com/677885/
[11:04] <G> nigelb: my thought exactly :)
[11:04] <G> I came up with http://pastebin.ubuntu.com/677887/ as a working patch
[11:06] <wgrant> bigjools: I guess.
[11:07] <nigelb> G: I don't know if it works, but if you propose a merge, you can ask the oncall reviewer to look at your MP and review/land.
[11:08] <G> I'm going by https://dev.launchpad.net/FixBugs which says discuss first
[11:08] <nigelb> mmm
[11:08] <nigelb> I forgot about that one.
[11:08] <G> but yeah, I was planning on going the MP route, but wanted to cehck my logic first
[11:08] <wgrant> bigjools: I don't really like making all the tests unicode like that, but I guess it's fine :)
 If your data is not binary or UTF-8, you are wrong.

[11:10] <bigjools> "Did you ever get an email from your friends in Bulgaria with the subject line "???? ?????? ??? ????"?"
[11:10] <bigjools> lol
[11:10] <wgrant> bigjools: By "making all the tests unicode" I mean "using non-ASCII characters just because, which makes the tests ugly"
[11:10] <bigjools> if it sweeps out decode errors in production, I don't care!
[11:10] <G> the other thing I'm wondering is if lines 79 & 81 are actually needed at all because everything seems to be 'config.something' not 'this.something'
[11:12] <wgrant> bigjools: Still, whenever I see bad Unicode code in LP, I just think to myself "at least it isn't lp.services.encoding.ascii_smash()", and then I feel better.
[11:12] <G> (actually, ignore that last line)
[11:13] <wgrant> bigjools: (bug #362957)
[11:14] <bigjools> ascii_smash is ....
[11:15] <wgrant> Broken and has no cause to exist.
[11:16] <bigjools> the bug reporter's name made me laugh.  I think I am a bit evil.
[11:16] <wgrant> MIME solved Unicode in emails in 1996 :/
[11:16] <wgrant> Heh.
[11:16] <wgrant> I haven't seen him around in a while.
[11:16] <wgrant> Hmm, only archiveuploader and soyuz.adapters.notifications use ascii_smash.
[11:16] <wgrant> Maybe we can delete it.
[11:17] <bigjools> it should be easy
[11:17] <wgrant> def safe_fix_maintainer(content, fieldname): """Wrapper for fix_maintainer() to handle unicode and string argument.
[11:17] <wgrant> It verifies the content type and transform it in a unicode with guess() before call ascii_smash(). Then we can safely call fix_maintainer(). """
[11:17] <wgrant> Convert to Unicode just so you can ascii_smash it.
[11:17] <wgrant> YAY
[11:17] <cjwatson> I filed a bug about that about four years ago :)
[11:18] <cjwatson> I mean, about ASCII-smashing on uploader names in upload announcements
[11:18] <wgrant> Bug #33137
[11:18] <wgrant> https://bugs.launchpad.net/launchpad/+bug/33137
[11:18] <cjwatson> it got unfixed
[11:19] <wgrant> I think for Changes it's still fixed.
[11:19] <cjwatson> see e.g. https://lists.ubuntu.com/archives/oneiric-changes/2011-August/005861.html
[11:19] <wgrant> Only for addresses is it still insane.
[11:19] <bigjools> mails from syncs should be ok
[11:19] <wgrant> bigjools: lol
[11:19] <bigjools> ?
[11:19] <bigjools> there are tests to preserve the From address
[11:19] <wgrant> bigjools: They still use the ascii_smash codepath.
[11:20] <bigjools> hmm it must be a weird corner case then
[11:20] <wgrant> cjwatson: You have to remember that the LP team will only do the absolutely minimal fix.
[11:20] <wgrant> cjwatson: Not the sensible one.
[11:20] <wgrant> :)
[11:20] <bigjools> wgrant: that is not a helpful remark
[11:20] <wgrant> Probably not.
[11:21] <wgrant> But it is hard to make helpful remarks when ascii_smash exists.
[11:22] <wgrant> Because the only conceivable reason for its existence was rendered invalid 8 years before LP was begun.
[11:23] <cjwatson> I'm sure I would be a lot more annoyed about it if it mangled my own name.  Part of the problem is probably that the Latin-alphabet ratio in Ubuntu development is too high.
[11:23] <wgrant> Yup.
[11:23] <wgrant> rvba has been useful.
[11:23] <wgrant> With his Unicode name breaking new Soyuz features :P
[11:23] <bigjools> heh
[11:23] <wgrant> Previously we had to rely on danilos.
[11:24] <nigelb> I should write my name in my mother tongue just to break LP.
[11:24] <jml> wow
[11:24] <jml> working with the LP bzr branch is really different when you are only casually dipping in
[11:24] <cjwatson> One of our proposed baby names contains an accent; I expect to get more annoyed with broken forms and the like
[11:24] <nigelb> heh
[11:25] <bigjools> in composite changelogs, how many blank lines, if any, do we want to keep once the trailer line is removed?
[11:25] <wgrant> charlieS has been wandering around with a snowman in his LP name for a while now.
[11:25] <wgrant> https://launchpad.net/~cschluti
[11:25] <wgrant> bigjools: There should be one blank line between each entry.
[11:25] <danilos> wgrant, cjwatson :)
[11:25] <nigelb> wgrant: Excellent!
[11:25] <poolie_> jml: ha ha
[11:26]  * bigjools curses python-debian
[11:26] <wgrant> bigjools: So you probably need to drop the trailing and one of the lines.
[11:26] <cjwatson> Why do we remove trailer lines in composite changelogs anyway?
[11:26] <danilos> wgrant, actually, I think charlieS is snowman-ready to test the SSO bug they have for our RT systems login (they are not sending the full name over anymore, but I suppose they'd like to)
[11:26] <nigelb> jml: Now you know how people like me feel :P
[11:26] <bigjools> cjwatson: that is an extremely good question
[11:26] <wgrant> danilos: Ah, but he must have changed it in LP too.
[11:26] <jml> wgrant: $ bzr grep ascii_smash | wc -l
[11:26] <jml> 29
[11:26] <wgrant> danilos: Or maybe even he is confused by login.launchpad.net :(
[11:26] <wgrant> jml: Mostly tests.
[11:26] <danilos> wgrant, right, could be :)
[11:26] <jml> wgrant: 29 is a small number. There art thou happy.
[11:27] <nigelb> jml: I'm curious though, what bits feel different?
[11:27] <wgrant> jml: It still does not inspire confidence that such a thing existed in the first place :(
[11:27] <jml> nigelb: the elapsing time
[11:27] <cjwatson> jml: you have to spend half an hour every time fixing your test setup?
[11:27] <bigjools> cjwatson: in fact as someone who looks at the emails from syncs, do you want to see them with or without trailer lines for each revision?
[11:27] <jml> cjwatson:  yeah, that too.
[11:27] <jml> Also, caching files into memory
[11:27] <wgrant> I think I'd prefer them with trailers.
[11:27] <nigelb> jml: Heh :)
[11:27] <jml> And bzr taking quite some time to download stuff
[11:27] <wgrant> But it's unconventional and might make parsers angry.
[11:28] <nigelb> I think I've accept that I'll take 4 hours to write a patch
[11:28] <cjwatson> hm, I'm not sure, the counterargument is that dpkg-genchanges -v wouldn't include the trailers
[11:28] <nigelb> and about 12 hours to write a test.
[11:28] <wgrant> cjwatson: I think that's the only reason not to include them.
[11:28] <cjwatson> I think e-mails from syncs should omit the trailer lines but representations like +changelog should include them
[11:28] <cjwatson> probably
[11:28] <bigjools> dpkg-genchanges output was the original argument for omitting them
[11:28] <wgrant> We really should replace +changelog with the real changelog, now that we have it.
[11:29] <bigjools> yes
[11:29] <cjwatson> I wouldn't be desperately sad if they were included everywhere, but wgrant may be right that the odd thing might get confused
[11:29] <wgrant> It's only a few lines to get rid of them.
[11:29] <wgrant> So let's get rid of them.
[11:30]  * bigjools gets rid of them
[11:30] <bigjools> now, htf to omit this blank line too
[11:30] <wgrant> You could strip the chunks and "\n\n".join()
[11:30] <wgrant> If python-debian isn't being convenient.
[11:30] <bigjools> gross, but yes
[11:31] <wgrant> Or just rstrip and + '\n\n' or so.
[11:34] <bigjools> today is going to need a lot more caffeine
[11:35] <poolie_> mrevell, wow, interesting post from cheater
[11:36] <poolie_> something to get started with :)
[11:36] <wgrant> poolie_: There was some discussion with him in #launchpad earlier.
[11:37] <poolie_> yeah i saw the quotes
[11:37] <mrevell> poolie_, I haven't read that yet ... /me dives in
[11:38] <nigelb> I find parts of it depressing.
[11:38] <poolie_> it is a bit
[11:38] <poolie_> in various ways
[11:38] <poolie_> some of them being that we saw the problem at the time
[11:38] <poolie_> on the other hand it's a lot of free moderately good user feedback
[11:39] <nigelb> heh
[11:39] <poolie_> it's possibly more efficient than him filing 50 bugs
[11:40] <nigelb> Well, now we'd file the 50 bugs instead of him :P
[11:40] <nigelb> Hoping, of course, that some of them get fixed in the near future.
[11:42] <jml> oh that reminds me
[11:43] <jml> oneiric feedback :(
[11:44] <poolie_> heh
[11:44] <nigelb> oneiric feedback?
[11:45] <wgrant> Argh.
[11:45] <wgrant> Why do I ever try to fix Unicode stuff in Python 2.
[11:46] <wgrant> The implicit str<->unicode conversions suck.
[11:47] <jml> nigelb: I'm running oneiric. It's critically buggy in about a dozen major ways for me. I should file those bugs.
[11:47] <nigelb> jml: Ahh.
[11:47] <wgrant> Unity has only crashed once today!
[11:47] <wgrant> It didn't much like me opening Character Map.
[11:47] <nigelb> At some point I should upgrade to something with Unity.
[11:48] <nigelb> I'm still on Lucid and Maverick.
[11:48] <wgrant> nigelb: You're running maverick?
[11:48] <wgrant> Hah.
[11:48] <mrevell> poolie_, On the positive side, some of the things he raises are pretty easy to fix. I've been reading a book, About Face, which is about goal-oriented design. The issues cheater mentions fall under what the book refers to as "implementation model" design ... i.e. the UI arises from how the thing is engineered, rather than from the user's goals. Such an observation isn't new, but I think we can solve a tonne of cod
[11:48] <mrevell> e.lp's problems by saying, "Right, person A wants to host code ... what's the least work they need to do to get up on LP" and then making everything else optional, something you can do later if it's necessary.
[11:48] <wgrant> mrevell: Very, very strongly agree.
[11:48] <nigelb> Amen.
[11:48] <nigelb> Its not very apprent how to upload code coming from github.
[11:48] <wgrant> mrevell: It's a huge shift from the last 7 years of UI. But I think it's the way the world has gone.
[11:49] <nigelb> That I need a project and then add to the project.
[11:50] <mrevell> So, perhaps we have a simple, default, path where you push something up and it lands in a renamed +junk (+personal?) and we allow merge proposals on +junk branches ... that'd solve some of what cheater mentions.
[11:50] <cjwatson> nigelb: well, technically you don't, but then you have to put up with your branch being called +junk.
[11:50] <wgrant> mrevell: We've long wanted an easy way to promote junk to a project.
[11:50] <nigelb> cjwatson: Yeah. I don't like LP calling my stuff +junk :)
[11:50] <nigelb> (GAH, no pun intended)
[11:51] <wgrant> The modern DVCS hosts tend to get around this by not having projects.
[11:51] <wgrant> Everything is namespaced under a team/person.
[11:51] <nigelb> cjwatson: I would like LP to say something like.. "Want to start a project? Go here!"
[11:51] <nigelb> Or something.
[11:51] <mrevell> wgrant, I think that'd be throwing the baby out with the bathwater, in our case. Projects are a really strong plus point of LP but maybe, in code's case, they shouldn't be compulsory.
[11:52] <mrevell> I didn't know what "junk" meant in America when we introduced +junk
[11:52] <wgrant> mrevell: Right, but it makes LP projects seem heavier-weight.
[11:52] <wgrant> mrevell: Because they are globally namespaced.
[11:53] <wgrant> And indeed, they sort of are.
[11:53] <wgrant> I'm not sure how to fix that without fundamentally changing how LP works, which would imply losing the single project community stuff.
[11:54] <nigelb> I'm not sure current LP users want that changed.
[11:54] <mrevell> wgrant, Wouldn't being able to promote a branch from +junk to a project solve it? Or am I missing something?
[11:54] <wgrant> mrevell: That's still a big leap.
[11:54] <mrevell> wgrant, It is?
[11:54] <mrevell> technically or conceptually?
[11:54] <nigelb> I would also like to see code.lp.net telling me how to statr a project.
[11:55] <wgrant> Conceptually.
[11:55] <wgrant> You're turning something that was local to you into something that is global.
[11:55] <wgrant> And more permanent.
[11:55] <wgrant> And more imposing.
[11:55] <jelmer> ... especially as we don't have a way for users to delete a project
[11:56] <wgrant> In other sites there is no leap there, because everything is equal.
[11:56] <wgrant> jelmer: Exactly.
[11:56] <nigelb> Argh. Really?
[11:56] <jml> also, sharing is a big deal
[11:56] <nigelb> I've never had to do that yet.
[11:56] <nigelb> Oh, I can't rename a project either, can I?
[11:56] <jml> licence, commit privs, contributions, etc.
[11:57] <mrevell> I haven't thought about the consequences too much but what about personal branches that are associated with a project but still viewed as and controlled by the owner, just like a +junk branch that has an affiliation.
[11:57] <bigjools> wgrant: do we ever need that trailer or is it always redundant?
[11:57] <wgrant> bigjools: For the current callsites (all one of them) it is redundant.
[11:57] <bigjools> particularly on acceptance and rejectio nemails
[11:58] <bigjools> there is more than one call site
[11:58] <wgrant> Well, only one conceptual callsite.
[11:58] <wgrant> Notifications.
[11:58] <bigjools> yes
[11:58] <wgrant> And they should be uniform.
[11:58] <wgrant> While announcements are all that are likely to be machine-parsed, we should keep it consistent, as they have been traditionally.
[11:59] <wgrant> mrevell: How is that different from what we have now?
[11:59] <wgrant> mrevell: Branches within a project are still controlled by the owner.
[11:59] <bigjools> ok thanks
[12:00] <wgrant> mrevell: It becomes a much smaller leap if we make project registration not scary,.
[12:00] <mrevell> wgrant, Well, sure, so that's where perhaps I'm missing something what you're saying. I guess my suggestion was as a looser affiliation between branch and project.
[12:00] <wgrant> mrevell: But it is still a significant leap that the other sites don't have.
[12:01] <mrevell> wgrant, Hmm ... project registration should, perhaps, be emergent from other "stuff" that's on LP. Maybe.
[12:01] <wgrant> You go from being a repository for code to launchpad.net/launchpad
[12:01] <wgrant> From relative simplicity to a bombardment of terms and clutter.
[12:01] <wgrant> Most of which cannot be disabled.
[12:02] <wgrant> The "Configuration Progress" thing was a good idea.
[12:02] <wgrant> But the implementation is very confusing.
[12:02] <wgrant> And doesn't go far enough.
[12:02] <mrevell> wgrant, We can make the project registration process, etc, much friendlier without fundamentally changing how LP handles projects.
[12:02] <wgrant> mrevell: Yes.
[12:02] <wgrant> But it would be nice to be able to get rid of the leap.
[12:02] <wgrant> But i don't think we can, without the fundamental change.
[12:02] <wgrant> Which I really, really don't want.
[12:03] <wgrant> I don't think anybody does :)
[12:03] <mrevell> :)
[12:03] <wgrant> I guess the first step is to make project registration not suck. Then we can think about solutions for going further.
[12:04] <wgrant> Defaulting LP features to off, with a nice simple initial project page, which walks you through maybe turning on additional features as you need.
[12:04] <mrevell> If we normalise the idea of personal branches ... so take away the pejorative name, make such branches more like a first-class citizen in LP, that would help.
[12:04] <wgrant> So it doesn't seem 1000x more complex than a +junk branch.
[12:04] <mrevell> agreed wgrant
[12:04] <G> gmb: I noticed you are the current reviewer 'on call' do you have a moment?
[12:05] <gmb> G: Sure. How can I help?
[12:05] <G> gmb: basically I spotted an issue in LP and I want to run it by someone in the know so I do it right the first time
[12:06] <wgrant> mrevell: I think junk's a good name, and other projects have used it for a very similar purpose, but as we've seen it does not seem to be well-received by some :(
[12:06] <G> gmb: I gave an outline an hour ago, but I'm happy to go over it again if you don't want to scroll back
[12:06] <wgrant> Not sure what to replace it with.
[12:06] <mrevell> wgrant, As an aside,  project registration sucks for a reason ... a kinda bad reason ... but to discourage mistaken or frivolous registrations.
[12:06] <gmb> G: Okay, sure. What's the deal, then?
[12:06] <wgrant> mrevell: Yeah.
[12:06] <wgrant> mrevell: Although it's better than it used to be.
[12:06] <G> gmb: okay, bug in question is: https://bugs.launchpad.net/launchpad/+bug/837290
[12:06] <_mup_> Bug #837290: When there is no "Other bug subscribers" incorrect descriptive text is displayed <Launchpad itself:New> < https://launchpad.net/bugs/837290 >
[12:06] <wgrant> mrevell: A bit of a workflow, rather than a 5 page form.
[12:07] <StevenK> mrevell: Making it easier for registry-admins or LOSAs to delete/hide projects, then?
[12:07] <mrevell> wgrant, I'd suggest either "+personal" or we go the whole way and simple allow branches at the /~ level, without a workaround project
[12:07] <StevenK> Sigh. s/Making/Make/
[12:08] <gmb> G: Okay, I'm with you.
[12:08] <G> gmb: basically, from what I've managed to find from looking at the javascript, and a bit of fiddling, is that SubscribersLoader in lib/lp/app/javascript/subscribers isn't merging config variables passed to the function with the defaults properly
[12:09] <mrevell> StevenK, Sure. It's very easy to deactivate a project. Do deactivated projects show up in searches etc?
[12:09] <StevenK> I have no idea. But if it is easy, then excellent.
[12:09] <G> as a result, when 'resetNoSubscribers' (approx line 596) runs it can't look up the value of subscirbers_label because it doesn't exist
[12:09] <poolie_> there's a big difference between someone choosing to call their code junk and us making it
[12:09] <gmb> G: Argh, right.
[12:09] <mrevell> I'd also like to fix whatever leads to people mistakenly creating a new project, when really they want something else.
[12:10] <poolie_> nigelb, as it happens i was just reading some of http://www.bwater.com/Uploads/FileManager/Principles/Bridgewater-Associates-Ray-Dalio-Principles.pdf today about the benefits of facing reality, _especially_ when its painful
[12:10] <G> gmb: it's because the bugs & answers scripts, aren't setting the value in the config var
[12:10] <wgrant> mrevell: Making the UI less bad would help there.
[12:10] <poolie_> mrevell, they really want CDs :)
[12:10] <wgrant> mrevell: Because people might be able to find their way to what they want.
[12:10] <mrevell> poolie_, Heh, yeah :)
[12:10] <G> gmb: it got masked by a unit test, but what I'm thinking is essentially: http://pastebin.ubuntu.com/677887/
[12:10] <nigelb> poolie_: heh :)
[12:10]  * gmb looks
[12:11] <wgrant> I wonder if people have stopped looking for ShipIt yet.
[12:11] <nigelb> G: If you were using for full-name, we'd have good fun with tabcomplete
[12:11] <nigelb> *your
[12:11] <G> nigelb: I have the IRC nick 'Nigel' registered ;)
[12:11] <mrevell> wgrant, huwshimi has a great deal of work when he gets back from leave :)
[12:11] <poolie_> that thing (200 page) pdf is well worth reading
[12:11] <wgrant> mrevell: Oh yes :)
[12:11] <nigelb> G: Ha! that's you
[12:11] <nigelb> poolie_: 2 days off, I have soemthing to read :)
[12:12] <G> I don't have 'nigelj' though, can't be bothered registering it :)
[12:12] <nigelb> hehe
[12:12] <G> gmb: because basically what is happening, it's merging everything into 'this' but SubscribersList(config) doesn't get 'this' it gets the unmerged config attrs
[12:13] <gmb> G: I understand and agree :).
[12:13] <G> gmb: I tried SubscribersList(this) but that crashed and burnt
[12:13] <G> gmb: so should I go w/ that and do a Merge Proposal?
[12:14] <bigjools> wgrant: right, it's all fixed.  Would you care to check the MP...
[12:14] <gmb> G: Yes, run up an MP and ping me the link. I'll take a look and double check it this afternoon.
[12:14]  * bigjools is now fairly sick of the sight of changelogs and unicode
[12:14] <G> gmb: okay, thanks!
[12:15] <gmb> np
[12:15] <G> (for what it's worth, the unit test never picked it up, because the unit test was pre-populated w/ a config that specified everything)
[12:15] <StevenK> G: I think you should fix/write another test
[12:16] <G> StevenK: I was thinking that myself :)
[12:18] <G> StevenK: I think what I'll have to do though, is create a second setUpSubscribersList without that information in the unit test
[12:21] <StevenK> G: A second unittest without the information sounds like an excellent idea.
[12:21] <G> yep just found how I can do it easy :)
[12:26] <nigelb> wait, you found unittest easy?
[12:26] <StevenK> nigelb is jealous.
[12:26] <nigelb> Of course.
[12:26] <G> nigelb: I'm basically running the same tests, but with a different starting point :)
[12:26] <nigelb> I headdesk constantly.
[12:27] <nigelb> And break them in truckloads
[12:27] <StevenK> nigelb: Is there a marked depression in your desk?
[12:27] <nigelb> Yes.
[12:28] <nigelb> do you have a pillow for those situations?
[12:28] <nigelb> Or does joiing the LP team give you a Launchpad branded pillow.
[12:28] <StevenK> No, I was just curious if your constant bashing your head was affecting your desk adversely.
[12:29] <nigelb> heh
[12:29] <nigelb> BUt I'm geting better.
[12:29] <nigelb> I wrote a test + fix with just little help the other day.
[12:33] <nigelb> StevenK: But is it just me or are tests challening?
[12:36] <wgrant> bigjools: Looks good.
[12:39] <StevenK> nigelb: I found tests get easier to write as you get more comfortable with the code base.
[12:39] <StevenK> nigelb: But it is still difficult if I jump into an area of the codebase that I'm not familar with.
[12:40] <nigelb> StevenK: I guess not being familiar with any bit of the code base is against me.
[12:40] <nigelb> I'm also unfamiliar with the different ways to test.
[12:41] <nigelb> Well, I am now familiar with a few, but I'm guessing there are more.
[12:41] <jml> nigelb: have you done much TDD before?
[12:41] <nigelb> jml: LP was one of the first. Now I'm doing more with Mozilla projects.
[12:42] <StevenK> Depending on what I'm doing -- if I'm playing or trying to understand how something works, I will just change the code. If I'm removing stuff, I will tend to just wield the axe and swing. If I'm fixing a bug or something like that, I will write the test first.
[12:42] <jml> nigelb: and I guess both are big, complex, old codebases
[12:43] <nigelb> jml: I touch the Mozilla Webdev, not firefox :)
[12:43] <nigelb> StevenK: Oh. I should try tyhat.
[12:43] <jml> nigelb: ah ok
[12:43] <nigelb> I tend to write tests later. THat's probably wrong.
[12:43] <StevenK> nigelb: It can be.
[12:44] <jml> nigelb: I found that getting started w/ TDD took a while, because I wasn't used to being so clear about what I was trying to do. Then, there was a bit of a watershed, and then writing tests was easier before *or* after code
[12:44] <jml> Although I still find writing tests after code deadly dull
[12:44] <nigelb> SHould find another bug to work on so I can try with tests first.
[12:44] <nigelb> 2 days holiday, I have 2 full days to come up with something!
[12:50] <gary_poster> jelmer, hi.  I have a fix for bzr 2.3 that I'd like in LP.  I know that you (?) have 2.4 coming to us Friday-ish.  John said that my fix would go into 2.4 and trunk "automatically"...do you have a recommendation on me getting my fix in?
[12:50] <gary_poster> About the best situation I can imagine in the situation is "my fix goes into 2.4 this week and when we switch to 2.4 we get the version with the fix".  Other options might be ppostponing getting my work in till later, but from a Lean/mgmt perspective that's not ideal
[12:53] <gary_poster> Hm, my connection seems a bit odd...
[13:04] <abentley> gary_poster: bzr 2.4.0 went gold on August 11.
[13:04] <gary_poster> abentley, I know, but LP uses our own distros of it frequently.
[13:05] <abentley> gary_poster: It wasn't clear you were talking about using unreleased versions.  Certainly, we could roll our own.
[13:06] <abentley> gary_poster: but the one coming out this week will not have the fix.
[13:06] <gary_poster> abentley, ok.  So, do you have a suggestion on how to proceed?  Once the 2.4 line had the fix, I could roll our own and merge it to db-devel
[13:06] <gary_poster> Or just wait till Friday and update separately...
[13:07] <gary_poster> I guess it depends in part on how quickly the 2.4 line gets the fix
[13:07] <gary_poster> (merged via PQM, that is)
[13:08] <abentley> gary_poster: to me, it doesn't seem like an urgent fix.  Am I missing something?
[13:08] <gary_poster> abentley, it was causing ec2 land to fail for me.  It appears to be intermittent.
[13:08] <G> gmb: thanks for the help, I've just submitted the merge proposal: https://code.launchpad.net/~dev-nigelj/launchpad/bug837290/+merge/73369
[13:08] <gary_poster> abentley, so it would only be urgent to LP
[13:08] <gmb> G: Okay, thanks. I'll try to get to it in the next hour or so.
[13:09] <G> gmb: okay, no hurry
[13:09] <gary_poster> and then only to people who are hitting the intermittent problem
[13:09] <nigelb> hehe, I got pinged for the nigel there.
[13:09] <nigelb> Drat.
[13:09] <abentley> gary_poster: I've seen that behaviour for months if not years.
[13:09] <G> nigelb: haha :)
[13:09] <gary_poster> abentley, huh.  I don't know why it was biting me
[13:09] <gary_poster> but it was
[13:10] <G> nigelb: you know, I recently had to write an irssi script to ignore people saying "G+" at the start of a line :)
[13:10] <gary_poster> heh
[13:10] <deryck> Morning, all.
[13:10] <abentley> gary_poster: Anyhow, if it matters to you significantly, then branch 2.4 now, apply the fix, and that'll be good until 2.4.1 comes out.
[13:10] <nigelb> G: haha! Fun!
[13:10] <StevenK> G: 'bzr pipes' is from a plugin called bzr-pipeline -- lp:bzr-pipeline
[13:10] <nigelb> THere's a machine called babune with bzr team.
[13:11] <nigelb> I got pinged for that quite a bit
[13:11] <nigelb> (My last name is babu, and I had a hilight for that)
[13:11] <nigelb> I had change how that hilight worked
[13:11] <deryck> Morning, adeuring.  How are things with the hwdb fixes?
[13:11] <adeuring> deryck: mixing results. shall we mumble about it?
[13:12] <deryck> that's not what I wanted to hear. ;)
[13:12] <deryck> adeuring, yes. let's mumble.  firing it up now.
[13:12] <G> StevenK: looks like rocketfuel-setup didn't know about it
[13:13] <StevenK> G: It's optional, but *awesome*
[13:13] <nigelb> G: It doesn't, I had to set it up manually as well.
[13:13] <nigelb> You should also probably install python-lint something
[13:14] <gary_poster> abentley, ok...I understood the fix would be automatically applied to 2.4 (though I don't think it will apply cleanly because pertinent code has moved around between 2.3 and 2.4), and it is not yet there...so I'll wait to see if it is applied and go from there.  Thanks.
[13:14] <gary_poster> (since 2.4 is not in tree yet)
[13:14] <wgrant> 2.4 is in db-devel now.
[13:15] <wgrant> And since staging is back after a two-week absence, we might be able to QA it.
[13:15] <wgrant> And get it into devel.
[13:15] <abentley> gary_poster: Not automatically.  bzr devs periodically merge one series into the next.
[13:15] <wgrant> jelmer: Any progress?
[13:15] <gary_poster> wgrant, ah great news about staging!
[13:16] <gary_poster> abentley, ok.  Can I do anything to help or encourage the merge--I'd be happy to prepare my own merge and make an MP if it helped
[13:16] <gary_poster> But don't want to be a bother if it won't help
[13:17] <stub> wgrant: Did you happen to rebuild the EC2 image?
[13:17] <jelmer> wgrant: on bzr 2.4 QA? Apart from loggerhead I managed to do the QA I wanted to
[13:18] <abentley> gary_poster: I think it would be best to wait until bzr 2.4 is actually released.
[13:18] <gary_poster> abentley, ok that's fine.
[13:18] <gary_poster> thanks
[13:19] <abentley> gary_poster: So if it really matters to you, you should cut your own release.
[13:19] <stub> gary_poster: If I update launchpad-dependencies, does a losa need to update the buildbot hosts too?
[13:19] <gary_poster> oh
[13:20] <abentley> gary_poster: i.e. if you want to have it this week or next week, make your own tarball.
[13:20] <gary_poster> stub, that's the deb?  If so, yes, I think so.
[13:20] <stub> Ta. I'll open an RT.
[13:21] <StevenK> Bah, I can't re-produce that missing pipes thing with lint
[13:22] <gary_poster> abentley, ok cool thanks.  I did not see "make a release" instructions; is it just "update bzrlib.version_info to increment the last number, and run ./setup.py build"?
[13:22] <stub> Anyone want to volunteer to update the ec2 test image with new launchpad-developer-dependencies so I don't have to experience the process myself via by Internet connection in a rain storm?
[13:23] <abentley> gary_poster: First manually override the version number in setup.py, then run "make dist".
[13:23] <gary_poster> stub, I or someone on yellow can do it.
[13:24] <gary_poster> stub, it's ready to go now?
[13:24] <gary_poster> abentley, got it, thank you very much.
[13:24] <stub> gary_poster: That would be lovely. Its all ready to go in the PPA. Need anything from me?
[13:24] <gary_poster> stub, not that I can think of.
[13:25] <abentley> gary_poster: np
[13:26] <flacoste> abentley, gary_poster, jelmer, adeuring: i'd like to release 13822 today, please QA your revisions
[13:26] <abentley> flacoste: roger.
[13:26] <flacoste> thanks!
[13:27] <gary_poster> abentley, ack, on it
[13:27] <gary_poster> sorry abentley, I meant flacoste
[13:28] <nigelb> flacoste says that quite differently from wgrant.
[13:28] <nigelb> ;)
[13:28] <abentley> gary_poster: also, sudo make me a sandwich :-)
[13:28] <StevenK> nigelb: QA!
[13:28] <nigelb> StevenK: Yeah, you too :P
[13:28] <gary_poster> abentley :-)
[13:29] <jelmer> aye aye!
[13:30] <mrevell> flacoste, Skype?
[13:30] <wgrant> nigelb: (for the record, I've only said 'QA!' twice, both times to StevenK after he started doing it, despite him doing it to supposedly emulate me!)
[13:30] <flacoste> mrevell: yes, please
[13:31] <nigelb> wgrant: hehe
[13:31] <deryck> flacoste, I need to chat with you about the state of that hwdb change.  but am on stand up now.
[13:31] <deryck> flacoste, I assume the qa pressure is for that.
[13:31] <flacoste> deryck: i'm getting on call with mrevell now
[13:32] <flacoste> deryck: will ping when i'm free
[13:32] <deryck> flacoste, ok
[13:40] <rvba> henninge: Hi
[13:41] <henninge> rvba: Hi! ;)
[13:41] <henninge> rvba: just reading your reply.
[13:41] <henninge> now
[13:41] <abentley> flacoste: I am having difficulty QAing because https://qastaging.launchpad.net/ is timing out.
[13:41] <rvba> henninge: Okay, I'm available if you need any clarification.
[13:41] <henninge> rvba: cool, thanks
[13:42] <rvba> henninge: BTW thanks for the very nice and instructive review ;)
[13:42] <flacoste> abentley: is your change the source of the timeout? or it's something else causing timeout?
[13:42] <abentley> flacoste: it must be something else.
[13:43] <abentley> flacoste: Now qastaging is giving "Please try again/Sorry, there was a problem connecting to the Launchpad server. ", so maybe it was due to a deployment?
[13:44] <wgrant> qastaging is not updating, so something is broken.
[13:45] <wgrant> It successfully updated a few hours ago, but the update log file is being truncated frequently when it never has been before, so something may be up.
[13:46] <abentley> wgrant: how can you tell it's not updating?
[13:46] <wgrant> wgrant@carob:~$ rsync -a asuka::qastaging-logs/qastaging-update.log .
[13:46] <wgrant> wgrant@carob:~$ tail qastaging-update.log
[13:46] <wgrant> Tue Aug 30 13:18:03 UTC 2011 Current Revno: 13822, New Revno: 13822 - nothing to update
[13:46] <wgrant> wgrant@carob:~$
[13:47] <wgrant> The next update will not start for almost another minute.
[13:47] <wgrant> And the last one found nothing to do.
[14:05] <gmb> G: Branch approved. I'll land it for you now.
[14:06] <G> gmb: just saw the e-mail, thanks
[14:29] <henninge> rvba: before I try to find out your asset problem, let me find something out.
[14:30] <henninge> deryck: Hi!
[14:30] <deryck> henninge, hello :)
[14:30] <henninge> deryck: When you merged lazr-js into lp in Dublin, you kept the directory structure.
[14:30] <henninge> deryck: There is a seperate directory for each lazrjs class.
[14:31] <henninge> e.g. overlay, formoverlay, etc.
[14:31] <henninge> deryck: Do you think that structure should be kept when adding more widgets?
[14:31] <henninge> deryck: Or wouldn't it be enough to have a file per widget?
[14:32] <deryck> henninge, hmmmm
[14:32] <henninge> deryck: I think a directory that holds just one file is a bit of a waste.
[14:32] <henninge> deryck: but then there are assets and tests but they can go into central directories, too.
[14:33] <deryck> henninge, I prefer keeping the directory structure so we know where tests live.....
[14:33] <rvba> henninge: ;)
[14:33] <deryck> henninge, if we do change to individual files and central tests, I don't mind that.  but I'd prefer a conscious change and move everything....
[14:33] <deryck> not have done one way, and new stuff done another.
[14:34] <henninge> deryck: well, the lp stuff does not use directories.
[14:34] <henninge> so there is lib/lp/app/javascript/client.js
[14:34] <henninge> and not client/client.js
[14:34] <henninge> so we already have a mixture.
[14:34] <deryck> hmmm, good pont.
[14:34] <deryck> point
[14:35] <deryck> henninge, I don't really care :)  You and rvba decide. :)
[14:35] <jcsackett> henninge, deryck: there are some cases where multiple files comprise the components. e.g. in the picker directory we have several files. it's probably worth maintaining folders only if we need to break up the files. :-)
[14:35] <deryck> yeah, I think do what makes sense for the widget.  I'm just not that passionate about this issue. ;)
[14:36] <henninge> deryck, jcsackett: although I'd prefer a unified approach.
[14:36] <henninge> ok, we decide ;-)
[14:36] <henninge> rvba: how do want to do it? ;-)
[14:36] <flacoste> deryck: i'm free now
[14:36] <deryck> flacoste, awesome.  let's mumble.
[14:36] <rvba> henninge: my really first idea was to put my new widget inside formoverlay.
[14:37] <henninge> rvba: no, that was not one of the choices ... ;-P
[14:37] <rvba> henninge: ideally I think we should have a directory called 'overlay' with all the 3 overlays.
[14:38] <flacoste> deryck: i'm in Orange 1-1
[14:38] <deryck> coming, sorry....
[14:39] <rvba> henninge: so, what do you reckon, back to the individual confirmationoverlay directory?
[14:44] <henninge> rvba: I like the "overlay" idea, too, but not for this branch.
[14:45] <rvba> henninge: That's right, not for this branch!
[14:45] <henninge> rvba: I think going back to the individual directory is fine.
[14:45] <rvba> henninge: So, let's go back to the confirmationoverlay directory, and I shall file a bug.
[14:45] <henninge> rvba: cool
[14:45] <rvba> \o/
[14:47] <henninge> rvba: your other changes look very good, too. I won't force you to remove all usages of join('')  (though I'd like to ;)
[14:48] <henninge> rvba: push your changes once you are done and 'll have a last look.
[14:48] <rvba> henninge: Thanks ;). You have to admit I followed the vast majority of your advices.
[14:48] <henninge> rvba: yes, thanks
[14:49] <henninge> rvba: but you also wrote some nice code yourself, where I let you ;-)
[14:49] <henninge> I am impressed at how nicely it came out.
[14:49] <rvba> Thanks!
[15:01] <jelmer> gmb: G'day!
[15:01] <jelmer> gmb: Can I add another small branch to your queue?
[15:03] <bigjools> gmb: yo, me too! :)
[15:04]  * nigelb waves
[15:04] <nigelb> Need to find another bug to work on.
[15:08] <abentley> jml: Congratulations!  And, I have a Twisted style question.
[15:10] <G> gmb: oh hey, I just realised, I need to do that Contributor Agreement thing right?
[15:10] <nigelb> G: Yeah, you do. Send an email with that stuff to francis
[15:11] <G> suddenly struck me that the code of conduct thing != contributor agreement
[15:11] <nigelb> hehe
[15:11] <G> I'll have to do it in the morning when I have access to a scanner
[15:12] <nigelb> wait, what?
[15:12] <nigelb> Has it changed?
[15:13] <G> I'm looking at: http://www.canonical.com/contributors
[15:13] <nigelb> I didn't scan for sure.
[15:13] <nigelb> But there's a new agreement.
[15:15] <rvba> henninge: Done!
[15:16] <G> nigelb: it's got the fill & in the blank bits in the PDF, but it says it needs to be printed, signed , scanned and sent
[15:16] <nigelb> Need to check wwhat I did back then
[15:17] <nigelb> Ah, i just had to send an email with that as an attachment.
[15:17] <nigelb> With Harmony, the rules have changed.
[15:17] <G> gmb: looks like the change needs to hold off for a day so I can send in the form
[15:17] <henninge> rvba: cool. Looking.
[15:33] <gmb> G: Ah, blast. I'd forgotten about that.
[15:34] <gmb> Okay, I'll stop the EC2 run.
[15:35] <jcsackett> gmb: can i throw https://code.launchpad.net/~jcsackett/launchpad/target-adapters-aplenty/+merge/73248 on to your queue?
[15:35] <gmb> jcsackett: Sure
[15:35] <jcsackett> thanks, gmb!
[15:39] <henninge> rvba: I did not know about ObjectAssert. I did not notice you were using it before.
[15:39] <henninge> rvba: or did you just add that?
[15:39] <henninge> rvba: Also, areEqual seems to be undocumented ... ;-)
[15:39] <rvba> henninge: No I did not.
[15:40] <henninge> ok, I missed that, then.
[15:40] <henninge> np
[15:40] <henninge> rvba: but the test is still failing for me
[15:40] <henninge> not on the ObjectAssert, though
[15:40] <rvba> henninge: strange, which test?
[15:40] <henninge> test_hidden_field_added_on_ok: failed.
[15:40] <henninge> Unexpected error: Cannot call method 'simulate' of null
[15:41] <henninge> and this:
[15:41] <henninge> test_call_submit_on_ok: failed.
[15:41] <henninge> Unexpected error: Cannot call method 'simulate' of null
[15:42] <rvba> henninge: They all pass here ...
[15:42] <henninge> hmmm
[15:43] <rvba> henninge: last revision is 13784
[15:43] <henninge> I will have to get a new branch. I had merged to get make lint working.
[15:44] <henninge> rvba: meanwhile: I *do* think it is important to satisfy the linter otherwise we might miss notice real issues.
[15:44] <henninge> rvba: so thanks for fixing that
[15:44] <henninge> s/notice//
[15:45] <rvba> henninge: Welcome :)
[15:47] <rvba> BTW I only had lint errors for the css file which was mostly copied from existing code. Hence my remark ;)
[15:49] <jelmer> gmb: Can I add another small branch to your queue?
[15:49] <gmb> jelmer: SUre
[15:49] <gmb> jcsackett: Your branch is approved.
[15:49] <henninge> rvba: even with a new checkout the test is still failing.
[15:50] <jelmer> gmb: Thanks! It's at https://code.launchpad.net/~jelmer/launchpad/no-code-import-approval-2/+merge/73388
[15:50] <jcsackett> gmb: thanks. :-)
[15:50] <gmb> allenap: What's the story with https://code.launchpad.net/~allenap/launchpad/dd-beta-icon-bug-827508/+merge/72492?
[15:51] <rvba> henninge: Ok ... let me try with a new checkout...
[15:51] <rvba> gmb: allenap is off today.
[15:51] <gmb> rvba: What a slacker. Thanks :)
[15:52] <matsubara> gmb, hi there, can I add this one https://code.launchpad.net/~matsubara/oops-tools/837468-missing-req-vars/+merge/73399 to your queue?
[15:52] <rvba> gmb: Back on Thursday. ;)
[15:52] <gmb> jelmer: I love it when a diff confuses the hell out of me. Approved.
[15:52] <gmb> rvba: I only care about other people's branches on Tuesdays. Says so on my calendar ;)
[15:52] <rvba> gmb: I see ;)
[15:53] <gmb> matsubara: Sure, looking now.
[15:53] <bigjools> gmb: hello, did you see my request from 16:03?  Looks like you're busy though ...
[15:54] <gmb> bigjools: I missed it, sorry, was picking up my car  from its service/MOT/owner-gouging. I'll take a look after I've looked at matsubara's. Please send me the link again.
[15:54] <gmb> matsubara: Approved.
[15:55] <matsubara> gmb, thanks!
[15:55] <bigjools> gmb: https://code.launchpad.net/~julian-edwards/launchpad/sync-close-bugs-bug-833736/+merge/73401  thank you sir
[15:55] <bigjools> gmb: and I hear you about the car....
[15:55] <flacoste> matsubara: you saw jane approved the examples script open-sourcing? can you make the necessary updates to the TestApiApplications page?
[15:56] <flacoste> matsubara: we'll revisit the whole SLA wording when lifeless once lifeless comes back, but i think the TestingApiApplications documentation is good enough in its current form
[15:56] <jelmer> gmb: :) thanks
[15:57] <matsubara> flacoste, yep, I saw Jane's email. I'll add to my todo list and try to get to it this week. when do you need this done? Are the scripts ready for release or OEM's going to release them?
[15:57] <henninge> rvba: so, it is failing on the second "simulate" in  test_hidden_field_added_on_ok
[15:58] <rvba> henninge: It looks like the button on the overlay is not found somehow.
[15:59] <bigjools> gmb: before you start one mine, the current diff is bong, it's not picked up the pre-req branch
[15:59] <bigjools> on*
[15:59] <flacoste> matsubara: i think we should take the responsibility of releasing them
[15:59] <gmb> bigjools: Oh, joy.
[15:59] <gmb> Hadn't started yet though.
[15:59] <bigjools> gmb: ok it has now
[15:59] <gmb> Hurrah.
[15:59] <flacoste> matsubara: since it's useful to us as examples more than anything else
[15:59] <gmb> Will look shortly.
[15:59] <flacoste> matsubara: and there is no urgency to this, do it as time permit
[15:59] <bigjools> gmb: yes.  Turns out you need to merge and push more than you think :)
[15:59] <gmb> :)
[16:00] <flacoste> matsubara: might be good to blog about testing API applications once it's complete
[16:00] <matsubara> flacoste, ok.
[16:00] <flacoste> thanks matsubara
[16:00] <matsubara> np
[16:01] <rvba> henninge: all good on a fresh checkout.
[16:02] <henninge> *#@$%& ???
[16:02] <nigelb> heh
[16:02]  * rvba *#@$%& too
[16:02] <james_w> flacoste, matsubara: http://bazaar.launchpad.net/~work-items-tracker-hackers/launchpad-work-items-tracker/trunk/view/head:/lpworkitems/fake_launchpad.py might pique your interest as an approach with pretty much the opposite set of pros and cons :-)
[16:05] <rvba> henninge: oh oh ... I bet you're using chrome ..?
[16:05]  * henninge was just starting FF
[16:05] <henninge> rvba: yes
[16:05] <henninge> passes in FF
[16:06] <rvba> Yep :(
[16:06] <henninge> rvba: what is the difference?
[16:06] <rvba> I really don't know.
[16:06] <rvba> Let's see if it's just the tests.
[16:08] <rvba> henninge: Gosh, something is really wrong with Chrome ... I guess I'm back to the drawing board.
[16:08] <matsubara> james_w, thanks for the link. I'll take a look when I get to update the wiki page.
[16:08] <LPCIBot> Project devel build #1,012: STILL FAILING in 4 hr 32 min: https://lpci.wedontsleep.org/job/devel/1012/
[16:13] <henninge> rvba: that is strange, though.
[16:13] <henninge> maybe it is just the selector in the test?
[16:13]  * henninge tries
[16:13] <rvba> henninge: "<button class="lazr-neg lazr-btn">Cancel</button></div>"
[16:13] <rvba> That's what chrome sees.
[16:13] <rvba> No "type=submit"
[16:14] <rvba> I mean no type=button
[16:15] <gmb> bigjools: Approved
[16:15] <bigjools> gmb: thanks.  I am surprised you don't have questions!
[16:16] <gmb> bigjools: Usually when someone says that it means I might have missed something. What kind of questions did you expect?
[16:16] <bigjools> gmb: well, it's soyuz ....
[16:16] <bigjools> terminology mainly
[16:16] <bigjools> maybe you guys are starting to understand it!
[16:17]  * bigjools lives in hope
[16:17] <gmb> bigjools: Yeah, but for Soyuz this is pretty obvious. I don't think I got stuck on any terminology beyond a couple of "what-does-that-tla-mean-again" moments.
[16:17] <henninge> rvba: Not sure where you see that.
[16:17] <rvba> henninge: In Chrome's dom inspector.
[16:17] <gmb> bigjools: I shan't profess to understanding *just* yet, thanks.  I was looking at the dom node in the javascript debugger.
[16:19] <henninge> rvba: that shows me that both buttons are type=submit.
[16:19] <henninge> rvba: I think that is the problem.
[16:20] <henninge> or rather, *may* be the problem
[16:20] <rvba> """var cancel_button = Y.Node.create('<button>').set('type', 'button')"""
[16:20] <gmb> bigjools: I can imagine :)
[16:20] <henninge> ha!
[16:20] <bigjools> gmb: right, ta
[16:24] <henninge> no
[16:25] <rvba> henninge: it works if I set a class on the button and use it to grab the button.
[16:25] <henninge> yes, I expect so.
[16:25] <henninge> I still wonder about the type thing
[16:27] <henninge> rvba: but does the form work in chrome?
[16:27] <rvba> Testing that right now.
[16:28] <rvba> It does.
[16:30] <henninge> rvba: This works, too, strangely enough:
[16:30] <henninge> Y.Node.create('<button type="submit"></button>')
[16:35] <henninge> rvba: I gotta run. r=me with some comments. Please have a look. ;-)
[16:36] <rvba> henninge: ok, I will ... I'm still trying to figure out what's going on.
[16:36] <henninge> rvba: may be a YUI bug.
[16:36] <rvba> henninge: Looks like allenap had a reason to do it this way:
[16:37] <henninge> rvba: but of course the test has to pass in both FF and chrome before you land this ...
[16:37] <rvba> Y.Node.create( '<button type="button" class="lazr-neg lazr-btn" />').set("text", "Cancel");
[16:37] <rvba> henninge: Sure.
[16:37] <henninge> Yes, I guess so.
[16:37] <henninge> See you tomorrow! ;-)
[16:48] <jml> abentley: hi
[16:48] <jml> abentley: sorry, was offline processing email.
[16:48] <jml> abentley: also, thanks :D
[16:48] <jml> abentley: how can I help?
[16:51] <abentley> jml: Currently, I have a method that either returns a Deferred or None, and calling code that assumes it always returns a Deferred.
[16:52] <abentley> jml: is it more tasteful to call maybeDeferred or to update the method to return twisted.internet.defer.success(None)
[16:53] <jml> abentley: my taste leans to the latter, but either can be alright. Generally maybeDeferred is best when calling arbitrary, "untrusted" code.
[16:53] <jml> abentley: or if you want to make things easy for function/method writers
[16:54] <abentley> jml: okay, cool.
[16:55] <jml> e.g. twisted.cred allows authentication methods to return a non-Deferred thing synchronously, because that's actually quite nice to do a lot of the time.
[17:49] <nigelb> Who's a good person to talk to about registry UI?
[17:49] <nigelb> I'm just wondering why we don't do mailto: for email ID's on the person page
[17:51] <abentley> nigelb: sinzui is the usual guy, but he's not here at the moment.
[17:51] <nigelb> abentley: Ah, ok :)
[17:51] <nigelb> I was looking at bug 82002 and wondering if I could link the jabber ones at least.
[17:51] <_mup_> Bug #82002: Jabber ids look like email addresses, causing confusion <jabber> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/82002 >
[17:51] <nigelb> abentley: Is he off today/this week?
[17:52] <abentley> nigelb: I don't know.
[17:52] <nigelb> Or am I asking at the wrong time
[17:52] <abentley> nigelb: he is usually around at this time.
[17:52] <nigelb> cool, so I can try another day :)
[17:52] <nigelb> abentley: Thanks!
[17:52] <abentley> nigelb: np
[17:54] <abentley> deryck: as we have no OCR, could you please review https://code.launchpad.net/~abentley/launchpad/simplify-twisted-runner-2/+merge/73402 ?
[17:54] <deryck> abentley, sure.
[18:09] <deryck> abentley, r=me.
[18:10] <abentley> deryck: ta
[18:11] <deryck> np!
[18:11] <nigelb> I have a conflict on utilities/sourcedeps.cache
[18:11] <nigelb> how do I fix that?
[18:11] <nigelb> (this is in devel)
[18:11] <nigelb> i.e., which is preferred? lpreview vs loggerhead apparently.
[18:12] <abentley> nigelb: use the version you merged, then run update-sourcecode.
[18:13] <nigelb> so, whatever is in  MERGE-SOURCE is what I want?
[18:14] <abentley> nigelb: there should be a complete copy called utilities/sourcedeps.cache.OTHER which what you want.
[18:15] <nigelb> ah, bzr resolve --take-other sourcedeps.cache did the trick!
[18:16] <abentley> nigelb: not sure if that does the same thing, but it's probably okay.
[18:16] <nigelb> :)
[19:07] <lifeless> flacoste: hi; waving at you via the hwdb bug; bye;)
[19:09] <flacoste> lifeless: hi! don't you have more important things to do than commenting on LP bugs? ;-)
[19:09] <lifeless> yes; am on the way to the hospital now. its slow going :
[19:10]  * lifeless goes
[20:05] <LPCIBot> Project devel build #1,013: STILL FAILING in 3 hr 56 min: https://lpci.wedontsleep.org/job/devel/1013/
[21:42] <thumper> imapfilter hates bug mail
[21:42] <thumper> x-launchpad-bug appears once per task
[21:42] <thumper> however imapfilter uses server side filtering using the IMAP RFC
[21:43] <thumper> which only checks the first header
[21:43] <thumper> so trying to match bugmail for bugs with multiple tasks is full of fail
[21:43] <thumper> I'd love a header like: x-launchpad-project that lists all effected projects
[21:44] <thumper> x-launchpad-sourcepackage for the packages ones
[21:44] <thumper> then the mail filtering would at least work
[21:44] <thumper> also
[21:44] <thumper> blueprint email has no x-launchpad-message-rational nor x-launchpad-project ...
[21:44] <thumper> if y'all can get LP working on oneiric I may provide patches
[21:57] <jelmer> thumper: it works (as far as I can tell) on oneiric here
[23:35] <G> gmb: btw, I fired off the CLA document, so I don't know what the process is now.  Sorry I didn't realise I hadn't done it before.