[01:19] <LCID_Fire> Hi. Could anyone tell me why git-buildpackage does not produce a orig.tar.gz?
[03:15] <stefanlsd> Im not unable to subscribe u-u-s. Anyone else having that issue?
[04:04] <Hobbsee> directhex: just filter that guy out.  That'll save you a lot more headaches.
[04:04] <Hobbsee> (but yeah.  agh, not again)
[05:27] <AnAnt> Hello
[06:42] <quentusrex> is it possible to build binary packages for hardy, intrepid and jaunty? easily?
[06:42] <quentusrex> I have a source package that builds for each one, but so far I have had to copy it to 3 different machines to build the binary.
[06:47] <ScottK> This is pretty easy to do with pbuilder.
[11:39] <LCID_Fire> Could someone answer the following question - I have the sourcecode of an application without any build files - for the debian package I added autotools build to the app. Now when I generate the source package (and orig.tar.gz), what should it contain: 1. the original application sourcecode 2. the full debianized sourcecode
[11:39] <LCID_Fire> )
[11:39] <LCID_Fire> ?
[11:41] <lifeless> a) you shouldn't be generating the orig.tar.gz; that should come from the upstream.
[11:41] <lifeless> b) the diff, naturally, should contain all changes you have made, in some form.
[11:45] <LCID_Fire> I have a git branch where the original sourcecode resides - and another one where the changes are done - but it just can't get the source package to be generated
[12:02] <Laney> LCID_Fire: are you the upstream developer?
[12:03] <LCID_Fire> Laney: nope - I'm the idiot who tried to build a debian package
[12:03] <Laney> ok so you shouldn't modify their releases
[12:03] <LCID_Fire> Laney: clarify "modify their releases"
[12:03] <Laney> the unmodified upstream source should be in the orig
[12:04] <Laney> and your changes in the diff
[12:05] <LCID_Fire> that's pretty much how the branches are setup in my git repo - but git-buildpackage keeps screwing it...
[12:06] <Laney> you should have a master and an upstream branch
[12:06] <Laney> upstream is just the unpacked tarball
[12:06] <Laney> and master is that + debian/ + your changes
[12:06] <Laney> master is merged from upstream
[12:07] <LCID_Fire> yep - it seems to me like git-buildpackage does not now what to use as orig source
[12:07] <Laney> maybe you need pristine-tar too?
[12:07] <Laney> hyperair knows more about this than me, he can probably help better
[12:07] <LCID_Fire> ?
[12:08] <LCID_Fire> hyperair always helps :)
[12:08] <lifeless> LCID_Fire: this has _nothing to do with branches_
[12:08] <Laney> he is the master of git
[12:08] <lifeless> LCID_Fire: the upstream *tarball* is what matters.
[12:08] <lifeless> LCID_Fire: as for git specific stuff, I can't help sorry.
[12:08] <LCID_Fire> lifeless: the tarball does not matter if you build from scm
[12:08] <lifeless> LCID_Fire: for debian and ubuntu packages, it does.
[12:09] <Laney> LCID_Fire: paste the output of git-buildpackage -S
[12:10] <Laney> Orig tarball 'agda_2.2.2.orig.tar.gz' not found at '../tarballs/'
[12:10] <Laney> pristine-tar: successfully generated /home/laney/dev/debian/packaging/build-area/agda_2.2.2.orig.tar.gz
[12:10] <Laney> that's what happens with one of my git packages
[12:11] <LCID_Fire> lifeless: the point is that orig.tar.gz is to be GENERATED out of git - but it isn't :(
[12:11] <Laney> where did the upstream sources come from in the first place?
[12:11] <lifeless> LCID_Fire: if you're not using pristine_tar, it cannot be created from git.
[12:11] <stefanlsd> Im not unable to subscribe u-u-s. Anyone else having that issue?
[12:11] <Laney> is there a release at all?
[12:11] <lifeless> LCID_Fire: or any other VCS
[12:12] <LCID_Fire> Laney: sourceforge - http://sourceforge.net/project/showfiles.php?group_id=171505
[12:12] <LCID_Fire> lifeless: I don't even know what pristine_tar is
[12:12] <lifeless> LCID_Fire: then just download the original tarball, name it correctly, and away you go.
[12:13] <LCID_Fire> lifeless: it's zip ;)
[12:13] <lifeless> LCID_Fire: ugh. Well you'll need to repack it, but do that once.
[12:15] <Laney> uscan can do this with --repack (I think for .zip)
[12:15] <LCID_Fire> lifeless: but to maintain it - I need it to be generated - I'm not in the mood to manually create the orig.tar.gz every time there is a release
[12:15] <Laney> LCID_Fire: please stop that huge paste if you can
[12:15] <Laney> :(((
[12:15] <LCID_Fire> Laney: done
[12:15] <Laney> thanks
[12:15] <Laney> pastebin would be easier to read
[12:16] <LCID_Fire> Laney: on my xchat it's pretty good to read
[12:16] <lifeless> LCID_Fire: then don't maintain this package, or get upstream to start generating tarballs.
[12:16] <Laney> so, what you want to write is a watch file
[12:16] <Laney> and then a get-orig-source file which calls uscan --repack
[12:16] <lifeless> *someone* somewhere has to put the orig source into a tarball for ubuntu packages.
[12:17] <LCID_Fire> lifeless: that's the point of git-buildpackage - it SHOULD do the work (at least it is advertised)
[12:17] <Laney> no
[12:17] <LCID_Fire> Laney: I have no idea what you are talking about, sorry
[12:18] <lifeless> LCID_Fire: thats not the point of git-buildpackage
[12:18] <Laney> LCID_Fire: then you should find out
[12:18] <LCID_Fire> yes it is: please read "man git-buildpackage"
[12:19] <lifeless> LCID_Fire: its point, like that of svn-buildpackage, bzr-buildpackage etc etc is to allow better granularity in maintaining the delta that makes up the packaging data & bugfixes that are needed to package the software
[12:19] <LCID_Fire> lifeless: you're right - but the manpage also says: "Build an orig.tar.gz if it doesn't exist."
[12:19] <lifeless> pristine-tar does allow putting *an existing* orig.tar.gz into a VCS and reconstructing it later.
[12:20] <LCID_Fire> lifeless: I did this with git-import-orig
[12:20] <Laney> actually gbp does let you do this without pristine-tar, but it isn't idempotetnt
[12:21] <Laney> agda_2.2.2.orig.tar.gz does not exist, creating from 'upstream/2.2.2'
[12:21] <lifeless> right, which makes it unsuitable for collaborative maintenance
[12:21] <LCID_Fire> for whatever reason this does not work for me
[12:22] <LCID_Fire> lifeless: why?
[12:22] <lifeless> because SHA1
[12:22] <LCID_Fire> shouldn't it work when everyone is using git?
[12:23] <lifeless> no
[12:23] <lifeless> as Laney says its not idempotent
[12:23] <Laney> he means it generates a different tarball each time it's run
[12:23] <Laney> this is the problem that pristine-tar fixes
[12:23] <lifeless> besides which, many people use other VCS's than git
[12:24] <hyperair> Laney: LCID_Fire you called?
[12:24] <Laney> it's alright
[12:24] <Laney> but, good morning!
[12:24] <LCID_Fire> hi
[12:25] <LCID_Fire> so the way gbp works is actually a bug?
[12:27] <LCID_Fire> btw: just found http://juliank.wordpress.com/2008/02/04/experiences-with-git-and-pristine-tar/
[12:28] <Laney> this is pretty much what we said
[12:29] <LCID_Fire> the interesting thing is - the patch was submitted - but pristine is not a dependency of git-buildpackage...
[12:30] <Laney> it's only optional
[12:34] <LCID_Fire> I still don't get why it isn't generating orig.tar.gz
[12:34] <Laney> if you pasted the output that I asked for we could take a look
[12:34] <Laney> to a pastebin(!)
[12:35] <LCID_Fire> np - you just have to wait till I google pastebin
[12:35] <Laney> www.pastebin.com
[12:38] <LCID_Fire> interesting - it's on http://pastebin.com/d4617b699
[12:41] <Laney> this isn't the whole output
[12:42] <LCID_Fire> it is the output of "git-buildpackage -S -sa --git-pristine-tar > ../build.txt"
[12:42] <Laney> remove those other options
[12:43] <LCID_Fire> so just using -S?
[12:43] <Laney> you're telling it explicitly to use git-pristine-tar there
[12:43] <Laney> ep
[12:43] <Laney> yep
[12:43] <LCID_Fire> ok
[12:46] <LCID_Fire> updated: http://pastebin.com/d1848a594
[12:48] <Laney> oh
[12:48] <Laney> you've made a native package
[12:48] <Laney> you need to make the version 7.1.2-0ubuntu1
[12:49] <LCID_Fire> how do these last 2 statements link?
[12:50] <Laney> http://people.debian.org/~mpalmer/debian-mentors_FAQ.html
[12:50] <Laney> check the FAQ about native packages
[12:51] <LCID_Fire> and why isn't it telling me this conclusion when I'm building?
[12:52] <Laney> because it doesn't know that this isn't what you want
[12:52] <LCID_Fire> but it should at least tell me what it does and what it thinks that I want
[12:53] <Laney> #
[12:53] <Laney> dpkg-buildpackage: source only upload: Debian-native package
[12:54] <LCID_Fire> Laney: this line is as good as saying nothing - it just helps if you already know what you have to do - which is what debian packaging seems to be aimed at
[12:57] <Laney> right, these are tools for developers to use in their daily work
[12:57] <Laney> documentation and help forums such as this are for learning how they work
[12:58] <LCID_Fire> In former times I wondered why so much software is not packaged for debian - now I know
[12:59] <Laney> it's really not bad if you read some documentation
[13:00] <LCID_Fire> I read a LOT - but you can't read everything there is to packaging - they hardly make a clear point
[13:00] <Laney> complaining to me isn't going to help anything
[13:00] <Laney> you have this place to ask specific questions
[13:00] <Laney> and then you can help to improve the documentation
[13:00] <LCID_Fire> I know - but I have to get all the anger out of my system ;)
[13:02] <LCID_Fire> besides I'm now stuck with "dpkg-source: unrepresentable changes to source" (seems to be related to autotools) - I'm getting further in babysteps
[13:02] <LCID_Fire> but for now - thanks a lot - would have never figured these things out without you guys
[15:17] <dupondje> Hello, I'm working on https://bugs.edge.launchpad.net/hundredpapercuts/+milestone/round-1
[15:17] <dupondje> I fixed a bug now, but how & where do I upload it ?
[15:23] <RainCT> dupondje: which bug is it?
[15:24] <dupondje> https://bugs.edge.launchpad.net/bugs/57210
[15:25] <RainCT> dupondje: In this case it'd be best to get the fix directly into GNOME.
[15:26] <dupondje> RainCT: but isn't it to late then to get it into Karmic ?
[15:26] <RainCT> dupondje: but it seems like someone has already provided a patch there
[15:26] <dupondje> yea, not working + outdated
[15:27] <RainCT> dupondje: No, not if it gets into GNOME in time. Karmic will ship with the next GNOME release.
[15:27] <dupondje> ok
[15:38] <masterkernel> hello
[15:39] <masterkernel> how do I request that a program be packaged?
[15:39] <hyperair> masterkernel.. you the one packaging kernelcheck?
[15:39] <masterkernel> yes
[15:39] <hyperair> anyway you file a needs-packaging bug in ubuntu
[15:40] <masterkernel> the problem is that I want to remain anonymous
[15:40] <hyperair> yes, i noticed.
[15:40] <hyperair> you could use a false alias ;)
[15:40] <hyperair> a real sounding false alias
[15:40] <masterkernel> John Smith
[15:40] <hyperair> heheh
[15:40] <hyperair> don't quote me on that
[15:40] <masterkernel> i wont
[15:40] <hyperair> some people will grill me i'm sure
[15:41] <hyperair> the channel's logged anyway, so whoops =p
[15:41] <Nafallo> and keep lurkers ;-)
[15:41] <masterkernel> i attempted to try to get other people to do it for me but no one's picked it up thus far
[15:41] <masterkernel> *package it
[15:42] <nhandler> RainCT: I just saw your pull-revu-source request. I have been thinking about that for a while. Instead of allowing users to pull from different versions of Ubuntu/Debian, they could pull different uploads of that package by specifying a date/upload id
[15:42] <hyperair> masterkernel: poke around in #ubuntu-kernel, maybe someone will be interested enough.
[15:42] <masterkernel> good call
[15:43] <hyperair> =)
[15:43] <hyperair> i'm past my kernel compiling days, or so i'd like to say
[15:43] <hyperair> because the kernel just works for me, and my notebook overheats and shuts down if i compile something that big
[15:44] <hyperair> otherwise i'd package it
[15:44] <hyperair> i think it's a good idea to get it into debian and let it get synced into ubuntu though
[15:44] <hyperair> that way more people benefit from the package
[15:44]  * hyperair pokes masterkernel 
[15:44] <masterkernel> I would ask the co-author to do it but i don'
[15:44] <ivoks> what's kernelcheck?
[15:45] <masterkernel> t think he knows much about packaging
[15:45] <masterkernel> http://kcheck.sourceforge.net/
[15:45] <ivoks> yeah, i'm looking at the page
[15:45] <ivoks> ah... found it
[15:45] <hyperair> i think it's something that downloads the up to date kernel sources
[15:45] <hyperair> and compiles it
[15:45] <hyperair> after applying the ubuntu patch
[15:45] <hyperair> basically a GUI for it
[15:46] <masterkernel> I should update the description on the homepage -- not very informative
[15:46] <ivoks> urgh...
[15:46] <hyperair> hmm come to think of it, there was someone who posted those awesome guides on ubuntuforums by the name Master Kernel. is that you?
[15:46] <masterkernel> yeah
[15:46] <ivoks> masterkernel: it's not easy to find, actually :)
[15:46] <hyperair> masterkernel: how come you didn't just call the project kernelcheck?
[15:46] <hyperair> masterkernel: like kernelcheck.sf.net instead of kcheck
[15:46] <ivoks> so, it breaks all tools that dpends on specific version of modules?
[15:47] <masterkernel> I'm not really sure
[15:47] <masterkernel> that would be logical
[15:47] <RainCT> nhandler: I don't use those tools so I have no comment on that (the request was from porthose, I only marked ubuntu-dev-tools as affected because he filed it against REVU).
[15:47] <masterkernel> ivoks: ?
[15:48] <ivoks> masterkernel: there are tools in linux distributions that depend on specific versions of modules
[15:48] <hyperair> what tools?
[15:48] <ivoks> i'm just trying to figure out what this kernelcheck actually is :)
[15:49] <ivoks> drbd, kvm...
[15:49] <ivoks> mostly kernel stuff
[15:49] <ivoks> errr... server :)
[15:49] <masterkernel> I haven't seen any breakages in my compilations - and with dkms they seem to compile right with every new kernel
[15:49] <masterkernel> apart from nvidia/ait
[15:49] <masterkernel> *ati
[15:50] <ivoks> right, dkms would help
[15:50] <dupondje> RainCT: I added patch to the Gnome bug, what should I do with the launchpad bug ?
[15:53] <hyperair> doesn't nvidia use dkms too?
[15:53] <ivoks> they do
[15:53] <ivoks> and should work
[15:53] <masterkernel> it's broken other than ubuntu-specific kernels
[15:54] <masterkernel> problems with nvidia-common
[15:54] <masterkernel> so I always have to use the binary package
[15:56]  * RoAkSoAx says hello
[15:57] <RainCT> dupondje: just leave a note saying that there's a patch in bugzilla
[15:57] <dupondje> ok
[15:57] <RainCT> dupondje: maybe you can get someone to look at it on #gnome-love (server irc.gnome.org)
[15:58] <dupondje> done :D
[15:58] <dupondje> thx
[15:59] <masterkernel> ubuntu-kernel seems inactive
[16:03] <RoAkSoAx> ivoks, heya master how's it going
[16:03] <ivoks> ok
[16:03] <ivoks> you?
[16:03] <RoAkSoAx> ivoks, tired :) just woke up xD
[16:04] <RoAkSoAx> ivoks, do you have little time to help me out with something?
[16:04] <ivoks> sure
[16:05] <RoAkSoAx> ivoks, ok, I've worked with: https://bugs.launchpad.net/ubuntu/+source/passenger/+bug/382539 and I have some doubts on the lintian warnings that are listed there in the comment
[16:06] <ivoks> ok
[16:06] <RoAkSoAx> ivoks, the first warning is related to that ${misc:Depends} is not use. I was wondering. what is ${misc:Depends} used for, and if it's necessary in my case??
[16:09] <maxb> It is used by miscellaneous components of debhelper to insert various boilerplate dependencies
[16:10] <ivoks> sorry, wasn't here for a moment
[16:10] <maxb> It simply means you need to include ${misc:Depends} in your package's Depends: line.
[16:11] <ivoks> right, misc:Depends is needed so that package pulls some packages it needs
[16:11] <ivoks> man debhelper
[16:11] <maxb> It's pretty minor, only very few debhelper commands insert anything there
[16:11] <ivoks>    Automatic generation of miscellaneous dependencies.
[16:12] <ivoks> RoAkSoAx: what comaptibility is that? (debian/compat)
[16:12] <RoAkSoAx> ivoks, 6
[16:12] <ivoks> since 4, there should be ${misc:Depends}
[16:14] <ivoks> just put it :D
[16:14] <RoAkSoAx> ivoks, oh i see. what about this warning: passenger source: maintainer-script-lacks-debhelper-token debian/postinst. Does that mean in debian/libapache2-mod-passenger.postinst ¿? because if it's so, the token is there
[16:15] <ivoks> #DEBHELPER#
[16:15] <ivoks> you should have that at the end of the file
[16:16] <ivoks> debian/postinst
[16:16] <ivoks> and debian/prerm
[16:17] <RoAkSoAx> ivoks, like this: http://pastebin.ubuntu.com/200119/ ?
[16:17] <ivoks> just at the end of the file
[16:18] <RoAkSoAx> ivoks, this changes should be in the changelog right?
[16:19] <ivoks> all changes have to be in changelog - that's why it's called changelog
[16:19] <RoAkSoAx> ivoks, and what about the last warning. Should I bump Standards Version ?
[16:20] <ivoks> sure
[16:24] <RoAkSoAx> ivoks, done. So, why is lintian still showing the warnings after the changes have been made?
[16:25] <ivoks> the same warning?
[16:27] <RoAkSoAx> ivoks, i know what's worng. never mind... btw.. if in debian contrl i have a package-doc whicuh install the documentation. should it also have the Depends?? it should right?
[16:27] <RoAkSoAx> I mean, it shouldn't since it's just documentation
[16:28] <directhex> popey, didn't you know "doing something I didn't ask for" is the same thing as "ticking a box in a dialog box to explicitly do something"?
[16:28] <maxb> NB you only bump Standards-Version because the package isn't in Debian at all
[16:29] <popey> directhex: :)
[16:29] <ivoks> RoAkSoAx: does it depend on anything?
[16:29] <directhex> popey, i like how a Certain Blog is accusing keybuk of orchestrating a whisper campaign
[16:29] <RoAkSoAx> ivoks, no, so it should not be used
[16:29] <popey> oh dear
[16:30] <RoAkSoAx> ivoks, btw.. the #DEBHELPER# token should be *only* in debian/postinst debian/prerm or in libapache2-mod-passenger.prerm libapache2-mod-passenger.postinst aswell ?
[16:30] <directhex> popey, due to his response in that thread, where he implies an endless source translation might get boring for its developer at some point
[16:30] <ivoks> RoAkSoAx: in all *inst and *rm scripts
[16:30] <RoAkSoAx> ivoks, ok cool
[16:31] <ivoks> RoAkSoAx: you should have misc:Depends for -doc
[16:32] <popey> directhex: I tire immensely of the whole m ono thing, you must be made of sterner stuff
[16:33] <directhex> popey, i was genuinely distraught last weekend at some of the hate against me on linuxtoday
[16:33] <RoAkSoAx> ivoks, ok this is -doc package: http://pastebin.ubuntu.com/200125/
[16:33] <popey> directhex: :( Sorry to hear that. We (Linux community) are our own worst enemy sometimes. It's so destructive.
[16:34] <ivoks> RoAkSoAx: you should have misc:Depends for -doc
[16:34] <RoAkSoAx> ivoks, just misc:Depends ?
[16:34] <popey> directhex: Just remember there's a boatload of people out here who really appreciate the good work you do.
[16:34] <ivoks> RoAkSoAx: Depends: ${misc:Depends}
[16:35] <directhex> popey, my spirits were lifted enormously by a blog post from David Schlesinger, the guy on u-d-d who had his bos contacted in an effort to have him fired
[16:35] <RoAkSoAx> ivoks, i meant, just misc:Depends and not shlibs:Depends. And, why should it be there ?
[16:35] <popey> directhex: url? not seen it.
[16:35] <directhex> popey, it'd be nice not to have people like [REDACTED] comparing my work to cancer. that'd be a good start
[16:35] <directhex> popey, http://opensourcetogo.blogspot.com/2009/06/when-zeal-becomes-zealotry-tawdry-tale.html
[16:35] <directhex> popey, it gets extra epic in the comments
[16:35] <ivoks> RoAkSoAx: read man page; i'm not going to repeat the stuff i said 5 minutes ago
[16:36] <popey> I am off out for the night, bookmarked for bedtime reading ;)
[16:37] <RoAkSoAx> ivoks, ok sorry
[16:39] <RoAkSoAx> ivoks, thanks for your help.
[16:40] <ivoks> sure
[16:48] <masterkernel> so should I just file a bug under needs-packaging and hope someone picks it up?
[16:57] <directhex> masterkernel, unless it's an app made from awesome and win, requiring little work, the chances of someone doing it for you are not huge
[16:57] <directhex> masterkernel, but you never know
[16:59] <masterkernel> even if I have all the debian/ files ready?
[16:59] <directhex> in that case, you don't file a needs-packaging bug, you upload the source package to REVU
[17:08] <joaopinto> directhex, from my reading of the new package wiki you always need a needs-packaging bug, that's the one you close on the changelog
[17:09] <hyperair> directhex: the issue is that masterkernel wants to remain anonymous.
[17:09] <masterkernel> hyperair: looks like it's possible - http://lists.debian.org/debian-devel/2009/06/msg00601.html
[17:10] <lesshaste> hi all
[17:10] <masterkernel> hyperair: it's getting the sponsor to accept responsibility thats going to be tough
[17:10] <hyperair> heh
[17:15] <joaopinto> odd request
[17:20] <joaopinto> masterkernel, what app is it ?
[17:21] <masterkernel> joaopinto: kernelcheck, i'll give you the link to the deb source in a sec
[17:22] <LCID_Fire> Hi - the bugger is back again ;)
[17:22] <masterkernel> joaopinto: http://mentors.debian.net/debian/pool/main/k/kernelcheck
[17:22] <joaopinto> masterkernel, if I am not mistaken there is already a ppa to get the latest upstream kernel, I don't see much value on such app for ubuntu
[17:24] <masterkernel> check out the doc link - it shows screenshots of the program: http://kcheck.sourceforge.net/pool/Documentation-Lumen.pdf
[17:24] <masterkernel> and kernelcheck lets you customize the kernel - it's not just some generic kernel you can download
[17:25] <masterkernel> it helps with hardware incompatible with the generic kernel, or modding the bootscreen, speeding up boot time and such
[17:26] <joaopinto> ok
[17:26] <LCID_Fire> when dpkg-source complains it means the difference between the orig.tar.gz and the debian changes, right?
[17:26] <joaopinto> masterkernel, looks good :)
[17:30] <hyperair> LCID_Fire: depends on what it complains about really
[17:30] <LCID_Fire> hyperair: error: cannot represent change to some.png: binary file contents changed
[17:31] <hyperair> heheh
[17:31] <hyperair> right
[17:31] <hyperair> yes
[17:31] <hyperair> difference between orig.tar.gz and debian changes
[17:31] <hyperair> question. some.png is inside or outside of debian/?
[17:31] <LCID_Fire> outside
[17:31] <hyperair> then don't change it!
[17:31] <hyperair> just leave it as it is!
[17:32] <LCID_Fire> I pretty much cannot - the original directory structure is pretty messed up
[17:32] <joaopinto> LCID_Fire, you are not expected to cleanup original directory structure as part of the package building :P
[17:32] <LCID_Fire> joaopinto: it's a dirty job, but someone has to do it ;)
[17:33] <joaopinto> why not send that to upstream and request a new clean orig ?
[17:34] <LCID_Fire> joaopinto: because the developer is not too much into contribution - besides he doesn't care too much because he doesn't have to on windows
[17:35] <LCID_Fire> all: basically in order to get debian to work I have to leave every file in it's place?
[17:36] <joaopinto> LCID_Fire, or you repack the original tarball, which is not very common
[17:36] <LCID_Fire> oh boy
[17:36] <joaopinto> and needs a strong reason
[17:37] <LCID_Fire> ok, I'll look into whether restructuring again might be an option
[17:38] <LCID_Fire> btw: how should one properly handle the deletion of a file being present in the orig.tar.gz?
[17:39] <joaopinto> LCID_Fire, you should not delete files from .orig.tar.gz
[17:40] <LCID_Fire> joaopinto: e.g. a compile script that I don't use!?
[17:40] <joaopinto> just don't install them, or remove from the installation target
[17:40] <LCID_Fire> and I do this by???
[17:40] <joaopinto> LCID_Fire, let me try to be very clear, .orig = original source
[17:41] <LCID_Fire> joaopinto: so you mean keep it in the sources but ignore!?
[17:41] <joaopinto> just because you don't need it or dont use it, it is still part of the original source
[17:41] <joaopinto> yes
[17:41] <LCID_Fire> ok - that will be one messy source package
[17:41] <joaopinto> if you need to "fix" the script, use a patch, if you don't just leave it there
[17:42] <LCID_Fire> so - a lot of work ahead - but thanks for now guys :)
[17:48] <ivoks> how should /etc/modprobe.d/dkms.conf be utilized?
[17:48] <ivoks> superm1: here?
[18:23] <dennis> Hello everybody
[18:23] <RoAkSoAx> Heya guys can someone still work with FTBFS and missing dependencies after the Debian Import Freeze?
[18:24] <ivoks> RoAkSoAx: of course
[18:24] <ivoks> RoAkSoAx: development doesn't stop with dif
[18:25] <nhandler> RoAkSoAx: The only thing that really happens after DIF is the auto-syncs from Debian stop
[18:25] <dennis> my question is: Where to put arch dependent libs best, if I don't want to package them themselves, their part of an application
[18:25] <RoAkSoAx> nhandler, what about merging and syncing new upstream versions?
[18:28] <nhandler> RoAkSoAx: Those can continue
[18:28] <RoAkSoAx> nhandler, till when?
[18:29] <masterkernel> I filed a needs-packaging bug on launchpad: 389946 and uploaded the package to revu. now I need 2 Ubuntu developers to sign & review it, correct?
[18:29] <nhandler> RoAkSoAx: It isn't really until FF where you need to start worrying about getting exceptions and stuff like that
[18:30] <RoAkSoAx> nhandler, which is on August 27th?
[18:31] <nhandler> Yes RoAkSoAx
[18:31] <RoAkSoAx> nhandler, and after FF people start concentrating on bug fixing right?
[18:32] <nhandler> RoAkSoAx: Correct. Bug fixes, important changes, and stuff that brings us closer to releasing a great Ubuntu ;)
[18:33] <RoAkSoAx> nhandler, ok cool :) that cleared my doubts
[18:33] <RoAkSoAx> thanks for your help
[18:34] <dennis> *push*: Where to put arch dependent libs best, if I don't want to package them themselves, their part of an application
[18:34] <nhandler> You're welcome RoAkSoAx
[18:36] <dennis> or the other way around, am I allowed to copy libs to /usr/lib or /usr/lib64 in my package wich is not a lib...-package?
[18:39] <hansolo669> hello when i try to bzr push it give me the error:      "bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Emythbuntu-documentation/mythbuntu/documentation/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()"  i have run "bzr launchpad-login callum1234moo-live"(my launch pad name(user name is hansolo669)) and it looks like it workd but then still give the error. i have
[18:43] <hansolo669> changed launch  pad name to hansolo669
[19:10] <dennis> nobody online who knows where to put it and whether I am allowed?
[19:20] <mrooney> any motu want to mentor me for a few minutes on building a nautilus package from a nautilus branch in git? I have the branch checked out, and the apt-get source of nautilus, I'm just not sure how to merge them
[19:24] <nellery> mrooney: here's a MOTU video which details upgrading packages http://www.youtube.com/watch?v=JJzM2LNOtWU
[19:25] <mrooney> nellery: ahh thanks that sounds functionally equivalent perhaps
[19:26] <nellery> mrooney: and words to go along with it https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate
[20:47] <masterkernel> I filed a needs-packaging bug on launchpad: 389946 and uploaded the package to revu. now I need 2 Ubuntu developers to sign & review it, correct?
[20:48] <RainCT> directhex: Hey. Can you take a look at bug #350203?  Seems like it needs /usr/lib/libgdk-x11-2.0.so from libgtk2.0-dev to run, but that doesn't seem right?
[20:49] <RainCT> masterkernel: Yes. Your best chance to get it reviewed quickly is asking here from time to time (but not too often as that would have the opposite effect ;)). Especially on Fridays as then it's "REVU Day".
[20:49] <masterkernel> RainCT: thanks. will you do it? :)
[20:50] <directhex> RainCT, your assessment seems correct. sounds like incorrect use of p/invoke to me
[20:51] <directhex> yTTrayLib.cs:	[DllImport ("gdk-x11-2.0")]
[20:51] <RainCT> masterkernel: As a start, look at the Warnings REVU gives you on http://revu.ubuntuwire.com/p/kernelcheck; also please limit the description of the package to a technical (but understandable) description: it's not the right place to mention whether it's based upon a forum thread or who the authors of the original app are (this later information could go into debian/copyright)
[20:52] <masterkernel> RainCT: thanks, will do
[20:54] <directhex> RainCT, i'll pastebin a fix. too busy to upload myself
[20:54] <RainCT> directhex: great, thanks
[20:55] <directhex> http://paste.ubuntu.com/200266/
[20:56] <RainCT> directhex: Oh, so easy? Thanks!
[20:57] <directhex> RainCT, mono tries a few values for remapping when given a dllimport - but it does NOT try adding a SONAME version
[20:57] <directhex> RainCT, which is why it resolves "gdk-x11-2.0" to "libgdk-x11-2.0.so" but not to "libgdk-x11-2.0.so.0"
[20:58] <directhex> basically "foo" is assumed to be interchangeable with "foo.dll" as per the spec, and mono remaps "foo.dll" to "libfoo.so" automatically
[21:09] <dtchen> superm1: apologies for the delay in answering your e-mail; i'll address some points tomorrow
[21:50] <vadi2> What is the preferred format for ubuntu packages - debhelper or cdbs?
[21:50] <RainCT> vadi2: That depends who you ask.
[21:51] <dtchen> IOW, there is no One Strict Way regardless what anyone tells you.
[21:51] <vadi2> Yeah, that's what has been confusing me. Alright.
[21:57] <alefteris> vadi2, rumors thought have it that dh 7 is the cdbs killer :) just rumors..
[21:58] <vadi2> Where can I find more information about dh 7?
[22:00] <alefteris> dh 7 = debianhelper version 7, don't know where to find docs about it :(
[22:00] <alefteris> debhelper* version 7
[22:00] <Laney> /usr/share/doc/debhelper
[22:00] <fta> man dh
[22:00] <fta> :
[22:00] <fta> :)
[22:15] <kpirc> I am looking for a reviewer for my 'cadabra' package currently on REVU. It's a computer algebra system in C++, including a graphical notebook frontend with mathematics typesetting.
[22:15] <kpirc> Any takers?
[22:21] <kpirc> quiet night...
[22:29] <masterkernel> I am in need a reviewer for 'kernelcheck', a GUI that can auto-build any 2.6 kernel from the upstream source with custom patches, and install it as a deb file.
[22:29] <masterkernel> http://revu.ubuntuwire.com/p/kernelcheck
[22:29] <masterkernel> RainCT: I fixed all those warnings and the description
[22:47] <ripps> Can someone help me, I'm trying to repackage mpd so that it runs under the local user's userspace and not it's own. Apparently there's some permission issues I've discovered in Karmic that's making it impossible for it scan files on an external harddrive mounted by gnome-vfs. I'm trying to create a mpd-userspace package, but I don't know how to make the package startup as the user and not as root service.
[22:49] <RainCT> ripps: and wouldn't it be easier to give the user as which mpd runs permissions to access the files there?
[22:51] <ripps> mpd is capable of being run in the userspace, it has code designed to run that way, but debian has always packaged it as root service, so I want to try and see if I can get to work well as a userspace app. That might even be a preferred method.
[22:51] <ripps> RainCT: ^
[22:52] <ripps> RainCT: also, the issue is because of devkit-disks which seems to mount external harddisks with different permissions.
[22:59] <RainCT> masterkernel: No time to do a complete review now, but I've left some quick comments.
[23:00] <masterkernel> RainCT: thanks, I'll check it out
[23:00] <RainCT> ripps: Oh, so it runs as root? I'd hoped I'd have a system user for itself or something :/
[23:01] <ripps> RainCT: not exactly root runs it as the mpd user, but that means it can't read files mounted as 0700 by devkit-disk
[23:02] <RainCT> ripps: OK, you had scared me :P. So have you tried "sudo adduser mpd devkit-disk"?
[23:02] <RainCT> err nevermind
[23:02] <ripps> Yeah, it because devkit will only allow me, the user who mounted the disk to access it, not mpd
[23:03] <ripps> I should be read/write for me and read for everybody else