[00:56] <Unit193> ...Well dang, python-httplib2 does have quite a few rdeps.  Meh.
[12:24] <ahasenack> tjaalton: around?
[12:27] <tjaalton> ahasenack: yes
[12:28] <ahasenack> tjaalton: adding dep8 tests to sssd: https://git.launchpad.net/~ahasenack/ubuntu/+source/sssd/tree/debian/tests?h=sssd-dep8-tests
[12:28] <ahasenack> will soon make a merge request in salsa
[12:30] <ahasenack> tjaalton: I'm guessing a bit in util's reconfigure_slapd(), I didn't want to purge and reinstall slapd. I think what I'm doing there is working
[12:32] <tjaalton> ahasenack: ok, looks good
[13:08] <ahasenack> hi, can somebody please update the agenda at https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda, the "next dmb meetings" bit is outdated
[14:52] <seb128> bdmurray, hey, I would like to dispute that SRU team position you state on bug #1782320 "
[14:52] <seb128> This is not yet fixed in cosmic as version 5.6-5ubuntu1 is still in -proposed."
[14:54] <seb128> bdmurray, saying that a security-update introduced in the LTS can't see it's SRU fix go to bionic-proposed because the corresponding cosmic upload is stucked in cosmic-proposed due glib blocking things atm isn't great imho
[14:54] <seb128> security-update introduced *regression*
[14:55] <seb128> slangasek, ^ btw  (unsure where would be the right place to discuss that policy, SRU team doesn't have a list? TB maybe?)
[14:56] <seb128> I think it's wrong as a default position to block SRUs because the newer-serie fix is blocked in proposed for a reason which isn't due to the package itself
[14:58] <bdmurray> seb128: We get lots of things uploaded in the queue which are incomplete / not following the process. When I first looked at this bug there was no Bionic task and I had to dig a bit to find out what was going on in Cosmic. When I saw it was stuck in -proposed for cosmic I stopped digging into what was going on.
[14:59] <bdmurray> seb128: I'm fine with getting the fix into Bionic, just wanted to explain how the bug ended up where it is.
[15:00] <seb128> bdmurray, I'm not sure I follow you, afaik that bug follows th process, the fix has been uploaded to cosmic, the cosmic line is fix commited, the description includes the impact/test case/regression potential sections, the changelog lists the bug number
[15:01] <seb128> https://wiki.ubuntu.com/StableReleaseUpdates#Procedure doesn't state that having the bug targetting bionic is a pre-review condition afaik
[15:03] <ricotz> hi, this seems to need a retry https://launchpad.net/ubuntu/+source/rust-syn/0.14.6-1
[15:03] <seb128> ricotz, hey, depwait should autoclear no?
[15:04] <ricotz> seb128, maybe not after a long time
[15:04] <seb128> let me retry
[15:05] <seb128> ricotz, those packages don't seem to exist though?
[15:06] <ricotz> seb128, https://launchpad.net/~ricotz/+archive/ubuntu/mozilla/+build/15330344
[15:06] <seb128> ?
[15:07] <seb128> $ rmadison librust-quote-0.6+proc-macro-dev
[15:07] <seb128> $
[15:07] <ricotz> it builds in a ppa, and those dependencies are available
[15:07] <Laney> could be a Provides from something else
[15:07] <ricotz> there are a lot of virtual packages
[15:07] <ricotz> exactly
[15:08] <seb128> what source/package is providing them?
[15:08] <ricotz> this is likely the reason it doesn't "autoclear"
[15:08] <seb128> rustc?
[15:08] <bdmurray> seb128: There is no need to have a bionic target, but having the cosmic task set to "Fix Committed" isn't enough for me to feel comfortable so I went and looked to see why it wasn't Fix Released in cosmic and added the comment about it being stuck in -proposed. I didn't look into why it was stuck in -proposed.
[15:08] <seb128> bdmurray, k, I'm still failing to understand what I did wrong though
[15:08] <ricotz> seb128, rust-quote
[15:08] <seb128> bdmurray, or what is described on  https://wiki.ubuntu.com/StableReleaseUpdates#Procedure is not a reflection of what you expect as a SRU reviewer?
[15:09] <seb128> ricotz, k, I guess that got uploaded together and it was not available at the time rust-syn tried to build
[15:09] <seb128> and the provide things made it not get into depwait
[15:10] <seb128> since it was not waiting on a real package maybe?
[15:10] <ricotz> yes, this what I am thinking too
[15:10] <Laney> https://bugs.launchpad.net/launchpad/+bug/335913
[15:10] <seb128> retrying is working, amd64 built
[15:10] <seb128> I did retry the other archs as well now
[15:11] <seb128> Laney, thx, that confirms it :)
[15:13] <bdmurray> seb128: No it is and part 1 says 'Check that the bug is fixed in the current development release, and that its bug task is "Fix Released".' With regards to doing something wrong, I don't think you did here rather my point was I'm predisposed to think SRU uploads are missing something.
[15:13] <bdmurray> s/you did/you did something wrong/
[15:13] <seb128> k
[15:14] <seb128> well, in that case the bug has been introduced by a CVE fix that went to bionic-security
[15:14] <seb128> which exposed a bug in the policykit use of that app
[15:14] <seb128> so I would appreciate if you could have a review :)
[15:14] <seb128> thx for the explanations bdmurray!
[15:15] <seb128> (I still think the SRU policy of waiting for things to be in the release pocket of the devel serie is not the right one, but I keep that one for Brussel maybe, I think there is a SRU team meeting there)
[15:15] <bdmurray> people sometimes flip the bug status to fix committed and don't mention the bug number in the changelog for the development release and it requires some detective work to figure out what's happing in -devel
[15:16] <seb128> that sounds like to me that you should request a clickable url to the devel-serie-fix in the bug description
[15:16] <seb128> maybe as part of the process
[15:16] <seb128> so the review can just click and doesn't have to do detective work
[15:16] <seb128> reviewer*
[15:17] <bdmurray> seb128: I'll add that to my notes for Brussels too
[15:17] <seb128> thx
[15:17] <seb128> ricotz, ryst-syn built on all arches now :)
[15:22] <ricotz> seb128, thanks
[15:22] <seb128> np!
[15:23] <seb128> bdmurray, thx for the SRU
[15:25] <ricotz> seb128, another one https://launchpad.net/ubuntu/+source/rust-tempfile/3.0.3-1
[15:25] <ricotz> and https://launchpad.net/ubuntu/+source/rust-serde-derive/1.0.70-1
[15:26] <ricotz> there are likely more
[15:26] <seb128> ricotz, k, I'm going to look at the rust- packages blocked in proposed and retry builds
[15:27] <ricotz> seb128, thanks
[15:27] <seb128> yw!
[15:27] <seb128> (done for those)
[15:27] <ricotz> damn new firefox dependency
[15:29] <ricotz> chrisccoulson, likely something to include into cargo backports or so
[15:29] <ricotz> chrisccoulson, please don't forget to push the firefox packaging branches, 61.x wasn't pushed either yet
[15:30] <ricotz> to clarify: rust-cbindgen is the needed one
[15:33] <ricotz> seb128, https://launchpad.net/ubuntu/+source/rust-fuchsia-zircon-sys/0.3.3-1 looks like a leaf
[15:41] <slangasek> seb128: we generally use ubuntu-release for such discussions
[17:27] <seb128> ricotz, k
[17:28] <seb128> slangasek, right, I think it's fine for now I can keep that discussion for Brussel
[20:37] <seb128> juliank, could you SRU bug #1790671 to bionic?
[20:38] <juliank> seb128: I will, yes
[20:38] <seb128> great, thx
[20:38] <juliank> I'll check xenial too
[20:40] <juliank> seb128: I need to find out a reproducer, and there's another bugfix to cherry-pick it seems; as well as potentially a fix for packagekit crashing upgrading itself
[20:41] <juliank> that last one just came in today: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1790613
[20:42] <seb128> juliank, I don't think we used that code in xenial, we had aptdaemon/session-installer since
[20:42] <seb128> since->there
[20:43] <juliank> possible
[20:43] <juliank> but if it applies, why bother not fixing it :)
[20:43] <juliank> If not, I don't really care :)
[20:43] <seb128> the  e.u.c summary has no report for xenial
[20:44] <seb128> well, unsure what's the point fixing a bug no user is hitting
[20:44] <seb128> just waste reviewers/testers time and bandwith
[20:47] <juliank> that code does not exist anyway
[20:47] <juliank> also, maybe xenial used the apt backend instead of the aptcc one
[20:47] <juliank> I don't remember the details :)