[00:14] <\sh> somerville32, why is gtkfilechooser in the source?
[00:15] <somerville32> \sh: Because the developers put it that there?
[00:16] <\sh> somerville32, in trunk it's not there anymore :)
[00:16] <\sh> http://svn.xfce.org/svn/goodies/thunar-svn-plugin/trunk/thunar-svn-plugin/
[00:16] <\sh> #
[00:16] <\sh> argl wrong dir
[00:16] <\sh> no chance to patch it somehow away?
[00:17] <somerville32> It would be pretty invasive
[00:17] <somerville32> Plus I don't know how stable trunk is
[00:17] <\sh> na..
[00:17] <\sh> was the wrong dir
[00:18] <\sh> but it's strange, really, because: gtkfilechooser.c:#include "gtkfilechooser.h" localversion included
[00:18] <\sh> but gtkfilechooserentry.h:#include <gtk/gtkfilechooser.h>
[00:19] <\sh> without having a libgtk-2.0-dev dependency somewhere
[00:19] <somerville32> libgtk-2.0-dev is brought in automatically
[00:19] <\sh> libthunar-vfs-1-dev ?
[00:21] <somerville32> right
[00:22] <\sh> I wonder if it would be a good idea to add those build-deps directly, because they are direct build-deps..
[00:23] <somerville32> I was already told to remove pkg-config
[00:24] <somerville32> because it was dependency of a dependency of a dependency
[00:25] <LaserJock> afternoon MOTU Land
[00:25] <tritium> Hi LaserJock
[00:25] <\sh> that's crap
[00:26] <LaserJock> heh
[00:26] <\sh> for me build-deps are need to be named for things which the source depends on it
[00:26]  * LaserJock hopes \sh wasn't talking about him
[00:26] <\sh> dbus-dev is not even a direct dependency
[00:26] <\sh> LaserJock, na
[00:26] <LaserJock> tritium: good to see you
[00:26] <tritium> You too, LaserJock :)
[00:27] <\sh> so when someone things about removing pkg-config from dbus-dev or from any other indirect build-dep because they don't need pkg-config anymore this packages still needs it
[00:27] <LaserJock> tritium: I haven't had a chance to respond to the -motu-science emails but it looks like there's some good stuff to be done
[00:27] <tritium> LaserJock: no problem.  You saw mine?
[00:28] <\sh> gpocentek, ping why do you think those build-deps are not necessary?
[00:28] <LaserJock> tritium: yep
[00:28] <tritium> Cool, thanks, LaserJock.  Like I said in the mailing list post, I'd like to help as I can.
[00:29] <LaserJock> tritium: yeah, I think there are some things that you could do to kinda get the rust out ;-)
[00:29] <somerville32> \sh: I'm certainly not opposed to your line of thought.
[00:29] <tritium> LaserJock: I'm sure I am quite rusty :)
[00:32] <LaserJock> tritium: well, I'm in the middle of writing papers/dissertation and getting things finished off
[00:33] <LaserJock> but I can do a fair amount of sponsoring
[00:33] <tritium> LaserJock: I completely understand :)
[00:34] <\sh> somerville32, I noted something...after all the package looks ok for me, just fix those direct build-deps...
[00:50] <rexbron> http://revu.tauware.de/details.py?package=ubuntustudio-controls
[00:50] <rexbron> opps
[00:50] <rexbron> Need the pitch first
[00:51] <rexbron> If someone has time for a review I would really appreciate it :) http://revu.tauware.de/details.py?package=ubuntustudio-controls
[00:51] <rexbron> hey Hobbsee
[00:52] <Hobbsee> hiya!
[00:57] <LaserJock> hi Hobbsee
[00:57] <Hobbsee> LaserJock!
[00:57] <StevenK> PONI .... Oh, damn.
[00:58] <LaserJock> StevenK: heh
[00:59] <LaserJock> so was I the one that got the complex or you? ;-)
[00:59]  * StevenK shrugs
[01:00] <jdong> crimsun: thanks (re: transmission)
[01:01] <LaserJock> StevenK: how's work?
[01:02] <StevenK> LaserJock: It's fine.
[01:03] <\sh> why can't upstream follow rules..e.g. not editing directly aclocal.m4?
[01:03] <LaserJock> \sh: rules?! what rules? :-)
[01:03] <jdong> \sh: bu.. but it's open source! they can if they want!
[01:03] <jdong> :D
[01:04] <\sh> jdong, not if everything breaks after aclocal
[01:04] <\sh> and not putting their local macros inside a dir which can be included via aclocal call
[01:05] <LaserJock> detail details
[01:06] <jonnymind> Goodnight to everyone.
[01:06] <jonnymind> I sign off.
[01:07] <\sh> LaserJock, well, if someone wants to rebuild the whole source he/she's fcked
[01:07]  * RAOF tries to puzzle out why he suddenly needs to add "acpi=off" to his kernel parameters for all kernels.
[01:08] <jdong> \sh: but why does anyone want to do that when they can just download the .autopackage, run it with sudo sh, and go!
[01:08] <StevenK> RAOF: Because your machine doesn't like ACPI or Matthew Garret any more?
[01:08] <LaserJock> heh
[01:08] <StevenK> Garrett, even
[01:08] <jdong> RAOF: have you seen the weather around here? contribute a watt or two towards warming the planet! sheesh!
[01:09] <RAOF> StevenK: Apparently so.  Either 2.6.24-4 has messed with some bios stuff, or there's something wrong in initramfs-tools, because it's affecting previously-working kernels too. :(
[01:11] <jdong> ok, /usr/share/dict/words really sucks for playing hangman
[01:12] <\sh> somerville32, the reason why they ship gtk code inside their sourcetree is
[01:12] <\sh>  * alternate GtkFileChooser implementations; no stability guarantees
[01:12] <\sh>  * are made at this point
[01:12] <\sh>  */
[01:12] <zul> thats why you never reboot
[01:12] <jdong> deuteronomistic
[01:12] <jdong> hmm...
[01:13] <jdong> is that a religious term?
[01:13] <RAOF> I wonder if #ubuntu-kernel would like to hear about this.
[01:14] <zul> RAOF: everyone is traveling on -kernel
[01:14] <jdong> RAOF: have you looked in LP for a bug? usually people are fast to whine about these kinds of bugs
[01:14] <zul> RAOF: best open a bug
[01:14] <RAOF> jdong: Yeah, I've looked at LP and nothing seems to fit.
[01:14] <\sh> RAOF, well, I wonder why bugs in our kernel are getting fixed but without closing any bug report...
[01:15] <RAOF> Aww, man.  /apps/metacity/general/application_based has the sounds awesome, right up until you read the final words of the long descripiton: "largely unimplemented ath the moment" :(
[01:21] <\sh> I wonder which package it was about the new way of understanding pushd and popd (see Lucas Nussbaums Blog Article) ;)
[01:23] <\sh> ok now to bned
[01:23] <\sh> aeh bed
[01:29] <\sh> good night :)
[01:38] <RAOF> If anyone's interested in the travails of my poor laptop, bug #184712 is the good stuff.
[01:38] <ubotu> Launchpad bug 184712 in linux "[regression] Asus F3Jm fails to work correctly without acpi=off" [Undecided,New] https://launchpad.net/bugs/184712
[01:44] <LaserJock> hmm, so maybe we should retire dgetlp
[01:44] <LaserJock> from ubuntu-dev-tools
[01:45] <Hobbsee> it doesn't work for ppa
[01:45] <jdong> LaserJock: what does dgetlp do?
[01:45] <jdong> LaserJock: is it the same thing as my lpget script?
[02:11] <LaserJock> jdong: you have a lpget script?
[02:11] <jdong> LaserJock: yeah, a simple ruby script that scrapes LP
[02:12] <LaserJock> LP is dgettable now so we shouldn't need to bother
[02:12] <jdong> LaserJock: well you still need to scrape to determine what to dget, right?
[02:12] <LaserJock> no
[02:12] <LaserJock> oh, well kinda
[02:13] <LaserJock> I mean it's the same as Debian
[02:13] <LaserJock> you need the url of the .dsc
[02:13] <jdong> LaserJock: like if I wanted Gutsy's libfoo...
[02:13] <jdong> I still need to find the URL to it, right?
[02:13] <jdong> by scraping +source/gutsy/libfoo?
[02:13] <LaserJock> well, you can create the URL
[02:13] <pochu> jdong: add deb-src for gutsy and apt-get source it ;)
[02:13] <LaserJock> pochu: that's often not what you want
[02:13] <jdong> pochu: well then you add a slow 5000kb file to each apt-get update run..
[02:14] <jdong> pochu: and it's not always up to date
[02:14] <jdong> pochu: as a backporter it's irritating I have to download like 30MB of sources files just to apt-get source :)
[02:14] <pochu> I see.
[02:14] <jdong> so for now I'm just URL mining LP
[02:14] <jdong> until I have a more humane way
[02:16] <LaserJock> I guess it's /ubuntu/<release>/+source/<package>/<version/+files/<package>_<version>.dsc
[02:16] <Hobbsee> LaserJock: if that bug is fixed, probably
[02:16] <jdong> LaserJock: <version> is the annoying one to build, wouldn't you say? :D
[02:16] <LaserJock> jdong: yes, but it's easy from webUI
[02:16] <LaserJock> which I guess it was more designed to do
[02:16] <jdong> might as well regex for a dsc at /ubuntu/release/+source/package
[02:17] <pochu> jdong: file a wishlist against python-launchpad-bugs :)
[02:17] <LaserJock> that's not a very appropriate place to do that is it?
[02:18] <pochu> LaserJock: it now has blueprints support, so why not package support? ;)
[02:18] <LaserJock> although it might be the easiest for now
[02:18] <LaserJock> pochu: because that's hackish
[02:18] <LaserJock> ;-)
[02:18] <pochu> LaserJock: I suggested to rename p-l-b to python-launchpad :)
[02:18] <LaserJock> well wait
[02:18] <LaserJock> the LP dget behavior is just the same as for Debian
[02:19] <LaserJock> if you're gonna use dget for anything else you still need the .dsc URL
[02:19] <LaserJock> so I think it's pretty consistent
[02:19] <pochu> Sure.
[02:19] <Hobbsee> so then there's a script required for .dscget
[02:19] <Hobbsee> :)
[02:19] <LaserJock> yeah
[02:20] <LaserJock> the issue is not dget'ing but in an automatic way to find the .dsc
[02:23] <jdong> wget https://edge.launchpad.net/ubuntu/hardy/+source/gtkpod/ -O- | sed -n 's/<a href="\(.*\.dsc\)">.*<\/a>/'
[02:23] <somerville32> \sh_away: you posted your comment on my package twice. Just thought I'd let you know if you wanted to delete one
[02:23] <jdong> that'll do it
[02:23] <jdong> wow, irssi expands escape chars on input?
[02:23] <jdong> that's retarded
[02:24] <jdong> that's >/\\1/p
[02:24] <jdong> err, single \
[02:27]  * jdong tries to write a 1-liner script :D
[02:37] <jdong> VICTORY
[02:38] <LaserJock> :-)
[02:38] <jdong> http://paste.ubuntu.com/3741/
[02:38] <jdong> the nastiest one-liner in the word :D
[02:38] <jdong> call like lpget gtkpod hardy
[02:39] <jdong> don't ask me what it does with nonexistent packages or distros
[02:39] <StevenK> Ewww
[02:39] <StevenK> You should use $() instead of `` anyway
[02:40] <jdong> StevenK: yeah yeah :)
[02:40] <jdong> StevenK: that was just for fun... I have no intention of using this version :D
[03:01] <joejaxx> jdong: haha maybe we should team up :) i have already written a number of launchpad crawlers lol
[03:05] <LaserJock> joejaxx, jdong: if you guys could send me your launchpad screen-scrapers sometime I'd appreciate it
[04:00] <gpocentek> \sh_away: then you need to B-D on gtk, libxfce* etc, and if I do is crap feel free to take care of the review
[04:00] <gpocentek> if whwta I do*
[04:09] <jdong> joejaxx: rofl what other kinds of scrapers do you use? :D
[04:11] <joejaxx> LaserJock:  :D
[04:11] <joejaxx> jdong: well no one could tell me where to get build logs
[04:11] <joejaxx> jdong: so i built a crawler to download them
[04:11] <joejaxx> loool
[04:12] <joejaxx> lp-crawler buildlog <source\ package\ name\ here>
[04:12] <joejaxx> LOL
[04:12] <LaserJock> jdong, joejaxx: seriously though, I need to collect screen-scrapers
[04:14] <jdong> joejaxx: haha
[04:14] <jdong> LaserJock: what kind of scrapers, and what kind of quality level, what preferred language, etc
[04:14] <LaserJock> jdong: doesn't matter, as long as you use it
[04:15] <LaserJock> the point being, LP devs want to eliminate the need for screen-scrapers
[04:15] <LaserJock> so I collect things that people actually use and get them to add that functionality, where possible
[04:15] <jdong> LaserJock: the main kind of screenscraper is for dgetting the latest source package of a given distro
[04:16] <jdong> LaserJock: so if they can have a static dsc URL, like /ubuntu/hardy/+source/gtkpod/+dsc, that'd be great
[04:16] <jdong> I can poitn dget to that URL and have it fetch that
[04:16] <jdong> should be relatively easy for the LP team to add
[04:17] <LaserJock> yeah
[04:17] <ScottK> It would be really nice if dget worked on Launchpad.
[04:18] <jdong> LaserJock: and along those lines, I'd love to see a meta dget in ubuntu-dev-tools too :)
[04:19] <jdong> LaserJock: I don't know exactly what that means, but I'd like to be able to track source packages in LP, packages.qa.debian.org, REVU, debian-multimedia, etc from a single utility
[04:19] <LaserJock> ScottK: well, it does, as long as you get the .dsc URL
[04:19] <ScottK> LaserJock: Not in my experience.  Let me give it a try
[04:20] <LaserJock> ScottK: I had kiko add it relatively recently
[04:20] <jdong> ScottK: yeah, if you grab a LP dsc URL now, dget will work with it now
[04:21] <jdong> ScottK: unfortunately you still need to go hunt around LP's lightning fast interface to find that link :)
[04:22] <LaserJock> oh, and you need --insecure if you don't have LPs cert
[04:23] <jdong> apt-get install ca-certificates should suffice too
[04:23] <jdong> and it's good to have anyway
[04:24] <ScottK> Ah.  Well that's definitely progress then.
[04:24] <jdong> indeed
[04:25] <Megaqwerty> I had a (hopefully) quick question about cdbs. I was trying to package a program that used setup.py by using cdbs' python-distutils.mk (I'm assuming that was the right .mk file) and when I tried to debuild -S -sa the source, it gave me this: /usr/share/cdbs/1/class/python-distutils.mk:72: *** package uses the new Python policy; DEB_PYTHON_SYSTEM must be set to "pysupport" or "pycentral".  Stop.    Any idea what I did wrong?
[04:26] <ScottK> Megaqwerty: You didn't tell it which to use.
[04:26] <ScottK> Megaqwerty: Which are you using?
[04:27] <Megaqwerty> ScottK: I'm not sure. It's not my program. I'll look into that though. When I do find out, do I just put that variable in debian/rules?
[04:28] <ScottK> Yes.  It's a Debian packaging specific question, so if you're the packager, it's up to you to decide.
[04:28] <ScottK> Megaqwerty: pyspf is a package you can look at for an example
[04:29] <Megaqwerty> ScottK: oh. Where can I find out about the differences between the two?
[04:29] <RAOF> And you might want to check up on the cdbs documentation, http://tinyurl.com/23x2xc
[04:29] <Megaqwerty> thanks guys.
[04:47] <nenolod> crimsun, i'm in the process of taking over bmpx in debian.
[04:48] <nenolod> crimsun, thanks for the ubuntu patches. ;)
[05:16] <nixternal> oi, the weekend is over...way to quick
[05:17] <StevenK> nixternal: That's how it usually goes
[05:17] <nixternal> shoot, all day I was stuck with LUG duties
[05:18] <nixternal> yesterday, well that was to long ago, I already forgot what I did
[05:47] <LucidFox> Hardy will ship with brasero and transmission by default? Awesome!
[06:20] <wallyweek> g'morning all!
[06:21] <wallyweek> could anyone please review sdlmame? http://revu.ubuntuwire.com/index.py
[06:21] <wallyweek> could anyone please review sdlmame? http://revu.ubuntuwire.com/details.py?package=sdlmame
[06:22] <LucidFox> wallyweek> no need to double-post :)
[06:25] <wallyweek> LucidFox: right, when you post the right link ;)
[06:25] <LucidFox> ah
[06:25] <LucidFox> I see
[06:34]  * wallyweek hopes irc@work works this morning or he won't be back until 6pm UTC :(
[07:00] <warp10> Heya
[07:35] <vemon> morning
[07:36] <vemon> is there a tool to generate the debian/rules file?
[07:36] <vemon> or some kind of a simple template for it?
[07:36] <vemon> and by generating i mean with some user input :)
[07:38] <LucidFox> vemon> dh_make
[07:41] <LaserJock> vemon: not a reliable one
[07:41] <LaserJock> and pretty much nothing for debian/rules specifically
[07:42] <crimsun> unless you count cdbs, and even that's a bit of a stretch.
[07:43] <LaserJock> hmm, that's somewhat a point
[07:43] <LaserJock> although I would suggest that it's often gonna take more work
[07:43] <LaserJock> but that's basically what cdbs is I suppose
[07:46] <LaserJock> crimsun: you have MLK Day off?
[07:48] <crimsun> LaserJock: no, I work later
[07:48] <LaserJock> ah, too bad
[07:49] <LaserJock> I'll be working on a paper/dissertation/presentation
[07:49] <LaserJock> but it's kinda like time off
[07:49] <crimsun> nah, I choose to.  Holiday pay is pretty nice.
[07:49] <LaserJock> I bet
[07:49] <LaserJock> I "get" to teach this semester
[07:49] <AdamSun> hey everybody
[07:50] <crimsun> LaserJock: fun!
[07:50] <LaserJock> crimsun: it is, although it means I have to have some sort of schedule
[07:50] <LaserJock> I'm also in charge of the department computer lab this semester
[07:51] <AdamSun> i've been trying to fix a bug in a package... running into some trouble
[07:52] <AdamSun> i made a fix.. but when i try to build with pbuilder it has errors
[07:53] <AdamSun> this is my first attempt at packaging :)
[07:53] <AdamSun> any help would be very much appreciated
[07:53] <crimsun> AdamSun: a bit more verbose, please
[07:54] <crimsun> LaserJock: indeed.  A schedule can be helpful.
[07:59] <crimsun> AdamSun: (hint: we can't assist if we don't know what the error is...)
[07:59] <AdamSun> sorry... I uploaded the output to the web
[07:59] <AdamSun> http://paste.ubuntu-nl.org/52872/
[08:00] <AdamSun> the problem with the package is that the desktop file is improperly installed
[08:00] <AdamSun> so my attempt at a fix was to use the gnome.mk script from the cdbs
[08:02] <crimsun> AdamSun: are you certain your pbuilder apt cache includes the universe component?
[08:02] <AdamSun> no.. i'm not
[08:03] <AdamSun> how would you go about that?
[08:03] <crimsun> AdamSun: did you simply execute `sudo pbuilder create`?  By default, that does not add the universe component.
[08:03] <AdamSun> i used sudo pbuilder build
[08:03] <crimsun> AdamSun: no, before executing 'build'
[08:05] <AdamSun> ahh.. yeah that is what i used
[08:05] <crimsun> ok, so you need this:  echo COMPONENTS="main universe" >> ~/.pbuilderrc
[08:05] <crimsun> (do that as your unprivileged user, of course)
[08:06] <AdamSun> ok.. i will try that.. thanks
[08:06] <crimsun> then, afterward, sudo pbuilder update --override-config
[08:06] <AdamSun> i was just going to ask if i had to recreate or update :)
[08:11] <AdamSun> ok.. wonderful it is working as it should now..  simple mistake it seems
[08:12] <crimsun> good.
[08:22] <AdamSun> ok.. ran into another problem.. sorry for the bother
[08:22] <AdamSun> the deb gets built correctly.. or so it seems
[08:23] <AdamSun> however when i open it with gdebi.. it says that Dependency is not satisfiable: libc6
[08:23] <AdamSun> which seems very strange to me
[08:24] <crimsun> are you running gutsy?
[08:24] <AdamSun> yeah.. i was thinking that was the problem
[08:24] <crimsun> then that's expected.  Your pbuilder is hardy.
[08:25] <AdamSun> is there a proper way to test the package?
[08:26] <crimsun> there are suggested methods; all involve testing in some sort of hardy install, chroot, vm, etc.
[08:26] <AdamSun> i see
[08:26] <AdamSun> chroot or vm seems like it'd be the easiest for me
[08:27] <AdamSun> any personal reccomendation?
[08:27] <crimsun> I use chroots or full-blown installs.
[08:28] <AdamSun> ok.. i'll work on that.. thanks for all of the info
[09:04] <jonnymind> Hello
[09:04] <AdamSun> hello
[09:05] <AdamSun> crimsun: I believe i got everything working.. and I think I solved the bug in the package as well
[09:05] <jonnymind> I ask if someone may have a look at http://revu.tauware.de/details.py?package=falconpl
[09:05] <jonnymind> Everythin should be fine now.
[09:08] <LucidFox> Stupid Debian, always reinventing the wheel.
[09:08] <LucidFox> Couldn't the qtcurve maintainer look at my packaging first? I think it was better. :/
[09:15] <geser> good morning
[09:30] <asabil> hi all
[09:31] <asabil> anyone to review please : http://revu.tauware.de/details.py?package=libgee
[09:39] <LucidFox> asabil> It's better to link to the specific LGPL version
[09:39] <asabil> LucidFox: it is 2.1 or later
[09:39] <asabil> so ...
[09:39] <smarter> Can someone please review this package? http://revu.tauware.de/details.py?package=extremetuxracer
[09:40] <LucidFox> since the copyright blurb in debian/copyright is for LGPL 2.1, consider linking to /usr/share/common-licenses/LGPL-2.1
[09:41] <asabil> LucidFox: are you sure, because the /usr/share/common-licenses/LGPL is the one that conforms the most
[09:41] <LucidFox> LGPL is a symlink, it currently points to LGPL-2.1 but it may change
[09:42] <LucidFox> you can mention something like "LGPL-2.1 for version 2.1 or LGPL-3 for version 3"
[09:42] <LucidFox> but it's not a blocker, I believe
[09:42] <LucidFox> so feel free to leave it unchanged if you disagree
[09:42] <asabil> LucidFox: It is not about agreeing/diagreeing
[09:43] <asabil> I want to see this package accepted and that's all
[09:43] <man-di> LucidFox: in Debian the package gets rejected when its ...or later and links a specific license like you say
[09:43] <asabil> am not really very interested in packaging
[09:43] <LucidFox> man-di> sorry then
[09:48] <LucidFox> smarter> every package I've seen uses (LP: #xxx) rather than (Closes LP: #xxx)
[09:48] <smarter> LucidFox: ok
[09:48] <LucidFox> I'll write more
[09:48] <geser> man-di: if a package build-depends on ibm-j2sdk1.6 in Debian is it safe to build it with sun-java6 (or is it sun-java5?) in Ubuntu?
[09:50] <selckin> yes
[09:50] <LucidFox> smarter> posted
[09:51] <smarter> LucidFox: thanks
[09:51] <man-di> geser: normally yes, but needs to be tested to be 100% sure
[09:51] <man-di> geser: what package is it?
[09:51] <TheMuso> c
[09:51] <TheMuso> ugh wrong tab
[09:51] <geser> man-di: libjibx-java
[09:52] <man-di> geser: a patch to Debian would be cool
[09:52] <LucidFox> geser> Does it build with icedtea?
[09:53] <emgent> heya
[09:53] <man-di> geser: as ibm jdk is not in archive
[09:55] <LucidFox> jonnymind> looking at falconpl
[09:55] <jonnymind> LucidFox: thanks
[09:58] <geser> man-di: what would be the correct build-depends for Debian?
[09:58] <man-di> e.g. sun-java6-jdk
[09:58] <man-di> dont forget to adjust debian/rules to use that
[10:00] <smarter> LucidFox: new version uploaded ;)
[10:00] <LucidFox> smarter> ok, but IANAMOTU, so I can't advocate it :)
[10:01] <LucidFox> (if I could, I would subject it to more thorough review)
[10:01] <geser> man-di: nice, somehow I missed that Debian has now also the sun-java packages
[10:01] <man-di> geser: since a long time
[10:01] <man-di> geser: afaik at the same time as Ubuntu
[10:07] <LucidFox> jonnymind> Commented
[10:07]  * LucidFox pings dholbach
[10:08] <dholbach> hi LucidFox
[10:08] <LucidFox> You should probably write on the "Packaging from scratch" page in big bold letters: "This is only a demonstration of what occurs under the hood of debhelper, DO NOT USE THIS" :)
[10:09] <LucidFox> otherwise we end up with a debian/rules like this: http://revu.ubuntuwire.com/revu1-incoming/falconpl-0801202000/falconpl-0.8.8/debian/rules
[10:09] <dholbach> LucidFox: which page are you referring to?
[10:09] <LucidFox> in the packaging guide
[10:09] <jonnymind> LucidFox: I cannot understand.
[10:09] <LucidFox> "Packaging from scratch", hello without debhelper
[10:10] <LucidFox> jonnymind> What isn't clear? I'm happy to explain :)
[10:10] <jonnymind> The comment on Packaging from scratch
[10:10] <jonnymind> in irc
[10:10] <LucidFox> ah... that's not directed to you :)
[10:10] <dholbach> LucidFox: I made a note on my todo list, but it's a wiki after all, you could do the change too :)
[10:11] <LucidFox> ah
[10:11] <wallyweek> g'morning all!
[10:11] <dholbach> LucidFox: thanks for letting me know
[10:12] <jonnymind> LucidFox: Ic. are theese stoppers?
[10:13] <LucidFox> jonnymind> Thiese are just my recommendations, I'm not a MOTU, so my reviews aren't "binding"
[10:13] <jonnymind> I.c. Thanks; about level 4, I picked that becasue level 5 was warned by lintian...
[10:14] <LucidFox> jonnymind> If you set "debhelper (>= 5) in debian/control, lintian wouldn't complain about compat 5
[10:15] <jonnymind> Ah, I see
[10:15] <jonnymind> thanks
[10:29] <jonnymind> LucidFox: the document you pointed out as changelog doesn't open up; may you please provide another one?
[10:29] <wallyweek> is revu ko to your knowledge?
[10:29] <LucidFox> wallyweek> What do you mean?
[10:30] <jonnymind> I have problems getting there too
[10:30] <LucidFox> jonnymind> Basically, I just meant that the standard form for the initial debian/changelog is "Initial release (LP: #xxx)"
[10:30] <jonnymind> IC
[10:31] <jonnymind> Conforming.
[10:32] <wallyweek> I can't reach it
[10:32] <LucidFox> wallyweek> It's slow, yes
[10:33] <wallyweek> LucidFox: ah, thanks
[10:34] <jonnymind> LucidFox: I have cleaned typos and deb depends; about other debhelpers, I would prefer not to use them if this isn't a stopper.
[10:34] <LucidFox> jonnymind> Why not? It's cleaner
[10:35] <jonnymind> LucidFox: It's obscurer; especially to just copy files in the right place. And it would require me to recheck the whole build and install process.
[10:36] <jonnymind> Last time I added a couple of debhelpers it didn't change the package and required me 8 hours to make them work.
[10:36] <jonnymind> Maybe my fault, but as long as theese are not stoppers...
[10:36] <LucidFox> Is upstream packaging that screwed up? o_O
[10:36] <jonnymind> Eh?
[10:37] <LucidFox> never mind :)
[10:38] <jonnymind> No, it's the overall documentation that's missing.
[10:39] <jonnymind> There's the policy which says how things should be, and there's the man pages that say how to use small tools.
[10:39] <jonnymind> A big plan of how to do things right is missing. You learn it here by osmosis, but it requires a bit of time.
[10:40] <jonnymind> And there's the wiki pages, with small samples that show how things are done, usually fail to explain why, and to help doing the harder (real-world) things.
[10:41] <LucidFox> I see.
[10:42] <LucidFox> It's partially the Packaging Guide's fault, it doesn't explain that debhelper is the preferred way. You could probably evade your problems if you started with a package generated by dh_make
[10:42] <jonnymind> Which, btw, is said not to work with cmake.
[10:42] <jonnymind> Also, falcon sources are kept on different source projects for administrative reasons.
[10:43] <jonnymind> Different servers, different developers, different commit policy, different security.
[10:43] <broonie> Well, it will generate a template for autofoo stuff but it's not particularly difficult to change for some othe rbuild system.
[10:43] <jonnymind> So, the source package merges different repositories, having different build system, through a unifying builder.
[10:43] <jonnymind> broonie: you know it. But it's not said in docs.
[10:44] <jonnymind> Nor is said WHAT it does, exactly, and HOW it can fit non-autofoo needs.
[10:44] <jonnymind> So, it is natural to avoid it when you're not in the simpe ./configure;make;make install case.
[10:45] <dholbach> the 'reference packages' section could do with some beefing up :)
[10:45] <jonnymind> It's just natural, as you'd have to study a different meta-tool and all its weirdness before even to decide that, hey, with a bit of tricks it could work also fro you...
[10:45] <broonie> jonnymind: What documentation would you look for?
[10:46] <broonie> An explanation of what each of configure, make, make install does might help...
[10:47] <jonnymind> broonie: docs on debian packaging are missing all the time "context information". Which is what makes effective and productive a workflow, btw.
[10:47] <jonnymind> It's managerial theory.
[10:47] <jonnymind> Very non-IT. So I understand.
[10:48]  * broonie always found the Debian documentation well above average :)
[11:07] <cyberix> revu down?
[11:08] <LucidFox> cyberix> No, just very slow
[11:12] <jonnymind> It's fun how revu tends to get ill on revu days
[11:13] <persia> LucidFox: Are you sure it's up?  I've not had a web page load for > 300 seconds, and while I can ping, interactive access also doesn't respond.
[11:15] <LucidFox> Hmm... now it doesn't seem to load at all anymore
[11:17] <LucidFox> persia, since you previously sponsored the qtcurve packages, could you please look at bug #183435?
[11:17] <ubotu> Launchpad bug 183435 in kde4-style-qtcurve "Please sync gtk2-engines-qtcurve and kde-style-qtcurve 0.55.2-1 from Debian unstable (main), sponsor kde4-style-qtcurve 0.55.2-0ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/183435
[11:18] <persia> LucidFox: You posted your tar.gz and links to the package to the ITP, right?
[11:19]  * persia is annoyed at the removal of a known working get-orig-source
[11:20] <LucidFox> yes, it was frustrating, the DD came out of nowhere after four months of absence and discarded all my changes
[11:21] <LucidFox> I mailed them to him for possible merge
[11:21] <persia> LucidFox: Is there nothing worth keeping in a merge?
[11:23] <LucidFox> There are three changes that I consider an improvement over the Debian version: the get-orig-source script, the new FSF address in debian/copyright, and a cleaner way to invoke cmake in debian/rules
[11:23] <LucidFox> but since they don't affect the build at all...
[11:25] <persia> OK.  I think the address thing is a fairly important bug, and should definitely be in the BTS.  get-orig-source and cleaner rules are nice, but not so critical.  I'm still catching up on things, but will definitely look at this first in my queue.
[11:26] <vemon> anything i should know before using cdbs for packaging? already know to avoid the auto generation of debian/control :)
[11:27] <LucidFox> vemon> Did you read the CDBS section of the packaging guide?
[11:28] <vemon> lucidfox, yes i did. and read some parts of the official cdbs docs too
[11:28] <vemon> seems like a handy tool but i was wondering if there are any drawbacks
[11:29] <vemon> (there always are :D)
[11:29] <jonnymind> LucidFox: well, to be slow, revu seems a bit stopped:
[11:29] <jonnymind> ####
[11:29] <jonnymind> U 192.168.1.3:32776 -> 192.168.1.1:53
[11:29] <jonnymind>   .............revu.tauware.de.....
[11:29] <jonnymind> #
[11:29] <jonnymind> U 192.168.1.1:53 -> 192.168.1.3:32776
[11:29] <jonnymind>   .............revu.tauware.de..................sparky...-............(^
[11:29] <jonnymind> ####
[11:29] <jonnymind> T 130.239.18.172:6667 -> 192.168.1.3:44582 [AP]
[11:29] <jonnymind>   :vemon!n=vemon@hoasb-ff03dd00-157.dhcp.inet.fi PRIVMSG #ubuntu-motu :+lucid
[11:29] <jonnymind> This is a ngrep after having launced dput...
[11:30] <geser> vemon: the only drawback with cdbs is that when you need something unusual you need to read deep into the docs or cdbs itself
[11:32] <vemon> ok. thanks! at the moment my needs are so primitive that cdbs will probably do fine
[11:34] <tarzeau> can i get some packages from debian synced to ubuntu?
[11:35] <tarzeau> or is it still automatic?
[11:35] <vemon> tarzeau, the automatic sync for hardy is already done
[11:36] <vemon> you should request sync with a launchpad bug
[11:36] <tarzeau> vemon: i don't know how to use launchpad, i used to just ping people on irc, but i lost my irssi window for it
[11:37] <geser> tarzeau: what do you want synced from Debian?
[11:38] <tarzeau> geser: ttf-marvosym
[11:41] <geser> tarzeau: bug #184790
[11:41] <ubotu> Launchpad bug 184790 in ubuntu "Please sync ttf-marvosym 0.1+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/184790
[11:42] <tarzeau> geser: thank you
[11:44] <vemon> is it still possible to get new packages & patches in to hardy?
[11:44] <vemon> i have a few coming this week
[11:44] <persia> vemon: packages are permitted for a couple more weeks.  patches are permitted for a couple more months.
[11:45] <vemon> ok. great :)
[11:45] <vemon> so i should conscentrate on the new packages first
[11:45] <amarillion> revu is completely down now...
[11:59] <wallyweek> is revu day already ended?
[12:00] <LucidFox> wallyweek> no
[12:00] <LucidFox> (I think)
[12:01] <LucidFox> just REVU happens to be down
[12:04] <Hobbsee> siretart: any idea why it's down?
[12:41] <jonnymind> ...
[12:41] <jonnymind> revu is up again
[12:42] <Hobbsee> feature freeze already?
[12:43]  * Hobbsee tries to think what's new in the way of ubuntu feature development
[12:43] <jonnymind> well, afaik none of the packages in the lis
[12:44] <jonnymind> well, afaik none of the packages in the list has been uploaded...
[12:44] <Hobbsee> i meant main, but true
[12:49] <jonnymind> I uploaded a new version of http://revu.ubuntuwire.com/details.py?package=falconpl with issues fixed. Waiting for it to appare...
[12:53] <jonnymind> Ok ppl; later
[12:57] <slytherin> does anyone have any diea how stable is grub2 on PC platform?
[12:59] <man-di> slytherin: hello
[12:59] <mruiz> hi all
[12:59] <slytherin> man-di: hi.
[12:59] <man-di> slytherin: do you found a fix for lucene2 FTBFS? I team member can reproduce it in Debian too (I cant)
[13:00] <slytherin> man-di: Is the error same?
[13:00] <slytherin> man-di: I mean same as the one seen in ubuntu build logs?
[13:00] <man-di> yes
[13:01] <slytherin> man-di: I have the solution but that also needs a fix to w3c-dtd-xhtml package
[13:02] <LucidFox> hmm, REVU is back up
[13:02] <man-di> slytherin: what is the solution for lucene2?
[13:02] <LucidFox> slytherin> Well, I used grub2 without any problems
[13:02]  * sistpoty|work is away: coffee break
[13:03] <persia> REVU is somewhat back for now.  Still experiencing issues.
[13:04] <frafu> Hello, could anybody please review mousetweaks on motu: http://revu.tauware.de/details.py?package=mousetweaks ?
[13:05] <TheMuso> frafu: Sure, I'll take a look.
[13:07]  * Hobbsee attempts to ssh into revu
[13:08] <zul> nooo...you are going to break it
[13:08] <TheMuso> haha
[13:08] <TheMuso> I just managed to pull a package form it with no problems.
[13:09] <slytherin> man-di: Sorry I was away. A small patch to source and some packaging changes are needed to use DTDs from w3c-dtd-xhtml. The problem is that one of the unit tests tries to validate an xml using DTD on internet but since it doesn't get net access form inside pbuilder, the test suite fails with error.
[13:09] <frafu> TheMuso:  Thanks; I hope mousetweaks will make it into hardy, because the gui of mousetweaks is shipped as the Accessibility tab of the Mouse control panel since GNOME 2.21.5.
[13:11] <TheMuso> frafu: Nice. Hopefully we can also get included in Ubuntu proper in hardy+1.
[13:11] <TheMuso> s/get/get it/
[13:12] <wallyweek> Hello, could anyone please review sdlmame on revu? Thanks :) http://revu.ubuntuwire.com/details.py?package=sdlmame
[13:13] <slytherin> LucidFox: Thanks for confirmation. Any visible changes from user's point of view?
[13:13] <frafu> TheMuso: As soon as it is in Universe, I will write a main inclusion report.
[13:13] <TheMuso> frafu: Ok.
[13:13] <LucidFox> not really, still the same ugly text-mode menu
[13:13] <LucidFox> even with gfxterm
[13:14] <pochu> Is wiki.u.c down?
[13:14] <LucidFox> pochu> opens for me
[13:14] <persia> pochu: works for me
[13:14] <amarillion> works for me
[13:15] <man-di> slytherin: can you show me the changes you did?
[13:15] <slytherin> man-di: Sure. I will paste debdiff somewhere. Give me 5 minutes
[13:16] <TheMuso> iii/c
[13:26] <pochu> whassup with freenode? :)
[13:27] <mruiz> pochu, kernel panic ;-)
[13:28] <broonie> There was a wall message about planned maintainance until (IIRC) ~1400
[13:28] <zul> someone keeps tripping over the plug
[13:28] <StevenK> broonie: 1400 sounds right
[13:30] <slytherin> Hi all, how can I use some passphrase caching using seahorse so that I don't have to enter password every time I try to create source package?
[13:35] <persia> slytherin: Configure seahorse-agent.
[13:36] <jpatrick> pochu: some servers falling of the inet
[13:36]  * jpatrick hides from persia's @
[13:37] <persia> jpatrick: ?
[13:37] <slytherin> persia: done now how to let debuild know to use agent?
[13:37] <jpatrick> persia: op status ;)
[13:38] <persia> jpatrick: I'm not sure how that happened.  Thanks for pointing it out.
[13:38] <jpatrick> "07:04 ** ServerMode/#ubuntu-motu [+o persia] by irc.freenode.net"
[13:38] <persia> jpatrick: What timezone?
[13:38] <pochu> persia: you are opped for at least 15 hours ;)
[13:38] <jpatrick> odd, must of been the split
[13:39] <persia> Not if it was 15 hours.  I was in deep idle then.
[13:39] <pochu> ( That's when I started irssi, and you were +o )
[13:39] <jpatrick> happened ~30 minutes ago
[13:40] <geser> slytherin: I only sign when I want to upload and don't sign during debuild or dpkg-buildpackage
[13:41] <persia> Anyone good with IRC want to find who lives at LPuteaux-151-41-37-62.w217-128.abo.wanadoo.fr. ?
[13:41] <zul> someone who is french? :0
[13:41] <slytherin> geser: I am not sure if it will work for me. let's see. Anyway I got the caching working
[13:42] <slytherin> man-di: Please check this debdiff - http://pastebin.com/m2a5afb22 It will only work if this bug us fixed - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423087
[13:42] <ubotu> Debian bug 423087 in w3c-dtd-xhtml "w3c-dtd-xhtml: path to entity sets is wrong" [Normal,Open]
[13:44] <Kmos> persia: do whois 217.128.89.62 at console
[13:44] <man-di> slytherin: what about including xhtml1-transitional.dtd temporaily in the package until the bug is fixed?
[13:45] <geser> slytherin: I use it also as a safety guard to not accidental upload stuff
[13:45] <persia> Kmos: Thanks.  Perhaps it's not a mistake by someone here then.
[13:45] <amarillion> I think I fixed the problem with alex4 on 64 bit. I'm not running 64 bit though, so I can't confirm myself. Would somebody care to give it a try? http://revu.tauware.de/details.py?package=alex4
[13:47] <slytherin> man-di: What about license mix up (?) and we will also need to include the entity sets and all other files that the DTD depends on. I would prefer the bug fixing. It is not that hard, the problem making a decision as to which way to fix it.
[13:47] <man-di> slytherin: was just a short idea, I dont know much about this stuff
[13:49] <slytherin> man-di: Can you push for the bug fix? :-)
[13:50] <man-di> slytherin: I can try
[13:54] <jpatrick> persia: they're probably all +i, so you won't see them
[13:54] <Hobbsee> who *.151-41-37-62.w217-128.abo.wanadoo.fr
[13:54] <Hobbsee> persia: there's no one on there from that IP
[13:56] <persia> Hobbsee: That was what I found.  I was hoping someone just ran wget --mirror expecting that to be useful.  It seems it's something deeper.  Maybe it will stop soon.
[13:59] <asabil> hi all
[14:00]  * sistpoty|work is back
[14:00] <geser> man-di: can you look at the changes to libjibx-java? http://members.ping.de/~mb/tmp/debian.debdiff
[14:01] <LucidFox> amarillion> upstream is under GPLv2 or later, and the packaging is under GPLv3 only
[14:01] <sistpoty|work> Hobbsee: do you have root@sparky?
[14:01] <geser> man-di: is this debdiff acceptable for debian before I submit a bug?
[14:01] <Hobbsee> sistpoty|work: yes
[14:02] <LucidFox> amarillion> it's better to license packaging under the same conditions, so patches can be sent upstream
[14:02] <Hobbsee> sistpoty|work: i'm currently playing with it, with persia
[14:02]  * Hobbsee knows slightly more about apache now
[14:02] <sistpoty|work> Hobbsee: can you blacklist that ip? (cannot login from work, since my work key still didn't get picked up with lpkeys)
[14:02] <persia> sistpoty|work: That's the plan.
[14:03] <sistpoty|work> :)
[14:03] <slytherin> geser: Can you please make build depends as sun-java5-jdk. Thsi will make sure that program will run with both java5 and java 6. Also adjust 'Depends' and JAVA_HOME in rules accordingly.
[14:05] <Hobbsee> sistpoty|work: yeah.  done that :)
[14:05]  * Hobbsee watches the load drop
[14:05] <sistpoty|work> Hobbsee: thanks
[14:06] <geser> slytherin: sun-java5-jdk instead of sun-java6-jdk? or as an alternative?
[14:06] <amarillion> LucidFox, ok, I'll change that
[14:07] <amarillion> I thought you can't use sun-java5-jdk in build-depends
[14:07] <man-di> geser: in general yes, but I wouldnt declare it as NMU from the start
[14:07] <slytherin> geser: instead. it's like you may not be able to use program built with java6 with a runtime of java 5 (depends on ant build script). but you can surely use program built with java 5 with runtime of java 6
[14:07] <amarillion> you definitely can't on ppa
[14:08] <man-di> slytherin: sun-java6-jdk is IMO better
[14:08] <man-di> slytherin: and the package needs to use target/source anyway
[14:08] <amarillion> the automated build system of ppa doesn't work with sun-java5-jdk
[14:08] <geser> amarillion: it should, at least for hardy
[14:09] <man-di> geser: you see: two people, three opinions :-)
[14:09] <amarillion> oh I'm glad it's fixed
[14:09] <slytherin> man-di: yes but aren't we always in favour of maintaining backward compatibility. :-) So unless the program uses any java 6 specific feature it is better to build it with java 5
[14:09] <man-di> slytherin: the source setting takes care of this
[14:09] <man-di> slytherin: source/target setting....
[14:10] <slytherin> man-di: Then it is ok.
[14:10] <Hobbsee> right, revu is fixed.
[14:10] <slytherin> geser: By the way, did you try if that package can be built using GCJ? Just curious. :-)
[14:10] <zul> Hobbsee: yay
[14:11] <persia> REVU is working again, thanks to Hobbsee and sistpoty.
[14:11] <geser> slytherin: no, what need I change for testing?
[14:11] <Hobbsee> and persia
[14:11]  * persia only griped
[14:11]  * Hobbsee is still incompetent with apache.
[14:11] <slytherin> geser: build dependency as 'java-gcj-compat-dev' instead of any sun-java package
[14:11]  * sistpoty|work only pressed one button so far *g*
[14:12] <persia> It was an important button :)
[14:13] <Hobbsee> it was the "this is how you fix it" button
[14:13] <slytherin> geser: and run time dependency as java2-runtime. If the package builds with GCJ then it will run with any VM. And all JVM package 'Provides' java2-runtime. :-)
[14:13] <geser> slytherin: and what set I JAVA_HOME_DIRS to?
[14:13] <slytherin> geser: /usr/lib/jvm/java-gcj
[14:13] <sistpoty|work> Hobbsee: heh, and the reset button g
[14:14] <Hobbsee> yeah, that too
[14:14] <slytherin> man-di: Going home. See you tomorrow.
[14:14] <man-di> slytherin: have fun
[14:18] <geser> man-di: should I use directly -2 as debian revision for the debian debdiff?
[14:19] <man-di> geser: yes
[14:19] <geser> btw: it doesn't build with gcj
[14:19] <man-di> I will add more changes anyway
[14:24] <geser> man-di: is http://members.ping.de/~mb/tmp/libjibx-java.debdiff enough for you or should I file a bug and attach it?
[14:24] <yamal> MOTUs, an improved sabnzbd package is awaiting review @ http://revu.tauware.de/details.py?package=sabnzbdplus
[14:26] <man-di> geser: please mail me personally: konqueror@gmx.de
[14:27] <man-di> geser: with the debdiff attached
[14:29] <civija> guys, can someone sponsor this please https://bugs.launchpad.net/bugs/184261?
[14:30] <ubotu> Launchpad bug 184261 in slrnface "slrnface doesn't display X-Face header" [Undecided,In progress]
[14:32]  * LucidFox wonders why everyone links to revu.tauware.de rather than revu.ubuntuwire.com
[14:33] <Hobbsee> LucidFox: ubuntuwire was down for a while, and revu preceeded ubuntuwire anyway.
[14:34] <yamal> and all mail from revu has links to tauware.de, not ubuntuwire
[14:34] <LucidFox> ah
[14:35] <LucidFox> yamal> commented
[14:36] <yamal> LucidFox: tx
[14:44] <RainCT> hey
[14:45] <bddebian> Heya gang
[14:45] <sistpoty|work> hi bddebian
[14:45] <geser> Hi bddebian
[14:45] <emgent> heya
[14:46] <bddebian> Hi sistpoty|work, geser, emgent :)
[14:47] <LucidFox> RainCT> Looks like your MOTU application is going to succeed :)
[14:47] <LucidFox> 6 support voices so far
[15:07] <RainCT> LucidFox: yes :D
[15:07]  * RainCT is happy
[15:07] <foolano> hi
[15:08] <\sh> apachelogger_, check your revu libksquirrel :)
[15:08] <\sh> apachelogger_, and please fix ;)
[15:08] <apachelogger_> meh
[15:08] <apachelogger_> KDE 4 ftw!
[15:10] <\sh> apachelogger_, nix fix it and let's get it out of revu
[15:10] <\sh> apachelogger_, revu day now
[15:10]  * apachelogger_ notes that wednesday would be a much better revu day
[15:14] <TheMuso> c
[15:14] <TheMuso> ugh
[15:14] <cyberix> dh_clean doesn't remove substvars?
[15:14]  * apachelogger_ restricts the build of ksquirrel to i368
[15:15] <cyberix> I now use dpkg-shlibdeps to create substvars.
[15:16] <apachelogger_> uhhhhhhh, god I hate that man page policy
[15:16] <apachelogger_> as if any normal user would have a look at the manpage
[15:16] <cyberix> Should I have a substvars template in my package or should the file be created by dpkg-shlibdeps?
[15:16] <bddebian> cyberix: Let debhelper create it
[15:17]  * LucidFox wonders if anything is going to clean up NEW today
[15:17] <LucidFox> * anyone
[15:17] <cyberix> bddebian: dh_shlibdeps is in some way equivalent to dpkg-shlibdeps?
[15:19] <LucidFox> cyberix> it's a wrapper
[15:19] <LucidFox> around dpkg-shlibdeps
[15:22] <TheMuso> frafu: Comments left.
[15:23] <frafu> TheMuso: thanks
[15:23] <TheMuso> frafu: You're welcome, I really want to see us get this in.
[15:32] <\sh> anybody using eclipse with pydev as IDE?
[15:42] <LucidFox> I periodically see binary packages named something like "libfoo1c2"
[15:42] <LucidFox> what does c2 mean?
[15:42] <slangasek> "C++ ABI verision c2"
[15:50] <cyberix> http://revu.tauware.de/revu1-incoming/malbolge-0801211640/malbolge-0.1.1/debian/copyright
[15:50] <cyberix> Does this look ok?
[15:56] <\sh> if  a package on revu has two advocates...it can be uploaded, right? who is doing the upload the last advocator?
[15:56] <LucidFox> \sh> depends
[15:56] <Hobbsee> \sh: usually, i think
[15:57] <Hobbsee> unless there's an agreement otherwise
[15:57] <sistpoty|work> \sh: yes, than it can be uploaded, but one of the advocates should do it (at least I wouldn't upload s.th. I didn't review myself)
[15:57] <sistpoty|work> s/than/then
[15:58] <\sh> sistpoty|work, that's what I mean..the last advocator can do the upload....
[15:58] <sistpoty|work> \sh: sure
[15:58] <\sh> ok mmdb uploading
[16:05] <frafu> TheMuso: In one comment in the mousetweaks review you say to use Standards 3.7.3. In debian/control, Standards is already 3.7.3. Do I have to set it elsewhere, too?
[16:06] <\sh> gpocentek, ping
[16:06] <TheMuso> frafu: Hrm hang on, let me have a look. i don't know how that came about.
[16:07] <TheMuso> frafu: Ok you're right. I think I was looking at an older revision of the package. Don't mind me. :p
[16:08] <frafu> TheMuso; ok.
[16:09] <asabil> anyone to review : http://revu.tauware.de/details.py?package=libgee ?
[16:12]  * apachelogger_ throws http://revu.ubuntuwire.com/details.py?package=libksquirrel at \sh
[16:14] <\sh> apachelogger_, give me some mins..need to check flpsed ,-)
[16:14] <\sh> sistpoty|work, new upstream addressed all our changes btw of flpsed
[16:14] <apachelogger_> pffft
[16:14]  * apachelogger_ scuttles off to read latest issue of linuxuser
[16:15] <\sh> apachelogger_, added the man page?
[16:17]  * ScottK does  a victory dance.
[16:17]  * ScottK has working versions of all relevant packages on Dapper for a clamav backport of the current version.
[16:19] <gpocentek> \sh: pong
[16:20] <TheMuso> ScottK: Nice.
[16:20] <\sh> gpocentek, http://revu.tauware.de/details.py?package=thunar-svn-plugin why do you think direkt-build-deps are not necessary?
[16:21] <frafu> TheMuso: I just uploaded the corrected version: http://revu.tauware.de/details.py?package=mousetweaks
[16:21] <gpocentek> \sh: like I said, it's brought by the othe B-D
[16:21] <gpocentek> other*
[16:22] <TheMuso> frafu: Thanks, I will have a look shortly.
[16:23] <\sh> gpocentek, but what when a build-dep package changes the deps to not include a direct-build-dep anymore? let's say libdbus-dev is removing pkg-config from it's package because they are using something else ... this package  which indirectly-depends on it would FTBFS it
[16:23] <frafu> TheMuso: thanks
[16:23] <gpocentek> \sh: why? if dbus-dev doesn't use pkg-config anymore, the thunar plugin will not use it either
[16:24] <\sh> gpocentek, hehe...but it needs it
[16:24] <\sh> gpocentek, not dbus-dev but pkg-config ;)
[16:25] <gpocentek> \sh: I need to have an other look but doesn't it need pkg-config to get compilation flags of dbus?
[16:25]  * LucidFox is worried by the sudden emergence of packages using the (Closes LP: #xxx) syntax. Where did they even find it/
[16:26] <gpocentek> anyway keeping it in B-D is not such a bug problem
[16:26] <gpocentek> big*
[16:27] <cyberix> I'm looking after first advocate for my package Malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
[16:27] <\sh> gpocentek, nope...it needs it for their aclocal.m4 stuff to check if a package is there or not...the same applies for GTK and friends
[16:27] <gpocentek> \sh: you're certainly right
[16:28] <\sh> gpocentek, that's why I was wondering that you think, not having direct-build-deps noted in control...
[16:29] <gpocentek> \sh: pkg-config is usefull to get the compilation conf for libs
[16:29] <gpocentek> so it needs to be a dep of the -dev packages IMO
[16:30] <gpocentek> but again, you're certainly right
[16:31] <\sh> apachelogger_, why didn't you add ghostscript to the build-deps?
[16:31] <\sh> apachelogger_, and netpbm check fails too ;)
[16:33] <apachelogger_> \sh: doesn't work, there is an issue in the detection system
[16:34] <\sh> apachelogger_, elaborate?
[16:34] <sistpoty|work> \sh: excellent about flpsed :)
[16:34] <\sh> sistpoty|work, requested a sync
[16:35] <sistpoty|work> :)
[16:35] <apachelogger_> \sh: nah, ain't worth it... upstream will take care of this, once I get hold of him ;-)
[16:36] <\sh> apachelogger_, and don't advocate your own packages ;)
[16:38] <apachelogger_> \sh: persia told me to, apparently it appears rather strange when I don't advocate my own package ^_^
[16:39] <\sh> anyways looks ok...advocated...
[16:39]  * apachelogger_ uploads
[16:39] <apachelogger_> \sh: can you archive?
[16:40] <\sh> apachelogger_, done
[16:40] <apachelogger_> \sh: thanks for your time :)
[16:43] <\sh> TheMuso, did you upload "jaaaa"?
[16:43] <\sh> make it -a ;)
[16:46] <\sh> TheMuso, got it...
[16:47] <TheMuso> \sh: yes I did. I know it technically should have gotten a second advocate, but the changes to the latest upload were to address Peris'a comments, which weren't blockers.
[16:48] <\sh> TheMuso, it had two ads anyways...at least one for the first upload ,)
[16:48] <TheMuso> Yeah I know
[16:51]  * LucidFox looks at the growing NEW apathetically
[16:53] <TheMuso> Lure: It will be checked. Don't panic.
[16:54] <TheMuso> LucidFox: even
[16:54] <LucidFox> heh
[17:08]  * sistpoty|work needs to go
[17:09] <sistpoty|work> cya
[17:31] <frafu> TheMuso: I just did an error and uploaded a wrong version to revu; the correct version is the version that I uploaded January 21 17:20
[17:31] <TheMuso> frafu: Ok.
[17:34] <\sh> guys, anyone who is using hardy + eclipse + pydev (gcj variant) could you check this out: have a python source opened, do a Ctrl+L (goto line) enter a line number and jump there and then do something else like editing etc. is eclipse closing unexpectedtly?
[17:41] <pochu> StevenK: did you forward the liferea hildon patches upstream?
[17:42] <TheMuso> pochu: You likely won't get a response from him for another 5 hours at the least.
[17:43] <pochu> TheMuso: it can wait, as long as he answers :)
[17:48] <TheMuso> pochu: Fair enough. I just couldn't remember whether you idle or not.
[18:24] <vemon> could someone point out my mistake in this debian/rules file: https://ukuti.mine.nu/temp/rules
[18:25] <vemon> when i build the package it doesn't include the binary though it's built
[18:26] <vemon> and i only have one Makefile which just builds one binary
[18:26] <vemon> this is the first package i've made from scratch so i'm a little bit confused about what to try next :)
[18:29] <geser> vemon: check the contents of the subdirs in debian and check the contents of the debian/pkgname.install file
[18:29] <geser> vemon: btw your certificate expired
[18:30] <vemon> well i was just too lazy to type in my password :D the cert should be fine
[18:33] <vemon> the debian dir contains two dirs after "dpkg-buildpackage": 1. lash-wrap (contains docs) 2. tmp/bin (contains the binary)
[18:33] <geser> vemon: lash-wrap is the package name?
[18:33] <vemon> yes
[18:34] <cyberix> Does revu have a freeze for new packages before the actual FeatureFreeze?
[18:34] <vemon> the lash-wrap dir actually has /usr/share/doc/lash-wrap -dir which has README
[18:34] <geser> have you a lash-wrap.install file listing which files belong to it? see man dh_install
[18:35] <geser> cyberix: no, you can still upload packages to revu after FF but don't expect them to get reviewed timely
[18:35] <vemon> no i don't have that file (.install)
[18:36] <vemon> hmm... actually it seems the contents of debian/lash-wrap get installed when installing the built .deb
[18:36] <vemon> so maybe i have to change the rules file to set PREFIX to $(CURDIR)/debian/lash-wrap
[18:37] <vemon> the PREFIX parameter which is used in the Makefile
[18:40] <vemon> geser, now it seems to create a working package when i changed the install PREFIX. but should i still care for the .install file you mentioned?
[18:40] <vemon> don't want my package to get rejected :)
[18:41] <geser> the reviewer will tell you, but right of my head it should be ok
[18:49] <cyberix> geser: Actually I was more worried about new packages going past my package in line.
[18:50] <cyberix> :-)
[18:51] <cyberix> But revu isn't a line of course. It is actually more of a
[18:51] <cyberix> well
[18:51] <cyberix> never mind
[18:58] <vemon> is it ok for a package name to contain an underscore (_) ?
[18:58] <vemon> since the binary built is named lash_wrap it would be consistent to have a package called lash_wrap
[18:59] <geser> vemon: no, as _ is the seperator between the components in the filename
[19:00] <vemon> geser, well that's what i thought :)
[19:01] <vemon> i'll use - instead
[19:02] <cyberix> vemon: how about lashwrap
[19:03] <cyberix> if you have to change it anyway
[19:09] <vemon> cyberix, maybe i'll do it like that then
[19:09] <vemon> is there a problem if the original source (.orig.tar.gz) unpacks to a different directory than <packagename>-<upstream version>?
[19:10] <vemon> in this case the package name is lashwrap but the original source unpacks to lash_wrap-0.8
[19:10] <ion_> No. dpkg-source ignores the name of the topmost directory when unpacking it.
[19:10] <vemon> ok. great! thanks :)
[19:10] <vemon> smart move from dpkg-source :D
[19:17] <blueyed> Where should I install icons so that they get used for the desktop file?
[19:17] <_MMA_> blueyed: /usr/share/pixmaps is a common place.
[19:23] <blueyed> _MMA_: thanks, it's probably just plasma which does not get it anew after I've moved it there.
[19:25] <_MMA_> np
[19:25] <blueyed> Which resolution should I chose (.png)? 16, 32, 48, 128 - no svg..
[19:27] <_MMA_> 128 is common but might look weird @48 if the detail is too high.
[19:33] <blueyed> Do I have to quote the whole "Creative Commons Attribution-ShareAlike 2.5 License Agreement" in debian/copyright?
[19:34] <geser> blueyed: yes, as it isn't included in /usr/share/common-licenses
[19:36] <blueyed> ok, but it's really long.. but that's life.. ;)
[19:38] <blueyed> for the copyright: do I have to cite the different copyright holders for all source files? e.g. main package is (c)foo, but ./src/util/io/NtpMessage.java is (c)bar - (both are gpl2+).. so I must list this special?
[19:38] <geser> yes
[19:39] <blueyed> well, this looks to get nasty then.. ;)
[19:50] <jonnymind> Hello all.
[19:51] <jonnymind> I am in search for advocates on http://revu.tauware.de/details.py?package=falconpl
[19:52] <jonnymind> is there anywhere else I should notify the upload and advocate request?
[19:57] <cbx33> where can I find the latest packging guide?
[20:05] <vemon> why do i get "dpkg-genchanges: not including original source code in upload" when running "debuild -S" and what does it actually mean?
[20:06] <vemon> what is it referring w/ "upload"?
[20:07] <geser> vemon: that only .dsc and the diff.gz is listed in the .changes file and uploaded
[20:07] <geser> when you actually upload it e.g. with dput
[20:08] <vemon> how can i include the original source? that's probably necessary when uploading to revu?
[20:09] <geser> debuild -S -sa
[20:11] <vemon> thanks!
[20:11] <blueyed> We need more licenses in /usr/share/common-licenses I'd say..
[20:24] <wallyweek> hello, could anyone please review sdlmame? thanks! :) http://revu.ubuntuwire.com/details.py?package=sdlmame
[20:34] <LaserJock> afternoon MOTU Land
[20:34] <bddebian> Heya LaserJock
[20:34] <geser> Hi LaserJock
[20:35] <LaserJock> wow, lots of REVUing done yesterday
[20:35] <LaserJock> hi bddebian, geser
[20:35] <LaserJock> phew, quite a lot left though :/
[20:37] <jonnymind> Including mine :_(
[20:37] <jonnymind> Switching on my main pc. Later.
[20:47] <LaserJock> jonnymind: but you didn't tell use which package was yours ;-)
[20:47] <jonnymind> :-) Sorry
[20:47] <jonnymind> falconpl on revu
[20:48]  * \sh is off
[20:49] <blueyed> JFI: please don't review tvbrowser yet. /me is still in the licensing jungle..
[20:50] <LaserJock> jonnymind: ahhh, right. the "famous" falconpl ;-)
[20:50] <LaserJock> jonnymind: how is it going in Debian?
[20:50] <jonnymind> Well, the package is the same.
[20:51] <jonnymind> Just, with the 0ubuntu stripped off.
[20:51] <LaserJock> jonnymind: yes, but the falcon namespace issue
[20:51] <jonnymind> The ones having taken a look at it said it was ok, but debianers seems less strict than motus in judgment.
[20:52] <LaserJock> it depends on the Debianers
[20:52] <jonnymind> I said once the falcon namespace was decided I would have renamed falcon to falconpl in debian; so I did.
[20:52] <jonnymind> I have the agreement of ppl involved that they won't upload falcon in debian till the file name clash is resolved, so I renamed the package.
[20:53] <LaserJock> hmm, I was hoping it would be resolved in Debian since we sync our packages from them
[20:54] <jonnymind> well, the issue raised here. Of all distros, I picked the only one having a guy with a project, still unpacked, but with the same name.
[20:55] <jonnymind> If I started from debian, this all would just have never happened.
[21:06] <pochu> LaserJock, jonnymind: ScottK ITP'd Seveas' falcon repo, and has renamed /usr/bin/falcon to /usr/bin/falcon-start to avoid the clash
[21:08] <jonnymind> yes, so it seems we have an agreement. My package is named falconpl, his binary is named /usr/bin/falcon-start (a -start thing cannot be possibly confused with something concerning a scripting language).
[21:10] <jonnymind> So, as things seems have been sorted out, I am searching for advocates...
[21:10] <LaserJock> cool
[21:13] <cbx33> hey hey LaserJock
[21:13] <cbx33> howz it going
[21:13] <LaserJock> woah! ghost from the past! ;-)
[21:14] <LaserJock> hi Pete
[21:16] <smarter> hi
[21:16] <smarter> could someone please review my package? ;) http://revu.ubuntuwire.com/details.py?package=extremetuxracer thanks!
[21:18] <blueyed> debian/copyright only applies to source, correct? So if there's a .jar/library in the source package itself, do I need to include copyright/license info in debian/copyright?
[21:19] <LaserJock> blueyed: debian/copyright needs to account for all files in the source package
[21:19] <jpatrick> blueyed: yes, all
[21:20] <smarter> I can't recover my password in revu :/ http://revu.ubuntuwire.com/lostpw.py?email=smarter@ubuntu.com is empty
[21:20] <geser> blueyed: and the jar should be rebuild so it's known that it builds and matches the source
[21:20] <blueyed> geser: rebuild? no, most of them are only shipped, without any source..
[21:21] <geser> blueyed: bad
[21:21] <blueyed> For quite a lot of the libraries it's (partial) missing. E.g. there's a poi_license.txt file, but no copyright around?! :/
[21:21] <blueyed> too bad, yes.
[21:21] <jpatrick> smarter: debian/copyright should say which version of GPL the package is licensed under
[21:22] <geser> blueyed: or do you plan to put it into multiverse (if the jars are redistibutable)
[21:22] <vemon> i now have a [needs-packaging] bug and have successfully created the source package, built it in pbuilder and it seems to work when installed. is the next step to upload it to REVU?
[21:22] <vemon> or should i attach the source package to the launchpad bug?
[21:22] <jpatrick> vemon: REVU
[21:23] <vemon> ok!
[21:24] <smarter> jpatrick: seems to be under gplv2, I just have to s/, or (at your option) any later version.//g ?
[21:25] <jpatrick> smarter: it just says: "is licensed under GPL" you must be specific, archive admins won't "seem to think" :)
[21:26] <jpatrick> smarter: "under the GPL version 2 of (at your option) any later version." :)
[21:26] <smarter> COPYING contains gplv2 so I assume that's the license
[21:27] <jpatrick> smarter: I mean the Debian packaging part
[21:28] <smarter> jpatrick: oh, ok
[21:29] <smarter> but /usr/share/common-licenses/GPL links is gplv2
[21:29] <blueyed> bleh.. there are files licended with "Common Public License Version 1.0", which is incompatible to GLP.. therefore I think I can stop packaging until this is resolved upstream, correct?
[21:29] <smarter> can I put my debian packaging under gplv2+ ?
[21:29] <jpatrick> smarter: yes
[21:30] <smarter> ok
[21:30] <jpatrick> smarter: package looks good apart from that
[21:30] <blueyed> smarter GPL links to v3 on Hardy.
[21:31] <smarter> jpatrick: thanks
[21:41] <amarillion> Hi there. My packages http://revu.tauware.de/details.py?package=alex4 and http://revu.tauware.de/details.py?package=speed-game are ready for review please!
[21:41] <amarillion> I've fixed the 64-bit hang bug in alex4
[21:43] <smarter> jpatrick: uploaded ;)
[21:43] <jpatrick> smarter: hmm, I promise to look at it tomorrow, it's too late right now
[21:44] <smarter> jpatrick: okay, I think I'm going to go to bed too ;)
[21:44] <jpatrick> smarter: bonsoir! :)
[21:45] <smarter> jpatrick: buenas tardes ;)
[21:45] <jpatrick> noches*
[21:46] <smarter> bonne nuit* :P
[21:47] <stgraber> Gute Nacht :)
[21:47] <stgraber> any other language ? :)
[21:47] <jpatrick> bona nit
[21:47] <Adri2000> good night? :)
[21:50] <jonnymind> oyasumi nasai?
[21:55] <rexbron> Hey everyone! Got one ack and looking to double up :) http://revu.tauware.de/details.py?package=ubuntustudio-controls
[21:55] <bddebian> persia: You up yet? :)
[22:16] <jscinoz> where is ubuntu's libjpeg62 stored?
[22:17] <geser> I've /usr/lib/libjpeg.so.62 in libjpeg62 (hardy)
[22:18] <jscinoz> alright cheers
[22:18] <persia> \sh, apachelogger: About self-advocation.  I only think this is useful when the packager (who is also a MOTU) is sure (as with something that has everything fixed).  It oughtn't be done for an early upload.
[22:18] <persia> cyberix: Last scheduled REVU day is 4th February.
[22:22] <rulus> I updated gtkvd yesterday (http://revu.ubuntuwire.com/details.py?package=gtkvd), please review, I'd really like to have it in the archive for Hardy.
[22:22] <jscinoz> how would i change this makefile http://pastebin.ubuntu-nl.org/52935/ to use ubuntu's libjpeg62 rather than compile its own?
[22:26] <james_w> jscinoz: first guess, delete lines 1715-1716
[22:27] <ryanakca> how would one merge a package into the other? Would that mean take two packages and combine them into one?
[22:28] <mok0_> jscinoz: It will take major surgery on the makefile
[22:28] <jscinoz> >_<
[22:28] <bddebian> persia: Hey, wtf man? :-)
[22:28] <james_w> jscinoz: and then you probably need to add -ljpeg62 to one of the LDFLAGS, but I don't know which actually needs it.
[22:28] <persia> bddebian: ?
[22:29] <mok0_> jscinoz: perhaps you can try to delete $(JPDIR)/*.c from line 1715
[22:29] <james_w> ryanakca: these are packages already in Ubuntu? They are built from the same source?
[22:29] <jscinoz> hmm
[22:29] <bddebian> persia: You are ignoring me :)
[22:30] <persia> Hi bddebian!
[22:30] <bddebian> persia: j/k.  Did you say you have wx2.6 patches for survex and trustedsql?
[22:31] <mok0_> jscinoz: This is one of the most spaghettish makefiles I have ever seen. Geeez
[22:32] <persia> bddebian: No.  I don't remember the trustedsql solution: I'll track it down.  I was working on some survex patches with upstream, but got distracted some months back.
[22:32] <ryanakca> james_w: yes and no
[22:32] <bddebian> persia: You're fired ;-P
[22:32] <ryanakca> james_w: *figured it out*
[22:32]  * persia demands appropriate notice and severance pay
[22:32] <bddebian> hehe
[22:33] <bddebian> persia: Somehow I've gotten tasked with tracking wx2.4 removal in Debian :-)
[22:33] <persia> bddebian: I thought you might :)
[22:34] <persia> bddebian: The solution for trustedqsl (*not* sql) is just to change the build-deps.  At least that's how I did it for gutsy.
[22:34] <jscinoz> mok0_ i didnt make the makefile, its from upstream >_<
[22:35] <mok0_> jscinoz: I figured
[22:35] <mok0_> jscinoz: otherwise you wouldn't be asking :-P
[22:35] <bddebian> persia: Ah nice, thx
[22:37] <persia> bddebian: for survex, upstream is picky.  They don't want any WX getting into the engine, but only for display.  The main issue is that the porter has to understand the API between the engine and the interface well enough to do the casts at the right points.  I'm not convinced upstream will stay with WX, but it's a lot of work to port to something else.
[22:37] <mok0_> ScottK: good you nailed that avscan! Congrats
[22:37] <persia> So survex-aven should depend on WX, but survex itself would only use the standard C libraries.
[22:40] <jonnymind> ppl, is someone planning to have a look on falconpl in this REVU day? -- otherwise I am going to log off and have some sleep...
[22:41] <jscinoz> mok0, simply removing all lines referencing libjpeg, and remove it from the source, it seems to still compile and run
[22:41] <jscinoz> >_<
[22:41] <persia> jonnymind: There's been lots of REVU activity today (more than for many past ones).  If your timezone calls for sleep, check the package status when you wake.
[22:41] <bddebian> persia: Oh joy
[22:42] <jonnymind> persia: thanks. I need a bit of sleep, just I wanted to help in case of troubles.
[22:42] <jscinoz> this is really strange >_<
[22:43] <persia> bddebian: Yep.  That's part of why I got bogged down.  freqtweak took me about a week, and I expected the same for survex until I was in contact with upstream about it.  There was also another interested party: I'll dig up some mail and forward it.
[22:43] <jscinoz> either libjpeg62 is optional for the game engine, or it's automatically finding the system provided one
[22:44] <bddebian> persia: You ROCK man
[22:44] <mok0_> jscinoz: What's in Makefile.local?
[22:45] <jscinoz> one sec.
[22:45]  * persia has been ignoring WX for eight months, and thinks that's a bit of time between downbeats to be called "rocking".
[22:45] <jscinoz> there isn't one?
[22:47] <RainCT> was there a users clean-up or something on REVU? (it says my email isn't in the database..)
[22:48] <jscinoz> jmemdos.c builds jmemdos.o right?
[22:49] <jscinoz> argh
[22:51] <RainCT> well, anyways, how can I get a new account? just upload some crap or is there a better way? :P
[22:51] <persia> RainCT: When did you previously create your account?
[22:52] <RainCT> persia: last summer :P
[22:52] <blueyed> RainCT: then you need to reupload something.. :)
[22:52] <persia> RainCT: Ah.  All the accounts were wiped in September or so.
[22:52] <RainCT> ah ok
[22:52] <persia> RainCT: Do you want an account to upload, or to comment?
[22:52] <RainCT> to comment
[22:52] <jscinoz> why is it so important that it uses the ubuntu included libjpeg instead of compiling its own?
[22:52] <persia> No need to upload something then.  @ubuntu address?
[22:53] <RainCT> yes :)
[22:53] <blueyed> jscinoz: for security/performance/space..
[22:53] <jscinoz> i have no idea how to rework this makefile to make it work >_<
[22:54] <blueyed> jscinoz: change the call to configure?
[22:55] <jscinoz> it doesnt have a configure >_<
[22:58] <LaserJock> jscinoz: pastinbin'ing the makefile or relevant files might help
[22:58] <jscinoz> already did, its at  http://pastebin.ubuntu-nl.org/52935/
[23:00] <mok0_> jscinoz: on line 44 and 1912 that makefile includes some others that may have important clues
[23:02] <jscinoz> there isnt a makefile.local to include and ill have a look at the other thing
[23:03] <azeem> jscinoz: you're supposed to write on on your own if you disagree with the upstream defaults, AFAICT
[23:03] <jscinoz> >_<
[23:04] <azeem> one*
[23:04] <jscinoz> ahh crap
[23:04] <jscinoz> that was the wrong makefile, thats the server one >_<
[23:06] <jscinoz> ill pastebin the correcto ne in a sec, firefox decided to segfault again
[23:12] <jscinoz> alright heres the makefile http://pastebin.ubuntu-nl.org/52941/
[23:19] <jscinoz> :(
[23:19] <RainCT> good night
[23:20] <jonnymind> Good night, people.
[23:22] <blueyed> jscinoz: can't you use Makefile.local? Tried setting JPDIR or something else to use the shared library? Otherwise just removing the included one before building might help (at first)
[23:22] <jscinoz> where is the shared library located
[23:22] <azeem> jscinoz: just autotoolize the thing
[23:22] <jscinoz> i see that it later references numerous .o files related to libjpeg and i'd assume these are source?
[23:23] <jscinoz> autotoolize?
[23:23] <mok0_> autoscan
[23:24] <azeem> jscinoz: well, I wasn't serious.  Autotoolizing is the verb for porting a build system to autoconf/automake/libtool
[23:24] <jscinoz> oh
[23:26] <jscinoz> are the libjpeg *.o files included somewhere in /lib?
[23:26] <jscinoz> or /usr/lib
[23:26] <mok0_> jscinoz: nope
[23:26] <jscinoz> thoguht so
[23:27] <jscinoz> because the only file i can find included are the libjpeg.o.62 etc
[23:27] <jscinoz> .so*
[23:27] <jscinoz> and the make file wants a whole bunch of *.o's
[23:27] <emgent> heya people
[23:28] <mok0_> jscinoz: you need the -dev package
[23:28] <jscinoz> ah.
[23:29] <mok0_> jscinoz: it has header files and devel libs
[23:29]  * jscinoz feels stupid.
[23:29] <jscinoz> strange...
[23:29] <jscinoz> i already have libjpeg-dev and libjpeg62-dev
[23:31] <ScottK> mok0_: Thanks.
[23:31] <mok0_> ScottK: good idea to replace that .c file
[23:32] <jscinoz> the commenter on revu said " static copy of system library: please change the upstream Makefile to link against Ubuntu’s libjpeg62 instead of using the static copy inside the sources" wouldnt using the headers from the -dev package be just as bad?
[23:32] <mok0_> jscinoz: the headers are just used when the source is compiled
[23:33] <ScottK> mok0_: Looking at it, it didn't seem to do anything but talk to clamav, so as long as I added the appropriate #ifdef, it seamed likely to work.
[23:33] <jscinoz> in the libjpeg source included with the upstream package, it has a number of headers that dont seem to be included in libjpeg62-dev...
[23:33] <jscinoz> is this going to be a problem?
[23:33] <mok0_> ScottK: ha!
[23:34] <geser> jscinoz: this could be internal headers which programs using that lib shouldn't use
[23:35] <mok0_> jscinoz: not necessarily. Those headers may not be part of the exposed interface of the library
[23:35] <jscinoz> hmm alright gonna try build again here goes :)
[23:36] <jscinoz> argh
[23:36] <LaserJock> ScottK: evening
[23:36] <jscinoz> this isnt gonna work
[23:37] <jscinoz> if you look at the makefile i pasted, when it changes to JPDIR it just builds every thing it finds, so if i gave it /usr/include where libjpeg62-dev puts its headers it wouldnt work >_<
[23:37] <ScottK> Good evening LaserJock
[23:38] <blueyed> Is the "Creative Commons Attribution-ShareAlike 2.5 License" (CC-BY-SA) compatible to GPL? Or doesn't it matter because icons are not code/documentation (for distribution)? It's about tango and shipping it with a java package which is mostly GPL.
[23:38] <mok0_> jscinoz: that's right.
[23:39] <mok0_> jscinoz: there is no indication in that makefile where libjpeg is being linked into the source
[23:41] <LaserJock> blueyed: hmm, I'm not really sure. I think there may have been packages rejected for that but it could have been just that they didn't properly include the CC-By-SA part
[23:41] <LaserJock> blueyed: I don't think the GPL and CC-By-SA are compatible
[23:42] <blueyed> LaserJock: that's difficult, yes. http://www.gnu.org/licenses/license-list.html says so for 2.0 (but it's 2.5 and 3.0 is current). Also it only says to not use if for code/doc.
[23:44] <blueyed> There's another icompatibility (CPL 1.0) anyway (with code) and we might get away by depending on the tango-package and only ship new/additional or changed icons. "changed" may become difficult again though..
[23:46] <LaserJock> blueyed: you might do some searching of ubuntu-motu and ubuntu-devel{-discuss}
[23:47] <LaserJock> blueyed: or maybe ask an archive admin
[23:58] <jscinoz> mok0_ what should i do, im completly lost now >_<
[23:59] <jscinoz> hmm, what is a .o file?
[23:59] <jscinoz> is it source, or a compiled thing
[23:59] <mok0_> jscinoz: Hmm, what you are trying to accomplish is not easy. Your skills are perhaps not quite up to the task I am afraid