[05:17] <Unit193> $someone miiight want to sync https://packages.qa.debian.org/libs/libssh2/news/20190403T043339Z.html
[08:48] <rbasak> Laney: on second thoughts, I don't think adding SpamapS to ~ubuntu-dev would even be a new thing
[08:48] <rbasak> If he had ever had packageset or PPU access then he'd be a member of that team anyway
[08:49] <rbasak> If he had then been added to ~ubuntu-core-dev, our process wouldn't have removed him from direct membership from ~ubuntu-dev
[08:49] <rbasak> And he'd be able to "expire himself" from ~ubuntu-core-dev and end up in this situation himself directly.
[08:50] <rbasak> Therefore, I think it's OK to add him to ~ubuntu-dev without further ado.
[08:50] <rbasak> No need for a new emeritus process.
[08:50] <rbasak> I'll leave an email to devel-p@ with an explanation.
[08:51] <rbasak> Unless someone here thinks that would be wrong?
[08:54] <Laney> That's for you collectively to decide but an obvious other option would be to decide that's a loophole you don't want and run a script that checks for ~ubuntu-dev who can't upload anything and move them to emeritus
[08:56] <rbasak> Sure - if it's a loophole we don't want then we can arrange to remove it and actually create an emeritus process. But for now, it seems harsh to "punish" SpamapS for asking and making him the first exception by denying it.
[08:56] <rbasak> Adding him to ~ubuntu-dev would maintain the status quo I think.
[08:56] <rbasak> (and his personal status, too)
[08:57] <rbasak> If we then decide to do something else instead later, I think that would cause less harm then leaving him in the lurch right now.
[08:59] <Laney> If you on the DMB are fine with that, then that's what you should do. I don't think, though, that using the first incidence of a new thing to determine a process is an unfair thing to do, if there weren't previous expectations set either way.
[09:00] <Laney> Anyway, that's probably enough of that. :>
[13:48] <coreycb> bdmurray: thanks for looking at that so quickly! i didn't follow your comment but i see it was accepted for cosmic at least.
[13:48] <coreycb> also need it for bionic but that might be more controversial
[14:10] <bdmurray> coreycb: your comment has "queue_text=" but nothing as argument. I'd think you'd want the package name there to filter the queue with only the package you are referencing
[14:11] <coreycb> bdmurray: that's a good idea!
[15:56] <seb128> vorlon, you closed bug #1812688 but I'm not sure it was "fixed", a delta was added (package was in sync before) to skip the test without any explanation of why that's needed/a good idea and without forwarding to Debian, imho it would deserve to be properly looked at
[16:00] <vorlon> seb128: ah, feel free to reopen; indeed, it looks like bdmurray agrees with you but I didn't read closely enough for context
[16:00] <seb128> vorlon, thx
[16:00] <vorlon> seb128: I closed it because it was a high rls-dd-incoming bug and the description didn't match the current state of the archive, sorry :)
[16:01] <seb128> no worry :)
[17:20] <brlin>  /var/lib/dpkg/info/ubuntu-defaults-zh-cn.postinst: 7: /var/lib/dpkg/info/ubuntu-defaults-zh-cn.postinst: update-gconf-defaults: not found
[17:20] <brlin> (facepalms)
[17:21] <brlin> Probably this one: https://bugs.launchpad.net/ubuntu/+source/ubuntu-defaults-zh-cn/+bug/1800608
[17:34] <teward> any sponsor want to take a look at https://launchpad.net/bugs/1820144 and perhaps upload my debdiffs to fix the bug?  It'll need SRU review still, but...