[09:58] <dholbach> good morning everybody and welcome to another MOTU Q&A session!
[09:59] <dholbach> I think we'll start again with a round of introductions
[09:59] <dholbach> I'm Daniel Holbach, been MOTU for quite a long time already, am trying to make becoming a MOTU easier and to make Ubuntu Universe rock even harder
[10:00] <norsetto> I'm Cesare Tirabassi, fresh MOTU
[10:01] <dholbach> ... and great contributor :-)
[10:01] <lool> I'm Loc Minier, would like to become MOTU
[10:01] <norsetto> and living proof that anybody can become a MOTU :-)
[10:01] <dholbach> norsetto: hahaha :)
[10:01] <dholbach> lool: great to have you around
[10:01] <dholbach> who else do we have?
[10:02] <slangasek> I'm Steve Langasek, MOTU wannabe
[10:02] <dholbach> heya slangasek, hey \sh
[10:02] <dholbach> anybody else? :)
[10:03] <dholbach> ok... seems we have only people around who are quite familiar with packaging already
[10:03] <dholbach> do you have any questions yourself?
[10:03] <dholbach> maybe about processes or how the MOTU team deals with things?
[10:04] <lool> Yes; I'd like to know how build failures on buildd should be handled and why I receive such notices
[10:04] <lool> For example I received two build failures for synaptic; it seems one arch was set to Needs-Build again (hppa IIRC)
[10:05] <dholbach> good question
[10:06] <dholbach> Soyuz (the buildd part of Launchpad) sometimes sends out build error mails when build-deps can not be properly installed, in a lot of cases this is not your fault at all
[10:06] <dholbach> that's something the Soyuz folks should fix, it's a bit annoying to have to check the buildlog before just deleting the error mail
[10:06] <lool> Am I supposed to do something with the notice?
[10:07] <slangasek> roll it up and hit lamont over the head with it ;)
[10:07] <dholbach> If you figured out that it's not your fault, no :)
[10:07] <lool> Hehe
[10:07] <lool> I wonder whether other bug reporters get similar spam and why?
[10:07] <norsetto> lool: we all get ......
[10:07] <lool> (I didn't prepare the synaptic upload, I only reported a bug)
[10:08] <dholbach> lool: oh?
[10:08] <lool> Ah wait I did
[10:08] <dholbach> lool: maybe that's part of the ChangelogClosesUbuntuBug thing?
[10:08] <lool> mvo didn't replace my name when he added his changes
[10:08] <dholbach> oh good *phew* :-)
[10:08] <dholbach> right
[10:08] <lool> Ok, I'm relieved as well
[10:09] <dholbach> in any case it's a good idea to talk to the folks on #launchpad if anything like that creeps up and is not explicable
[10:10] <dholbach> any other questions?
[10:10] <dholbach> do we have somebody here who's new to packaging and would like to benefit from the packaging experience we have gathered in #ubuntu-classroom right now? :)
[10:10] <dholbach> a package review? build problem? something?
[10:11] <lool> I have another question about attaching debdiffs to bug reports; is it ok to use "UNRELEASED" in the target dist or should I use gutsy?
[10:12] <dholbach> lool: I personally would use 'gutsy' and also (LP: #123456)
[10:12] <dholbach> that way it's just a matter of applying it, trying and uploading it
[10:12] <dholbach> I personally find UNRELEASED only useful for VCS commits
[10:12] <dholbach> lool: is that common for sponsored uploads in Debian?
[10:12] <lool> What do you mean by "and also (LP: #123456)"?  You mean instead of "; LP: #123456." which I used?
[10:13] <dholbach> oh, no - that's not what I referred to
[10:13] <dholbach> "LP: #123456." should be fine too
[10:13] <slangasek> dholbach: not IME; I agree with you that UNRELEASED is only useful when you're sharing around something in an intermediate state
[10:13] <lool> dholbach: It's just that I saw a sponsor requesting an updated debdiff with s/UNRELEASED/gutsy and wondered whether this was a strict requirement
[10:13] <dholbach> I just meant that if you make use of ChangelogClosesUbuntuBug and specify the upload target it's less work for the sponsor
[10:13] <lool> Ok; naurally I close bugs in changelogs
[10:14] <dholbach> lool: it's not strict afaik
[10:14] <norsetto> I would say its good practice though
[10:14] <dholbach> that's great - it's mainly new contributors who forget to use it, but you all know how to use it :-)
[10:15] <dholbach> hey adam_b - how are you doing?
[10:15] <dholbach> adam_b: here for the MOTU Q&A session?
[10:15] <lool> Ok; I have a question about bug states when reporting: I think I now have the bug triaging capability, but I'm new to it and I'm sometimes in doubt with bug states: should I set a bug to "confirmed" after I report it?
[10:15] <adam_b> dholbach: I'm doing ok, yep thought I might listen in
[10:15] <norsetto> lool: no, we should never confirm our own bugs
[10:15] <lool> (In order to avoid bug triage)
[10:15] <dholbach> adam_b: rock on
[10:16] <dholbach> adam_b: if you have any questions regarding packaging, becoming a MOTU or something else - just ask :)
[10:16] <dholbach> lool: in some cases it's OK to do that - I think pitti's requestsync script for example sets to 'confirmed' automatically
[10:17] <dholbach> but the archive admins will recognize your name on the bug report anyway and probably know that you know what you're doing
[10:18] <dholbach> any other questions?
[10:18] <lool> Hmm bash tells me requestsync is in devscripts, but I have devscripts and no requestsync script
[10:18] <dholbach> lool: thanks for that - I'll tell mvo to update command-not-found-data
[10:18] <dholbach> lool: it moved to ubuntu-dev-tools
[10:19] <lool> Ok, thanks
[10:19] <adam_b> dholbach: there's a package from debian 'mapnik' that is half in ubuntu, just wondered why that might be? there is .gz's but no .debs
[10:19] <dholbach> adam_b: ok, let's take a look at http://launchpad.net/ubuntu/+source/mapnik together
[10:20] <dholbach> it seems the source for mapnik 0.4.0-2 arrived in Ubuntu alright
[10:20] <adam_b> cool
[10:20] <dholbach> if you look at https://launchpad.net/ubuntu/gutsy/+source/mapnik/0.4.0-2
[10:20] <dholbach> you will find that it failed to build on all architectures
[10:20] <dholbach> let's take a look at the build logs
[10:21] <adam_b> failed to build
[10:21] <dholbach> python scons/scons.py PROJ_INCLUDES=/usr/include PGSQL_INCLUDES=/usr/include/postgresql PROJ_LIBS=/usr/lib DESTDIR=/build/buildd/mapnik-0.4.0/debian/tmp PREFIX=/usr BIDI=yes PYTHON=/usr/bin/python2.5 --clean
[10:21] <dholbach> scons: Reading SConscript files ...
[10:21] <dholbach> Checking for main() in C library m... no
[10:21] <dholbach> Could not find header or shared library for m, exiting!
[10:21] <dholbach> make: *** [clean]  Error 1
[10:21] <dholbach> a scons build issue, it seems
[10:21] <adam_b> its cpp app and build thinks its c?
[10:22] <adam_b> oh no next line
[10:23] <dholbach> it has problems in Debian as well, it seems
[10:23] <slangasek> why do you say that? it's up-to-date on all archs in Debian
[10:24] <lool> dholbach_: Missed some lines?
[10:24] <adam_b> when I build it in a gutsy chroot I have to build with sudo python scons/scons GDAL_INCLUDES=/usr/include/ install
[10:25] <dholbach_> adam_b: you shouldn't have to use sudo - try fakeroot
[10:25] <adam_b> ok
[10:25] <adam_b> even for the install part?
[10:26] <slangasek> only for the install part
[10:26] <dholbach> slangasek: I saw this http://bjorn.haxx.se/debian/testing.pl?package=mapnik
[10:26] <slangasek> for the non-install part, you should deliberately avoid using fakeroot or sudo, to make sure the package builds cleanly as a normal user
[10:27] <slangasek> dholbach: well, "waiting for boost" isn't a bug in mapnik
[10:27] <lool> Here it cleans fine; perhaps it's a missing build-dep
[10:27] <slangasek> (hmm, I immediately want to retract that comment after saying it, clearly depending on boost /is/ a bug ;)
[10:31] <adam_b> so in ububut build its looking for 'm' which is math.h (in SConstruct)
[10:33] <dholbach> I'm afraid I can't offer an answer to this one
[10:34] <adam_b> fakeroot gives: scons: *** [/usr/local/lib/libmapnik.so]  /usr/local/lib/libmapnik.so: Permission denied
[10:35] <dholbach> upstream have received a similar report: http://trac.mapnik.org/ticket/14 - but it's not of much help
[10:35] <slangasek> adam_b: then you're missing the DESTDIR=$(CURDIR)/debian/tmp from the original
[10:38] <dholbach> I think it might make sense to raise awareness of this failing to build on ubuntu-devel-discuss@lists.u.c
[10:39] <dholbach> not sure we'll find an answer right here, right now
[10:39] <dholbach> do we have any other questions?
[10:40] <dholbach> adam_b: did you start to actively dive into MOTU things already?
[10:43] <adam_b> dholbach: nope, just contemplating writing an app that will use mapnik
[10:43] <dholbach> adam_b: ahh nice
[10:43] <dholbach> hey huats
[10:44] <huats> hey
[10:44] <huats> dholbach: what a surprise to see you here
[10:44] <dholbach> welcome huats, another soon-to-be-MOTU ;-)
[10:44] <huats> dholbach: ;-)
[10:44] <dholbach> huats: do you have any questions? anything we could take a look at together?
[10:44] <huats> dholbach: yes I have
[10:44] <dholbach> rock on
[10:44] <dholbach> :-)
[10:44] <huats> I am searching it :-)
[10:45] <dholbach> I knew we could count on huats :-)
[10:45] <huats> alwasy count on me where there are questions to ask
[10:45] <dholbach> hehe
[10:46] <huats> it is related to bug #137513
[10:46] <dholbach> http://launchpad.net/bugs/137513
[10:46] <huats> ubotu is down ?
[10:46] <ubotu> Sorry, I don't know anything about is down ? - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[10:46] <lool> (Just for the record: I don't get the failure on mapnik in pbuilder)
[10:47] <norsetto> bug 137513
[10:47] <huats> the last comment from pkern bothers me a bit...
[10:47] <dholbach> lool: me neither
[10:47] <huats> hey norsetto
[10:47] <norsetto> huats: hola, I have some info you you (later)
[10:47] <dholbach> lool: we had weird scons problems in sbuild (at least I think so) before
[10:47] <huats> norsetto: ?
[10:48] <dholbach> huats: it's best to ask asac about that
[10:48] <norsetto> huats: sorry, for you
[10:48] <huats> norsetto: ok
[10:48] <huats> dholbach: ok
[10:48] <dholbach> huats: I don't know about a policy decision on iceweasel in package names
[10:49] <huats> it is the only one apparently...
[10:49] <dholbach> right
[10:49] <dholbach> in debian there are lots of iceweasel-* binary packages
[10:49] <dholbach> in ubuntu it would be just this one
[10:49] <dholbach> so best to check with asac and ask if it should be renamed to mozilla-torbutton or firefox-torbutton
[10:50] <huats> dholbach: ok
[10:50] <huats> dholbach: I will
[10:50] <dholbach> super thanks
[10:51] <dholbach> anything else? anything more we can review? :)
[10:51] <huats> I have a second question to fire : can you explain me a bit the process to transmit bug fixes to debian... I know norsetto tried to many times, but I am sure it is someting interesting for many of us
[10:52] <dholbach> soren wrote submittodebian (in ubuntu-dev-tools) maybe that'd help with it?
[10:52] <huats> oh
[10:52] <huats> great
[10:52] <huats> I'll have a look
[10:53] <norsetto> dholbach: I think huats has some problems about what should be sent to Debian, in particular re. debdiff
[10:53] <huats> norsetto reads my mind
[10:53] <dholbach> right... I think the diff the debian maintainer could apply to the current source in sid would be most useful
[10:54] <dholbach> but we have two experienced Debian folks here, ... :-)
[10:54] <norsetto> three ....
[10:56] <dholbach> slangasek, lool: huats just asked " can you explain me a bit the process to transmit bug fixes to debian... I know norsetto tried to many times, but I am sure it is someting interesting for many of us" - do you have an answer for that?
[10:57] <huats> dholbach: if you want we can have a look to a precise bug entry to see what is sendable to debian...
[10:57] <dholbach> submittodebian is particularly useful for merges it seems
[10:57] <lool> The best case would be to confirm the bug is still present in Debian by actually running a Debian and checking the bug and patch, then using reportbug to report the bug with the patch; that's probably a long process for simple bugs though
[10:57] <dholbach> submittodebian has the advantage that you can edit the diff
[10:57] <dholbach> and remove stuff that is ubuntu specific
[10:57] <lool> So I guess one simpler case is simply checking whether the packages were patched in Debian or not
[10:58] <huats> ok
[10:58] <slangasek> dholbach: I was refraining from comment because my views on how Ubuntu should send bugfixes back to Debian seem to be at odds with the prevailing opinion within Ubuntu :)
[10:58] <slangasek> but as a Debian maintainer, if someone in Ubuntu has made a change that they think fixes a bug, I would like to hear about it directly through the Debian BTS
[10:58] <dholbach> slangasek: right, but given the question from somebody who wants to submit a patch to the debian bts? :)
[11:00] <slangasek> btw, the actual submittodebian script seems to be missing from current ubuntu-dev-tools, only the manpage is there
[11:00] <dholbach> oh?
[11:00] <huats> dholbach: so I'll use the debian BTS ...
[11:00] <dholbach> slangasek: I'll fix that in a sec - there's another change to it pending
[11:01] <dholbach> (need to talk to Sren about that)
[11:02] <dholbach> ok, asked him
[11:02] <dholbach> if there are no more questions, this is the end of this MOTU Q&A session
[11:02] <dholbach> we'll have one next week - I'll just ask for a proposal of a different time before :-)
[11:03] <dholbach> thanks everybody for your questions and answers
[11:03] <dholbach> have a nice day
[11:03] <huats> dholbach: thanks to you
[11:03] <lool> Thanks!
[11:04] <slangasek> cheers