[01:00] <teward> would anyone be kind enough to run `apt-cache rdepends python-myssql` for me on a Xenial or Yakkety box, please?
[01:01] <teward> I would, except I'm IRC-ing from phone again... so I can't reach my Xenial or Yakkety VMs
[01:01] <teward> (dead internet at home is dead)
[01:01] <karstensrage> starting up my vm teward
[01:01] <teward> karstensrage: thank you kindly
[01:02] <teward> trying to figure how depended-upon python-pymssql is relied on, given that it's not working (so if it doesn't work and hasn't been updated in Debian for years, maybe it should be removed)
[01:05] <karstensrage> udo apt-cache rdepends python-myssql
[01:05] <karstensrage> E: No packages found
[01:05] <karstensrage> hmm you meant mysql
[01:05] <karstensrage> not myssql right?
[01:05] <karstensrage> sudo apt-cache rdepends python-mysql
[01:05] <karstensrage> E: No packages found
[01:05] <teward> karstensrage: python-mssql
[01:05] <karstensrage> nothing
[01:05] <teward> yes i mistyped
[01:05] <teward> erm
[01:05] <teward> python-pymssql I think it is
[01:06] <teward> fat-fingering on a mobile keyboard >.<
[01:06] <karstensrage> there we go
[01:06] <karstensrage> sudo apt-cache rdepends python-pymssql
[01:06] <karstensrage> python-pymssql
[01:06] <karstensrage> Reverse Depends:
[01:06] <karstensrage>   python-sqlalchemy
[01:06] <karstensrage>  |pyrit
[01:06] <teward> so no difference then from Trusty
[01:06] <teward> karstensrage: thank you kindly!
[01:06] <karstensrage> my pleasure
[01:06] <karstensrage> :)
[01:07] <teward> betcha a dollar that nobody depends on it because it's broken and you can't get anything from executed SQL queries)
[01:08] <teward> eww
[01:08] <teward> nevermind, that's a very painful removal
[01:08] <teward> at least.... jesus, a huge amount of python-* things depend on sqlalchemy it looks like
[01:09]  * teward gives up :p
[01:09] <teward> forget i said anything about package removal :)
[01:52] <JanC> teward: isn't there also another python module for MS SQL?
[01:55] <teward> is there?
[01:55] <teward> JanC: MSSQL is what's in use at the workplace
[01:55] <teward> that was a migration hurdle recently until I discovered the StackOverflow post about the version of pymssql being old being the cause
[01:56] <teward> JanC: problem being the rdepends for the removals, though, unless you're saying there's an alternative for python-sqlalchemy to rely on, it has a depends on python-mssql, and AFAICT the rdeps for python-sqlalchemy extend to a large # of python-* packages
[01:57] <JanC> right
[01:57] <teward> JanC: i'd rather see it updated, but it looks like upstream in Debian nobody cares
[01:57] <teward> ("It doesn't work" bugs have been there for at least 3 years)
[01:58] <JanC> I'm sure Debian as a whole cares
[01:58] <teward> JanC: the maintainer probably doesn't care, there's been no movement on 'updated versions'
[01:58] <teward> which makes me think they don't care it doesn't work, because they haven't reported that it's not fixable
[01:58] <teward> when there's been a patch submitted already
[01:59] <JanC> there are procedures to handle that AFAIK
[01:59]  * teward shrugs
[01:59] <teward> as i said, I don't care anymore, I have my workaround
[01:59] <teward> :p
[02:02] <JanC> you need a 2.1 version, I guess?
[02:04] <JanC> maybe just get a pymssql2 package into Debian  ;-)
[05:37] <cpaelzer> good morning
[05:39] <b4r> moin
[06:17] <pitti> Good morning
[06:18] <pitti> teward: how are non-ascii bytes choking up the hooks? UTF-8 should be fine and things will end up as str, for binary data you get byte arrays
[06:18] <pitti> teward: i. e. if there's a particular hook that doesn't get along with that, that hook should be fixed; it's certainly not limited by design to ascii
[09:39] <bdrung_work> pitti, hi. did you have time to look at https://github.com/bdrung/systemd/commit/2b824ccae61142cbcdaf251c2d3c996f933e217a
[09:39] <pitti> bdrung_work: yes, I answered in #u-desktop; looks good to me, thanks!
[09:40]  * bdrung_work should connect his personal and professional IRC client.
[09:40] <bdrung_work> pitti, one open question: what value will testing/sid use?
[09:41] <bdrung_work> (unstable)root@konstrukt:~# cat /etc/debian_version
[09:41] <bdrung_work> stretch/sid
[09:41] <bdrung_work> should the specification allow this value?
[09:41] <pitti> bdrung_work: no, I don't think so
[09:42] <pitti> either we can determine whether we are running unstable or testing, or it should not be set, or it should be one of the two
[09:42] <pitti> "stretch/sid" is a rather useless and confusing value IMHO
[09:42] <bdrung_work> should we enhance the specification to make that clear?
[09:42] <pitti> but I wouldn't allow things like "or" (/) in that spec
[09:42] <pitti> it already is -- '/' isn't allowed?
[09:43] <bdrung_work> yes, '/' isn't allowed
[09:43] <pitti> bdrung_work: lsb_release -a says "sid", and IMHO os-release should agree to that
[09:44] <bdrung_work> other question: should we restrict the allowed characters even more? e.g. no underscore, dot, etc?
[09:44] <pitti> bdrung_work: I don't know a reason why it shoudl be restricted further
[09:45] <bdrung_work> underscore is not allowed in the distribution name in Debian and derivatives
[10:26] <rbasak> cjwatson: do you have an opinion on bug 1588457 please?
[10:28] <cjwatson> rbasak: I don't think it would be wise to try to restore the old behaviour on upgrade; upstream made the change for a good reason.  IMO this is release notes kind of material
[10:29] <rbasak> cjwatson: thanks. Do we change release notes post-release?
[10:29] <cjwatson> Sure
[10:29] <rbasak> I'll do that then and mark the bug Won't Fix. Thanks!
[10:30] <cjwatson> Almost (but not quite) by definition - many release-notes-worthy issues are only discovered post-release
[10:30] <cjwatson> I would consider adding a NEWS.Debian entry if that would be helpful
[10:30] <cjwatson> (I did call it out in the changelog at the time)
[10:31] <rbasak> I'm not sure how many users look at that nowadays but it does seem like the right thing to do.
[10:33] <cjwatson> rbasak: https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=79139a04a0183cd47f3e837fa76fe5d51e62fcc9
[10:33] <rbasak> Thank you!
[10:47] <rbasak> pitti: may I have your opinion on bug 1588915 please?
[10:51] <pitti> rbasak: followed up
[10:51] <rbasak> pitti: thank you!
[10:51] <pitti> yw!
[11:29] <xnox> today is evil day
[12:04] <teward> pitti: I swear there's at least six bug reports on it
[12:05] <teward> I'll have to dig up bugs, I know sarnold filed several against packages which have had issues
[12:05] <teward> though they problaby should have been dual-filed against Apport as well
[12:05] <teward> since they were in the 'generic' apport hooks that apport runs for most bugs
[12:14] <teward> pitti: here's one such bug that looks similar
[12:14] <teward> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1582950
[12:14] <teward> that one's for Ubiquity, yes, but the error string is one I've seen in many hooks
[12:14]  * teward digs in nginx bugs
[12:15] <teward> pitti: here's one, https://launchpadlibrarian.net/257302123/HookError_ubuntu.txt on https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1577059 shows the hook error I'm referring to
[12:16] <teward> and here (https://launchpadlibrarian.net/260081000/HookError_ubuntu.txt) - https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1582954
[12:16] <teward> in some cases my hooks get choked up, in others they don't
[12:19] <teward> i'm more concerned about the "AttributeError: 'bytes' object has no attribute 'encode'" issue which appears to crop up most
[12:19] <teward> and that's in general apport hooks, not package-specific
[12:46] <caribou> ginggs: Are you working on merging clamav ?
[14:01] <ginggs> caribou: no
[14:01] <caribou> ginggs: ok fine, I'm taking care of it
[15:03] <rbasak> !dmb-ping
[15:06] <cyphermox> howdy
[15:07] <sil2100> !
[15:07] <sil2100> Uh oh, sorry guys
[16:29] <nacc> ogasawara: did you ever find out about the mainline builds for xenial?
[16:30] <bjf> apw, ^ ?
[17:01] <apw> nacc, ?
[17:04] <nacc> apw: this page: http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D shows mainline builds (4.6-rc6, e.g.) for wily and yakkety, but not xenial
[17:04] <nacc> apw: a user was asking waht version to use to test on xenial for a possible mainline fix
[17:16] <apw> nacc, those -<series> things tell you the config used not where it is suitable for
[17:17] <nacc> apw: oh!
[17:17] <nacc> that is ... confusing
[17:17] <nacc> given the wiki page referring to it, i think
[17:17] <apw> yea, i suspect we should remove the suffix completely
[17:18] <nacc> apw: ok, so the user could use the -yakkety one ok on xenial? or would we not recommend that? i was worried about dependencies
[17:18] <tjaalton> it's fine
[17:18] <apw> nacc, mostly you should be ok, except when you arn't
[17:18] <nacc> heh
[17:18] <nacc> tjaalton: apw: ok, thanks!
[19:38] <nacc> rbasak: around?