[03:57] <bkerensa> usb-creator is broken seven ways from sunday
[04:10] <adam_g_> anyone alive familiar with the dep8 testing suite @ lp:auto-package-testing?
[05:22] <ScottK> adam_g_: yolanda is.
[11:44] <mitya57> Who broke the builders? Here is a debdiff between pyside 1.1.2-3ubuntu1 and 1.1.2-4 (http://launchpadlibrarian.net/142485559/pyside_1.1.2-3ubuntu1_1.1.2-4.diff.gz)
[11:44] <mitya57> ... and the latter ftbfs on both i386 and amd64 while the former built fine...
[11:49] <jtaylor> am I blind or is there no error message?
[11:52] <mitya57> there is no error message :)
[11:52] <mitya57> and the build was done up to 100%
[12:01] <cjwatson> mitya57: make[4]: *** No rule to make target `/usr/lib/i386-linux-gnu/libQtWebKit.so', needed by `PySide/QtWebKit.so'.  Stop.
[12:02] <cjwatson> (trick: look at the make level that fails near the end, namely make[2], then search back for successively increasing make levels until you find the one with the actual error message nearly
[12:02] <cjwatson> *nearby)
[12:03] <mitya57> cjwatson: oh thanks; but why did the mostly identical version build?
[12:06] <cjwatson> mitya57: dunno, maybe qtwebkit changed?
[12:07] <mitya57> oh yes, seb128 sponsored new webkit yesterday
[12:07] <mitya57> *qtwebkit
[12:15] <mitya57> libqtwebkit-dev_2.3.1-0ubuntu1_i386.deb does contain /usr/lib/i386-linux-gnu/libQtWebKit.so symlink
[12:23]  * mitya57 found the issue
[12:24] <jtaylor> what is it?
[12:28] <mitya57> hardcoded version in rules
[12:28] <mitya57> ln -s libQtWebKit.so.4.10.0 debian/libqtwebkit-dev/usr/lib/$(DEB_HOST_MULTIARCH)/libQtWebKit.so
[12:29] <mitya57> the .so is 4.10.1 in the new version
[12:49] <infinity> Grr, who retried llvm-toolchain-3.3 on i386? :(
[12:49] <infinity> Pro tip: if a build is hanging, retrying it over the weekend when no one will be around to kill it is probably silly.
[13:08] <mitya57> infinity: probably that was a new upload to sid
[13:09] <mitya57> and it hangs again :(
[13:09] <infinity> mitya57: It wasn't.  It's already been killed once and someone retried it in the last couple of hours.
[13:11] <mitya57> infinity: that wasn't me, but kill it anyway if you're able to
[13:11] <infinity> mitya57: I'm not able, which was the point of my grumpiness.  All the people who have access to log in to buildds tend to take their weekends very seriously.  Oh well. :P
[13:12] <mitya57> Somebody really needs to fix auto-killing...
[13:12] <infinity> Yeah, it's on my TODO.
[16:17] <ricotz> infinity, hi :), jfyi, this linker failure looks like a toolchain problem -- https://launchpadlibrarian.net/142502649/buildlog_ubuntu-saucy-i386.gst-plugins-bad1.0_1.1.1.1%2Bgit20130614.d50625ee-0ubuntu1~13.10~ricotz0_FAILEDTOBUILD.txt.gz
[16:19] <infinity> ricotz: Why on earth is that using -nostdlib and then trying to guess the right thing to do?
[16:21] <infinity> ricotz: Anyhow, without looking too closely, I'd give good odds that the -lfoo bits are at the wrong point in the linker command.
[16:22] <infinity> ricotz: Still, not trusting your compiler or linker, and then manually linking all of crt* -lc, etc, is a bit nuts.
[16:22] <infinity> ricotz: So, I'd be less inclined to call it a toolchain bug and more inclined to assume it's a misuse of the toolchain.
[16:23] <ricotz> infinity, thanks for taking a glimpse at it, will point it out to upstream
[16:24] <infinity> ricotz: If you happen to have a failed local build tree around, try re-running that last link command with "-lstdc++ -lm -lc -lgcc_s" at the end of the command line.
[16:24] <ricotz> infinity, the amd64 didnt fail which i am have locally too
[16:25] <ricotz> so a vanilla git build is fine on amd64
[16:27] <infinity> I'll see if I can reproduce on i386 in a bit.
[16:28] <ricotz> infinity, thanks!
[16:28] <infinity> (Probably going to blame crazy toolchain abuse either way, but there's a slim chance it's a gcc/binutils bug)
[16:28] <infinity> Though, probably not, given that it's whining about stack_chk symbols in libc, and I haven't changed glibc since raring.