| infinity | win 19 | 00:06 |
|---|---|---|
| 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.) | 00:31 |
| pitti | Good morning | 04:58 |
| === davidcalle_ is now known as davidcalle | ||
| === Guest8229 is now known as Tm_Tr | ||
| 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:30 |
| 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:32 |
| sitter | ah | 08:33 |
| sitter | pitti: ok thanks :) | 08:34 |
| 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:36 |
| 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? | 08:37 |
| pitti | flexiondotorg: sounds like it reported it to errors.u.c. only? | 09:08 |
| 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:09 |
| 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:10 |
| pitti | true that | 09:11 |
| Laney | but if you can think of a good process checkpoint later on | 09:11 |
| 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:13 |
| 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:14 |
| 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:25 |
| 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:26 |
| 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:27 |
| apw | pitti, OH do you use a profile ? | 09:28 |
| pitti | no, I don't think so | 09:28 |
| 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:29 |
| pitti | apw: so all these missing ones have a build profile now? how do they look? (to spare me apt-get source linux) | 09:30 |
| pitti | <!stage1> or something? | 09:30 |
| apw | http://paste.ubuntu.com/12327328/ | 09:30 |
| 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:31 |
| 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:35 |
| 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:36 |
| 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:38 |
| 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:39 |
| apw | yeah must be ... i wil beat tim to find out what occured later then :) | 09:40 |
| 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:41 |
| 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:50 |
| 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 | 09:51 |
| 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:02 |
| 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:26 |
| 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:32 |
| 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:33 |
| 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:34 |
| === nudtrobert1 is now known as nudtrobert | ||
| 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:40 |
| pitti | apw: yep, working on that now | 10:41 |
| 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:49 |
| pitti | apw: so for bug 1491865 -- 1) just means you want to see it in the log, right? | 10:50 |
| ubottu | bug 1491865 in autopkgtest (Ubuntu) "report and record the actual booted kernel with test results" [High,In progress] https://launchpad.net/bugs/1491865 | 10:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 10:59 |
| 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:00 |
| pitti | test_kernel_versions: testname -> ID -> version | 11:01 |
| pitti | (and we usually don't expect the latter at all) | 11:01 |
| apw | is testname ID there is that like testname: [(id, version), ...] | 11:02 |
| pitti | apw: "testname" -> name in Tests: in d/t/control | 11:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| pitti | apw: "after test bed setup" would be the first entry with the special reboot ID '' | 11:16 |
| 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:17 |
| apw | ironically i will just run the list and make sure V does not change, and use it | 11:18 |
| pitti | apw: http://paste.ubuntu.com/12327750/ | 11:19 |
| pitti | apw: (no tuples in json, they become lists, but *shrug*) | 11:19 |
| apw | that looks good to my eye, over engineered to hell and back i am sure, but yes | 11:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| apw | pitti, so i think i am voting for kernel_version + test_kernel_versions form | 11:26 |
| 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:28 |
| 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:29 |
| apw | just becasue, and name the file such that it can :) | 11:30 |
| pitti | apw: *nod* | 11:35 |
| === MacSlow is now known as MacSlow|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| 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:42 |
| ogra_ | heh ... i still cant stop laughing about that naming :) | 14:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:50 |
| 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 >.< | 14:51 |
| pitti | apw: http://autopkgtest.ubuntu.com/packages/l/linux/ \o/ | 15:59 |
| apw | pitti, sweet ... thanks for that | 15:59 |
| === mnepton is now known as mneptok | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!