[05:29] <pitti_> Good morning
[05:41] <pitti> bdmurray: FYI, I fixed the eternal sru-report crash on missing "published" attribute in r713 and (in a better way) r717; I hope the sorting will be alright with that
[06:25] <pitti> @pilot on
[06:25] <udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[06:25] <pitti> @pilot in
[06:52] <dholbach> good morning
[07:03] <mlankhorst> g'day
[08:27] <bl4de> hi to all! :)
[08:30] <bl4de> Guys, I've an idea (I've a dream ;) ). I'd like to write a Qt opensource SublimeText editor, 100% compatible with the original plugin packages, with same characteristics etc, but there is too much work for only me. I'd not experience for creating a brand new editor widget for qt, so I want to create a team. Who can join and help me?
[08:30] <bl4de> *I've not
[08:32] <bl4de> Languages are C++ for editor and Python for plugin system
[08:39] <mitya57> bl4de: you probably want #ubuntu-app-devel
[08:40] <bl4de> mitya57, thank you, I'll try also there :)
[08:50] <pitti> yolanda: please forward your autopkgtests to Debian; e. g. your quagga one introduces an Ubuntu delta, and thus will require merging from now on
[08:51] <yolanda> ok, i saw the new approved branches, i'll do it
[08:51] <pitti> thanks
[08:51] <pitti> yolanda: great to see so many new tests!
[08:51] <pitti> many of them are just "daemon running", and no functional behaviour, but that alone already covers quite a bit
[08:52] <pitti> yolanda: are you transitioning the old qa-regression-tests over to autopkgtests?
[08:54] <yolanda> pitti, i'm just copying tests from qa-regression-test branches to autopkg in the case that there are some, but nothing more. What do you mean with transitioning?
[08:54] <pitti> yolanda: yes, that's what I meant
[08:54] <pitti> "moving over"
[08:56] <yolanda> well, i copied the tests, is there something else i should do for it? should i inform someone, maybe the authors of that branch?
[08:56] <pitti> yolanda: no, that's fine; well, they should be forwarded to Debian
[08:57] <yolanda> i'm normally moving the approved ones, i have some to forward today
[08:57] <yolanda> pitti, i saw a failure for ganglia
[08:57] <yolanda> did you see it?
[08:57] <pitti> no, I didn't -- it's not yet on https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/
[08:58] <pitti> oh, you mean the powerpc build failure?
[08:58] <pitti> yes, that needs to be addressed; the previous version built
[08:59] <pitti> I guess it's enough to retry the build once librrd-dev becomes installable again on ppc in saucy-proposed
[08:59] <yolanda> yes, the powerpc
[09:00] <cjwatson> That'll be fixed after the next publisher run
[09:00] <cjwatson> pangox-compat was a bit behind in building
[09:03] <pitti> yolanda: I'll retry the ppc build in a bit
[09:03] <yolanda> great
[09:05] <cjwatson> Or I'll do a mass retry of affected stuff after the next publisher run - I have a script to help me out a bit
[09:07] <pitti> even better (gnome-control-center also failed due to this)
[09:14] <pitti> hey sabdfl, how are you?
[09:14] <sabdfl> well thanks pitti, how about you?
[09:15] <pitti> sabdfl: quite fine, thanks!
[09:15] <sabdfl> got the phone up and running near you?
[09:15] <pitti> no, I only have an n7
[09:15] <pitti> so using wifi :)
[09:15] <sabdfl> looking good, huh
[09:15] <pitti> until we get a build for the Sony xperia :)
[09:16] <tvoss> pitti, seems like some images are available for sony xperia: https://wiki.ubuntu.com/Touch/Devices
[09:17] <tvoss> pitti, although not from cdimage.u.c
[09:17] <pitti> yeah, for the neo; I have the mini pro
[09:17] <pitti> (mango)
[09:18] <tvoss> pitti, ah :)
[09:18] <pitti> btw, are we going to have daily saucy builds for the n7 at some point? or do you guys prefer to stick on raring for now? (moving target vs. not picking up fixes)?
[09:19] <didrocks> pitti: it's going to be saucy in the next few days (hope by end of the week AFAIK)
[09:19] <pitti> \o/
[10:05] <cousteau> https://bugs.launchpad.net/ubuntu/+source/freehdl/+bug/291075
[10:06] <cousteau> this bug has been around since 2008 and still not fixed (at least for Precise).  The fix seems to consist in changing a line from a Perl script.  Could somebody do something to fix this?
[10:07] <cousteau> (the patch has been there since 2008 as well)
[10:09] <cousteau> found this bug when running gvhdl manually, not through Qucs
[10:10] <pitti> cousteau: that ought to be fixed in raring?
[10:10] <cousteau> well, the freehdl version of raring and precise are the same
[10:11] <cousteau> that should have been fixed in freehdl 0.0.6-something, actually; and 0.0.7 has been there since lucid
[10:26] <pitti> cjwatson: do you have an opinion about https://code.launchpad.net/~diwic/dpkg/original-maintainer/+merge/165107 ? it seems fine to me, as we introduced that field
[10:27] <cjwatson> pitti: IMO should be sent to Debian for comment; it's not urgent so can afford to go through review there
[10:27] <pitti> cjwatson: ack, thanks
[10:27] <diwic> cjwatson, to me it's ubuntu specific
[10:28] <cjwatson> Original-Maintainer is mentioned in the upstream code, since Dpkg::Vendor::Ubuntu is carried there
[10:28] <cjwatson> So please forward it first even if you think it's Ubuntu-specific
[10:28] <cjwatson> We want to get to zero delta in dpkg eventually if we can possibly manage it
[10:29] <diwic> cjwatson,  hmm, ok
[10:29] <cjwatson> (Dpkg::Vendor::Ubuntu is the result of an earlier attempt to get to zero delta, and made a big dent even if it didn't get us all the way there)
[10:30] <diwic> want me to upstream it or is it better that pitti or cjwatson  does it if you know the dpkg people better?
[10:30] <cjwatson> I think you can go ahead and upstream it yourself
[10:30] <cjwatson> Just file a bug against Debian's dpkg package
[10:30] <diwic> cjwatson, ok, will do. Thanks
[10:31] <pitti> thanks diwic
[10:31] <cjwatson> I do think it's a reasonable change, but since it's cosmetic I'd like to avoid it resulting in an extra delta to maintain, that's all
[10:31] <diwic> even dpkg itself has this build warning in Ubuntu :-)
[10:45] <tvoss> didrocks, ping
[10:46] <didrocks> tvoss: pong
[12:03] <pitti> @pilot out
[12:04] <cjwatson> pitti: Hmm, I'm trying to work out what's going on with an image build failure; currently only Mythbuntu but I suspect it'll bite other flavours / upgrades shortly
[12:04] <cjwatson> cp: cannot stat '/module-files.d/libpango1.0-0.modules': No such file or directory
[12:04] <cjwatson> cp: cannot stat '/modules/pango-basic-fc.so': No such file or directory
[12:04] <cjwatson> pitti: Do you know where those files have moved to?
[12:42] <pitti> hey cjwatson (back from lunch)
[12:44] <pitti> cjwatson: not out of hand, I don't seem to have these files anywhere; is that a  failure during package installation, or from the live-build scripts?
[12:45]  * pitti reviews recent changes
[13:06] <pitti> cjwatson: oh, is that for the udeb? ./debian/libpango1.0-udeb/usr/lib/x86_64-linux-gnu/pango/1.8.0/modules/pango-basic-fc.so and ./debian/libpango1.0-udeb/usr/lib/x86_64-linux-gnu/pango/1.8.0/module-files.d/libpango1.0-udeb.modules
[13:08] <pitti> ah no, it's from /usr/share/initramfs-tools/hooks/plymouth apparently
[13:09] <seb128> pitti, we probably need changes to plymouth from the discussion I saw on #debian-gnome about the new pango
[13:10] <pitti> ah, so that was from http://anonscm.debian.org/viewvc/pkg-gnome?view=revision&revision=36846
[13:11] <pitti> cjwatson: ^ so the separate files are included in the .so's now, part of the split/multiarchification
[13:11] <pitti> seb128: right, seems we can drop all this
[13:12]  * pitti verifies that the pango library itself is in the initramfs
[13:12] <pitti> yes it is, and I can reproduce the error with update-initramfs -u
[13:12]  * pitti uploads fix
[13:16] <cjwatson> pitti: it's from update-initramfs in a livefs build
[13:16] <cjwatson> pitti: right - thanks
[13:19] <pitti> cjwatson: ok, verified that plymouht still displays text correctly now (I added a bogus block device to wait for into /etc/fstab)
[13:21] <pitti> argh, /me uses the actual source this time instead of the outdated UDD branch
[13:25] <pitti> cjwatson: ok, verified that plymouht still displays text correctly now (I added a bogus block device to wait for into /etc/fstab)https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/ \o/
[13:26] <pitti> yolanda: ah, your tests are trickling into https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/
[13:26] <pitti> yolanda: most of them succeed, except clamav
[13:27] <yolanda> :(
[13:27] <pitti> dsc0t-clamd          FAIL non-zero exit status 52
[13:27] <pitti> there's no output at all from this
[13:28] <pitti> bbl, need to head out for some errands
[13:29] <yolanda> locally works for me, do you have any idea why it fails?
[14:41] <mitya57> pitti: wow, you managed to reduce the queue by half — very nice!
[15:11] <pitti> bdmurray: bah, with the "today" datetime fallback I now get "TypeError: can't compare offset-naive and offset-aware datetimes"
[15:11] <pitti> bdmurray: would you have any idea how to make this work properly?
[15:45] <fhf> Hi all I created new bazaar branch but I cant compile program using bzr builddeb -- -us -uc it gives following error: bzr: ERROR: Unable to find the needed upstream tarball for package; but there is no upstream I created package myself. Could any1 help?
[22:05] <bjsnider> how does the multiarch directory structure get implemented? should it work in ppa packages?
[22:05] <cjwatson> It doesn't care about the package's origin
[22:06] <cjwatson> http://wiki.debian.org/Multiarch/Implementation
[22:11] <bjsnider> ah, i think i know what was wrong. compat 7 instead of 9
[22:16] <cjwatson> bjsnider: Do review the entirety of that wiki page, or at least the section relevant to your style of packaging; converting to multiarch requires care