[01:11] <doug> is there a way i can tell what version of a package 12.04 is likely to be tracking?
[01:12] <psusi> doug, what do you mean?
[01:13] <psusi> you can find out what version of a package is currently in 12.04 by looking it up on launchpad.net
[01:14] <doug> cool, that might be what i'm looking for
[01:14] <doug> hm, looking at https://launchpad.net/qtwebkit
[01:15] <psusi> launchpad.net/ubuntu/+source/qtwebkit
[01:15] <doug> > There is no current release for this source package in Ubuntu.
[01:16] <psusi> the source package appears to be gqwebkit-source
[01:16] <psusi> qtwebkit-source rather
[01:17] <psusi> you can also use packages.ubuntu.com
[01:20] <doug> psusi++
[01:32] <psusi> is there any sort of glib utility function somewhere to parse a string for backspace characters and process them?
[02:55] <Corey> I'm seeing something odd-- I install a package that I built, and it seems to install python libraries twice, once in /usr/share/pyshared/salt/, and again in /usr/lib/pymodules/python2.6/salt/.  The latter isn't shown at all by dpkg -c, and -S says no package owns it-- how do I effectively troubleshoot this?
[02:55] <Corey> The .install file for this package reads simply usr/lib/python2*/dist-packages/salt/
[03:19] <jalcine> So that package I had issues compiling with, its source uses a C++ safe name, whereas the it's header doesn't.
[03:19] <jalcine> Definitely going to give my two cents upstream.
[03:20] <Corey> Oh jeez, one's a symlink.  Not sure where it came from...
[06:24] <tiagoscd> hi
[06:24] <vibhav> hi
[06:24] <vibhav> https://bugs.launchpad.net/ubuntu/+source/deluge/+bug/852454 is fixed upstream
[06:24] <vibhav> What do I need to do with it?
[06:24] <vibhav> oh wait
[06:25] <vibhav> I need to submit a debdiff for it, right?
[06:25] <tiagoscd> I'm fixing the first bug (#750134) in Ubuntu, and I like to get help to build and test package, as well how I can send it to LP
[06:25] <tiagoscd> *my first bug
[06:26] <tiagoscd> can anyone help me?
[06:26] <vibhav> tiagoscd: yes
[06:27] <vibhav> tiagoscd: Can you give me the url of this bug?
[06:27] <tiagoscd> https://bugs.launchpad.net/ubuntu/precise/+source/ubiquity/+bug/750134
[06:27] <vibhav> have you fixed this bug in the source ?
[06:29] <tiagoscd> yes, i got their code via apt-get source and resized the image to an acceptable size
[06:29] <vibhav> tiagoscd: now cd to the source via the terminal
[06:29] <tiagoscd> vibhav: ok, done
[06:30] <vibhav> tiagoscd: execute "debuild -S"
[06:31] <tiagoscd> vibhav, ok
[06:32] <vibhav> tiagoscd: did debuild succeed?
[06:33] <tiagoscd> well, i need to review my GPG key
[06:33] <tiagoscd> vibhav, just a moment
[06:45] <tiagoscd> vibhav, I'm running debuild -S now
[06:49] <tiagoscd> vibhav, I need to modify changelog first?
[06:51] <vibhav> yes
[06:51] <vibhav> dch -i
[06:51] <vibhav> and then put the change you did
[06:51] <vibhav> The format is
[06:51] <vibhav> * Fixed icon (LP: #BUGNO)
[06:52] <vibhav> developer.ubuntu.com/packaging/html/fixing-a-bug.html
[06:53] <tiagoscd> * Fix size of the "Install Ubuntu" pixmap. (LP: #750134)
[06:53] <vibhav> yes
[06:53] <tiagoscd> done
[06:53] <vibhav> now run debuild -S
[06:53] <vibhav> (again, Since yo uhave modified the changelog)
[06:53] <vibhav> you *
[06:53] <tiagoscd> ok
[06:55] <tiagoscd> signfile ubiquity_2.9.27ubuntu1.dsc Tiago Hillebrandt <tiagohillebrandt@ubuntu.com>
[06:56] <tiagoscd> gpg: ignorado "Tiago Hillebrandt <tiagohillebrandt@ubuntu.com>": chave secreta não disponível
[06:56] <tiagoscd> debsign: gpg error occurred!  Aborting...
[06:56] <tiagoscd> my GPG key is fine, I created it just now
[06:57] <vibhav> never mind
[06:57] <vibhav> now "cd .."
[06:58] <tiagoscd> ok
[06:58] <tiagoscd> done
[06:59] <vibhav> "ls | grep dsc"
[07:00] <vibhav> paste the output
[07:00] <tiagoscd> ubiquity_2.9.27.dsc
[07:00] <tiagoscd> ubiquity_2.9.27ubuntu1.dsc
[07:00] <tiagoscd> only this
[07:00] <vibhav> debdiff ubiquity_2.9.27.dsc ubiquity_2.9.27ubuntu1.dsc
[07:00] <vibhav> oops
[07:00] <vibhav> dont use this command
[07:00] <tiagoscd> ok
[07:00] <vibhav> debdiff ubiquity_2.9.27.dsc ubiquity_2.9.27ubuntu1.dsc > patch.debdiff
[07:01] <tiagoscd> done
[07:02] <vibhav> submit this patch to Launchpad
[07:02] <vibhav> IN the comments section of the bug you are fixing
[07:04] <tiagoscd> vibhav, the image that I've resized will be putted into this patch?
[07:05] <tiagoscd> done
[07:05] <tiagoscd> LP ask me if this file is a patch
[07:05] <tiagoscd> can I confirm?
[07:19] <tiagoscd> Can anyone continue helping me?
[07:19] <tiagoscd> Now debuild -S was worked
[07:19] <tiagoscd> Successfully signed dsc and changes files
[12:00] <plipp> hi guys and guysettes, I'm looking at "Packaging New Software" and following the steps. The application (kqrcode) is missing a few dependencies, among others 'libqrencode' as I had a missing file  'qrcodec.h'
[12:01] <plipp> Anyway, the page tells me to look the file up at 'packages.ubuntu.com' to find the missing package. And then it goes on to install libqrencode-dev.  However, I failed in finding that package on the site. Tried searching on different releases and what not.
[12:02] <plipp> clarification: I failed to find any package that contains the file 'qrcodec.h'
[12:03] <directhex> http://packages.ubuntu.com/search?searchon=contents&keywords=qrcodec.h&mode=exactfilename&suite=precise&arch=any
[12:04] <plipp> directhex: Yep, that yields in "Sorry, your search gave no results."
[12:04] <directhex> yep.
[12:05] <plipp> oh.
[12:05] <plipp> :)
[12:06] <plipp> it's actually not in libqrencode-dev either, no..
[12:06] <plipp> hmm
[12:06] <jtaylor> qrencode does nto have that file
[12:06] <jtaylor> neither the packge nor upstream
[12:07] <plipp> jtaylor: Yes, I realized that. I was merely assuming that the page was correct and I was wrong.
[12:07] <plipp> But as always, assumption is the mother of a lot
[12:08] <directhex> i believe it's "assumption is The Black Goat of the Woods with a Thousand Young"
[12:08] <directhex> or something
[12:08] <plipp> Fun fact: I know I'm pretty much always wrong. So even now when I was right, I ended up being wrong.
[14:03] <Pikkachu> hi, is it a practice in raw patch management to specify dependencies as comments within the patches?
[14:04] <Pikkachu> for example, you are applying a few patches to an application, some are mandatory (early access to bug fixes) some are not (rejected features)
[14:05] <Pikkachu> but you do not want the non-mandatory ones in a patch queue, because they're not supposed to be run into a given order
[14:05] <Pikkachu> someone else may select which non-manadatory patches to apply
[14:07] <jtaylor> you could put them as comments in the quilt series file
[14:11] <valdur55> Hey! Lubuntu misses cups package.  Printer managemend doesn't find printer server
[14:18] <tiagoscd> hi
[14:26] <tiagoscd> I fixed the bug #750134 and already built it (debuild -S). Now I need to know how to test the app and after how to submit it to LP
[14:26] <tiagoscd> Can anyone help me?
[14:26] <tiagoscd> My first bug fix :)
[15:03] <Pikkachu> jtaylor: I think I'll just reference the dependencies within the patch
[15:06] <tumbleweed> that sounds sensible
[15:06] <tumbleweed> breaking up the quilt series into blocks of different types of patches is also helpful
[15:09] <Pikkachu> I'm sorry I think I'm being offtopic, I asked here just because I know you make patch management, not because I'm actually in ubuntu and building a package (I don't know what "quilt" is)
[15:10] <tumbleweed> quilt is the program we use to managed debian/patches
[15:10] <tumbleweed> *manage
[15:10] <Pikkachu> cool, I tried to build a package but failed miserably, documentation is extremely complex and long
[15:11] <Pikkachu> in my opinion of course
[15:11]  * tumbleweed avoids getting dragged into that discussion again
[15:13] <Pikkachu> well, as for the question tbh I don't think the term dependency apply completely given that one patch would not need other to be applied to achieve its intent, it's really just the technical problem of line references.
[15:13] <Pikkachu>  Currently I have 5 patches here but none of them conflict regarding line references, so I'm not worrying that much
[15:14] <tumbleweed> I woludn't call that a dependency then
[15:14] <Pikkachu> yeah dependency is not really a good term
[15:15] <tumbleweed> if they apply and work on their own, you don't need to worry at all
[15:15] <Pikkachu> I think maybe I'll just put them in a queue and if one wants to apply specific patches, then I let them manually changing the patches
[15:16] <Pikkachu> yeah currently they can be applied in any order
[15:17] <Pikkachu> but in the future two could change the same file but one affect the reference used by the other, in that case is that I think I'll just put them in a queue
[15:19] <Pikkachu> btw I found out a neat way to produce a patch log using the patches themselves, I just do something like:
[15:20] <Pikkachu> +++PATCHES
[15:20] <Pikkachu> @@ -0,0 +1 @@
[15:20] <Pikkachu> + Description of this patch
[17:26] <Laney> Woe is "oh crap, nobody merged haskell-devscripts yet, did they?"
[18:00] <iulian> Laney: Oups. That was on my todo list. Completely forgot about that. It was the next package to do after GHC. :(
[18:00] <iulian> I'm doing it now.
[18:00] <Laney> I did it
[18:00] <Laney> but it means the syncs I already did are busted
[18:00] <iulian> Pfft.
[18:01] <Laney> so if you fancy uploading some rebuilds ^o)
[18:45] <Laney> ok, doing them myself
[18:46]  * Laney accidently made twice as much popcorn as was intended
[18:58] <iulian> Laney: Will do.
[19:15] <Laney> iulian: reuploading everything I synced
[19:15] <Laney> sorry buildds :(
[19:15] <Laney> y
[21:11] <jtaylor> anyone aware of a reason why asterik is not up to date with debian?
[21:12] <jtaylor> just looked at the release notes and it only has a bunch of fixes so its probably worth it to get that into precise
[21:12] <Pikkachu> hi, has anyone ever used ubuntu font in windows?
[21:16] <quidnunc> Anyone know how cabal-debian generates dependencies?
[21:46] <shadeslayer> jtaylor: I don't see any package called asterik
[21:46] <jtaylor> asterisk
[21:46] <shadeslayer> oh cool
[21:47] <jtaylor> I think its a good idea to stick as close to upstream as possible, it had a security update each release
[21:48] <shadeslayer> well, 2 things, it'll need a merge and someone will have to test it on armhf
[21:49] <jtaylor> why the latter?
[21:49] <shadeslayer> "Fix building on armhf with debian/patches/armhf-fixes:"
[21:49] <jtaylor> debian has armhf now too
[21:49] <jtaylor> it built there
[21:49] <jtaylor> the patch can be removed half
[21:49] <jtaylor> the configure part does not seem to be in debian
[21:50] <jtaylor> though it does not appear to break the build
[21:50] <shadeslayer> well, I'm not entirely sure that stuff that builds on debian armhf will also build on ubuntu armhf
[21:50] <jtaylor> the patch is tiny, so probably was never a large issue
[21:50] <shadeslayer> possibly, I haven't looked at the patch, just looking at the changelog
[21:51] <jtaylor> I'll push my merge in a moment
[21:51] <shadeslayer> cool :)
[21:51] <jtaylor> I kept all the really old hardy stuff
[21:51] <jtaylor> can probably be dropped as I doubt it still works ^^
[21:51] <jtaylor> some backport stuff
[21:53] <jtaylor> friggin bzr and its humongous andwidth requirements!
[21:54] <shadeslayer> hahaha ...
[21:56] <shadeslayer> cya
[22:36] <jtaylor> ok apparently updating is not such a good idea, well the merge can still be used for +1 then
[22:50] <jtaylor> why does bzr upload 4MB+ data for a 1kb diff!
[22:54] <jtaylor> 7MB and counting, its larger than the orig tar already ...
[22:58] <jtaylor> ok used the wrong merge base but its still much larger than the diff
[23:10] <dupondje> Some small question. How do we handle a difference in files in a package on debian and ubuntu. For example on debian it should install normal init scripts, on ubuntu upstart scripts.
[23:15] <Ampelbein> dupondje: dh_installinit should do the right thing already.
[23:29] <dupondje> Ampelbein: so you mean dh_installinit will install upstart file on ubuntu, and normal init script on debian right ?
[23:30] <Ampelbein> dupondje: That's what I get from it's manpage, yes.