[02:53] <dtchen> nhandler: mind looking at bug 313820? it has been verified for a couple months now
[02:54] <nhandler> Sure thing dtchen
[02:54] <dtchen> thanks
[02:57] <nhandler> dtchen: Have you talked to the Debian Maintainer about this issue?
[02:59] <dtchen> i pinged, but no response
[02:59] <dtchen> as you can see, it has been a couple months
[03:36] <nhandler> dtchen: What do you need to do to triger the buffer overflow?
[03:43] <nhandler> dtchen: I'm going to bed. Please add a comment explaining how to reproduce that bug, and I'll look at it tomorrow
[05:59] <dholbach> good morning
[05:59] <binarymutant> thanks for uploading that change dholbach :)
[06:00] <dholbach> binarymutant: no worries
[06:01] <dholbach> binarymutant: I added a changelog entry for 1ubuntu1 for you
[06:02] <binarymutant> thank you :)
[06:02] <fabrice_sp_> Hey dholbach ! :-)
[06:02] <fabrice_sp_> already sponsoring ;-)
[06:02] <dholbach> fabrice_sp_: I figured that's the best way to start the day :)
[06:03] <fabrice_sp_> dholbach, Well. I would say a coffee is not that bad ;-)
[06:04] <dholbach> fabrice_sp_: that too :)
[06:10] <dholbach> luisbg: can you recommend a club in Barcelona? :)
[06:14] <fabrice_sp_> dholbach, you mean nightclub? Because club can be misunderstood in Spain :-)
[06:14] <dholbach> fabrice_sp_: nightclub, music, dancing, yes :)
[06:14] <fabrice_sp_> (at least in Madrid. I don't know for Barcelona :-) )
[06:14]  * slangasek recommends a club soda
[06:14] <fabrice_sp_> ok ;-)
[06:15] <dholbach> fabrice_sp_: every other kind of club I leave to UDS attendees to figure out themeselves ;-)
[06:15] <fabrice_sp_> do't worry: in the air plane books, you generally have some addresses of other kind of clubs...
[06:15] <fabrice_sp_> lol
[06:21] <dholbach> fabrice_sp_: regarding te graphviz fix - is there no way to get it to build 2.5 and 2.6 modules?
[06:21] <dholbach> doko: ^ do you have an idea how to do it (bug 338553)
[06:23] <dholbach> fabrice_sp_: sugar-base: intrepid -> jaunty :-)
[06:25] <fabrice_sp_> dholbach, about graphviz: the package is not ready to deal with python26. We should modify at least configure and perhaps Makefile to deal with 2 build version (the build location is different in --enable-python and --enable-python2.5)
[06:26] <fabrice_sp_> what do you mean with sugar-base? I saw that a update request is there, but I didn't saw morgs to ask him the status
[06:26] <dholbach> fabrice_sp_: the sponsoring bug regarding python2.6
[06:28] <dholbach> hiya jono
[06:28] <fabrice_sp_> dholbach, the rebuild, yes. Sorry, but I don't get your point :-( Is there something also in Intrepid?
[06:28] <dholbach> fabrice_sp_: no, you had "intrepid" in the changelog entry
[06:28] <fabrice_sp_> ahhh
[06:28] <dholbach> just fixed it and re-uploaded
[06:29] <fabrice_sp_> dholbach, sorry about that: I use intrepid for building the package in a sbuild and jaunty chroot for the change. I sometime mix things :-/
[06:29] <fabrice_sp_> thanks! :-)
[06:29] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases :)
[06:30] <doko> dholbach, fabrice_sp_ : fix the packaging, build it twice.
[06:31] <fabrice_sp_> dholbach,  yeah, I know, but it's a shared computer, and I already have 'family problems' to have Ubuntu accepted (especially because of flash in adm64), so using a 'non stable' version could be a reason of not having a family any more! :-)
[06:32] <dholbach> fabrice_sp_: that page explains how to do it in a "safe way"
[06:32] <fabrice_sp_> doko, should the rules file be generic, or we could use 'hardcoded' python version (ie: if python2.5 move that files and if python2.6, move that other files)
[06:33] <fabrice_sp_> dholbach, oh. I'll have a look then! :-)
[06:34] <dholbach> fabrice_sp_: in the synfigstudio request quilt would not have been necessary - the debian maintainer seems to patch the source directly, so you could have just done the same
[06:34] <dlynch> does anyone have any opinions on a good package name for a program called "rapid photo downloader" (I am the upstream author, and I'm doing my first package) http://damonlynch.net/rapid/
[06:35] <dlynch> two obvious choices are 'rapidphoto' or just 'rapid'
[06:35] <dholbach> dlynch: what's wrong with rapid-photo-downloader? :)
[06:35] <dlynch> it has not been packaged at all yet
[06:35] <dlynch> is that not too long?
[06:35] <dholbach> makes sure it's not being confused with anything else
[06:35] <dlynch> ok if the length is not a problem, it's not a problem with me! :)
[06:35] <dholbach> it's shorter than xserver-xorg-video-openchrome :)
[06:36] <dholbach> or system-config-printer-gnome
[06:36] <dholbach> or lots of others :)
[06:36] <dholbach> dlynch: rock on! :)
[06:36] <dlynch> ok that probably makes my life as a packaging novice easier then
[06:36] <dlynch> thanks!
[06:36] <dholbach> no worries
[06:36] <fabrice_sp_> dholbach, I have to say I always use quilt to patch, and never look at debian modifications. I'll check with kallery
[06:37] <dholbach> fabrice_sp_: it makes the patch shorter and is in line with what the debian maintainer does, so I thought that'd make sense :)
[06:38] <fabrice_sp_> dholbach, sure. Should I upload a new debdiff? By the way, for Bug #348160 should I subscribe u-u-s after each package or only when having all the debdiff
[06:38] <dholbach> fabrice_sp_: yeah, please attach a new debdoiff
[06:39] <dholbach> fabrice_sp_: I just try to keep the sponsoring overview as short as possible, so if there's nothing to sponsor, I unsubscribe the team - just re-subscribe if you want anything uploaded :)
[06:39] <fabrice_sp_> dholbach, will do. Thanks!
[06:40] <dholbach> rock on! :)
[06:40]  * dholbach hugs fabrice_sp_
[07:00] <didrocks> morning o/
[07:46] <slangasek> does someone who knows ruby want to fix ruby-gnome2 FTBFS?
[07:47] <slangasek> (maybe a merge from Debian?)
[07:55] <Elbrus> I like my package to "suggest" any internet browser. Is there a virtual package I could suggest (e.g. sensible-browser)?
[07:55] <Toadstool> good morning
[07:57] <Toadstool> Elbrus: Suggests: www-browser
[07:58] <Elbrus> Toadstool: thanks
[08:00] <Elbrus> is there something similar for pdf-readers?
[08:01] <Toadstool> Elbrus: pdf-viewer :)
[08:02] <Elbrus> great. I was trying to find it in debian-policy...
[08:03] <Toadstool> Elbrus: http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
[08:03] <Elbrus> Toadstool: just found it a second ago... Thanks
[09:00] <dlynch> I am having problems with the man page section of the debian/rules file, after following the instructions at https://wiki.ubuntu.com/PackagingGuide/Complete#Necessary%20packaging%20changes
[09:00] <dlynch> http://paste.ubuntu.com/137312/ , when running dpkg-buildpackage -us -uc I get this error :
[09:00] <dlynch>  fakeroot debian/rules clean \n debian/rules:12: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.
[09:01] <dlynch> (sorry I was d/c a few minutes ago)
[09:01] <liw> dlynch, you need to indent the commands in debian/rules (just like in a Makefile, for it is a Makefile) using tab characters, not spaces
[09:02] <dlynch> liw: thank you, I'll try that then
[11:41] <Mewcenary> Hi, can someone help me with a newbie packaging query please?
[11:42] <Mewcenary> lintian complains that I have files which are changed despite using quilt (I am taking over a package)...
[11:42] <Mewcenary> But one of those files is Makefile.in which seems to be changed whenever a build occurs.
[11:42] <Mewcenary> HOw can I get around that problem?
[11:57] <mok0> Mewcenary: delete Makefile.in in the clean rule
[11:58] <Mewcenary> Thanks for the tip, I'll try that out.
[11:58] <pmjdebruijn> soe packages so NOCONFIGURE=1 ./autogen.sh before creating the source tarball, I'm not sure whether that's applicable here
[12:38] <bddebian> Heya gang
[12:41] <jdstrand> btm, cjwatson, Laney: not sure what happened with bug #334065. I clearly didn't process the request... I'm pretty sure it was the day that I was doing requests manually (ie without syncbugbot). Regardless, it was a mistake and I apologize
[12:43] <siretart`> heya bddebian
[12:45] <bddebian> Hi siretart
[12:47] <sistpoty|work> hi folks
[12:49] <bddebian> Heya sistpoty|work
[12:49] <sistpoty|work> hi bddebian
[12:49] <bddebian> sistpoty|work: I don't know if  you noticed but I uploaded trigger-rally and -data :)
[12:49] <sistpoty|work> bddebian: yep, I saw that... thanks a lot! :)
[12:50] <bddebian> NP
[13:10] <jdstrand> btm, cjwatson, Laney: fyi-- bug #334065 is now synced
[13:11] <Laney> cool, thanks
[13:11] <jdstrand> sure. sorry again for the mix up
[14:22] <dlynch> is this the correct place to ask a question about a PPA build error?
[14:26] <maxb> Depends on whether you suspect the problem is with the PPA build environment (#launchpad) or the package source (here is reasonable)
[14:31] <dlynch> maxb: thanks given this is my first attempt to build a deb for a PPA, I strongly suspect the latter ;-)
[14:32] <dlynch> I got an 'ImportError: No module named gtk.gdk' in the dh_clean part of the build
[14:33] <dlynch> I'm hoping that by simplifying the imports in the setup.py, this problem will go away
[14:33] <maxb> Have you built the package locally in pbuilder prevu or sbuild ?
[14:33] <geser> dlynch: can you point us to the package?
[14:35] <dlynch> maxb: I'm not sure I understand your question, but when I built it locally, I ran dpkg-buildpackage -us -uc
[14:35] <maxb> dlynch: Then it sounds as if your problem is a build-time dependency that is not declared in your debian/control Build-Depends
[14:36] <dlynch> geser: I can point you  to the trunk on launchpad
[14:36] <maxb> Packages build on the automated builders in a very minimal environment, into which the dependencies explicitly asked for in Build-Depends have been added. If you don't ask for a package in Build-Depends, you don't get it available.
[14:37] <dlynch> maxb: I have cdbs (>= 0.4.49),  debhelper (>= 7), python-central (>= 0.5.6), perl in my build depends
[14:37] <maxb> pbuilder replicates this scenario locally to help you check your packages
[14:37] <maxb> dlynch: There's no mention of any python gtk stuff there, yet you're using it in your build process - so that's the problem
[14:38] <dlynch> maxb: ahhh ok. I think it merely came from the fact that my setup.py was importing the version number from the main script, which of course has many imports in it, including gtk
[14:39] <dlynch> so the solution is to store the version number somewhere with no imports, I think :D
[15:02] <cyberix> https://bugs.launchpad.net/ubuntu/+bug/348480
[15:03] <cyberix> This is actually probably not MOTUs fault, but maybe someone knows someone who knows something about this.
[15:06] <dlynch> please forgive me for asking such a super newbie question, but is the best (only?) way to add the ~ppan package suffix via the changelog in the debian directory?
[15:07] <geser> yes, the last entry in the changelog determines the package version/revision
[15:08] <cyberix> Should people really add ppa suffixes to their packages?
[15:08] <dlynch> geser: thanks! I already figured out that not rigidly adhering to the changelog format causes a build failure :)
[15:09] <radix> cyberix: see "Versioning" in https://help.launchpad.net/Packaging/PPA
[15:09] <geser> dlynch: when you use dch it helps you with the format of it
[15:09] <radix> cyberix: it has the rationale for ~ppaN
[15:10] <cyberix> right
[15:10] <dlynch> one thing I've come across is that my debian directory is part of my python setup.py sdist output
[15:10] <cyberix> custom packages
[15:10] <dlynch> which is all fine and good
[15:10] <cyberix> customized for ppas
[15:10] <dlynch> but the problem arises when launchpad rejects the orig.tar.gz
[15:10] <dlynch> saying it's different, even though the version didn't change
[15:11] <dlynch> but it is different only because the contents of the debian directory  have changed
[15:11] <dlynch> I'm only trying to update my packaging stuff, not the source code itself
[15:12] <dlynch> sorry if this is a confusing explanation
[15:14] <dlynch> my question is this: is it a bad idea to put the contents of the debian directory in the tarball created by python setup.py sdist ?
[15:14] <maxb> Generally, yes.
[15:15] <dlynch> aha
[15:15] <dlynch> maxb: so that means to do a build, I should copy the contents of that directory myself
[15:16] <maxb> Does this thing you're packaging have upstream releases?
[15:17] <dlynch> maxb: I am the upstream author, and this is my first time to package anything
[15:17] <maxb> The usual approach is to maintain the upstream release and the packaging separately
[15:18] <dlynch> so I should put things like the man page pod file and the .desktop file in the upstream, and practically everything else in the debian directory?
[15:20] <maxb> Well, presumably you'll want to release a tarball for people and/or other distributions to use?
[15:20] <dlynch> maxb: yes
[15:20] <maxb> That tarball, which would usually be foo-1.0.tar.gz gets renamed to foo_1.0.orig.tar.gz for the debian package
[15:21] <dlynch> I store the tarballs on launchpad
[15:21] <maxb> Then, you unpack that tarball, add a debian/ directory to it, and build a debian source package, which generates a .diff.gz and a .dsc file that go along with the .orig.tar.gz
[15:23] <dlynch> since this must be such a common procedure on launchpad python archives, has someone built a tool to automate as much of this as possible?
[15:24] <maxb> dpkg-buildpackage (or debuild) will build the source package from the unpacked directory
[15:25] <dlynch> thank you maxb, I will look into this tool more thoroughly... and thanks very much for your guidance, it makes a lot of sense
[15:41] <rgreening> ScottK: ping
[16:01] <dlynch> I'm confused by how to have a python package work for intrepid as well as jaunty. I've read the documentation at https://help.launchpad.net/Packaging/PPA, but it doesn't say what how the debian changelog entry should be entered to presumably allow the package to work on more than one release
[16:06] <geser> dlynch: you need an upload for jaunty and one upload for intrepid (and if you want to support other releases too and upload for them too)
[16:07] <dlynch> geser: and they should have separate changelogs, or the same?
[16:07] <geser> and each upload needs a different pkg revision (e.g. include the disto name in the revision, e.g. ~ppaN~intrepid1)
[16:08] <dlynch> geser: why do I need to do this when the program does not need to be recompiled?
[16:08] <geser> dlynch: the minimalistic way would be to change the release and the pkg version in the changelog but you can also add a new entry for those "backports"
[16:09] <geser> dlynch: often it's because of the runtime dependencies which are determined during build
[16:10] <dlynch> geser: you mean the launchpad build process is clever enough to determine whether the python program can be built across more than one release?
[16:11] <geser> dlynch: no, during the build some scripts scan the package and add the necessary dependecies e.g. on libraries or the python intepreter
[16:11] <dlynch> do they "hard code" in something like 'python2.6', or do they keep the version range I specified?
[16:12] <geser> dlynch: it depends on the package if it runs on several releases or not
[16:12] <geser> dlynch: depends on how you packaged it
[16:12] <dlynch> geser: my package does run on several releases
[16:12] <dlynch> and I did package it so it will install unchanged on both jaunty and intrepid
[16:12] <geser> what are the runtime dependencies on the binary package?
[16:13] <dlynch> ${python:Depends},         ${misc:Depends},        python-gnome2,         python-gtk2 (>= 2.10),  python-glade2 (>= 2.10),        python-pyexiv2 (>= 0.1.2),        python-notify
[16:14] <dlynch> XS-Python-Version: >= 2.5, << 2.7
[16:14] <geser> and now the same from the build package (from PPA)
[16:14] <dlynch> you mean from the one built by the PPA?
[16:14] <btm> jdstrand: thanks!
[16:15] <geser> dlynch: yes. is it rapid-photo-downloader?
[16:15] <dlynch> yes
[16:17] <dlynch> geser: it is the same, except python-central >= 0.6.11 is now explicitly specified
[16:17] <geser> dlynch: the depends on python itself are ok for intrepid, but the generated dependency on python-central (>= 0.6.11) can't be fulfilled on intrepid -> rebuild necessary to get the correct versioned dependency for intrepid
[16:18] <dlynch> geser: if I did the build from intrepid instead, would it work for both intrepid and jaunty automatically?
[16:18] <dlynch> or do I still need to make  two different packages?
[16:20] <geser> dlynch: if you build it on intrepid and "copy" then the debs to jaunty it should work on both
[16:20] <geser> copying debs forward has more success than copying backwards
[16:21] <dlynch> geser: great! thank you very much for your time!
[17:36] <BlackLukes> hi, yesterday I was asking about what code is used to display the partition bar in ubiquity as seen here: http://www.askdavetaylor.com/2-blog-pics/ubuntu-install-pic6.png
[17:36] <BlackLukes> I can't find it in the source, can anyone help me?
[17:53] <RainCT> Is there some GUI tool to sync directories on different PCs? (decentralized, not stuff like Dropbox)
[17:54] <mrooney> RainCT: version control?
[17:54] <mrooney> :)
[17:56] <RainCT> mrooney: well, but I don't really mind about revisions, I just want something fast and space efficient, and most important with monitoring (so that if I change something, and I'm connected to the other PC, it gets synced automatically)
[17:56] <RainCT> perhaps fsniper + bzr would do, but I was looking for something more ellaborated :P
[17:57] <RainCT> (uhmm no, fsniper is only for new files)
[17:58] <sistpoty|work> RainCT: maybe grsync? (no clue so, what it can do, haven't used it myself yet)
[18:01] <RainCT> Looks nice, but it doesn't have the file monitoring
[18:07] <RainCT> well, I think I'll get with plain rsync for now
[18:07] <RainCT> s/get/go.    thanks anyway
[18:07]  * sebner waves at sistpoty|work :)
[18:08] <sistpoty|work> hi sebner
[18:10] <geser> Hi sebner, you've now internet during the week again?
[18:10] <RainCT> hey sebner
[18:11] <geser> RainCT: have you had a look at unison?
[18:12] <sebner> hi geser RainCT
[18:12] <dtchen> nhandler: simply rebuilding the source package and starting the compiled daemon results in the symptom
[18:12] <sebner> geser: well, only if I return home (1h with the train). I won't do this that often. maybe 1-2 times a week
[18:12] <RainCT> geser: oh, that one looks great :)
[18:16]  * sistpoty|work calls it a day... cya
[18:21] <dtchen> nhandler: it's a case of toolchain skew; we can either leave it be for jaunty, or we can fix the source. it's fairly obvious to me that the correct thing is to fix the source, but eh, i leave it to you guys who have upload privileges.
[18:31] <iulian> RainCT: You might want to try giver.
[18:32] <directhex> cprov-afk, didn't know there WERE whiteboards. nuke 'em
[18:32]  * iulian is disappointed because it's unmaintained upstream.
[18:33] <cprov> directhex: right, that's the point :)
[18:34] <directhex> iulian, adopt upstream duties!
[18:35] <directhex> cprov, the only PPA wishlist for me right now is debian support
[18:35] <directhex> cprov, e.g. the dependency management stuff is great
[18:35] <cprov> directhex: really ? have you explored it ?
[18:36] <cprov> directhex: we've never had much feedback about it.
[18:36] <directhex> cprov, just added a dep on someone else's PPA to avoid needing to repackage some stuff myself. huge timesaver
[18:36] <directhex> also, dh7!
[18:37] <cprov> directhex: cool, it gets more useful when the PPAs for important projects (kde, gnome, bzr) are organized.
[18:38] <directhex> cprov, well, that ties into the debian question - if a ppa could build debian stuff natively, then it'd be much easier to convince migration from alioth for cross-distro teams
[18:40] <cprov> directhex: right, I see your point. Building debian sources natively (using debian chroots) is theoretically possible and is in our plans, but unfortunately not before July.
[18:40] <directhex> cprov, meh. it's been how many years so far? what's a few more months? :p
[18:41] <cprov> directhex: 'good things take time' seems appropriate here ;)
[18:42]  * cprov hides
[18:42] <directhex> cprov, the phrasology is "good things come to those who wait"
[18:45] <ScottK> directhex: For dh7 (I assume you're packaging for Hardy) you can also depend on hardy-backports to get it.
[18:45] <directhex> ScottK, exactly! like i said, PPAs are awesome ;)
[18:46]  * ScottK is a lot happier with them now that they are signed.
[18:51] <directhex> ScottK, i was under the impression there was a debate about the role PPAs were meant to serve - i.e. not signing was an intentional "don't use me!" flag
[18:53] <ScottK> directhex: I think there was a debate, but if it was meant that way, it was far too subtle for most users.
[18:54] <directhex> ScottK, "rm -fr /" is too subtle for most users ¬_¬
[18:54] <ScottK> Certainly.
[18:55] <directhex> hm, my benchmarks of vdpau are promising
[19:09] <ripps> Can someone help me figure out why a PPA plugin pack won't build on intrepid/hardy, but build perfectly on jaunty? I've already taken into account build-depends and autogen.sh scripts.
[19:09] <ScottK> ripps: #launchpad for PPA questions.
[19:35] <fabrice_sp> JontheEchidna, I've been able to build kallery to get rid of aRts. The problem you had is because in the clean target, it was executing the configure target :-/
[19:36] <fabrice_sp> I'll upload the debdiff soon (in Bug #348160)
[20:41] <phaidros> hi. a dependency for calendarserver (jaunty) is python-twisted-calendarserver_0.2.0.svn19773-5ubuntu1_amd64.deb which is trying to overwrite a file from python-twisted-core
[20:42] <phaidros> what to do about it?
[20:42] <phaidros> (I'm no dev, just user)
[20:43] <phaidros> packages.ubuntu.com states to ask @motu before contacting the maintainer :)
[20:47] <geser> please file a bug at launchpad against that package
[20:57] <phaidros> geser: ok
[21:07] <nhandler> dtchen: I am still unable to reproduce that bug inside of a jaunty chroot (pbuilder) on i386.
[21:08] <dtchen> nhandler: it's quite straightforward here. also, there's a known fix; it's unintrusive; it's trivially correct. it kinda makes sense to apply it *before* release.
[21:09] <nhandler> dtchen: I know. However, Luca also said he was unable to reproduce it, so I'm questioning if there is a need.
[21:09] <dtchen> well, that's really up to you guys
[21:10] <nhandler> dtchen: I have to run out for a little bit. I'll look at it again when I get back
[21:10] <dtchen> do you want me to write an exploit PoC or something? ;)
[21:13] <ScottK> nhandler: If dtchen says it needs fixed, I'd fix it.
[21:29] <fabrice_sp> JontheEchidna, I've update Bug #348160 with the patch for kallery (that drop aRts also). If you want to have a look
[21:31] <JontheEchidna> fabrice_sp: col, I can probably look at it after dinner
[21:31] <fabrice_sp> ok. I'll be in my bed at that time ;-)
[21:36] <khashayar> ScottK: TheMuso re-uploaded pencil with an updated copyright file :-)
[21:37] <ScottK> khashayar: Thanks.
[21:44] <khashayar> ScottK: I've been doing little more than pinging people. Thanks go to you.
[21:45] <ScottK> khashayar: Source is accepted.  It'll go to binary New after it builds.
[21:46] <ScottK> khashayar: The short description could be more gramatical.  Try pencil is a _________ and it should flow from that.  The current one is a bit awkward.
[21:46] <khashayar> ScottK: Thanks a lot!
[21:47] <ScottK> khashayar: Thank you for making Ubuntu better.
[21:48] <khashayar> ScottK: So, when I want to tidy things up (like the short description), do I file a bug against the package with a patch?
[22:11] <ScottK> khashayar: Yes.
[22:34] <ausimage> I am wondering if someone could look over a personal project of mine and help me get things up to standards for Jaunty... https://code.edge.launchpad.net/~ausimage/+junk/PbParser
[22:34] <Laney> fabrice_sp: I'm looking at synfigstudio, but the program crashes after the splash screen. Does it run for you?
[22:35] <ausimage> I have it working in with intrepid... but since the python changes in Jaunty I am unclear... I really would like to see this avaible in Karmic ;)
[22:50] <geser> ausimage: I gave it a quick look and it doesn't need any packaging changes due to the python2.6 transition
[22:50] <ausimage> what about the setup switch?
[22:50] <ausimage> to specify the different layout
[22:51] <ausimage> also I had questions if I am putting the icon where it is supposed to be
[22:52] <ausimage> geser?
[22:54] <geser> ausimage: cdbs is patched to do the right thing and you don't have any settings or custom targets which break it
[22:54] <ausimage> ok... I was not sure if the icon going into icon was correct or if it belongs in pixmaps
[22:55] <geser> looking at that icon now
[22:55] <geser> have you checked your desktop file with "desktop-file-validate"?
[22:55] <ausimage> also I a had a question about the best way to include the manpages...
[22:56] <ausimage> um no did not know it existed
[22:56] <geser> and you shouldn't hard-code the path to the icon as it breaks themeing and auto-selecting of the icon format
[22:56] <ausimage> how should I do it?
[22:57] <ausimage> how should I do it?
[22:57] <ausimage> sorry :/
[22:58]  * ausimage pulls up his desktop file
[22:58] <geser> install your pbparse.svg as /usr/share/pbparse.svg and use "Icon = pbparse"
[22:59] <geser> if I remember correctly at least Gnome should find the svg file and use it
[22:59] <ausimage> and cdbs puts it where it supposed?
[23:00] <ausimage> I thought icons should have a specific location under /usr/share??
[23:01] <geser> sorry, missed the pixmaps dir: /usr/share/pixmaps/pbparse.svg
[23:01] <ausimage> and gnome checks there for any images not in the current path?
[23:02] <geser> I don't know exactly the search order but yes, it should find it there (if your icon theme doesn't provide an own one)
[23:16]  * ausimage made geser changes and is awaiting the arrival on his ppa