[00:53] <rmunn> Aspiring MOTU / new packager here with a question about licensing: I'm trying to package the NLTK library for Python (http://www.nltk.org/), and the upstream tarball has a minor licensing issue. It's licensed Apache-2.0, and the upstream tarball also distributes a yaml library that I identifyed as pyyaml (http://pyyaml.org/). Pyyaml is MIT-licensed, but the NLTK tarball doesn't include a copy of the MIT license, nor any attrib
[00:53] <rmunn> ution for pyyaml. I plan to create an NLTK package that doesn't install pyyaml (and instead simply Depends: on python-yaml), but what's the best way to remove the yaml/ directory from the upstream tarball? Modify the tarball and create a dfsg.tar.gz, or remove it in the .diff.gz?
[00:55] <rmunn> If I modify the upstream tarball, it makes it harder for people to verify that I made no changes to upstream -- but if I don't, then under one reading of the MIT license (which says "you must include this license will any redistributions"), redistributing the upstream's tarball would not be legal.
[00:55] <ajmitch> removing it, creating a new upstream version with +dfsg in the name, note what you did in debian/README.source
[00:55] <rmunn> Best solution is, of course, to get upstream to fix it and release a new tarball with the PyYaml code's license properly included -- but that might not happen before the Lucid freeze.
[01:56] <dhillon-v10> hi all, I just finished doing a merge, and here's the diff: http://pastebin.com/d7ccd7ad0 I do know I am supposed to remove the .po stuff and the patch applies cleanly too :) so can any one just have another look at it
[02:56] <Burzmali> Hello everyone.  Anyone available to give me some advice about how to set up a group of packages?
[03:13] <rhpot1991> persia: I'm told you are a good person to ping about a library soname question
[03:14]  * vorian has heard he's a good person to ping about a lot of things
[03:15] <RAOF> Even better is to ping the whole channel!
[03:15] <RAOF> And by ping the whole channel, I mean: ask your question.
[03:15] <RAOF> Because persia, awesome as he is, sadly isn't active in here 24/7 :)
[03:17] <vorian> but please, do not /ping #ubuntu-motu :P
[03:19] <rhpot1991> well I'm working with some upstream code and they do not have any soname data associated with their library
[03:19] <rhpot1991> I am trying to work with them to fix the issue, they aren't really sure how to handle the numbering procedure as their version numbers are nothing more than a date (yyyymmdd)
[03:20] <RAOF> Do they expect other people to be able to use their library?
[03:20] <rhpot1991> so for soname data should it be, 0.yyyymmdd, yyyy.mm.dd, or just yyyymmdd?
[03:20] <RAOF> Neither.
[03:20] <rhpot1991> RAOF: its pretty much specific to their source
[03:21] <rhpot1991> RAOF: not sure if code example would help at all here
[03:21] <RAOF> Then you don't need to care about the soname; if other people shouldn't link against it, don't put it into the public link space.
[03:21] <rhpot1991> RAOF: then its safe to ignore the lintian warnings about soname data?
[03:22] <RAOF> As long as the library isn't installed into /usr/lib (or other public library path)
[03:22] <rhpot1991> RAOF: that is where it gets installed to
[03:22] <rhpot1991>  /usr/lib/libhdhomerun specifically
[03:23] <RAOF> If the library is private to this application it shouldn't go there.
[03:27] <rhpot1991> RAOF: ok well lets see here, I have 2 packages from the same upstream
[03:27] <rhpot1991> http://www.silicondust.com/downloads/linux
[03:27] <rhpot1991> so there is a lib source and a gui source
[03:27] <rhpot1991> pastebining my controls
[03:28] <rhpot1991> http://mythbuntu.pastebin.com/d2010eaf8
[03:29] <RAOF> Hm.
[03:30] <RAOF> Well, http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html might be helpful for you.
[03:33] <rhpot1991> RAOF: reading now, thanks
[03:34] <RAOF> As long as upstream make an effort to not break ABI, it looks like you want to make that a regular library package.
[03:35] <rhpot1991> RAOF: what do you mean by regular library package?
[03:36] <RAOF> I mean, packaged as per that library packaging guide.
[03:37] <rhpot1991> RAOF: my view coming in was that my work as a packager was done and I just needed upstream to get some soname data into the library
[03:37] <rhpot1991> trying to understand what that entails so I can help them with that
[03:39] <RAOF> What that entails is ensuring that they keep the ABI as stable as possible.
[03:39] <RAOF> The libpkg-guide has a nice description of that.
[03:40] <rhpot1991> RAOF: ok reading on then
[03:40] <RAOF> Particularly: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi
[03:41] <rhpot1991> RAOF: so is it normally to start at 0 and them bump from there?
[03:41] <RAOF> Yes.
[03:57] <rhpot1991> RAOF: so then the package name should always match the soname, example libhdhomerun1 when the soname is 1
[03:58] <RAOF> rhpot1991: Correct.
[03:58] <rhpot1991> RAOF: I'm pretty sure this library falls into this situation: "Refer to libssl and other packages which used to handle it. They basically had SONAME version numbers which matched the package version, and every version: e.g. 0.9.4 and 0.9.6 had incompatibility. The solution was to create a SONAME containing 0.9.6, so that : "
[03:58] <rhpot1991> they release a new library with every release
[03:59] <RAOF> Yeah, but does that new library break existing users.
[03:59] <RAOF> We've had a *lot* of libc releases since the SONAME bump to 6, including switching to a different source tree.
[04:00] <RAOF> The SONAME hasn't been bumped, because they've been binary compatible.
[04:27] <rhpot1991> RAOF: so where does a private library get installed to?
[04:27] <rhpot1991> via dpkg of course
[04:48] <RAOF> rhpot1991: Generally into a subdirectory of /usr/lib.
[04:49] <rhpot1991> RAOF: thanks, you wouldn't happen to have any documentation about how a library gets soname data in the first place would you?
[04:49] <rhpot1991> google isn't helping me find what I'm looking for
[04:50] <RAOF> rhpot1991: I'm fairly sure that's in the libpkg-guide I linked you.  The answer is generally “from libtool”
[04:51] <rhpot1991> RAOF: thanks, I need to learn to read better :)
[04:53] <RAOF> rhpot1991: It's a big guide; library packging is much more complex than application packaging because it affects packages outside of itself.
[04:54] <rhpot1991> RAOF: yes, it is quite complex
[05:09] <superm1> anyone have any good documentation they can link me to on v3 source format?
[05:09] <superm1> my google-foo is apparently failing
[05:18] <jmarsden> superm1: man dpkg-source
[05:18] <jmarsden> In Debian sid...
[05:18] <Hobbsee> superm1: i think you want http://wiki.debian.org/Projects/DebSrc3.0
[05:19] <superm1> yes Hobbsee that's what i'm looking for.  jmarsden the man page didn't talk much about converting packages to v3, just about some nice things in it from what i saw
[05:19] <superm1> thanks Hobbsee
[05:19] <Hobbsee> you're welcome
[05:20] <jmarsden> superm1: It defines what the format is, which is what I thought you were looking for... the web page dances around what v3 format really *is*, IMO.
[05:51] <hyperair> what are those little flame icons at the top right of a bug report?
[05:51] <hyperair> Bug #XXXXXX reported by ____  on yyyy-mm-dd, <flame icons>
[05:52] <ajmitch> bug heat
[06:05] <micahg> What do I have to check when bumping the standards version on a package?
[06:27] <jmarsden> micahg: That it really does meet the newer standards version.  See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz
[06:28] <micahg> thanks jmarsden, I didn't know that existed :)
[06:29] <jmarsden> You're welcome.
[07:26] <dholbach> good morning
[07:39] <shadeslayer_> dholbach: morning
[07:40] <dholbach> hi shadeslayer_
[07:56] <iulian> Good morning dholbach!
[07:57] <dholbach> heya iulian!
[08:00] <xaka> anybody knows where i can find the history for the latest training Python Applications Packaging? (it was yeasterday)
[08:02] <shadeslayer_> !logs | xaka
[08:04] <xaka> shadeslayer_: great! big thx!
[11:09] <xteejx> Morning all!
[11:14] <geser> xteejx: Hi, the answer to your last question yesterday: debian/package.dirs (man dh_installdirs)
[11:14] <xteejx> geser: I havent' looked at the packaging stuff today, will do in a bit, but can't remember what the question was now
[11:15] <geser> xteejx | Can I tell the Makefile to mkdir $CURRENT/debian/xorcurses/usr/bin/games ?
[11:15] <xteejx> so create a file with those directories listed name it debian/package.dirs ? That's cool
[11:16] <geser> yes, just put "usr/bin/games" into debian/xorcurses.dirs and dh_installdirs will create it for you
[11:16] <xteejx> Cool :)
[11:16] <xteejx> Thanks
[11:19] <randomaction> it's probably a bad idea as /usr/bin should have no subdirs, games should be installed to /usr/games
[11:20] <geser> right
[11:21]  * geser blames it on the auto correction in his brain
[11:34] <xteejx> It's ok I know game executables go in /usr/games/bin :)
[11:34] <xteejx> I wrote it all down
[12:32] <xteejx> What is the correct way to create a package.dirs file so that dh_installdirs can create the needed directories?
[12:39] <hakaishi> Hi everyone! Anyone up to review qt-shutdown-p? I think everything is fixed; no lintian waringins or other warnings. http://revu.ubuntuwire.com/p/qt-shutdown-p
[12:40] <hakaishi> * no lintian warnings or errors.
[12:54] <jcfp> hakaishi: why install the standard gpl text via debian/docs?
[13:08] <freeflying> http://revu.ubuntuwire.com/p/ailurus
[13:26] <shadeslayer> hmm. any ideas why this failed : http://launchpadlibrarian.net/38489013/buildlog_ubuntu-lucid-i386.kopete-facebook_0.1.5-0ubuntu1%2Blucid1~ppa3_FAILEDTOBUILD.txt.gz
[13:28] <Laney> jcfp: what's up with sab? :'( :'(
[13:29] <jcfp> Laney: on lucid you mean?
[13:29] <Laney> yeah
[13:29] <Laney> aptitude wants to rip it out
[13:30] <jcfp> 1) python-cheetah is broken
[13:30] <jcfp> 2) someone broke the sab package a few days ago
[13:30] <directhex> bloody python
[13:30] <shadeslayer> hehe...
[13:30]  * shadeslayer hates it when he gets a FTBFS
[13:31] <jcfp> bug #511547 and bug #512079
[13:31]  * Laney spanks porthose
[13:32] <jcfp> on the positive side, 0.5.0 is almost out and via my ppa things do work, of course :)
[13:32] <Laney> so you have fixes?
[13:33] <jcfp> nope, a newer version that works with python2.6 so it isn't hit by the cheetah bug
[13:33] <jcfp> but that's still rc status for now
[13:34] <jcfp> Laney: and that in turn needs a newer python-cherrypy3 before it could go into an official repo
[13:37] <Laney> all good fun
[13:43] <shadeslayer> um anyone aware of the fact that libqt4-dev no longer depends on pkg-config and needs to be added as a build dep?
[13:50] <jcfp> Laney: not really, work is claiming enough of my time to make cleaning up someone else's mess a very unwelcome addition to my schedule
[14:53] <dupondje> https://bugs.launchpad.net/ubuntu/+source/gnome-do/+bug/513802 => would be cool if sponsored :)
[14:56] <bddebian> Heya gang
[14:56] <directhex> bddebian! your nation needs you!
[14:57] <bddebian> To stop Obama? :)
[14:58] <directhex> bddebian, to help get a transition done, by prioritizing gsf-sharp which is in NEW
[14:58] <directhex> so we can sync it. for great justice
[15:11] <bddebian> directhex: I'll see what I can do. :)
[15:11]  * Laney feeds bddebian cookies
[15:11] <directhex> thanks :)
[15:26] <rmunn> Question about redistribution requirements from a new packager / aspiring MOTU: I have an upstream package (from http://www.nltk.org/) I'm trying to Ubuntuize. It contains MIT-licensed code (from http://pyyaml.org/) but no copy of the MIT license (which is a violation of the MIT license terms that require a copy of the license to be redistributed along with the code).
[15:26] <rmunn> Does this mean the .orig.tar.gz would not be legal to redistribute, and therefore I'd have to modify the original tarball?
[15:27] <rmunn> Or could I put a copy of the MIT license into the .diff.gz and be in compliance that way?
[15:27] <rmunn> I've notified upstream of the license compliance problems and expect they will fix it, but I don't know if their fix will come in time for the Lucid freeze or not, so I might have to package the current version and solve the licensing issue myself.
[15:45] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 4 starting in 15 minutes in #ubuntu-classroom (first: Adopt-An-Upstream)
[16:48] <abogani> Hi All, What is the right way to try to package a software when it isn't available a source package but only the SVN tree and this tree contains a lot of all types of unwanted stuff (binary stuff, driver for other OS, etc etc)?
[16:48] <abogani> RTFM is welcomed.
[16:49] <daurnimator> RTFM then?
[16:49] <daurnimator> :P
[16:49] <shadeslayer> abogani: you archive it,well git has git archive,dunno about svn
[16:49] <shadeslayer> abogani: apparently it doesnt
[16:49] <statik> abogani, do you have a good relationship with the upstream developers? are they open to making it easier for you or do you need to package it without any cooperation from them?
[16:50] <abogani> statik: Are cooperative.
[16:51] <statik> abogani: the smoothest thing is when you can convince upstream to start making some tarball releases that have good contents. if you can't do that, there are some other tools which can generate tarballs but it's a lot more work to manage
[16:51] <statik> one is bzr-builddeb
[16:51] <abogani> statik: Ok I'll try this way.
[16:52] <abogani> statik, shadeslayer: Thanks!
[16:55] <shadeslayer> isnt there *any* svn archiving tool?
[16:55] <shadeslayer> if not,then svn is truly outdated :)
[17:32] <_stink_> i'm playing around with packaging.  since i need to give pbuilder a .dsc file, it seems like i need to do debuild *first* always to generate the .dsc file, then do pbuilder.  is there a way to cut out the debuild step?
[17:33] <slytherin> _stink_: nope
[17:33] <_stink_> okee :)
[17:34] <slytherin> _stink_: debuild generates a source package. Then you ask pbuilder to build a binary package from that source package.
[17:35] <_stink_> gotcha.  and i guess the signing takes place in debuild, too.  i think.
[17:35] <_stink_> thanks.
[17:44] <slytherin> yes
[17:49] <cyphermox> slytherin, _stink_, i recall there is pdebuild. I just tried it and it created the source package (it seems) and tried to proceed to run pbuilder to build the binary but failed... it would be cool to make sure it does work properly throughout ;)
[17:50] <slytherin> cyphermox: never used pdebuild
[17:59] <hakaishi> Hi everyone! Anyone up to advocate/review qt-shutdown-p? - I corrected the desktop file, the copyright file and the docs file as jcfp asked. http://revu.ubuntuwire.com/p/qt-shutdown-p
[18:12] <dupondje> https://bugs.launchpad.net/ubuntu/+source/gnome-do/+bug/513802 => can somebody check to sponsor ?
[18:13] <slytherin> dupondje: why sid?
[18:13] <dupondje> slytherin: only sid contains 0.8.3.1
[18:14] <slytherin> dupondje: Is it likely not to enter squeeze soon?
[18:15] <dupondje> testing version is already in ubuntu, but contains some bugs fixed in 0.8.3.1
[18:15] <dupondje> it will get into squeeze prolly, but just don't want to miss it .. as it contains really needed fixes
[18:16] <slytherin> dupondje: The Debian packages get auto synced till DIF date provided there is no Ubuntu specific changes to the package.
[18:16] <slytherin> dupondje: gnome-do is just three days away from entering squeeze. http://packages.qa.debian.org/g/gnome-do.html
[18:16] <om26er> For being a MOTU one must be a developer? even for updating packages?
[18:16] <slytherin> DIF is set on 11th February. So the bug was not really needed.
[18:17] <slytherin> om26er: It depends on what you mean by developer?
[18:17] <om26er> slytherin, patcher/code writer
[18:19] <slytherin> om26er: Most of the packaging work require that you have basic understanding of patches/code writing. Hence people only get involved with packages they actually use.
[18:19] <slytherin> om26er: The basic packaging itself requires knowledge of make (at least).
[18:20] <om26er> slytherin, if I dont know any programming but still I can compile sources can I become a MOTU
[18:20] <maco> yep
[18:20] <maco> packaging is all you need to know
[18:20] <maco> well and policy
[18:21] <dupondje> slytherin: it will automaticly getting added to squeeze after 3 days ?
[18:22] <slytherin> om26er: yes you can in theory. How well it works in practice I can not say.
[18:22] <slytherin> dupondje: yes and soon after that to lucid.
[18:22] <dupondje> okay, so it will be in lucid in ~5 days ?
[18:23] <slytherin> yes
[18:23] <om26er> where should I start
[18:23] <om26er> any documents?
[18:23] <slytherin> om26er: check the links in channel topic
[18:24] <shadeslayer_> om26er: i dont know any programming and yet i compile stuff and just learnt to package
[18:25] <om26er> shadeslayer_, so you are the right person to ask where to start
[18:27] <cyphermox> om26er, you might be interested in following the sessions in #ubuntu-classroom as well, since it's DeveloperWeek
[18:27] <cyphermox> nevermind that, I see you're already there ;)
[18:42] <nyu> hi
[18:42] <nyu> how do I go about requesting that a package is imported from debian sid?
[18:45] <Laney> nyu:  you can use the requestsync tool in ubuntu-dev-tools
[18:46] <nyu> Laney: is there no other way?  I don't have an ubuntu system handy
[18:46] <nyu> (I'm the debian maintainer for that package)
[18:46] <Laney> nyu: it's in debian :)
[18:46] <nyu> oh
[18:47] <Laney> (or you can just file a bug on the package in Launchpad)
[18:47] <nyu> got it, thanks
[18:47] <Laney> but requestsync will grab the changelog entries and such for you
[18:47] <MTecknology> I want to submit this package to Debian so it reaches a wider audience but I'm starting to think it's not worth the hassle and I should just get it into Ubuntu
[18:48] <Laney> what hassle?
[18:48] <blairzajac>    g
[18:48] <blairzajac> oops, mistype
[18:49] <MTecknology> Laney: so for I've submitted the ITP twice but never heard back
[18:51] <MTecknology> Laney: You see anything wrong with this? http://paste.ubuntu.com/364730/
[18:51] <MTecknology> except the extra ) in line 12
[18:51] <Laney> MTecknology: an ITP isn't something you hear back from
[18:51] <Laney> it's just a bug that says 'i am packaging this'
[18:52] <MTecknology> Laney: You're supposed to..
[18:52] <Laney> no
[18:52] <MTecknology> Laney: that's what I was told in #debian-mentors
[18:52] <Laney> you need to ask someone to sponsor your package
[18:52] <Laney> just like you do in ubuntu
[18:52] <MTecknology> Laney: Even if it doesn't; it's still supposed to show up here - http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp;dist=unstable
[18:53] <Laney> then your reportbug is broken
[18:54] <MTecknology> Laney: aptitude install reportbug
[18:55] <Laney> you should try setting the smtp host
[18:55] <Laney> (and blaming your own setup before writing debian off)
[18:56] <MTecknology> Laney: you're being pretty rude
[18:56] <MTecknology> Laney: http://paste.ubuntu.com/364733/
[18:57] <Laney> well if your bugs aren't showing up then there is something wrong with the way you are reporting them, yes?
[18:57] <Laney> you probably want smtphost not mta :)
[18:57] <nyu> E: The package 'mingw-w64' does not exist in the Debian primary archive in 'sid'
[18:57] <nyu> uhm damn
[18:57] <nyu> I guess it won't import from incoming? ;-P
[18:58] <Laney> nyu: usually have to wait for dinstall + archive push + all that fun stuff
[18:58] <MTecknology> Laney: I'm trying that out now.
[18:58] <nyu> okay then
[18:59] <nyu> thanks for your help
[18:59] <Laney> no worries
[19:18] <MTecknology> Laney: there way go - you do get an email response.. - thanks for that s/mta/smtphost/
[19:20] <hyperair> banshee builds on intrepid!!
[19:20] <hyperair> oops wrong channel
[19:34] <dooooomi> are ubuntu packages required to contain manpages for command line apps? i think i remember reading something like that about debian...
[19:42] <randomaction> dooooomi: this is a near-requirement for new packages
[19:43] <randomaction> and absence of manpage counts as a bug for existing ones
[19:46] <dooooomi> randomaction: thanks, i guess i'll need to write one then...
[19:46] <randomaction> help2man is a useful tool
[19:48] <dooooomi> randomaction: great, that will makes things a lot easier!
[20:32] <knipknap> i am trying to build a ubuntu package that shows no errors in "revu". when I add a debian/watch file, lintian reports "debian-watch-file-in-native-package"; when I don't, revu reports an error. which one is correct?
[20:33] <randomaction> add watch file and make package non-native :)
[20:33] <knipknap> how would i make it non-native?
[20:34] <randomaction> you need an upstream tarball for that
[20:34] <directhex> knipknap, a "native package" is one where ubuntu is the upstream, i.e. where there's no "orig" tarball downloaded from anywhere
[20:35] <randomaction> named PACKAGE_UPSTREAMVERSION.orig.tar.gz
[20:36] <knipknap> ok; i am actually trying to integrate the debian directory directly into the upstream makefile; there is no tarball at the time at which the debian package is created - does this mean that a tarball is absolutely required anyway?
[20:41] <randomaction> native format is usually used for Ubuntu infrastructural packages
[20:42] <randomaction> from https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews: "Package should not be native without an approved spec"
[20:45] <randomaction> how can you have a watch file without tarballs anyway?
[20:48] <knipknap> the watch file points to already published releases. but the release that is currently being built doesn't exist there at the time when the debian package is prepared. in other words, the package is built before the source package is officially released.
[20:50] <knipknap> i guess i'll have to change the release workflow for this to work
[20:52] <randomaction> you don't need to, it's a common situation
[20:52] <randomaction> you can check out versions from your VCS and turn them into tarballs
[20:53] <randomaction> if, for example, previous release is 1.2.3 and next is 1.2.4, you can name your resulting tarball 1.2.3+git20100128 or 1.2.4~git20100128
[20:54] <randomaction> or replace git with your VCS
[20:57] <knipknap> ah! that looks nice. i'll give it a try
[21:21] <knipknap> huh. now locally, i don't get any errors. but revu still claims "This is a native Debian package, with no .orig.tar.gz tarball", even though the orig.tar.gz was uploaded by dput. (http://revu.ubuntuwire.com/p/gelatin) i'm confused
[21:27] <randomaction> version in changelog should be 0.1.12~git20100128.gb1f8fdd-0ubuntu1
[21:28] <randomaction> also, your tarball seems to be missing doc/ and syntax/ directories, as well as other files
[21:28] <stochastic> If I'm already an ubuntu member and want to eventually become a motu, is there a documented process of doing so?
[21:29] <geser> stochastic: start contributing :)
[21:29] <randomaction> stochastic: then apply to DMB
[21:29] <stochastic> I have been contributing
[21:30] <stochastic> I just seem to remember there was an intermediate stage like 'universe contributor' or something
[21:31] <stochastic> geser, randomaction, ^^ ?
[21:31] <randomaction> stochastic: https://wiki.ubuntu.com/UbuntuDevelopers
[21:31] <geser> there still is but as a Ubuntu member isn't give you any additional benefit (only one badge more on your LP page)
[21:31] <randomaction> yep, no upload rights
[21:31] <stochastic> ahh, okay
[21:31] <stochastic> thanks.
[21:32] <geser> 'universe contributor' is just an other path to become Ubuntu member
[21:49] <knipknap> randomaction, yay, all bugs on revu disappeared (except for the launchpad bug reference). thanks!
[21:49] <knipknap> so.. against which package must i file a bug...?
[21:49] <knipknap> ugh, too late
[21:57] <Nahsei> Hello! I would like to ask some basic questions....
[21:58] <Nahsei> I followed this recipe:   https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
[21:59] <Nahsei> and in point 5, just like it says in the recipe, the procedure failed
[22:00] <Nahsei> then it says that the best solution is to dch -e, and that i should get some result show my current version...
[22:01] <Nahsei> but i got confused... i ran the same command on both the old and the new sources and i couldn't understand what i was supposed to do
[22:02] <Nahsei> because de new source code already had my version... the old source code should remain the same, right?
[22:02] <Nahsei> (in changelog...)
[22:02] <Nahsei> can someone help me?
[22:02] <Nahsei> thanks
[22:04] <xteejx> Hey guys, I'm trying to package another new project, the last one was already packaged, I didn't check...doh!
[22:05] <xteejx> The one I'm doing now has no configure/make abilities, it is simply source code. How can I Ubuntu-ize it?
[22:10] <xteejx> How do I package without a configure/make file?
[22:10] <xteejx> ^To put it another way
[22:16] <neversfelde> how do I skip dh_auto_test for debehlper in debian/rules?
[22:19] <xteejx> Remove it from rules I would've thought or comment it out with #
[22:20] <neversfelde> xteejx: I use dh --with kde $@, so I guess I have to add an override
[22:20] <xteejx> dunno then, sorry
[22:20] <xteejx> I'm new, seemed logical
[22:20] <geser> xteejx: what does upstream write about how to install it?
[22:23] <xteejx> I've just looked again...there's a Makefile.am and Makefile.in
[22:24] <xteejx> The README says "./configure && make"
[22:24] <xteejx> I get ./configure: No such file or directory - there simply isn't a configure script
[22:26] <xteejx> make fails with or without telling it the Makefile.in/am .... all the files are .hpp or .cpp
[22:28] <xteejx> With "No rule to make target `Makefile'."
[22:28] <xteejx> :(
[22:46] <geser> do you have a configure.in?
[23:29] <dooooomi> hi everyone, i've uploaded a new package to REVU: klick is a command-line metronome using the JACK sound server. http://revu.ubuntuwire.com/p/klick