[00:24] <RoAkSoAx> heya guys... I want to package from scratch a program that contains a kernel module and and a user space daemon. When issuing dh_make, and selecting the type of package.. what should I select?
[00:27] <jmarsden> RoAkSoAx: I suspect that whichever you pick you'll end up making a lot of changes to the resulting template files from dh_make -- mabe try both and use the one that looks closest to what you think you'll want?
[00:28] <RoAkSoAx> jmarsden, ok thanks :)
[00:31] <directhex> i suspect dh_make is 101% useless for this kind of package
[00:31] <directhex> you want to look at a package which makes use of dkms, and rip off the contents of its debian/ folder
[00:36] <RoAkSoAx> ok
[09:24] <pythonic> hi, revu says Package is for "unstable" but only packages for "karmic" are currently accepted.
[09:26] <jmarsden> pythonic: Did you upload a package to REVU that had "unstable" in the debian/changelog when it should have said "unstable"?  In the top line of the changelog file?
[09:26] <pythonic> right, it has unstable, should that be karmic (or whatever the next one is)?
[09:27] <loic-m> pythonic: unstable is for Debian, replace it with karmic and use a -0ubuntu1 version number
[09:27] <loic-m> pythonic: you just need need to edit that in the changelog (version + distribution)
[09:27] <pythonic> ok, i have 0ubuntu1 version.. karmic is just the next release right? do i update the package when karmic is released to whatever the next release is?
[09:28] <pythonic> (if the package is not accepted before karmic releases)
[09:29] <jmarsden> Yes, as far as I know.
[09:30] <pythonic> ok, thanks
[09:30] <pythonic> i need to bump the version to 0ubuntu2 etc. for this right?
[09:33] <loic-m> nope
[09:34] <pythonic> oh, ok, when do i bump version numbers?
[09:34] <loic-m> as long as the package isn't accepted, you only get one entry in the changelog - 0ubuntu1 for new pkg not in Debian
[09:35] <loic-m> pythonic: it's different from Debian, where you document your changes and bump the version even when the package hasn't been accepted yet
[09:35] <pythonic> i see.. i already have a package or two at 0ubuntu2. should i change those to 0ubuntu1?
[09:35] <loic-m> pythonic: once the package enter the repos, you bump the version number when you release a new version or modify the packaging
[09:36] <loic-m> pythonic: are they on REVU?
[09:36] <pythonic> yes
[09:36] <loic-m> Then AFAIK it should be 0ubuntu1 with only one changelog entry (you can regroup info from the two entries you have at the moment if it's relevant)
[09:37] <pythonic> ok, thanks
[09:40] <loic-m> you're welcome
[09:52] <pythonic> ok, fixed now
[11:34] <davideotape> Hi guys :)
[11:35] <davideotape> Does anyone know how I can download the french source for https://bugs.edge.launchpad.net/ubuntu/+source/iat when I'm on an english computer?
[11:38] <directhex> davideotape, french source?
[11:39] <davideotape> directhex: Well, the french translation of that package
[11:39] <davideotape> If it helps, this is the bug I'm working on: https://bugs.edge.launchpad.net/ubuntu/+source/iat/+bug/379290
[11:46] <iulian> davideotape: apt-get source <pkg>
[11:48] <davideotape> iulian: That gets me the source with the English translation, which doesn't' have the French description in it
[11:48] <kklimonda> could any MOTU sponsor bug 383109?
[11:50] <davideotape> kklimonda: Does that bug not need to be set to confirmed now you've provided a patch?
[11:51] <kklimonda> davideotape: good point.
[11:51] <iulian> davideotape: That's odd.  I have no idea, sorry.  I couldn't find any translation in the source package.
[11:52] <directhex> the description as in "apt-cache show" description?
[11:53] <iulian> directhex: Yea, it seems so, take a peek at the bug report.
[11:53] <davideotape> directhex: Yes, but the french description
[11:56] <directhex> right, i didn't think ubuntu used that
[11:56] <directhex> check rosetta?
[12:01] <davideotape> directhex: iat doesn't seem to use rosetta (ie. https://translations.edge.launchpad.net/ubuntu/jaunty/+source/iat) doesn't exist
[12:06] <pochu> only packages in main do
[12:06] <geser> kklimonda: looking at your debdiff: how will this change fix the dependencies on python itself?
[12:07] <kklimonda> geser: right now python 2.6 modules are installed in /usr/local/...
[12:07] <davideotape> pochu: I've found http://packages.debian.org/lenny/iat . What does debian use for it's translations?
[12:07] <kklimonda> geser: because of that they aren't even installed in package.
[12:08] <pochu> davideotape: is it translated at all?
[12:08] <geser> kklimonda: the current python packaging helper know about that and move the files around, see http://launchpadlibrarian.net/27399626/buildlog_ubuntu-karmic-i386.mercurial_1.2.1-3_FULLYBUILT.txt.gz
[12:08] <davideotape> pochu: It must be, as the bug reporter ( https://bugs.edge.launchpad.net/ubuntu/+source/iat ) says that they are using the french version
[12:09] <kklimonda> geser: but not modules compiled into .so
[12:09] <pochu> oh
[12:09] <geser> ah, I guess I begin to understand
[12:10] <pochu> davideotape: it's not the program that is translated, but the description :-)
[12:10] <kklimonda> geser: copying build/lib.linux-i686-2.6/mercurial/base85.so -> /build/buildd/mercurial-1.2.1/debian/tmp/usr/local/lib/python2.6/dist-packages/mercurial - they go here and then aren't in resulting package at all.
[12:10] <geser> right
[12:10] <kklimonda> geser: and because of that /usr/bin/hg has python2.5 hardcoded as interpreter
[12:10] <davideotape> pochu: Okay. So where about are descriptions translated for ubuntu then?
[12:12] <pochu> davideotape: ddtp in Debian
[12:12] <davideotape> pochu: So that bug is one that would need to be fixed in debian, and passed downstream?
[12:13] <pochu> davideotape: you should check if the typo is in Debian, and if so, the answer is yes
[12:13] <pochu> I think there's something similar to ddtp in Ubuntu, but am not sure what it is
[12:15] <davideotape> pochu: Thanks, I'll go and have a look now :)
[12:19] <geser> kklimonda: thanks, uploaded (with one additional change)
[12:25] <pochu> kklimonda: a FTBFS in Ubuntu that doesn't happen in Debian isn't a serious bug in Debian (re mercurial)
[12:26] <kklimonda> pochu: heh, my bad - I though about it too late.
[12:28] <pochu> you can still lower it :)
[12:30] <DktrKranz> pochu, at least for now :)=
[12:30] <pochu> DktrKranz: and hopefully not for a long time :-)
[12:30]  * DktrKranz accepts bets
[12:35] <mib_oujn9hi1> hey can anyone help me create a simple meta package
[12:36] <kklimonda> pochu: can I send an email with Severity: minor in first line and then comment? debian bts is really confusing sometimes.. ;)
[12:36] <DktrKranz> kklimonda, send one with severity bugnumber wishlist to control@bugs.debian.org instead
[12:37] <pochu> or use the 'bts' command :)
[12:41] <kklimonda> yeah, it's much easier :)
[13:45] <goshawk> hi
[13:51] <goshawk> there is a problem with this package
[13:52] <goshawk> http://packages.ubuntu.com/karmic/mercurial
[13:52] <goshawk> i can't install on karmic
[13:52] <goshawk> due to dependency error
[13:52] <goshawk> python < 2.6
[13:53] <goshawk> but debian/control says : +Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}, ucf (>= 2.0020),
[13:53] <goshawk> + mercurial-common (= ${source:Version})
[13:54] <cody-somerville> goshawk, Whats your question exactly?
[13:55] <goshawk> have python been updated recently that a recompile of mercurial is needed?
[13:55] <pochu> goshawk: the fix has already been uploaded
[13:55] <pochu> what version of mercurial are you trying to install?
[13:55] <goshawk> mercurial (1.2.1-3
[13:56] <goshawk> official from karmic
[13:56] <goshawk> i'm in karmic
[13:56] <pochu> goshawk: 1.2.1-3ubuntu1 fixes it
[13:56] <pochu> so just wait until it appears in your mirror
[13:56] <goshawk> oki :)
[13:58] <goshawk> pochu: as long as you know, was it just a recompiling problem or a probem in the control or rules (i'm the one that filled the sync for that package, this is why i wanna know)
[13:58] <goshawk> *sync bug
[14:18] <pochu> goshawk: it needed some adjustements to build with 2.6
[14:20] <goshawk> pochu: thx
[14:45] <siretart> FYI: I've just uploaded debian's mplayer uploaded to ubuntu
[15:58] <aravindoo> hello everyone
[15:59] <aravindoo> i am new. how do i join motu
[16:02] <hyperair> !motu
[16:02] <Laney> there's a getting involved link in the topic
[16:04] <aravindoo> thank for info guys
[16:09] <hyperair> have fun
[17:25] <thjc> Hi all, I am working on packaging a new library (gearbox) for ubuntu. The library uses cmake and produces a python extension, however doesnt use distutils
[17:26] <thjc> I am on good terms with the developers so can get changes made to the build system, what is the recommended way of dealing with python extensions with cmake?
[17:27] <hyperair> er. use their build system?
[17:27] <hyperair> actually the recommended way of dealing with python extensions is using distutils
[17:27] <hyperair> i suggest you drop by #debian-python and ask the guys there
[17:27] <hyperair> in OFTC, by the way
[17:30] <thjc> okay will do
[19:56] <kklimonda> When I'm updating package in ubuntu and, between time I have prepared debdiff and it was sponsored by developer, new version is released can I keep in changelog entry about previous one that didn't make it to ubuntu?
[19:57] <kklimonda> I keep changes in bzr repository so reverting it because update didn't happen is going to be pain in the ass.. ;)
[19:57]  * LarstiQ would keep the changelog entries
[19:58] <LarstiQ> but I don't see how having it version controlled is making it _harder_
[20:00] <kklimonda> no harder, just more work - i would have to revert a commit ;)
[20:04] <LarstiQ> kklimonda: no?
[20:06] <kklimonda> why not?
[20:07] <ScottK> kklimonda: No.  Debian/changelog should be the history of the package in the archive.
[20:07] <ScottK> You needed revert, just merge the changes in and then re-edit your changelog.
[20:07] <ScottK> needed/needn't.
[20:08] <LarstiQ> ScottK: which archive though?
[20:08] <ScottK> The Ubuntu one (or Debian/Ubuntu in the case of packages we get from Debian and modify).
[20:08]  * ScottK observes the Ubuntu is the distro we are working on here ....
[20:09] <LarstiQ> ScottK: the latter case is tricky
[20:09] <ScottK> LarstiQ: Not at all.  We have well established tools for the merge process.
[20:09] <LarstiQ> nevermind
[20:09] <ScottK> OK.  Obviously we aren't communicating very well.
[20:10] <ScottK> If you care to discuss it, it's fine with me.
[20:10] <LarstiQ> ScottK: you make a valid point, it's just that I'm not included
[20:11] <LarstiQ> so I'll do the right thing and leave this channel, as I should have before
[20:11] <LarstiQ> ScottK: I'm fine with discussin it somewhere else
[20:11] <ScottK> LarstiQ: I certainly didn't intend to say anything that would cause you to leave.
[20:12] <LarstiQ> ScottK: no worries
[20:12] <LarstiQ> ScottK: would /query be ok with you?
[20:13] <e-jat> can some one verify this : http://tinyurl.com/q6cm5l
[20:14] <ScottK> LarstiQ: If you really feel  it's needed.  OK.
[20:14] <kklimonda> e-jat: link is broken
[20:15] <e-jat> yups .. proposed repo broken right ?
[20:15] <kklimonda> no, the link to the post is broken
[20:20] <ScottK> YokoZar: I thought you'd be interested in http://ariya.blogspot.com/2009/06/how-to-get-spotify-running-on-opensuse.html
[20:21] <YokoZar> ScottK: thanks
[20:21] <ScottK> no problem.
[20:21] <LarstiQ> ScottK: thanks, and cheers
[20:21]  * LarstiQ goes back to #bzr
[20:34] <c_korn> can anyone explain me why this build fails? http://launchpadlibrarian.net/27625080/buildlog_ubuntu-jaunty-i386.vlc_1.0.0~rc3-1~ppa1~jaunty1_FAILEDTOBUILD.txt.gz
[20:36] <soren> c_korn: Because libvlccore2 stopped provinding a unescape_URI function?
[20:39] <c_korn> soren: so I just have to delete those two lines from the symbols file?
[20:40] <soren> c_korn: Err...
[20:40] <soren> c_korn: Not exactly.
[20:41] <soren> c_korn: I mean.. Yes, that will make the build succeed again, but if something is actually using that symbol, you're screwed.
[20:41] <c_korn> (as I see the symbols have been removed upstream http://git.videolan.org/?p=vlc.git;a=commit;h=2341f8bbc23622d0d8b8a511b7cc745d20beb878 )
[20:41] <soren> If it was never used externally and only exported by accident or whatnot, you're probably fine.
[23:17] <pochu> cool - http://af.reuters.com/article/oddlyEnoughNews/idAFTRE55623320090607
[23:23] <directhex> pochu, sadly it sounds like the BNP have some seats too
[23:27] <pochu> not everything can be perfect...