=== chihchun_afk is now known as chihchun
[07:33] <DanChapman> Good Morning
[07:35] <elfy> hi d
[07:35] <elfy> anChapman
[07:35] <Noskcaj> hey DanChapman
[07:35] <Noskcaj> forgot the tab button elfy?
[07:36] <elfy> :)
[07:36] <DanChapman> Hey e
[07:36] <DanChapman> lfy
[07:36] <DanChapman> :-)
[07:36] <DanChapman> Hey Noskcaj
[07:37] <elfy> Noskcaj: nope remembered the tab button - but refused to believe it when it said there was more than one choice :p
[08:43] <jibel> pitti, did you change the default timeout in autopkgtest? https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-linux/40/ fails after 1h
[08:44] <pitti> jibel: no, I didn't
[08:44] <pitti> jibel: at least not deliberately, might be a bug
[08:49] <jibel> pitti, ah, that's because the 'install' timeout applies. Shouldn't it be the 'build' timeout instead which is 100ks?
[08:51] <pitti> oh, those tar errors, yay
[08:51] <pitti> jibel: yes, that looks like it should be the build timeout
[08:54] <pitti> jibel: hm, I grepped for all "install" and "build" in adt-run, and they seem to be alright
[08:55] <jibel> pitti, I did the same, maybe the alarm is not reset with the right timeout before starting the build
[08:55] <pitti> ah, good idea
[08:59] <pitti> jibel: lib/VirtSubproc.py reads ok, but I'll make some tests
=== chihchun is now known as chihchun_afk
[09:03] <pitti> jibel: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=python-dateutil_1.5%2Bdfsg-1.debdiff;att=1;bug=729461 is missing an "allow-stderr", fixing
[09:04] <jibel> pitti, thanks
=== chihchun_afk is now known as chihchun
[10:59] <davmor2> Morning all
=== vrruiz_ is now known as rvr
=== Ursinha is now known as Ursinha-afk
=== chihchun is now known as chihchun_afk
=== _salem is now known as salem_
[13:08] <DanChapman> jibel, hey o/ whats the easiest way to find uploaded crash reports from jenkins jobs?
[13:09] <jibel> DanChapman, Hi, it should be in the test artifacts
[13:10] <jibel> for example https://jenkins.qa.ubuntu.com/job/ubiquity_ap-ubuntu_devel_daily-test_english_lvm/62/ARCH=i386,label=rabisu/
[13:10] <jibel> in results/var/crash
[13:12] <DanChapman> jibel ahh yes i see it now :-) darn segfault is playing havoc still
[13:12] <DanChapman> thanks
[13:13] <jibel> DanChapman, and now it is uploaded to errors.ubuntu.com too
[13:13] <jibel> https://errors.ubuntu.com/problem/8ff8c9bfa3317b35d4a1af984e0e4208acd7af42
[13:13] <jibel> if you have access to it
=== Ursinha-afk is now known as Ursinha
[13:16] <DanChapman> jibel, i don't have access, i'll fill out the form though :-)
[13:21] <jibel> DanChapman, I created bug 1267105 but it is not very useful, it is just a link to the error tracker
[13:21] <ubot5> bug 1267105 in ubiquity (Ubuntu) "/usr/lib/ubiquity/bin/ubiquity:11:GtkNode::MatchStringProperty:xpathselect::XPathQueryPart::Matches:SelectNodes:GetNodesThatMatchQuery:Introspect" [Undecided,New] https://launchpad.net/bugs/1267105
[13:22] <jibel> pitti, do you know how to generate a useful trace from a report on errors.ubuntu.com ?
[13:22] <jibel> for example https://errors.ubuntu.com/problem/8ff8c9bfa3317b35d4a1af984e0e4208acd7af42
[13:23] <pitti> jibel: hm, looking at the first example (https://errors.ubuntu.com/oops/efb3cb2c-783e-11e3-88dc-2c768aafd08c) that almost looks like the original user's stack trace, not a retraced one
[13:24] <jibel> pitti, yes, hence my question, is there anything special to do to retrace it when it is uploaded?
[13:24] <pitti> jibel: that sounds like our old autopilot-gtk crash friend again?
[13:24] <jibel> pitti, yup
[13:24] <pitti> jibel: the daisy retracers are supposed to do that; I don't have access to those, though; i. e. no idea why the result is so bac
[13:24] <pitti> bad
[13:24] <pitti> perhaps it's missing ddeb apt sources for trusty?
[13:43] <jibel> DanChapman, I filed bug 1267116. We'll see if it makes a better job than errors.u.c
[13:43] <ubot5> bug 1267116 in ubiquity (Ubuntu) "ubiquity crashed with SIGSEGV in GtkNode::MatchStringProperty()" [Undecided,New] https://launchpad.net/bugs/1267116
[13:57] <DanChapman> jibel, great cheers, looking at the differences between the passing/failing artifacts all, there seems to be a difference in the autopilot.log showing "[default] CRITICAL: atk_object_set_parent: assertion 'ATK_IS_OBJECT (accessible)' failed
[13:57] <DanChapman> Segmentation fault (core dumped)" i've seen a issue like this recently with inkscape when trying to open an image and it crashes displaying the same  atk error
=== elopio_ is now known as elopio
[14:25] <elopio> good morning
[14:25] <balloons> good morning elopio
[15:17] <balloons> ping pitti
[15:19] <pitti> hey balloons, happy new year!
[15:19] <balloons> hey pitti :-) All holiday'd out by now eh? :-) Happy New Year to you as well ;-)
[15:20] <pitti> balloons: heh, yes; two weeks plus an extra day was quite fine
[16:01] <jibel> pitti, re bug 1267116
[16:02] <ubot5> bug 1267116 in ubiquity (Ubuntu) "ubiquity crashed with SIGSEGV in GtkNode::MatchStringProperty()" [Medium,New] https://launchpad.net/bugs/1267116
[16:02] <jibel> the stack trace is not very useful but it crashes again on the closing brace
[16:02] <pitti> argh
[16:02] <jibel> of the method GtkNode::MatchStringProperty
[16:02] <pitti> jibel: with DanChapman's reproducer I only got it to hang, but not to crash
[16:03] <jibel> same here, I couldn't reproduce locally
[16:03] <pitti> this seems ridiculously hard to boil down into a smaller test case :(
[16:24] <pitti> jibel: hmm; the only kinds of std::string that are left are the method arguments
[16:26] <pitti> and they are only references
[17:56] <DanChapman> pitti, how does autopilot-gtk match doubles say for the progressbar fraction property? I can only see Match String/Integer/Boolean Property methods
[18:59] <thomi> morning
=== salem_ is now known as _salem