[09:41] <mwhudson> xnox: hooray
[09:42] <mwhudson> (ubuntu-make)
[09:43] <mwhudson> xnox: so just need to get botch kicked out of artful-release and then python3-defaults should migrate?
[09:55] <xnox> mwhudson, yeah, need to ping steve again about it.
[09:56] <mwhudson> an archive admin, my kingdom for an archive admin
[09:57] <xnox> mwhudson, i take your kingdom and raise you an empire
[10:25] <ginggs> mwhudson: archive admins are next door, in -release
[10:26] <mwhudson> ginggs: yeah
[10:27] <clivejo> anyone here familiar with python module packaging?
[10:28] <clivejo> Trying to use gbp buildpackage with this git repo https://anonscm.debian.org/cgit/python-modules/packages/pyee.git
[10:29] <clivejo> but something keeps changing version.txt
[10:31] <ginggs> mwhudson: and only offer them part of your kingom
[10:32] <cjwatson> clivejo: That would be the fact that it uses https://pypi.python.org/pypi/vcversioner
[10:32] <cjwatson> clivejo: version.txt should probably be gitignored
[10:34] <clivejo> would you have a package I could see it in action?
[10:34] <clivejo> an example of how its done
[10:53] <cjwatson> sorry, no
[10:54] <cjwatson> but git ignore isn't hard to look up
[11:28] <clivejo> cjwatson: I have tried adding version.txt to .gitignore but gbp is still complaining that it has changed
[11:29] <cjwatson> yeah you would have to actually remove it too
[11:29] <cjwatson> perhaps there's a problem with it being in the upstream tarball though, I haven't checked
[11:30] <clivejo> git rm --cached version.txt
[11:30] <cjwatson> you might need to arrange to put back the upstream version on debian/rules clean
[11:30] <clivejo> then added my .gitignore
[12:05] <mapreri> doko: does that binutils upload include https://sourceware.org/bugzilla/show_bug.cgi?id=21820 as well?
[12:07] <doko> mapreri: yes, forgot to add the changelog entry
[12:07] <mapreri> doko: cool, thanks
[12:39] <xnox> mwhudson, so botch is now done, ubuntu-make too. requeue / restarted adt tests python3-defaults triggering ubuntu-make. once those pass we shall see if python3-defaults migrates or not.
[13:13] <infinity> juliank, xnox: Yo, where are we on apt versus unattended-upgrades.  Is the apt in the xenial queue "the final solution", or is there still more to discuss/fix/tweak?
[13:14] <infinity> juliank, xnox: And if that's what we want, do we want/need it for the point release, and if so, is there enough time to verify it by the end of the week if I review and accept it today?
[13:14] <xnox> there is time to verify it and push it through.
[13:15] <juliank> infinity: There'll be another round with further improvements, but as it is, it already is a substantial improvement in itself.
[13:15] <xnox> it would be nice, if we shipped it like 3 weeks ago, as clouds are complaining.
[13:15] <juliank> Yeah
[13:15] <xnox> infinity, we do want it soon - the stuff in the queue is enough to fix the cloud wining.
[13:15]  * xnox vining?
[13:15]  * xnox whyning?
[13:18] <infinity> juliank, xnox: Alright, so you both agree that what's in the queue is a progression, even if not "perfect", and we want it soon?
[13:18] <juliank> YES
[13:18] <xnox> yes.
[13:18] <infinity> Do we need unattended-upgrades changes to go with it, or can that apt update stand alone?
[13:19] <juliank> It's an improvement either way. With the u-u changes it would be nicer
[13:19] <infinity> Well, I don't see any u-u changes anywhere, which is why I asked. :P
[13:20] <infinity> I thought there was something about needing new CLI options.
[13:20] <juliank> Yeah, https://github.com/mvo5/unattended-upgrades/commit/db9eb377cbf371a07641ca5c58a030c6081c51ab https://github.com/mvo5/unattended-upgrades/commit/f26edb4425e488d7acdb825b0b6e8e327d2d51e6 https://github.com/mvo5/unattended-upgrades/commit/2e5deed4a3ef77fb0dcc02525eb32ed134b98a91
[13:20] <juliank> em, read that right to left
[13:20] <infinity> If only those were in an archive somewhere.
[13:21] <xnox> >_<
[13:21] <xnox> i thought options were not needed =/
[13:21] <juliank> I wanted to get feedback on it :)
[13:21] <infinity> Ahh, right, the apt bits check for the new option before attempting to use it.
[13:22] <juliank> I mean, we can roll out the u-u change too, I think, now that it's merged.
[13:23] <juliank> rbalint pushed these to mvo
[13:25] <juliank> The change should be easy to review for an SRU, but I don't know if u-u builds in artful right now, it certainly does not in Debian
[13:28] <infinity> juliank: Not sure I want to see them in an SRU before the devel release.  But the apt stuff looks guarded against old versus new, so we can just land it first.
[13:29] <juliank> infinity: Yeah, it's also worth noting that the apt part is shipping in Debian stable, so I guess we get some good testing already :)
[13:29] <juliank> We can either wait for mvo to finish the new unattended-upgrades release and then sync or merge that to artful, or just cherry-pick the changes now. I do have some time today :)
[13:30] <mvo> juliank: I had one feedback item for rbalint in the PR, otherwise this looks good
[13:30] <mvo> juliank: I also want to add pep484 to u-u, its probably also something for python-apt :)
[13:32] <juliank> mvo: Once we drop python 2 support it is.
[13:32] <juliank> Or we need to strip that stuff away for python 2 builds.
[13:33] <juliank> But then I actually want to drop python2 support soon
[13:36] <mvo> juliank: there is a # type: based syntax that is both py2 and py3 compatible, I use that in u-u because I need py2 compat
[13:36] <mvo> juliank: its not as nice as the proper py3 stuff of course
[13:36] <mvo> juliank: but gets the job done
[13:37] <juliank> Hmm, yes, we can do that. But I have to say it looks ugly :/
[13:37] <juliank> The major advantage of that for me is to have nicely readable type info
[13:37] <mvo> juliank: I'm very excited about this, it brings python to a new level for me, the lack of basic static checking was always annoying me. agreed on UGLY
[13:38] <juliank> We also really need to fix all the PEP8 errors in python-apt at some point
[13:38] <juliank> I just added a hack to make it ignore that in the pre-build script :D
[13:38] <mvo> juliank: indeed
[13:38] <mvo> juliank: ha!
[13:38] <juliank> python-apt uploads are basically NMU-style right now
[13:39] <juliank> And perpetual beta
[13:40] <juliank> It's missing like *one* binding to leave beta state
[13:40] <mvo> juliank: which one is this? just out of curiosity
[13:40] <juliank> Something with the MD5->HashsumList (??) transition is missing
[13:41] <mvo> juliank: aha, that sounds reasonable
[13:42] <juliank> mvo: It's apt_pkg.SourceRecords where 'files' is a list of tuples (md5: str, size: int, path: str, type: str)
[13:42] <juliank> This tuple needs to become some magic type that works as a tuple, and also has named fields with a hashstringlist instead of md5
[13:43] <juliank> And tuple-style access should cause deprecation warnings of course :)
[13:43]  * mvo nods
[13:44] <mvo> juliank: let me have a quick look at this pep8 stuff while I'm wait for my other code to run tests
[13:45] <infinity> mvo: Do you remember how Python works?
[13:46] <mvo> infinity: *cough*
[13:46]  * mvo hugs infinity
[13:47] <infinity> mvo: Honestly, more curious if you remember how C++ works, but that's less relevant to the above discussion. :P
[13:48] <juliank> infinity: Maybe mvo should work on the Go bindings instead. They only do configuration now https://github.com/julian-klode/go-apt
[13:48] <juliank> :D
[13:48] <mvo> juliank: ha! nice, I was actually thinking aobut this
[13:48] <infinity> juliank: I assume they're cgo bindings around libapt.  That's not how the Go community works.  The only acceptable Go solution is to rewrite libapt itself in Go.
[13:49] <infinity> (I wish I was joking)
[13:49] <juliank> infinity: They actually first wrap the C++ interface in a C interface and then wrap that in Go
[13:49] <mvo> infinity: I still do, but right now my go skills are way more fluent
[13:49] <infinity> juliank: Sure, yes.  Hence "cgo".
[13:49] <juliank> Because of course, C++ is not supported directly by cgo :(
[13:50] <juliank> That said, it might be useful to have a nice, easy-to-use C binding for APT
[13:50] <infinity> To be fair, cgo isn't supported by cgo.  See above. :P
[13:50] <infinity> But agreed that a libcapt that's a C binding to libapt would be nice.
[13:50] <infinity> And then the cgo bindings would link libcapt.
[13:50] <infinity> *hand-wavy*
[13:51] <juliank> Exactly
[13:52] <juliank> I currently mostly write Go, it's always confusing to switch to C or C++
[13:52] <juliank> Right now I'm used to if expression { } ...
[13:53] <infinity> Yeah, I don't write any Go, but I read/review more than I'd like, and it's the subtle syntax differences that would drive me nuts if I were writing it.
[13:53] <infinity> I mean, I'm sure I'd be fine if it was my only language, but it seems gratuitously nasty for people who need to switch back and forth.
[13:54] <juliank> If you're used to if (...) {} and never write if (...) statement, it's fine, gofmt automatically drops the ()
[13:54] <juliank> That said, the only C++ code I touch atm is apt, and that's not even a style I like
[13:55] <juliank> That's worked around now, though: All new code is automatically formated with clang-format :D
[13:55] <juliank> s/new/changed/
[13:56] <infinity> No sympathy here, most of the C I touch is glibc, which is GCS, ish.
[13:56] <juliank> (APT is Allman style with 3 space indent, 8 space tabs, and tabs always used)
[13:56] <juliank> glibc is awful
[13:56] <infinity> That whole 4 spaces, tab, tab+4spaces, etc thing drives me batty.
[13:56] <mvo> go fmt ftw!
[13:57] <juliank> go fmt definitely was the right decision
[13:57] <infinity> But changing the whitespace formatting of a project that large is basically a non-starter, and we all prefer consistency to having new code formatted "better", so we're stuck with what we have.
[13:58] <infinity> Changing format of a project is a stellar way to break all VCS history.
[13:58] <juliank> infinity: It's better than 3 spaces, 6 spaces, 1 tab + 1 space, tab + 4 space, tab + 7 space, 2 tab + 2 space
[13:59] <infinity> That made my head hurt.
[13:59] <infinity> I don't care if people prefer tabs or spaces, I just prefer a style that uses one or the other, not both.
[13:59] <Laney> and Unicode identifiers?
[13:59] <infinity> Mixed styles offend me.
[14:00] <juliank> infinity: It's OK if you have tabs for indentation, and spaces for alignment of continuation lines.
[14:00] <infinity> juliank: Oh yes, and that's my preferred POSIX shell style.
[14:01] <infinity> juliank: I don't consider continuation to be part of indentation, though, it's just a bonus to make something a bit more friendly.
[14:01] <infinity> (And continuation styles mixed with line-length caps are where Python PEP-whatever kills me)
[14:02] <infinity> Cause hey, it's totally "readable" to break your (foo, bar, baz, thing, stuff) across 7 lines because it happens near the end of an 80-char line.
[14:02] <infinity> Yep.
[14:02] <infinity> Super readable.
[14:02] <infinity> Except, y'know, the opposite thing.
[14:02] <juliank> Sometimes it's quite nice to have one element per line
[14:02] <juliank> But yeah, sometimes it gets weird
[14:03] <infinity> juliank: Okay, sure, one element per line can be intentionally readable, so pretend I meant 1 element, then 2, then 1, then...
[14:03] <infinity> Basically, following the letter of the PEP that demands no line extend past 80, and continuation happen at the opening bracket.
[14:03] <infinity> Which paints you in some fun corners.
[14:03] <juliank> Well, I'd split them up further, even if the line is shorter than it could be
[14:04] <juliank> Well, sometimes I do group related items together in a single line :)
[14:04] <juliank> mvo: One thing that will get odd about gofmt is when they fix a bug there and a lot of code gets formatted differently.
[14:04] <infinity> (Mostly, I think I'm just not on board with people who think 80 chars is somehow sacred in the modern world of HD+ displays, etc)
[14:05] <mvo> juliank: yeah, its important that the repo keeps go fmt clean
[14:05] <infinity> If you're still stuck in an 80x24 terminal, you might have bigger problems than my line lengths.
[14:05] <juliank> mvo: No, I meant if gofmt changes its output format, that will cause quite some turmoil
[14:06] <infinity> juliank: Yeah, see above with my "changing format breaks VCSes". :/
[14:06] <juliank> infinity: 80 characters is nice because narrower text is easier to read due to some unknown reasons.
[14:06] <infinity> OTOH, you get to take credit for a 25000 line commit when you commit the changes!
[14:06] <juliank> But it should be a soft rule, not a hard rule
[14:06] <maswan> juliank: also, that's roughly 80 chars on the right hand side of indentation
[14:06] <juliank> infinity: NeoMutt reformatted all code with clang-format, if you need an example :)
[14:07] <infinity> juliank: Oh, I'm super dyslexic (I need to track with a finger or ruler, use intentionally small browsers, etc), but if a line needs to be long to be readable, it needs to be long.  Such is life.
[14:07] <maswan> juliank: if you go by "ease of reading text"
[14:07] <LocutusOfBorg> mapreri, devscripts "seems" fixed
[14:07] <LocutusOfBorg> ta
[14:07] <juliank> maswan: Yes, code is fairly similar to text, so I'd assume they'd behave differently, but there was obviously only a study on the latter
[14:08] <juliank> s/differently/similarly/
[14:08] <infinity> maswan: A fair point.  And if those standards were written because of line-tracking/reading issues, "80 chars after the whitespace" would be a much saner rule.
[14:09] <infinity> maswan: But, of course, they were written because of 80x24 VT terminals, not readability.
[14:10] <infinity> Ultimately, I guess we can blame DEC.
[14:10] <infinity> Somehow.
[15:26] <doko> jamespage: ceph has some installability issue in proposed
[15:42] <xnox> cyphermox, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/i386/n/nplan/20170725_021235_59459@/log.gz nplan seems to fail, looking at i386 history it is flaky. But i do wonder if util-linux affects NM on i386 in strange ways. As usually one or two retries does the trick.
[15:43] <xnox> AssertionError: timed out waiting for NetworkManager to settle down
[15:44] <xnox> and there are also
[15:44] <xnox> Error: Could not create NMClient object: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying
[15:44] <xnox> is there a way to get the test pass, or troubleshoot what is going on. on i386.
[15:44] <xnox> it is holding up util-linux at the moment.
[15:44] <xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#util-linux
[15:48] <jamespage> doko: yeah - needs a MIR of something - on my list for this week
[15:50] <doko> jamespage: needed for python3-defaults to migrate
[15:50] <jamespage> doko: ok bumping priority
[15:52] <infinity> jamespage: Looks like it just needs cherryp3 to re-promote.  It was already MIRed in saucy.
[15:52]  * infinity does that now.
[15:52] <doko> jamespage: it's not the last blocker, but thanks
[15:52] <jamespage> infinity: yeah - I was just looking at that - thanks!
[16:11] <mapreri> LocutusOfBorg: \o/
[16:30] <mapreri> mwhudson: FWIW, diffoscope builds with today's binutils
[16:30] <mapreri> well, once fixed the other thing, etc
[16:31] <mapreri> git is in a funky state atm, but will upload once things are cooled down....
[16:31] <mapreri> (I prefer to not branch out just for this, but of course I can do a number of things if suddenly a buildable diffoscope is needed urgently…)
[16:56] <xnox> C++ is aweful
[17:59] <catbus> Hi, will 17.04 4.11 kernel be available in the 16.04 daily image before the 16.04.3 is released? Wondering if there is sort of a beta version to try.
[18:01] <sarnold> catbus: maybe this https://launchpad.net/ubuntu/+source/linux-hwe-edge ?
[18:07] <catbus> sarnold: I think I found what I am looking for: http://cdimage.ubuntu.com/ubuntu-server/xenial/daily/current/.
[18:09] <sarnold> /pool/main/l/linux-hwe/linux-image-4.10.0-28-generic_4.10.0-28.32~16.04.2_amd64.deb
[18:09] <sarnold> woot
[18:10] <catbus> sarnold: Thanks. I was looking for the image, not just the hwe-kernel package.
[20:57] <mwhudson> so why hasn't python3-defaults migrated today
[21:31] <ricotz> mwhudson, afaics there are some desktop-packages which need a python-nochange-rebuild: e.g. eog-plugins, gedit, gedit-plugins