[00:06] win 19 [00:31] infinity: Pokepoke! Seen these https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167 ? (And of course all the ones linked in there.) [04:58] Good morning === davidcalle_ is now known as davidcalle === Guest8229 is now known as Tm_Tr [08:30] pitti: update_excuses says ubiquity armhf test is in progress for >12 hours while in fact it finished quite a while ago :/ [08:30] sitter: will look in a minute [08:32] sitter: they actually didn't -- there is no result for 2.21.29 on http://autopkgtest.ubuntu.com/packages/u/ubiquity/wily/armhf/ [08:32] oops, the pre-last one [08:32] sitter: incidentally, this is a transient bug which I'm currently working on [08:33] ah [08:34] pitti: ok thanks :) [08:36] I have a dump in /var/crash created when Caja encountered a segfault. [08:36] approt-gtk simply didn't upload anything when it detected the crash. [08:37] I've create a bug report and would like to submit the crash report, manually invoking apport-gtk had the same issue. It just silenty closed when I tried to submit the report. [08:37] Can anyone help me get the crash report submitted? [09:08] flexiondotorg: sounds like it reported it to errors.u.c. only? [09:09] did we leave LP reporting off this cycle? [09:09] oops, it seems we never actually enabled it [09:09] Ah! [09:09] ha [09:09] :-) [09:09] add that to NRCP or so? [09:10] So, does that mean there might be an entry in errros.ubuntu.com? [09:10] Laney: we don't actually want to enable it that early, usually around alpha-2 [09:10] flexiondotorg: there should, yes [09:10] I'll finish something else first, and then do a new apport upload [09:10] * flexiondotorg goes searching. [09:10] pitti: I don't have the impression that early release is that wild-westy any more [09:11] true that [09:11] but if you can think of a good process checkpoint later on [09:13] Can I just understand why it was disabled? [09:13] we don't want users of stable releases report to LP, just to errors.u.c. [09:14] so we disable that right before release, and re-enable it at some (not well-defined) appropriate point in time after opening the new devel series [09:14] pitti, OK. [09:25] apw: hm, and now linux regressed again -- were the two successful runs just good luck, or did 9.9 actually break something again? [09:26] oh, curiously they pass the regression suite, but fail "rebuild", wut? [09:26] pitti, bah ... hate [09:26] dpkg-checkbuilddeps: Unmet build dependencies: makedumpfile libelf-dev libnewt-dev libiberty-dev libdw-dev libpci-dev pkg-config flex bison libunwind8-dev libaudit-dev bc python-dev libudev-dev autoconf automake libtool xmlto docbook-utils ghostscript transfig sharutils asciidoc [09:26] pitti, erm ... how is that possible even ... wtf ? [09:27] apw: did that lose the Depends: @builddeps@ or so? [09:27] Tests: rebuild [09:27] Depends: @builddeps@, fakeroot [09:27] Restrictions: allow-stderr [09:27] looks ok ... [09:28] pitti, OH do you use a profile ? [09:28] no, I don't think so [09:29] apw: no, I don't [09:29] do you parse debian/control directly, could you be being confused by the new use of profiles [09:29] apw: I use libdpkg-perl, but I fixed autopkgtest to get along with profiles a fair while ago [09:29] apw: ah, but trusty's libdpkg-perl might not [09:30] apw: so all these missing ones have a build profile now? how do they look? (to spare me apt-get source linux) [09:30] or something? [09:30] http://paste.ubuntu.com/12327328/ [09:31] pitti, i'd say for an instant fix you could just rip them ... as we only use them to pare down deps for bootstrapping [09:31] apw: thanks; let me look into this [09:35] pitti, thanks as always [09:35] test_build_deps_profiles (__main__.ChrootRunner) [09:35] test depends on build dependencies with build profiles ... FAIL [09:35] bingo [09:35] :) [09:35] apw: ^ this is the test suite running on the production box (trusty) [09:35] pitti, makes sense [09:35] apw: I'll see to adding a fallback, like just blatantly ignoring them [09:35] I don't think it's practical to backport a newer dpkg to trusty [09:35] pitti, yeah i recon just rip them on average, clearly they arn't used much else other people would be moaning [09:36] pitti, and i assume if we can't figure it out, we can enumerate @buildeps@ by hand and be happy [09:36] apw: nah, this needs to work [09:36] please don't change the kernel for this, othe rpackages use profiles too now [09:36] and this likely causes some other failure [09:38] pitti, i meant if we were doing something that "just ripping them" doesn't fix ... [09:38] ah [09:38] which we arn't [09:38] pitti, what happened to the results for -8.8 i wonder [09:39] apw: there is no such thing, at least not in ubuntu [09:39] https://launchpad.net/ubuntu/+source/linux/+changelog [09:39] apw: apparently it never got copied? [09:39] wierd ... [09:40] yeah must be ... i wil beat tim to find out what occured later then :) [09:41] pitti, and when you get bored you can try and explain how the one below ever occured, it looks like one binary package from linux-meta is published but not the others, which makes my head hurt: [09:41] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/l/linux/20150909_203426@/log.gz [09:50] flexiondotorg: apport uploaded; if you want, you can apply the simple config change locally: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/wily/apport/ubuntu/revision/2453 [09:51] apw: we got tons of such failures over night [09:51] apw: as linux and linux-signed were stuck in binNEW; I NEWed them, and then retried all temp failures [09:51] pitti, ahh i guess htat if i asked it to install the second one listed, it would blame something deeper ... ok its just confusng me [09:51] apw: this was again the case of linux-meta being updated with its dependencies not being installable [10:02] pitti, yeah, i see that now, the reported error had me confused, but its just being lazy and telling me the top not the real missing package [10:26] pitti, is htere something wrong with ppc64el/armhf testing atm ? i seem to have no results for dkms packages for wily for -9.9 on those [10:32] apw: ok, fixed in http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=69561dae , rolled out, and linux retried on i386/amd64 [10:33] apw: nothing wrong that I'm aware of [10:33] apw: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux-meta is full of bling? [10:33] apw: well, pretty much all the dkms packages fail on armhf/ppc64el for sure [10:34] apw: we can't actually install newer kernels in LXC [10:34] but at least formally they get triggered [10:34] pitti, of course, they are run they just don't mean anything ... doh [10:34] apw: I hear ppc64el scalingstack support is coming RSN, then these will work [10:34] apw: yeah, I don't bother adding some special cases for those -- they fail fast enough === nudtrobert1 is now known as nudtrobert [10:40] pitti, we're going to need that "report kernel" i guess before we get lts backports to work anyhow, but that likely should tell you if it is a host kernel or not [10:41] apw: yep, working on that now [10:49] apw: ok, it's past build dep installation, that worked now [10:49] * pitti now lets it do its three-hour thing [10:49] reat ... [10:49] great [10:50] apw: so for bug 1491865 -- 1) just means you want to see it in the log, right? [10:50] bug 1491865 in autopkgtest (Ubuntu) "report and record the actual booted kernel with test results" [High,In progress] https://launchpad.net/bugs/1491865 [10:51] apw: which is hard for machine parsing, but for humans [10:51] apw: and 2) is to add this to result.tar [10:51] yeah i think when a human reads the log and they see a reboot, each and every reboot should report the kernel as it comes up [10:51] right, that's trivial [10:52] and in a perfect world the computer would check that it was concistent throughout the run (but ...) [10:52] and for 2) I think it would be the kernel version that the test bed has after the initial setup [10:52] well, a test might actually go and install a different kernel [10:52] right after you "update everything and reboot if /boot changed" phase [10:52] right, that's the point I meant [10:52] alrighty [10:53] something to do after lunch [10:53] do we expect that, or do you handle lts-XXX outside, i think you will ? [10:53] pitti, or ... you could make that a list of kernels [10:53] and record after any reboot [10:53] apw: we already have a list of kernels, I thought the point was to know which kernel actually ran? [10:53] not a list of installed kernels, but a list of "each kernel in each reboot" [10:54] so if the test installs and reboots it owuld like say [10:54] [ V1, V2 ] [10:54] apw: not sure yet about lts-XXX -- either it'll become part of what the dkms autopkgtest script does, but that's impractical for some reasons [10:54] apw: I think I'd rather special-case it in the autopkgtest cloud worker, and install that kernel when it is the test trigger [10:54] (as part of setup-commands) [10:54] yep i can see how that makes sense [10:55] anyhow, i thnk i'd say make the kernel thing a list of an entry after each reboot if that is doable [10:55] in the main it will be just one anyhow [10:55] it's less obvious for reproducing locally, but avoids SRUing the dkms-autopkgtset script all over again, and instaslling yet another kernel into the testbeds and another reboot [10:55] heh [10:56] at least if every consumer is keying off the kernel listed in the test results we don't care how it gets made [10:56] apw: a list would only make sense if you expect tests to isntall/reboot into different kernels [10:56] do you want to do that actually? [10:56] pitti, well i don't think i do, but its more about whether something will reboot more than once [10:57] pitti, if it does, then recording what you booted each time catches bugs in the test [10:57] pitti, we can see tht it should be X each time and it went X, Y, Y or whatever [10:57] apw: okay [10:57] its as much about being able to tell a result is right as anything [10:58] for my purposes i will check it is consistant throughout or bin the result [10:58] apw: so this would be a testname → reboot ID → kernel version map [10:58] apw: where "reboot ID" is the string the test passes to /tmp/autopkgtest-reboot [10:58] hm, but most tests don't do that [10:59] what is the first one called, the one you do after /boot [10:59] so perhaps "testname → initial -> kernel version" for those? [10:59] apw: it doesn't have one, as that's not triggerd by the test [10:59] but for the yaml we need to make up something [11:00] so you are saying i'd have for each testname what kernel version it had underneath? and if it reboots it would have initial -> v and ID -> w [11:00] sort of thing [11:00] actually, we don't even need the per-test initial thing, it's always the same [11:00] apw: so perhaps: [11:00] always the same ? [11:00] kernel_version: [11:00] and *if* a test installs a different one, [11:01] test_kernel_versions: testname -> ID -> version [11:01] (and we usually don't expect the latter at all) [11:02] is testname ID there is that like testname: [(id, version), ...] [11:02] apw: "testname" -> name in Tests: in d/t/control [11:03] apw: I mean the reboot ID, as explained above (autopkgtest-reboot ID) [11:03] test_kernel_versions: [11:03] test_with_utopic_lts: [11:03] reboot_new_kernel: # (from claling autopkgtest-reboot reboot_new_kernel) [11:04] 3.14.0-blah [11:04] (imagine some more indentation in the last line) [11:04] i guess it depends if we care to look them up by test name ... [11:04] from Tests: test_with_utopic_lts [11:05] in my mind i was seeing more: (python form) kernel_version: [ ('setup', None, V), (testname1, ID1, V2), ... ] [11:05] apw: well, otherwise you wouldn't really know what/when it happened? [11:05] or even kernel_version: [ (None, None, V), (testname1, ID1, V2) ] [11:05] apw: isn't that mostly the same, except a list insted of a testname -> bootid map? [11:05] well i have ordering information that way [11:06] ah, ok [11:06] though i'd almost wonder if you have test1 test2 test3 in your control [11:06] apw: not sure that None can be represented adequately in yaml [11:07] apw: I was thinking of only adding entries to that complicated structure which actually differ from the default version, as we almost always expect tests to use one and the same [11:07] that it would be " [ ('setup', '', V), (test1, '', V), (test2, '', V), (test2, 'ID', V2), (test3, '', V2) ] [11:07] and put the initial version into a different field, so that it's much easier to parse [11:07] yeah that simlpification is fine indeed [11:08] i am looking to be able to trivaily know for any test what kernel was it run under [11:08] so knowing when the tests run relative to the reboots if any [11:10] (this is something we found valuable when doing testing in a previous life, allowing validation of test results) [11:10] apw: btw, would you terribly mind json insted of yaml? json is built into python, yaml is a separate module; I'd like to avoid new deps if I can [11:10] pitti, i care not at all what the format indeed, use what you find most convienient [11:11] apw: we usually reset the testbed in between tests; should that be reflected in your list? [11:11] as long as python can parse it later [11:11] [ ('setup', '', V), (test1, '', V), ('setup', '', V), (test2, '', V) ...] [11:12] so it is a phase list not a test list, that seems ok [11:12] can we use that somehow to make it an event [11:12] (still not entirely sure what the goal of this is, so you tell me :) ) [11:13] but the above seems both highly redundant to me and not that useful [11:13] in 99% of cases all the Vs are the same [11:13] ultimatly i want to know what tests ran under what kernels and preferably to know the order, but i guess i can tell that from teh control file [11:13] so i can tell if a reboot failed and we got the wrong kernel, like a grub bug picking the wong kernel on reboot [11:13] apw: ah, so no ('setup') at all then? as the initial one would already be in ('test1', '', V) [11:14] apw: i. e. I don't understand the difference between (setup, '') and (test1, '') [11:14] that is essentially (test1, setup, V) yes [11:14] ah, ok [11:15] pitti: for LP we mostly take the approach of just stripping off build profiles, although you have to be quite careful with that because obviously < and > have other meanings too. There's a giant regex in modern libdpkg-perl that can sensibly be appropriated for the purpose. [11:15] so, [ (test1, '', V), (test2, '', V), (test2, 'reboot_id', V2), ...] [11:15] apw: ^ [11:15] pitti, that seems more than enough indeed ... i hope we anr't overdoing it [11:15] cjwatson: ack, thanks [11:15] pitti, and would you have kernel_version: as the "after update" one for the common case ? [11:16] apw: "after test bed setup" would be the first entry with the special reboot ID '' [11:17] ie at the start of the first test, so always the first entry in fact [11:17] right, and it's a list, thus ordered [11:17] apw: with that we only need exactly one kernel_versions: with that list of triples [11:17] well that works for my use case :) [11:18] ironically i will just run the list and make sure V does not change, and use it [11:19] apw: http://paste.ubuntu.com/12327750/ [11:19] apw: (no tuples in json, they become lists, but *shrug*) [11:20] that looks good to my eye, over engineered to hell and back i am sure, but yes [11:21] pitti, is this going to be like a systeminfo file with other things later ? [11:21] apw: so that's one option; the other is http://paste.ubuntu.com/12327760/ [11:21] apw: yeah, hence the top-level dict [11:21] apw: I don't want to add yet another file in the future for similar system state info [11:22] apw: and in fact I'd like to merge testbed-packages into this one [11:22] pitti, the second one is simpler for the normal case, and provides the same info as long we include any test which runs != 1.2 in the bottom [11:23] apw: a file like this sounds interesting if/once we run tests on real iron [11:23] ie if there was test3 which didn't reboot after test2 [11:23] apw: it's a reduced list, so if there is a test3 which doesn't reboot, it'd just use teh default kernel [11:24] pitti, but we rebooted in test2 and are on that kernel now no ? [11:24] well, I suppose you can construct a package test which runs test3 without reinitializing the testbed [11:24] apw: but it would appear in the list then [11:24] apw: i. e. the idea was to not show anything in the list which has (_, _, default_kernel_version) [11:25] apw: so that your check reduces to "this list must be empty" [11:25] right, if thats what it is doing, that works too [11:25] apw: but I don't care much either way, pick your poison :) [11:25] well the second is much shorter in the common case where theer is no reboot [11:25] so ... making it harder for those who care is fine with me :) [11:26] pitti, so i think i am voting for kernel_version + test_kernel_versions form [11:28] apw: ack; I sent a summary to the bug [11:28] and now, lunch for realz [11:28] perhaps kernel_version_changes: to get them to sit by each other in the json [11:29] as it is a delta list effectivly [11:29] noted in the bug, good call [11:29] pitti, you should record the trigger in there too [11:30] just becasue, and name the file such that it can :) [11:35] apw: *nod* === MacSlow is now known as MacSlow|lunch === MacSlow|lunch is now known as MacSlow [14:42] at what point did we switch to predictable interface names? Is that a recent thing? (First proposal email I can find is May 2015...) [14:45] heh ... i still cant stop laughing about that naming :) [14:46] teward, i think in wily at some point [14:46] ogra_: what about retroactive changes? Trusty (all variants) still on the older system? [14:46] pitti might have the exact date [14:47] yeah, trusty still uses properly guessable names [14:47] teward: https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038786.html [14:47] on June 17 [14:47] such an insane move [14:47] pitti: and that was never implemented retroactively, or for the latest trusty point releases? [14:48] teward: heck, no -- that's a rather intrusive change, it's really not backportable [14:48] haha, yeah [14:48] pitti: tell that to dschatz_ in -server [14:48] well, "able" yes, but we so much won't [14:50] right, i knew it was being enabled in Wily, heck I even discovered the server installer iso bug where it was still using the older system and not the one it should be (the 'installer installs eth# which means networking doesn't load after reboot' problem) [14:50] which was fixed same-day xD [14:51] well, but that shows pretty good why backporting would be insane :) [14:51] and i'm fairly familiar with "Yeah not backporting sorry" things, from all the 'security' changes from the SSL vulns and such that prompted default-config changes in http server packages and such that didn't get backported to other ubuntu releases, but meh. was fairly certain that was the case. [14:51] ogra_: indeed [14:51] lots of scripts to change etc etc [14:51] mhm [14:51] oop that reminds me. Note to self: update wily VM >.< [15:59] apw: http://autopkgtest.ubuntu.com/packages/l/linux/ \o/ [15:59] pitti, sweet ... thanks for that === mnepton is now known as mneptok