[07:21] <luis220413> amurray: Are you there?
[08:00] <luis220413> Is anyone from the Ubuntu Security Team here'
[08:00] <luis220413> Is anyone from the Ubuntu Security Team here?
[08:02] <ebarretto> luis220413, yes
[08:03] <luis220413> ebarretto: I have completed testing for my updates in bug 1986627 (regression: incomplete fix for CVE-2020-11653) and bug 1982670. Alex Murray said he would look today in the morning but it is already 17:33 in his timezone.
[08:03] <ebarretto> we already have someone looking at the varnish issue
[08:04] <ebarretto> jupyter-notebook we will get to it when we get to it, it is already queued up, please be patient
[08:16] <luis220413> ebarretto: What are the priorities of the Ubuntu Security Team now?
[08:18] <ebarretto> luis220413, we do way more than security patching. Everyone in the team is busy doing something.
[08:24] <luis220413> ebarretto: On Friday I requested two CVE status changes. I will repeat them but with an explanation.
[08:25] <luis220413> Can you set the status of CVE-2022-38150 for trusty/esm to not-affected (code not present) because it only affects Varnish >= 7.0, and of CVE-2021-32798 for jammy to not-affected (6.4.8-2) because this version includes the fix made upstream?
[08:30] <ebarretto> done, thanks
[08:38] <luis220413> ebarretto: Thanks for the status changes!
[08:41] <luis220413> What are your priority public updates right now and what else you do besides security patching and MIR review?
[08:45] <luis220413> By "you" and "your" I mean the Ubuntu Security Team.
[08:59] <ebarretto> we do security reviews for other teams, apparmor development, snap reviews, certifications (fips, cis, stig), oval generation, cve triage, bug triage, improve our own infrastructure, deal with issues from cloud customers and lots of other tasks
[09:07] <luis220413> Thanks! What public updates do you have in the queue?
[09:19] <ebarretto> that's not the kind of information we advertise. Keep an eye on USNs and you will know what we were working on for Ubuntu releases
[11:17] <mitya57> Hi! Can someone please take a look at my proposed debdiff for jammy-security in bug 1981807 (comment #13)?
[11:45] <luis220413> mitya57: I will take a look. Can you update the debdiff to fix these CVEs? https://ubuntu.com/security/cves?q=&package=qtbase-opensource-src&priority=&version=jammy&status=
[11:51] <mitya57> luis220413: jammy package already has debian/patches/CVE-2021-38593.diff and debian/patches/CVE-2022-25255.diff
[11:55] <luis220413> The binary packages built from this source package have 2096 reverse dependencies.
[11:56] <luis220413> in Ubuntu 22.04 amd64
[11:56] <teward> luis220413: fwiw you are not Security team
[11:56] <teward> mitya57: ^^
[11:56] <teward> ebarretto: because i was poking you earlier - see above
[11:57] <teward> i also am interested because Qt is used by Lubuntu so it's on my radar as well now
[11:57] <mitya57> teward: ok, thanks
[11:57] <teward> i'm not security team either ;)
[11:57] <mitya57> :))
[11:58] <teward> luis220413: yes, Qt is a huge library set.  no TLS1.3 support sounds like it's  just a no change rebuild + patches, but i'll wait for ebarretto or amurray to confirm that for me
[11:58] <teward> (we had the same issue for NGINX with no TLS 1.3 support right when OpenSSL landed with it, a no chnage rebuild against the latest libssl in the repo at the time fixed that chaos)
[11:58] <teward> (but that wasn'ta sec issue)
[11:59] <mitya57> No rebuilds of reverse dependencies are needed. Just a fix in qtbase.
[11:59] <teward> yep, but then a hard watch on all the autopkgtests to make sure it doesn't explode
[11:59] <teward> cc tsimonq2 in case youre bored ^^
[12:00] <teward> (because Lubuntu)
[12:01] <ebarretto> yes, that's more likely a bug fix that should go through SRU, it could go to the security pocket if we deem it worth it
[12:08] <teward> ebarretto: i'll handle that then, because it's on the Lubuntu radar (aka mine)
[12:08] <teward> luis220413: ^^ since i can get this into the SRU process a bit faster ;)
[12:09] <teward> cc also mitya57 because
[12:09] <tsimonq2> I'm curious, why?
[12:09] <teward> tsimonq2: tls1.3 is good?
[12:09] <teward> in case you're bored on the other stack of crap you ahve you might want to do an SRU ;)
[12:09] <teward> (qtbase affects our stuff too)
[12:09] <tsimonq2> (Why originally treat as an SRU?)
[12:10] <teward> that's an ebarretto question ;)
[12:10] <mitya57> I can do the SRU myself as well.
[12:10] <teward> mitya57: oh, well then have fun :)
[12:11] <teward> i'mma go back to stabbing Windows (which is evil) at FT job.  >.<
[12:11] <teward> (can anyone say with me, "Microsoft Exchange Sucks [CENSORED]"?
[12:11] <teward> )
 "cc Simon Quigley in case youre..." <- I'm very rarely bored these days unfortunately... but if you ping me here I make time ;)
[12:16] <luis220413> mitya57, teward: I only mentioned reverse dependencies to show the importance of this source package.
[12:16] <teward> luis220413: helpful hint again from a seasoned dev: rdeps alone don't determine the importance of the package for an update/sru/etc.
[12:16] <teward> there's a ton of other factors
[12:17] <teward> rdeps also can be a *hindrance* if we're doing an update that would break the entire stack;)
[12:17] <luis220413> teward: I know. Examples are actual usage, being seeded in Ubuntu flavors, and so on.
[12:19] <ebarretto> tsimonq2, it might go through the security pocket as I mentioned, it will depend on who reviews it more deeply, but I didn't review it, just glanced over the bug
[12:30] <tsimonq2> Ah, no worries then
[12:30] <tsimonq2> Not my first universe security update, I'll take a look at this either before or after $dayjob, but today. Expect pings before EOD US time :)
[12:51] <luis220413> ebarretto: Can you explain why CVE-2022-30067 was rated as low?
[12:54] <ebarretto> luis220413, probably Steve set this as low because you need to have a crafted xcf file from an untrusted source and this will only cause a crash in the program
[12:55] <ebarretto> sorry but I am quite busy with other stuff right now and won't do much investigation
[12:56] <luis220413> OK. But deeper investigation is needed and will be done at another time.
[12:56] <luis220413> OK. But deeper investigation is needed and will be done later.
[12:57] <ebarretto> not by me, I trust my colleagues choice and if you think it otherwise then you should give us your reasoning. Do not that priority and severity are two different things
[12:57] <ebarretto> note*
[13:07] <luis220413> ebarretto: Can you mark qtbase-opensource-src in jammy as not vulnerable to CVE-2021-38593 and CVE-2022-25255 due to the message by mitya57?
[13:09] <luis220413> Can anyone else patch these CVEs for Focal? https://ubuntu.com/security/cves?q=&package=qtbase-opensource-src&priority=&version=focal&status=
[13:09] <luis220413> mitya57: Does your bug affect Ubuntu 18.04 or 20.04 on any architecture? (qtbase-opensource-src is in main in Ubuntu 18.04.)
[13:10] <luis220413> I will return in 45 minutes but remain online.
[13:13] <mitya57> luis220413: It doesn't, because it happens only with openssl 3.
[14:02] <luis220413> I am back.
[14:56] <luis220413> I will return in 10 minutes but remain online.
[15:06] <luis220413> I am back.
[15:14] <luis220413> teward: Are autopkgtests run automatically for stable releases?
[15:27] <luis220413> tsimonq2: What security updates have you made to packages in the universe component?
[15:36] <teward> luis220413: i would avoid bugging tsimonq2 on anything non urgent
[15:37] <teward> for reasons I'm not at liberty to disclose
[15:37] <teward> as for 'stablereleases' yes autopkgtests still trigger for those updates, it's how additional regression testing happens.
[15:37] <teward> but that's not a security related question here ;)
[15:38] <teward> i also strongly suggest you dial back the amount of pings you send people here, i tend to notice you like to ping people **a lot** - a lot more than you probably should be doing.
[15:49] <trench> luis220413: we don't care if you are away ..
[17:08] <luis220413> OK
[17:10] <luis220413> teward: I always ping to send replies, but others do not do so in most or all replies. From now on, I will not ping when not appropriate in a reply, by modifying the nick of the target user (for example, "t_eward: ...").
[17:29] <tsimonq2> luis220413: Why do you need to know how many security updates I've done when a) the number is more than 5 and b) as a core developer in the Ubuntu project I'm stepping up and volunteering to do work that will benefit everyone. All that question does is create FUD
[17:31] <tsimonq2> Anyway, besides dealing with that, I'll hop on this later tonight and at least get something pushed to Bileto or similar by US EOD, if mitya57 hasn't already beat me to the punch (which he often does nowadays, thanks!! :) )
[17:38] <Eickmeyer[m]> luis220413: Once again, I need to remind you that Ubuntu is a meritocracy, and here you are, questioning the qualifications of seasoned developers and their contributions within the project when you haven't been contributing for very long and have been acting in a very demanding and outright rude manner toward those who have.
[17:38] <Eickmeyer[m]> luis220413: This is your final warning to stop this behavior before I go to the rest of the Ubuntu Community Council to recommend you be banned from contributing to Ubuntu. Do I make myself clear?
[17:40] <luis220413> tsimonq2: I did not expect that my question will create FUD. I would happily say that I have done 8.
[17:40] <luis220413> Anyway, thanks for your security updates for stable releases!
[17:43] <teward> ebarretto: can i borrow your hammer please?
[17:43] <tsimonq2> Keep on flexing dude, you're already on thin ice, there's nothing more I can say or do here :)
[17:43] <teward> for two reasons.
[17:44] <luis220413> Eickmeyer[m]: Yes.
[17:44] <luis220413> I will prepare the qtbase-opensource-src security update for Ubuntu 20.04.
[17:45] <luis220413> in this week
[17:49] <tsimonq2> Nope, sorry, someone already volunteered. There's plenty else to do, the Ubuntu Qt Team has this one under control.
[18:00] <luis220413> ebarretto: Can you mark CVE-2021-38593 for qtbase-opensource-src in Focal as released (5.12.8+dfsg-0ubuntu2.1)?
[18:00] <luis220413> s/mark/set the status of/
[18:02] <luis220413> s/as released/to released/
[18:31] <luis220413> Bug 1987336
[18:34] <mitya57> tsimonq2: I have just uploaded the SRU :)
[18:35] <tsimonq2> >:D
[18:35] <tsimonq2> Thank you!!!!!!!!!
[18:44] <ahasenack> sarnold: hm, I tried using netplan to configure wireguard, but that didn't work: https://discourse.ubuntu.com/t/netplan-with-wireguard/30168
[18:45] <ahasenack> found a related bug in systemd-networkd, apparently fixed, but unclear if it needs an extra configuration (that netplan isn't doing) out of the box or not
[18:45] <sarnold> hey! an html anchor to the netplan docs! i've wanted those for ages
[18:45] <ahasenack> I had to "view source" to find it...
[18:45] <ahasenack> I was dearly hoping there would be one
[18:46] <sarnold> well, dang, it's still not the granularity I was hoping for -- eg the `key` a bit lower down doesn't appear to have an anchor point :( oh well..
[18:46] <ahasenack> the systemd docs say an extra route section is needed
[18:46] <ahasenack> let me update my post with links to that
[18:46] <sarnold> alright, back to netplan / wireguard, hehe
[18:48] <ahasenack> updated
[18:48] <ahasenack> I'm about to file a bug with netplan
[18:49] <ahasenack> now that I collected it all together in a post, it looks more and more like a bug
[18:49] <ahasenack> or unsupported feature
[18:49] <ahasenack> thing is, I can't even easily add the route myself in the .network file, because netplan would just rewrite it
[18:49] <ahasenack> so it would have to be something external
[18:52] <sarnold> oh my goodness this systemd issue gets complex
[18:52] <ahasenack> in systemd, what doesn't :)
[18:52] <ahasenack> I still can't figure out dns resolver
[18:52] <ahasenack> sometimes it works as I think it should, sometimes it surprises me
[18:52] <sarnold> wireguard seems simple, maybe even too simple, when you're configuring it via ip and wireguard commands, but translating all that into netplan configs to translate into systemd configs that then get executed .. oof
[18:53] <ahasenack> personally I have decided against netplan for wireguard, mainly because "netplan apply" disrupts everything
[18:53] <ahasenack> not just the wg interface
[18:53] <sarnold> never mind that I never got the hang of the multiple routing tables business
[18:53] <ahasenack> at this point I'm considering not documenting netplan + wireguard, for now
[18:53] <ahasenack> maybe just point at it, but "beware dragons"
[18:54] <sarnold> hmm. I can appreciate trying to leave breadcrumbs behind for the adventurous folks who want to try it out; but my experience with the apparmor wiki, which documents *lots* of things that don't yet exist, is that people *will* find it, they *will* try it, and they *will* ask for help and file bug reports when it doesn't work perfectly
[18:55] <ahasenack> true
[18:56] <ahasenack> right now this isn't working out of the box, at least not for me
[18:56] <ahasenack> let me just add the missing route manually, see if that is the only thing missing
[18:56]  * ahasenack goes to this cheat sheet about ip route commands
[18:57] <ahasenack> root@laptop-coffee-shop:~# telnet <IP_ADDRESS> 22
[18:57] <ahasenack> Trying <IP_ADDRESS>...
[18:57] <ahasenack> Connected to <IP_ADDRESS>.
[18:57] <ahasenack> Escape character is '^]'.
[18:57] <ahasenack> SSH-2.0-OpenSSH_8.9p1 Ubuntu-3
[18:57] <ahasenack> ok, worked
[18:57] <ahasenack> had to add `ip route add <IP_ADDRESS>/24 via <IP_ADDRESS>`
[18:58] <ahasenack> I'm on the "wireguard on the router" part of https://gist.github.com/panlinux/2bc62c10799284590e577de0640d2767
[18:58] <ahasenack> (diagram-wise)
[18:59] <sarnold> heh, I'm glad I'm not hte only one who needs the cheetsheets :) if it requires more than ip a ; ip l ; ip r   .. then help is required :)
[18:59] <ahasenack> "ip a show dev <nic>" is my strongest ip-foo that I know from memory
[18:59] <ahasenack> I also like "ip get route <ip>"
[18:59] <ahasenack> that's very handy
[19:00] <ahasenack> er, ip route get
[19:00]  * ahasenack blushes
[19:00] <sarnold> ahh, see, I never know the name of my nics any more ;( so it's hard to be confident there. ip route get <ip> is my headliner :)
[19:05] <ahasenack> well, without tab-complete, I wouldn't know either :)
[19:06] <sarnold> oh hey!
[19:14] <sdeziel> ahasenack: out of curiosity, howdid you end up with a wg0 MTU of 1378? The default is supposed to be 1420 IIRC
[19:14] <sdeziel> pppoe should shave 8 bytes but still ;)
[19:15] <ahasenack> I didn't mess with any of that
[19:15] <ahasenack> where did you see that again?
[19:15] <sdeziel> interesting, so that might suggest PMTU going on.
[19:15] <ahasenack> I just checked `ip a` and the mtu on the home0 wg interface is 1420
[19:16] <ahasenack> pmtu is working? *gasp*
[19:16] <sdeziel> https://gist.github.com/panlinux/2bc62c10799284590e577de0640d2767#testing has "ip link set mtu 1378 up dev wg0"
[19:16] <ahasenack> hmmm
[19:16] <ahasenack> wg-quick?
[19:16] <ahasenack> indeed
[19:16] <ahasenack> my other endpoing, which I brought up using wg-quickj, has an mtu of 1378
[19:17] <ahasenack> the one I brought up using netplan (via systemd-networkd), has an mtu of 1420
[19:18] <sdeziel> I use the systemd instance template (`wg-quick@%i`) and for those, the `[Interface]` section has to have a `MTU = XYZ` to no inherit the 1420 default
[19:18] <sarnold> hmm why do you need to change it?
[19:19] <ahasenack> sdeziel: tjat
[19:19] <ahasenack> sdeziel: that's what I have at the other endpoint
[19:19] <sdeziel> ahasenack: OK, so no PMTU ;)
[19:19] <ahasenack> sdeziel: https://pastebin.ubuntu.com/p/xtPkB7mVr2/
[19:20] <sdeziel> sarnold: I usually tweak it to 1440 when I'm 100% sure I won't tunnel stuff over IPv6
[19:20] <ahasenack> just the normal privatekey, listenport, address in [Interface]
[19:20] <ahasenack> btw, via netplan/systemd one does not have the hooks options, afaik
[19:21] <ahasenack> PostUp and stuff
[19:21] <sdeziel> ahasenack: hmm, maybe your default route has a lower MTU itself?
[19:21] <ahasenack> oh, its nic does have a lower mtuy
[19:21] <ahasenack> mtu
[19:21] <ahasenack> 1458
[19:21] <ahasenack> it's an openstack vm
[19:22] <ahasenack> ¯\_(ツ)_/¯
[19:22] <sdeziel> ahasenack: probably vxlan or geneve eating some MTU away
[19:23] <ahasenack> ok, well, no netplan for wireguard for now
[19:24] <sarnold> thanks for giving it a *really* good shot :)
[19:25] <ahasenack> I kept the text I wrote
[19:25] <Unit193> sarnold: But the systemd template is so easy. :3
[19:26] <ahasenack> https://gist.github.com/panlinux/49444e54ab109fe8399912a43553e105 is where I stopepd
[19:26] <ahasenack> Unit193: yeah, it is
[19:26] <ahasenack> I struggled to find a scenario where someone wouldn't use it
[19:26] <sarnold> Unit193: you mean the wg-quick@ thingy?
[19:27] <ahasenack> just wrote "if for some reason you cannot install wireguard-tools, or don't want to, then  you can ...."
[19:27] <ahasenack> I do see this flexibility a nice point in favor of wireguard, though
[19:27] <ahasenack> not that netplan or systemd-networkd are better, but just the fact you *could* use them, is something nice to have, and in favor of the design I think
[19:28] <sarnold> yeah,it's just too bad it's not there yet
[19:28] <ahasenack> I could try network-manager next
[19:29] <ahasenack> let's see how it is in jammy
[19:33] <ahasenack> hm, the integration isn't super nice, it doesn't show up in the top right network menu as one interface to activate or deactivate
[19:33] <ahasenack> presumably it can only be driven via the nm cli
[19:44] <Unit193> It shows up as a VPN option.
[19:44] <ahasenack> I don't see it
[19:44] <ahasenack> maybe I'm missing a package?
[19:44] <ahasenack> I had to use nm-connection-editor
[19:45] <ahasenack> then I deactivated it with nmcli
[19:45] <ahasenack> and now it doesn't show up in the nmcli devices list anymore, but is still in nm-connection-editor
[19:46] <ahasenack> it doesn't look like it's saving the private key
[19:47] <ahasenack> but yeah, I don't see it in the network menu on the top right of gnome-shell desktop
[19:54] <Unit193> I use network-manager-gnome.
[19:54] <ahasenack> yeah, it's what I have. Do you see the wireguard connection in the top right menu, that one that shows the network status?
[19:55] <ahasenack> I see wired, wifi, openvpn, and bluetooth
[20:00] <Unit193> I specifically wanted to hide it, as it had the VPN locked icon when I use that VPN for vLAN instead.
[20:00] <Unit193> But it had the lock icon when activated and it was in the VPN submenu of the tray icon.
[20:02] <ahasenack> Unit193: which ubuntu release?
[20:03] <Unit193> It's Xfce, I didn't know GNOME still used network-manager-gnome even.
[20:03] <ahasenack> ah, well, we are comparing different things then
[20:05] <Unit193> A bit, but nm does have it, and -gnome does expose it.  Weird that GNOME doesn't.
[20:19] <ahasenack> Unit193: what's the best practice to add another peer to an existing config without disrupting the existing connections? Write a config snippet with just the new [Peer] section, and use wg addconf, and then wg syncconf to merge it back to the main config?
[20:19] <ahasenack> or just update the main config with the new [Peer] and run wg setconf?
[20:19] <ahasenack> or something else?
[20:30] <Unit193> ahasenack: I'd do it just by adding it to the main config and systemctl reload wg-quick@wg0
[20:33] <ahasenack> I just tested:
[20:33] <ahasenack> a) add the new [Peer] to the wg0.conf file
[20:33] <ahasenack> b) run wg-quick strip wgnet0
[20:33] <ahasenack> well, wg0
[20:33] <ahasenack> that shows the new peer
[20:33] <ahasenack> and then maybe some wg command to set it on the interface, live
[20:33] <Unit193> ExecReload=/bin/bash -c 'exec /usr/bin/wg syncconf %i <(exec /usr/bin/wg-quick strip %i)'
[20:34] <ahasenack> ah, reload does that already
[20:34] <Unit193> Yes, that's why I said just reload. :>
[20:35] <Unit193> I poked zx2c4 about adding that a while ago.
[20:35] <ahasenack> and here I was doubting it would all work out of the box
[20:35] <ahasenack> nice packaging
[20:35] <sarnold> :D
[20:36] <ahasenack> cool, I had `watch wg` running elsewhere, and the reload action added the new peer
[20:37] <ahasenack> and the existing one still shows "latest handshake" about 48min ago, so it wasn't disrupted
[20:37] <Unit193> The goal is kinda to make it easy enough anyone can use it.  Looking at WireGuard and OpenVPN, the former is seemingly faster and seems easier to me, so why not? :3
[20:37] <Unit193> I know an IRC network that links it's servers over WireGuard, sooo...there's that.
[20:37] <ahasenack> indeed, nobody likes netsplits
[20:38] <Unit193> sarnold: No, not Libera either. :P
[20:39] <sarnold> hehe, I was going through that in my mind .. "on the one hand it's pretty cool, on the other hand, that's a lot of host keys to juggle"
[20:39] <Unit193> You say that as if the TLS certs aren't already that.
[20:41] <sarnold> "let acme sort it out"
[20:43] <ahasenack> what one could say is annoying is that the key has no metadata associated with it, at all
[20:43] <ahasenack> so unless you organize yourself, just inspecting the key won't tell you who it belongs to
[20:43] <ahasenack> which can be a plus too
[20:43] <Unit193> Yeah, adding an alias in the config for it to show in `wg` output would be nice.
[20:44] <ahasenack> compounded with the fact that you don't use files for the keys in the config
[20:44] <ahasenack> just the content itself
[20:44] <ahasenack> yeah, a Description= or Name= field in the config
[20:44] <ahasenack> which, if present, would be shown in the wg output
[20:45] <sarnold> sticking keys in the config feels pretty dangerous imho; people pastebin configs *all the time* and remembering to strip out the keys first is asking for trouble
[20:45] <sarnold> or throw configs in git..
[20:46] <Unit193> wg | grep -c peer: → 11 :(
[20:46] <sarnold> wow :)
[20:47] <ahasenack> Unit193: I was just reminded in #wireguard that the systemd reload action won't create any routes, for example, like wg-quick would when bringing the interface up from scratch
[20:48] <ahasenack> Unit193: yeah, good point, I'll add that to the doc
[20:48] <Unit193> Good point?  What point?
[20:49] <ahasenack> about the private key being in the config file, and people pasting the config thinking it has only config, not secrets
[20:49] <Unit193> And yeah that's noteworthy indeed.  I wouldn't say I'm a WireGuard expert, btw.  I only use it.
[20:49] <Unit193> ...If I can take credit for sarnold's ideas, I'm going to look *so* much smarter very quickly. :D
[20:50] <sarnold> only if I can offload the doozies, too!
[20:50] <ahasenack> oops, true
[20:50] <ahasenack> sorry sarnold
[20:53] <sdeziel> ahasenack: re private keys in config files, I instead do: `PostUp = wg set %i private-key /etc/wireguard/%i.key` and the .key file is root accessible only
[20:54] <ahasenack> good point, I've seen that in some config examples
[20:54] <sdeziel> that still leaves PresharedKey directly under each [Peer] though...
[20:55] <ahasenack> the same trick doesn't apply?
[20:55] <ahasenack> [preshared-key <file path>]
[20:55] <ahasenack> looks like it can be uset with "wg set" too, same command line, just one more parameter?
[20:55] <sdeziel> you can possibly load it but then it's harder because you don't have the `%i` trick
[20:56] <ahasenack> ah, it's under a peer
[20:56] <ahasenack> ofc
[20:56] <sdeziel> yeah :/
[20:58] <ahasenack> and `wg showconf <interface>` strips out the wg-quick bits (it doesn't know about them)
[20:59] <ahasenack> this overloading of wg and wg-quick configs is a bit odd
[20:59] <ahasenack> s/overloading/mixing up/
[21:01] <sarnold> it certainly confuses me, heh
[21:02] <ahasenack> it's what allowed all these other tools to exist
[21:02] <ahasenack> wg-quick does what systemd-networkd does, netplan, network-manager, cloud-init even
[21:02] <Unit193> ifupdown!
[21:02] <ahasenack> actually, I don't know what tool cloud-init does, I doubt it interacts directly with the kernel
[21:02] <ahasenack> hehe
[21:02] <ahasenack> oh yeah, debian
[21:03] <ahasenack> just checked, cloud-init is relying on wg-quick@<if>
[21:04] <sarnold> ifupdown2!
[21:04] <ahasenack> and just saw something we could make better: https://github.com/canonical/cloud-init/pull/1570/files#diff-2bd8283d4911d29b15ad597ad65cf85e585b9ff285df6b766d0708fad8d8d4acR42
[21:04] <ahasenack> they are sayhing to install resolvconf, but we can use resolvectl in postup hooks


[00:00] <lifeless> zyga: we've executed the workaround again; the error should be gone for a while
[00:02] <zyga> lifeless, I read your comments, my new key (the one that is failing) is needed valid for a different period, perhaps the system checking the key has incorrect time/
[05:04] <james_w> Lots of 500 errors from the API for the last few minutes?
[05:05] <james_w> No time to look in to it now I'm afraid, but if someone could check that it's not systemic that would be great
[05:05] <wgrant> james_w: No OOPS IDs?
[05:08] <james_w> 2012AU139 is one
[05:09] <wgrant> Thanks.
[05:09] <james_w> From many different methods
[05:10] <wgrant> james_w: It's apparently crashing during OAuth.
[05:10] <wgrant> May be specific to your consumer token.
[05:11] <james_w> This is multiple services, multiple tokens, multiple users
[05:11] <lifeless> SSO may have fallen over
[05:12] <wgrant> OAuth doesn't use SSO.
[05:12] <james_w> Multiple machines too
[05:12] <wgrant>   Module storm.database, line 366, in _check_disconnect
[05:12] <wgrant>     return function(*args, **kwargs)
[05:12] <wgrant> DataError: integer out of range
[05:12] <lifeless> rollover"?!
[05:13] <wgrant> Possibly. AFAICT it's on an INSERT that works fine locally, though.
[05:13] <wgrant> But maybe it only logs after the bit that crashed...
[05:13] <wgrant> That's more likely.
[05:14] <james_w> Started around 03:46 GMT
[05:15] <wgrant> It seems to be the OAuthNonce INSERT, looking at the code.
[05:15] <wgrant> But how.
[05:15] <james_w> Now I must sleep. Call me if you need me, but I think any of you should be able to reproduce
[05:16] <spiv> Or just look at the package importer :/
[05:16] <james_w> Yeah
[05:16] <wgrant> Indeed, I've reproduced. Thanks for letting us know.
[05:16] <StevenK> wgrant: Need any help?
[05:17] <james_w> Or ask a GSA about ubuntu status @cranberry
[05:17] <james_w> Night
[05:17] <james_w> Thanks wgrant
[05:17] <james_w> My inbox appreciates it :)
[05:29] <wgrant> james_w: Fixed.
[07:39] <apw> anyone know if there is an email update syntax to update a specific nomination task?  affects ubuntu/natty/linux stylee ?
[07:54] <wgrant> apw: What you suggested should work.
[07:55] <spiv> apw: https://help.launchpad.net/Bugs/EmailInterface#affects is the reference
[07:57] <apw> spiv, that shows like ubuntu/linux but doesn't hint that ubuntu/natty/linux is valid
[08:10] <mrevell> B'jour
[10:30] <apw> wgrant, testing shows the full triplet does work, that probabally should be added to the docs
[12:04] <doctormo> guillemhs?
[13:59] <bjsnider> am i doing something wrong that launchpad keeps hanging on the last 1k of a source package upload?
[14:12] <abentley> bac: how would I mute all bugs for https://bugs.launchpad.net/rabbitfixture ?  They are sent to me because ~lazr-developers is the registrant.
[14:37] <deryck> abentley, adeuring -- we'll take interrupt work this week, since last week was our week and we were in Dublin.
[14:38] <deryck> and hi, btw :)
[14:38] <abentley> deryck: hi, roger.
[14:38] <adeuring> deryck: ah, right
[14:39] <deryck> adeuring, abentley -- I suspect the queues might need extra attention the next couple days to catch them up.
[14:39] <adeuring> yeah...
[14:59] <cr3> I'm suddenly getting this error when trying to run a local instance of launchpad, any ideas? Ident authentication failed for user "launchpad_main"
[15:00] <cr3> nevermind, found the problem in my postgres configuration. my fault :)
[15:05] <mneptok> but you guaranteed finding that facepalm conf file problem in 30 seconds by asking on IRC
[15:07] <cr3> mneptok: who's palm, yours or my own?
[15:08] <cr3> must be yours, mine is busy right now...
[15:09] <mneptok> cr3: http://www.checkoutmyink.com/assets/photos/0106/5853/6541529890a10375013383l_large.jpg?1242269658
[15:14] <happyaron> can any launchpad admin deal with this? https://bugs.launchpad.net/ubuntu/+source/ucimf-openvanilla/+bug/605363/comments/10
[15:14] <happyaron> I mean the comment itself is purely spam.
[15:17] <deryck> happyaron, hi.  I can deal with it for you.
[15:18] <happyaron> deryck: thanks
[15:18] <deryck> happyaron, np.  should be gone now.
[15:18] <happyaron> yeah
[15:40] <genii-around> Hello. I'm a recent Ubuntu member. It looks like the ubuntu.com email forwarding may be going to my old primary LP email which no longer exists ( I changed my primary on LP to go to my gmail instead a while ago now ).
[15:41] <nigelb> genii-around: "a while ago"  = ?
[15:41] <nigelb> a few hours? a few days?
[15:42] <genii-around> nigelb: Months
[15:42] <nigelb> genii-around: and your launchpad ID/
[15:42] <nigelb> ?
[15:43] <genii-around> nigelb: mystic-scientist
[15:43] <nigelb> (I don't have powers to look what's wrong, but it'll help whoever might be around)
[15:44] <genii-around> OK, thanks
[15:44] <tsimpson> genii-around: you may have better luck in #canonical-sysadmin (maybe)
[15:45] <genii-around> tsimpson: OK... I'll try there in a little while when I go to lunch... work has me back and forth from computer right now
[15:59] <deryck> hi, genii-around.  Did you find any help for the email issue?  Or still need someone?
[16:01] <genii-around> deryck: Apologies on lag, work. No assistance yet, was going to try #canonical-sysadmin in a couple minutes when lunch begins
[16:02] <deryck> genii-around, ok, I can ask around about what to do too.
[16:47] <jdobrien> acklog 1
[17:50] <deryck> abentley, tag, you're it.
[17:51] <abentley> deryck: ack.
[17:52] <hyperair> can we have https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/489293/comments/4 removed?
[18:19] <abentley> hyperair: I've hidden it and notified the user.
[18:19] <hyperair> abentley: thanks
[18:20] <hyperair> abentley: it might be a good idea to look for other such comments from the same user and hide them as well
[18:20] <TheEvilPhoenix> abentley is it against policies to put a package which contains a program which is copyrighted into a Launchpad PPA (even though I own the copyright on the program)?
[18:21] <TheEvilPhoenix> s/policies/Launchpad policies/
[18:21] <abentley> hyperair: I don't think there is a way to search for other comments by that user.
[18:21] <hyperair> abentley: oh okay
[18:21] <Ampelbein> TheEvilPhoenix: most of the software in ubuntu is copyrighted. it's the license that matters.
[18:21] <TheEvilPhoenix> Ampelbein, which licenses are acceptable?
[18:23] <Ampelbein> TheEvilPhoenix: See https://help.launchpad.net/PPATermsofUse


[00:06] <wgrant> lifeless: Yes, it's on LPS, but that normally gets ignored :)
[00:06] <lifeless> gawd I hope not
[00:07] <lifeless> so whats special
[00:07] <lifeless> also when is good for you
[00:07] <wgrant> It needs buildd-manager to be shut down before the update, then process-upload run, then proceed as normal.
[00:08] <lifeless> why?
[00:08] <wgrant> The directory name format has changed.
[00:09] <wgrant> And accepting and testing both seems more trouble than having a slightly special one-off upgrade.
[00:12] <lifeless> maxb: https://code.launchpad.net/~launchpad-committers/lpreview-body/packaging
[00:12] <lifeless> is done
[00:12] <lifeless> the other needs the regression in LP fixed
[00:13] <maxb> thanks
[00:13] <lifeless> maxb: can you follow up on the list so folk know
[01:21] <lifeless> wgrant: so whats the filename format change about
[01:21] <wgrant> lifeless: Removing BuildFarmJob.id.
[01:21] <wgrant> It was used to identify temporary upload directories.
[01:21] <lifeless> what did the filename encode, what does it encode, why does it encode it
[01:22] <wgrant> So, buildd-manager takes an upload and dumps it into a directory for process-upload.py --builds to handle.
[01:22] <wgrant> It used BuildFarmJob.id to identify the relevant build.
[01:22] <wgrant> Now it uses the job type and BPB/SPRB ID.
[01:22] <lifeless> is that in a metadata file or the dirname?
[01:23] <wgrant> dirname.
[01:23] <wgrant> (yes, ew)
[02:01] <LPCIBot> Yippie, build fixed!
[02:01] <LPCIBot> Project db-devel build #519: FIXED in 5 hr 12 min: https://lpci.wedontsleep.org/job/db-devel/519/
[02:03] <lifeless> wgrant: when would you like to talk?
[02:12] <wgrant> lifeless: Now's good for me.
[02:15] <wgrant> lifeless: You still prefer Skype?
[02:24] <lifeless> cooking lunch, will ping in a bit
[02:25] <wgrant> Sure.
[03:06] <lifeless> wgrant: ping
[03:07] <LPCIBot> Project windmill-db-devel build #240: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/240/
[03:12] <LPCIBot> Project windmill-devel build #38: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/38/
[03:16] <wgrant> lifeless: Hi.
[03:16] <lifeless> hi
[03:16] <wgrant> I'm ready.
[03:16] <lifeless> voip or skype is bestest
[03:16] <wgrant> I'm on Skype, I've not got SIP set up.
[05:37] <lifeless> poolie: jetlag?
[05:52] <lifeless> hmm, code free day :(
[06:09] <lifeless> wgrant: https://bugs.launchpad.net/launchpad/+bug/777794 - please triage as you file :)
[06:09] <_mup_> Bug #777794: Bug subscription AJAX popups are too bold <Launchpad itself:New> < https://launchpad.net/bugs/777794 >
[06:10] <lifeless> 777789 too
[06:10] <lifeless> and 777786
[06:10] <wgrant> lifeless: I can't triage those.
[06:10] <lifeless> why not?
[06:10] <StevenK> Hm, I meant to file a low bug about that
[06:11] <wgrant> Because I don't know what importance they are.
[06:11] <lifeless> wgrant: take a good guess
[06:11] <wgrant> Given that there is meant to be a UI polish mode at the end of each feature, they should probably be High.
[06:11] <wgrant> But I don't know.
[06:11] <lifeless> the feature squads are not watching the tracker.
[06:11] <StevenK> If you set the importance and such like when you file a bug, we shouldn't say "Your bug will be triaged soon"
[06:11] <StevenK> Perhaps ...
[06:11] <wgrant> StevenK: That's for external people.
[06:11] <lifeless> StevenK: that prose is just the post-filing-notice, its not programmatic
[06:12] <wgrant> Right.
[06:13] <lifeless> wgrant: please triage them, even if its just to high + an email to gary to say 'these need your hand to really assign importance'.
[06:13] <lifeless> wgrant: you can certainly assess them in the context of the BugTriage wiki page
[06:15] <lifeless> wgrant: a nontrivial reason for doing is so that end user filed bugs which are not triaged are obvious on the portlets on https://bugs.launchpad.net/launchpad-project/+bugs
[06:15] <lifeless> the [non]zero distinction is easier for everyone to observe than a floating figure
[06:20] <poolie> hi lifeless
[06:20] <poolie> a bit
[06:37] <wgrant> DF's up to 62GB... this is going to take a little while.
[06:38] <StevenK> As in DF's DB?
[06:38] <wgrant> Yes.
[06:38] <wgrant> Hmm. Might need to clean some stuff out.
[06:38] <wgrant> lifeless: \l+ on staging?
[06:38] <lifeless> its fat too
[06:38] <lifeless> it has the garbo running nowadays
[06:39] <lifeless> qastaging is 275GB fwiw
[06:40] <lifeless> wgrant: ok, I've triaged your  bugs... next time I'll make em all opinion :P
[06:45] <lifeless> ohh nice
[06:45] <lifeless> +patches gone from oopses
[06:48] <wgrant> lifeless: Thanks.
[07:25] <wgrant> Hmm, the missing structural subscription listing a bit unfortunate.
[07:33] <LPCIBot> Project windmill-db-devel build #241: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/241/
[08:14] <LPCIBot> Project windmill-db-devel build #242: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-db-devel/242/
[08:59] <adeuring> good morning
[09:04] <mrevell> Hello!
[09:06] <poolie> hi mrevell
[09:06] <poolie> lifeless, did people ever consider changing the ec2 image to run tests on a tmpfs?
[09:06] <poolie> it doesn't seem to be using its whole cpu
[09:07] <bigjools> good morning
[09:12] <poolie> hi bigjools
[09:12] <lifeless> poolie: I don't think our ec2 stack has been all that optimised
[09:12] <lifeless> bigjools: missed you this morning
[09:12] <bigjools> lifeless: yeah sorry
[09:12] <lifeless> no worries
[09:12] <bigjools> was knackered
[09:12] <lifeless> perhaps we could talk in ~30 ?
[09:13] <bigjools> lifeless: I have a standup, but in  ~45 would work
[09:14] <lifeless> ok
[09:18] <LPCIBot> Project windmill-devel build #39: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-devel/39/
[10:38] <poolie> hm so just moving bits of /var to ram doesn't immediately fail
[10:39] <poolie> and is doing little io
[10:39] <poolie> still lots of idle cpu, but i think that's just lack of parallelism
[10:55] <wgrant> bigjools: Bug #778408 may amuse you.
[10:55] <_mup_> Bug #778408: Deleting an unpublished publication behaves unexpectedly <soyuz-ftpmaster-tools> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/778408 >
[10:57] <wgrant> (Side-effects of amusement may include uncontrollable sobbing and a sense of hopelessness.)
[11:00] <al> hehehe
[11:04] <wgrant> rvba: Have you seen the stable->db-devel merge conflict? It seems to be your stuff.
[11:04] <wgrant> So you're probably best to resolve it.
[11:05] <rvba> wgrant: I just saw that.
[11:06] <rvba> wgrant: can you guide me with how I can fix that?
[11:07] <rvba> wgrant: I understand the problem of course but I'm unsure about the procedure to solve it.
[11:07] <bigjools> wgrant: colour me unsurprised
[11:07] <wgrant> rvba: Grab stable and db-devel locally, merge stable into db-devel, fix the conflict as you would normally. Push the branch up somewhere, then pqm-submit it to db-devel.
[11:07] <bigjools> wgrant: we need yet more code to stop people from being stupid
[11:08] <wgrant> rvba: if you are feeling forgiving you could ask for a review, but I never do and haven't broken anything yet.
[11:08] <rvba> wgrant: thanks. I'll do that.
[11:24] <wgrant> bigjools: Do you have a list of stuff to kill from mawson? Its free space will probably not last the weekend.
[11:24] <bigjools> wgrant: yeah I was looking at that
[11:24] <wgrant> We could just start wiping out the archive, I guess.
[11:24] <bigjools> yes
[11:24] <bigjools> that archive is too fat
[11:24] <wgrant> Easy enough to bring back in a few hours if we need to.
[11:24] <wgrant> (sorry mizuho)
[11:24] <wgrant> It is fat, but was useful for testing a few things.
[11:25] <wgrant> But that's all done now.
[11:25] <bigjools> can be restored easy
[11:25] <bigjools> given time :)
[11:25] <wgrant> Yep.
[11:25]  * wgrant deletes.
[11:25] <wgrant> Mass deletion + restore == molten mawson?
[11:25] <bigjools> I bet it's hot it mawson's cabinet :D
[11:25] <bigjools> s/it/in/
[11:26] <bigjools> wgrant: it'll all be invalid once the db is restored anyway
[11:27] <bigjools> local librarian is 5.2G, purging
[11:27] <wgrant> Not really. This is all from frozen series.
[11:27] <wgrant> maverick + natty
[11:27] <bigjools> not all
[11:27] <bigjools> not sure they weren't frozen when we last restored
[11:28] <wgrant> maverick was released, and natty was basically identical to maverick.
[11:28] <wgrant> So it was mostly just maverick's final packages plus a few more.
[11:28] <wgrant> Anyway, deleting now.
[11:28] <wgrant> Very slowly.
[11:29] <bigjools> the disk stepper motor is going to fall off its track
[11:33] <LPCIBot> Project windmill-devel build #40: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-devel/40/
[11:55] <rvba> wgrant: would you mind taking a look at this for a quick sanity check? https://code.launchpad.net/~rvb/launchpad/db-devel-fix-merge-failure
[11:57] <wgrant> rvba: The diff is large, but as long as the tests you've changed pass it should be fine.
[11:58] <rvba> wgrant: yeah, the tests in the modified file pass.
[11:59]  * rvba bzr pqm-submit -m "Merge stable."
[12:01] <wgrant> rvba: You'll need a --submit-branch
[12:01] <bigjools> "fix conflict with stable" would be more accurate
[12:01] <wgrant> To target db-devel.
[12:01] <bigjools> and that
[12:01] <rvba> wgrant: oops ... too late.
[12:02] <wgrant> It should reject it.
[12:02] <lifeless> rvba: hi; its my weekend now, but wgrant may be able to answer your perf tuning thing if you're lucky
[12:03] <lifeless> rvba: otherwise I'll shoot you some thoughts on mondayish
[12:03] <wgrant> Where's that?
[12:03] <lifeless> wgrant: I'l forward
[12:03] <rvba> lifeless: thanks a lot. Have a good weekend!
[12:03] <wgrant> I have no email client at the moment, but I'll get one in a sec.
[12:06] <wgrant> rvba: So, what's the issue with it being a list?
[12:06] <wgrant> rvba: checkCopy is already pretty fast, except for one code path.
[12:06] <rvba> wgrant: since it's not a ResultSet there is not way to try to eager load related objects ... right?
[12:07] <rvba> s/not/no/
[12:07] <wgrant> rvba: You can't add a preiter hook to it, no. But that's just a handy place to do it... you can do the same thing manually afterwards.
[12:07] <wgrant> What are you looking to eager-load?
[12:09] <wgrant> (the slow bit is when _checkArchiveConflicts finds some destination_archive_conflicts)
[12:09] <rvba> I was just *thinking* of eager-loading related things since I saw the the kind of db queries issued looked like related objects being loaded.
[12:09] <rvba> but I might be wrong.
[12:10] <rvba> I you say it's pretty quick already, it might not be worth the bother then.
[12:10] <wgrant> It's already pretty good. Most copies check within half a second, except for _checkArchiveConflicts.
[12:10] <wgrant> So yeah, not worth spending time on that yet.
[12:10] <rvba> s/I/If
[12:11] <rvba> ok, so I guess the tests to make sure the number of queries does not increase is enough for now.
[12:11] <wgrant> Yup.
[12:11] <wgrant> That would be useful.
[13:47] <gmb> adeuring: Can you take a look at https://code.launchpad.net/~gmb/launchpad/bug-772609/+merge/60176 for me please?
[13:47] <adeuring> gmb: sure
[13:48] <gmb> Thanks
[13:48] <LPCIBot> Project windmill-db-devel build #243: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-db-devel/243/
[13:58] <deryck> Morning, all.
[14:15] <jtv> hi deryck
[14:15] <deryck> hi jtv
[14:22] <adeuring> gmb: overall, nice work. but could you remove the "#import pdb; pdb.set_trace()" line in test_bugs_views.py?
[14:23] <SteveA> yay, code reviews :-)
[14:23] <adeuring> gmb: and you disabled the get_notified_subscribers() call in bugs/subscribers/bug.py
[14:24] <adeuring> gmb: there is an XXX from bac about the call which has no bug number
[14:24] <adeuring> gmb: also, I am not sure if we can really simply drop the call.
[14:26] <adeuring> deryck: could you please run these queries  on staging: https://pastebin.canonical.com/47200/ ?
[14:26] <deryck> adeuring, indeed I can.
[14:29] <LPCIBot> Project windmill-db-devel build #244: STILL FAILING in 40 min: https://lpci.wedontsleep.org/job/windmill-db-devel/244/
[14:41] <deryck> benji, I'm triaging bug 778323 as high as I assume it's related to y'all's current work.  Is story-better-bug-notification  still the best tag?
[14:41] <_mup_> Bug #778323: On the subscription page, the help popup button opens up a 404 page. <Launchpad itself:Triaged> < https://launchpad.net/bugs/778323 >
[14:41] <benji> deryck: yep, that's the current tag
[14:42] <deryck> benji, cool.  done.  Thanks
[14:44] <deryck> I don't think anyone understood the implications of dropping ~launchpad-bugs mailing list.
[14:46] <jtv> danilo, henninge: I wonder if those links in the "untranslated" etc. numbers on the overview pages disappeared because of the Prague work.
[14:54] <danilos> jtv, I don't know, I don't have the time to investigate right now
[14:54] <jtv> Same here.  :(
[14:55] <danilos> jtv, I filed a bug so when I switch to maintenance I'll take a look
[14:55] <jtv> OK
[14:55] <danilos> jtv, it's tagged "regression", which makes it "Critical"
[14:56] <jtv> I guess it doesn't absolutely require a Rosetta veteran.
[14:56] <jtv> Hi Ursinha
[14:56] <danilos> jtv, indeed
[14:56] <jtv> I wonder why I'm suddenly being showered in bugmail.
[15:01] <deryck> Hi, gmb.  Could I get you to review my GCC credentials branch for me?  It's simple, but I want to make sure I haven't missed something I don't know about.
[15:01] <gmb> deryck: Sure thing. Diff me.
[15:02] <deryck> gmb, lp branch is:  https://code.launchpad.net/~deryck/launchpad/add-gcc-keys-schema-lazr-745794/+merge/60186
[15:02]  * gmb looks
[15:02] <gmb> Oo, complex!
[15:02] <deryck> heh
[15:03] <gmb> That looks fine.
[15:03] <deryck> gmb, and I did a matching lp-production-configs one first:  https://code.launchpad.net/~deryck/lp-production-configs/add-gcc-bugzilla-creds/+merge/59956
[15:03] <deryck> gmb, so I understand land the lp branch, nodowntime rollout, then the lp-production-configs one, yes?
[15:03] <gmb> deryck: I believe so. I haven't had to do one of these since before there were nodowntime rollouts.
[15:04] <gmb> But that sounds sane.
[15:04] <deryck> gmb, ok, cool.  yeah, this is my first config change believe it or not.
[15:04] <gmb> Ah, always fun.
[15:08] <wgrant> deryck: Land the branch, land the configs, nodowntime rollout.
[15:08] <wgrant> No need for a rollout in the middle.
[15:08] <deryck> wgrant, ah, ok.  thanks.
[15:09] <deryck> wgrant, and no need for any special rollout requirements, i.e. the usual nodowntime will cover everything I need?
[15:09] <wgrant> deryck: That's right.
[15:09] <deryck> wgrant, awesome sauce.  thanks, again.
[15:09] <wgrant> We grab the requested rev of stable and the latest lp-p-c rev.
[15:09] <deryck> gotcha
[15:34] <LPCIBot> Project windmill-devel build #41: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-devel/41/
[15:36] <adeuring> gmb: did you see my questions about your mp?
[15:37] <gmb> adeuring: Oops, missed them. Let me look...
[15:37] <adeuring> bac: are you around?
[15:37] <gmb> Ahaha
[15:37] <gmb> Thanks for catchign that pdb.
[15:39] <gmb> Oh. I don't remember removing that...
[15:40] <adeuring> gmb: np. but can we reall drop the get_also_notified_subscribers() call?
[15:40] <gmb> Ah, I see. That's from bac's work and I've not spotted it...
[15:40] <gmb> adeuring: Hmm. Lemme check.
[15:41] <gmb> adeuring: I honestly don't know.
[15:41] <bigjools> adeuring: hi, I've got a small branch in the queue, no rush.  TIA :)
[15:41] <gmb> adeuring So, I'll put it back and run EC2 and see what happens.
[15:41] <adeuring> bigjools: I'll look
[15:41] <adeuring> gmb: ok, sounds good
[15:42] <gmb> Ta
[15:43] <jcsackett> sinzui: would you like to mumble this morning?
[15:51] <beuno> hello lp devs
[15:51] <beuno> I _love_ this new email management story
[15:51] <beuno> I get this:
[15:51] <beuno> Launchpad Bug Contacts subscription: (unnamed)You do not receive emails from this subscription
[15:51] <beuno> any idea what the (unnamed) bit is?  should I file a bug?
[15:52] <huwshimi> beuno Did you give the subscription a name?
[15:52] <huwshimi> beuno: Did you just create the subscription or was it an old one?
[15:52] <beuno> huwshimi, no, not even sure where (or why!) to do that
[15:52] <beuno> huwshimi, old
[15:52] <jcsackett> allenap: i've made changes to the branch you looked at yesterday, if you could take another look.
[15:53] <huwshimi> beuno: I don't know heaps about it, but I'm guessing you might be able to give it a name somwhere
[15:54] <beuno> huwshimi, why would I want to name something so efimeral?
[15:54] <huwshimi> beuno: Are you around somewhere and have a minute? I wouldn't mind looking at the UI of what you have.
[15:55] <wgrant> Anyone in ~launchpad can see the same thing at https://launchpad.net/launchpad/+subscriptions
[15:55] <beuno> huwshimi, I am! I'm in the canonical sumit room, and would love to meet you. I have another hour of sessions, but then I'm free.
[15:56] <deryck> beuno, if you name it, bug mail gets the name in headers and in the footer of emails, to help you filter on that name.
[15:56] <huwshimi> beuno: I'll try to catch you at some stage. Not sure what I'll be doing in an hour though
[15:57] <beuno> deryck, right, that makes a bit of sense
[15:57] <huwshimi> deryck: Does that mean someone needs to go back to the subscription and give it a name?
[15:57] <beuno> huwshimi, I'm here this and next week
[15:57] <huwshimi> beuno: ok, I'll be around until Wednesday
[15:59] <deryck> beuno, huwshimi -- you can edit the subscriptions off the target or the +subscriptions or +structural-subscriptions pages, I believe.
[15:59] <adeuring> bigjools: r=me
[15:59] <bigjools> adeuring: cheers
[16:00] <deryck> beuno, huwshimi -- should be able to name it from:  https://launchpad.net/launchpad for example
[16:00] <beuno> deryck, so maybe it needs a default name?
[16:01] <deryck> I may have some details wrong, though, since it's Yellow Squad working on this now :-)
[16:01] <deryck> beuno, yeah, probably some string concact of $target-$user-sub or some such.
[16:01] <deryck> (Unamed) seems not clear or useful
[16:01] <allenap> jcsackett: Already done :)
[16:02] <jcsackett> \o/ thanks, allenap!
[16:04] <danilos> beuno, there should still be old headers which one used to use for subscriptions filtering
[16:04] <deryck> beuno, can you file a bug?  I can triage it and assign to story tag.
[16:05] <danilos> beuno, fwiw, the bug mail you might have started getting could be due to a change in launchpad product configuration, and is unrelated to the beta fwiw
[16:05] <danilos> deryck, thanks for helping out with this :)
[16:07] <deryck> danilos, np. :-)  I don't mean to nosy my way into your work ;)
[16:07] <danilos> deryck, not at all, just go ahead, I am off now as well :)
[16:07] <deryck> ok cool :-)
[16:08] <danilos> deryck, and we appreciate all the help we can get :)
[16:08] <deryck> It's an awesome feature.  Many will love it.
[16:08] <danilos> as long as launchpadders don't confuse this configuration change with the feature :)
[16:09] <danilos> (i.e. ~launchpad losing the contact address)
[16:10] <beuno> deryck, I can
[16:11] <beuno> danilos, right, no, I get the same amount of email (I was subscribed to everything)
[16:11] <huwshimi> danilos: But this change should mean you can stop getting all that mail though right?
[16:11] <beuno> this was me taking advantage of muting some email  :)
[16:11] <danilos> huwshimi, right
[16:11] <beuno> deryck, I'll file the bug, I need the karma
[16:11] <danilos> beuno, I am sure you'll find a bunch of bugs to report :)
[16:12] <huwshimi> danilos: Do you know how I can mute all of this new mail?
[16:13] <deryck> I don't even see why we need ~launchpad-bugs.  Just unsubscribe it from the ~launchpad, no?
[16:14] <deryck> isn't that the account causing issues?  huwshimi ^^
[16:14] <huwshimi> deryck: I think it might be
[16:14] <wgrant> ~launchpad-bugs' subscription to /launchpad can be removed by a Launchpad admin. But it's not the main problem.
[16:14] <deryck> ah
[16:14] <wgrant> ~launchpad also gets vcs-imports spam, loggerhead question spam, probably launchpad-reviewers MP spam.
[16:14] <deryck> ah
[16:14] <wgrant> None of that is fixable.
[16:14] <deryck> and ~launchpad lost it's email address
[16:14] <deryck> I see
[16:15] <wgrant> We may have to readd the address, once everyone is pissed off enough to file critical bugs about all the unstoppable mail.
[16:15] <huwshimi> deryck: It's not just that. I'm getting heaps of mail from Loggerhead and stuff now too
[16:15] <wgrant> But until we have lots of bugs filed it would be silly to readd it.
[16:15] <wgrant> Because we'd never fix it properly.
[16:15] <deryck> yeah
[16:15] <wgrant> (see eg. the last 5 years of having a contact address)
[16:16] <deryck> we just shouldn't expand teams to individual emails.  why would anyone really want that ever?
[16:16] <deryck> could be easier to fix than file the bug ;)
[16:16] <wgrant> deryck: Then who gets the mail?
[16:17] <wgrant> eg. ~launchpad is an admin for some teams. Who gets the mail that somebody is trying to join?
[16:17] <danilos> huwshimi, you should be able to go to any of the bugs with emails, click on "Edit bug mail" and mute the team subscription
[16:17] <deryck> wgrant, if you don't set a contact for the team, no one.
[16:17] <wgrant> I think team subscriptions to any object are stupid and should be banned.
[16:17] <danilos> huwshimi, with something like "Don't send me email"
[16:17] <wgrant> But we use subscriptions for security too.
[16:17] <wgrant> So we can't do that.
[16:17] <deryck> create a security mailing list for the team that people optionally subscribe to.
[16:18] <deryck> this is how the rest of the world works, no?
[16:18] <huwshimi> danilos: Thanks
[16:18] <wgrant> This sounds a lot like working around an incomplete advanced subscriptions feature to me :)
[16:18] <deryck> maybe in one sense
[16:19] <deryck> but I think my point is that you want a security or team mailing list, not a team subscription.
[16:19] <danilos> wgrant, for security stuff, direct subscriptions are created for the security contact on all security bugs
[16:19] <deryck> that magically expands
[16:19] <huwshimi> danilos: What about stuff that comes from questions etc?
[16:19] <LPCIBot> Project windmill-db-devel build #245: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/245/
[16:19] <wgrant> deryck: Why?
[16:19] <danilos> huwshimi, can't help there, other than filtering
[16:20] <huwshimi> danilos: OK thanks :)
[16:20] <wgrant> deryck: Security email isn't special enough that it deserves a list. That's just the only way it can sensibly be done now, because LP is broken.
[16:20] <wgrant> Hmm, poolie's not here.
[16:20] <wgrant> We should unsubscribe loggerhead-team from loggerhead's questions.
[16:20] <wgrant> That will stop a lot of the immediate spam.
[16:21] <deryck> wgrant, maybe you're right.  I'm just being clear that the rest of the world uses a security mailing list, not team membership to manage security bugs.
[16:21] <deryck> and that we're conflating the two
[16:21]  * danilos -> really out
[16:21] <deryck> what happened now is that we have a team subscribed for many reasons, not to manage mail
[16:21] <deryck> and the conflation is the issue.
[16:21] <wgrant> Right.
[16:21] <wgrant> A lot of these reasons are obsolete.
[16:21] <deryck> right
[16:22] <wgrant> Ah, flacoste is readding the address now.
[16:22] <deryck> and that's all I mean.  I don't mean to overanalyze or suggest the one true way to fix it.  just pointing out the root issue.
[16:22] <wgrant> deryck: The root issue is that we need to separate permission and subscription, and we probably also want to extend the excellent new structural subscription stuff to cover everything.
[16:23] <flacoste> wgrant: yeah, PQM bot will receive all the email we are receiving
[16:23] <wgrant> flacoste: We should really fix that PQM bug.
[16:23] <flacoste> so it will be sending those kind of error message in a lot of case
[16:23] <deryck> wgrant, yes, agreed.
[16:23] <flacoste> wgrant: or we should fix launchpad spam :-)
[16:23] <flacoste> to be honest, i'm not sure what is the PQM bug in this case
[16:23] <flacoste> that it's a member of ~canonical
[16:23] <flacoste> actually
[16:23] <deryck> yeah, some things we really just should never send mail for
[16:24] <flacoste> i don't know why PQM should be a member ~canonical
[16:24] <flacoste> it's mainly for branch
[16:24] <flacoste> and we always subscribe it explicitely
[16:24] <flacoste> which is better
[16:24] <wgrant> flacoste: The PQM bug is that it crashes when it can't verify a signature.
[16:24] <wgrant> Rather than just ignoring the mail.
[16:25] <wgrant> Also it probably shouldn't be a member of ~launchpad, I guess, but it might need those privileges.
[16:25] <flacoste> well, even if it didn't oops
[16:25] <flacoste> it should send an email about the error
[16:25] <flacoste> it can be a legitimate user error
[16:25] <wgrant> Possibly.
[16:25] <wgrant> I guess having ~launchpad-pqm's email address set to PQM's email address is pretty pointless.
[16:25] <flacoste> also
[16:25] <wgrant> I can see no possible benefit of that.
[16:25] <flacoste> me neither
[16:26] <flacoste> but it's hard to set a LP profile to a sink hole
[16:26] <flacoste> address
[16:26] <wgrant> Yeah.
[16:26] <wgrant> We need robot profiles.
[16:26] <deryck> sinzui, ping
[16:52] <deryck> benji, are we making noise about +subscriptions or +structural-subscriptions as part of y'all's work?  or keeping that on the dl?
[16:53] <abentley> adeuring: Could you please review https://code.launchpad.net/~abentley/launchpad/daily-build-permissions/+merge/60207 ?
[16:53] <adeuring> abentley: sure
[16:53] <abentley> Thanks.
[16:54] <benji> deryck: I don't think they're secrets; both should be linked to from user-visible parts of the UI (those users who can see them because of the feature flag that is)
[16:55] <benji> adeuring: I have a small review for you when you have a minute: https://code.launchpad.net/~benji/launchpad/bug-777794/+merge/60209
[16:56] <adeuring> benji: sure, I'll look
[16:56] <benji> thanks
[16:56] <deryck> benji, ok, thanks.  Early on in that story there was talk of hiding them until they were ready, and I didn't want to assume they were ready. :-)
[16:57]  * deryck is doing IRC duties and wants to be prepared as people ask about new work
[17:01] <adeuring> benji: r=me
[17:01] <benji> thanks
[17:15] <adeuring> abentley: r=me, just one note: there is an "import re" in a method in test_sourcepackagerecipe.py. I think this import can happen at the top of the file
[17:29] <sinzui> deryck: I think all registry admins can hide bug and question comments. I do not think https://answers.launchpad.net/launchpad/+question/156277 should be assigned to an admin
[17:29] <deryck> sinzui, ah, sorry.  from the web UI?  I didn't realize this.
[17:30] <deryck> sinzui, or using an api script?
[17:30] <sinzui> deryck:  https://dev.launchpad.net/MaintenanceRotationSchedule has link to dealing with spam and there is a script that you can run
[17:30] <deryck> sinzui, ok, I'll take a look.
[17:31] <deryck> I have such a low tolerance for administrivia.   You may not ever run that scrip again after today
[17:33]  * bigjools is with deryck
[17:33] <deryck> nice
[17:34] <deryck> sinzui, and if I have a user spamming bugs with linkedin invites, do I deactive or suspend the account?
[17:34]  * deryck sucks at reading 45 wiki pages too :-P
[17:34] <sinzui> suspend and include the question URL in the comment so that we know why
[17:34] <deryck> gotchas
[17:38] <deryck> sinzui, why isn't hide-comments in the lp tree?
[17:38] <sinzui> ask gmb he wrote it
[17:38] <sinzui> deryck: I modified that script a week ago so that we could work with questions too
[17:39] <sinzui> As I said, jcsackett is adding the UI now
[17:39] <deryck> sinzui, is that the copy in the wiki?
[17:39] <deryck> ah true
[17:39] <sinzui> yes it is
[17:39] <deryck> so shall I wait until Monday to hide this comment then? ;)
[17:40] <sinzui> jcsackett: when do you estimate we can QA comment hiding in the UI
[17:41] <deryck> sinzui, i was just kidding around.  I've got the script running now.
[17:47] <deryck> feels so 2004 to have to moderate Launchpad
[17:47] <deryck> don't people automate this sort of thing these days ;)
[17:47]  * deryck is just kidding around
[17:50] <jcsackett> sinzui: Out to ec2 land now.
[17:51] <jcsackett> so I can qa sometime this weekend, or Monday depending.
[17:53] <sinzui> jcsackett: thanks, I was just confirming my commitment not to add the api script to the lp tree
[17:54]  * jcsackett nods
[17:54] <jcsackett> There should be no need.
[18:06] <gmb> deryck, sinzui: No he didn't. That was intellectronica. At least I think it was. I could be lying.
[18:06] <sinzui> gmb: my apologies
[18:07] <gmb> sinzui: Don't apologise :) I just don't want people to get the impression that I know anything.
[18:07] <sinzui> yes. I know exactly how you feel. People keep asking me questions expecting me know the answer
[18:21] <sinzui> Help! I see that @operation_returns_collection_of errors if the method it decorates returns a Set. Can I make it like the Set, or do I need to change it to a list?
[18:22] <sinzui> I think there may be good reason the method returns a Set.
[18:44] <SteveA> hi, quick question. I couldn't find the answer on a cursory look at the launchpad dev wiki
[18:44] <SteveA> how long is a launchpad dev cycle?
[18:45] <EvilUrsinha> SteveA, it used to be about a month
[18:46] <SteveA> specifically, how long does a squad work on one area?
[18:46] <abentley> SteveA: Mostly, we release features when they are done: https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone
[18:46] <EvilUrsinha> SteveA, that's a bit different question, what abentley said
[18:46] <abentley> SteveA: as long as it takes to complete the feature.
[18:47] <SteveA> cool :-)
[18:47] <SteveA> for the most part (the modal average, say) how long does a squad work on a feature?
[18:47] <SteveA> or rather, on an area of the codebase
[18:47] <abentley> SteveA: We have two feature squads and two maintenance squads at a time.  When a feature squad finishes, they swap with a maintenance squad.
[18:48] <abentley> SteveA: I don't think we've got enough experience to answer this.  We've only been doing this since the last Epic.
[18:49] <sinzui> SteveA 4-13 months, but that we want to scope features into small units so that no feature is longer than a few months. We want teams to rotate to do maintenance more often.
[18:51] <SteveA> ok, I understand, I think. Thanks sinzui
[18:51] <SteveA> thanks abentley and EvilUrsinha too
[18:52] <EvilUrsinha> no problem :)
[18:52] <abentley> SteveA, np
[19:06] <LPCIBot> Project windmill-devel build #42: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/42/
[19:11] <deryck> benji, wouldn't the views I was asking about this morning count as a single view of subscriptions.  i.e. https://launchpad.net/~deryck/+subscriptions and https://launchpad.net/~deryck/+structural-subscriptions ?
[19:11] <deryck> well where single == two views ;)
[19:14] <benji> deryck: I think so!  I had forgotten that +structural-subscriptions works for a user; I thought there was only a list of directly subscribed bugs (i.e., ~user/+subscriptions)
[19:14] <deryck> benji, right.  jkakar might be interested in that  ^^ then
[19:15] <jkakar> Hiya benji, deryck. :)
[19:15]  * jkakar looks at +structural-subscriptions
[19:15] <benji> hmm, I can't find any links to those pages; I wonder why not
[19:16] <benji> it seems to me that there should be a link from the ~user page to those
[19:16] <deryck> benji, right.  that's why I asked this morning.
[19:16] <jkakar> benji, deryck: Uhm... my first impression is that I have no idea why I'm seeing what I'm seeing on this page. :)
[19:16] <deryck> benji, early on they needed a lot of polish
[19:16] <deryck> excatly! :-)
[19:16] <benji> the style looks messed up on +structural-subscriptions, those boxes should be full width
[19:17] <benji> oh, and the edit links take you to the old-style subscription edit pages
[19:17] <deryck> yeah, maybe they're not ready to talk about
[19:18] <benji> deryck and jkakar: ok, those are definatly not meant for public consumption; we need to either kill those or fix them posthaste
[19:18] <deryck> benji, right
[19:18] <benji> sorry for the confusion
[19:19] <deryck> np
[19:19] <jkakar> benji: Okay, cool.
[19:20] <deryck> but as a rough, unpolished sketch of what you're subscribed to, they're not bad
[19:20] <deryck> lp subscriptions easter egg
[19:20] <jkakar> benji: I think what I want to see is something like (1) a list of bug subscriptions I have (ie, things I explicitly subscribed to), (2) a list of projects that I get bug or merge proposal mail from because I'm in a team, and (3) a way to control each of those things.
[19:21] <benji> That's one of the downsides of deploying incomplete features, they are sometimes never finished.
[19:21] <jkakar> benji: Yeah.  Though, seeing something unfinished in production can also be a strong motivator to land further improvements.
[19:21] <jkakar> Anyway, I'm really glad you guys are pushing this work forward.  It's going to be so great to have control of these issues.
[19:22] <benji> yeah, that would be quite nice; you'll also probably want a list of all the non-subscription reasons you can get email; there are quite a few of those
[19:23] <jkakar> benji: Yeah, I probably do want that... particularly because I don't understand what they are off the top of my head... it would be nice to see it all in one place so I could complete my mental model of how LP notifies me of things.
[19:45] <jkakar> Uh oh, am getting repeated OOPSes trying to load: https://launchpad.net/fluidinfo/+milestone/11.05
[19:45] <jkakar> Like OOPS-1952AY485 for example.
[19:48] <sinzui> jkakar: You have discovered a bug! looks like the page dies trying to render the  structural subscription menu items
[19:49] <LPCIBot> Project windmill-devel build #43: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill-devel/43/
[19:50] <jkakar> sinzui: Ah, oops. :)
[19:50] <sinzui> I am reporting the bug now
[19:53] <sinzui> jkakar: I can see the page as anonymous since we do not try to render the bad link
[19:53] <sinzui> I think the issue may just be project group milestons
[19:53] <jkakar> sinzui: But I guess you can't see any bugs because the project is private, right?
[19:53] <sinzui> I see 1
[19:54] <jkakar> sinzui: Interesting, I can load https://launchpad.net/storm/+milestone/0.19 without issue.
[19:54] <jkakar> sinzui: Ah, which one? :)
[19:54] <sinzui> bug 664548
[19:54] <_mup_> Bug #664548: Rearrange chairs on upper decks <story-brave-new-world> <Fluidinfo:In Progress by fluiddb-dev> < https://launchpad.net/bugs/664548 >
[19:54] <jkakar> sinzui: Ah, okay, that one is public indeed.  Thanks.
[20:51] <LPCIBot> Project windmill-db-devel build #246: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/246/
[20:59] <LPCIBot> Project windmill-devel build #44: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill-devel/44/
[21:00]  * deryck reboots, brb
[21:43] <LPCIBot> Project windmill-devel build #45: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill-devel/45/
[21:48] <lifeless> jkakar: I didn't realise fluidinfo used lp. Cool.
[22:29] <LPCIBot> Project windmill-devel build #46: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill-devel/46/
[23:17] <lifeless> spammer on bug 411296
[23:17] <_mup_> Bug #411296: traceback if python has no ssl support: httplib module has no HTTPSConnection <https> <Bazaar:Confirmed for vila> < https://launchpad.net/bugs/411296 >
[23:22] <LPCIBot> Project db-devel build #523: FAILURE in 5 hr 13 min: https://lpci.wedontsleep.org/job/db-devel/523/