[00:17] Odd_Bloke: Something about this particular case, I think - https://pastebin.canonical.com/142724/ but that code didn't change in the last deployment and hasn't changed for some time [00:18] Odd_Bloke: Can you file a bug with details and referencing the OOPS ID, please? [00:18] We still have relatively few users of git-based MPs, so it's probably specific to some subcase of that. [00:48] Odd_Bloke: Indeed, it looks like any git diff that involves an extended header line will fail. [00:49] Odd_Bloke: Well, other than "index .. ". [01:08] Odd_Bloke: Never mind, I filed https://bugs.launchpad.net/launchpad/+bug/1510337 [01:08] Launchpad bug 1510337 in Launchpad itself "Extended headers in git diffs break patch parsing" [Critical,In progress] [01:12] cjwatson: hmm fun, I thought we had a few git tests [01:12] We do, but they don't cover extended header lines. [01:12] I'm fixing that. [01:13] (Or at least they don't cover most extended header lines.) [01:50] blr: https://code.launchpad.net/~cjwatson/launchpad/git-patch-headers/+merge/275792 [02:05] ergh, I just changed some stuff in the packaging, and it's not building for ARM... [02:05] https://launchpadlibrarian.net/222927857/buildlog_ubuntu-vivid-armhf.libretro-gpsp_0.9%2Br247~10~ubuntu15.04.1_BUILDING.txt.gz [02:06] this gba emu has ARM dynarec which I think is hard to build in the launchpad, but last time it built... [02:08] the diff: http://bazaar.launchpad.net/~libretro/libretro/gpsp-libretro-debian/revision/10 [02:08] I'm pretty sure it's not my fault... [02:11] sergio-br2: Launchpad itself doesn't really have a whole lot to do with this. I suspect you'd do better to diff build logs and/or consult an ARM/toolchain expert [02:12] hum [02:12] You have a working build log from before, so you can diff it and see what compiler options changed etc. [02:12] And try changing them back and seeing if it works again [02:13] weird, there's this fstack-protector-strong, I didn't add that [02:13] e.g. perhaps the change from -fstack-protector to (implicitly via dpkg-buildflags) -fstack-protector-strong makes some kind of difference for some reason [02:13] the working log: https://launchpadlibrarian.net/222742385/buildlog_ubuntu-vivid-armhf.libretro-gpsp_0.9%2Br247~9~ubuntu15.04.1_BUILDING.txt.gz [02:13] Don't tell us, diff it yourself please [02:13] :p [02:14] You effectively switched to dpkg-buildflags by changing to DEB_*FLAGS_MAINT_* [02:14] yup [02:14] That's normally a good direction to take, but in some cases it needs further overrides, and it's certainly a place to look for problems of this kind [02:14] before I was overriding it [02:15] also -g flag [02:15] weird, the CFLAGS should be -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security [02:16] not with this fstack-protector-strong [02:16] though it's hard to imagine either influencing a section named .jit [02:16] I removed the -g, so it was building without debug symbols right? [02:16] $ dpkg-buildflags --get CFLAGS [02:16] -g -O2 -fstack-protector-strong -Wformat -Werror=format-security [02:17] Mine is -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security [02:17] It depends on the release. [02:17] why yours is protect? [02:17] humm [02:17] mine is 14.04 [02:17] Right, which is different. [02:18] The Launchpad build you're referring to is vivid, so unless you know the packaging toolchain well enough to know all the differences then maybe you might be well advised to check there? [02:18] ok, so probably this is not the problem, the log from 14.04 has -fstack-protector too [02:18] I'll try to remove the -g i guess [02:18] The vivid log has -fstack-protector-strong, which is different. I'm not saying that that is definitely the problem or anything, but you should check all the obvious differences. [02:18] with -s is no debug symbol right? [02:19] * the 14.04 also failed [02:19] -s? what? [02:19] -s -O2 [02:19] Do you mean -g? [02:19] instead -g -O2 [02:19] Omit it, don't make up some random other flag :) [02:19] ok :) [02:20] Should just need to add -g to *_MAINT_STRIP [02:21] yup [02:21] let's see [02:22] cjwatson: so many fun cases to handle in this code... [02:23] that seems like a good approach though, certainly trying to match every possible extended header could be problematic in the future? [02:25] Yeah, there are enough entries that I'd rather treat it as an open-ish set [02:57] cjwatson, it worked [11:18] cjwatson: wgrant: Is there a problem with git hosting ATM? I'm seeing a Jenkins job that started failing in the last hour, and I've noticed rumblings about problems in other channels. [11:19] Odd_Bloke: Can you link to details? [11:19] (wgrant is on holiday) [11:20] cjwatson: I'm seeing http://paste.ubuntu.com/12978751/ in a Jenkins job that was working about an hour ago. [11:21] cjwatson: And the rumblings: http://paste.ubuntu.com/12978753/ [11:22] ouch [11:23] investigating [11:23] Thanks. [11:38] Odd_Bloke: Fixed now; maas decided to turn on dnssec validation on one of the internal nameservers, which doesn't work so well for .internal names. [11:38] cjwatson: Thanks muchly. [11:39] cjwatson: Have let the other folks who were hitting issues know as well. :) [20:08] Did I do good by changing that bug's project, or do I need to revert it some way and report a new bug? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1507957 [20:08] Launchpad bug 1507957 in network-manager (Ubuntu) "Huawei E3372 LTE modem on 15.10 works only when connecting via wvdial and not network-manager" [Medium,Confirmed] [20:24] Cysioland: ask in #ubuntu for help about reporting ubuntu bugs; this channel is more about questions about how to use launchpad itself, and not for answquering questions about how projects that use launchpad manage their bugs [20:24] and bug related questions like that are likely supposed to be in #ubuntu-bugs (bug triage questions usually end up there) [20:25] oh right, yeah, #ubuntu-bugs [20:25] :) [20:25] (so many irc channels, can't remember them all if i don't hang out in them) [20:25] On #ubuntu nobody responds, maybe #ubuntu-bugs will work [20:26] dobey: happens to us all :0