[06:45] <bilalakhtar> help! How do I upgrade a package to new upstream version using bazaar branches?
[06:46] <bilalakhtar> does debcommit handle that properly?
[07:14] <kronos> slangasek: poke
[07:14] <kronos> slangasek: was looking at binutils-z80 ftbfs
[07:14] <kronos> slangasek, http://launchpadlibrarian.net/49755201/buildlog_ubuntu-maverick-amd64.binutils-z80_2.20.1-1_FAILEDTOBUILD.txt.gz
[07:39] <slangasek> kronos: alright :)
[07:41] <kronos> slangasek, binutils-2.20.1.tar.bz2 -> /usr/src/binutils/binutils-2.20.1.tar.bz2 but the tarball is not present .
[07:42] <kronos> slangasek, instead binutils-2.20.51.tar.xz is present there
[07:43] <kronos> in the /usr/src/binutils directory
[07:44] <carstenh> it's also broken in debian
[07:46] <slangasek> kronos: right - I synced it because it was already broken in Ubuntu at the time, so there's no point in carrying a delta when there was a chance the Debian maintainer might fix it for us
[07:46] <slangasek> kronos: if you're going to fix it, I would certainly recommend doing so first in Debian, and syncing from there
[07:51] <carstenh> no it was broken in debian, weird package
[09:13] <omid> amd64 build problem, its OK on my local amd64 ubuntu, but in launchpad i got this error, what should i do to fix it: http://pastebin.ubuntu.com/464876/
[16:23] <omid> amd64 build problem, its OK on my local amd64 ubuntu, but in launchpad i got this error, what should i do to fix it: http://pastebin.ubuntu.com/464876/
[16:47] <geser> omid: do you have any arch-specific files? e.g. some code that needs to get compiled on each architecture?
[16:49] <omid> geser, no, I don't know what is it, where should I find some description about that? I cannot find any in https://wiki.ubuntu.com/PackagingGuide/Complete
[16:51] <geser> omid: I ask because if you don't have any e.g. .c files in your package that need compiling and only e.g. php code than you could make the package "Architecture: all" but if you need compiling you need to fix your binary-arch target in debian/rules
[16:52] <geser> omid: see the description for Architecture on https://wiki.ubuntu.com/PackagingGuide/Complete#control (it's a bit terse)
[16:54] <omid> geser, But I can compile it in my own system, without any problem!
[16:54] <geser> omid: if it's php-cairo from http://sourceforge.net/projects/klecks/ then it has architecture-specific code (cairo.c)
[16:54] <omid> geser, No, it is from pecl.php.net
[16:55] <geser> omid: because there is a small difference how pbuilder operates by default (build arch-specific and arch-indep packages), the i386 buildd work the same, but the amd64 buildd build only the arch-specific packages
[16:56] <geser> omid: you should get the same error when you pass "--binary-arch" when building your package (this would simulate the amd64 build): pbuilder build --binary-arch your_package.dsc
[16:57] <omid> geser, thanks, then I will debug it local :-)
[17:25] <LucidFox> Wait wait wait
[17:25] <LucidFox> So MOTUs can sync packages directly, without waiting for archive admins to do that?
[17:26] <hyperair> syncpackage is the (not-so-recommended) way to do that for now.
[17:26] <hyperair> a button is planned.
[17:26] <shadeslayer> heh
[17:26] <hyperair> a launchpad.net button
[17:27] <hyperair> LucidFox: http://old.nabble.com/The-syncing-process-and-syncpackage-%28or%3A-How-to-speedup-the-syncing-process%29-td28576593.html and https://code.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/syncpackage
[17:28] <LucidFox> Not-so-recommended?
[17:28] <hyperair> i think it's still considered "experimental"
[17:28] <hyperair> which is why it's not in any package, but stuffed away in some bzr branch somewhere.
[17:30] <hyperair> "Manually running syncpackage does add chances for errors.  This is why
[17:30] <hyperair> it's use has been discouraged in the past.  I think this is still a good
[17:30] <hyperair> reason to minimize it's use.
[17:30] <hyperair> "
[17:30] <hyperair> quoted from ScottK's email.
[17:31] <hyperair> LucidFox: ^^
[17:33] <LucidFox> hyperair> syncpackage is actually in ubuntu-dev-tools
[17:33] <hyperair> LucidFox: is it actually distributed already?
[17:34] <hyperair> LucidFox: i thought it was in the source but not in the binary package.
[17:37] <LucidFox> Well, apparently it is
[17:37] <LucidFox> at least in maverick
[17:39] <hyperair> ah.
[17:39] <hyperair> nice.
[17:39] <hyperair> it isn't in lucid.
[17:39]  * hyperair still uses the ancient syncpackage from pitti.
[17:39] <geser> it was left out on purpose for lucid but is currently in maverick
[17:40] <hyperair> the new one uses the lp api afaik, which makes it so goddamn slow i could grow a moustache and beard while waiting.
[17:40] <hyperair> a big bushy one like stallman's
[17:43] <geser> I didn't look yet in detail at the code but AFAIK it is an improved version of that script
[17:43] <hyperair> my general experience is that anything, *anything* at all that uses the launchpad api is slow as hell.
[17:43] <hyperair> requestsync for example.
[17:44] <hyperair> i started requestsync, forgot about it, went to sleep, woke up next day, didn't open a terminal for half a day, and when i resumed my screen session, i saw requestsync still hung
[17:44] <geser> that slow is it for you?
[17:44] <hyperair> yes, that slow.
[17:45] <geser> LP in general or only scripts using the LP API?
[17:45] <hyperair> LP in general is slow
[17:45] <hyperair> but scripts using the LP API are especially slow.
[17:45] <geser> that explains it as the LP API uses http request towards LP
[17:46] <hyperair> i can finish downloading debs from PPAs faster than requestsync can fetch data from LP.
[17:46] <geser> you can use requestsync without the LP API (still default), it then falls back on using rmadison to get the version info and asks the user about things it couldn't check
[17:46] <geser> oh
[17:46] <hyperair> oh rmadison works splendidly fast.
[17:47] <hyperair> and yeah, since that wonderful waiting experience, i've never used requestsync with the LP API again.
[17:48] <hyperair> well occassionally i'd forget, and then realize after a long wait.
[17:49] <geser> I could add a check if $USER == hyperair and always don't use the LP API in that case :)
[17:49] <hyperair> heh lol
[17:49] <hyperair> don't bother, ever since syncpackage <3, i've never touched requestsync.
[20:44] <ScottL> i want to file an SRU for the ardour mute bug https://bugs.launchpad.net/ubuntustudio/+bug/581786
[20:45] <ScottL> however i can not nominate the bug for SRU to the correct version (i.e. 10.04 LTS)
[20:45] <ScottL> i can do nominate the trunk version and others
[20:45] <ScottL> should i nominate on of the others with explanation or is there another way to nominate 10.04 LTS
[20:46] <ScottL> of course I would like to accomplish this before 10.04.01 on july 29
[20:46] <ScottL> any help is greatly appreciated
[20:46]  * evilshadeslayer was about to mistake ScottL for ScottK
[20:46] <ScottL> evilshadeslayer, that happens a lot, apologies for that
[20:47] <evilshadeslayer> ScottL: oh no need to apologies :P
[20:47] <evilshadeslayer> *apologize
[20:53] <c_korn> hm, has someone an idea why "apxs2 -c -o mod_form.so mod_form.c" only creates a "la" and "lo" file? but no shared "so" library ?
[20:53] <c_korn> http://paste.debian.net/80744
[20:53] <evilshadeslayer> whee
[21:06] <evilshadeslayer> any MOTU's around?
[21:06] <evilshadeslayer> http://packages.debian.org/source/sid/qoauth << thats currently not in maverick
[21:07] <evilshadeslayer> should i get it syncd and then change anything if theres a failiure ?
[21:07] <evilshadeslayer> or do we directly upload 1.0-2ubuntu1
[21:08] <kees> evilshadeslayer: if it builds without modification just request a sync
[21:08] <evilshadeslayer> ok.. im letting it go through pbuilder as of now
[21:08] <evilshadeslayer> kees: i was unsure if we need a un modified package in ubuntu first
[21:10] <geser> no need to sync a package which doesn't build, just upload the fixed one
[21:10] <kees> nah, should be fine either way; just make sure the orig matches debian if you do an initial ubuntu1 upload. since it's NEW, though, it frequently easier to review if it's unmodified
[21:10] <kees> right
[21:11] <evilshadeslayer> seems to build fine.. now looking for missing files
[21:13] <evilshadeslayer> kees: geser http://pastebin.ca/1902587
[21:14] <evilshadeslayer> do we need those?
[21:15]  * evilshadeslayer doesnt think so
[21:15] <geser> are they in the Debian package?
[21:15] <evilshadeslayer> geser: nope
[21:15] <evilshadeslayer> those are missing files
[21:15] <evilshadeslayer> from the pbuilder hook
[21:16] <evilshadeslayer> afaik we need only .so and .a files
[21:18] <evilshadeslayer> i wonder where my mail went after i run request sync
[21:20] <evilshadeslayer> geser: kees and any other MOTU bug 606751
[21:22] <evilshadeslayer> ill attach build log
[21:48] <evilshadeslayer> build log attached
[22:16] <c_korn> hm, why does EDITOR=nano quilt header -e open up gedit ?
[22:20] <shadeslayer> c_korn: missing a export there?
[22:21] <c_korn> $ echo $EDITOR
[22:21] <c_korn> nano
[22:23] <StevenK> c_korn: Try VISUAL=nano ...
[22:24] <christoph_debian> maybe .quiltrc overrides it?
[22:24] <c_korn> StevenK: thanks
[22:24] <carstenh> sensible-editor is used in sid instead of $EDITOR
[22:24] <c_korn> I have no .quiltrc