=== JanC_ is now known as JanC === salem_ is now known as _salem [06:17] good morning === dholbach_ is now known as dholbach [08:29] Mirv: hi! Do you understand what is the problem here? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-ci-train-ppa-service-landing-067/yakkety/amd64/u/unity8/20160803_115255@/log.gz [09:01] sil2100: or do you? ^ [09:09] Hi,In ubuntu14.04,which daemon or modules is used to apply the ima(integrity measurement architecture)? [09:09] mardy: you'll need to either ask QA to be ok with yakkety failures (assuming xenial/vivid green) or archive admins to rerun yakkety tests with --all-proposed. this should be unneeded possibly later today if/when we get unity8 landing greenlighted, get unity8 autopkgtests to pass and get 200+ source packages to migrate to release pocket [09:10] (and if there is still any problem with the landing, I'll beg release team again to let u8 pass so that the big migration can stop annoying people) [09:11] Mirv: I'm not in a hurry; can you please ping me later, if/when it's time to retry? [09:11] mardy: I fear it'll be very late today, if it happens today. [09:11] QA has not yet started revalidating the rebuilt silo [09:11] Mirv: ok, nw, I'll check tomorrow morning then [09:12] and autopkgtest + migration infra will take hours [09:12] ok [09:41] hi guys === Guest58264 is now known as zokko [09:41] why CONFIG_UEVENT_HELPER=y [09:41] is not enabled in 4.7/ [09:47] zokko: there is no 4.7 in ubuntu [09:47] it enabled in 4.4 which we have [09:49] jtaylor: i'm talking about http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7/ [09:49] it's almost ready, but im interested why ueventhelper is disabled? [09:50] ask in #ubuntu-kernel my guess is mainline uses a different configuration than ubuntu [09:50] in 4.2 it's enabled by default: root@s42260:~# grep UEVENT /boot/config-4.2.0-42-generic [09:50] CONFIG_UEVENT_HELPER=y [10:14] can anybody please retry curl/systemd autopkgtestsuite? [10:14] or better, ignore the test since it seems to be an unrelated issue [10:22] LocutusOfBorg: I can retry it [10:23] and I did [10:27] oh dear, Laney did as well, now it runs twice... [10:27] * juliank is waiting for the apport tests to finally start running on i386 or amd64 [10:29] oh yeah [10:29] I forgot to say [10:29] DISASTER! [10:30] juliank: ah nice, you're fixing apport? [10:30] Laney: Yeah, I want to get the apt upload migrating now before I sync the new upstream release [10:31] Laney: It's only test suite bugs [10:32] The apport test suite is complicated too look at with each test case being run individually [10:32] mmm [10:32] I wonder if it could use python-apt's test_all.py script, that imports all test classes and then runs them. Which means you only have one summary at the end of all tests [10:32] and all errors at the end [10:35] apport/amd64 looks suspicious [10:35] ah no [10:35] it is moving [10:36] Laney: It had some quota issues in the first try and now tries again [10:36] but the test is failing since a lot of time (new systemd seems to have broken it) [10:36] maybe just ignore? [10:36] no [10:36] it's being fixed, see above [10:36] oh you are talking about that, thanks [10:38] unless you mean the curl one === willcooke_ is now known as willcooke [10:38] yes, I mean the curl one [10:38] http://autopkgtest.ubuntu.com/packages/s/systemd/yakkety/ppc64el/ [10:38] seems that the test broke a while ago [10:39] meh, pitti force-skiptested it [10:39] I have wild guessed it too, because systemd migrated already [10:40] isn't force-skiptest something persistent? [10:40] not if it gets removed [10:40] but why, the test is not fixed [10:40] :( [10:41] seems like a mistake [10:41] do you want to file a bug? [10:41] against systemd? [10:41] yeah [10:42] "please fix testsuite" or "please skiptest"? [10:42] erm [10:42] I would usually start by assuming the testsuite is finding a real bug [10:43] "please investigate ppc64el test failure" [10:43] :) [10:43] sure [10:44] but for now can we skip once more and see curl migrate? [10:45] I would like to have the CVE fixes in [10:45] curl is in [10:46] <3 [10:47] If we're lucky, we'll get socks5 proxy support in APT soon, and built-in tor support [10:47] https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1609740 [10:47] Launchpad bug 1609740 in systemd (Ubuntu) "please investigate ppc64el networkd-test.py failure" [High,New] [10:52] LocutusOfBorg: merci === marcustomlinson is now known as marcustomlinson| === marcustomlinson| is now known as marcustomlinson [11:00] apport:i386 passed test! [11:00] Soon it should pick up amd64 results and migrate [11:01] aieeeeeeee [11:14] merci a toi [11:14] Laney, I was going to assign pitti, but I don't see him here, maybe he is on VAC [11:14] I'm happy you did it :) [11:21] email works [11:21] hopefully [11:23] in what group does a user have to be in order for the LTS-upgrade notification to show up and actually allow to update the system? [11:25] the notification just wreaked havoc in a mid-large ubuntu workstation cluster used by users that should never be able to trigger system-updates [11:30] LocutusOfBorg, he's on VAC since yesterday yes [11:31] LocutusOfBorg, you better don't block/count on it and find somebody else [11:31] It's not blocking anything [11:31] I actually don't have a real issue [11:31] exactly [11:32] k, no need to write emails either then ;-) [11:33] Launchpad wrote the email [11:33] but yeah, I was just pointing out he's out [11:33] no need to be picky on the words I used [11:33] just saying, nothing to worry about [11:33] k, well I was not going to worry, I don't even know what you are talking about [11:33] he asked if pitti was maybe on VAC [11:33] I replied to that [11:34] end of the story [11:37] Laney: It migrated. APT to follow soon, hopefully [11:38] juliank: Good work! [11:39] now I can retry the gtk one [11:39] Laney: Might want to wait a bit until apport binaries have been published [11:40] yes [11:41] This was amazing: 4 APT uploads, 1 python-apt, and 2 apport [11:42] I actually have a apt 1.3~pre2ubuntu5 built too, but I'm going to skip this, as I uploaded a new upstream release containing the stuff which I'll sync then [11:42] using your new powers for good? [11:43] + env["APT_KEY_DONT_WARN_ON_DANGEROUS_USAGE"] = "1" [11:43] lalala [11:43] Laney: Yeah, there will be a proper deprecation python warning soon [11:43] or something harsher [12:22] Laney: I'm giving up for now. I wanted to retry the apport for apt tests now that apport -0ubuntu4 is published, but it still tests against 2.20.3-0ubuntu2 ... [12:23] juliank: Still not published out [12:23] juliank: I'm watching rmadison [12:23] * juliank only sees launchpad seeing published since 24 mins [12:23] But right, rmadison says it's still in -proposed [12:24] I think Launchpad marks everything at the start of the publisher, but it's not really available to consumers until later on [12:24] and if rmadison shows then it's definitely available on ftpmaster [12:25] So annoying... [12:26] Send a shipment of hamsters to Launchpad HQ [12:27] Laney: Looking at apt-rpm and thinking about merging that into apt is more annoying, though! === _salem is now known as salem_ [12:28] you're crazy [12:28] The initial version being based on 0.5.5 and the latest on 0.5.15 [12:44] bleh [12:44] juliank: If you see it happen before me, please hit the apport test on gtk too [12:44] * Laney goes to lunch [12:45] Aye, aye! [12:48] doko, why not syncing boost-defaults in ubuntu? [12:49] xnox, ^^ [12:49] LocutusOfBorg, because doko didn't know better =) [12:49] will fix with my upload [12:50] <3 [12:50] later, there are fixes to be made. [12:50] I see some changes in the debdiff [12:50] a package disappeared [12:51] and create-boost-defaults-control.py shouldn't point to BoostVersion('1.61.0')? [12:57] Laney: hitting it now [12:58] This might take some time .... === salem_ is now known as _salem === _salem is now known as salem_ [13:13] xnox, FYI, I pinged the maintainers for cufflinks zegrapher deal.ii, they are the only three packages depending on boost1.60 in Debian, I think you might want to remove it, right? [13:18] LocutusOfBorg, sure, but there is a lot of work to do still to e.g. remove boost1.58 [13:18] it will sort itself out [13:22] xnox, it is easier to remove 1.60 than 1.58 [13:22] at least in Debian [13:23] for 1.58 we need the transition to finish [13:50] Laney: All tests seem to have run now, let's wait and see what the next excuses update says [13:52] rbasak: It would be nice if someone would investigate the postfix test regressions in Ubuntu. I suspect it's more likely issues with the tests than the package, but in either case, I'd be glad to incorporate any needed changes in Debian (the tests have never worked on Debian infrastructure for reasons I haven't figured out, so it's not a 'regression' there). [14:39] Mmh, I tried SRUing apt/xenial via "syncpackage -V 1.2.14 -r xenial-updates apt" but have not received anything from LP yet. Is -r xenial-updates wrong? [14:39] It definitely shows the real target version number [14:39] juliank: xenial-proposed [14:40] but yes, it did work: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= [14:40] You don't get mail for syncs that go to queues, unfortunately [14:42] Laney: OK. I also tried -proposed, but it showed "current version 1.2.10ubuntu1", not "current version 1.2.12~ubuntu16.04.1" as -updates did. In the end, all probably get remapped anyway, but this seemed safer... === dholbach_ is now known as dholbach [14:42] Laney: But it's listed in a different pocket than the others :/ [14:42] weird stuff [14:42] juliank: Yes, it's going to be rejected - I guess the tool doesn't look at -updates first for syncs to -proposed [14:43] syncing for SRUs is pretty unusual [14:43] you should re-sync to proposed [14:43] Laney: Doing so [14:44] Laney: That's the last sync from Debian. I can do future SRUs via PPA sync as infinity wanted or via direct uploads. [14:44] 04/08 15:44:14 -queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.12~ubuntu16.04.1 => 1.2.14] (core) (sync) [14:44] queuebot is smarter than syncpackage [14:47] ScottK: I wasn't aware. I'll make a note for us to take a look, thanks. [14:47] Thanks. [14:48] We're sprinting next week, so I'm not sure if we'll get to it before we're back though. [14:48] I'll certainly bring it up. [14:48] OK. [14:49] rharper: sorry (you didn't call me out and I forgot about this until this morning) - yeah, yakkety has to come first for the qemu sru [14:49] Laney: The advantage of the PPA being that I can test the stuff more properly before actually uploading it to the archive [14:49] rharper: and where is the fix? [14:49] hallyn: heh, I'm trying to extract just the ddw patches from your deb in the ubuntu-virt ppa [14:50] oh, right. [14:50] the ddw package had a bump to 2.6 + cherry pick [14:50] juliank: and run the autopkgtests against it, in theory [14:50] Laney: yep [14:50] things have moved; I'm somewhat nervous about bumping qemu from 2.5 to 2.6 in xenial just for DDW [14:50] rharper: what do you mean by "thinkgs have moved" ? [14:50] s/k// [14:51] hallyn, rharper: FYI, I uploaded a minor qemu SRU to the Xenial queue earlier. [14:51] (for nacc) [14:51] yeah saw the email [14:51] just the base version of the packages , your patch against 2.5-1ubuntu12 (which isn't in xenial at all), it has a 2.5-1ubuntu10.2 [14:51] rharper's is a much bigger deal so i think we wait for yours to clear rather than combine them :) [14:51] ok, i thought you meant the code has changed a lot. i've not really compared. [14:52] no [14:52] just some rebasing of the patches is needed [14:52] if you have a pointer to the upstream patchset you cherry picked, then I can just go grab that and look to do the rebase [14:52] ok. it's worth thinking about which we think might be more stable long term, if either [14:52] i don't want in 4 months to be asked to upgrade xenial to 2.7 bc of some other feature, that's setting a bad precedent [14:53] I need to poke the openstack folks, maybe coreycb or jamespage would know if cloud-archive is going to pull in 2.6 or 2.7 [14:53] hallyn: exactly [14:53] if yakkety is going to get 2.7 [14:53] bah, that's irrelevant :) [14:53] then instead of bumping to 2.6 + ddw now [14:53] yakkety is a flash in the pan [14:53] hallyn: my point was around testing [14:53] gotcha [14:53] I'd rather have the same versions under test [14:54] there have been a few qmeu-img regressions reported, i can't recall offhand - were those against xenial or yakkety? [14:54] rharper, no plans to rev qemu or libvirt in newton UCA unless I have to [14:54] i.e. it will be the shipped Xenial release versions by default [14:54] ok [14:54] so 2.5 for now [14:54] hrm =( [14:55] only this DDW asking for newer bits; I suspect getting just the DDW fixes for ppc64 won't easily backport to 2.5; hallyn did you look at that or just move up to make the patches import easily / [14:55] the latter [14:56] y [14:56] so how badly does someone want these patches in x, and why [14:56] sad builders? [14:56] gpu pass-through on power is unusable [14:57] performance-wise [14:57] they attempted for FFE for X, but the upstream patches weren't ready [14:57] didn't land till may IIRC [15:01] are the ppl requestiong the feature the ones who did the upstream patch? [15:01] yeah, IBM [15:02] they haven't provided patches against 2.5 for us right? seems like a reasonable request for us to make [15:02] yeah [15:02] heh, well, we can ask [15:03] all right so if you want to build+test i'll back yo uup on that, but in my opinion you should simply say "if you want it in x give us a simple, backported patchset for 2.5 as it is in x" [15:03] (whether or not you can do that will of course depend on the pressure they're causing for you :) [15:04] gotta skeedaddle - ttyl [15:04] I'll through in the request for patches for now; given that we don't have anything else yet pushing for 2.6 or 2.7 into X; I'd rather not bump base version in X without good reason (and testing) [15:04] hallyn: thanks! [15:37] doko, hey, is there any toolchain or such package that got bigger in yakkety? trying to figure out why the iso is 1.7G now when it was 1.5G in xenial [15:39] seb128, cc1/lto1 are not yet stripped in y [15:39] doko, would that account for that much difference? [16:57] doko: for bug 1609215, I gave you the output of bzr diff but there were file renames which appear to not be applied with patch -p0 [16:57] bug 1609215 in grilo-plugins (Ubuntu) "Merge grilo-plugins 0.3.2-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1609215 [16:58] jbicha, hmm, usually these should be part of a debdiff? [17:05] doko: I don't know, I just pushed a packaging-only branch to https://code.launchpad.net/~jbicha/grilo/update-to-grilo-0.3/ if you want to try that instead [17:07] maybe patch doesn't recognize bzr mv so I would have been better off just removing the old file and adding the new one [17:31] cyphermox: is bug 1604499 verified or just not v-failed? [17:31] bug 1604499 in grub2-signed (Ubuntu Xenial) "include loopback and squash4 modules in EFI binary" [Undecided,Fix committed] https://launchpad.net/bugs/1604499 [17:55] hallyn: well, yuck; the ddw device is a property only on machinc type 2.6 for ppc [18:00] jbicha, could you have a look at the freerdp ftbfs? [18:07] bdmurray: fully verified. [18:08] cyphermox: could you add a comment about the verification? [18:13] I thought I did [18:13] ah oops [18:16] bdmurray: done [19:05] hallyn: so, the ubuntu-machine types patch we carry only -$release values for the x86 pc-i440fx machine type; if we bring back ddw device into 2.5, then we'd need a pseries-2.5-16.04 (alias to pseries-2.5) and pseries-2.5.16.04.1 (with ddw) [20:03] rharper: pseries-specific, [20:03] heh [20:03] it's not yet a problem due to the number of users doing live migration on ppc64 [20:10] ugh "One of the main differences is that all access to your secret key will be handled through gpg-agent, which should be automatically launched as needed. [20:20] hallyn: the libvirt secrets stuff ? or something else [20:21] the new gpg which is becoming the default in debian [20:22] (the gpg agent sucks a bit of battery ,and i'm a miser) [20:22] I see [20:45] nacc: Your qemu upload for LP: #1490611 seems to have been superseded by a security update [20:45] Launchpad bug 1490611 in qemu (Ubuntu Xenial) "Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to the result file, which Microsoft Azure rejects as invalid" [Medium,In progress] https://launchpad.net/bugs/1490611 [21:06] bdmurray: ah ok, i'll review [21:16] Ah, just seen this. I commented on the bug thinking that you won't have seen the queue reject email. [21:18] rbasak: yep, i won't have :) [21:19] rbasak: bdmurray: updated debdiff just attached [21:32] xnox, you around? [21:32] xnox, if so: https://launchpad.net/ubuntu/+source/gtest [21:33] xnox, sorry: https://bugs.launchpad.net/ubuntu/+source/gtest/+bug/1609989 [21:33] Launchpad bug 1609989 in gtest (Ubuntu) "Undefined behavior "member call on null pointer of type 'const struct ResultHolder'"" [Critical,New] [21:33] xnox, with gcc-6 in y, using gtest/gmock segfaults when mocking functions returning void [21:34] xnox, would you be able to take a look at the proposed solutions? [21:34] doko, ^ [22:25] xnox: you ping-timed-out moments after tvoss asked if you could look at https://bugs.launchpad.net/ubuntu/+source/gtest/+bug/1609989 [22:25] Launchpad bug 1609989 in gtest (Ubuntu) "Undefined behavior "member call on null pointer of type 'const struct ResultHolder'"" [Critical,New] [23:09] man there sure are a lot of these "triggers looping" bug reports :( https://bugs.launchpad.net/ubuntu/+source/ca-certificates [23:14] Everything is just so loopy. :( [23:17] yes :(