=== maclin1 is now known as maclin | ||
=== maclin1 is now known as maclin | ||
=== maclin1 is now known as maclin | ||
mwhudson | xnox: hooray | 09:41 |
---|---|---|
mwhudson | (ubuntu-make) | 09:42 |
mwhudson | xnox: so just need to get botch kicked out of artful-release and then python3-defaults should migrate? | 09:43 |
xnox | mwhudson, yeah, need to ping steve again about it. | 09:55 |
mwhudson | an archive admin, my kingdom for an archive admin | 09:56 |
xnox | mwhudson, i take your kingdom and raise you an empire | 09:57 |
=== sergiusens_ is now known as sergiusens | ||
ginggs | mwhudson: archive admins are next door, in -release | 10:25 |
mwhudson | ginggs: yeah | 10:26 |
clivejo | anyone here familiar with python module packaging? | 10:27 |
clivejo | Trying to use gbp buildpackage with this git repo https://anonscm.debian.org/cgit/python-modules/packages/pyee.git | 10:28 |
clivejo | but something keeps changing version.txt | 10:29 |
ginggs | mwhudson: and only offer them part of your kingom | 10:31 |
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:32 |
clivejo | would you have a package I could see it in action? | 10:34 |
clivejo | an example of how its done | 10:34 |
cjwatson | sorry, no | 10:53 |
cjwatson | but git ignore isn't hard to look up | 10:54 |
clivejo | cjwatson: I have tried adding version.txt to .gitignore but gbp is still complaining that it has changed | 11:28 |
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:29 |
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 | 11:30 |
mapreri | doko: does that binutils upload include https://sourceware.org/bugzilla/show_bug.cgi?id=21820 as well? | 12:05 |
ubottu | sourceware.org bug 21820 in binutils "[2.29 Regression] readelf now exits with error reading an empty section" [Normal,Resolved: fixed] | 12:05 |
doko | mapreri: yes, forgot to add the changelog entry | 12:07 |
mapreri | doko: cool, thanks | 12:07 |
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. | 12:39 |
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:13 |
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:14 |
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:15 | |
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:18 |
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:19 |
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:20 |
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:21 |
juliank | I mean, we can roll out the u-u change too, I think, now that it's merged. | 13:22 |
juliank | rbalint pushed these to mvo | 13:23 |
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:25 |
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:28 |
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:29 |
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:30 |
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:32 |
juliank | But then I actually want to drop python2 support soon | 13:33 |
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:36 |
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:37 |
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:38 |
juliank | And perpetual beta | 13:39 |
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:40 |
mvo | juliank: aha, that sounds reasonable | 13:41 |
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:42 |
juliank | And tuple-style access should cause deprecation warnings of course :) | 13:43 |
* mvo nods | 13:43 | |
mvo | juliank: let me have a quick look at this pep8 stuff while I'm wait for my other code to run tests | 13:44 |
infinity | mvo: Do you remember how Python works? | 13:45 |
mvo | infinity: *cough* | 13:46 |
* mvo hugs infinity | 13:46 | |
infinity | mvo: Honestly, more curious if you remember how C++ works, but that's less relevant to the above discussion. :P | 13:47 |
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:48 |
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:49 |
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:50 |
juliank | Exactly | 13:51 |
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:52 |
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:53 |
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:54 |
juliank | That's worked around now, though: All new code is automatically formated with clang-format :D | 13:55 |
juliank | s/new/changed/ | 13:55 |
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:56 |
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:57 |
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:58 |
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. | 13:59 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
infinity | maswan: But, of course, they were written because of 80x24 VT terminals, not readability. | 14:09 |
infinity | Ultimately, I guess we can blame DEC. | 14:10 |
infinity | Somehow. | 14:10 |
=== PaulW2U_ is now known as PaulW2U | ||
doko | jamespage: ceph has some installability issue in proposed | 15:26 |
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:42 |
xnox | AssertionError: timed out waiting for NetworkManager to settle down | 15:43 |
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:44 |
jamespage | doko: yeah - needs a MIR of something - on my list for this week | 15:48 |
doko | jamespage: needed for python3-defaults to migrate | 15:50 |
jamespage | doko: ok bumping priority | 15:50 |
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! | 15:52 |
=== Bluefoxicy_ is now known as Bluefoxicy | ||
mapreri | LocutusOfBorg: \o/ | 16:11 |
mapreri | mwhudson: FWIW, diffoscope builds with today's binutils | 16:30 |
mapreri | well, once fixed the other thing, etc | 16:30 |
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:31 |
=== gusnan_ is now known as gusnan | ||
xnox | C++ is aweful | 16:56 |
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. | 17:59 |
sarnold | catbus: maybe this https://launchpad.net/ubuntu/+source/linux-hwe-edge ? | 18:01 |
=== fossfreedom_ is now known as fossfreedom | ||
catbus | sarnold: I think I found what I am looking for: http://cdimage.ubuntu.com/ubuntu-server/xenial/daily/current/. | 18:07 |
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:09 |
catbus | sarnold: Thanks. I was looking for the image, not just the hwe-kernel package. | 18:10 |
=== JanC_ is now known as JanC | ||
=== bdmurray_ is now known as bdmurray | ||
=== est31_ is now known as est | ||
mwhudson | so why hasn't python3-defaults migrated today | 20:57 |
ricotz | mwhudson, afaics there are some desktop-packages which need a python-nochange-rebuild: e.g. eog-plugins, gedit, gedit-plugins | 21:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!