[00:02] <nfirvine> Where's the best place to get advice on packaging software?
=== medberry is now known as med_out
[03:14] <persia> nfirvine: New software?  Probably #ubuntu-packaging or #debian-mentors@OFTC.  We can sometimes help, for some software, if you're specifically targetting Ubuntu, but since we typically recommend against targetting Ubuntu (better to submit to Debian), you'd need some reason why it's Ubuntu-local software.
[03:27] <stlsaint> would someone mind taking alook at some piuparts results from a package: http://paste.debian.net/124824/
[05:56] <stlsaint> can someone please take a look at pbuilder error log: http://pastebin.com/VH1MJc9c
[06:37] <geser> stlsaint: you need to either find a backport of debhelper and javahelper for lucid or backport it yourself
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== RoAkSoAx_ is now known as RoAkSoAx
=== tremolux_ is now known as tremolux
[15:08] <directhex> ... did one of my PPA builds just get killed?
[15:57]  * zooko looks at https://wiki.ubuntu.com/OneiricReleaseSchedule and thinks about Tahoe-LAFS v1.9...
[16:00] <tgm4883> If a MOTU has a moment, could someone look at mythbuntu-bare for a second ack http://revu.ubuntuwire.com/p/mythbuntu-bare
[16:06]  * tumbleweed waves from the croatian coast (probably going to be offline for a few days again)
[16:07] <tumbleweed> bdrung: before I forget, we got to the bottom of the lintian issue, and it'll be fixedin teh next upstream release, due RSN (if not already)
[16:11] <jtaylor> zooko: I would not try to get 1.9 into oneiric, instead do a backport when the release is ready
[16:11] <jtaylor> are 1.8 and 1.9 compitable?
[16:12] <micahg> tgm4883: if there's a needs-packaging bug, you could subscribe ubuntu-sponsors to it
[16:17] <tgm4883> micahg, is it considered needs-packaging? It's packaged, it just needs revu'd to get into the archive
[16:18] <micahg> tgm4883: new packages should have a needs-packaging bug associated with them (like a Debian ITP)
[16:19] <tgm4883> micahg, ah I see what you mean, yea it does have a needs-packaging bug. So just subscibe ubuntu-sponsors to the bug?
[16:19] <micahg> tgm4883: yep, then it'll show up in the sponsorship queue
[16:19] <tgm4883> micahg, awesome, will do. Thanks
[16:20] <micahg> tgm4883: just make sure there's a link to the revu page in the bug so sponsors don't have to hunt
[16:22] <jtaylor> how does one remove a pkg<-> upstream link in LP? see https://bugs.launchpad.net/ubuntu/+source/apt-offline/+bug/819514/comments/2
[16:22] <ubottu> Ubuntu bug 819514 in apt-offline (Ubuntu) "Sync apt-offline 1.1.1 (universe) from Debian unstable (main)" [Undecided,Confirmed]
[16:27] <micahg> jtaylor: I can do that now apparently (LP used to be broken)
[16:30] <micahg> jtaylor: done
[16:31] <jtaylor> thx
[17:02] <zooko> jtaylor: Tahoe-LAFS has a strong policy of backward-compatibility. Unless there's a major mistake, nobody will have any compatibility issues in upgrading from 1.8 to 1.9.
[17:03] <zooko> I would be sad for Oneiric to be the first Ubuntu that *didn't* come with a new version of Tahoe-LAFS, but I guess the next one after Oneiric will be an LTS, so I can console myself with the thought of having an even better Tahoe-LAFS in that.
[17:04] <zooko> Oh, no it won't. Oh well.
[17:04] <zooko> It won't be an LTS that is.
[17:04] <zooko> Oh wait, yes it will! Yay!
[17:04] <zooko> https://wiki.ubuntu.com/LTS
=== zooko` is now known as zooko
[19:27] <c_korn> if the source directory contains a file named "clean" debuild clean does not clean the debian directory
[19:30] <jtaylor> then your rules is buggy
[19:30] <jtaylor> clean must be a phony target
[19:31] <jtaylor> c_korn: ^
[19:31] <c_korn> if use the tiny rules
[19:31] <c_korn> the file is already in the upstream tarball
[19:31] <c_korn> s/if/i/
[19:32] <paultag> I'm sure you can .PHONY: clean above the tiny rules
[19:32] <paultag> I'm not sure, though, but it should be fine
[19:38] <c_korn> hm, let's try
[19:40] <c_korn> odd, I deleted the file but it is still in the orig tarball but debuild does not create a patch in debian/patches to delete it
[19:40] <paultag> c_korn: you shouldn't be futzing with upstream, there's a clean solution here
[19:43] <c_korn> hm, so .PHONY: clean did not do it
[19:43] <c_korn>  fakeroot debian/rules clean
[19:43] <c_korn> make: Nothing to be done for `clean'.
[19:50] <c_korn> any other ideas?
[19:53] <paultag> c_korn: could add a .PHONY: clean\nclean:\n\tdh clean
[19:54] <paultag> c_korn: or similar. that should work, I think
[19:55] <c_korn> ok, that did it. thank you paultag
[19:56] <paultag> c_korn: sure thing
[19:56] <paultag> jeez, and I'm not even MOTU. I should try for MOTU at some point.
[19:56] <paultag> Meh, I guess that's time and energy and all that.
[19:58] <c_korn> ;)
[19:59] <c_korn> ok, another question. can symbol files be arch dependent ? so I have for i386 another one than for amd64?
[19:59] <jtaylor> yes
[20:00] <jtaylor> debian/package.symbols.arch
[20:01] <c_korn> perfect, thanks jtaylor
[20:02] <jtaylor> do you really need that? should be quite rare
[20:03] <c_korn> well, I created the file under amd64 now the build on i386 failed because of a too large diff
[20:05] <c_korn> this is the diff, jtaylor: http://pastebin.com/raw.php?i=AbSjmbL0
=== med_out is now known as med
=== med is now known as medberry
[20:11] <jtaylor> ah no makes sense, pointer ahs a different size for the two archs
=== yofel_ is now known as yofel
[21:50] <bdrung> tumbleweed: great. to get all those annoying thing fixed before 2.5.2 was my reason to upload a git snapshot
=== gumdrop is now known as bagofbones
[22:20] <bdrung> tumbleweed: do you have a link to the fix commit?
=== medberry is now known as med_brb
=== med_brb is now known as med
=== med is now known as medberry