[00:06] <infinity> win 19
[00:31] <Unit193> 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] <pitti> Good morning
[08:30] <sitter> pitti: update_excuses says ubiquity armhf test is in progress for >12 hours while in fact it finished quite a while ago :/
[08:30] <pitti> sitter: will look in a minute
[08:32] <pitti> 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] <pitti> oops, the pre-last one
[08:32] <pitti> sitter: incidentally, this is a transient bug which I'm currently working on
[08:33] <sitter> ah
[08:34] <sitter> pitti: ok thanks :)
[08:36] <flexiondotorg> I have a dump in /var/crash created when Caja encountered a segfault.
[08:36] <flexiondotorg> approt-gtk simply didn't upload anything when it detected the crash.
[08:37] <flexiondotorg> 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] <flexiondotorg> Can anyone help me get the crash report submitted?
[09:08] <pitti> flexiondotorg: sounds like it reported it to errors.u.c. only?
[09:09] <Laney> did we leave LP reporting off this cycle?
[09:09] <pitti> oops, it seems we never actually enabled it
[09:09] <flexiondotorg> Ah!
[09:09] <Laney> ha
[09:09] <flexiondotorg> :-)
[09:09] <Laney> add that to NRCP or so?
[09:10] <flexiondotorg> So, does that mean there might be an entry in errros.ubuntu.com?
[09:10] <pitti> Laney: we don't actually want to enable it that early, usually around alpha-2
[09:10] <pitti> flexiondotorg: there should, yes
[09:10] <pitti> I'll finish something else first, and then do a new apport upload
[09:10]  * flexiondotorg goes searching.
[09:10] <Laney> pitti: I don't have the impression that early release is that wild-westy any more
[09:11] <pitti> true that
[09:11] <Laney> but if you can think of a good process checkpoint later on
[09:13] <flexiondotorg> Can I just understand why it was disabled?
[09:13] <pitti> we don't want users of stable releases report to LP, just to errors.u.c.
[09:14] <pitti> 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] <flexiondotorg> pitti, OK.
[09:25] <pitti> 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] <pitti> oh, curiously they pass the regression suite, but fail "rebuild", wut?
[09:26] <apw> pitti, bah ... hate
[09:26] <pitti> 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] <apw> pitti, erm ... how is that possible even ... wtf ?
[09:27] <pitti> apw: did that lose the Depends: @builddeps@ or so?
[09:27] <apw> Tests: rebuild
[09:27] <apw> Depends: @builddeps@, fakeroot
[09:27] <apw> Restrictions: allow-stderr
[09:27] <apw> looks ok ...
[09:28] <apw> pitti, OH do you use a profile ?
[09:28] <pitti> no, I don't think so
[09:29] <pitti> apw: no, I don't
[09:29] <apw> do you parse debian/control directly, could you be being confused by the new use of profiles
[09:29] <pitti> apw: I use libdpkg-perl, but I fixed autopkgtest to get along with profiles a fair while ago
[09:29] <pitti> apw: ah, but trusty's libdpkg-perl might not
[09:30] <pitti> apw: so all these missing ones have a build profile now? how do they look? (to spare me apt-get source linux)
 or something?
[09:30] <apw> http://paste.ubuntu.com/12327328/
[09:31] <apw> 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] <pitti> apw: thanks; let me look into this
[09:35] <apw> pitti, thanks as always
[09:35] <pitti> test_build_deps_profiles (__main__.ChrootRunner)
[09:35] <pitti> test depends on build dependencies with build profiles ... FAIL
[09:35] <pitti> bingo
[09:35] <apw> :)
[09:35] <pitti> apw: ^ this is the test suite running on the production box (trusty)
[09:35] <apw> pitti, makes sense
[09:35] <pitti> apw: I'll see to adding a fallback, like just blatantly ignoring them
[09:35] <pitti> I don't think it's practical to backport a newer dpkg to trusty
[09:35] <apw> pitti, yeah i recon just rip them on average, clearly they arn't used much else other people would be moaning
[09:36] <apw> pitti, and i assume if we can't figure it out, we can enumerate @buildeps@ by hand and be happy
[09:36] <pitti> apw: nah, this needs to work
[09:36] <pitti> please don't change the kernel for this, othe rpackages use profiles too now
[09:36] <pitti> and this likely causes some other failure
[09:38] <apw> pitti, i meant if we were doing something that "just ripping them" doesn't fix ...
[09:38] <pitti> ah
[09:38] <apw> which we arn't
[09:38] <apw> pitti, what happened to the results for -8.8 i wonder
[09:39] <pitti> apw: there is no such thing, at least not in ubuntu
[09:39] <pitti> https://launchpad.net/ubuntu/+source/linux/+changelog
[09:39] <pitti> apw: apparently it never got copied?
[09:39] <apw> wierd ...
[09:40] <apw> yeah must be ... i wil beat tim to find out what occured later then :)
[09:41] <apw> 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] <apw> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/l/linux/20150909_203426@/log.gz
[09:50] <pitti> 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] <pitti> apw: we got tons of such failures over night
[09:51] <pitti> apw: as linux and linux-signed were stuck in binNEW; I NEWed them, and then retried all temp failures
[09:51] <apw> 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] <pitti> apw: this was again the case of linux-meta being updated with its dependencies not being installable
[10:02] <apw> 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] <apw> 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] <pitti> 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] <pitti> apw: nothing wrong that I'm aware of
[10:33] <pitti> apw: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux-meta is full of bling?
[10:33] <pitti> apw: well, pretty much all the dkms packages fail on armhf/ppc64el for sure
[10:34] <pitti> apw: we can't actually install newer kernels in LXC
[10:34] <pitti> but at least formally they get triggered
[10:34] <apw> pitti, of course, they are run they just don't mean anything ... doh
[10:34] <pitti> apw: I hear ppc64el scalingstack support is coming RSN, then these will work
[10:34] <pitti> apw: yeah, I don't bother adding some special cases for those -- they fail fast enough
[10:40] <apw> 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] <pitti> apw: yep, working on that now
[10:49] <pitti> apw: ok, it's past build dep installation, that worked now
[10:49]  * pitti now lets it do its three-hour thing
[10:49] <apw> reat ...
[10:49] <apw> great
[10:50] <pitti> apw: so for bug 1491865 -- 1) just means you want to see it in the log, right?
[10:51] <pitti> apw: which is hard for machine parsing, but for humans
[10:51] <pitti> apw: and 2) is to add this to result.tar
[10:51] <apw> 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] <pitti> right, that's trivial
[10:52] <apw> and in a perfect world the computer would check that it was concistent throughout the run (but ...)
[10:52] <pitti> and for 2) I think it would be the kernel version that the test bed has after the initial setup
[10:52] <pitti> well, a test might actually go and install a different kernel
[10:52] <apw> right after you "update everything and reboot if /boot changed" phase
[10:52] <pitti> right, that's the point I meant
[10:52] <pitti> alrighty
[10:53] <pitti> something to do after lunch
[10:53] <apw> do we expect that, or do you handle lts-XXX outside, i think you will ?
[10:53] <apw> pitti, or ... you could make that a list of kernels
[10:53] <apw> and record after any reboot
[10:53] <pitti> apw: we already have a list of kernels, I thought the point was to know which kernel actually ran?
[10:53] <apw> not a list of installed kernels, but a list of "each kernel in each reboot"
[10:54] <apw> so if the test installs and reboots it owuld like say
[10:54] <apw> [ V1, V2 ]
[10:54] <pitti> 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] <pitti> 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] <pitti> (as part of setup-commands)
[10:54] <apw> yep i can see how that makes sense
[10:55] <apw> anyhow, i thnk i'd say make the kernel thing a list of an entry after each reboot if that is doable
[10:55] <apw> in the main it will be just one anyhow
[10:55] <pitti> 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] <apw> heh
[10:56] <apw> 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] <pitti> apw: a list would only make sense if you expect tests to isntall/reboot into different kernels
[10:56] <pitti> do you want to do that actually?
[10:56] <apw> pitti, well i don't think i do, but its more about whether something will reboot more than once
[10:57] <apw> pitti, if it does, then recording what you booted each time catches bugs in the test
[10:57] <apw> pitti, we can see tht it should be X each time and it went X, Y, Y or whatever
[10:57] <pitti> apw: okay
[10:57] <apw> its as much about being able to tell a result is right as anything
[10:58] <apw> for my purposes i will check it is consistant throughout or bin the result
[10:58] <pitti> apw: so this would be a testname → reboot ID → kernel version map
[10:58] <pitti> apw: where "reboot ID" is the string the test passes to /tmp/autopkgtest-reboot <ID>
[10:58] <pitti> hm, but most tests don't do that
[10:59] <apw> what is the first one called, the one you do after /boot
[10:59] <pitti> so perhaps "testname → initial -> kernel version" for those?
[10:59] <pitti> apw: it doesn't have one, as that's not triggerd by the test
[10:59] <pitti> but for the yaml we need to make up something
[11:00] <apw> 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] <apw> sort of thing
[11:00] <pitti> actually, we don't even need the per-test initial thing, it's always the same
[11:00] <pitti> apw: so perhaps:
[11:00] <apw> always the same ?
[11:00] <pitti> kernel_version: <initial kernel after test bed init/upgrade>
[11:00] <pitti> and *if* a test installs a different one,
[11:01] <pitti> test_kernel_versions: testname -> ID -> version
[11:01] <pitti> (and we usually don't expect the latter at all)
[11:02] <apw> is testname ID there is that like testname: [(id, version), ...]
[11:02] <pitti> apw: "testname" -> name in Tests: in d/t/control
[11:03] <pitti> apw: I mean the reboot ID, as explained above (autopkgtest-reboot ID)
[11:03] <pitti> test_kernel_versions:
[11:03] <pitti>     test_with_utopic_lts:
[11:03] <pitti>      reboot_new_kernel:   # (from claling autopkgtest-reboot reboot_new_kernel)
[11:04] <pitti>      3.14.0-blah
[11:04] <pitti> (imagine some more indentation in the last line)
[11:04] <apw> i guess it depends if we care to look them up by test name ...
[11:04] <pitti> from Tests: test_with_utopic_lts
[11:05] <apw> in my mind i was seeing more: (python form) kernel_version: [ ('setup', None, V), (testname1, ID1, V2), ... ]
[11:05] <pitti> apw: well, otherwise you wouldn't really know what/when it happened?
[11:05] <apw> or even kernel_version: [ (None, None, V), (testname1, ID1, V2) ]
[11:05] <pitti> apw: isn't that mostly the same, except a list insted of a testname -> bootid map?
[11:05] <apw> well i have ordering information that way
[11:06] <pitti> ah, ok
[11:06] <apw> though i'd almost wonder if you have test1 test2 test3 in your control
[11:06] <pitti> apw: not sure that None can be represented adequately in yaml
[11:07] <pitti> 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] <apw> that it would be " [ ('setup', '', V), (test1, '', V), (test2, '', V), (test2, 'ID', V2), (test3, '', V2) ]
[11:07] <pitti> and put the initial version into a different field, so that it's much easier to parse
[11:07] <apw> yeah that simlpification is fine indeed
[11:08] <apw> i am looking to be able to trivaily know for any test what kernel was it run under
[11:08] <apw> so knowing when the tests run relative to the reboots if any
[11:10] <apw> (this is something we found valuable when doing testing in a previous life, allowing validation of test results)
[11:10] <pitti> 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] <apw> pitti, i care not at all what the format indeed, use what you find most convienient
[11:11] <pitti> apw: we usually reset the testbed in between tests; should that be reflected in your list?
[11:11] <apw> as long as python can parse it later
[11:11] <pitti> [ ('setup', '', V), (test1, '', V),  ('setup', '', V), (test2, '', V) ...]
[11:12] <apw> so it is a phase list not a test list, that seems ok
[11:12] <apw> can we use that somehow to make it an event
[11:12] <pitti> (still not entirely sure what the goal of this is, so you tell me :) )
[11:13] <pitti> but the above seems both highly redundant to me and not that useful
[11:13] <pitti> in 99% of cases all the Vs are the same
[11:13] <apw> 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] <apw> 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] <pitti> apw: ah, so no ('setup') at all then? as the initial one would already be in ('test1', '', V)
[11:14] <pitti> apw: i. e. I don't understand the difference between (setup, '') and (test1, '')
[11:14] <apw> that is essentially (test1, setup, V) yes
[11:14] <pitti> ah, ok
[11:15] <cjwatson> 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] <pitti> so, [ (test1, '', V), (test2, '', V), (test2, 'reboot_id', V2), ...]
[11:15] <pitti> apw: ^
[11:15] <apw> pitti, that seems more than enough indeed ... i hope we anr't overdoing it
[11:15] <pitti> cjwatson: ack, thanks
[11:15] <apw> pitti, and would you have kernel_version: as the "after update" one for the common case ?
[11:16] <pitti> apw: "after test bed setup" would be the first entry with the special reboot ID ''
[11:17] <apw> ie at the start of the first test, so always the first entry in fact
[11:17] <pitti> right, and it's a list, thus ordered
[11:17] <pitti> apw: with that we only need exactly one kernel_versions: with that list of triples
[11:17] <apw> well that works for my use case :)
[11:18] <apw> ironically i will just run the list and make sure V does not change, and use it
[11:19] <pitti> apw: http://paste.ubuntu.com/12327750/
[11:19] <pitti> apw: (no tuples in json, they become lists, but *shrug*)
[11:20] <apw> that looks good to my eye, over engineered to hell and back i am sure, but yes
[11:21] <apw> pitti, is this going to be like a systeminfo file with other things later ?
[11:21] <pitti> apw: so that's one option; the other is http://paste.ubuntu.com/12327760/
[11:21] <pitti> apw: yeah, hence the top-level dict
[11:21] <pitti> apw: I don't want to add yet another file in the future for similar system state info
[11:22] <pitti> apw: and in fact I'd like to merge testbed-packages into this one
[11:22] <apw> 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] <pitti> apw: a file like this sounds interesting if/once we run tests on real iron
[11:23] <apw> ie if there was test3 which didn't reboot after test2
[11:23] <pitti> 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] <apw> pitti, but we rebooted in test2 and are on that kernel now no ?
[11:24] <pitti> well, I suppose you can construct a package test which runs test3 without reinitializing the testbed
[11:24] <pitti> apw: but it would appear in the list then
[11:24] <pitti> apw: i. e. the idea was to not show anything in the list which has (_, _, default_kernel_version)
[11:25] <pitti> apw: so that your check reduces to "this list must be empty"
[11:25] <apw> right, if thats what it is doing, that works too
[11:25] <pitti> apw: but I don't care much either way, pick your poison :)
[11:25] <apw> well the second is much shorter in the common case where theer is no reboot
[11:25] <apw> so ... making it harder for those who care is fine with me :)
[11:26] <apw> pitti, so i think i am voting for kernel_version + test_kernel_versions form
[11:28] <pitti> apw: ack; I sent a summary to the bug
[11:28] <pitti> and now, lunch for realz
[11:28] <apw> perhaps kernel_version_changes: to get them to sit by each other in the json
[11:29] <apw> as it is a delta list effectivly
[11:29] <pitti> noted in the bug, good call
[11:29] <apw> pitti, you should record the trigger in there too
[11:30] <apw> just becasue, and name the file such that it can :)
[11:35] <pitti> apw: *nod*
[14:42] <teward> 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] <ogra_> heh ... i still cant stop laughing about that naming :)
[14:46] <ogra_> teward, i think in wily at some point
[14:46] <teward> ogra_: what about retroactive changes?  Trusty (all variants) still on the older system?
[14:46] <ogra_> pitti might have the exact date
[14:47] <ogra_> yeah, trusty still uses properly guessable names
[14:47] <pitti> teward: https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038786.html
[14:47] <pitti> on June 17
[14:47] <ogra_> such an insane move
[14:47] <teward> pitti: and that was never implemented retroactively, or for the latest trusty point releases?
[14:48] <pitti> teward: heck, no -- that's a rather intrusive change, it's really not backportable
[14:48] <ogra_> haha, yeah
[14:48] <teward> pitti: tell that to dschatz_ in -server
[14:48] <pitti> well, "able" yes, but we so much won't
[14:50] <teward> 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] <teward> which was fixed same-day xD
[14:51] <ogra_> well, but that shows pretty good why backporting would be insane :)
[14:51] <teward> 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] <teward> ogra_: indeed
[14:51] <ogra_> lots of scripts to change etc etc
[14:51] <teward> mhm
[14:51] <teward> oop that reminds me.  Note to self: update wily VM >.<
[15:59] <pitti> apw: http://autopkgtest.ubuntu.com/packages/l/linux/ \o/
[15:59] <apw> pitti, sweet ... thanks for that