| === steve__ is now known as sbeattie | ||
| rsalveti | stgraber: hey, if still around, quick question, I did a binary copy of phablet-tools to proposed (https://launchpad.net/ubuntu/+source/phablet-tools/1.0+14.04.20131108-0ubuntu1/+publishinghistory), now is there anything else I need to do or just wait for migration to happen? | 00:43 |
|---|---|---|
| rsalveti | first time I'm actually copying the binary package to the archive (from the daily-build one) | 00:44 |
| rsalveti | seems it was finally published in proposed | 00:45 |
| stgraber | if britney/autopkgtest don't find any problem, there shouldn't be anything for you to do | 00:49 |
| rsalveti | great :-) | 00:52 |
| === doko_ is now known as doko | ||
| doko | cjwatson, could you have a look at https://launchpad.net/ubuntu/+source/libpod-spell-perl/1.12-1/+build/5193802 ? libclass-tiny-perl is in main | 09:58 |
| cjwatson | doko: only the source | 09:59 |
| doko | looking ... | 10:00 |
| cjwatson | double-override accident, maybe? | 10:00 |
| cjwatson | https://launchpad.net/ubuntu/trusty/i386/libclass-tiny-perl suggests so | 10:00 |
| cjwatson | I'll try copying it back. Please don't do the same within this publisher run | 10:00 |
| doko | hmm, I did run ./change-override -s trusty -y -S -c main libclass-tiny-perl | 10:01 |
| doko | ok | 10:01 |
| cjwatson | But it looks like either you did it twice, or somebody else did it at the same time | 10:01 |
| doko | yes, could be | 10:02 |
| doko | wondering what else I did do twice for the perl stuff | 10:02 |
| cjwatson | Not sure OTTOMH how to tell | 10:03 |
| cjwatson | infinity: do you have a way to search for double-override accidents? | 10:03 |
| infinity | cjwatson: Nope. | 10:04 |
| cjwatson | We could iterate all binary packages looking for ones where the most recent BPPH is superseded, but that'd be really slow over the API | 10:05 |
| infinity | cjwatson: /win 36 | 10:06 |
| infinity | Erm. | 10:06 |
| infinity | La la la. | 10:06 |
| cjwatson | Shan't | 10:06 |
| doko | cjwatson, does NBS complain about recommends too? e.g. gmsh/gmsh-doc | 10:57 |
| cjwatson | Yes | 11:02 |
| cjwatson | If you think it's appropriate to remove anyway then you can | 11:02 |
| cjwatson | Probably makes sense to remove in that case | 11:02 |
| doko | ok | 11:04 |
| doko | filed a bug in debian | 11:04 |
| === tkamppeter_ is now known as tkamppeter | ||
| apw | i am just doing a dist-upgrade from saucy to trusty and (for the second time of asking) i am hitting a rhythmbox-data install failure, which doesn't seem to have any deatails ... is this known | 13:57 |
| Laney | apw: Were there really no details? Check /var/log/apt/term.log | 14:18 |
| Laney | (also, reproduced) | 14:19 |
| apw | Laney, doh didn't look there, looked a lot of other places | 14:21 |
| Laney | Simple file conflict, fixing | 14:21 |
| apw | heh ... thanks ... yes file conflict | 14:21 |
| seb128 | Laney, doing a rb upload? | 14:22 |
| Laney | ya | 14:22 |
| Laney | well, unless you have something | 14:22 |
| seb128 | Laney, can you include https://git.gnome.org/browse/rhythmbox/commit/?id=f326f8e7055ee8b681a72f000203d071ccc72646 ? | 14:22 |
| Laney | in which case I | 14:22 |
| Laney | damn! | 14:22 |
| seb128 | lol | 14:22 |
| seb128 | too slow :p | 14:22 |
| seb128 | if you did it already no worry, we can queue in the vcs for the next upload | 14:22 |
| Laney | no, I'm not that fast :P | 14:22 |
| Laney | will do | 14:23 |
| seb128 | thanks | 14:23 |
| apw | awsome ... | 14:23 |
| Laney | seb128: is there an lp bug for that? | 14:30 |
| seb128 | Laney, no, I just noticed it while look at git logs for cherrypicks for the LTS | 14:31 |
| Laney | k | 14:31 |
| apw | seb128, that rhythmbox upload you did that is in -proposed, seems to change the Uploaders:, does that make sense ? | 15:43 |
| infinity | apw: GNOME Team packages get control auto-mangled via gnome team tools. | 15:44 |
| infinity | apw: So, uploaders and some other bits randomly morph from week to week. | 15:45 |
| apw | infinity, up in debian right ? in ubuntu with an ubuntu specific change only i am supprised | 15:45 |
| infinity | apw: Same tools run in Ubuntu. | 15:45 |
| infinity | apw: And, in fact, that can often be the source of the delta, as we may have a different version of said tools with an older uploaders list. :P | 15:46 |
| infinity | (But it doesn't much matter) | 15:46 |
| apw | fair enough then, it is an oddity and no mistake | 15:46 |
| apw | Laney, when you have dumped that fix for rhythmbox in ping me, i have a nice test rig waiting for it | 15:47 |
| Laney | now | 15:47 |
| Laney | it's trivially reproducible in a chroot by installing rhythmbox in saucy then dist-upgrading to trusty | 15:48 |
| seb128 | apw, what infinity said, GNOME packages computes the Upload from the recent entries in the changelog | 16:08 |
| seb128 | compute the Uploaders* | 16:09 |
| apw | fair enough, something to ignore when looking at diffs | 16:09 |
| apw | as i was really looking for Laney's diff anyhow :) | 16:09 |
| jodh | please could someone do magic to make upstart 1.11-0ubuntu1 migrate out of proposed? 1 test is failing but only on amd64 (I'm sure this is a test or test env bug). | 16:57 |
| infinity | jodh: Generally, the solution to failing tests is to fix the failure. :P | 16:57 |
| ogra_ | really ? | 16:58 |
| ogra_ | not "close your eyes" ? | 16:58 |
| jodh | infinity: clearly, I'd prefer that. Since the other 1669 test all pass both locally and on the build's and in the jenkins env, and I've boot tested on 3 arches locally, I'm happy that the failure is not indicative of a regression. | 16:59 |
| infinity | jodh: Have you tested on the latest trusty kernel? | 16:59 |
| infinity | jodh: (If the test is known-broken, an upload to disable it, or at least a commit that will do so in the next upload would still be better than me having to wave it through every third upload) | 17:00 |
| infinity | jodh: If the test isn't provably broken, then maybe the code is. Which is the point of testsuites. | 17:00 |
| infinity | jodh: (Is there an urgent reason upstart needs to be a unique snowflake in this regard?) | 17:01 |
| stgraber | jodh: another test run is happening now | 17:01 |
| jodh | infinity: >latest kernel=yes. I am obviously currently trying to resolve the issue. If slangasek is happy to wait until its fixed, fine with me but we were hoping to get this into the archive today and every test run until now has passed 100%. | 17:04 |
| infinity | Everyone's always hoping to get things in when they upload them. I just prefer not to short around the whole point of testsuites until one can provably demonstrate that a failure is due to a broken test. | 17:05 |
| infinity | *shrug* | 17:05 |
| infinity | "It usually passes but sometimes doesn't" isn't so much proof. | 17:05 |
| slangasek | jodh: I said you should upload today, but if it doesn't get into trusty because of a test suite failure, we should resolve that rather than bypass it :) | 17:07 |
| jodh | slangasek: ok, I'll keep at it then... | 17:09 |
| stgraber | hmm, looks like the most recent run of the test just passed (not sure what triggered the re-run, maybe a rdepend upload) | 17:17 |
| slangasek | stgraber: where do you see that? | 17:17 |
| slangasek | amd64 build 14 is the most recent on https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-upstart/ and has a test suite failure | 17:17 |
| stgraber | slangasek: http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-upstart/ARCH=amd64,label=adt/15/console | 17:17 |
| stgraber | currently running | 17:17 |
| slangasek | jodh: so is this a known test failure? | 17:18 |
| slangasek | stgraber: ok | 17:18 |
| slangasek | so we get it into trusty for free, but we should still figure out why the test was failing ;) | 17:18 |
| jodh | stgraber: we have seen it before. I thought I'd fixed it before release but clearly not :) | 17:20 |
| stgraber | the remaining tests just finished without any failure, so looks like upstart will get promoted next time britney runs | 17:20 |
| jodh | slangasek: that is to say, I had a test fix merged for this bug and that appeared to squish it, but... | 17:20 |
| slangasek | jodh: that was lp:~jamesodhunt/upstart/fix-test_state-test-reprise ? | 17:39 |
| slangasek | jodh: I'm confused how this test ever works. You have a child that blocks waiting to read a byte from fds[0], but I don't see the parent ever writing to fds[1] | 17:56 |
| slangasek | jodh: so I think this thread only works by accident when the kernel *happens* to have flushed the log after the write of the initial data | 17:56 |
| slangasek | s/thread/test/ | 17:56 |
| jodh | slangasek: the parent does write to fds[1]. I'll debug Monday now... | 19:09 |
| slangasek | no really, it doesn't ;) | 19:09 |
| === Pici is now known as Guest25996 | ||
| === Guest25996 is now known as Pici | ||
| xnox | slangasek: i guess i'm on the hook, for accepting that fix. thus clearly i don't understand the fds in that test either. | 22:01 |
| slangasek | well, I was wrong when I said it doesn't write to fds[1] | 22:01 |
| slangasek | I just didn't read down far enough | 22:01 |
| slangasek | (it might help if there were comments to make it clear where the expected sync points are for child and parent...) | 22:02 |
| xnox | so parent asserts at 2153, did not stat filename. | 22:03 |
| slangasek | so the failure seems to be to do with TEST_FORCE_WATCH_UPDATE() not successfully triggering the write to the logfile. But that's a complex macro that's only used in the test suite, so we basically don't know if it's correct | 22:04 |
| xnox | and child asserts at 2122, failed to read. | 22:04 |
| slangasek | right; the child assert is strictly secondary | 22:05 |
| xnox | so imho when the write to pty_slave happened, that didn't hit the disk (?!) | 22:07 |
| slangasek | correct | 22:07 |
| slangasek | but we don't know why, because the route to disk goes into upstart's logging subsystem and back out again :) | 22:07 |
| xnox | i did ask / comment (maybe it was private irc) to have "sync()" after write. | 22:07 |
| slangasek | and of course, that's not what this test is /about/ | 22:07 |
| slangasek | that wouldn't work | 22:07 |
| slangasek | the pty doesn't point at the log file, it points at upstart's internal log handler, which buffers and then writes to disk | 22:08 |
| xnox | right, so the test, if the file was not statted, should have done in tap "# skip initial data didn't write" | 22:08 |
| slangasek | why 'skip'? | 22:08 |
| xnox | slangasek: well, i guess it should continue, and everything should be still unflushed. | 22:09 |
| xnox | slangasek: why do we do initial file checks? | 22:09 |
| slangasek | I don't know | 22:09 |
| xnox | and does the upstart's internal log handler have something like nih_flush_sync_now()? =) | 22:10 |
| slangasek | I would /guess/ that it's to ensure that a race doesn't cause the log file to be created and flushed when we're not looking, before the re-exec happens | 22:10 |
| slangasek | but given that we're not in an event loop at this point, I don't know why we're worried about that happening | 22:10 |
| slangasek | hmm, but we do have to trigger the read from the pty to have any of the data in our internal buffer | 22:11 |
| slangasek | which might silently trigger a flush to disk | 22:11 |
| slangasek | so... we *could* pre-populate the file in the parent with EACCES perms, then all of the child's output would be queued | 22:12 |
| slangasek | I think? | 22:12 |
| xnox | yeah. | 22:13 |
| xnox | it's just it wouldn't tell us if it kept the original output, or overwrote it. | 22:14 |
| slangasek | how do you mean? | 22:14 |
| xnox | start with a log file that has "hello world\n" in it. | 22:14 |
| slangasek | why wouldn't we start with an empty log file? | 22:15 |
| slangasek | this test is only supposed to be testing that unflushed log buffers are serialized/deserialized correctly across re-exec | 22:15 |
| xnox | ok. | 22:16 |
| xnox | and i presume log buffer is tested to not clobber over previous output already. | 22:16 |
| xnox | slangasek: today nih test-suite caught non-Posix behaviour of the FreeBSD kernel. =) | 22:17 |
| slangasek | I don't know if we have a test for not clobbering logs, but that's not this test ;) | 22:17 |
| slangasek | xnox: heh, nice | 22:17 |
| xnox | so i'm happy. (PR filed in freebsd & and the devs were grumpy on irc) | 22:17 |
| * slangasek snerks | 22:18 | |
| xnox | int off-by-a-WEXITEDSTATUS-bitmask error | 22:19 |
| slangasek | xnox: lp:~vorlon/upstart/flaky-log-serialization-test, maybe | 23:31 |
| xnox | slangasek: code looks good. should probably also remove the introduced #define TIMED_BLOCK as well. | 23:46 |
| slangasek | ah, good catch | 23:47 |
| slangasek | pushed | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!