=== maclin1 is now known as maclin === maclin1 is now known as maclin === maclin1 is now known as maclin [09:41] xnox: hooray [09:42] (ubuntu-make) [09:43] xnox: so just need to get botch kicked out of artful-release and then python3-defaults should migrate? [09:55] mwhudson, yeah, need to ping steve again about it. [09:56] an archive admin, my kingdom for an archive admin [09:57] mwhudson, i take your kingdom and raise you an empire === sergiusens_ is now known as sergiusens [10:25] mwhudson: archive admins are next door, in -release [10:26] ginggs: yeah [10:27] anyone here familiar with python module packaging? [10:28] Trying to use gbp buildpackage with this git repo https://anonscm.debian.org/cgit/python-modules/packages/pyee.git [10:29] but something keeps changing version.txt [10:31] mwhudson: and only offer them part of your kingom [10:32] clivejo: That would be the fact that it uses https://pypi.python.org/pypi/vcversioner [10:32] clivejo: version.txt should probably be gitignored [10:34] would you have a package I could see it in action? [10:34] an example of how its done [10:53] sorry, no [10:54] but git ignore isn't hard to look up [11:28] cjwatson: I have tried adding version.txt to .gitignore but gbp is still complaining that it has changed [11:29] yeah you would have to actually remove it too [11:29] perhaps there's a problem with it being in the upstream tarball though, I haven't checked [11:30] git rm --cached version.txt [11:30] you might need to arrange to put back the upstream version on debian/rules clean [11:30] then added my .gitignore [12:05] doko: does that binutils upload include https://sourceware.org/bugzilla/show_bug.cgi?id=21820 as well? [12:05] sourceware.org bug 21820 in binutils "[2.29 Regression] readelf now exits with error reading an empty section" [Normal,Resolved: fixed] [12:07] mapreri: yes, forgot to add the changelog entry [12:07] doko: cool, thanks [12:39] 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] 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] 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] there is time to verify it and push it through. [13:15] infinity: There'll be another round with further improvements, but as it is, it already is a substantial improvement in itself. [13:15] it would be nice, if we shipped it like 3 weeks ago, as clouds are complaining. [13:15] Yeah [13:15] 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] 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] YES [13:18] yes. [13:18] Do we need unattended-upgrades changes to go with it, or can that apt update stand alone? [13:19] It's an improvement either way. With the u-u changes it would be nicer [13:19] Well, I don't see any u-u changes anywhere, which is why I asked. :P [13:20] I thought there was something about needing new CLI options. [13:20] 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] em, read that right to left [13:20] If only those were in an archive somewhere. [13:21] >_< [13:21] i thought options were not needed =/ [13:21] I wanted to get feedback on it :) [13:21] Ahh, right, the apt bits check for the new option before attempting to use it. [13:22] I mean, we can roll out the u-u change too, I think, now that it's merged. [13:23] rbalint pushed these to mvo [13:25] 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] 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] 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] 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] juliank: I had one feedback item for rbalint in the PR, otherwise this looks good [13:30] juliank: I also want to add pep484 to u-u, its probably also something for python-apt :) [13:32] mvo: Once we drop python 2 support it is. [13:32] Or we need to strip that stuff away for python 2 builds. [13:33] But then I actually want to drop python2 support soon [13:36] 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] juliank: its not as nice as the proper py3 stuff of course [13:36] juliank: but gets the job done [13:37] Hmm, yes, we can do that. But I have to say it looks ugly :/ [13:37] The major advantage of that for me is to have nicely readable type info [13:37] 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] We also really need to fix all the PEP8 errors in python-apt at some point [13:38] I just added a hack to make it ignore that in the pre-build script :D [13:38] juliank: indeed [13:38] juliank: ha! [13:38] python-apt uploads are basically NMU-style right now [13:39] And perpetual beta [13:40] It's missing like *one* binding to leave beta state [13:40] juliank: which one is this? just out of curiosity [13:40] Something with the MD5->HashsumList (??) transition is missing [13:41] juliank: aha, that sounds reasonable [13:42] mvo: It's apt_pkg.SourceRecords where 'files' is a list of tuples (md5: str, size: int, path: str, type: str) [13:42] 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] And tuple-style access should cause deprecation warnings of course :) [13:43] * mvo nods [13:44] juliank: let me have a quick look at this pep8 stuff while I'm wait for my other code to run tests [13:45] mvo: Do you remember how Python works? [13:46] infinity: *cough* [13:46] * mvo hugs infinity [13:47] mvo: Honestly, more curious if you remember how C++ works, but that's less relevant to the above discussion. :P [13:48] infinity: Maybe mvo should work on the Go bindings instead. They only do configuration now https://github.com/julian-klode/go-apt [13:48] :D [13:48] juliank: ha! nice, I was actually thinking aobut this [13:48] 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] (I wish I was joking) [13:49] infinity: They actually first wrap the C++ interface in a C interface and then wrap that in Go [13:49] infinity: I still do, but right now my go skills are way more fluent [13:49] juliank: Sure, yes. Hence "cgo". [13:49] Because of course, C++ is not supported directly by cgo :( [13:50] That said, it might be useful to have a nice, easy-to-use C binding for APT [13:50] To be fair, cgo isn't supported by cgo. See above. :P [13:50] But agreed that a libcapt that's a C binding to libapt would be nice. [13:50] And then the cgo bindings would link libcapt. [13:50] *hand-wavy* [13:51] Exactly [13:52] I currently mostly write Go, it's always confusing to switch to C or C++ [13:52] Right now I'm used to if expression { } ... [13:53] 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] 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] If you're used to if (...) {} and never write if (...) statement, it's fine, gofmt automatically drops the () [13:54] That said, the only C++ code I touch atm is apt, and that's not even a style I like [13:55] That's worked around now, though: All new code is automatically formated with clang-format :D [13:55] s/new/changed/ [13:56] No sympathy here, most of the C I touch is glibc, which is GCS, ish. [13:56] (APT is Allman style with 3 space indent, 8 space tabs, and tabs always used) [13:56] glibc is awful [13:56] That whole 4 spaces, tab, tab+4spaces, etc thing drives me batty. [13:56] go fmt ftw! [13:57] go fmt definitely was the right decision [13:57] 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] Changing format of a project is a stellar way to break all VCS history. [13:58] 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] That made my head hurt. [13:59] 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] and Unicode identifiers? [13:59] Mixed styles offend me. [14:00] infinity: It's OK if you have tabs for indentation, and spaces for alignment of continuation lines. [14:00] juliank: Oh yes, and that's my preferred POSIX shell style. [14:01] 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] (And continuation styles mixed with line-length caps are where Python PEP-whatever kills me) [14:02] 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] Yep. [14:02] Super readable. [14:02] Except, y'know, the opposite thing. [14:02] Sometimes it's quite nice to have one element per line [14:02] But yeah, sometimes it gets weird [14:03] juliank: Okay, sure, one element per line can be intentionally readable, so pretend I meant 1 element, then 2, then 1, then... [14:03] Basically, following the letter of the PEP that demands no line extend past 80, and continuation happen at the opening bracket. [14:03] Which paints you in some fun corners. [14:03] Well, I'd split them up further, even if the line is shorter than it could be [14:04] Well, sometimes I do group related items together in a single line :) [14:04] 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] (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] juliank: yeah, its important that the repo keeps go fmt clean [14:05] If you're still stuck in an 80x24 terminal, you might have bigger problems than my line lengths. [14:05] mvo: No, I meant if gofmt changes its output format, that will cause quite some turmoil [14:06] juliank: Yeah, see above with my "changing format breaks VCSes". :/ [14:06] infinity: 80 characters is nice because narrower text is easier to read due to some unknown reasons. [14:06] OTOH, you get to take credit for a 25000 line commit when you commit the changes! [14:06] But it should be a soft rule, not a hard rule [14:06] juliank: also, that's roughly 80 chars on the right hand side of indentation [14:06] infinity: NeoMutt reformatted all code with clang-format, if you need an example :) [14:07] 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] juliank: if you go by "ease of reading text" [14:07] mapreri, devscripts "seems" fixed [14:07] ta [14:07] 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] s/differently/similarly/ [14:08] 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] maswan: But, of course, they were written because of 80x24 VT terminals, not readability. [14:10] Ultimately, I guess we can blame DEC. [14:10] Somehow. === PaulW2U_ is now known as PaulW2U [15:26] jamespage: ceph has some installability issue in proposed [15:42] 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] AssertionError: timed out waiting for NetworkManager to settle down [15:44] and there are also [15:44] Error: Could not create NMClient object: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying [15:44] is there a way to get the test pass, or troubleshoot what is going on. on i386. [15:44] it is holding up util-linux at the moment. [15:44] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#util-linux [15:48] doko: yeah - needs a MIR of something - on my list for this week [15:50] jamespage: needed for python3-defaults to migrate [15:50] doko: ok bumping priority [15:52] jamespage: Looks like it just needs cherryp3 to re-promote. It was already MIRed in saucy. [15:52] * infinity does that now. [15:52] jamespage: it's not the last blocker, but thanks [15:52] infinity: yeah - I was just looking at that - thanks! === Bluefoxicy_ is now known as Bluefoxicy [16:11] LocutusOfBorg: \o/ [16:30] mwhudson: FWIW, diffoscope builds with today's binutils [16:30] well, once fixed the other thing, etc [16:31] git is in a funky state atm, but will upload once things are cooled down.... [16:31] (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…) === gusnan_ is now known as gusnan [16:56] C++ is aweful [17:59] 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] catbus: maybe this https://launchpad.net/ubuntu/+source/linux-hwe-edge ? === fossfreedom_ is now known as fossfreedom [18:07] sarnold: I think I found what I am looking for: http://cdimage.ubuntu.com/ubuntu-server/xenial/daily/current/. [18:09] /pool/main/l/linux-hwe/linux-image-4.10.0-28-generic_4.10.0-28.32~16.04.2_amd64.deb [18:09] woot [18:10] sarnold: Thanks. I was looking for the image, not just the hwe-kernel package. === JanC_ is now known as JanC === bdmurray_ is now known as bdmurray === est31_ is now known as est [20:57] so why hasn't python3-defaults migrated today [21:31] mwhudson, afaics there are some desktop-packages which need a python-nochange-rebuild: e.g. eog-plugins, gedit, gedit-plugins