[06:27] <Whoopie> broder: Hi, could you perhaps have a look at bug 898003? I added a usbip package to my testing PPA, but I'm not sure if it meets the requirements, especially the version number. Thanks!
[08:38] <hrw> hi
[08:39] <hrw> how to mention LP bug number in changelog to not get it closed on upload?
[08:44] <iulian> The bug number without LP in front of it? I haven't tried it but it should work I reckon.
[08:45] <iulian> For instance, `Changes here. #123456'. Or you could also try `Changes here. Bug 123456'.
[08:46] <iulian> I personally use that when I mention upstream bug reports.
[08:50] <mr_pouit> or remove Launchpad-Bugs-Fixed from the .changes
[08:56] <arand> Does it not need to be "LP #123456"?
[08:57] <arand> Since otherwise it would refer to the Debian BTS..?
[08:58] <arand> Oh... Nevermind, misread >_<
[09:02] <hrw> mr_pouit: thx, will do this
[09:03] <hrw> I prefer to not use #bugnumber as I feel that this is for Debian bts
[09:04] <micahg> hrw: just don't add the colon (i.e. LP #XXXXXX)
[09:05] <micahg> like arand mentioned I see
[09:07] <hrw> ok
[09:45] <tumbleweed> Laney: better?
[09:46] <Laney> ye, looks good
[09:47] <Rhonda> Anyone got a hint what's needed when moving a conffile from one package to another one?  I have a gut feeling that having a Replaces isn't enough
[09:48] <Laney> preserving user changes
[09:48] <Laney> there's dpkg-maintscript-helper though
[09:48] <Rhonda> Sure, that's a different topic.
[09:48] <Laney> different to "what's needed?"
[09:48] <Rhonda> But I have a situation here where the file still seems to be registered with the old package and I wonder why  :/
[09:50] <Laney> there's something to do with conffiles sticking around later than usual
[09:53] <Rhonda> hmm, in the replaced package there is the snippet about removing the obsolete conffile …
[09:53] <Amoz> hi, i've got a fix for a bug in Precise, should I just subscribe ubuntu-release to the bug and link my fix (it's in a ppa) to the bug?
[09:54] <Laney> dpkg won't remove them for you, yeah
[09:55] <Laney> Amoz: bug fixes don't need release approval, please seek sponsorship as normal
[09:55] <Laney> diff or branch is easier than ppa
[09:57] <Amoz> Laney, like this? https://launchpadlibrarian.net/100361095/pidgin_1%3A2.10.2-1ubuntu2_1%3A2.10.3-0ubuntu1.diff.gz
[09:58] <Amoz> hm. I should probably do a debdiff
[09:58] <Laney> that is a seeded package
[09:59] <Amoz> meaning?
[09:59] <Laney> but new upstream version → .diff.gz or branch
[09:59] <Laney> meaning that it needs a bit more review
[09:59] <Laney> should be ok though
[09:59] <Amoz> it fixes the "contacts not going offline" bug
[10:00] <Laney> yep
[10:00] <Amoz> okay I'll put it in a branch and propose it
[10:00] <Amoz> and follow the normal sponsorship process?
[10:01] <Amoz> subscribe ubuntu-sponsors to the bug, that's it?
[10:01] <Laney> yeah
[10:02] <Laney> mention that you tested it fixes the bug
[10:02] <Amoz> I will
[10:05] <geser> does someone remember what the build fix for "rsvg: command not found" was?
[10:06] <jtaylor> geser: use rsvg-convert
[10:07] <jtaylor> see unison
[10:15] <valdur55> Hey. I fixed two items on upstream source. What i should do?
[11:14] <geser> Ubuntu Mobile Edition is gone, right?
[13:04] <ockham> what would be the hard deadline for syncing a new version of ocrfeeder (that's not ready yet) which fixes an important bug when using tesseract 3.0? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661499
[13:05] <Laney> why do you want to wait until a hard deadline?
[13:05] <Laney> the sooner the better.
[13:07] <ockham> i know -- i've already added a comment to the upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=670953 -- but it hasn't been fixed yet, so i thought telling them about a deadline might speed up things ;-)
[13:07] <ockham> (my comment is #12)
[13:08] <valdur55> I fixed #972259  and #972205 on upstream version control system. What i should now do? Should i make patch for downstream ?
[13:09] <Laney> ockham: the really final deadline is april 24
[13:09] <geser> valdur55: if you want to see it fixed now, then yes (instead of waiting till a new upstream release, see it packaged in Debian and synced to Ubuntu)
[13:10] <ockham> Laney: ok. maybe i can think of some comment to ask for a fix for easter...
[13:10] <Laney> you could take a look at the code yourself :P
[13:11] <hrw> ok, time to generate arm{el,hf}-cross-toolchain-base 1.80 and upload
[13:11] <ockham> Laney: well, upstream already said he was going to take care of it, and i'd be much slower, i fear...
[13:13] <hrw> done. now all in hands of buildders... (but it built fine in pbuilder here)
[13:14] <ockham> will it also be possible to sync a new version (0.4.4) of a package (ocropus) whose previous version (0.3.x) has been removed from Precise (due to incompatibilities with tesseract 3.0) until the 24th?
[13:15] <ockham> (somewhat similar situation -- the debian maintainer's still working on an FTBFS bug in a dependency...)
[13:16] <Laney> possibly
[13:17] <Laney> it all depends on whether someone can review the fix in time
[13:19] <ockham> well, i hope it'll get done this weekend, too. if anyone cares, i'm talking about this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651402
[13:44] <hrw> ockham: does this bug exists also in ubuntu?
[13:44] <ockham> hrw: the iulib one?
[13:44] <hrw> yes
[13:45] <ockham> ubuntu doesn't have iulib 0.4.x, only 0.3.3
[13:45] <hrw> ok
[13:46] <Laney> you want us to bring in a new library?
[13:48] <ockham> um, yeah. it's a dependency of ocropus 0.4.4
[13:50] <Laney> hrm
[13:50] <ockham> not good, at this time?
[13:51] <Laney> it has a new SONAME, but apparently no rdepends
[13:51] <Laney> might be ok
[13:52] <ockham> yeah, i figured it was only used by ocropus
[13:53] <ockham> with ocropus currently not in precise, it'd be pretty much useless, wouldn't it?
[13:53] <Laney> as far as the archive is concerned
[13:53] <Laney> others may be using it
[13:54] <ockham> true
[13:54] <ockham> so i'll hope for that bug to get fixed soonish, then test the new ocropus and file a sync request/FFe?
[13:55] <Laney> hrw: it will exist in ubuntu when the FTBFS is fixed (at least, that is ockham's plan)
[13:55] <Laney> ockham: yes, for both packages
[13:55] <ockham> ok
[14:01] <hrw> problem may be in scons itself
[14:01] <ockham> well, as for the FTBFS bug, i think it's largely solved; or do you mean the symbols?
[14:02] <hrw> ah, right - there was a patch
[14:03]  * hrw shuts up
[14:06] <hrw> for me it looks like test for tiff is broken. It checks for existance of tiff.h (which is fine) and is using 'inflate()' from zlib
[14:07] <hrw> http://code.google.com/p/iulib/issues/detail?id=27 has fix
[14:07] <valdur55> Ok, I made patch with  [ hg diff -g -r r1 -r r2 > fix.patch ] command output is here: http://paste.ubuntu.com/917450/ . What next?
[15:41] <broder> Whoopie: i just started a new job, so i don't currently have the time to do anything for ubuntu other than skim irc once a day or so
[15:56] <tumbleweed> broder: how is stripe? are they letting you go to UDS?
[17:13] <valdur55> i have binary files on my diff.
[17:59] <valdur55> Lol.. my first package build is failed :P.... damn.. bad patch ...
[18:13] <EtienneG> hello everyone
[18:14] <EtienneG> I would like to know if it is too late to request that nsscache 0.21.17-2 be synced from Debian testing
[18:14] <ScottK> If it's a bug fix no.
[18:15] <ScottK> If it's more than that, we can talk.
[18:15] <EtienneG> the version in precise (0.8.8-1) is awfully out of date, and it would be good to fix bug #901701
[18:15] <EtienneG> (which is really just cosmetic, but still)
[18:16] <EtienneG> ScottK, thing is: I am not sure why 0.8.8-1 was brought in precise, given it is so dated (2009)
[18:16] <EtienneG> I am neither upstream nor the Debian maintainer, I am just interested in that package
[18:17] <ScottK> OK.
[18:17] <ScottK> Please have a look at the changes and see if there's feature changes and if so, file an FFe.
[18:19] <EtienneG> ScottK, ok, I will file an FFe.  I am just surprised that we didn't synced 0.21.17-2 or -1 (or even 0.21.16-something) in the first place.
[18:21] <EtienneG> ScottK, actually, it seems like this package was uploaded for the first time in precise.  Would a sync still require an FFe?  That seems overkill.
[18:21] <ScottK> EtienneG: Yes.
[18:21] <EtienneG> ScottK, ok then!
[18:22] <ScottK> That will make it easier to get approved since there's no regression risk, but FFe is still needed.
[18:33] <EtienneG> ScottK, filed as bug #975373, thanks a lot for the guidance!  :)
[18:42] <valdur55> :D again fail with packaging... i have cloned upstream source and i wan't build PPA from it...
[22:36] <broder> tumbleweed: definitely having a lot of fun so far, but also feel like it's going to take a while to legitimately get spun up. i will absolutely be at UDS