=== tuantub_ is now known as tuantub
=== asac_ is now known as asac
[01:23] <robinp1> Can someone help me with an issue with dh_installdirs: basically i want to create dirs to install into but it doesn't seem to work: http://ubuntu.pastebin.com/m427d0b8a
[01:24] <ebroder> robinp1: I don't think that's the variable name. It's probably more like DEB_DH_INSTALL_DIRS_ARGS or something
[01:24] <ebroder> Alternatively, just create a debian/$package.dirs file with one directory per line and kill the DEB_INSTALL_DIRS_ALL line
[01:24] <ebroder> Oh, never mind - if that's the output than that must be the correct argument
[01:25] <ebroder> I'd still use the .dirs file, though
[01:25] <robinp1> ebroder: ok, ill give it a go but I have a feeling I tried that already without any luck ...
[01:27] <robinp1> I already have a file called mdnsresponder-daemon.dirs with two lines usr/sbin and
[01:27] <robinp1> debian/tmp/usr/sbin in it!
[01:28] <robinp1> http://ubuntu.pastebin.com/m3c073002 <- thats my control file
[03:46] <robinp1> is it possible to override rule fragments in upstream Makefiles with cdbs ?
[04:51] <xnox> vorian: thanks a lot for the upload =D!!!!
[04:51] <xnox> my first ever direct upload to ubuntu
[04:51] <vorian> who are you!
[04:51] <vorian> :P
[04:52] <xnox> bug #386138
[04:52] <ubottu> Launchpad bug 386138 in gmsh "FTBFS: Gcc4.4 missing includes classic fail" [Undecided,Fix released] https://launchpad.net/bugs/386138
[04:52] <vorian> ah
[04:52] <vorian> yeah!
[04:52] <xnox> cheers anyway =D
[04:52] <vorian> no, great fix
[04:52] <vorian> my flippin pbuilder hooks are all messed up somehow
[04:52] <xnox> I will forward this to Debian ;-)
[04:53] <vorian> great! thanks very much
[04:53] <vorian> please link your upstream bug to the LP bug
[04:53] <xnox> in the past I had trouble with hooks and sometimes the faster dependency resolution via gdebi also results in FTBFS.
[04:53] <xnox> Ok I'll link it.
[04:54] <vorian> thank you :)
[05:05] <xnox> vorian: i've filed bug report in lp on the 6th, but debian maintainers commited a fix to their svn on the 8th =``((( Should have cross-submit to them straight away
[05:10] <vorian> xnox: it's unreleased at this point.  keep an eye on it, once it's released by debian, request a sync
[05:10] <xnox> vorian: fair enough. I've subscribed to bug-mail. I'll go try to find something else to work on.
[05:11] <vorian> awesome
=== nafunu is now known as nafunu-afk
=== nafunu-afk is now known as nafunu
[07:23] <Technoviking> What is the best way to setup postfix on a laptop, if I have to install it for pbuilder?
[07:24] <Hobbsee> errrr, i'd first look at why you have to install it for pbuilder, and figure out if ssmtp / msmtp will suffice.
[07:26] <Technoviking> Hobbsee: pbuilder wants it not me:) seems like an odd dependecy
[07:26] <Hobbsee> Technoviking: what are you building?
[07:27] <Hobbsee> and, er, why do you need to set it up at all, for pbuilder?
[07:27] <lifeless> fakemail or something
[07:27] <Hobbsee> lifeless: that's what i was thinking
[07:27] <lifeless> Hobbsee: I think its devscripts not pbuidler
[07:27] <lifeless> offhand
[07:27] <Technoviking> sudo apt-get install pbuilder told me postfix was an required package
[07:28] <lifeless> yes, I understand that
[07:28] <Hobbsee> oh, i see
[07:28] <lifeless> but its not pbuilder
[07:28] <lifeless> its something pbuilder depends on
[07:28] <Hobbsee> yeah, it'll be devscripts
[07:29] <lifeless> Technoviking: are you sure it said required and not recommended?
[07:29] <Technoviking> was required
[07:29] <jmarsden> Maybe try    sudo apt-get install pbuilder --no-install-recommends
[07:29] <Technoviking> installed automatically, but I was able to remove it after the fact.
[07:31] <lifeless> then it was a recommends
[07:32] <Technoviking> lifeless: ok sorry
[07:49] <Technoviking> when a patch is not longer needed for a package (fixed upstream), how do I remove the patch with the debian dir properly
[07:50] <RAOF> Technoviking: Depends on the patch system.
[07:51] <RAOF> With simple-patch-sys, you just delete the patch from debian/patches.
[07:51] <RAOF> With quilt or dpatch, you also need to remove the reference to the patch from debian/patches/series or debian/patches/00list, respectively.
[07:53] <Technoviking> RAOF: did that, do I need to run debuild again to generate a new .dsc file?
[07:53] <RAOF> Yes, you'll need to generate a new source package.
[07:53] <RAOF> debuild will do that.
[11:25] <robinp1> how can I get the installed JDK dir for a debian/rules Makefile ?
=== azeem_ is now known as azeem
[12:26] <geser> set/export JAVA_HOME. it's top of my head so better look how the existing java packages do it
[12:31] <dyfet> The java tools, javac, java, etc, are all symlinked through /etc/alternatives to the ones in the bin dir of the active jvm
[12:33] <dyfet> geser: That by itself does not tell you where to place built java binaries though...just how to run the tools...
[12:40] <dyfet> geser, robinp1: debian/ubuntu java policy currently suggests generic compiled jars are to be installed in /usr/share/java as per http://wiki.debian.org/Java/Draft and native jni libs in libdir/jni.
[12:42] <dstansby> Hi guys
=== ejat is now known as e-jat
[17:27] <dstansby> Hi guys :)
[17:27] <dstansby> Just wondering if anyone can help me with something
[17:27] <dstansby> I'm trying to build cheese, but I get this error message:
[17:27] <dstansby> debian/rules:6: /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk: No such file or directory
[17:27] <dstansby> make: *** No rule to make target `/usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk'.  Stop.
[17:27] <dstansby> dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2
[17:27] <dstansby> debuild: fatal error at line 1334:
[17:27] <dstansby> dpkg-buildpackage -rfakeroot -d -us -uc -S failed
[17:28] <nhandler> dstansby: Install gnome-pkg-tools
[17:29] <dstansby> nhandler: thanks for that, it worked :D
[17:29] <nhandler> Glad to hear that dstansby
[17:42] <Laney> Does Required-Start do anything in LSB headers? I'm trying to fix a problem with mediatomb where it launches from its init script before the network interfaces are up
[17:44] <Laney> it's currently set to $all, which from my understanding should be making it come up last
=== yofel_ is now known as yofel
[17:55] <james_w> Laney: it's currently still done based on the symlinks as far as I know
[17:55] <Laney> alright
[17:55]  * Laney moves to 99, maybe that will help
[18:08] <RainCT> Any plans to update hildon-thumbnail? (Karmic has 2.0, Debian has version 3)
[18:08] <RainCT> (and there's an even newer version in Maemo's repo)
[18:09] <RainCT> I can do the update myself but I'm not familiar with any hildon stuff so checking to be sure we want the new version :)
[19:34] <dupondje> https://bugs.launchpad.net/ubuntu/+source/audacious-plugins/+bug/383307
[19:34] <ubottu> Launchpad bug 383307 in audacious-plugins "Please merge audacious-plugins 2.0.1-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
[19:34] <dupondje> please somebody accept it, audacious 2.0.1 is already in Karmic, but can't be installed without the plugins :(
[19:37] <dyfet> the package depends on the plugins?  not just a recommends, a required?
[19:38] <dupondje> +Package: audacious
[19:38] <dupondje> +Architecture: any
[19:38] <dupondje> +Depends: ${shlibs:Depends},
[19:38] <dupondje> +         audacious-plugins (>= 1.9),
[19:42] <dyfet> dupondje: Reading the audacious site, at least some plugins are not supported by the same upstream...but can it do anything useful with any entirely free formats without plugins?  that is not clear from the site...
[19:45] <dupondje> how u mean ?
=== jldugger_ is now known as pwnguin
[19:46] <dyfet> dupondje: I mean, if it can be used, even without all codecs and features, without audacious-plugins installed, then I do not think it should be a required dependency, especially if the plugins contain restricted codecs.  But that is my impression.
[19:46] <dupondje> output is also a plugin
[19:47] <dupondje> so alsa etc is a plugin
[19:47] <dupondje> kinda needed ;)
[19:47] <dyfet> Okay :)...It was not clear from the site whether that was true :)
[19:47] <dupondje> should be accepted imo :)
[19:48] <dyfet> though in any case, if audacious has been merged from debian, then yes, I would expect the audacious-plugins to be merged also...
=== lukjad007 is now known as PYTHON_MAN
=== PYTHON_MAN is now known as group
=== group is now known as PYTHON_MAN
=== PYTHON_MAN is now known as lukjad007
[20:16] <ryanakca> I have a package in Debian NEW. If it doesn't get processed in Debian by DebianImportFreeze, will it still be possible to get it sync'd into Ubuntu, assuming it isn't too far past the import freeze?
[20:17] <sebner> ryanakca: without problems
[20:17] <ryanakca> sebner: Great, thanks :)
[20:17] <sebner> unless it breaks something :P
[20:18] <ryanakca> sebner: Haha, only thing that depends on it is Kobby, which I'm hoping to get uploaded to NEW sometime this week :)
[20:19] <sebner> kk
[20:33] <geser> ryanakca: at DIF only the automatic import stops, between DIF and FF you need to file a sync request to get a package synced
[20:34] <ryanakca> geser: *nod*, that isn't a problem :)
=== emgent_ is now known as emgent
=== RainCT_ is now known as RainCT
[21:57] <porthose> sebner: would you mind if I did the lat merge/sync?
[21:58] <directhex> porthose, if it needs merging, can you see if there's a good reason for it (i.e. can we update it in debian then sync?)
[22:00] <porthose> directhex: ok let me look at it closer, from just glancing at it, it looks like a sync anyway
[22:00] <directhex> yay for syncs
=== RainCT_ is now known as RainCT
[22:21] <porthose> directhex: in lat upstream Depends on mono-devel (>=2.0.1), and mono-devel-2.0.1 is waiting on MoM to be merged/synced sooo I think I will wait on doing lat until mono-devel is done that way we should be able to just sync lat  ;-)
[22:22] <directhex> porthose, mono will be synced as soon as requestsync believes that 2.4+dfsg-4 is current
=== lifeless is now known as all
=== all is now known as lifeless