=== dupondje_ is now known as dupondje
=== Estilanda_ is now known as Estilanda
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== roadmr is now known as roadmr_afk
[21:07] <tlyu> could someone please triage 1347147? i think it deserves at least "High" importance and to target Utopic and Trusty
[21:28] <rbasak> tlyu: I saw that, but am not sure of the importance. How common is it? Are krb5 KDC slave operators likely to hit it in practice?
[21:30] <rbasak> tlyu: besides that, krb5-kdc is in universe. What are you hoping will happen if the importance field is set?
[21:30] <rbasak> tlyu: what we really need is someone to find and assess the fix (I can see progress being made there) and to submit debdiffs to the sponsorship queue.
[21:31] <rbasak> I agree with the Trusty task though, but I don't think I have permission to add that, sorry.
[21:31] <tlyu> rbasak: it's actually more general than just slaves.  an admin of a realm with more than a few hundred principals can run into the bug and encounter an infinite loop condition when modifying the database
[21:32] <rbasak> tlyu: how likely is it that this will happen in practice?
[21:33] <tlyu> most sites i know that run Kerberos have tens if not hundreds of thousands of principals
[21:33] <rbasak> Right, but only 3 people are affected by this bug?
[21:35] <tlyu> it's not easy to debug, and the bug is maybe a week old
[21:36] <tlyu> also KDC operators tend to be conservative about updating software
[21:47] <rbasak> tlyu: I've commented on the bug. I appreciate the work that's already gone into this issue.
[21:47] <rbasak> tlyu: Importance doesn't really matter here. What matters is that developers can do the right things to get the fix landed. I've subscribed to the bug and so if we can get my questions answered we can just get the fixes landed.
[21:48] <tlyu> we (upstream) will probably take the approach of having a Debian package uploaded that contains the fix/workaround, which might be the easier way to get it into Utopic
=== roadmr_afk is now known as roadmr
[21:50] <rbasak> tlyu: that's fine and completely acceptable. Though krb5 currently has a delta, so someone will need to manually merge any new Debian uploads into Ubuntu.
[21:50] <rbasak> tlyu: Ubuntu's SRU policy is to require Utopic fixed first, so that users don't get a regression after taking a Trusty SRU.
[21:51] <rbasak> tlyu: so if we want this landed in Trusty quickly, it may be better to temporarily fix Utopic with a cherry-pick directly to Utopic.
[21:52] <rbasak> tlyu: I'd like to help you with fixing Ubuntu and I appreciate your efforts. I'm happy to champion your patches as long as I know what I'm landing so as to meet our requirements (mainly about avoiding regressions).
[21:52] <rbasak> tlyu: particularly when fixes are sanctioned by upstream.
[21:56] <tlyu> rbasak: do you consider the current test case (comment #1) inadequate?
[22:01] <rbasak> tlyu: I'm sorry. That test case is fine. I missed it when writing my comment.
[22:16] <tlyu> rbasak: thanks for all your help.  we'll work on supplying the needed information
[22:17] <rbasak> tlyu: no problem - thank you for caring for the packages in Ubuntu. It's a little difficult from my end - we're not so familiar with the individual packages and so don't have the confidence in taking patches that you might have.
[22:18] <rbasak> tlyu: OTOH, we value upstreams' opinions highly. Might be worth identifying yourself in bugs for this reason.
[22:19] <rbasak> tlyu: as long as we don't think we'll get users yelling us, we do want to fix things :)
[22:19] <rbasak> yelling at us