=== asac_ is now known as asac
=== bdefreese2 is now known as bddebian
[00:54] <feasty>  Hi there. I am looking into how to go about getting started fixing bugs for Ubuntu. Can anyone point me in the right direction to start working on fixing some bugs. I have read the wiki pages but cant seem to see where I would go to pick one up to work on. Can anyone help me please?
[00:55] <micahg> feasty: there should be a bitesize tag for small fixes needed
[00:55] <micahg> https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[00:55] <micahg> might be a good start
[00:55] <micahg> feasty: what languages do you know?
[00:55] <feasty> thanks I'll have a look
[00:56] <feasty> c++, C but I am happy to work in Python and Java as well
[00:57] <feasty> also competent in bash if that helps
[00:57] <micahg> feasty: that's great
[00:58] <feasty> whats the difference between triaged and confirmed?
[00:59] <micahg> feasty: depends on the bugs
[00:59] <micahg> here's the standard list: https://wiki.ubuntu.com/Bugs/Status
[01:01] <feasty> thanks, perfect
[01:01] <micahg> feasty: usually triaged means it's ready to be worked on
[01:02] <micahg> feasty: unless it's a packaging bug
[01:04] <feasty> So how do I take on one of these bugs to fix?
[01:04] <feasty> Do I need someone to assign it to me?
[01:05] <lifeless> no
[01:05] <lifeless> just start working on it
[01:06] <feasty> but is it possible that someone else could be working on it too?
[01:06] <lifeless> yes
[01:06] <lifeless> but
[01:07] <feasty> ok cool
[01:07] <lifeless> 80K open bugs
[01:08] <lifeless> if we had 1000 developers, that would still be 80:1 chance of working on the same bug
[01:09] <feasty> ah ok :). No problem. When I work on a fix I just download the source through apt and use that or should I get it elsewhere?
[01:10] <lifeless> debcheckout, or apt, or bzr.
[01:10] <feasty> ok thanks
[01:10] <lifeless> all are ok - and there are lots of docs about process and how to record your work etc.
[01:11] <feasty> ok. Thanks for all your help.
[01:13] <lifeless> np
[01:39] <shriekout> http://revu.ubuntuwire.com/p/happytimer
[01:39] <shriekout> Sign up advice.
[02:13] <DktrKranz> geser: with lazr.restfulclient >= 0.9.4 you get http://pastebin.com/m7cd288e8, a workaround is applying http://people.debian.org/~dktrkranz/u-d-t_unicode.patch to lazr.restfulclient
=== yofel_ is now known as yofel
[05:59] <shriekout> http://revu.ubuntuwire.com/p/happytimer
[05:59] <shriekout> please advice...
[06:12] <micahg> shriekout: sat night is the slow time
[06:13] <shriekout> humm... yes...
[06:13] <shriekout> :)
[07:21] <fabrice_sp> directhex, do you have an opinion on Bug #489467 ?
[07:21] <ubottu> Launchpad bug 489467 in monodevelop-database "Sync monodevelop-database 2.1.1+dfsg-1 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/489467
[07:57] <RAOF> fabrice_sp: It'd be nice to have a set of monodevelop packages that are installable; currently all the plugins are unable to be installed against our monodevelop 2.1.1.
[08:00] <RAOF> In fact, most of our monodevelop packages should be sync'd, it would appear.
[08:00] <fabrice_sp> ok RAOF will process then (just wanted to be sure the sync won't destroy anything).
[08:00] <fabrice_sp> Yes: just what I was thinking
[08:01] <RAOF> The only one I've seen so far with meaningful ubuntu delta is monodevelop-debugger-mdb.
[08:02] <fabrice_sp> but it could be solved with the help of directhex I suppose ;-)
=== Guest87841 is now known as Zic
[08:06] <RAOF> I could probably check; it'd be nice to have a working monodevelop debugger
[08:07] <fabrice_sp> TBH, I'm not a mono fan :-D
[08:11] <RAOF> Heretic!  Burn the unbeliever! :P
[08:12] <fabrice_sp> lol
=== Zic is now known as Guest81151
=== Guest81151 is now known as Zic
=== Zic_ is now known as Zic
=== Zic is now known as Guest40040
=== Guest40040 is now known as Zic
[09:02] <shiki-> hi everyone
[09:02] <maco> shiki-: this is where developer training happens
[09:03] <maco> packaging is something developers do, so...makes sense to bring you here
[09:03] <shiki-> ah I know.. I just tried this "Quassel" irc ..and I dont have to autojoin list
[09:03] <maco> i use quassel too :) any channels you're in when you close it, itll autojoin when you start it again
[09:03] <shiki-> yeah.. but I tried this client first time
[09:03] <shiki-> I use Pidgin mostly ^^"
[09:04] <shiki-> okay
[09:04] <shiki-> so
[09:04] <shiki-> source package has two conflicting values.. hmm
[09:06] <maco> perhaps different version numbers?
[09:07] <shiki-> oh geez
[09:07] <shiki-> the person who made the changelog basically, messed up the name of the package
[09:07] <shiki-> \o/
[09:07] <shiki-> voila' its working
[09:07] <maco> yay!
[09:07] <shiki-> yeah
[09:07] <shiki-> !
[09:07] <shiki-> :)
[09:07] <shiki-> ty for the help
[09:08] <maco> np
[09:08]  * maco points to revu again ;-)
[09:08] <shiki-> ah one more 'fast' question
[09:09] <shiki-> if I want to build a package for 8.04-9.10 for example. Then I should NOT put the ~ppaX~distroY part and just copy into the folder itself after upload? OR replace the "distroY" to "ZubuntuY" ?
[09:09] <maco> you cant have 1 binary in 2 versions with ppas
[09:09] <nigel_nb> maco: got a min?
[09:09] <shiki-> oh..damn :)
[09:09] <maco> nigel_nb: whats up?
[09:09] <shiki-> I could reduce my "work time" to 1/4
[09:09] <shiki-> could.. ^^"
[09:09] <maco> shiki-: they have be named differently
[09:09] <nigel_nb> i'm looking for some pointers to start with motu
[09:09] <shiki-> yeah.. thats what is annoying :)
[09:10] <nigel_nb> just finished daniel's videos and installing everything
[09:10] <maco> nigel_nb: was just gonna ask how far you were :)
[09:10] <nigel_nb> read the wiki too, but still feel kinda lost
[09:10] <maco> nigel_nb: have you seen harvest?
[09:10] <nigel_nb> no
[09:10] <maco> !harvest
[09:11] <maco> oh boo
[09:11] <maco> why does this not have a factoid?
[09:11] <maco> silly bot
[09:11] <shiki-> :)
[09:11] <nigel_nb> hahha
[09:11] <maco> http://daniel.holba.ch/harvest/sourc
[09:11] <maco> http://daniel.holba.ch/harvest/sourcepackages.html
[09:11] <maco> there we go
[09:12] <maco> i think the "patches" column is easiest to handle as a beginner
[09:12] <maco> um scroll past the linux package though
[09:12] <nigel_nb> after karmic right?
[09:13] <maco> harvest is full of low-hanging fruit
[09:13] <maco> small tasks for new devs
[09:13] <maco> or lazy ones...
[09:13] <nigel_nb> haha
[09:13] <nigel_nb> lemme try one out
[09:14] <maco> im trying to find one for a source package i can upload that way i can walk you through it and then upload it for you
[09:14] <nigel_nb> oh, great :)
[09:17] <shiki-> hmmm.
[09:17] <shiki-> How can I replace a string recursively with sed? (like karmic -> hardy) :)
[09:17] <shiki-> or .. just..RTFM? ^^"
[09:22] <shiki-> uploaded the stuff to REVU. (hope I didnt do anything wrong..)
[09:30] <maco> nigel_nb: ugh it seems like most stuff with patches is in main so im just gonna dig up a simpleish one
[09:31] <maco> nigel_nb: ok see https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/351509 ?
[09:31] <ubottu> Launchpad bug 351509 in vm-builder "vmbuilder should provide an option to choose which libvirt virtual network" [Wishlist,Confirmed]
[09:31] <maco> nigel_nb: go to packages.ubuntu.com and get to the vm-builder page for lucid
[09:32] <maco> copy the link for its .dsc then run "dget blahblah.dsc" with that link instead of blahblah.dsc
[09:34] <maco> itll download a .dsc, .orig.tar.gz, and .diff.tar.gz
[09:34] <nigel_nb> ok
[09:34] <micahg> I find it's easier to add the deb-src line for lucid and just do apt-get source -t lucid PKGNAME
[09:34] <maco> micahg: that seemed like more explaining
[09:34] <maco> run "dpkg-source -x blahblah.dsc" to get it to unpack the source package
[09:35] <maco> also download the diff from that bug
[09:36] <nigel_nb> maco: I'm a little slow, hold on
[09:37] <maco> woah....wait im wondering what the heck this patch is doing now
[09:37] <maco> ah ok i see
[09:37] <nigel_nb> in package.ubuntu.com, there was python-vm-builder and ubuntu-vm-builder
[09:38] <nigel_nb> I take the second one?
[09:38] <maco> yeah
[09:40] <nigel_nb> oddly the gpg validation failed when I downloaded the dsc
[09:40] <nigel_nb> is that okay?
[09:42] <nigel_nb> maco: got everything you asked me to
[09:42] <maco> yeah it always does
[09:43] <maco> its because source package v. binary package
[09:43] <maco> ok you got the patch from the bug too?
[09:43] <nigel_nb> yep
[09:43] <maco> and did the dpkg-source -x thing?
[09:43] <nigel_nb> yep
[09:44] <maco> k so when you "ls" you have network.diff       vm-builder_0.11.3-0ubuntu1.diff.gz  vm-builder_0.11.3.orig.tar.gz    vm-builder-0.11.3  vm-builder_0.11.3-0ubuntu1.dsc
[09:44] <maco> right?
[09:44] <nigel_nb> right :)
[09:44] <maco> great
[09:44] <geser> the validation failed because you (or more precisely dscverify) doesn't have the key of the person who signed the source package
[09:44] <maco> cd vm-builder-0.11.3
[09:44] <nigel_nb> geser: oh.
[09:45] <maco> geser: can i continue ignoring it or should i start importing gpg keys like mad?
[09:45] <geser> depends how paranoid you are
[09:46] <maco> geser's in ur tubes corruptin ur src pkgs
[09:48] <maco> nigel_nb: anyway, first thing you do when youre going to apply a patch to a package is "patch -p1 --dry-run < ../patchfile" so in this case "patch -p1 --dry-run < ../network.diff" to test and see if it applies cleanly
[09:49] <nigel_nb> maco: there is a "can't find the file to patch at input line 3
[09:49] <maco> thatd be "does not apply cleanly" then ;-)
[09:50] <maco> that means we gotta fix it up a big
[09:50] <maco> *bit
[09:50] <nigel_nb> aha :)
[09:51] <maco> take a look at the first line of network.diff and at the contents of vm-builder-0.11.3/  ...something seem a little off to you?
[09:54] <maco> nigel_nb: ^ ?
[09:54] <nigel_nb> its supposed to change the file inside the package instead of the one already installed?
[09:54] <maco> right
[09:54] <maco> also, im pretty sure that adding .orig to the end of the file name is bad
[09:55] <maco> sooo have to dig around and find where those files actually exist in the source package
[09:56] <maco> i suggest "find . -name __init__.py" for possible paths to the first part of the diff and "find . -name libvirtxml.tmpl" for the second
[09:56]  * nigel_nb sheepish grin
[09:56] <nigel_nb> i found it manually
[09:56] <maco> so did i :)
[09:56] <maco> i just realized right now that find wouldve been the easy way
[09:57] <nigel_nb> oh :)
[09:57] <maco> meanwhile i was digging around while you were downloading the source package
[09:57] <nigel_nb> i just looked into the VMBuilder folder and then went on
[09:57] <maco> me too
[09:57] <shiki-> Do I really have to mess up the launchpad bugtracker? :(
[09:57] <shiki-> (when creating a revu package upload)
[09:58] <maco> nigel_nb:  so i edited the diff to have this: http://paste.ubuntu.com/330956/
[09:59] <maco> nigel_nb: make sense to you?
[09:59] <nigel_nb> whats with the a and b?
[10:00] <maco> patch level -p1 requires one extra level
[10:00] <maco> without itd be -p0
[10:00] <maco> i *think* p0 p1 and p2 are all commonly tried, but umm..
[10:00] <maco> geser: ??
[10:00] <hyperair> quilt doesn't like -p0
[10:00] <maco> is there a reason p1 seems to be the favourite?
[10:01] <maco> ah ok thatd be why then
[10:01] <hyperair> it does seem to be standardized everywhere
[10:01] <hyperair> git diff does -p1
[10:01] <hyperair> among other things
[10:01] <maco> yeah i knew git diff did it
[10:01] <maco> thats how i got used to seeing a/ and b/
[10:01] <hyperair> and svn diff. and bzr diff
[10:01] <hyperair> dpatch seems to like -p0 though
[10:02] <hyperair> i remember having to add a/ and b/ to all the dpatch stuff when converting to quilt
=== fabrice_sp_ is now known as fabrice_sp
[10:02] <maco> nigel_nb: ok so i guess the answer is "because everyone else likes it"
[10:02]  * hyperair lol
[10:02] <hyperair> +s
[10:02] <nigel_nb> wat i meant is, u've just taken a and b randomly?
[10:02] <maco> yah
[10:03] <hyperair> you can put anything in front
[10:03] <maco> you add another level because tools like that extra level
[10:03] <nigel_nb> clear now :)
[10:03] <hyperair> -p1 means the first part is stripped away
[10:03] <nigel_nb> ah
[10:03] <hyperair> you can even use ./
[10:03] <maco> a and b are just because im used to seeing a & b because of using git
[10:03] <nigel_nb> so doesn't matter what is put there as long as there is something
[10:03]  * hyperair nods
[10:03] <maco> yep
[10:03] <hyperair> for p1 patches yes
[10:04] <hyperair> i think traditionally -p1 patches were used because then you'd know it's to be applied from the root of the source directory
[10:05] <shiki-> geez... REVU says it should have watch file. Okay, added one. now it says it should NOT have since its a native package. So?...
[10:05] <maco> shiki-: it should have a watch file
[10:05] <shiki-> okay then.. I'll ignore the warn
[10:05] <nigel_nb> maco: okay, made the changes to diff and saved it
[10:06] <hyperair> more like you shouldn't be creating native packages
[10:06] <maco> nigel_nb: ok  and if you re-run that patch command, it comes out happy?
[10:06] <geser> maco: I just looked at the original diff: the .orig in the filename isn't the problem, the problem is that the patch was made against the installed binary package and not the source
[10:06] <maco> hyperair: exactly
[10:06] <shiki-> theeen..what the heck should I do ? ..Im aldy lost in the buntu labyrinth
[10:06] <maco> geser: oh yeah we got that part already ;-) i just wasnt sure if the .orig mattered or not
[10:06] <hyperair> shiki-: make sure your .orig.tar.gz is around
[10:07] <hyperair> shiki-: if it isn't, then it'll end up creating a native package
[10:07] <maco> geser: we've just been discussing what the actual paths to the files should be and discovering that find is a useful thing to remember exists :P
[10:07] <nigel_nb> maco: not really, Hunk #1 FAILED at 27.
[10:07] <shiki-> uhm... sure. and how to create a .orig.tar.gz ? ... (sorry Im totally confused ^^")
[10:08] <nigel_nb> maco: the fact that find exists was useful, though we both didn't really use it ;)
[10:08] <maco> nigel_nb: oh? pastebin your current version of the diff?
[10:08] <maco> nigel_nb: ...there arent 27 line
[10:09] <hyperair> shiki-: where did you get the source code from?
[10:09] <nigel_nb> its probably line 27 of one of the files that we're modifying?
[10:09] <shiki-> well..from the person who makes the app.. a sourceforge page
[10:09] <maco> nigel_nb: youre probably right
[10:09] <shiki-> I used a "Debianized" source to create the PPA packages.. which successfully built, and they work flawless
[10:09] <shiki-> but if I get the pure source, debianize it, I end up the same way.. it will be a native package
[10:10] <nigel_nb> maco: http://paste.ubuntu.com/330962/
[10:10] <maco> shiki-: are you using debhelper?
[10:10] <shiki-> now? nope .. now I just used simple debuild and manual edit
[10:10] <geser> I this case I wouldn't try converting this patch into quilt but make a new quilt patch and edit this few lines by hand
[10:11] <shiki-> (yeah I know the standards, always building the package on my machine first with pbuilder)
[10:11] <maco> i wondr if the indentation change on "self.vm.register_setting_group(group)" matters...it may
[10:11] <maco> geser: the package doesnt use quilt
[10:12] <maco> geser: im told not to add patch management systems to packages that dont already have them
[10:12] <geser> oh it doesn't?
[10:12] <maco> it has no debian/patches/ ...
[10:12] <maco> nope, no quilt in debian/control
[10:13] <geser> interesting as vm-builder has quilt in it's build-depends
[10:13]  * maco re-reads
[10:13] <maco> heh i cant read
[10:13] <maco> q on one line, uilt on the next...what thats not quilt!
[10:14] <geser> it's even enabled in debian/rules
[10:14] <maco> why would it have quilt if it doesnt have debian/patches/ ?
[10:14] <hyperair> it could be elsewhere
[10:14] <hyperair> or it could be leftover from when patches existed
[10:15] <shiki-> maco: where should I start? can you point me to a "start point"? (how should I prepare this stuff...)
[10:15] <maco> i half feel like this lack of reading skills means bedtime and other half feels like "what? it can go elsewhere? oooh tell me!"
[10:15] <maco> geser: do you wanna take over? im not sure i wanna explain quilt at 5am when i havent used it in 2 months
[10:16] <nigel_nb> maco: its 5 am?
[10:16]  * hyperair heads into a corner and laughs
[10:16] <maco> where i am, yes
[10:16] <nigel_nb> what are you doing anywhere other than bed?
[10:16] <maco> being on irc?
[10:16] <geser> I'd but I'm busy myself now, so don't have time, sorry
[10:16] <nigel_nb> there's thing called sleep that human beings need.....
[10:16] <maco> yeah i know...
[10:17] <maco> particulary when i have to be up in 3 hours
[10:17]  * hyperair has seen the sunrise quite a few times this month..
[10:17] <hyperair> prior to going to bed
[10:17] <nigel_nb> hyperair: i see it everyday, I work nights :P
[10:17] <hyperair> meh
[10:17] <hyperair> nocturnal being eh =p
[10:17] <nigel_nb> maco: hit the bed.  we'll continue this another day?
[10:17] <maco> it was only 4am when i came in here!
[10:17] <maco> heh ok
[10:17] <nigel_nb> hyperair: I get scared sleeping at night now
[10:17] <hyperair> hmm scared of the dark are we?
[10:18] <nigel_nb> hyperair: been 2.5 years since i slept in the dark
[10:18] <hyperair> O_o
[10:18] <hyperair> i sleep... regardless of whether there is light
[10:18] <hyperair>  lecture theatres suit me best
[10:18] <nigel_nb> now, I do too :P
[10:18] <nigel_nb> cubicles are better
[10:19] <nigel_nb> maco: when are you on irc generally?
[10:19] <nigel_nb> maco: first thing, which tz are you on?
[10:19] <maco> nigel_nb: eastern US
[10:19] <nigel_nb> Dc right?
[10:19] <maco> 1500-700 UTC, id say
[10:19] <maco> yes
[10:20] <hyperair> what kind of timezone is 1500-700 UTC?
[10:20] <nigel_nb> its not tz, its her irc timings
[10:20] <hyperair> oh
[10:20] <hyperair> heh
[10:20] <nigel_nb> hold on, lemme get that to my tz
[10:22] <nigel_nb> maco: I'll be on at around 0130 UTC to 0700 UTC
[10:22] <maco> ok so evening for me
[10:22] <maco> im gonna sleep now. bye bye
[10:23] <nigel_nb> bye, night
[10:23] <hyperair> have a good sleep
[10:23] <nigel_nb> dont come back soon :P
[10:23] <maco> haha
[10:24] <nigel_nb> someone kick her out :D
[10:24] <maco> im gone im gone!
[10:24] <maco> see away message and everything!
[10:44] <shiki-> back... just had a full KDM/plasma/KDE crash ^^
=== azeem_ is now known as azeem
[12:55] <Mailaender> I prepared GNOME-chemistry-utils 0.10.9 debdiffs: https://bugs.launchpad.net/ubuntu/+source/gnome-chemistry-utils/+bug/233963
[12:55] <ubottu> Launchpad bug 233963 in gnome-chemistry-utils "Please merge gnome-chemistry-utils 0.10.9-1 (universe) from Debian testing (main)" [Wishlist,Confirmed]
=== emma_ is now known as emma
[14:20] <xee> Hi, I'm trying to follow the guide https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate but I'm facing problems, is this the right channel to ask?
[14:24] <maco> yes
[14:26] <xee> well, I'm just trying to create a deb of a newer version of a library but I get an error when running pbuilder, which should create the binary if I understand correctly
[14:26] <xee> it says E: failed to find /var/cache/pbuilder/base.tgz, have you done <pbuilder create> to create your base tarball yet?
[14:27] <av`> xee, you didnt create the tarball or you specified a wrong --basetgz path
[14:27] <xee> I just followed the guide above, I don't know much about debian packaging
[14:27] <av`> xee, start with pbuilder create --distribution whatever --basetgz /what/ever/path --mirror http://a.good.mirror.for.you.com
[14:28] <av`> xee, then wait for it to be done
[14:28] <av`> xee, then you can pbuilder build foo.dsc
[14:28] <av`> remember to specify the path you choose with --basetgz
[14:28] <av`> xee, so it will look like
[14:28] <xee> that's the path to the original source tarball, right?
[14:29] <av`> xee, pbuilder --basetgz /path/you/choose build foo.dsc
[14:29] <av`> xee, no
[14:29] <av`> xee, that's a random path to store the distro tarball
[14:29] <av`> xee, what pbuilder does it unpacking that tarball and then builds your package into a clean chroot
[14:30] <av`> xee, but can even be used to log in and test stuff there too
[14:31] <xee> ok thx, I'll try and get back to you
[14:31] <av`> ok, perfect :)
[15:12] <xee> av`: now when I do the build command I get the error mentioned here http://paste.ubuntu.com/331116/
[16:08] <keffie_jayx> hello, I just generated a debdiff and it complains about not being able to validate my gpg key, should I worry about that?
[16:09] <Laney> nope
[16:09] <keffie_jayx> thanks
[16:15] <LucidFox_> Hmm.
=== LucidFox_ is now known as LucidFox
[16:15] <LucidFox> This Qt4 app does a lot of qDebug << logging, resulting in the console being cluttered with debug messages.
[16:16] <LucidFox> What would be the cleanest way to disable it at package build? (It uses cmake.)
[16:17] <LucidFox> Hmm, apparently it's accomplished by ADD_DEFINITIONS(-DQT_NO_DEBUG), but can it be done on the cmake command line without patching CMakeLists.txt?
[16:33] <ScottK> Anyone with a Debian chroot that has gcc4.4 from experimental?
[16:34] <geser> DktrKranz: re the udt problem: wouldn't it be better to change line 78 of lpapicache.py to "isinstance(data, basestring)"? that would catch data being str or unicode
[16:44] <DktrKranz> geser: good idea, I'll try that
[16:54] <Laney> wgrant: I hassled you about this a while ago, but any chance of an MDT lucid <-> sid instance?
[16:54] <Laney> (I could do it myself if you want to give me access to the box)
[17:00] <Laney> anyone have access to the mdt configuration that's running on ubuntuwire atm?
[17:00] <Laney> siretart: ?
[17:49] <nigel_nb> maco: back after the nap?
[18:56] <siretart> Laney: yes. please write me a mail with your launchpad id. make sure that you have registered an ssh key
[18:57] <Laney> coming up
[18:58] <Laney> siretart: sen t
[19:24] <akheron> LucidFox: I made the fixes you suggested: http://revu.ubuntuwire.com/p/jansson
[19:25] <LucidFox> Nice. Going to sleep now, though.
[19:30] <akheron> :)
=== stgraber_ is now known as stgraber
[19:42] <siretart> Laney: okay, now please try to login
[19:43] <Laney> siretart: what's the host?
[20:27] <siretart> Laney: err, the revu host?
[20:34] <Laney> siretart: doesn't work
[20:47]  * jdong scratches head at the new handbrake buildsys
[20:54] <xee> I'm trying to upgrade a package to a newer upstream version but I'm getting an error when running pbuilder
[20:55] <xee> the output of pbuilder is http://paste.ubuntu.com/331297/ , the error is in the last 10 lines
[21:01] <xee> the error is: dh_movefiles: debian/tmp/usr/lib/libfribidi.so.0.0.0 not found (supposed to put it in libfribidi0)
[21:39] <geser> look at line 436
[21:39] <geser> looks like the lib changed the minor version
[21:45] <xee> ok so I should just change debian/*.files?
[21:45] <geser> yes
[21:46] <geser> but as I'm no library packaging expert, something more might be needed too
[21:46] <xee> ok thx, I'll give it a shot
[21:47] <RAOF> You'll almost certainly need to touch the shlibs file, too, if upstream has bumped a version.
[21:47] <xee> RAOF: I'm new to packaging, where's that file and what do I need to do to it?
[21:48] <RAOF> xee: Library packages are special (and more complicated).  The shlibs file (in debian/ along with the rest of the packaging) basically tells dpkg how other packages should depend on your library.
[21:50] <RAOF> If upstream has bumped a version it's likely that either (a) the ABI has changed in an incompatible way, in which case you need to do all sorts of stuff, or (b) there are new symbols exported by the library, in which case you need to change the shlibs file to say ">= current version".
[21:51] <RAOF> xee: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html is a less rough-and-ready description of what needs to be done for library packaging.
[21:51] <xee> actually I have installed it manually(configure; make install) with no visible problems, and it worked well for the purpose I have installed it for
[21:52] <xee> so I'm a bit confident and will give it a shot at least
[21:53] <RAOF> xee: That depends a bit on what you've actually used it for; if the SONAME has changed then you can happily build & install it, but nothing will use it without a rebuild.
[21:54] <xee> yes but it worked properly after I installed it(and I got new functionality)
[21:54] <RAOF> Hm.  That packaging guide needs updating for multiarch.
[21:55] <ajmitch> RAOF: many things probably need updated for multiarch
[21:55] <xee> I think this is bigger than I can handle, can I make a packaging request for the newer version or something?
[21:55] <nhandler> Isn't there a recipe somewhere on the wiki for packaging an app that where upstream maintains it in bzr without formal tarball releases? I'm having trouble finding the page
[21:55] <RAOF> xee: Yes.  Library packaging is significantly more complex than app packaging.  File a bug against the package.
[21:56] <xee> ok, I'll do this, thx
[22:20] <lfaraone> Can I tell cdbs to regenerate configure since upstream's sources lack it?
[22:33] <Laney> yep
[22:34] <lfaraone> Laney: okay, how would I do that?
[22:34] <lfaraone> Laney: in my case, I need to run "autogen.sh"
[22:35] <Laney> there's some variable you set
[22:35] <Laney> DEB_AUTO_UPDATE_* iirc
[22:46] <jgoppert> i'm using uscan to update gdal1.5 to gdal1.6 for my ppa, what do i do at this prompt? --------------------------
[22:46] <jgoppert> |--- gdal-1.5.4.orig/debian/patches/00list
[22:46] <jgoppert> |+++ gdal-1.5.4/debian/patches/00list
[22:46] <jgoppert> --------------------------
[22:46] <jgoppert> File to patch:
[22:51] <jgoppert> http://pastebin.com/m6b17ff1b, can anyone help?
[22:52] <bddebian> You are trying to patch a file under debian/ ?
[22:54] <jgoppert> no, i'm trying use uscan to update the gdal package to 1.6
[22:55] <jgoppert> i don't understand why its asking for a file to patch, i've never used uscan before, just got my watch file to work on my other project
[22:55] <bddebian> I never use uscan personally, sorry
[22:56] <jgoppert> ok thanks anyway
[22:56] <bddebian> I always just pull the new tarball rename it, extract it and copy in the old debian/ dir.
[22:58] <RAOF> jgoppert: uupdate might work better; it handles the directory rename (which I think is what's killing you there).
[22:58] <jgoppert> thanks RAOF, just checking out the man page on it :-)
[23:07] <RAOF> You know, it might be nice to implement the session org.freedesktop.PackageKit daemon in aptdaemon.  It looks fairly simple.