[02:34] <dnyy> Anyone care to help me figure out why I'm getting these errors while trying to build a package?
[02:36] <nhandler> dnyy: What errors?
[02:38] <dnyy> http://pastie.org/368082 It's the whole log, but the errors are more towards the bottom.  Some saying it can't find pkg-config and others saying theirs errors in the source when I'm almost certain there's not. ;/
[02:39] <dnyy> This is my first time building, so I'm a bit clueless as to what all these errors are trying to tell me.
[02:44] <nhandler> dnyy: It does look like it is a problem in the source
[02:45] <dnyy> it built/installed good using debuild though, and without trying to include the dependencies. :/
[02:46] <dnyy> it's just when trying to add those that i get the errors (with both pbuild and debuild)
[02:47] <nhandler> dnyy: What do you mean by "and without trying to include the dependencies"?
[02:48] <dnyy> to use the app you need to have libmad0-dev and libao-dev installed, but adding those to /debian/control gives me that huge list of errors.
[02:49] <nhandler> dnyy: The Dependencies should not affect whether or not the package builds. Only Build-Depends should be installed by pbuilder to build the package
[02:50] <dnyy> Hm, so I wonder why it's not building then. Maybe I'm making an error in the way I try to include the dependencies(syntax and whatnot), or does that not matter since it doesn't use those while building?
[02:50] <nhandler> dnyy: It shouldn't matter. Are your Build-Depends correct?
[02:51] <tomhinkle> I'm an upstream developer interested in releasing .debs for my users (Ubuntu packages are too slow for those who want the bleeding edge, and .debs are convenient packages for many users to test out). My app is packaged in ubuntu, but I can't seem to figure out where the debian/ directory lives in launchpad... where do I find the packaging stuff?
[02:51] <dnyy> nhandler: Can I paste you the control file?
[02:52] <maxb> dnyy: It would appear from your paste that it is trying to run pkg-config, but failing. You should add a Build-Depends for it
[02:52] <dnyy> The build-depends is where I'm putting the 'libmado-dev, libao-dev, etc
[02:53] <dnyy> Hm, I'll give that a go real quick.
[02:53] <nhandler> tomhinkle: Go to launchpad.net/ubuntu/+source/SOURCENAME
[02:53] <nhandler> dnyy: Yeah, go ahead and pastebin it
[02:53] <dnyy> http://pastie.org/368414
[02:54] <nhandler> dnyy: Are those packages really needed for the package to build?
[02:54] <dnyy> Well, they are listed as so in the source package from the ubuntu repos.  This is the newer/dev version.
[02:55] <dnyy> autoconf and automake made me wonder, but I figured if it was included in the source they must be. :/
[02:56] <nhandler> dnyy: If the package is already in Ubuntu/Debian, there is no need to package it again to get a newer version added
[02:57] <dnyy> Well I'm packaging it for personal use and for the crunchbang (ubuntu-based distro) repos.
[02:57] <nhandler> dnyy: I would contact the Debian Maintainer and see if he has plans to update the version of shell-fm in Debian. If they do that, we can sync the changes
[02:57] <nhandler> dnyy: If you are packaging it for personal use, you still don't need to start from scratch
[02:58] <dnyy> Well how could I go about updating the older deb and repackaging?
[02:58] <nhandler> dnyy: Download the source package from Jaunty using dget, pull-lp-source, or apt-get source. Then, download the .tar.gz for the newer upstream version. Then, use uupdate.
[03:00] <dnyy> Hm, doing that now then.  What do you mean use update? ;o
[03:03] <nhandler> uupdate is a tool in the devscripts package
[03:03] <dnyy> kk, looking it up
[03:07] <dnyy> does the tar.gz of the upstream need to be in the same folder as the source? i notice i have to be in the source top dir to run uupdate or will it look above the current dir?
[03:08] <nhandler> I normally run uupdate from the source directory (the one that contains the debian directory). I run it like 'uupdate ../foo_x.y.orig.tar.gz'
[03:09] <dnyy> aah, kk
[03:09] <dnyy> then just pbuild the new dir?
[03:10] <nhandler> Then cd into the new directory and make sure the changelog is correct. debuild -S -sa and build in pbuilder
[03:10] <maxb> wow, this package sure has changed a lot since the jaunty version
[03:10] <nhandler> maxb: What package?
[03:11] <maxb> shell-fm, that dnyy is working on
[03:11] <nhandler> maxb: Ok. I didn't even look at the changes. I just saw that we auto-synced from Debian
[03:11] <dnyy> what version is in the jaunty repos? same as the intrepid ones?
[03:12] <maxb> lyes
[03:12] <nhandler> Yes dnyy
[03:12] <nhandler> svn20071125.r282-1
[03:12] <dnyy> ah, yuh
[03:12] <dnyy> I didn't know 'til yesterday it had been worked on so much
[03:13] <tomhinkle> nhandler: Thanks for the pointer. I think I've found what I needed...
[03:13] <nhandler> Glad to hear that tomhinkle
[03:14] <dnyy> nhandler: http://pastie.org/368425 Is my fakeroot broke?  I seem to get a lot of errors about it, too. :/
[03:16] <nhandler> dnyy: Can I see your debian/rules?
[03:17] <dnyy> http://pastie.org/368428
[03:17] <maxb> dnyy: No, the problem is that the package has *completely* changed its buildsystem upstream, and debian/rules needs a significant overhaul
[03:19] <dnyy> ah, well shucks.  I don't think I'm anywhere near knowledgeable enough to do that.
[03:19]  * nhandler seems to remember suggesting contacting the DM
[03:19] <dnyy> :P
[03:19] <dnyy> seems like that's what i'm gonna have to do.
[03:20]  * maxb has been idly fiddling with it just now, following along with the problems, let me paste a debdiff of what I've got
[03:21] <dnyy> kk.  I'd really like to do this without getting the DM to do it, as it'd be a nice learning experience.
[03:25] <maxb> http://pastie.org/368432
[03:25] <maxb> it's a start
[03:26] <maxb> there's obvious things that I haven't touched, like the fact that the upstream ships a shell-fm.1 manpage now, which would need to be reviewed against the one shipped in debian/
[03:26] <maxb> upstream has also apparently dropped the example rc file that was previously shipped
[03:27] <maxb> and they could really do with being told that they're misusing DESTDIR in a
[03:27] <maxb> * and they could really do with being told that they're misusing DESTDIR against all common convention
[03:28] <dnyy> yeah. this is all pretty new to me, but basically I need to go through and see whats different between the uupdate version and the upstream version, and clean things up in the uupdate to match the upstream?
[03:37] <maxb> dnyy: erm, I didn't really understand that sentence
[03:38] <dnyy> haha, I'm horrible at explaining myself.  What I mean is; In order to get things working, do I need look through the 0.4 source and the 0.6 source, find the difference, and then remove them from the package that uupdate creates?
[03:39] <dnyy> remove the differences, i mean
[03:39] <maxb> uhm. If you remove the differences that the update creates, you'll be back at 0.4
[03:40] <dnyy> oh wait, duh. ;(
[05:38] <dholbach> good morning
[05:38] <fabrice_sp> Good morning dholbach. a bit early today ;-)
[05:39] <dholbach> hi fabrice_sp
[05:39] <dholbach> yeah, woke up early today :)
[05:40] <fabrice_sp> no real activity here at this time :-)
[05:49] <ScottK> dholbach: It's REVU day.  Please dive in.
[05:50] <dholbach> ScottK: I try to do a few today, but I'm completely drowning in work right now :-/
[05:50] <dholbach> I like the discussion on the MOTU list about REVU and automated checks - that'd be awesome
[05:50] <fabrice_sp> And if you want to begin with an already advocated one, you can have a look at dvdstyler (http://revu.ubuntuwire.com/details.py?package=dvdstyler). This package only miss one advocate :-)
[05:56]  * persia reviews foo-plugins
[06:05]  * persia reviews gebabbel
[06:08] <persia> Anyone running Kubuntu jaunty and has a GPS unit?
[06:11] <ScottK> I think most of the likely candidates are sleeping.
[06:12] <persia> Probably.  Pity, as I can't test this and don't like to advocate without having tested.
[06:12] <coppro> http://revu.ubuntuwire.com/details.py?package=metakit
[06:16] <ScottK> persia: I found one with Kubuntu Jaunty, but not a GPS.
[06:16] <ScottK> persia: rgreening says hi.
[06:17] <persia> heh :)  It's a GPS tool though, and as we've so few of those that work, I'd rather it actually work.
[06:17] <persia> Worst case, maybe mok0 tested it for the previous advocation, in which case I can push.
[06:18] <ScottK> Perhaps you can at least make that assumption ...
[06:19] <persia> I'll still be about when mok0 wakes: a few hours of double-advocation pre-upload won't be significant when compared against the months it's been in queue
[06:41] <tritium> Is there a simple example of source package that builds both a binary and shared library using CDBS that you could recommend?
[06:43] <persia> tritium, wildmidi does that
[06:43] <tritium> persia: thanks!
[06:44] <persia> tritium, I can't promise it's a perfect example, but at least it's an example
[06:44] <tritium> I'm sure it's better than nothing.  :)
[07:46] <hyperair> mok0: sorry i forgot to upload bansheelyricsplugin this morning. i missed out the 'revu' argument to dput. realized it when i woke up
[08:09] <mok0> hyperair: yeah I noticed, will take a look a bit later today
[08:34] <didrocks> morning
[08:35] <somaunn> didrocks: hi
[08:36] <didrocks> Hi somaunn
[09:33] <verwilst> hellow
[09:33] <verwilst> if i have a package version like -1.0-1
[09:33] <verwilst> and i want to make my own changes and make it be considered higher than the original
[09:34] <verwilst> -1.0-1~verwilst1 for example won't cut it, right?
[09:34] <StevenK> -1?
[09:34]  * StevenK twitches
[09:34] <DktrKranz> 1.0-1~verwilst1 is lower than 1.0-1
[09:34] <persia> verwilst, Right.  Try +verwilst1
[09:34] <StevenK> -1.0-1~verwilst1 will be lower, since ~ sorts lower than ''
[09:40] <saschpe> Hi y'all, I uploaded a new upstream version package for "crawl" and request approval, as I'm no MOTU. Bug no.: #320142
[09:40] <iulian> bug #320142
[09:42] <verwilst> persia: is +verwilst1 debian-legal? :)
[09:42] <persia> verwilst, How do you mean?  The tools support it.  The ftp-masters would get grumpy if you uploaded it, and tell you to use -1.1 and do an NMU, or work with the maintainer.
[09:44] <iulian> saschpe: You don't need to upload it to revu, just upload diff.gz to launchpad.
[09:44] <saschpe> iulian: oops, sorry. thought I'd read that that's the way to do
[09:45] <quadrispro> hi maxb ! following your good suggestions, I've uploaded a new w-scan package. I want to thank you for your feedback, let me know if you see something wrong :)
[09:46] <quadrispro> maxb -> http://revu.ubuntuwire.com/details.py?package=w-scan
[10:38] <Quintasan> The pbuilder installs same -dev packages everytime I compile something, this is done on purpose or I'm doing something worng?
[10:39] <persia> Quintasan, Assuming you're compiling similar things, it's on purpose.
[10:39] <persia> If this takes a while, or you have download caps, you might consider using a package cache so pbuilder only downloads new ones.
[10:41] <Quintasan> persia: thanks
[10:41] <broonie> The download cache is the default.
[10:42] <persia> Quintasan, The reason it does this is that it downloads the set of packages listed in Build-Depends (and their dependencies) to build the package, and let the packager specify the target environment.  This takes a little longer, but allows the packager to ensure the builds are repeatable.
[11:29] <snuitje> Hello, I don't know if this is the right place to ask, but I have to backport packages from Jaunty to 8.04 and I was wondering if there's already a tool that can help automating it
[11:29] <Hobbsee> prevu
[11:30] <snuitje> kewl, thanks =)
[11:34] <Hobbsee> no guarentees on it actually working, but it'll try
[11:36] <thekorn> hi motus', I try to dive into packaging a python tool, and I get this error:
[11:37] <thekorn> E: launchpad-shell source: missing-python-build-dependency
[11:37] <thekorn> so my question is: what's missing there?
[11:38] <thekorn> I compared my control file to other packages, some have 'python' and some have 'python-all-dev'
[11:38] <thekorn> which one is the way to go?
[11:39] <POX> you're missing one of: "python{,-dev,-all,-all-dev} (>= 2.3.5-11)" in Build-Depends: or Build-Depends-Indep:
[11:39] <POX> -dev if you're building arch:any package, -all if you're building a module
[11:40] <POX> python (without -add or -dev) if it's application
[11:41] <POX> if it's arch:any, python-all-dbg should be in Build-Depends: as well (unless you're not building -dbg package)
[11:41] <thekorn> thanks POX, so I will go with python for this small app
[11:42] <POX> thekorn: lintian -i *changes
[11:42] <Tonio_> hi there...
[11:42] <Tonio_> anyone free to give a look at http://revu.ubuntuwire.com/details.py?package=k3b
[11:42] <Tonio_> thanks :)
[11:42] <thekorn> POX, no output, so it's working now, thanks again
[11:43] <directhex> Tonio_, ehm... k3b's already in the archive, surely?
[11:43] <directhex> http://packages.ubuntu.com/source/jaunty/k3b
[11:43] <POX> thekorn: I meant lintian will be more verbose if you turn verbose mode on (-i)
[11:43] <Tonio_> directhex: yeah, but that's major packaging rewrite, as this is the kde4 version
[11:43] <Tonio_> directhex: I could upload it like this, but a second pair of eyes is always welcome :)
[11:44] <directhex> they should rename it k4b imho ;)
[11:44] <Tonio_> directhex: goob point :)
[11:44] <POX> thekorn: of use lintian-info :)
[11:44] <POX> s/of/or
[11:45] <thekorn> POX, hmm, is there a way to pass this -i through debuild?
[11:45] <POX> thekorn: lintian-info -t missing-python-build-dependency
[11:46] <POX> debuild has a --lintian-opts
[11:46] <thekorn> wow, that's nice
[11:53] <saschpe> directhex: k3b means "KDE Burn Baby Burn" and is not directly related to KDE3 :-)
[11:54] <directhex> saschpe, so rename it "KDE Better Burn Baby Burn" anyway!
[12:01] <snuitje> what's the best way to keep updated on new uploads of certain packages to certain releases, like intrepid and jaunty?
[12:01] <snuitje> so i can keep feeding prevu
[12:03] <snuitje> i tried using package-import.ubuntu.com but the server is kinda shoddy
[12:03] <snuitje> it gives regular proxy errors
[12:04] <james_w> snuitje: launchpad will soon provide two things, package feeds, and package branches
[12:04] <snuitje> package feeds as in rss?
[12:04] <james_w> the first will allow you to subscribe to feeds of uploads for packages
[12:05] <james_w> the other will be pretty much the same as what you are trying to do but more robust
[12:05] <snuitje> kewl :)
[12:06] <snuitje> well thanks, i'll keep an eye out :)
[12:08] <persia> snuitje, In the meantime, there are the -changes mailing lists (see lists.ubuntu.com) which send an email for each upload.
[12:08] <snuitje> okay
[12:09] <snuitje> btw, woohoo prevu worked flawlessly :) already installed my 1st automatic backport, goodbye pdebuild and friends (except for ppa packages) =)
[12:10] <maxb> prevu is just a thin wrapper on pbuilder
[12:11] <snuitje> yes, but looking up the dsc url, then doing the dget -x, pdebuild etc dance is such a hassle
[12:11] <maxb> Really, I'd recommend learning to use pbuilder directly, because then you can use cowbuilder, which vastly speeds up the process by eliminating the tar.gz unpack step
[12:12] <maxb> snuitje: "pull-lp-source mypackage jaunty"
[12:13] <hyperair> jpds: ping
[12:15] <snuitje> hm, i dont have that...
[12:15] <hyperair> jpds: thanks for the comments. regarding sigx, i've fixed removed NEWS from debian/docs, and shifted the rest of the stuff from debian/docs to debian/libsigx-2.0-doc.docs. there's a new upload at revu. if you could look at it, i'll be very grateful =p
[12:16] <maxb> snuitje: apt-get install ubuntu-dev-tools
[12:20] <snuitje> maxb: i did, but it must've come after 8.04
[12:20] <snuitje> so i'll prevu it ;) ;)
[12:23] <snuitje> prevu even managed to build despite tha fact that the new packages use a later debhelper, now that's good work
[12:27] <maxb> *shrug*. That just comes from having the package available in hardy-backports for just this reason
[13:36] <snuitje> maxb: of course, i haven't thought of that >.< thanks, i upgraded the package with an apt preferences exception :) thanks!
[14:18] <slytherin> jdong: any idea how to disable the auto update in azureus?
[14:26] <snuitje> Hello, I prevu'ed ubuntu-dev-tools and ran apt-get update, but apt-get dist-upgrade wants to keep it at the 8.04 version, how can apt be configured to upgrade to prevu packages?
[14:27] <snuitje> btw, it did work for another package
[14:27] <snuitje> no wait
[14:29] <snuitje> yes, it did work for 2 other packages
[14:29] <snuitje> lsb and lighttpd
[14:29] <snuitje> (lsb-release)
[14:29] <slytherin> snuitje: what is prevu?
[14:30] <snuitje> it's a tool to backport packages from Ubuntu+1 to Ubuntu or Ubuntu-1, etc
[14:31] <vorian> its a pbuilder wrapper
[14:31] <slytherin> snuitje: oh, I was not aware of that. What is the version number you have specified for the backported package?
[14:31] <snuitje> the version numbering is automatic, but it's 3.2-14ubuntu2~8.04prevu1
[14:31] <snuitje> and the 8.04 version is 3.2-4ubuntu1
[14:33] <slytherin> snuitje: is the backported package available in some repository?
[14:33] <snuitje> of course
[14:34] <snuitje> prevu does that ^-^
[14:34] <snuitje> oh wait
[14:35] <snuitje> the new version is 0.59~8.04prevu1 the old one is 0.30
[14:35] <slytherin> snuitje: I don't see a problem here with version number. Have you verified if all the dependencies are present in hardy?
[14:38] <snuitje> OIC, why didn't i think of that -_-'''
[14:38] <snuitje> python-launchpadlib is missing ^-^
[14:38] <snuitje> ty
[14:50] <binarymutant> if anyone has anytime to review my package, http://revu.ubuntuwire.com/details.py?package=charm, I would be greatly appreciative. Thanks :)
[14:54] <mok0> binarymutant: I'll bite
[14:54] <mok0> binarymutant: what's it for?
[14:54] <binarymutant> charm is a blogging software for the console/terminal
[14:55] <mok0> binarymutant: ah! Charming! :-)
[14:55] <binarymutant> :)
[14:56] <mok0> binarymutant: wow, you've been through quite many cycles
[14:56] <binarymutant> yeah 2 versions, I had to get a couple of patches uploaded to it
[15:01] <mok0> binarymutant: you know how to use the patch system?
[15:02] <binarymutant> yes, I had been using dpatch but took it off because my  patches were included in the source
[15:02] <mok0> binarymutant: I
[15:02] <Chris`> Any revu'ers free to check my package? I require just one more advocate :D
[15:02] <mok0> binarymutant: I'd like you to include a patch then :-)
[15:03] <binarymutant> :*(
[15:03] <mok0> binarymutant: ... to get it perfect
[15:03] <binarymutant> right, what is it?
[15:03] <mok0> binarymutant: there's a number of hyphen-used-as-minus errors in upstream's manpage
[15:04] <mok0> I paste a script to fix it: http://pastebin.com/f11c8da4e
[15:05] <binarymutant> what's hyphen-used-as-minus mean?
[15:05] <mok0> binarymutant: the minus character is used for options, for example --help, that needs to be typeset in nroff like this \-\-help
[15:06] <mok0> binarymutant: you can't see it when the man page is shown in a terminal, but if it's printed you can
[15:06] <binarymutant> in charm.1?
[15:06] <mok0> right
[15:06] <vadi21> Hi, I have a quick question about .desktop files - how can I make one use an .svg? I placed the svg with the corresponding name into /usr/share/icons/hicolor/scalable/apps, .desktop into /usr/share/applications, but it does not want to associate the picture.
[15:07] <mok0> binarymutant: just run the fixhyphens < charm.1 > charm.fixed.1 and make the patch
[15:07] <binarymutant> k, I see it the double -- were hyphened but not the single -
[15:09] <binarymutant> anything else you can see mok0 ?
[15:11] <mok0> I
[15:12] <mok0> binarymutant: I've posted a message on the REVU page. Looking good...
[15:12] <hyperair> mok0: http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin =D
[15:12] <binarymutant> thanks mok0
[15:12] <mok0> hyperair: ha! ok
[15:12] <hyperair> mok0: =D thanks
[15:14] <mok0> hyperair: there!
[15:14] <hyperair> mok0: thanks =D
[15:15] <mok0> Ah I see MOTUs have been picking the low hanging fruit :-D
[15:19] <slytherin> what is the best way to merge a package from experimental?
[15:21] <mok0> slytherin: you mean without a grab-merge set?
[15:21] <Chris`> mok0: Busy? :D
[15:21] <mok0> Chris` ready for some reviewing action, what have you got?
[15:22] <slytherin> mok0: yes. I mean experimental merges are not available on MoM. ANd I want to avoid manual work as much as possible.
[15:22] <Chris`> http://revu.ubuntuwire.com/details.py?package=grdc & http://revu.ubuntuwire.com/details.py?package=grdc-gnome
[15:22] <hyperair> is any motu free to review bansheelyricsplugin? it's already got one advocate: http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
[15:22] <Chris`> mok0: All I need is one more advocate (if it is good enough)
[15:23]  * mok0 wonders why Chris`insists on having a backslash in his nick...
[15:23] <Chris`> mok0: A grave accent? ;p
[15:23] <Chris`> Just Ch<TAB> :)
[15:23] <mok0> a nuisance to type....
[15:24] <Chris`> My name used to be `Chris :)
[15:24] <mok0> Ch <Tab> = chillywilly Chipzz Chris` chrisccoulson
[15:24] <mok0> Uhuh now they all think the message is for them ;-)
[15:24] <chrisccoulson> yes
[15:24] <Chris`> Do Chr<TAB>
[15:24] <mok0> sorry chrisccoulson
[15:24] <Chris`> I will be the first :)
[15:24] <chrisccoulson> can i have that last 5 seconds of my life back? lol
[15:25] <Webspot> Hi. If I want to package something from a git repo, what should I use as the version number?
[15:25] <slytherin> Webspot: something like a.b+git<revision>
[15:25] <slytherin> mok0: any idea?
[15:25] <mok0> slytherin: not really
[15:26] <liw> Webspot, many people like to use the date; git doesn't really have revision numbers (it uses sha-1 instead)
[15:26] <mok0> slytherin: I don't know what software is used to generate those merge sets
[15:26] <Webspot> liw: Yeah. I thought the revision looked too long to use as a version number. Thanks.
[15:27] <liw> Webspot, more important than length is that the sha-1's aren't behaving like version numbers, you can't compare which one is the newer version
[15:27] <Webspot> liw: Oh yeah. So do I use a.b+git<date>?
[15:28] <slytherin> NCommander: any plan to update linux-image for powerpc?
[15:28] <mok0> Damn revu is slow
[15:29]  * jpds checks load levels.
[15:31] <jpds> OK; it sure is using a lot of its memory.
[15:32] <mok0> jpds: what's it doing?
[15:32] <liw> Webspot, a.b+git<date>.<32bitid> might be most illuminating
[15:33] <Webspot> liw: Ok. Thanks for your help :)
[15:33] <jpds> mok0: The usual, apache, postgresql, helper scripts.
[15:35] <jpds> mok0: I think this is more concerning tho: http://paste.ubuntu.com/108617/
[15:36] <mok0> Chris`, you know how to use the patch system?
[15:36] <Chris`> mok0: Not entirely but wiki.ubuntu.com exists to serve
[15:37] <mok0> Chris`, it's a t-i-n-y problem, not a blocker, but if you want to learn how to use the patch system...
[15:38] <Chris`> OK...
[15:38] <jpds> include /usr/share/cdbs/1/rules/simple-patchsys.mk
[15:39] <ScottK> man cdbs-edit-patch
[15:39] <mok0> Chris`,  desktop-entry-contains-encoding-key /usr/share/applications/grdc.desktop:3 Encoding
[15:40] <Chris`> mok0: What does that mean?
[15:40] <mok0> Chris`, there's an "Encoding" statement in there that is deprecated
[15:40] <mok0>  Chris` very common error
[15:40] <Chris`> So what should be done?
[15:41] <mok0> Chris` I can't seem to locate the .desktop file in the tree... know where it is?
[15:42] <Chris`> "No Name"
[15:42] <Chris`> Is the config file
[15:42] <Chris`> but no .desktop
[15:44] <mok0> Chris`, it's in src/grdc.desktop.in, it gets processed by configure to generate the final version
[15:45] <Chris`> grdc.desktop.in doesn't exist for me :-/
[15:45] <mok0> Chris`, in src/ ?
[15:46] <Chris`> When I run search, nautilus displays it as "No Name"
[15:46] <Chris`> ls found it though
[15:46] <mok0> Chris`, look using ls
[15:47] <Chris`> I am in the file using vim
[15:47] <Chris`> Any alterations?
[15:47] <mok0> Chris`, wait, not yet
[15:48] <mok0> Chris`, instead, edit your .bashrc file, and insert "export QUILT_PATCHES=debian/patches"
[15:49] <Chris`> Done
[15:49] <mok0> Chris`, source .bashrc
[15:49] <Chris`> Is that the same as . .bashrc?
[15:49] <Chris`> Done anyway 6
[15:49] <Chris`> ^
[15:50] <mok0> $HOME/.bashrc
[15:50] <Chris`> chris@chris-laptop:~$ $HOME/.bashrc
[15:50] <Chris`> bash: /home/chris/.bashrc: Permission denied
[15:50] <mok0> Chris`, now cd grdc-0.3
[15:50] <mok0> source $HOME/.bashrc
[15:51] <Chris`> Yeah I've done that
[15:51] <mok0> ok
[15:51] <mok0> Chris`, now cd grdc-0.3
[15:51] <Chris`> Yep
[15:51] <mok0> mkdir debian/patches
[15:51] <Chris`> Done
[15:51] <mok0> touch debian/patches/series
[15:51] <Chris`> Yeah
[15:52] <mok0> Try: quilt series
[15:52] <Chris`> chris@chris-laptop:~/motu/src/grdc-0.3.0$ quilt series
[15:52] <Chris`> chris@chris-laptop:~/motu/src/grdc-0.3.0$
[15:52] <Chris`> No output?
[15:52] <mok0> right
[15:52] <mok0> now we need to add a patch
[15:52] <Chris`> Sounds fun :)
[15:53] <mok0> so you go "quilt add 01-fix-desktop-entry.patch"
[15:53] <mok0> so you go "quilt new 01-fix-desktop-entry.patch"
[15:53] <mok0> sorry
[15:53] <Chris`> Ok done
[15:53] <mok0> now you add (register) a file to the patch:
[15:54] <mok0> quilt add src/grdc.desktop.in
[15:54] <Chris`> Ok done again
[15:54] <mok0> Good, now you can edit the desktop.in file and remove the Encoding line
[15:55] <mok0> After that, "quilt refresh"
[15:55] <Chris`> Remove the entire line from src/grdc.desktop.in?
[15:55] <mok0> yes
[15:55] <Chris`> Ok done
[15:55] <mok0> quilt refresh?
[15:55] <Chris`> Yeah
[15:55] <mok0> did it say anything?
[15:56] <Chris`> Refreshed patch 01-fix-desktop-entry.patch
[15:56] <mok0> yay
[15:56] <mok0> now look in the dir debian/patches
[15:56] <mok0> there should be a patch file and a series file
[15:56] <Chris`> Yeah two files
[15:56] <mok0> try "quilt pop"
[15:57] <Chris`> Removing patch 01-fix-desktop-entry.patch
[15:57] <Chris`> Restoring src/grdc.desktop.in
[15:57] <Chris`> No patches applied
[15:57] <mok0> Yes!
[15:57] <mok0> quilt push
[15:57] <Chris`> Now at patch 01-fix-desktop-entry.patch
[15:57] <mok0> Great, it works
[15:57] <Chris`> Sounds cool :)
[15:57] <mok0> All you need to do now is to add something to rules and to control
[15:58] <Chris`> Ok sure
[15:58] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek - last day going to kick off in #ubuntu-classroom now!
[15:58] <mok0> In debian/rules: include /usr/share/cdbs/1/rules/patchsys-quilt.mk
[15:59] <mok0> Chris`, and in control, add quilt to build-depends
[15:59] <Chris`> Et voilà
[15:59] <mok0> Chris`, in changelog, write "Patched to fix desktop file"
[15:59] <mok0> or something
[16:00] <ScottK> Chris`: And then when you can't remember how to do this remember than Googling for quilt patch debian first hit gives you a good howto.
[16:00] <mok0> ... and you get a lot of hits on sewing patchwork and quilt :-)
[16:00] <Chris`> How does dch -i work?
[16:00] <Chris`> I get changelog.dch
[16:00] <Chris`> But how to apply it?
[16:01] <mok0> er, just vi debian/changelog
[16:01] <mok0> dch -i adds a new version afaik
[16:02] <broonie> Chris`: Just edit the file dch -i gives you, when you quit the editor dch will overwrite debian/changelog with the new file.
[16:02] <Chris`> Alright uploading to revu, thanks mok0, ScottK & broonie
[16:03] <mok0> Chris`, finally, edit debian/control again
[16:03] <Chris`> Ah what? :)
[16:03] <Chris`> What I am editing in control?
[16:03] <mok0> Chris`, remove "a" in "a remote...." in the summary
[16:04] <Chris`> Ok changed :)
[16:04] <mok0> General note on package synopses (one-line descriptions:) they should start in l
[16:04] <mok0> owercase ("extract cluster data" versus "Extract cluster data",) and no precedin
[16:04] <mok0> g articles ("filter for generating HTML logs" versus "A filter for generating HT
[16:04] <mok0> ML logs.")
[16:05] <Chris`> I need to get jpds to give me the thumbs up again now :p
[16:05] <Chris`> After revu showsit
[16:05] <mok0> Chris` if he's around
[16:06] <Chris`> Doesn't look like :(
[16:06] <mok0> Chris` I good with his advocacy,
[16:06] <Chris`> http://revu.ubuntuwire.com/details.py?package=grdc --- Final stuff has been changes *Searches for advocates*
[16:06] <mok0> Chris` I don't think he'll remove it just because you've fixed some minor probs
[16:06] <jpds> mok0: Upload if you want to.
[16:07] <mok0> jpds: great thx
[16:07] <mok0> when I get the last fixes from Chris`
[16:07] <Chris`> mok0: Yeah they've all been submitted since the last comment
[16:07] <Chris`> 17:09
[16:07] <mok0> Chris`, just to repeat what you've done: https://wiki.ubuntu.com/PackagingGuide/Howtos/Quilt
[16:08] <Chris`> The time server is a bit out though, thanks mok0
[16:08] <mok0> I see it
[16:09] <mok0> Chris` you see, with the patch system, it is possible to fix all kinds of strange stuff in upstreams code
[16:09] <mok0> ... and you still keep your changes in debian/
[16:09] <Chris`> mok0: Pretty neat function
[16:09] <mok0> yeah
[16:10] <mok0> The other patch system is dpatch, but it requires a header on the patches which is extra trouble
[16:10] <refdoc> pochu - are you around?
[16:11]  * Laney likes the sound of piuparts
[16:11] <refdoc> I am trying to find out about libsword, gnomesword etc packages
[16:11] <refdoc> and someone said you were the last maintainer
[16:11] <refdoc> or uploader
[16:11] <Chris`> mok0: Did you say that you were uploading now or something?
[16:11] <ScottK> refdoc: Did you send us mail yesterday?
[16:12] <mok0> Chris`I am
[16:12] <mok0> Chris`doing final test build right now
[16:12] <binarymutant_> is it readme.source for info on patch systems?
[16:12] <Chris`> mok0: Cool awesome :)
[16:12] <Chris`> mok0: Will I get Karma points for fixing the LP bug?
[16:12] <Chris`> Or don't they count?
[16:12] <ScottK> They count.
[16:13] <mok0> Chris`, I am not sure
[16:13] <mok0> ah
[16:13] <Chris`> Cool, I've got ~700 so far
[16:13] <mok0> But they subtract some every day
[16:13] <refdoc> Scottk
[16:13] <refdoc> I did
[16:13] <Chris`> Only if your karma is over 6months old, mine isn't :D
[16:14]  * Laney eyes the new application process
[16:14] <Chris`> I've been gaining like 200day over the past 2 days
[16:14] <ScottK> refdoc: This is the team that maintains those packages for Ubuntu.
[16:14] <refdoc> Great
[16:14] <refdoc> I thought so.
[16:14] <ScottK> refdoc: That and about 10000 other source packages.
[16:14] <refdoc> I know :-)
[16:14] <refdoc> hence the personal approach :-)
[16:15] <ScottK> refdoc: One point from your mail: Not updating modules from an external source is considered a feature and not a bug in Debian and Ubuntu.
[16:15] <refdoc> There is a misunderstanding
[16:15] <refdoc> our "modules" are texts - ebooks
[16:15] <ScottK> Ah.
[16:15] <refdoc> we have 300 or 400 of them
[16:15] <refdoc> and growing
[16:15] <refdoc> some sell them
[16:15] <refdoc> this is like project gutenberg
[16:16] <ScottK> OK.  That wasn't clear in the mail.
[16:16] <refdoc> you would not want their 50.000 odd books in the repo?
[16:16] <ScottK> No.
[16:16] <ScottK> So you have two choices:
[16:16] <refdoc> so, no it is not about software update
[16:16] <ScottK> 1. Convince someone active in Ubuntu to update your stuff.
[16:16] <ScottK> 2.  Do it yourself.
[16:17] <refdoc> either, indeed.
[16:17] <sistpoty|work> hi folks
[16:17] <ScottK> txwikinger: Are you interested in helping refdoc with updating sword stuff?
[16:17] <ScottK> Hi sistpoty|work
[16:17] <sistpoty|work> hi ScottK
[16:17] <Chris`> ScottK: Is it easy?
[16:17] <ScottK> Chris`: Dunno.  I haven't looked at the packages.  Sometimes it's trivial, sometimes it's painful.
[16:18] <Chris`> ScottK: What's he need updating?
[16:18] <refdoc> We have some packages which work on new installs. I am jkust not sure how much they fullfill all rules
[16:18] <refdoc> libsword from 1.5.9 to 1.5.12
[16:18] <refdoc> gnomesword to 2.4.1
[16:18] <Chris`> refdoc: I'll give it a shot if you wish?
[16:18] <refdoc> I would be delighted!
[16:19] <refdoc> what do you want me to do?
[16:19] <refdoc> I am new to this
[16:19] <binarymutant_> if anyone has time on their hands I would appreciate a review on my package, http://revu.ubuntuwire.com/details.py?package=charm Thanks :)
[16:19] <Chris`> refdoc: Are you the upstream author?
[16:19] <refdoc> I am one of the lot - I am not a programmer
[16:19] <refdoc> but do documentation, translation etc
[16:20] <refdoc> but I got fed up
[16:20] <refdoc> and hence approached yoyu
[16:20] <refdoc> I have svn access to a lot
[16:20] <refdoc> and can do things
[16:20] <Chris`> Are we talking about libsword6 in the repos?
[16:20] <refdoc> yes
[16:20] <Chris`> Ubuntu ^
[16:20] <refdoc> and gnomesword and bibletime and diatheke
[16:20] <Chris`> refdoc: Is there a LP bug open?
[16:21] <refdoc> LP?
[16:21] <Chris`> LaunchPad
[16:22] <refdoc> there are a few
[16:22] <refdoc> all either referring to the fact that our programmes are old
[16:22] <refdoc> or stating that our (old) programmes have bugs
[16:22] <refdoc> indeed
[16:22] <Chris`> refdoc: Find me one so I can change to "work in progress"
[16:22] <ScottK> I can't find a good wiki page on getting upgrades in.
[16:23] <mok0> ScottK, you mean a guide telling you how to go about it?
[16:23] <ScottK> refdoc: The short version if you have packages prepared is to file a bug against the package in Launchpad, attach the .diff.gz of the package to the bug, tag the bug upgrade, and subscribe the ubuntu-universe-sponsors team to the bug
[16:24] <ScottK> mok0: Yes.
[16:24] <ScottK> mok0: We have a stunningly detailed page on merges, but nothing on upgrades.
[16:24] <refdoc> ScottK https://bugs.launchpad.net/ubuntu/+source/gnomesword
[16:24] <ScottK> Yes.
[16:24] <mok0> ScottK, huh? strange
[16:24] <ScottK> For each package.
[16:24] <ScottK> mok0: That or I'm just not able to find it.
[16:25] <mok0> ScottK, I can't remember ever seeing one either
[16:25] <refdoc> ok ScottK I will go ahead and do this
[16:26] <refdoc> probably on Sunday night as I am now at work
[16:26] <refdoc> That is brilliant. Thanks
[16:26] <quadrispro> maxb, i did a little error, now w-scan builds well :)
[16:30] <refdoc> Chris, sorry got mixed up with responding : https://bugs.launchpad.net/ubuntu/+source/gnomesword
[16:30] <refdoc> these are the bugs againts GS.
[16:31] <refdoc> The best packages we have are in http://dominique.corbex.net/gnomesword/
[16:31] <Chris`> refdoc: Have you got a direct link to the package tarball for libsword?
[16:31] <Chris`> This crosswire site is hard to navigate
[16:31] <refdoc> there are packages for bibletime, libsword and GS
[16:32] <Chris`> No matter; found it
[16:34] <refdoc> Chris, wharp is one of us, he just joined
[16:34] <refdoc> and my connection is flaky
[16:34] <wharp> ok
[16:34] <refdoc> I thinK I just missed a whole lot
[16:34] <wharp> I was going to ask about replacing the old packages with the renamed packages that will result from the name change
[16:35] <Chris`> mok0: You there?
[16:36] <Chris`> mok0: I used the POD format and then added POD rules to the debian/rules file, how come there is no manpage?
[16:36] <Chris`> wharp: What packages have changed name?
[16:37] <wharp> Chris`: as of yet, none have, however, gnomesword is likely going to change project names
[16:37] <Laney> The new package will have to go through NEW, but it shouldn't be a problem
[16:37] <Chris`> wharp: I believe that the gnomesword package will then change to a dummy package but then relies on the new one so it downloads and installs the new one instead
[16:37] <mok0> binarymutant_: +1 from me
[16:38] <binarymutant_> hey hey thanks! :) :)
[16:39] <mok0> Anymore REVU hopefuls lurking around?
[16:46] <wharp> Chris`: are you the same Chris who just assigned himself to the Ubuntu bug?
[16:46] <Chris`> wharp: Yep
[16:47] <wharp> Chris`: do you need anything from us, and if so, what?
[16:47] <Chris`> wharp: No nothing is required, I just need to see what the older deb contributor did and I'm checking if the same applies via lots of experimentation
[16:47] <wharp> ok
[16:48] <Chris`> I'm building a test .deb atm for libsword6
[16:48] <wharp> ok, then you did find the tarball on crosswire.org?
[16:48] <wharp> refdoc mentioned you were looking for it
[16:48] <Chris`> wharp: Yeah after some navigation ;
[16:49] <wharp> good, because I was looking for it for you and I sure as heck don't see it
[16:49] <wharp> oh, there it is
[16:49] <Chris`> wharp: Yeah that's what I feltl ike too
[16:50] <wharp> Chris`: do you do packaging for Debian also, or just Ubuntu?
[16:50] <Chris`> wharp: Just Ubuntu but I believe that my efforts go over to Debian too
[16:50] <wharp> hopefuly so
[16:53] <iulian> ubuntu-devel
[16:53] <iulian> Blah
[16:56] <Chris`> mok0: You there again? I have a package to double-check for upload http://revu.ubuntuwire.com/details.py?upid=4616
[17:00] <mok0> Chris`I am here, looking
[17:00] <Chris`> mok0: There is something strange, in the .deb, the manpage exists...
[17:01] <mok0> yes?
[17:01] <Chris`> But you said linitian said that it doesn't?
[17:02] <mok0> Oh you wrote it in .pod format
[17:02] <Chris`> Yeah it's the only one that I feel safe in :P
[17:02] <mok0> Chris`educate me on how it gets installed
[17:03] <Chris`> On POD or the manpage of the package?
[17:03] <mok0> afaics the manpage is created in $topdir
[17:04] <mok0> I can't see it being installed...
[17:04] <Chris`> usr/share/man/man1/grdc-gnome.1.gz?
[17:04]  * mok0 building now
[17:05] <Chris`> mok0: I managed that in the debian/rules file, so I can show what I have done in debian rather than branching outwards if that is what you meant?
[17:06] <mok0> Chris`hang on
[17:06] <mok0> oh yes it's there
[17:06] <fabrice_sp> Hi. Anyone to review dvdstyler, a dvd authoring tool (http://revu.ubuntuwire.com/details.py?package=dvdstyler). It has already been advocated by mok0.
[17:08] <mok0> Chris`, Lintian complains because it wants a manpage for the app grdc-applet
[17:08] <Chris`> mok0: Oh yeah, did I change the name of it?
[17:08] <mok0> ... and the man page you've writen is grdc-gnome :-)
[17:08] <Chris`> Blame jpds :)
[17:09] <mok0> heh
[17:09] <mok0> Never mind, I will fix & upload
[17:09] <Chris`> Oh cool ok thanks
[17:09] <jpds> I wanted to call it gnome-applet-grdc.
[17:12] <jpds> RainCT: How can I merge accounts on REVU?
[17:12] <Chris`> mok0: Oh, over-rides, using that quilt patching system I guess?
[17:12] <jpds> RainCT: Tonio_ is having problems with his MOTU status.
[17:13] <jpds> RainCT: And scripts/alter_user.py has disappeared.
[17:14] <jpds> RainCT_ or RainCT__: please see above.
[17:14] <mok0> Chris`, what overrides?
[17:14] <Chris`> mok0: The .so versions
[17:14] <Chris`> http://revu.ubuntuwire.com/details.py?upid=4567
[17:14] <Chris`> mok0: Oops wrong reviewer
[17:16] <Chris`> Oh right tonio has uploaded it, I misread what he said too!
[17:16] <mok0> Chris` the problem from 18.1 is that you need to include quilt build-deps because you use the include ... patchsys-quilt.mk in rules,
[17:16] <mok0> Chris` but if you're not patching, you might as well remove both
[17:17] <Chris`> mok0: Where can I see what packages have been recently uploaded?
[17:17] <Chris`> i.e. grdc?
[17:17] <mok0> https://edge.launchpad.net/ubuntu/jaunty/+queue
[17:18] <Chris`> Ah great thanks
[17:19] <LaserJock> quick lunch
[17:22] <Chris`> My first 3 packages got uploaded today ;D
[17:24] <mok0> Chris`: a good day
[17:24] <Chris`> mok0: Very much so :)
[17:27] <bddebian> Anyone good with Gnome/Gtk2?
[17:30] <tritium> superm1: update on hdhomerun-config: In order to build the gui, I'm going to need to build a lib package from libhdhomerun as well, and not just hdhomerun-config.  I should have something tonight or tomorrow.
[17:32] <mok0> HMPF. Why did the FSF have to move?
[17:32] <bddebian> heh
[17:34] <mok0> Am I the only one who finds the README.source file comletely redundant?
[17:34] <bddebian> Nope
[17:34] <binarymutant> :)
[17:35] <LaserJock> if the contents are redundant
[17:35] <binarymutant> isn't it just a file pointing to another file
[17:35] <LaserJock> is it?
[17:35] <mok0> No, but most have the same boilerplate content
[17:36] <LaserJock> I suppose a redudant file with redudant content would be reredundant
[17:36] <binarymutant> please see /usr/share/doc/whatever/dpatch.readme
[17:36] <LaserJock> oh, well that's kinda dumb though could be important
[17:36] <LaserJock> it's supposed to be the stuff about the source package that isn't redundant
[17:36] <mok0> Right
[17:37] <LaserJock> but like everything else that's boilerplate, people like to make examples useless ;-)
[17:37] <binarymutant> I thought it was to show others how you manage patches
[17:37] <mok0> Repackaging and other things that concern the source tarball belongs there, but how to use the patch system? Duh!
[17:38] <LaserJock> yeah, that's totally not necessarily unless you're doing something non-standard
[17:38] <mok0> The patches can very well be applied manually using patch -p0 < file
[17:38] <binarymutant> the easiest way :)
[17:38] <mok0> for f in debian/patches/*.patch; do patch -p0 < $f ; done
[17:39] <mok0> preseto
[17:39] <mok0> presto
[17:39] <LaserJock> I still prefer dpatch
[17:39]  * sistpoty|work prefers VCS - i.e. upstream VCS *g*
[17:39] <LaserJock> I don't
[17:39] <mok0> LaserJock: yes , but the file is supposedly intended for people who don't use the std tools for some reason
[17:39] <LaserJock> those are a pain
[17:40] <LaserJock> mok0: well, I would consider "for f in debian/patches/*.patch; do patch -p0 < $f ; done" still standard :-)
[17:40] <sistpoty|work> well. I guess my advantage is that I'm upstream as well for the thingy I'm packaging right now *g*
[17:40] <LaserJock> sistpoty|work: yeah, that usually helps in many ways ;-)
[17:40] <sistpoty|work> yep :)
[17:40] <mok0> We hates upstream!
[17:41] <LaserJock> except for when you get mad at upstream for doing something stupid ;-)
[17:41] <mok0> We hatesssss upstream!
[17:41] <sistpoty|work> luckily we're a team, so I can blame the others *g*
[17:41] <LaserJock> "WTH, why did the bonehead do it *that* way!!!! oh yeah, that was me"
[17:41] <sistpoty|work> heh
[17:41] <mok0> ha
[17:44] <binarymutant> if anyone has time on their hands I would appreciate a review on my package, http://revu.ubuntuwire.com/details.py?package=charm Thank you :)
[17:50]  * sistpoty|work calls it a day and heads home
[17:50] <sistpoty|work> cya
[17:58] <iefremov_work> any MOTUs here to review UGENE - genome analysis suite? http://revu.ubuntuwire.com/details.py?package=ugene
[18:02] <mok0> iefremov, I'll bite
[18:02] <james_w> any suggestions for this developer news issue?
[18:04] <mok0> iefremov, concerning zlib, just repackage the upstream tarball on our side.
[18:04] <mok0> iefremov, in fact also strip windows specific directories if they exist
[18:05] <mok0> iefremov, it's no problem, done with lots of packages
[18:06] <LaserJock> james_w: do you have the new application process already?
[18:07] <iefremov_work> mok0, do you mean repackaging with removing zlib?
[18:07] <james_w> LaserJock: no need, it went to u-d-a
[18:08] <mok0> iefremov, yes, and rename the tarball to something, for example ugene_1.3.2+repack.orig.tar.gz
[18:08] <iefremov_work> ok, will be fixed
[18:08] <LaserJock> james_w: but doesn't the developer news go elsewhere as well?
[18:09] <iefremov_work> should i place any comments about it - creating special readme, etc. ?
[18:09] <mok0> iefremov, then, create a script or a target in rules "get-orig-source" that does everything needed to repackage
[18:09] <james_w> LaserJock: elsewhere than Ubuntu developers?
[18:09] <LaserJock> james_w: doesn't it go on Fridge, for instance
[18:09] <iefremov_work> mok0, ok
[18:09] <james_w> LaserJock: why would it?
[18:10] <LaserJock> because it's news ...
[18:11] <james_w> it's news for developers
[18:15] <fabrice_sp> Any MOTU to check my debdiff for Bug #318967?
[18:21] <Webspot> Hey. Are there any MOTUs available to review osm-gps-map? It is a GTK+ widget for showing OpenStreetMap in apps. It's my first package! http://revu.ubuntuwire.com/details.py?package=osm-gps-map
[18:22] <mok0> Webspot: I am busy atm but will take a look later
[18:22] <Webspot> mok0: Thanks.
[18:23] <Laney> Webspot: :O do any apps use it?
[18:24] <Webspot> Laney: I don't think so yet. There are also some python bindings that I'm going to get packaged up, after this is done. And then I'm going to make a little app with it :)
[18:24] <mok0> Cool then we can test it
[18:25] <Webspot> In the -dev package, there's a small test script just to browse the map.
[18:28] <Chris`> Webspot: I've added a comment but I'm not MOTU :)
[18:28] <Webspot> Chris`: Thanks. I'll check it out.
[18:29] <Webspot> Chris`: I'll work through that stuff :)
[18:29] <Chris`> Webspot: Yeah cool, they're the stuff that I often get wrong so I just picked up on them :)
[18:30] <Webspot> Chris`: Right. Hopefully I'll get better at this as I go along :)
[18:31] <Chris`> Webspot: I've only had 3 packages into the Universe so far :P They were uploaded today as well!
[18:34] <fabrice_sp> by the way, shouldn't it be better to sync gavl (bug #318658) before fixing the FTBFS, as openmovieeditor would need a rebuild after the sync?
[18:35] <mok0> fabrice_sp: sounds reasonable
[18:37] <fabrice_sp> mok0, ok. I'll link the gavl link request it in the FTBFS bug. Thanks :-)
[18:38] <mok0> fabrice_sp: good to get that out of the way
[18:39] <james_w> fabrice_sp: why would it need a rebuild?
[18:40] <fabrice_sp> james_w, the soname is bumped, if I remember well
[18:40] <james_w> I thought we already had the SONAME bump
[18:41] <fabrice_sp> Have to check ,then (not sure, now that you say it)
[18:41] <james_w> yeah http://people.ubuntu.com/~ubuntu-archive/NBS/libgavl0
[18:43] <fabrice_sp> there is a new one (if I understand packages.debian.org)
[18:44] <fabrice_sp> from libgavl0 -> libgavl-1.0-0 -> libgavl1
[18:44] <james_w> ugh
[18:44] <james_w> sorry, I assumed that it was libgavl0 -> libgavl1
[18:45] <fabrice_sp> It would have been logical, yes
[18:45] <fabrice_sp> :-/
[18:45] <LaserJock> RainCT__: priority extra could be checked for
[18:46] <ScottK> I think we really don't care at all in Ubuntu about optional/extra
[18:46] <LaserJock> no, but there's a Policy difference
[18:46] <ScottK> Even Debian is having a hard time convincing themselves they still care.
[18:46] <LaserJock> and we don't know if they'll be used in the future
[18:47] <LaserJock> not that I think optional/extra are particularly useful
[18:47] <directhex> ScottK, some dev with a package which only works on hppa, with 4 users, might care!
[18:47] <RainCT> LaserJock: How? REVU can't know if the priority is "extra" for some reason or not
[18:47] <LaserJock> RainCT: sure you can
[18:48] <LaserJock> if the package doesn't declare any replaces/conflicts I don't think it can be in extra really
[18:48] <RainCT> LaserJock: It can. Eg, packages which require some special hardware to be useful
[18:48] <ScottK> Also packages where it would be 'confusing'
[18:49] <ScottK> Also if depends on extra pacakges.
[18:49] <fabrice_sp> thanks for the ack mok0  :-)
[18:49] <LaserJock> well, I guess it does depend a little on what part of Policy you take on that
[18:50] <LaserJock> I'd take "contains all packages that conflict with others with required, important, standard or optional priorities" as being the thing to look for
[18:50] <LaserJock> but I agree with ScottK that it's a fairly usless check
[18:51] <LaserJock> but I think the dh_make template should do optional
[18:51] <LaserJock> I'd take "contains all packages that conflict with others with required, important, standard or optional priorities" as being the thing to look for
[18:51]  * RainCT would suggest fixing dh_make to not set extra by default :P
[18:51] <LaserJock> exactly
[18:51] <LaserJock> that would basically solve the "bad priority" problem
[18:52] <RainCT> LaserJock: btw, I like the proposal from your mail
[18:52] <RainCT> [wth is that RainCT_ coming from? o.O
[18:53] <LaserJock> RainCT: yeah?
[18:53] <RainCT> [oh, irssi running twice :P]
[18:55] <mok0> RainCT: In screen?
[18:55] <RainCT> LaserJock: Yeah. Although if we decide to go with it, it'll take me some weeks to do the required changes on REVU (unless someone else wants to do them)
[18:55] <RainCT> mok0: yep
[18:55] <mok0> RainCT: great then, can you tell me how to scroll in screen?
[18:56] <pochu> Chris`: hey, I've seen refdoc pinged me. Are you going to do the work? If so, there's someone in the motu mailing list offering help and willing to maintain those packages; perhaps you want to work with him
[18:56] <LaserJock> RainCT: right, yeah. I realized it would take some modification.
[18:56] <LaserJock> mok0: PgUp or Shift-PgUp works for me
[18:56] <mok0> ah, /me tries that
[18:56] <Chris`> pochu: I would love any extra help since it is still a learning experience for me. I'll check the mailing list atm
[18:57] <RainCT> mok0: by pressing some key combination to switch to another mode.. but here it's pageup/pagedown is working, let me check if i added something to the config file..
[18:57] <mok0> LaserJock: nope, must be in your .screenrc
[18:57] <pochu> nhandler: hey, did you use GMail to reply to ScottK's mails in your REVU thread?
[18:59] <RainCT> mok0: can't find it, but I guess jpds knows
[18:59] <LaserJock> mok0: I've never set up a .screenrc
[18:59] <mok0> heh ok, what term are you using?
[18:59] <LaserJock> mok0: PgUp works here
[18:59] <RainCT> mok0: terminator
[19:00] <mok0> RainCT: Hm, me too...
[19:01] <LaserJock> mok0: gnome-terminal, terminator, konsole ...
[19:01] <mok0> LaserJock: I feel ... like... somethings wrong with me
[19:02]  * LaserJock gives mok0 a hard smack
[19:02]  * mok0 wakes up
[19:03] <mok0> It's probably my termcap entry or something
[19:03] <mok0> 'cause PgUp doesn't work anywhere
[19:09]  * ScottK finds it ironic that armel is the least backlogged arch on the buildd's right now.
[19:09] <mok0> ScottK, that's because almost nothing builds on it ;-)
[19:10] <ScottK> mok0: Actually it's because all the pending backports got processed today.
[19:10] <ScottK> No armel in Hardy/Intrepid
[19:10]  * sebner waves and is happy to be still alive =)
[19:10] <mok0> sebner!!
[19:10]  * ScottK wonders if that was in question?
[19:11] <sebner> ScottK: yes, really xD
[19:11] <ScottK> Tell us then ...
[19:12] <sebner> ScottK: well, it's really hard. 16hours per day on the feet. bad meals, instructors shouting all day long
[19:13] <ScottK> Sounds like you joined the army.
[19:13] <sebner> xD
[19:13] <sebner> of course
[19:13] <laga> oh, i thought it was ~ubuntu-bugs
[19:13] <sebner> for the next 6 months :(
[19:13] <ScottK> Ah.
[19:13] <RainCT> lol
[19:13] <sebner> laga: lol
[19:13] <ScottK> It's good for you.
[19:13] <sebner> ScottK: NAAAAAAAAHHHHHHHHHHHHHHH
[19:14] <sebner> ScottK: the bad thing is that I would have gone home last weekend already but I was ill so I had to stay there. So I'm at home the first time since 2 weeks
[19:15]  * sebner asks himself if the new nvidia driver (180-glx) is now compatible with new Xorg? 492 updates to go
[19:17] <james_w> fabrice_sp: nice work on openmovieeditor
[19:17]  * mok0 goes for pizza!
[19:18] <hyperair> is there any motu available for revu? if so, may i have a review please? http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
[19:30]  * mok0 looks the other way ;-)
[19:31] <hyperair> mok0: heheh
[19:31] <mok0> hyperair: it's getting awfully quiet around here...
[19:31] <hyperair> mok0: if you're free for another revu, http://revu.ubuntuwire.com/details.py?package=sigx
[19:31] <hyperair> mok0: and yeah, i agree.
[19:31] <hyperair> imo the most noise happens when i'm asleep
[19:31] <mok0> Ah, ok
[19:31] <mok0> yes
[19:32] <mok0> Somewhere I saw some statistics on when the channels were busy
[19:32] <iulian> mok0: To scroll down/up in screen - CTRL+A+ESC works for me.
[19:33] <mok0> iulian: your'e using C-A as the command sequence?
[19:34] <hyperair> Ctrl+A+ESC triggers copy mode in screen ;)
[19:34] <iulian> mok0: Exactly, then press esc.
[19:34] <mok0> for me too
[19:35] <mok0> I changed C-A to C-Z
[19:35] <iulian> You can now scroll with PgUp/PgDn or with the arrows.
[19:35] <mok0> Ah!
[19:35] <mok0> Yay!
[19:35]  * mok0 hugs iulian
[19:36]  * iulian hugs mok0 back.
[19:40] <hyperair> fabrice_sp: you're a motu right? could you revu a package for me? =p
[19:48] <fabrice_sp> hyperair, sorry: I'm only an interested contributor
[19:48] <fabrice_sp> but I can have a look at a package :-)
[19:49] <fabrice_sp> just throw the URL, and I'll comment it (even if I can't advocate it)
[19:51] <hyperair> fabrice_sp: http://revu.ubuntuwire.com/details.py?package=sigx
[19:55]  * fabrice_sp builds sigx, to check the resulting packages
[19:56] <hyperair> jpds: ping
[20:05] <fabrice_sp> hyperair, sigx FTBFS:
[20:05] <fabrice_sp> dh_makeshlibs: command returned error code 256
[20:05] <fabrice_sp> make: *** [binary-fixup/libsigx-2.0-2] Error 1
[20:06] <hyperair> how very strange
[20:06] <hyperair> i saw no such error
[20:06] <hyperair> and what's FTBFS?
[20:06] <slytherin> hyperair: fails to build from source
[20:07] <hyperair> ig'
[20:07] <hyperair> oh
[20:08] <hyperair> hmm
[20:08] <hyperair> fabrice_sp: are you using amd64 by any chance?
[20:08] <fabrice_sp> yep
[20:09] <fabrice_sp> amd64 here
[20:09] <hyperair> thought so
[20:09]  * hyperair frowns
[20:09] <hyperair> mok0: are debian/package.symbols.arch files required for libs?
[20:10] <hyperair> fabrice_sp: could you try removing debian/*.symbols and see if it builds?
[20:12] <fabrice_sp> ok
[20:12] <mok0> hyperair: not required,
[20:12] <hyperair> mok0: alright, then i'll just toss it out. lintian -I was complaining though
[20:12] <mok0> hyperair: so far, it's only a recommendation
[20:12] <fabrice_sp> hyperair, so will upload a new version?
[20:13] <hyperair> fabrice_sp: yeah i will.
[20:13] <mok0> hyperair: but it will be useful in the long run
[20:14] <hyperair> mok0: i can't for the life of me understand the .symbols file generated by dpkg-gensymbols
[20:14] <mok0> hyperair: can you pastebin it
[20:14] <slytherin> hyperair: why do you need to understand it? Just use it. :-P
[20:15] <fabrice_sp> mok0, is uploading a package to PPA mandatory before uploading to REVU? It should help fixing FTBFS before advocating the package
[20:15] <hyperair> mok0: it's a C++ library so there are a whole lot of mangled names
[20:15] <mok0> fabrice_sp: true. It's a good idea, but not required
[20:15] <hyperair> slytherin: well, it's unmaintainable otherwise right?
[20:15] <mok0> hyperair: ah yes
[20:16] <mok0> hyperair: it's basically a list of (symbol  version)
[20:16] <hyperair> mok0: it would also seem that the x86 .symbols doesn't work on amd64
[20:16] <slytherin> fabrice_sp: not required. ppa is not the only way to make sure your package builds. use pbuilder.
[20:16] <mok0> where "version" is the version of the library (no soname)
[20:16] <hyperair> mok0: http://pastebin.com/f586e7665
[20:16] <mok0> (NOT soname)
[20:17] <mok0> hyperair: yup, looks good
[20:17] <hyperair> slytherin: well it builds on x86, but i don't have an amd64 pbuilder around
[20:17] <mok0> hyperair: place it as debian/<package>.symbols
[20:17] <hyperair> mok0: that's what made dh_makeshlibs spit flames on fabrice_sp's machine
[20:17] <mok0> hyperair: oh?
[20:18] <hyperair> mok0: yeah, error 256 or something
[20:18] <mok0> fabrice_sp: what version are you running? Gutsy?
[20:18] <mok0> hyperair: what package is it?
[20:19] <mok0> sigx?
[20:19] <hyperair> mok0: http://revu.ubuntuwire.com/details.py?package=sigx
[20:19] <hyperair> yeah
[20:19] <mok0> Ah, about to take a look at it anyway
[20:19]  * mok0 goes to other window for a while...
[20:19] <hyperair> mok0: actually i removed the .symbols file
[20:19] <fabrice_sp> mok0, no: it's a jaunty's sbuild
[20:19] <hyperair> mok0: should i add it back?
[20:19] <mok0> Uhm, the symbol file?
[20:20] <mok0> I can snatch it from the pastebin
[20:20] <hyperair> mok0: yeah
[20:20] <hyperair> oh
[20:20] <hyperair> right
[20:20] <fabrice_sp> I'll paste the sbuild's log in REVU
[20:20] <mok0> fabrice_sp: thanks
[20:21]  * hyperair needs to bathe
[20:22] <mok0> hyperair: yeah you're starting to smell
[20:22] <mok0> :)
[20:23] <mok0> hyperair: why do you use that strange version # for the lib?
[20:23] <mok0> 2.0-2?
[20:24] <fabrice_sp> bad idea to paste the build log in REVU....
[20:24] <mok0> fabrice_sp: firefox crashed?
[20:24] <mok0> fabrice_sp: we just need those error messages not the whole thing
[20:25] <fabrice_sp> nop: it's a too long comment
[20:25] <fabrice_sp> yeap: will just past the error
[20:27] <fabrice_sp> done
[20:28] <mok0> fabrice_sp: ah I may know what that is
[20:29] <fabrice_sp> mok0, wouah!
[20:29] <mok0> fabrice_sp: I get the same erros
[20:29] <fabrice_sp> ok
[20:31] <mok0> fabrice_sp: right now I am thinking that it has to do with that funny version no
[20:34] <Webspot> mok0: You mentioned on my REVU package (http://revu.ubuntuwire.com/details.py?package=osm-gps-map) that I should have a watch file. Is this possible, when the packaged is based off a git checkout?
[20:34] <mok0> Webspot: oh
[20:34] <mok0> Webspot: I guess not
[20:35] <Webspot> mok0: Okay. I'll just upload the other changes, ignoring that then :)
[20:35] <mok0> Webspot: all right
[20:36] <Webspot> I've uploaded the changes requested by people to my package. If any MOTUs are free could they please review. Thanks :) - http://revu.ubuntuwire.com/details.py?package=osm-gps-map
[20:37] <Webspot> Just give it a second to show up on the site though...
[20:39] <Webspot> It's up now, for those interested.
[20:41]  * hyperair is back!
[20:41] <mok0> hyperair: that .symbols file is from another version of the library
[20:41] <hyperair> eh?
[20:41] <hyperair> seriously?
[20:41] <hyperair> whoops
[20:41] <mok0> hyperair: why do you use that strange version # for the lib?
[20:42] <hyperair> what strange version #?
[20:42] <mok0> 2.0-2
[20:42] <hyperair> mok0: that's not a version
[20:42] <hyperair> i mean that's part of the library package name
[20:42] <hyperair> isn't it?
[20:43] <mok0> Package: libsigx-2.0-2
[20:43] <hyperair> i read from the debian library packaging guide that if the library is libsigx-2.0.so.2.y.z, then the package name should be libsigx-2.0-2
[20:43] <hyperair> or something
[20:43] <mok0> hyperair: normally, you just append the major soname -> libsigx2
[20:43] <loic-m> mok0: before my computer rebooted a few hours ago I read a comment from you that (C) for copyright wasn't good in a package
[20:44] <mok0> loic-m: right
[20:44] <hyperair> libtool params: -export-dynamic -version-info 0:0:0 -release 1.2.3 package name: libfoo-1.2.3-0
[20:44] <mok0> loic-m: Either © or Copyright
[20:44] <hyperair> taken from http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[20:45] <mok0> hyperair: errr...
[20:45] <loic-m> mok0: I suggested that line in a REVU comment (my bad) : The Debian packaging is (C) 2008, Your_name <your@adress> and is licensed under the GPL, see above.
[20:45] <hyperair> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id250154
[20:45] <loic-m> mok0: I can just suggest "The Debian packaging is Copyright 2008, (...)
[20:45] <mok0> loic-m: yes
[20:45] <loic-m> or "The Debian packaging is ©2008, (...)"
[20:45] <mok0> exactly
[20:45] <loic-m> mok0: thanks a lot
[20:46] <mok0> You're welcome
[20:46] <mok0> hyperair: 2 secs
[20:46] <hyperair> mok0: ok
[20:46] <loic-m> mok0: is "Copyright (C) 1999 " ok? I've seen it on a Debian package afair
[20:47] <loic-m> mok0: or should i tell the uploader to correct that too?
[20:47] <mok0> loic-m: It's commonly used that way, but AFAIK, the "(C)" is worthless
[20:48] <mok0> loic-m: in the sense: has no legal implecations
[20:48] <mok0> implications
[20:48] <loic-m> mok0: thanks, I'll have to review my own package on REVU too ;)
[20:48] <mok0> he
[20:50] <mok0> hyperair, from Debian policy manual: "The most common mechanism is to place it in a package called librarynamesoversion, where soversion is the version number in the soname of the shared library
[20:50] <hyperair> hmm =\
[20:50] <hyperair> i'll change it then
[20:51] <hyperair> mok0: but looking at libsigc++, it's libsigc++-2.0-0c2a
[20:51] <mok0> hyperair: Ugly
[20:51] <hyperair> heh
[20:52] <hyperair> mok0: so should i strip the -2.0 from all the binary packages?
[20:52] <mok0> hyperair: hang on, I want to be sure
[20:53] <mok0> hyperair: in the meantime, read this: http://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning
[20:53] <loic-m> Has the FSF address (in debian/copyright) changed? I've seen 2 address, but can't tell for sure which is the new one or if both are ok (and I don't want to mislead the uploader)
[20:53] <loic-m> Is 675 Mass Ave, Cambridge, MA 02139, USA. the old one, and 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA the new one?
[20:53] <mok0> loic-m: It's the Franklin St. one that's current
[20:54] <loic-m> mok0: thanks a lot.
[20:54] <hyperair> mok0: that doesn't seem to talk about -release at all
[20:55] <hyperair> oh wait it does
[20:56] <hyperair> mok0: basically what i infer from this is that sigx-2.0 is the name of the library, and 2 is the soname version
[20:56] <hyperair> mok0: hence libsigx-2.0-2
[20:56] <mok0> hyperair: Explain to me why you need that
[20:57] <hyperair> mok0: umm because upstream decided to do things like that?
[20:57] <mok0> hyperair: I maintain that libsigx2 is sufficient
[20:57] <mok0> hyperair: if the ABI changes, upstream will bump the soname to 3 and the new library will be libsigx3
[20:58] <hyperair> because the library's filename is libsigx-2.0.so.2, and the author's latching the -2.0 part to the libsigc++ -release version
[20:58] <mok0> hyperair: then old and new apps using the library can co-exist
[20:59] <mok0> hyperair: ok
[20:59] <hyperair> mok0: similar to how libsigc++ has -1.2, -1.9, and -2.0, as well as potetntially higher versions in the future, i think sigx will follow the same way
[20:59] <hyperair> mok0: in which case i think the soname would be reset
[20:59] <mok0> hyperair: very peculiar
[21:00] <hyperair> mok0: it's something like branching from the old one, similar to how gtk1 shifted to gtk2
[21:00] <mok0> hyperair: of course this is not a libtool library
[21:00] <hyperair> and yes it's not, but it uses libtool versioning, after i persuaded the author to do so
[21:00] <hyperair> however, libsigc++ is a libtool library
[21:00] <hyperair> author seems to really love scons
[21:01] <mok0> hyperair: what is libsigc++ ?
[21:01] <hyperair> mok0: signal/slot library for C++
[21:01] <hyperair> mok0: used extensively in gtkmm
[21:01] <mok0> hyperair: ..and this lib is on top of that?
[21:01] <hyperair> mok0: libsigx is the multithreaded extension to it
[21:01] <hyperair> mok0: yep
[21:01] <mok0> ah
[21:01] <mok0> Then why not libsigx2-2.0 ?
[21:02] <hyperair> um.
[21:02] <hyperair> i haven't seen any versioning that looks like that
[21:02] <hyperair> have you seen any package which has a name like that?
[21:02] <mok0> libofapi0 - OpenFirmware device-tree parsing library
[21:03] <mok0> libnucleus5 - EMBOSS library for molecular sequence analysis
[21:03] <hyperair> mok0: but that's not libofapi0-0.0 or something
[21:03] <mok0> libnmz7 - full text search engine - shared library
[21:03] <hyperair> mok0: i'm talking about libraries with libfiles libfoo-<some release version>.so.<soname>
[21:04] <mok0> hyperair: so, like lib*-*.so.* ?
[21:04] <hyperair> mok0: every library i can think of which has files /usr/lib/libfoo-<version>.so.<soname> is named similar to how i named sigx
[21:04] <hyperair> mok0: more specifically lib*-\d+.so.*
[21:04] <mok0> libgthread-1.2.so.0
[21:04] <hyperair> uh make that [\d.]+
[21:04] <hyperair> ah
[21:05] <mok0> corresponding package: libglib1.2ldbl
[21:05] <hyperair> but that has an even stranger package name
[21:05] <loic-m> Is the fact the simple description line in debian/control starts with an upercase a big problem? I'm checking packages in the repos to make sure but some do, some don't
[21:05] <hyperair> i mean you don't see the soname anywhere, and what's ldbl?
[21:05] <mok0> libgtk1.2: /usr/lib/libgtk-1.2.so.0
[21:06] <mok0> dunno
[21:06] <hyperair> mok0: those don't seem to have sonames in their package names
[21:06] <Chris`> ScottK: Nice bug fixing, you had fixed in less than 3hrs of me originally reporting it! :P
[21:07] <ScottK> Turned out to be an easy one.
[21:07] <hyperair> mok0: the other variant i see is libfoo<version>-<soversion>
[21:07] <hyperair> mok0: as the package name, i mean
[21:07] <mok0> kdelibs5: /usr/lib/libkhtml.so.5
[21:07] <ScottK> If Debian hadn't aleready done 4.2.4a it'd have gone into the 'too hard, do later' pile.
[21:08] <mok0> kdelibs5: /usr/lib/libkhtml.so.5.1.0
[21:08] <Chris`> ScottK: Heh you have those piles too?
[21:08] <mok0> hyperair: that's an example!
[21:08] <hyperair> mok0: those don't have a version before .so
[21:08] <ScottK> Piles of them.
[21:08] <mok0> hyperair: not the library, the package
[21:08] <jpds> RainCT: Know what?
[21:09] <mok0> hyperair: so you can also have the earlier package:
[21:09] <hyperair> mok0: but the package name has to be tailored towards the way the library was versioned
[21:09] <hyperair> mok0: right?
[21:09] <mok0> kdelibs4: /usr/lib/libkhtml.so.4
[21:09] <RainCT> jpds: uhm?
[21:09] <hyperair> mok0: okay, supposing the sigx author decides to release a libsigx-3.0.so.2, what do i call it?
[21:09] <mok0> hyperair: yes, but you said it was using libtool versioning
[21:09] <jpds> 18:59:11 #ubuntu-motu: < RainCT> mok0: can't find it, but I guess jpds knows
[21:09] <jpds> hyperair: pong.
[21:09] <RainCT> jpds: Ah, nvm, he already got an answer.
[21:10] <mok0> hyperair: ok, if that's what he calls it, I guess we're stuck with that
[21:10] <RainCT> jpds: (he wanted to know how to scroll with screen)
[21:10] <hyperair> jpds: hi. is the package name "libsigx-2.0-2" okay for libsigx-2.0.so.2?
[21:10] <mok0> jpds: I believe it was a question about how to scroll in screen
[21:11] <mok0> jpds: but we figured it out
[21:11] <hyperair> mok0: well if you like, it looks like there are naming conventions where the release number is glued onto the package name, like libsigx2.0-2. would that be better?
[21:11] <jpds> mok0: How do you do it? I knew how to but I forgot.
[21:11] <jpds> hyperair: Should be.
[21:12] <mok0> jpds: first you need to go into copy mode (C-A esc) then you can use PgUp
[21:12] <RainCT> jpds: ctrl+a+escape
[21:12] <hyperair> jpds, mok0: scrolling in screen requires activating copy mode (C-a [)
[21:12] <RainCT> jpds: here it works out of the box, though.. dunno why
[21:12] <jpds> Hmm, /me writes into Tomboy.
[21:12] <hyperair> jpds: ctrl+u seems to work for scrolling up
[21:12] <mok0> hyperair: leave it like it is, I am convinced
[21:12] <jpds> RainCT: Did you fix tonio's REVU MOTU status thing?
[21:13] <hyperair> jpds: and ctrl+d for scrolling down
[21:13] <hyperair> mok0: okay
[21:13] <hyperair> mok0: so apart from adding a proper package.symbols file, are there any other issues?
[21:13] <mok0> hyperair, now I'm gonna look at that symbols thing.
[21:13] <hyperair> mok0: okay
[21:13] <mok0> hyperair: haven't gotten that far yet :-)
[21:14] <hyperair> jpds: when you poked around sigx last night, did it build? if so, x86 or x86_64?
[21:14] <jpds> hyperair: I didn't have time to test build..
[21:14] <RainCT> jpds: I don't even know who that is. (Well, thanks to google, now I know it :P)
[21:14] <hyperair> jpds: i see. nevermind then.
[21:14] <mok0> hyperair: anyway, I just created a totally new .symbols file from the library built, and it's different from the one included in debian/
[21:15] <jpds> RainCT: He's a core-dev and motu, but doesn't have it on REVU, can't merge his accounts.
[21:15] <hyperair> mok0: can i have it?
[21:15] <hyperair> mok0: pastebin or something
[21:15] <mok0> sure, just a minute
[21:15] <hyperair> mok0: okay
[21:16] <mok0> http://pastebin.com/f37431e11
[21:17] <RainCT> jpds: OK, he's a reviewer now. You know that you can change the rank from the profile?
[21:17] <jpds> RainCT: No, I did not.
[21:17] <RainCT> well, now you do ;9
[21:17] <RainCT> * ;)
[21:18] <hyperair> mok0: i'm getting a different .symbols file
[21:18] <mok0> hyperair: heh
[21:18] <jpds> RainCT: Learn something knew everyday.
[21:18] <mok0> hyperair: are we working with the same upload I wonder?
[21:18] <hyperair> mok0: same upload
[21:19] <hyperair> mok0: you're on x86_64, i'm on x86. that seems to be creating the difference imo
[21:19] <hyperair> but then again symbols shouldn't change from one arch to another
[21:19] <mok0> Hm, it shouldn't
[21:19] <hyperair> mok0: how did you generate yours
[21:19] <mok0> hyperair: what's the version you used to compile?
[21:19] <mok0> heh
[21:20] <hyperair> mok0: i ran dpkg-gensymbols -plibsigx-2.0-2 | patch debian/libsigx-2.0-2.symbols
[21:20] <mok0> I used a fresh jaunty builder
[21:20] <hyperair> eh mine's intrepid
[21:20] <hyperair> i should use jaunty =\
[21:20] <mok0> hyperair: it could be a difference in the compiler.
[21:20] <hyperair> i'll just take your symbols file and see if it works lol
[21:20] <mok0> hyperair: that kind of defeats the whole purpose of .symbols, though
[21:21] <mok0> The C++ mangling throws off the scheme
[21:21] <hyperair> yeah
[21:21] <hyperair> so i should just leave it out?
[21:22] <mok0> In fact, C++ almost _always_ introduces a different ABI
[21:22] <mok0> Any change of a class will do it
[21:22] <hyperair> meh
[21:22] <hyperair> lol
[21:22] <hyperair> so i should toss it out
[21:22] <hyperair> =\
[21:23] <hyperair> since it's pointless and adds a whole lot of useless stuff to the diff.gz
[21:23] <mok0> Yeah, probably... although it would be interesting to find out what is going on
[21:23] <hyperair> heh
[21:23] <hyperair> o
[21:23] <hyperair> i'm trying your .symbols file in pbuilder now
[21:23] <hyperair> let's see if dpkg-gensymbols generates a diff
[21:23] <mok0> The file will tell clients what parts of the library are still the same as the older versions
[21:25] <mok0> So, it's pretty useful, but if different versions of the compiler have different mangling schemes then it's not worth squat
[21:25] <hyperair> lol pbuilder threw a hissy fit
[21:26] <hyperair> looks like the symbols thing just introduces probs
[21:27]  * mok0 attempts an intrepid build
[21:27] <Laney> hyperair: You should maintain that banshee plugin in debian-mono
[21:27] <Laney> ;)
[21:29] <hyperair> Laney: you mean bansheelyricsplugin?
[21:29] <Laney> is there another?
[21:29] <hyperair> Laney: eh?
[21:29] <hyperair> Laney: you're talking about the one i uploaded to revu right
[21:29] <Laney> yes
[21:29] <hyperair> ah
[21:29] <hyperair> heheh
[21:29] <hyperair> well. i don't have a debian system =p
[21:29] <hyperair> just ubuntu
[21:29] <Laney> forget revu, go straight to the place where great packages are born
[21:30] <hyperair> heh
[21:30] <mok0> Laney: you mean, never born :-)
[21:30] <Laney> You can test it in a VM, but really it's the same
[21:30] <hyperair> well, are you a motu? if you are you can always add the final advocate? =p
[21:30] <Laney> I'm not, and if I were I'd still ask you to bring it over
[21:30] <hyperair> Laney: i'd submit it through utnubu or whatever
[21:30] <mok0> hyperair: it's a good idea
[21:30] <mok0> Laney: utnubu exists?
[21:30] <Laney> not really
[21:31] <mok0> Laney: no one here ever heard of it
[21:31] <hyperair> oh it doesn't?
[21:31] <Laney> It's pretty defunct afaict
[21:31] <hyperair> mok0: what's a good idea?
[21:31] <mok0> hyperair: to maintain the package in Debian
[21:31] <hyperair> hmm
[21:31] <Laney> in the pkg-cli-apps team
[21:31] <hyperair> what does it take to become a debian maintainer?
[21:31] <Laney> you don't need to be
[21:31] <hyperair> eh? i don't?
[21:32] <mok0> hyperair: you need to get it sponsored, like on REVU, but you only need 1
[21:32] <hyperair> mok0: where do i upload it?
[21:32] <mok0> hyperair: they keep all packages in a common svn or git repo
[21:32] <Laney> And we maintain packages in SVN, so it's much more collaborative
[21:33] <Laney> the preparing of an upload, I mean
[21:33] <mok0> hyperair: Laney can tell you
[21:33] <hyperair> Laney: i know that svn.. i have a few of slomo's packaging stuff checked out on my copm
[21:33] <fabrice_sp> Anyone MOTU willing to review DVStyler and perhaps to give it the second advocate? It's a DVD Authoring tool, and it's at http://revu.ubuntuwire.com/details.py?package=dvdstyler
[21:33] <Laney> right, slomo maintains a lot of packages in pkg-cli-* svn
[21:33] <hyperair> Laney: yeah, i sync from them into the ppa
[21:33] <mok0> I'm the only motu around I'm afraid
[21:33] <Laney> awesome
[21:34] <hyperair> mok0: i thought jpds was around, as was rainct
[21:34] <mok0> hyperair: then they're hiding from uploaders, lol
[21:34] <hyperair> time to ping
[21:34] <hyperair> =p
[21:34] <Laney> har har
[21:34] <hyperair> heheh
[21:35] <hyperair> anyway i've got to sleep
[21:35] <hyperair> got a bus to catch tomorrow
[21:35] <hyperair> i mean later today ;)
[21:35] <mok0> heh, I'll leave a review for sigx
[21:35] <hyperair> mok0: thanks
[21:36] <mok0> hyperair: it depends on half the archive
[21:36] <mok0> takes forever to build
[21:36] <hyperair> mok0: you serious? it only takes ~5 minutes on my notebook
[21:36] <cemc> hi. i was just reading this thread: http://ubuntuforums.org/showpost.php?p=2884866&postcount=46 about updating clamav. it there anything new on this subject?, the thread ends on 09 aug 2007 ;)
[21:36] <mok0> I guess it's 'cause I'm watching
[21:37] <hyperair> mok0: also i've got LAN access to an archives mirror =p
[21:39] <mok0> hyperair: I have an apt-cacher-ng on the gigabit network
[21:41] <mok0> cemc: ScottK is the big clamav person
[21:41] <cemc> yea, i saw that, but wanted to ask here first instead in private
[21:42] <mok0> cemc: we've mentioned his name, so he'll come around
[21:42] <mok0> probably
[21:43] <mok0> maybe
[21:43] <cemc> :) i'll stick around then, thanks
[21:43] <mok0> :-)
[21:54] <ScottK> cemc: What's the question?
[21:55] <cemc> ScottK: hi. well, i just installed 8.04 and saw that whole thread about clamav, and i wish to use it and have the latest in hardy, and i would like to help to get it there ;)
[21:56] <cemc> i'm fairly new to this whole thing, but i would like to help somehow
[21:56] <tobi__> what can be reasons for a package not being listed on merge-o-matic, although a newer version of a package is listed in the debian repos? (package: gpsbabel)
[21:57] <ScottK> cemc: What do you use clamav with?
[21:57] <ScottK> https://launchpad.net/~ubuntu-clamav <- we need testers.
[21:58] <cemc> amavis + postfix
[22:01] <ScottK> So if you could run the 0.94.2 packages from the PPA and report any problems, that would be useful.
[22:03] <jcfp> if a package exists in both debian and ubuntu, and the ubuntu one gets updated (new upstream release) so it's newer than the one in debian, should the version be -0ubuntu1 or -1ubuntu1?
[22:05] <ScottK> jcfp: -0ubuntu1
[22:05] <jcfp> tx
[22:06] <ScottK> Once Debian gets it and uses -1, we want it to be a higher version.
[22:09] <jsmidt> I cannot get debuild to call my gpg key.  It always fails saying "Joseph Smidt <josephsmidt@gmail.com>": secret key not available
[22:10] <jsmidt> yet here is my gpg --list-key output Joseph Smidt (Personal Key) <josephsmidt@gmail.com>
[22:10] <jsmidt> Is there some config file I need to change.  I tried making a .devscripts file
[22:13] <_stochastic_> does anyone wat to REVU my package: http://revu.ubuntuwire.com/details.py?package=calf
[22:14] <ScottK> jsmidt: Email address and name have to match exactly.
[22:14] <ScottK> jsmidt: use -k<keyid> then.
[22:20] <mok0> _stochastic_: I'll take a look when I'm done with the one I'm looking at now
[22:20] <_stochastic_> mok0, thanks
[22:21] <mok0> _stochastic_: I've looked at it before
[22:21] <_stochastic_> mok0, I've fixed it up
[22:22] <mok0> _stochastic_: great!
[22:38] <nhandler> pochu: Yes, I did use gmail, why?
[22:44] <pochu> nhandler: because it mangled ScottK's Message-Id in your References header and that broke threading :P
[22:47] <jsmidt> Found my gpg error.  I called the copied the /etc/devscripts.conf to ~/devscripts.conf but it only works if you get rid of the .conf.  Thanks ScottK though for the help.
[22:47] <nhandler> pochu: Good old gmail. Is there a fix to this? Or is it just one more of gmail's faults?
[22:47] <jsmidt> ~/.devscripts.conf
[22:47] <pochu> nhandler: well the fix would be to fix gmail, but we can't do that
[22:48] <pochu> nhandler: but it's ok, it only happened because the message-id had brackets and gmail removed them, but generally they don't have brackets so it's not common :)
[22:49] <pochu> nothing to worry about too much
[23:05] <directhex> BLARG!
[23:05] <directhex> if this is true, i may feel a need to punch something
[23:24] <lucas> A
[23:24] <lucas> oops
[23:34] <loic-m> Can anyone review/advocate my package at http://revu.ubuntuwire.com/details.py?package=ecm ? It's been reviewed twice by simrunbasuita and I've done the corrections, plus fixed a few more stuff since
[23:34] <nhandler> loic-m: I'll look at it
[23:35] <loic-m> nhandler: thanks a lot
[23:35] <loic-m> it's not a so well known package, but it's quite useful for storing isos + only available as source on the homepage
[23:36] <loic-m> btw, is there a team for emulation (game consoles) in Debian or Ubuntu?
[23:37] <nhandler> loic-m: I believe there is a Debian game team
[23:37] <nhandler> loic-m: https://alioth.debian.org/projects/pkg-games/
[23:38] <postalchris> Is there a way to give a package a new version number without doing a full rebuild?
[23:38] <nhandler> postalchris: Why do you need to give it a new version number?
[23:38] <postalchris> I want to upload the same version to a PPA and to REVU
[23:38] <nhandler> postalchris: For PPAs, you really should append ~ppaX to the end of it
[23:39] <loic-m> nhandler: I've seen this team before, I thought it was only for Linux native games - do they also focus on emulation?
[23:39] <nhandler> loic-m: I'm not sure
[23:39] <postalchris> nhandler: Right, I mean I want the same source package in the two places with different version numbers (per the naming convention)
[23:41] <nhandler> postalchris: I'm not sure if there is a better way. I normally upload to REVU, modify version to have ~ppaX in debian/changelog, debuild -S, and upload to PPA
[23:42] <postalchris> nhandler: Cool. Thanks.
[23:44] <loic-m> nhandler: ~ppaX do you leave X, or does X has to be replaced?
[23:44] <maxb> X == a number, start at 1, increase if you need to make a revision
[23:45] <loic-m> maxb: thanks
[23:51] <cyberix> hey, we just transfered development of package pyliblo over from me to dooooomi
[23:51] <cyberix> could someone review the new version to make sure everything went ok?
[23:51] <cyberix> http://revu.ubuntuwire.com/details.py?package=pyliblo
[23:53] <loic-m> When reviewing, is there a command to check there's not useless spaces in debian/ files (+ maybe number of characters in a line not >80)?
[23:54] <nhandler> loic-m: I normally just skim down the line using vim (which shows the column number) to see if it is > 80 characters. Extra spaces are pretty easy to spot
[23:55] <Laney> I thought there was a lintian check for >80 (maybe in -I?)
[23:55] <nhandler> Laney: I think there is, but I don't remember if it checks every file or not
[23:56] <Laney> the ones in debian/ that have this limit, sure
[23:57] <loic-m> nhandler, Laney, thanks. I'll try lintian -l first ;) I'm still not good at spotting them with a text editor (I'll have to try vim though)
[23:57] <Laney> not l, I (that's capital-i)
[23:57] <Laney> loic-m: ^
[23:57] <nhandler> loic-m: You also need to build the package before running lintian. Running it on the .dsc won't work
[23:59] <maxb> lintian can check a source package, can't it?
[23:59] <nhandler> Yes it can