[01:45] <xnox> cjwatson: yeap, that did it.
[04:06] <shuduo> hi, anyone know where is right channel to discuss Ubuntu SDK issue if not here?
[09:32] <xnox> shuduo: typically #ubuntu-touch and/or #ubuntu-app-devel. But do note it's coming up to hollidays seasons.
[09:33] <xnox> shuduo: if no answer on irc, email ubuntu-phone mailing list (plenty of sdk questions answered) and/or file bugs on launchpad.
[09:34] <shuduo> xnox: thanks. i aleady file a bug to website since they are different. but i can't find where to file bug for ubuntu-sdk
[09:35] <xnox> shuduo: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bugs is a good starting place.
[09:35] <shuduo> xnox: in theory ubuntu-sdk don't provide scope template is not fault of ubunt-touch ;)
[09:35] <xnox> shuduo: ah, templates are part of the qtcreator ubuntu plugin.
[09:40] <shuduo> xnox: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1263593 already also affect ubuntu-ui-toolkit
[09:41] <xnox> shuduo: tweaked, moved to qtcreator-plugin-ubuntu project.
[09:41] <xnox> shuduo: thanks =)
[09:42] <shuduo> xnox: great. thanks.
[11:58] <mlankhorst> ok I finished up the xorg lts-saucy stack preparations :P
[12:09] <mardy> cjwatson: hi! Can I use the "Exec" field of a click hook to perform some checks and optionally return an error to prevent the installation of the click package?
[12:33] <Laney> xnox: will look at some point
[12:33] <Laney> christmas shenanigans
[12:34] <xnox> Laney: all fixed now, i think.
[12:34] <xnox> Laney: merry xmas ;-)
[12:35] <cjwatson> mardy: You can't prevent installation as such, because Exec hooks necessarily run after the package has been unpacked
[12:36] <cjwatson> mardy: If the command named in the Exec field of a hook returns non-zero then click will raise an exception
[12:37] <cjwatson> mardy: We could debate whether something in the stack should remove the package again in that event, I suppose (though what if the hook still fails?)
[12:37] <mardy> cjwatson: right, and I actually figured out that I don't need that; I was worried that a click package could install an Online Account plugin in ~/.local/... which would obscure a system plugin, but then realized that it will always have the click ID as namespace
[12:38] <cjwatson> mardy: Right, that's a better answer indeed
[12:38] <cjwatson> mardy: I'd be open to defining some other type of hook for pre-installation checks, but I'd prefer to do so in response to a need that isn't satisfied some other way so that I know we're designing it right :-)
[12:39] <mardy> cjwatson: absolutely
[12:40] <mardy> cjwatson: about bug 1245826, would you like me to work on that?
[12:42] <cjwatson> mardy: oh, sure, if you like
[12:42] <cjwatson> mardy: just make sure you include a doc update and tests
[12:43] <mardy> cjwatson: OK, it's not my top priority ATM, but it might become it. :-) If/when I start working on it, I'll assign the bug to myself
[12:43] <mlankhorst> cjwatson: well lts-saucy stack in NEW soon :P
[12:44] <mlankhorst> who's doing 12.04.4 this time?
[15:46] <caribou> what should be done when a FTBS on trusty-proposed is caused by a FTBS issue on Debian/sid ?
[15:46] <caribou> the FTBS in question is seabios 1.7.3-3
[15:47] <cjwatson> no different from any other cause
[15:47] <cjwatson> just make sure to forward the fix to Debian
[15:48] <caribou> cjwatson: it doesn't build on Sid because of the version of iasl that doesn't fit with seabios
[15:48] <caribou> cjwatson: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707454
[15:49] <caribou> cjwatson: last comment on the bug is that it will not build on Sid either
[15:57] <cjwatson> caribou: I don't have any special expertise in this package, so no point telling me the details :)
[15:58] <cjwatson> if you don't know how to fix it then you can always leave it for the Debian maintainer
[15:58] <caribou> cjwatson: it was not specific to the package itself, but what do Ubuntu does whenit import a package that is FTBS on Debian as well ?
[15:59] <caribou> cjwatson: but that's fine, I'll let it up to the DM to fix
[15:59] <cjwatson> caribou: it FTBFS until somebody fixes it ...
[15:59] <cjwatson> caribou: there's really nothing special about the *reason* for the FTBFS here
[15:59] <cjwatson> caribou: it'll generally sit unmigrated in trusty-proposed
[15:59] <cjwatson> as indeed I see is happening here
[15:59] <caribou> cjwatson: ah, ok, that was my question
[16:00] <caribou> cjwatson: thanks for the answer
[16:43] <zyga> hi, is it possible to sync from debian NEW into ubuntu?
[16:44] <cjwatson> No
[16:45] <cjwatson> Because the files in NEW aren't publicly available
[16:45] <zyga> ah, ok
[16:46] <cjwatson> You can reupload manually if you have them, but it can be faster to just wait ... once ftpmaster processes something it'll be auto-synced without intervention, whereas manual uploads require manual attention from the Ubuntu side
[16:46] <cjwatson> So it depends whether you think Debian ftpmasters or Ubuntu AAs will be faster :)
[16:46]  * zyga wonders if he should wait $random amount of time for NEW to get processed or should he continue the motu path to get that package into ubuntu first
[16:46] <cjwatson> Over the Christmas break I'd bet on the former if I were you
[16:46] <zyga> cjwatson: I have no experience with either TBH :)
[16:47] <cjwatson> Ubuntu NEW can be fairly random too for source uploads ...
[16:47] <zyga> cjwatson: is a package going to be in NEW after each upload or just the initial release into debian?
[16:48] <cjwatson> NEW means "package of that name not currently in that suite"
[16:48] <zyga> ah, I see
[16:48] <cjwatson> So you generally only hit it once per package unless you're backporting
[16:48] <zyga> so subsequent updates should be fairly quickly, as in, sponsor-fast
[16:48] <cjwatson> Yes
[18:21] <cjwatson> hmph, python-numpy fails to build with python3.4 in python3-defaults
[18:21] <cjwatson> I think I shall finish for the day (and year) rather than investigating :)
[20:17] <xnox> ev: as much as we like to have a package that only builds on arm64 & ppc64el and fails elsewhere, I'm disabling valgrind across the board. Looks like it's reporting unrelated leakage or somesuch with new gtk3.10. This has been noticed across other #ps projects, so until that is fixed / valgrind filtered the build will run without valgrind.
[20:17] <xnox> https://launchpad.net/ubuntu/+source/whoopsie/0.2.24.2
[20:19] <Logan_> xnox: Did you get my email?
[20:20] <xnox> Logan_: yeah, it's all fixed =)
[20:20] <xnox> Logan_: check out the hdf5 upload.
[20:20] <xnox> (diff)
[20:20] <Logan_> xnox: Oh sweet. Why was it disabled?
[20:20] <xnox> Logan_: not only openmpi is arch restricted in debian/control, it was further "building empty package" in the debian/rules.
[20:21] <xnox> Logan_: i presume the packager didn't spend time to filter and dynamically detect which backend default mpi is using & dynamically check if it's openmpi. Instead it got hard-coded twice.....
[20:22] <Logan_> Okay. That whole thing is a mess, honestly.
[21:02] <xnox> ev: https://launchpad.net/ubuntu/+source/whoopsie/0.2.24.3 that is.
[21:02] <xnox> Logan_: yeah. =)
[21:03] <xnox> Logan_: similarly, if you expand http://people.canonical.com/~ubuntu-archive/transitions/html/openmpi1.6.html to include "good" you will notice how plenty of projects are not linking against openmpi on arm64/ppc64el. Sometimes it's because debian/rules and/or debian/control were restricted in a similar manner to hdf5, other-times it simply needs a no-change rebuild..... =)
[21:04]  * xnox *hides*
[22:01] <melodie> hello!
[22:02] <melodie> I try to improve a remix I am working on. I have an issue with the integrity-check stanza. Where should I look to find what to fix?
[22:30] <melodie> does someone know what triggers the integrity-check stanza in a live iso?
[23:01] <slangasek> wow, schadenfreude. https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1263672
[23:44] <infinity> slangasek: I have so many questions about that upgrade log...