[00:04] so, is Lua 5.1 going to continue to be in 'main' in Xenial or are there plans to make it Universe or something going forward? [00:11] teward, any action on demoting this would be appreciated [00:13] doko_: the reason I asked is because nginx-extras will lose a feature I know a ton of people use [00:13] i think that and Apache were reasons for it staying in Main with 14.04 [00:13] "ton"? :) [00:13] sarnold: substantial percentage of people using nginx [00:13] exact # unknown, but i've posed questions to the world 'bout the lua dropping and it was met with negativeness [00:13] teward: interesting. I still haven't run into any mentions of it casually.. [00:13] * teward yawns [00:14] sarnold: your name isn't on the 'last uploaded by' field [00:14] * teward gets a lot of emails :/ [00:14] hehe [00:14] point not withstanding [00:14] if lua 5.1 is demoted, it drops from nginx as a build dep [00:14] which means dropping Lua module in the universe packages [00:14] which I don't particularly mind (Lua module users have the PPA which isn't bound to the Main restricts) [00:15] but while i'm stabbing the merge right now... :P [00:15] thought i'd ask about the state of lua 5.1 and whether dropping is planned by 16.04 release [00:15] (dropping from Main, that is) [00:15] teward: obligatory reminder, please keep http/2 off for now.. [00:15] sarnold: ack [00:16] sarnold: note that the SPDY users will hate you and the Sec team for that [00:16] I'd really rather that code have a few more eyes and fuzzers thrown at it before we throw it live into an lts :) [00:16] since there's no SPDY in nginx [00:16] I know, heh [00:16] sarnold: um... you were here for the Tech Board meeting right? [00:16] sarnold: by release it'll be near the 1.9.x branch, with 1.10.x as an after-release update [00:16] but I feel marginally good about getting SPDY removed from libmicrohttpd before that moved to main.. [00:16] at least, as it was discussed with the TB before the "SRU" changes [00:16] HATE my laptop >.< [00:17] but I feel marginally good about getting SPDY removed from libmicrohttpd before that moved to main.. [00:17] sarnold: perhaps you, me, and rbasak should butt heads before I upload [00:17] teward: yeah, I know it's not ideal, but turning it on via sru feels much better to me than shipping with it on before the start :) [00:17] 'cause I understand the Sec Team's opinion, but the users will kill me :P [00:19] tedg, seriously, can you remove the dependy on lua5.1? [00:19] teward, ^^^ [00:22] i reiterate: hate hate hate hate HATE my laptop sometimes [00:22] doko_: not without dropping the Lua module from nginx-extras [00:22] which rbasak and i have argued about in the past [00:22] namely with the impending liblua5.1 'demotion' [00:23] doko_: doesn't address the Apache dependency though [00:23] doko_: if it's an 'order from above' I'll drop the Lua 5.1 dep [00:23] but it's getting a release notes notice [00:23] sarnold: i'll drop HTTP2 support then [00:23] sarnold: it's your fault i now have to maintain even *more* of a delta [00:23] teward: sorry... [00:23] until 1.10.x [00:23] * teward yawns [00:23] teward: but thanks for that :) [00:23] sarnold: also not my fault Debian enabled it [00:24] it makes perfect sense for it to be enabled in e.g. debian unstable, debian testing, etc. maybe a bit premature for a debian-stable.. [00:24] (the HTTP/2 stuff also is getting a release notes note too, I believe) [00:24] sure, feel free to blame us if it helps :) [00:24] sarnold: well, there's a backports-failure problem there [00:24] sarnold: my mind's on low-coffee mode [00:24] teward,we should resolve to at least two lua versions for xenial [00:25] send me $5, coffee will be in my system, and the blaming goes away [00:25] doko_: what's currently in Main then for Xenial, 5.1 and 5.2? [00:25] (I remember 5.2 was a headache at 14.04 because it's essentially a different beast) [00:25] teward, it would be 5.3 and another version [00:26] currently we have three, 5.1, 5.2 and 5.3 [00:26] doko_: has the Apache package managed to resolve the liblua5.1 depends, or dropped Lua entirely? [00:26] doko_: the reason I ask that is the initial "Lua 5.1 dependency" issue was in a bug against both [00:26] * teward digs it up [00:26] ... it'd help if Chrome weren't slow [00:26] and my computer didn't hard-reboot on me [00:27] https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1324062 [00:27] Launchpad bug 1324062 in nginx (Ubuntu) "No lua 5.2 support" [High,Triaged] [00:27] doko_: that's got an nginx and an Apache message [00:27] filed by rbasak of course [00:27] it looks like Apache's resolved it [00:27] or not [00:28] doko_: the options for nginx are "keep lua5.1 or drop Lua module" [00:28] teward, lua is insane, so getting everything to 5.3 would be preferred. if that's not possible, have *one* legacy version [00:28] it's a third party module [00:29] doko_: 5.1 would have to be the legacy then, if only to satisfy Apache and nginx headaches [00:29] but here's the real reason my options are "Drop Lua module" or "Convince 5.1 to be kept": https://github.com/openresty/lua-nginx-module/issues/343 [00:29] the third-party authors have "Won't Fix"'d the "Support 5.2+" thing === salem_ is now known as _salem [00:31] teward, so what needs to be done to remove 5.2? === _salem is now known as salem_ [00:33] doko_: nothing [00:33] at least, not from me [00:33] nginx doesn't depend on 5.2 [00:34] doko_: nginx-extras and the Lua module depends on 5.1 [00:34] so if 5.1 is the legacy version kept, then I don't have to do anything [00:34] and then I get concerned at 18.04 or next LTS about 5.1 dying [00:34] i would check the Apache deps though [00:35] they may need 5.2 [00:35] doko_: the question is, do we keep 5.1 or 5.2 [00:36] and if the answer is 5.2, then nginx-extras (universe) loses the Lua module [00:36] and a notice goes out to those users to switch to the PPAs instead [00:36] sarnold: oh, i reminded myself, any chance the SRU to turn on HTTP/2 can go out as a sec update as well as SRU? Odd request, but the reason I ask is that 1.10.x is supported when 1.9.x is 'dead' come 1.10.x's release and SRUing [00:37] sarnold: those who only use the security repos in addition to the base main repos would miss [00:37] teward: though missing it would be part of the reason for sticking with -security rather than -updates :) [00:38] sarnold: well, you have two issues then: [00:38] (1) HTTP/2 is never available [00:38] (2) last minute fixes between 1.9.x final and 1.10.x which could be security in nature are missed [00:38] and esp. if dynamic module support becomes a thing then that's seriously missed [00:38] (and a major hell-hole is opened) [00:38] teward: if there's bits in #2 that justify an update, then it could be included [00:38] teward, I disagree, please see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt [00:38] Didn't you just claim a lot of the users use the PPA anyway? [00:38] Unit193: 14.04 users, mostly [00:39] Unit193: because it's outdated in the repos [00:39] teward, I don't care about 5.1/5.2 [00:39] doko_: what do i look for under the mismatches [00:39] * teward isn't pro at reading yet :/ [00:40] teward, getting 5.1 or 5.2 demoted [00:41] doko_: there are no references to "5.2" in that file and the only references to "52" appear unrelated (a52dec, golang-gettext) [00:43] sarnold, teward: "appear unrelated", please can you explain? [00:43] doko_: wasn't sure what you wanted me to look for is all [00:43] * teward yawns [00:43] though sarnold knows more about that file [00:43] i don't see Lua 5.2 in there though [00:43] nor 5.1 [00:43] doko_: I do not know how a52dec or golang-gettext are at all related to lua 5.2. [00:43] and the only Lua stuff I see there is libluajit [00:44] which isn't a factor in nginx (and dropped actually during the merge) [00:44] (though Debian has that for one of the 'rare' arches) [00:45] sorry guys, I'm afk. will look at that tomorrow [00:45] night doko_ :) [00:45] 'night [00:45] sarnold: build-testing the no-http2 stuff now [00:45] and in other news my hands hurt [00:49] sarnold: mind doing me a favor by the way and state it's a Sec Team mandate on the merge bug to disable HTTP/2 [00:49] (https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1510096) [00:49] Launchpad bug 1510096 in nginx (Ubuntu) "Please merge 1.9.6-2 (main) from Debian Unstable (main)" [Wishlist,In progress] [00:49] that way if users complain I point there [00:52] ehh, nevermind, i'll add it myself [00:52] done [00:52] oop speed is speed xD [00:52] that works [00:52] though SPDY is *gone* [00:53] yay :) [00:53] heh [00:54] been gone since HTTP/2 was introduced [00:55] sarnold: i'm ACKing that but adding in a note on SPDY. I assume we'd be OK with HTTP/2 being enabled in 1.10.x when it lands, SRU or otherwise? [00:55] teward: preferable 1.10.1 or .2 :) [00:55] ok [00:55] ehh [00:56] sarnold: i question that, because theres zero guarantee of a 1.10.1 [00:56] consider the current stable branch [00:56] 1.8.0 has received no updates, bugfixes, etc. since April release [00:56] hmm. that's either really good or really bad :) [00:56] and in April 2016, it gets torpedoed [00:57] and the next stable is released [00:57] sarnold: indeed, this was brought up in the TB discussion as well [00:57] sarnold: security patches can probably be done easily [00:57] If my pessism is correct, there'll be a .1 :) [00:57] but that doesn't resolve the number of 16.04 LTS users who are going to be "Hey, where's HTTP/2?" [00:57] (and after 16.04 release, I'll be pointing at the Sec Team, and saying "all complaints to there") [00:57] or rather, the users will [00:57] * teward yawns [00:58] i need to stop working on this at some point, i've been working on this since 11AM :/ [00:59] sarnold: i think Stable only gets fixes if there's a huge security hole that needs patching, or a major bug [00:59] but I can pass that to NGINX and ask [00:59] (or you can, if you can get LinuxJedi when he's around xD) [01:03] doko_: AIUI, 5.1 and 5.2 are essentially different incompatible languages. Like Python 2 and Python 3. Or so I've been told. [01:04] doko_: I understand that you don't want to maintain 5.1 and 5.2 and 5.3. That's reasonable. [01:04] doko_: but OTOH pushing upstreams to move up is difficult because of the backwards incompatibility. [01:05] doko_: I think Ubuntu should pick one, file bugs with upstreams as needed, and then drop support if that version is not supported by upstream. [01:05] doko_: I don't think the latest is necessarily the right one to pick though. The most commonly supported version is maybe a better criterion. [01:06] rbasak, I agree, so should it be 5.1 or 5.2? [01:06] doko_: I don't know enough about lua or what upstreams support to answer that unfortunately. [01:07] doko_: whatever we pick, I'd like a researched statement to point people to if they complain about lack of support. [01:08] Eg. (I'm making this up) "lua 5.1 was supported by A, B and C upstreams, but not D, lua 5.2 was supported by X, Y and Z, so we decided to go with 5.1 to maximise upstream support, and your upstream lost out, sorry". [01:08] oh hey rbasak is alive [01:08] I haven't heard of any complaints about migrating from 5.2 to 5.3. I think people have the emotional attachment to 5.1 and want to keep that one. [01:08] rbasak: check PMs [01:08] sarnold: actually, 5.1 -> 5.2 is like dealing with almost completely different languages, from the Lua coders I know when I posed them that question [01:08] (they use Lua for a lot of things, not just nginx) [01:09] I just don't htink anyone would cry about losing 5.2. They're either on 5.1 or they paid the price and moved forward, and moving again to 5.3 is probably no big deal. [01:10] +1 for sarnold's interpretation here [01:10] sarnold: the trouble is that we have to pick one version for all upstreams in main. If the upstream doesn't happen to support that (too new or too old for them) then that's unfortunate. [01:10] Eg. a diligent upstream could have moved to 5.3 and dropped support for anything older. [01:10] And we might end up with only 5.1 in main. [01:11] rbasak: both 5.1 and 5.2 are in main from T through X [01:11] rbasak: 5.3 is in main since W [01:12] rbasak: doko wants at most two :) I think 5.1 and 5.3 would please maximal number of people, but you're right, some research would be worthwhile. [01:12] sarnold: we can arbitrarily change that for X though, if doko agrees. Eg. if we decide 5.1 is best, then we could just ship 5.1 in main in X. [01:13] rbasak: heh, in the case that 5.2 and 5.3 basically killed the lua community? [01:13] I get the impression it's just fragmented a little. The lua use case doesn't need to stick to one version across all projects that use lua. [01:14] But general distributions do need that. [01:15] So that comes down to "if you want general distros to ship projects with lua support, then move together, otherwise we'll be forced to pick for you". [01:15] MOre specifically, this applies to Ubuntu with a main/universe distinction. But Debian probably doesn't want to release three at once either. [01:16] "we're sorry your upstreams pulled a python" [01:17] I don't think it's quite the same. We'd have to compare to projects using libpython for it to be a fair comparison. [01:19] rbasak, teward: any foreward progress on 5.1 and any of 5.2 or 5.3? [01:19] doko_: zero for the nginx lua module [01:19] upstream's outright rejected the notion [01:20] for going off of 5.1 [01:20] rbasak has better gauge of the state of Server in general [01:22] doko_: I'm not aware of any progress whatsoever. I'm not interested in pushing upstreams either though. I'm happy with going with the popular choice and dropping lua support at build time for any upstreams that don't support that choice. [01:23] ^ that's my opinion as well === salem_ is now known as _salem === yuning-afk is now known as yuning [05:38] Good morning [07:11] Good morning [07:11] pitti: Hi, I'm around if you need any more feedback or vnc for https://bugs.launchpad.net/bugs/1492546 [07:11] Launchpad bug 1492546 in systemd (Ubuntu) "Systemd runs ifdown on shutdown even when it shouldn't" [Medium,Triaged] [07:14] alkisg: thanks for the journal, looks good now! [07:14] alkisg: I'll ponder that [07:14] Thank you [08:10] good morning [08:22] Laney, i wonder if i broke transition tracker [08:29] Laney, nah, all is good. [08:29] jodh, morning =) [08:50] pitti: good morning. i'm having issues with julia autopkgtest again. amd64 is good now, but i386 has a regression (it runs, but very slowly) that might only be fixed by a new llvm. is it possible to disable autopkgtests for i386, or forget that it was ever successful? [09:07] ginggs: we can do the latter, yes; or it needs a sourceful upload to skip the test on i386, but I guess we rather want to avoid introducing a delta for that [09:08] ginggs: indeed, 5h 42?? [09:08] ah, that's a regression from the new julia or from the toolchain? [09:09] pitti: both, apparently [09:21] pitti: The apt tests work on ppc64el and s390x now and those could be enforced now - the armhf and i386 ports have some timing issues (probably too slow) [09:29] * juliank is not sure if they were automatically ignored, if there was a setting to ignore !amd64 architectures, but anyway: ppc64el and s390x works now, and we should ensure that they remain that way. [09:32] juliank: they are automatically enforced -- once they succeed on an architecture, they must continue to succeed [09:32] Ah OK [09:32] juliank: i. e. we differ between "always failed" (which is not blocking) vs. "regression" (which is blocking) [09:33] juliank: and track that per-architecture [09:33] pitti: But only within in release series, right, because other archs also worked in vivid, for example. [09:33] ginggs: but if that's an actual regression on i386, wouldn't it be right to hold it back until this gets fixed? [09:33] ginggs: if julia is awfully slow on i386, that's a real problem, not just a test problem? [09:34] juliank: for wily->xenial we enforce it across the release, but we didn't retroactively do that for vivid [09:34] OK [09:34] juliank: so in general we do, just not vivid as we only set up that whole cloud testing system during wily [09:36] So if I understood things correctly, apt uploads need to be manually accepted right now, because one reverse dep (sbuild) currently fails the test suite (listed as Regression) [09:37] juliank: right; or more precisely, we ignore test failures of the current version of sbuild [09:38] OK. BTW, The python-apt and autopkgtest tests tmpfail on s390x currently [09:38] W: Target Sources (restricted/source/Sources) is configured multiple times in /etc/apt/sources.list:6 and /etc/apt/sources.list.d/proposed.list:2 [09:38] and other warnings [09:40] juliank: yes, I just saw, I'm looking at that now [09:50] ah, bad container, fixed now [09:50] next britney run will re-trigger all the bad ones (http://autopkgtest.ubuntu.com/status/alerts/) [09:55] pitti: yes, it is a real problem, not just a test problem, but i don't believe it is much of a problem - i don't think think many people are doing serious julia work on i386, and if you use it interactively the regression is not noticeable [09:56] hi cjwatson, syncpackage ghc? === doko_ is now known as doko === vrruiz_ is now known as rvr === yuning is now known as yuning-afk === _salem is now known as salem_ === salem_ is now known as _salem [11:04] LocutusOfBorg1: not worth the build time right now [11:04] LocutusOfBorg1: will do it sometime when it isn't going to get in people's way [11:04] ack sure [11:06] xnox: btw, amd64 finished yesterday, do the stats look better now? [11:07] pitti, yes they do =) thank you [11:12] xnox: hey! bzoltan_ has a s390x linker issue he doesn't know how to resolve, and it's a regression so he'd ask for removal of the ubuntu-ui-toolkit s390x from archives if there's no quick solution. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-060/+build/8438344 [11:12] Mirv: thanks [11:15] bzoltan_, if you have issues, you can talk about them yourself here, no? =) [11:15] xnox: I am not brave enough :) [11:15] bzoltan_, i don't bite =))))) too hard.... ;-) [11:16] xnox: I am more araid of the smiling hunters :) [11:16] afraid I mean [11:16] warning: libUbuntuGestures.so.5 .... not found [11:17] looking where it should come from. [11:19] Mirv: is it OK if I remove qtenginio-opensource-src? removed from Debian, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802788 [11:19] Debian bug 802788 in ftp.debian.org "RM: qtenginio-opensource-src -- ROM; Deprecated, not used" [Normal,Open] [11:21] cjwatson: yes, that's what I tried to ask at bug #1512737 [11:21] bug 1512737 in qtenginio-opensource-src (Ubuntu) "RM: qtenginio-opensource-src" [Undecided,New] https://launchpad.net/bugs/1512737 [11:21] but it is there.... ln -s libUbuntuGestures.so.5.5.0 libUbuntuGestures.so [11:22] Mirv: ah, thanks - done [11:22] cjwatson: thank you [11:29] Mirv, bzoltan_ it seems like libUbuntuGestures.so* are placed into ./lib/ at the top level of the build dir, yet linker -Llib/ is not specified?! [11:29] xnox: would that fix the issue? [11:30] bzoltan_, it should. this doesn't look like an arch specific issue at all, and just a generic typo/error somewhere in the build system. I want to pop out for lunch, but then i can spin a build of this on s390x (i have access) and check what's going on. [11:32] how it build on other arches is what gets me wondering. unless something else is going on. [11:34] xnox: ok to re-merge mono? [11:34] seems quick enough [11:54] pitti: do you know how long I should expect to wait for dbusmock 0.16.3 to migrate into xenial? [11:55] pete-woods: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-dbusmock [11:55] pete-woods: it's currently blocking on unity-scope-click regression on armhf; I already retried it twice [11:55] dammit [11:55] pete-woods: ah, last retry actually succeeded, so next britney run should get it [11:55] and promote it [11:56] pitti: awesome, thanks! [11:56] pete-woods: it only got autosynced into xenial this morning [11:56] seems reasonable to ignore that failure anyway [11:56] those errors pretty clearly look unrelated [11:59] having a shoddy baseline means you have to repeatedly make that kind of assessment [11:59] would be better to tests to be reliable [12:00] yeah [12:00] they aren't mine [12:00] my tests do not print out 6k lines of errors [12:00] "Failed" :P === cpaelzer is now known as cpaelzer_afk === cpaelzer_afk is now known as cpaelzer [12:19] bzoltan_, Mirv, sil2100 - builds fine https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/8442437 http://paste.ubuntu.com/14026402/ [12:20] i would have expected that any of you could read the original build log failure, that a library was not found and add it to be linked in. [12:22] pete-woods: just landed [12:22] pitti: awesome, thanks! [12:25] can re-enable my functional tests in my silo now :) [12:31] xnox: I have no context regarding that [12:33] sil2100, earlier bzoltan_ & Mirv complained about s390x build failure as seen in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-060/+build/8438344 when in fact it has a trivial fix that anybody should be able to do. [12:33] sil2100, shouldn't build-failures like that be noticed quickly? (especially since it happened like 4 minutes after the upload) [12:40] xnox: well, I'm not involved in that silo and I don't really scan all silos for build failures, that's up to the lander to take care of that ;) [12:54] pitti: hi! I uploaded libseccomp yesterday. it showed a ppc64el lxc regression and an i386 systemd regression. looking at them, I don't think the failures are related to the upload [12:59] xnox: all I know is that bzoltan_ was hitting a similar issue on other archs earlier but the trick they did for that did not help on s390x [13:00] xnox: it's great if there's a solution that works on s390x too [13:01] Mirv, i wonder what they have done on other arches.... the error is that library foo is required for a test, but has not been linked the same way all other libraries were linked. see the one-line diff i pasted. [13:47] mdeslaur, hey, is https://bugs.launchpad.net/ubuntu/+source/libjpeg-turbo/+bug/1518035 on your merges list? [13:47] Launchpad bug 1518035 in libjpeg9 (Ubuntu) "package libjpeg-progs 1:9a-2ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/djpeg.1.gz', which is also in package libjpeg-turbo-progs 1.3.0-0ubuntu2" [High,Confirmed] [13:47] seb128: it's not, no [13:47] :-( [13:47] mdeslaur, it has your name on https://merges.ubuntu.com/main.html ... ;-) [13:48] seb128: see "please take" comment on the right [13:48] oh, right [13:48] :-( [13:48] seb128: someone needs to investigate why we've diverged from debian, and then do a whole transition for it [13:48] I guess we should at least backport the Conflicts for that files conflicts [13:48] even if we don't update nor merge [13:52] pitti, halo =) koonnen sie bitte autopkgtest im English benutzen? =) [13:52] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/j/juju-core/20151215_104022@/log.gz [13:52] pitti, ich liebe alle "Lese Datenbank" =) [13:53] xnox: bah -- that must be ssh again, forwarding my host's locale to the remote [13:53] what a silly anti-feature [13:54] xnox: I guess that locale further made it into the container [13:54] haha [13:54] we should keep it that way [13:54] pitti, das ist normal. Aber, Ich kann nich verstehen was is loss mit http://autopkgtest.ubuntu.com/packages/j/juju-core/xenial/s390x/ =( [13:55] pitti, koonen sie bitte dass noch ein mal gefahren? [13:55] xnox: ah, missing universr [13:55] xnox: yes, I'll rety; I think I fixed that this morning [13:55] * xnox wonders if pitti, doko, mvo, dholbach find my german funny at all =) [13:55] xnox: it is indeed! :-) [13:56] xnox: it's really good enough to comprehend, but funny all the same [13:57] ich verstehe alles! [13:57] xnox: haha, great :) [14:08] pitti: it appears here http://autopkgtest.ubuntu.com/packages/j/julia/xenial/i386/ that julia 0.4.2-3 built on i386, but that was actually 0.3.12-2ubuntu1. Am i just reading that wrong? [14:08] didrocks, no comment on this bug https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1521984 -> so it's perfect right?! =) [14:08] Launchpad bug 1521984 in s390-tools (Ubuntu) "[MIR] s390-tools" [Undecided,Confirmed] [14:11] Get:27 http://ftpmaster.internal/ubuntu xenial-proposed/universe i386 julia i386 0.4.2-3 [3,767 kB] [14:12] ginggs: ^ what do you mean? seems the version was correct [14:12] xnox: I think doko told he had time to do some MIR [14:12] xnox: but don't worry, you have enough to do to fix the others first :p [14:12] s/to do// [14:12] didrocks, true that [14:13] jdstrand: hey! Looking [14:13] jdstrand: the three nspawn tests failed on i386, which do use seccomp, and there's an error message: Failed to add audit seccomp rule: Bad address [14:13] jdstrand: so it's by far not obvious that this is unrelated [14:14] jdstrand: (it rather looks quite relevant) [14:14] jdstrand: lxc has failed on ppc64el for a while, so we can ignore that indeed [14:15] jdstrand: I'll run it locally and investigate [14:16] jdstrand: ah, indeed it has started failing 4 days ago already, so it's not that; I'll wave it through then [14:23] pitti, so are we building lxd images for s390x? and what needs doing to achieve that? or shall i talk to stgraber about it? are they built in launchpad? [14:29] xnox: no, stgraber having access to an s390x machine, stgraber, no [14:30] xnox: for bug 1524618 I created an LXC container with the "ubuntu" template (i. e. debootstrap), created the metadata manually, and imported the image into lxd [14:30] bug 1524618 in lxd (Ubuntu) "please add support for s390x" [Wishlist,Fix released] https://launchpad.net/bugs/1524618 [14:30] xnox: that works fine, it's just a bit elaborate to do, particularly as you'd need to do it every day [14:30] (can certainly be automated, though) [14:31] xnox: lxd can use two ready-made types of images -- the ones on http://images.linuxcontainers.org (built on stgraber's linuxcontainers.org infra) and our regular cloud images [14:31] xnox: but neither are available for s390x so far [14:31] pitti, we have dev machines ready... which i can do stuff on. e.g. build images and publish them. [14:32] * xnox kind of likes lxd too. [14:32] xnox: yeah, me too; it so rocks on btrfs [14:32] and image handling, transparent caching etc. make it really simple to use [14:32] pitti, and zfs will make it soooo much better =) [14:33] xnox: lxc does seem to support zfs indeed [14:34] I haven't tried that yet, though; I think the jump from ext4 to btrfs is quite a bit more interesting than btrfs → zfs, from my POV [14:39] pitti: thanks! yes, it wasn't obvious to me either for the i386 one. there were other errors around the seccomp bad address one, so I wasn't sure if it was cascading failures, etc. thanks for the archaeology and accepting it :) [14:40] jdstrand: so the i386 seccomp regression is in xenial already, I reproduced it without -proposed [14:40] * jdstrand nods [14:40] jdstrand: I'm now downgrading stuff step by step to see what broke it [14:40] cool [14:40] i. e. it's a real regression, not just a test issue [14:52] pitti: i see Get:26 http://ftpmaster.internal/ubuntu xenial/universe i386 julia i386 0.3.12-2ubuntu1 [2,935 kB] - this is where it says version 0.4.2-3, triggers mpfr4 3.1.302 [14:52] ginggs: ah right, for other triggers it'll run against the xenial-release version, as 0.4 isn't in -release yet [14:53] ginggs: the bug there is that it runs the tests from the 0.4.2 *source* package (from -proposed) against the 0.3 binary packages in -release [14:53] ginggs: that's known, and this needs working around in apt as apt pinning doesn't apply to source packages [14:54] pitti: ok, thanks [15:00] !regression-alert [15:00] bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive [15:00] bug 1526271 - the recent SRU to 14.04 for haproxy introduced a regression where the return code from the init script is now always 0 [15:01] bug 1526271 in haproxy (Ubuntu Trusty) "Could not patch cib; leading to no haproxy running" [Critical,Confirmed] https://launchpad.net/bugs/1526271 [15:01] not great when other tools rely on return codes being lsb compliant :( [15:01] working a fix now [15:01] thats and interesting list of people... [15:05] jamespage: so a quick followup SRU should be fine for that, right? it's been out in the wild for 6 days already, and fixable with another update, so I don't think that warrants pulling the update from teh servers [15:05] pitti, agreed - its pretty much a one line change to resolve [15:05] bdmurray: ^ maybe you can reset its propgagation percentage to 0%? [15:06] jamespage: ack, so let's get that in ASAP and release tomorrow after testing? [15:06] i. e. 0.5 or 1 day instead of 7 [15:06] pitti, ack [15:10] pitti, fix uploaded to trusty-proposed - bug updated with reproduction details. [15:10] only impacts trusty - all other releases got a better version of the fix.... [15:12] caribou, hey - just so you are aware ^^ ;-) [15:13] jamespage: thanks! [15:24] cjwatson, hey, britney is saying (cached yaml here: http://paste.ubuntu.com/14028195/) that arm64 has old binaries, but it does not have any up to date binaries so it should be saying that... confused ? [15:27] apw: which source? [15:27] cjwatson, sorry, linux itself [15:28] cjwatson, which would have been at -4.13 at the time, and failed utterly to produce anything on arm64: https://launchpad.net/ubuntu/+source/linux/4.3.0-4.13/+build/8427529 [15:29] apw, hence my earlier comment about linux[-meta] on #ubuntu-kernel. it is rather confusing. i believe there was an intermittend build that was hence superseeded, but never migrated to -release pocket that is still visible. or some such. [15:31] apw, linux-meta is 4.3.0.2.5 in release, and 4.3.0.5.6 in proposed, yet there was a successful build 4.3.0.2.4 of arm64 in -proposed.... which didn't get removed. huh, should it not have had migrated to release and be removed (?!) [15:31] something is really odd. [15:32] apw, i think we simply need to ask AAs to purge stale arm64 things from -proposed. [15:32] apw: that seems normal if there was a previous unmigrated thing in -proposed [15:33] cjwatson, but for it to complain about cruft it should think there are builds for arm64 in there at the source package version it is expecting "uptodatebins = True" as it were [15:34] cjwatson: there are several openstack packages in universe that I work on frequently but I can't upload. any chance they could be seeded somehow so that I can upload them with my ubuntu server per-package upload rights? [15:34] coreycb: not up to me [15:35] xnox, yes, we have NBS in there, i am happy it is complaining about that indeed, but i am not expecting it to tell me about NBS it finds if there are no uptodate binaries, that overrides the cruft complaint [15:35] apw: err possibly? that code is deeply twisty [15:35] coreycb, please email to developer membership board to grant upload rights and/or update seeds. [15:35] yeah, its like the epochroful maze and no mistake [15:35] coreycb, do you know where to send such request? [15:35] apw: some time since I stared at it in any depth [15:35] xnox, ok yeah I can figure that out [15:36] apw: the NBS of linux-source-4.2.0 that hasn't yet been removed due to build-dep from user-mode-linux may not be helping [15:36] coreycb, https://wiki.ubuntu.com/DeveloperMembershipBoard devel-permissions@lists.ubuntu.com list will used. Check out archives for previous requests about it. [15:36] apw: indeed that may be the main problem here [15:36] coreycb, or if you are ready, apply to become a MOTU =) [15:36] cjwatson, yeah, prolly not worth thinking too hard on. it probabally needs debugging one time it is in that state, but i just uploaded over it :) [15:36] xnox, thanks [15:36] xnox, that's an option :) [15:36] cjwatson, ahh thanks [15:37] * apw puts that on the list of things which are broke [15:39] apw: argh, that's what we get with ignoring REGN.. bug 1526358 :( [15:39] bug 1526358 in systemd (Ubuntu) "xenial/i386 regression: nspawn fails with "Failed to add audit seccomp rule: Bad address"" [High,Triaged] https://launchpad.net/bugs/1526358 [15:39] apw: i. e. on i386, 4.3 broke something in linux-libc-dev wrt. seccomp [15:40] apw: not sure if that affects lxc as well, but at least lxd is using seccomp too [15:41] jdstrand: ^ FYI, I bisected the change, it was the new linux-libc-dev (see bug) [15:41] jdstrand: so if you hear about seccomp trouble on i386, it's likely that [15:41] pitti: yeah, just finished reading the bug. nice triage work [15:41] apw: also, fyi, seccomp is used on snappy, but i386 aren't official [15:42] there's now an < 1 s reproducer, but unfortunately it involves building systemd === cpaelzer is now known as cpaelzer_afk [15:42] pitti, though to be fair we started ignoring it because it was a networkd thing, which we thought was fixed [15:42]