[00:04] <crimsun> oh jeez, 46 different VIA codecs
[00:04] <crimsun> well, that'll keep me occupied while I wait for VTK to build
[01:28] <crimsun> 30% through the build!
[01:33] <geser> in 90min? that's about 3h for the remaining 70% :(
[01:34] <crimsun> geser: yep. And, there's clearly something wrong with this CMake progress
[01:34] <sebner> geser: crimsun hhiuhu
[01:34] <crimsun> it has been at 100% for five minutes on another box building Java bindings :-)
[01:34] <geser> Hi sebner , still awake?
[01:35] <sebner> geser: yeah I'm at a friends house and feeling like doing packaging work ^^
[01:39] <geser> sebner: training a future MOTU? :)
[01:40] <sebner> geser: nah, haXX0ring packages for Debian xD
[01:40] <sebner> geser: working through maaaaany files for creating an acceptable copyright :\
[01:43] <crimsun> man, I've cycled twice through the PID space just for docs generation
[01:44] <crimsun> I think I'm going to escape back to the simpler world of kernel hacking
[02:58] <bjsnider> there's no formatting requirement in a debian/rules file that would require 7 consecutive tabs on a line is there?
[02:59] <RAOF> bjsnider: No.
[02:59] <bjsnider> i swear i found it like this
[03:39] <machina> I was working on packaging a new upstream version of xsensors for ubuntu, but chose instead to try and get the new upstream in debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446530
[03:39] <ubottu> Debian bug 446530 in xsensors "xsensors: New upstream version (0.60) available" [Wishlist,Open]
[03:39] <machina> unfortunately the debian maintainer is not very responsive
[03:39] <machina> Should I wait a couple weeks, or should I go and try and get a new version in ubuntu?
[03:40] <bjsnider> what do you need him for?
[03:40] <machina> I was told on IRC that having a newer version than debian would cause sync problems..
[03:42] <bjsnider> oh, i see.  you want to push the latst upstream code into debian. i thought you meant you wanted to pull the latest in debian into ubuntu
[03:44] <machina> yeah, I also made the "debian directory" needed for the new version, but met a few stumbling blocks before I could finalize the debian/ubuntu package..
[03:45] <bjsnider> like dependencies and such
[03:46] <machina> I used most of the dependencies from previous versions, but I did notice another bug report about that.. my problem was mostly about the debian/copyright file (it's at the bottom of the bug report)
[03:47] <ScottK> Particularly for Lucid/Squeeze where we are synchronizing release freeze it'd be good to keep the same version in Ubuntu and Debian.
[03:48] <machina> Is that the cadence thing shuttleworth was talking about earlier? I couldn't find any updates on it.
[03:49] <machina> So would that mean it's best just to patch the older version of xsensors?
=== Whoopie_ is now known as Whoopie
=== binitamshah is now known as binitamshah|away
[04:11] <machina> I guess I'll just push the new upstream to ubuntu
[04:36] <ScottK> machina: It may be better to do that, but your efforts to get Debian updated are good too.
[04:38] <machina> cool, thanks for the advice
[04:59] <w3asal> what exactly happens to the sync when there's a newer version in ubuntu than debian?
=== binitamshah|away is now known as binitamshah
[05:35] <ScottK> w3asal: Nothing until Debian gets a newer version.
[05:36] <w3asal> so it's just good policy to try to push the new version into debian, but not necessarily bad for ubuntu if it doesn't happen?
=== asac_ is now known as asac
[07:18] <crimsun> sorry, unimplemented: inlining failed in call to '(!#$*': redefined extern inline functions are not considered for inlining
[07:18] <crimsun> sigh, there goes that pile. Thanks, gcc-4.4 (and gcc-snapshot).
[07:21] <foxbuntu> bjsnider, ping
[07:22] <foxbuntu> bjsnider, thought I would let you know there is a bug in the nvidia packages in the in vdpau testing ppa
[07:23] <foxbuntu> bjsnider, they are pointing to a depends on libvdpau, but the package name is really libvdpau1
[07:24] <crimsun> foxbuntu: that isn't a bug.
[07:24] <crimsun> $ apt-cache show libvdpau1|grep ^Pro
[07:24] <crimsun> Provides: libvdpau
[07:25] <foxbuntu> crimsun, The following packages have unmet dependencies:
[07:25] <foxbuntu>   nvidia-glx-190: Depends: libvdpau
[07:25] <foxbuntu> E: Broken packages
[07:27] <crimsun> foxbuntu: and?
[07:27] <crimsun> as long as you have libvdpau1 installed, your package manager shouldn't whine
[07:28] <foxbuntu> crimsun, yes, but if you dont, it wont install the drivers
[07:28] <foxbuntu> crimsun, so it is a bug
[07:29] <foxbuntu> crimsun, the proper depends is libvdpau1 or better would be not at all, as libvdpau1 is not a required piece to the nvidia drivers
[07:30] <crimsun> foxbuntu: I agree that it should be a Recommends, not a Depends
[07:30] <crimsun> foxbuntu: however, I disagree that it is a bug
[07:30] <foxbuntu> crimsun, how could it not be?
[07:30] <foxbuntu> crimsun, I am not motu, but I am trying to understand
[07:30] <crimsun> I just tried, and apt-get and aptitude both worked correctly
[07:31] <foxbuntu> crimsun, from that ppa?
[07:31] <crimsun> yes
[07:31] <foxbuntu> crimsun, without libvdpau1 already installed?
[07:31] <crimsun> now, if you manually used dpkg -i but did *not* include libvdpau1...deb, that still isn't a bug. That's your own fault.
[07:31] <crimsun> foxbuntu: yes, from within a schroot.
[07:32] <foxbuntu> crimsun, I was able to do the same once, but after attempting to upgrade to another build of libvdpau and that package it failed on the upgrade
[07:33] <crimsun> well, certainly it could be made better with libvdpau1 | libvdpau
[07:34] <foxbuntu> crimsun, agreed on that point
[07:43] <happyaron> sorry if it's not suitable to ask here, does CC by-sa 2.5 compatible with LGPLv3?
[08:03] <superm1> foxbuntu, crimsun no libvdpau shouldnt be a depends or recommends
[08:03] <superm1> that's the bug
[08:03] <superm1> it does nothing for the nvidia driver itself
[08:03] <superm1> it's the applications that should be depending on libvdpau1 (by build-depending on libvdpau-dev and shlibs resolving libvdpau1)
[08:40] <yuanyelele> Hi! Why don't we have a free version of mplayer, with patented codecs in a separate package?
[11:10] <martoss> hey folks, i have two packages to review. I uploaded them to revu but they don't show up in revu.
[11:16] <surfzoid> directhex: Hi, in the mono rule file you use autoreconf -i -f -s, the symlinks switch is really important, or it will be same to use libtool file of mono source rather link them to the system one ?
[12:58] <cornucopic> yesterday, I used 'debuild -sa -S' to build my signed source package. What is the 'a' switch for?
[13:03] <geser> -sa    Forces the inclusion of the original source.
[13:03] <geser> i.e. the .orig.tar.gz
[13:04] <cornucopic> and -S is for signing?
[13:04] <cornucopic> or -S for source package and signing is the default behavior?
[13:04] <geser> -S     Specifies  that  only  the  source should be uploaded
[13:05] <geser> signing is the default behaviour
[13:05] <cornucopic> thanks geser!
[13:05] <geser> -us    Do not sign the source package.
[13:05] <geser> -uc    Do not sign the .changes file.
[13:30] <bdrung_> porthose: do you have some sponsor examples?
[13:55] <porthose> bdrung_, I just sent you a mail listing all the bugs you have sponsored for me, there is also a list of bugs that I have worked on at https://wiki.ubuntu.com/CharlieSmotherman :)
[14:13] <bjsnider> foxbuntu, i removed libvdpau from the depends list
[15:04] <bdrung_> porthose: thanks.
[15:05] <bdrung_> porthose: you are doing so many syncs, why not syncing ampache? 3.0 (quilt) is now supported in ubuntu.
=== thekorn_ is now known as thekorn
=== azeem_ is now known as azeem
=== zooko` is now known as zookol
=== yofel_ is now known as yofel
[19:30] <vadi21> I'm trying to create a package for a lua module, but having a hard time understanding lua5.1-policy-dev/Makefile.Debian.conf. Anyone know a good page that explains what values are supposed to be where?
[20:21] <crimsun> some of these upstream "fixes" for gcc-4.4's more stringent CXX compliance are downright nasty
[20:21] <crimsun> like, casting away a const char *? what the blazes?
[21:26] <jreinhardt> Hi everybody. A year ago I packaged a tex package (#310015) and tried to get it through revu, but then lost the patience. Today a new upstream version was released and I updated my package. Is someone interested in revuing it? http://revu.ubuntuwire.com/p/pgfplots
[21:31] <TomJaeger> Hi. I'm trying to convert a package to debhelper 7, and I can't figure out how I'm supposed to call dh_installman, dh_installchangelogs and dh_installdocs and I can't really find any documentation besides http://kitenet.net/~joey/blog/entry/cdbs_killer___40__design_phase__41__/.
[21:31] <TomJaeger> What is the correct way to do this?
[21:33] <ScottK> TomJaeger: Why are you converting it?
[21:35] <TomJaeger> https://bugs.launchpad.net/bugs/502366
[21:36] <ubottu> Ubuntu bug 502366 in easystroke "Please upgrade easystroke to 0.5.2" [Undecided,Incomplete]
[21:38] <ScottK> TomJaeger: OK, but why redo the packaging?
[21:38] <TomJaeger> Benjamin suggested to switch to debhelper v7.
[21:39] <ScottK> OK, my view is generally to not make unneeded changes, but if there's a specific problem that switching to dh 7 solves, then go for it.
[21:40] <TomJaeger> I don't really care either way, so I'm fine with keeping things the way they are.
[21:57] <foxbuntu> bjsnider, thanks.
=== bdefreese2 is now known as bddebian
[22:52] <dhillon-v10> hi all, I am packaging this ppa for this software that has a makefile, all the user needs to do is to run the makefile and everything is done, I got everything else but including autotools.mk class gives me an error that a configure file doesn't exist and this is the way its supposed to be
[22:57] <ScottK> PPA packaging isn't on topic for #ubuntu-motu
[22:58] <jmarsden> dhillon-v10: If there is a working makefile already, why use autotools.mk ?   Seems odd, if the upstream software does not use autotools, don't package with autotools.mk :)
[22:59] <dhillon-v10> ScottK, which channel should I got to ?
[23:00] <ScottK> dhillon-v10: I'd say #launchpad, but they'd say here.  There probably isn't one.
[23:00] <dhillon-v10> jmarsden, so how do I get the debian/rules file to call the makefile
[23:00] <dhillon-v10> ScottK, :)
[23:00] <jmarsden> dhillon-v10: Just run make :)
[23:01] <dhillon-v10> jmarsden, so wait just type in make in debian/rules ? that's it
[23:01] <jmarsden> Yes.
[23:01] <dhillon-v10> jmarsden, thanks a bunch :D
[23:01] <jmarsden> Sounds like you need to go through the Package Guide and understand packaging some more...
[23:02] <dhillon-v10> jmarsden, you are awesome it works  I read the package guide before, but I will read it again :)
[23:02] <jmarsden> You're welcome.
[23:03] <dhillon-v10> jmarsden, every time I encounter something new I document it, so that way I don't forget, this was something I had never seen before so...