[00:00] <PasNox> thank u for all your help guyz :)
[00:00] <SpamapS> slangasek: I think we should disable that test. It looks to be non-deterministic based on the comments from Kristofer Pettersson
[00:00] <SpamapS> slangasek: Stewart Smith (very highly respected mysql internals dev) is calling to reopen the bug too near the bottom
[00:01] <SpamapS> slangasek: but yeah, retry the build, there's a chance it will work
[00:02] <PasNox> and for the python package
[00:02] <slangasek> SpamapS: ok
[00:02] <PasNox> python-qt4-fresh1 / python-qt4-fresh-dev or python-qt4-fresh / python-qt4-fresh-dev ?
[00:03]  * SpamapS spies something wicked in the way 5.5 builds its libraries..
[00:03] <SpamapS> lrwxrwxrwx root/root         0 2011-11-09 15:53 ./usr/lib/libmysqlclient.so -> libmysqlclient.so.16
[00:04] <slangasek> hehwhat
[00:04] <slangasek> is that courtesy of debian/rules?
[00:04] <SpamapS> I am not sure
[00:04] <SpamapS> mysql has always had.. problems.. with building their libraries
[00:05] <slangasek> I know that the symlinks in -5.1 were being done via debian/rules instead of trusting the upstream build system to do it, so maybe fixes are needed there
[00:06] <slangasek> mmnope
[00:06] <SpamapS> entirely possible that the upstream forgot to bump SOVER properly
[00:09] <SpamapS> slangasek: possibly need to resurrect the thing that does the symlink manually though.. :(
[00:09]  * slangasek nods
[00:10]  * SpamapS is so tired of rebuilding mysql.. :-P
[00:15] <SpamapS> slangasek: AHA! ./debian/libmysqlclient-dev.links:usr/lib/libmysqlclient.so.16	usr/lib/libmysqlclient.so
[00:15] <SpamapS> it is debian/rules fault.. sort of ;)
[00:16] <slangasek> score
[00:19] <SpamapS> hrm.. I wish I'd kept that last chroot around.. such a tiny problem. :-P
[00:29]  * TheMuso has a double take at the download speed from cdimage with a DVD iso to Australia.
[00:29] <TheMuso> I've never pulled images from cdimage this fast before.
[00:31] <StevenK> SpamapS: "increasingly convinced that @Percona & Ubuntu are the only people who ever regularly run the MySQL test suite and naively expect it to pass."
[00:33] <SpamapS> StevenK: we're just a bunch of silly gits aren't we? ;-)
[00:33] <StevenK> Haha
[00:35] <slangasek> "naively expect it to pass" is a funny way to spell "demand quality control from a database server"
[00:35] <StevenK> slangasek: That's from Stewart Smith, he's allowed to be bitter.
[00:36] <slangasek> I also expect the php test suite to pass
[00:36] <slangasek> even though I know it has test cases that care which side of Greenwich you're on :)
[00:36] <StevenK> Hah
[00:36] <SpamapS> actually
[00:36] <SpamapS> 5.4 has fixed that
[00:37] <StevenK> slangasek: Twisted sets the timezone to UTC+0530 for its test suite for exactly that point.
[00:37] <SpamapS> http://ci.qa.php.net/ btw
[00:39] <SpamapS> the PHP release process has been formalized and the tests must pass now. :-P
[00:39] <StevenK> I wonder why that is. :-P
[00:39] <StevenK> *cough*
[00:39] <slangasek> does that include the unixtojd test that was written wrong? :)
[00:39] <SpamapS> I believe its been ammended
[00:39] <slangasek> (and correctly verifies that the function returns the wrong answer it was programmed to return? :)
[00:40] <slangasek> ok :)
[00:40] <SpamapS> haha probably tho ;)
[00:40] <SpamapS> still , its a happy thing that there is actual CI for PHP now
[00:41] <SpamapS> and actual guarantees for backward compatibility
[00:41] <SpamapS> just don't ask them about unicode. ;)
[01:11] <SpamapS> Ugh, mysql has really gone and #%!@'d up libmysqlclient_r ... instead of just leaving it out and letting people update their build scripts.. :p
[01:12] <SpamapS> lrwxrwxrwx root/root         0 2011-11-09 16:39 ./usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18 -> libmysqlclient.so
[01:12] <SpamapS> lrwxrwxrwx root/root         0 2011-11-09 16:39 ./usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18.0.0 -> libmysqlclient.so
[01:12] <SpamapS> *doh*
[01:12]  * SpamapS ponders just removing it so builds will fail and we can fix them
[01:16]  * SpamapS does just that
[01:20] <slangasek> not sure how ./usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18 would prevent a build from failing anyway
[01:24] <SpamapS> slangasek: that would make libmysqlclient18 depende on libmysqlclient-dev
[01:24] <SpamapS> slangasek: technically anyhow.
[01:24] <slangasek> oh, well obviously the symlink as-is is wrong
[01:24] <SpamapS> slangasek: I'm just removing it. -lmysqlclient_r is actually deprecated, may as well find them all and fix them now.
[01:24] <slangasek> I just don't see any reason having it at all would help anyone
[01:25] <slangasek> because -lmysqlclient_r wouldn't match libmysqlclient_r.so.18 anyway
[01:25] <SpamapS> slangasek: right, at one time libmysqlclient_r.so pointed at libmysqlclient_r.so.18
[01:29] <SpamapS> It will mean that anything that we change from -lmysqlclient_r to -lmysqlclient will have to build-dep on libmysqlclient-dev ( >> 5.5.17-2 ) so that they don't accidentally backport and lose thread safety.
[01:33] <slangasek> yep
[01:34] <SpamapS> ok.. enough building ... I'm off to see the wonderful wizard of Trader Joes
[02:28] <Riddell> highvoltage: we would like LTS for 5 years, it'll be up to the tech board if we get it of course
[03:28] <nigelb> Yay chrisccoulson! http://blog.mozilla.com/meeting-notes/archives/702
[03:28] <nigelb> "Chris has done a ton of work with integrating both Thunderbird and Firefox nicely with Ubuntu. He’s a machine. "
[03:56] <TheMuso> D/c
[05:16] <pitti> Good morning
[05:17] <ion> o hai
[05:18] <pitti> lool: thanks; so I guess that was the same problem as  last time then?
[05:18] <pitti> slangasek: yes, it should be consistent; chances are very high that it just needs a rebuild, I fixed an instance of this in the last upload
[05:45] <micahg> pitti: looks like we might not need a FIrefox transition for Maverick, will confirm next week
[05:45] <pitti> micahg: oh, 3.6 will be supported longer?
[05:46] <micahg> ATM, looks like until Apr 2012
[05:46] <pitti> that should be enough indeed, nice
[06:04] <broder> awesome. i apparently earn the idiot award of the day for uploading a source-change backport...and forgetting to make the source change
[06:06] <broder> pitti: can you at least reject the natty upload for znc? :)
[06:06] <pitti> broder: urgh, sorry, didn't spot that; reupload, and I'll process right away?
[06:06] <pitti> broder: done
[06:07] <micahg> broder: debdiff is your friend :)
[06:08] <broder> i know! and i think i decided not to look because it was such a simple change and how could i possibly have screwed it up :-/
[06:08] <pitti> broder: it'll just FTBFS, right?
[06:08] <pitti> (or depwait)
[06:11] <broder> pitti: FTBFS - <= oneiric's swig2.0 conflicts with swig
[06:13] <broder> pitti: thought since i'm actually fixing this, i'm going to make sure the natty one depwaits until the pending no-change backport of swig2.0 is processed
[06:14] <broder> pitti: double-checked, and reuploaded. should show back up in your queue mometarily
[06:14] <broder> sorry about that!
[06:14] <pitti> thanks!
[06:19] <broder> ...huh, oh dear. the regexps i wrote for backport-helper totally don't work :)
[06:19] <broder> "Please backport activity-log-manager (0.8.0-1) from precise" => backport-helper gets "activity" as the package name
[07:46] <lool> pitti: it looks like last time
[07:46] <lool> pitti: but then, I don't have a lot of caracterizing evidence to claim it's the same bug
[07:46] <pitti> lool: so I'll revert that patch once again; could you check if it's working then?
[07:46] <lool> pitti: if you'd like, we can try debugging this, but I wouldn't mind some handholding
[07:46] <lool> pitti: Sure
[07:50] <pitti> lool: ok, 175-0ubuntu0test2 uploaded; I'll ping you when it's built
[07:50] <pitti> so let's confirm first that it's that part of the code
[07:56] <dholbach> good morning
[08:24] <lool> pitti: test2 booted fine
[08:25] <pitti> lool: thanks
[08:55] <Daviey> @pilot in
[09:15] <dholbach> @pilot in
[09:15]  * dholbach hugs Daviey
[09:24] <dholbach> hum, can somebody help me with http://paste.ubuntu.com/734002/ please?
[09:25] <dholbach> not quite sure what to do about "bzr: ERROR: None 0.3.4 was not found in <PristineTarSource at http://bazaar.launchpad.net/%7Eblair/ubuntu/precise/rbtools/rbtools-fix-886436/>."
[09:26] <pitti> hm, perhaps the branch didn't use merge-upstream/
[09:26] <pitti> ?
[09:26] <dholbach> probably
[09:26] <Laney> how do you see the raw pristine-tar data in udd branches?
[09:26] <pitti> you can't see in http://bazaar.launchpad.net/~blair/ubuntu/precise/rbtools/rbtools-fix-886436/revision/3, though
[09:27] <pitti> you could check out the branch and try bzr bd -S
[09:27] <pitti> if that works, then it's a bug in merge-package (not taking new pristine-tars)
[10:09] <gaspa> barry: can you take a look at: http://pastebin.ubuntu.com/734039/ ? (this works in debian sid and in 10.10, but not in Oneiric, nor in Precise)
[10:11] <geser> gaspa: gcc -I/usr/include/python2.7 -o pyrun pyrun.c/tmp/ccImdWA6.o -lpython2.7
[10:12] <geser> the -lpython2.7 has to come after the .o which uses it (ld --as-needed)
[10:14] <gaspa> geser: oh, as-needed,  ... and debian didn't use it yet?
[10:14] <geser> no, not yet as far as I know (but accepts patches fixing such issues)
[10:16] <gaspa> geser: ack. thanks :)
[10:26] <pitti> hmm
[10:26] <pitti> /etc/alternatives/javac -> /usr/lib/jvm/java-6-openjdk/bin/javac
[10:27] <pitti> but I have /usr/lib/jvm/java-6-openjdk-amd64/bin/javac
[10:27] <pitti> incomplete multi-arch-ification?
[10:30] <pitti> ah, bug 887077, updating
[11:05] <dholbach> can somebody please reject https://code.launchpad.net/~pallavikumarijha/ubuntu/oneiric/battery-stats/oneiric/+merge/80145?
[11:20] <dholbach> can https://code.launchpad.net/~gandelman-a/ubuntu/natty/facter/lp876130_lp732953/+merge/80276 be marked as merged please (r16)?
[11:21] <dholbach> https://code.launchpad.net/~gandelman-a/ubuntu/oneiric/facter/lp876130/+merge/80277 (r16) too
[11:24] <janimo> ricotz, hi, do we wait for newer version of clutter-gst to land in debian first? We are  2 minor releases behind upstream. There's a fix going into 11.10 via SRU and I wonder whether it makes more sense to just upgrade to the new version in precise instead of cherry-picking the fix as for the SRU
[11:24] <dholbach> Daviey, up until now no mid-air collisions while we're working on the queue - seems there's still enough in there ;-)
[11:33] <ricotz> janimo, hi, yeah syncing it to precise after an update in debian would be better -- is this fix actually in 1.4.4?
[11:37] <Daviey> dholbach: I'm going to continue working bottom up, ok?
[11:37] <dholbach> Daviey, sure sure
[11:38] <ricotz> janimo, http://git.gnome.org/browse/clutter-gst/commit/?id=11cce755880127565e88bd50c63c6f0b7ee6051f -- it wasnt committed to the 1.4.x branch
[11:38] <Daviey> dholbach: looks like we did have a near miss :)
[11:51] <janimo> ricotz, ah, I saw Oct 6 yesterday and assumed it was in a 1.4 release
[11:52] <ricotz> janimo, 1.4.4 isnt so important though, i guess you confirmed that this works and fixes the problem ;)
[11:52] <ricotz> since you already uploaded it
[11:53] <janimo> ricotz, indeed it fixes it
[11:53] <janimo> ricotz, so in order to comply with SRU should I just add the patch to our precise package exactly the same way?
[11:54] <dholbach> can https://code.launchpad.net/~jtaylor/ubuntu/oneiric/bitlbee/fix-879730/+merge/80498 please be marked as merged?
[11:54] <pitti> dholbach: done
[11:55] <dholbach> pitti, and the other ones above as well?
[11:55] <ricotz> janimo, yeah i guess you can do so, i will ask for this patch to get in 1,4
[11:55] <janimo> ricotz, thanks. Although they seem to consider it a sort of ABI breakage even if these may not have been very public shader variables
[11:56] <pitti> dholbach: done
[11:56]  * dholbach hugs pitti
[11:56]  * pitti hugs dholback, kein Problem
[11:56] <ricotz> janimo, ok
[12:02] <ricotz> janimo, probably there will be a 1.4.6 soon including this fix
[12:02] <janimo> ricotz, great
[12:02] <dholbach> can https://code.launchpad.net/~cldunlap1/ubuntu/oneiric/xine-lib/fix3-for-835437/+merge/78959 be rejected (fix is upstream already, and a bug in Debian already filed)?
[12:02] <pitti> done
[12:03] <dholbach> merci
[12:08] <Daviey> dholbach: are you looking at bug 881695?
[12:08] <dholbach> Daviey, I thought that one had the fix already uploaded, it was just sitting in the queue?
[12:08] <lifeless> ev: are we on for that call in ~7h ?
[12:08] <Daviey> dholbach: I haven't sniffed, i just saw your latest comment.
[12:08] <ev> lifeless: sure are!
[12:09] <lifeless> cool
[12:09] <lifeless> I'll go get some sleep :)
[12:09] <ev> enjoy :)
[12:25] <dholbach> can https://code.launchpad.net/~cldunlap1/ubuntu/oneiric/xchat/fix-for-816506/+merge/80118 be rejected?
[13:09] <jandrusk> test
[13:15] <seb128> what team is giving ubuntu series nominations rights?
[13:16] <seb128> i.e the right to nominate a bug for a serie
[13:18] <geser> isn't it ubuntu-dev?
[13:18] <pedro_> its ubuntu-drivers ^
[13:18] <seb128> geser, is that for suggesting nominations or approving?
[13:18] <geser> IIRC MOTU can nominate for packages in universe, not sure if for packages in main too (didn't use it for some time)
[13:19] <seb128> pedro_, doesn't make sense, you just said you can approve but you are not in ubuntu-drivers?
[13:23] <cjwatson> bug supervisor (ubuntu-bugcontrol) can nominate; driver (which in this context is either ubuntu-drivers or ubuntu-release I think, possibly the union) can approve
[13:24] <cjwatson> at least by my reading of the code
[13:26] <seb128> ok, I guess pedro can approve by ubuntu-release which include canonical qa team then
[13:27] <cjwatson> right
[13:27] <cjwatson> ubuntu-release is typically the series driver
[13:28] <ScottK> So developers can't?
[13:28] <ScottK> Seems off.
[13:28] <cjwatson> er, not sure, as you know it's hard to tell by experimentation
[13:28] <cjwatson> do not assume anything in particular from my attempt to divine it from the code - in particular don't assume malice!
[13:29] <seb128> do we have a definition somewhere of how nominations and targetting should work and who should have access?
[13:30] <seb128> I've some people who asked me if they should have access or not to nominations, that's what I was trying to figure
[13:30] <seb128> would it be a TB topic to get some clarification on that?
[13:31] <tumbleweed> I'm pretty sure I could approve MOTU nominations before I was on -release
[13:31] <tumbleweed> s/MOTU/universe/
[13:33] <cjwatson> yofel_: hey, I was just looking at the kalgebra build failure and noticed that you'd added libncurses-dev to the build-deps in bzr
[13:34] <yofel_> cjwatson: ah right, it didn't get uploaded yet - should I close a bug in the changelog?
[13:34] <cjwatson> yofel_: this is *a* fix, but I don't think it's the ideal fix - calgebra doesn't actually use ncurses, so it would be better to drop that linkage
[13:34] <cjwatson> yofel: would you mind if I worked on removing the ncurses requirement instead?
[13:35] <cjwatson> yofel: I don't think there's a bug, no, I was looking at the ftbfs list for main
[13:35] <cjwatson> (I was gently corrected by one of the Debian ncurses developers when I made a similar mistake in one of my packages)
[13:35] <yofel> no, as long as you send that to KDE, and notify the debian-qt-kde team about it, as they added libncurses-dev to their package too
[13:36] <cjwatson> ok, sure
[13:36] <dholbach> @pilot out
[13:41] <cjwatson> yofel: do you have the tarball location handy?
[13:42] <cjwatson> ah, never mind
[13:42] <yofel> found it?
[13:45] <cjwatson> yeah
[13:55] <cjwatson> seb128: https://bugs.launchpad.net/launchpad/+bug/174375 has the history; at this point I think you should ask Launchpad rather than the TB if you want clarification
[13:56] <seb128> cjwatson, thanks
[13:57] <brendand> can someone point me to the page on the requirements for proposing an SRU?
[13:58] <seb128> brendand, https://wiki.ubuntu.com/StableReleaseUpdates
[14:07] <jdstrand> cjwatson: speaking of that... I see this comment from you in the bug "Pete has approved canonical-qa's membership of ubuntu-release, so I have gone ahead and removed canonical-qa from ubuntu-drivers."
[14:07] <jdstrand> cjwatson: (hi btw)
[14:08] <jdstrand> cjwatson: it would be good if the security team was part of one of these groups, since we routinely use release tasks for tracking security bugs
[14:09] <jdstrand> cjwatson: we've approached skaet, but she said something about needing to talk about it with people. I am a driver like pete is, I wonder if we can actually just do it if I say my team needs it?
[14:09]  * jdstrand is not trying to circumvent anything of course, just want my team to not be blocked
[14:10] <jdstrand> right now, jjohansen is unable to perform his duties on his own because of this
[14:11] <jdstrand> cjwatson: telling me you don't want to be involved and keep dealing with skaet is a perfectly acceptable answer :)
[14:13] <hallyn> cjwatson, I'm thinking of syncing syslog-ng.  Just pinging you bc you did the last commit.  Had you started that?
[14:14] <cjwatson> jdstrand: I don't want to be involved but surely you should deal with the TB not with skaet, since the TB is the owner of ubuntu-drivers and skaet isn't
[14:14] <cjwatson> I mean I don't want to be involved personally
[14:15] <jdstrand> I understand
[14:15] <jdstrand> we approached her for the ubuntu-release bits
[14:15] <cjwatson> oh, ubuntu-release not ubuntu-drivers
[14:15] <jussi> Hrm, I asked this elsewhere this morning, but no one seemed to know. After marks keynote, Is there a part of canonical looking into phones, phone applications etc for ubuntu? and if so, who are the relevant people?
[14:15] <cjwatson> I do not think we should artificially add even more people to ubuntu-release, TBH ...
[14:16] <cjwatson> if you can't do what you want with the privileges you have then perhaps we should open a discussion with LP about it
[14:16] <jdstrand> cjwatson: yeah, figured ubuntu-drivers was too much. really, I think ubuntu-security should just be one of the groups allowed to create tasks, but that is probably a slow fix
[14:16] <cjwatson> the problem is that a slow undesigned accretion of privileges was the position we were in before
[14:16] <cjwatson> people understood it even less
[14:17] <jdstrand> I just hope it doesn't take months/years to fix...
[14:17]  * jdstrand files a bug
[14:17] <cjwatson> I mean, it's possible to add ubuntu-security if we need to I guess
[14:18] <cjwatson> I'd just like to understand what we're doing and plan for a better fix
[14:18]  * jdstrand nods
[14:18] <cjwatson> because if we just turn ubuntu-release into a copy of the mess that ubuntu-drivers used to be, we won't have gained a whole lot
[14:18] <jdstrand> the bug is the correct thing to do. I'll file it and maybe we can workaround in the meantime
[14:18] <cjwatson> hallyn: if the libdbi-dev fix is in Debian now, feel free to sync, otherwise merge; I'm not working on it
[14:19] <hallyn> cjwatson, thanks
[14:19] <jdstrand> cjwatson: thanks
[14:25] <seb128> cjwatson, jdstrand: do we have any Ubuntu definition of who in theory should have access to nominations?
[14:25] <seb128> out of the launchpad groups and teams handling issue
[14:29] <cjwatson> seb128: not AFAIK
[14:29] <jdstrand> I just filed bug #888568 to expand any existing definition
[14:29] <cjwatson> we have lots of opinions
[14:29] <cjwatson> some of them may even be the same
[14:29] <jdstrand> and I added one more :)
[14:30] <seb128> cjwatson, who would be qualified to come with a definition, TB?
[14:30] <cjwatson> I guess.
[14:30] <seb128> thanks
[14:33] <jdstrand> seb128: if you are crafting correspondence to the TB, feel free to reference my new bug :)
[14:33]  * jdstrand likes piggybacking
[14:34] <seb128> jdstrand, ok, I've put it on my list but I will probably don't get to it this week since tomorrow is off there and I've still work I want to do today, but maybe next week ;-)
[14:35] <jdstrand> seb128: sure thing. I would like to see the larger issue fixed, but I'm currently focused on getting something going so my team can do their work. as such, your timeframe works fine for me :)
[14:36] <seb128> jdstrand, right, I think we should workaround to unblock your team and then try to get a better definition of who should have access or not
[14:36]  * jdstrand nods
[15:42] <cjwatson> yofel: committed, sent upstream, forward to Debian in progress
[15:49] <nigelb> g20
[15:49] <nigelb> urgh
[16:08] <debfx> Laney, ScottK: bug #828017 has been marked as a duplicate. is there another bug that tracks the "backports can't build-depend on other backports" issue?
[16:09] <Laney> i didn't know about that issue
[16:10] <debfx> it's that way since NotAutomatic has been introduced (natty)
[16:10] <Laney> so you need to specify a version constrant
[16:12] <debfx> that doesn't help, see https://launchpad.net/ubuntu/+source/teeworlds/0.6.0-2~natty1
[16:12] <debfx> it's stuck in dep-wait
[16:12] <Laney> interesting
[16:14] <Laney> lamont: any clue ^ ?
[16:35] <ScottK> debfx: I'm not sure if it's the same thing or not.  I guess we'll know when the fix lands if teeworlds builds.
[16:53] <dr3mro> hello i have created a package with some bash scripts and python scripts the package just copy them into /usr/bin .. and i made it by debuild -S and uploaded it into launchpad by dput .. but it fails to build ??? can anyone help me ? why to build there is nothing to build
[16:55] <dr3mro> http://pastebin.com/jwDSfVX6
[16:56] <slangasek> dr3mro: you use debhelper in debian/rules, but debian/control doesn't declare this as a build dependency
[16:57] <slangasek> you can only use tools at build time that are listed as build dependencies
[16:57] <slangasek> (Build-Depends: debhelper (>= 7.0.50~)
[16:57] <slangasek> )
[16:58] <dr3mro> slangasek, but the package have no code to build just plain bash scripts
[16:59] <slangasek> dr3mro: you still have to be able to run debian/rules to output the binary package
[16:59] <dr3mro> slangasek, http://dl.dropbox.com/u/8828739/packages/nautilus_actions_etxra/nautilus-actions-extra_0.1.3-1_all.deb
[17:02] <dr3mro> slangasek, http://dl.dropbox.com/u/8828739/packages/nautilus_actions_etxra/nautilus-actions-extra_0.1.3-1.debian.tar.gz
[17:03] <slangasek> dr3mro: I'm not sure what you expect those files to tell me; I've already given you the answer to your question, which is that you need to fix debian/rules to list the correct build dependencies for your package
[17:04] <dr3mro> slangasek, i am noob and i don't know about that :) sorry .. how to do that can you explain plz
[17:04] <bjsnider> dr3mro, did you use dh_make to create build scripts?
[17:05] <slangasek> dr3mro: edit debian/control; make sure the stanza has a 'Build-Depends: ' field that includes 'debhelper (>= 7.0.50~)' as one of the values
[17:05] <dr3mro> bjsnider, yes
[17:05] <slangasek> (sorry, it's debian/control that needs fixed, not debian/rules - I misspoke)
[17:06] <bjsnider> well, then debhelper should have been added as a build-dep automatically
[17:06] <slangasek> yes, it should have
[17:06] <bjsnider> pastebin your debian/control
[17:09] <dr3mro> ok i had added it to control
[17:09] <bjsnider> that file could have other problems
[17:09] <dr3mro> http://pastebin.com/MMuLys6S
[17:10] <slangasek> dr3mro: the field name is 'Build-Depends:', not 'Build-Depend:'
[17:11] <slangasek> so the full line should be:
[17:11] <slangasek> Build-Depends: debhelper (>= 7.0.50~)
[17:11] <dr3mro> slangasek, thank you ... i will fix it
[17:12] <bjsnider> dh_make didn't create that line by itself? i don't accept that.
[17:13] <slangasek> dh_make does add the line itself
[17:14] <dr3mro> slangasek, why it succeeded to build on my system but failed on launchpad ?
[17:15] <dr3mro> It finished upload by dput .. waiting for it to appear on ppa and build
[17:15] <slangasek> because you have debhelper installed on your system
[17:16] <slangasek> whereas launchpad only installs the things that the package tells it to
[17:16] <dr3mro> slangasek, thank you it was very helpful
[17:16] <slangasek> you're welcome :)
[17:30] <dupondje> kenvandine: pitti: prepared new patches for papyon, as the current patch didn't seem to solve the issues for everybody. New patches uploaded in https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349
[17:32] <iceroot> dupondje: the issue is based on routing-issues (imo) so you cant patch that issue for all users
[17:32] <iceroot> dupondje: because on of the servers cant be reached from everyone
[17:34] <dupondje> iceroot: but now the server to be used is hardcoded to a .us based one. This works indeed fine for most people.
[17:34] <dupondje> The new patch uses the 'old' server, but follows the redirection to the server supplied by msn itself
[17:35] <iceroot> dupondje: ah ok
[17:36] <dupondje> This should be better as msn will prolly push a server near to your location
[17:37] <dupondje> Its also the patch that got included upstream and in emesene and debian
[17:37] <dupondje> and no isses reported there atm
[17:42] <iceroot> dupondje: sounds good
[17:56] <Fusionite> Hey all
[18:04] <debfx> ScottK: that commit won't fix the backports problem. that's an issue in sbuild or how sbuild is used.
[18:05] <lifeless> ev: hiya; I'm up early :>
[18:06] <ev> lifeless: hi
[18:06] <ev> ready whenever you are then
[18:06] <lifeless> will ping shortly then
[18:06] <ev> cool
[18:20] <dr3mro> .
[18:20] <dr3mro> how to create a recipe on launchpad to build app against gtk 3 .. lets say equevalent to ./configure --gtk3
[18:27] <debfx> Laney, ScottK: I've opened a new report: bug #888665
[18:44] <mterry> slangasek, libmysqlclient-dev is installing into /usr/lib/${DEB_HOST_MULTIARCH}/libmysqlclient.so (literal characters)
[18:44] <slangasek> hmm
[18:44] <slangasek> well I'll just fix that then, shan't I
[18:44] <mterry> :)
[19:04] <lifeless> ev: http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops/trunk/view/head:/oops/config.py
[19:49] <broder> infinity: just fyi re bug #888665, i honestly don't think anybody has particularly well-formed expectations for how the backports pocket is *supposed* to work these days (see also last week's TB discussion), so as long as there's some way to pull in build-deps from backports, i'm not sure the exact behavior on the corners is that important
[19:49] <broder> which is really a long winded way of saying that i think overriding NotAutomatic for builds would be fine
[19:54] <slangasek> mterry: mysql-5.1 fixed
[19:58] <micahg> broder: I think I'd almost prefer it to behave like experimental where the dependency had to be explicit to minimize the requirement of installing packages from backports on users' systems
[19:58] <broder> micahg: i think that's a better solution, but i'd rather fix the issue quickly than fix it better
[19:58] <broder> and try to do that in the longer term
[19:58] <micahg> broder: the fix is to bump the versioned dependency in the build-depends when backporting :)
[19:59] <broder> no, that's not sufficient, because sbuild's resolver is too dumb
[20:00] <broder> micahg: the problem is that sbuild's apt resolver just takes the un-versioned build-deps and passes them to apt-get install
[20:00] <broder> you can see it if you look at a failing build log: https://launchpadlibrarian.net/84871107/buildlog_ubuntu-natty-i386.teeworlds_0.6.0-2~natty1_MANUALDEPWAIT.txt.gz
[20:01] <micahg> broder: ugh, is that the case with a more current sbuild as well?
[20:02] <broder> the bug description makes it sound that way
[20:02] <broder> oh wait, no, i think they fixed it
[20:02] <broder> it does the pbuilder thing where it generates a dummy package
[20:02] <broder> so that would work
[20:03] <broder> i'll mention that on the bug
[20:06] <mterry> slangasek, thanks!
[20:29] <chrisccoulson> slangasek, fixed your issue now (bug 888307)
[20:29] <chrisccoulson> we disabled this new feature entirely in the end :)
[20:30] <tumbleweed> broder: currents sbuild has 3 different resolvers, you can choose between them. lp sbuild in an old version of the internal resolver
[20:30] <broder> tumbleweed: right. infinity said that there were plans to upgrade lp's sbuild
[20:30] <tumbleweed> well, people have been talking about that for years, but apparently that's non-trivial
[20:31] <broder> i'm sure
[20:32] <slangasek> chrisccoulson: ok :)
[20:56] <sebner> slangasek: is it safe to upgrade to precise atm?
[20:59] <hallyn> Is there a standard command one can use to say "add release-updates and release-security to /etc/apt/sources.list" ?  Or does that need to be done by hand?
[21:00] <slangasek> sebner: somewhat? :)
[21:01] <slangasek> hallyn: software-properties-gtk lets you do it interactively; not sure if there's a commandline version
[21:01] <hallyn> slangasek, ok, thanks
[21:02] <sebner> slangasek: sufficient for me :D
[21:02] <broder> hallyn, slangasek: software-properties is backed by a python library that could probably be scripted
[21:04] <slangasek> broder: so the answer to "is there a standard command" is "no" :)
[21:04] <broder> oh, sure
[21:08] <hallyn> it definately sounds worth doing at some point
[21:08] <hallyn> but for now the files I'm working with are guaranteed to be simple enough that it makes sense to do it by hand :)
[21:08] <hallyn> thanks
[22:23] <Daviey> @pilot out
[22:23] <Daviey> oops
[22:46] <angelo-c> inifinity: are you here?
[22:47] <SpamapS> infinity is always "here"
[22:48] <angelo-c> great news! hi spamaps!
[22:48] <angelo-c> I have to test the bugs infinity helped me to submit
[22:48] <angelo-c> I'm asking an advice on that
[22:49] <MDesigner> hey guys, who is head of the audio team?
[22:49] <MDesigner> I'd like to contribute
[22:50] <MDesigner> I actually asked before, but forgot the link. there was a page w/ someone's name on it..
[22:50] <infinity> SpamapS: I am?
[22:51] <SpamapS> infinity: you are technically imaginary.. but.. every time we divide by zero, there you are.
[22:52] <infinity> angelo-c: The oneiric-proposed upload is still sitting in the queue waiting for the SRU team to let it in.
[22:52] <slangasek> MDesigner: I don't know that we have an "audio team" per se, but TheMuso is usually the right person to talk to
[22:52] <infinity> angelo-c: So, not much for you to test right now. ;)
[22:52] <slangasek> (particularly at this time of day)
[22:53] <infinity> SpamapS: Well, stop dividing by zero and maybe I could finally get some sleep?
[22:53] <MDesigner> slangasek: actually I found this- https://launchpad.net/~ubuntu-audio-dev
[22:54] <slangasek> MDesigner: yes, TheMuso is listed as the sole administrator of that team :)
[22:54] <MDesigner> ok, I'll come back when he's not idle. or maybe drop an email
[22:54] <TheMuso> I am here.
[22:55] <TheMuso> Please read the message at the top of that team page.
[22:55] <TheMuso> Help is welcome however.
[22:55] <MDesigner> actually.. I just wanted to contribute a new startup sound for Ubuntu
[22:55] <TheMuso> But that team has direct access to packaging that goes into the Ubuntu archives.
[22:55] <TheMuso> MDesigner: Oh right. You might want to talk to the design/dx team about that, as it probably needs to be run by them. That is, if you want to get it into Ubuntu proper.
[22:55] <TheMuso> Otherwise, I'd just make a sound theme deb availab eiwth your ifferent startup sound.
[22:56] <MDesigner> ok. who do I talk to?
[22:56] <angelo-c> infinity: it's advisable to test for precise?
[22:56] <TheMuso> I am not sure who you should talk to re design team.
[22:57] <MDesigner> hmm
[22:58] <infinity> angelo-c: Testing the precise version would be nice.  But testing the SRU version is essential (or, will be once it's accepted)
[22:58] <angelo-c> infinity: if yes, if I download a cd image and install to a vm, I can download the latest version of xoscope with patch applied?
[22:58] <infinity> angelo-c: Yeah, xoscope in precise will be with the patch applied.
[22:59] <infinity> angelo-c: And if you can verify it's fixed in precise, that would be nice.
[22:59] <angelo-c> infinity: when the package will be ready, i'll test for oneiric as soon as possible
[23:00] <angelo-c> infinity: I think it doesn't should be too much difficult, I'm downloading a daily cd image of precise, when done, i'll install inside the live cd, clean and simple!
[23:00] <infinity> angelo-c: Danke.  The SRU team will post a comment to the bug when they accept it and ask for testing.
[23:00] <angelo-c> great, i'm impatient!
[23:01] <angelo-c> infinity: great, i'm impatient!
[23:01] <MDesigner> ok I'll try to find a contact for the design team
[23:02] <TheMuso> MDesigner: I believe there is an ayatana design mailing list, perhaps thats the best place to ask.
[23:02] <TheMuso> No other idea where to ask I'm affraid.