=== hikiko is now known as hikiko|ln
=== hikiko|ln is now known as hikiko
[16:16] <nacc> Can someone please nominate LP #997172 for Trusty and Xenial?
[16:16] <ubot5> Launchpad bug 997172 in smbldap-tools (Debian) "[SRU] smbldap-config.pl not installed" [Unknown,New] https://launchpad.net/bugs/997172
[16:17] <teward> nacc: nominated, needs approval now
[16:17] <nacc> teward: thanks!
[16:17] <teward> rbasak: ^ you able to approve the tasks?
[16:59] <rbasak> nacc, teward: done
[17:00]  * hggdh was slower than rbasak on the trigger...
[17:01] <teward> rbasak: thanks
[17:01] <teward> rbasak: if I may query your brain, an issue which makes a python library's core functions unusable because it returns no data when it reaches into a DB, High or Critical ?
[17:01] <teward> (the python library doesn't work as is in the repos)
[17:01] <teward> not necessarily a server package, but...
[17:02] <hggdh> is it common to use this?
[17:03] <teward> hggdh: rdepends shows python-sqlalchemy; rdepends on *that* is a lot of python-* packages.  I set it as High because it renders the thing unusable (discovered the issue during a workplace 9.10 -> 14.04 programs migration of inhouse python)
[17:03] <teward> but was curious if that's the right one to set
[17:04] <teward> hggdh: also, hello in a more general sense :)
[17:04] <hggdh> teward: hello :-)
[17:04] <hggdh> if there are no "known" issues on the other packages, then high is OK
[17:05] <teward> that's what i thought
[17:05] <teward> though i didn't check the other packages
[17:06] <teward> hggdh: I wouldn't *expect* it to be a huge issue because it's a library that allows DB interfacing with MSSQL, but... "No Data Returned From Queries" is a huge red flag
[17:06] <teward> and been known since 2012
[17:06] <teward> with no progress in Debian either on a fix :p
[17:06] <hggdh> ught
[17:06] <teward> though upstream has a patch that's been around since... oooh, years.
[17:07] <hggdh> on a more meta-philosophical view, anyone depending on alchemy to get something is bound for disaster
[17:07] <hggdh> teward: did you try the patch?
[17:07] <teward> :P
[17:07] <teward> hggdh: debdiffs locally, though on the affected systems I just used 'easy_install --upgrade pymssql', which grabs upstream's 2.x branch
[17:07] <teward> while Debian and Ubuntu still use 1.0.x
[17:08] <teward> planned to test this evening
[17:08] <teward> the second part was "set up a test mssql" server.
[17:08] <rbasak> teward: what's the bug?
[17:08] <teward> want to guess what I hate the most?
[17:08] <teward> rbasak: https://bugs.launchpad.net/ubuntu/+source/pymssql/+bug/918896, though hggdh's analysis matched mine
[17:08] <teward> https://bugs.launchpad.net/ubuntu/+source/pymssql/+bug/918896
[17:08] <ubot5> Launchpad bug 918896 in pymssql (Ubuntu) "No data returned from MSSQL server" [High,Confirmed]
[17:08] <teward> oopsies
[17:08]  * teward kicks the computer
[17:08] <hggdh> uh, the "setup & test" part?
[17:08] <teward> hggdh: (1) set up MS Server, (2) Set up MSSQL
[17:08] <teward> (3) configure DB server
[17:08] <teward> (4) raise hell
[17:09] <teward> 5 is testing, but that's after rebuilds :)
[17:11] <rbasak> teward: yeah I'd say High, because it only impacts other packages if using Python and MSSQL, which on Ubuntu is a fairly rare case.
[17:11] <teward> indeed.
[17:11] <teward> rbasak: that was my original assessment :)
[17:11] <teward> but i like second opinions :)
[17:11] <rbasak> :)
[17:11] <teward> and third, and fourth, and fifth... *goes on and on until his need for coffee forces him to get up to get more*
[17:12]  * hggdh sips a bit of the decaf, and laughs
[17:12]  * teward noms chocolate-covered espresso beans in the interim until the coffee is ready :)
[17:13] <teward> anyways, thanks rbasak for setting the tasks :)
[17:13] <teward> nacc will be appreciative :)
[19:36] <teward> rbasak: or any other bug lord, can someone approve my bug task nominations on https://bugs.launchpad.net/ubuntu/+source/pymssql/+bug/918896 please for the series I nominated?
[19:36] <ubot5> Launchpad bug 918896 in pymssql (Ubuntu) "No data returned from MSSQL server" [High,Confirmed]
[19:36] <teward> i have confirmations that the upstream patch works, and am prepping debdiffs.
[20:48] <hggdh> teward: you realise that first we will have to have yakkety done, right?
[21:14] <teward> hggdh: the debdiffs i'm submitting?
[21:14] <teward> all of them
[21:14] <teward> but yes
[21:14] <teward> not my first SRU-rodeo
[21:14] <teward> hggdh: the debdiffs i've already prepped are precise thru yakkety
[21:14] <teward> as soon as Chrome starts up
[21:16] <hggdh> teward: ack, I will approve all
[21:16] <teward> hggdh: should I dump all the debdiffs or wait for yakkety?
[21:16] <hggdh> it would be better to wait for yakkety validation
[21:16] <teward> ack
[21:16] <teward> hggdh: well, yakkety debdiff submitted there
[21:17] <teward> but the only people testing in Yakkety are me and maybe a few others
[21:17] <hggdh> (cuz this is, theoretically, how it should be done)
[21:17] <teward> though, I did test yakkety :)
[21:17] <teward> hggdh: ack
[21:17] <teward> hggdh: in the mean time i have a PPA to 'fix' the problem for me :P
[21:17] <hggdh> teward: anyway, I will approve the others
[21:17] <teward> (so my servers won't be impacted)
[21:17] <teward> hggdh: if you wish, or you can wait
[21:17] <teward> :)
[21:17] <hggdh> teward: although I did not say it before: thank you :-)
[21:17]  * teward is in no rush, but the people who have wanted this fixed for an age are :p
[21:17] <teward> hggdh: you're welcome :)
[21:18] <hggdh> tempus fugit, and all
[21:26] <teward> hggdh: off hand would you know the process in Debian for getting something NMU'd if there's bugs that have patches but the maintainer has been AWOL on it for years?
[21:26] <teward> s/years/several years/
[21:37] <hggdh> teward: sorry, no (if the package is orphaned, then there is nobody taking care of it)
[21:41] <rbasak> teward: have you considered applying to the bug control team?
[21:42] <rbasak> teward: I'd be happy to endorse your application (if that's a thing for bug control, I'm not sure)
[21:53] <teward> rbasak: erm, i'm already bugcontrol
[21:53] <teward> can't approve tasks
[21:53] <teward> only nominat
[21:53] <teward> e
[21:53] <teward> except where I have upload privs (nginx)
[21:54] <teward> which is how the security bug got all series set by me in one go
[21:54] <teward> rbasak: Ubuntu Drivers members have approve-series-nomination (or whatever the permission is called)
[21:55] <teward> rbasak: bugcontrol has 'nominate-for-series' or w/e it's called, but not approve
[21:55] <conslo> hello! I have a pretty specific question about the update release process. I'm affected by this: bugs.launchpad.net/ubuntu/+source/linux/+bug/1573231/ which is supposedly fixed in kernel 4.4.0-23.41, which is commited-but-not-released for Xenial (as of 5-18)
[21:55] <teward> hggdh: i'm poking #debian-devel and #debian-python now over on OFTC, see if they can't at least get the fix as well as mark it orphaned
[21:55] <teward> hggdh: the python modules team is listed as uploader so..
[21:56] <teward> maybe they can get it patched, then orphan-status it
[21:56] <teward> rbasak: also, hence why I poked you to approve the nominations on nacc's bug earlier :)
[21:57] <conslo> it's commited for proposed, build succeeded as far as I can see, but it's not actually in the repo. It's seems like a pretty serious bug and it's blocking some of our projects, so I'm wondering if I can get an idea of a timeline/if there's someone to poke about things
[21:59] <rbasak> teward: oh. That's a bit rubbish :-/
[22:00] <teward> rbasak: yes, it is, but I don't argue, because where I do most of my triage (nginx), I have series-approval rights already