[01:40] <bcurtiswx> quilt edit always says patch is located below debian/patches/
[01:40] <bcurtiswx> how do I fix that?
[01:41] <ebroder> are you trying to do something like "quilt edit debian/patches/my_new_awesome_patch.patch"?
[01:42] <nomadium> bcurtiswx: with QUILT_PATCHES env var?
[01:42] <bcurtiswx> ebroder, yes.  i have it pushed to that patch, and am trying to quilt edit
[01:42] <bcurtiswx> yes i have that in my .bashrc
[01:42] <ebroder> bcurtiswx: you use quilt edit to edit files in a patch. you use quilt create to make a new patch
[01:42] <ebroder> bcurtiswx: quilt automatically works on the last patch that you pushed
[01:43] <bcurtiswx> OK, so it will edit a chunk in a patch?
[01:43] <bcurtiswx> ebroder, ^^
[01:44] <ebroder> bcurtiswx: or create a new one as needed
[01:46] <bcurtiswx> ebroder, ty
[01:50] <bcurtiswx> ebroder, how would I delete a chunk from a patch?
[01:52] <bcurtiswx> manually the only way?
[01:53] <EagleScreen> I ma trying to create a natty enviroment with pbuilder in Debian testing, I get this: http://pastebin.ca/2039969
[01:54] <EagleScreen> this is my pbuilderrc http://pastebin.ca/2039984
[01:54] <bcurtiswx> EagleScreen, pbuilder-dist natty ?
[01:55] <EagleScreen> bcurtiswx: I use sudo DIST=natty pbuilder create
[01:56] <EagleScreen> how do I do it in your way?
[01:56] <bcurtiswx> do you get the same error with pbuilder-dist natty create ?
[02:00] <EagleScreen> yes bcurtiswx, the same
[02:04] <bcurtiswx> EagleScreen, could be your pbuiderrc, comment the entire thing out and see if my command works then
[02:05] <EagleScreen> bcurtiswx: the DEBOOTSTRAPOPTS= line?
[02:06] <bcurtiswx> seems to be where your issues are.. so its a good start
[02:09] <EagleScreen> bcurtiswx: the same for your command
[02:10] <bcurtiswx> EagleScreen, try commenting out the entire pbuilderrc just to see if it is really something with that in the first place
[02:11] <EagleScreen> ok
[02:11] <EagleScreen> i will mv it
[02:12] <bcurtiswx> EagleScreen, yes, didn't think of that
[02:13] <EagleScreen> the same error
[02:15] <EagleScreen> :(
[02:15] <bcurtiswx> EagleScreen, pastebin plz
[02:16] <EagleScreen> here is http://pastebin.ca/2039993
[02:18] <ari-tczew> EagleScreen: have you got installed debian-archive-keyring ?
[02:18] <EagleScreen> will check it, but shouldn't I need ubuntu-archive-keyring?
[02:18] <EagleScreen> debian-archive-keyring is installed
[02:19] <bcurtiswx> EagleScreen, is the ubuntu one installed?
[02:19] <EagleScreen> ubuntu-archive-keyring (or ubuntu-keyring) isn't because it is not packaged in Debian
[02:19] <EagleScreen> do I need it?
[02:19] <EagleScreen> I can install it
[02:20] <bcurtiswx> EagleScreen, its ubuntu-keyring
[02:20] <bcurtiswx> got it ?
[02:21] <EagleScreen> I have installed it
[02:21] <EagleScreen> the same problem with sudo pbuilder-dist natty create
[02:22] <bcurtiswx> patebin plz
[02:22] <EagleScreen> ok -> http://pastebin.ca/2040000
[02:23] <bcurtiswx> hmm, whats the version of the key ?
[02:23] <EagleScreen> i have installed this one -> http://packages.ubuntu.com/natty/all/ubuntu-keyring/download
[02:25] <EagleScreen> the same happens trying to create a maverick or lucid enviroment
[02:26] <bcurtiswx> EagleScreen, you're running as root
[02:26] <bcurtiswx> i don't usually
[02:27] <EagleScreen> I always run pbuilder as root as the root tar.gz are stored out of home
[02:27] <EagleScreen> sudo DIST=natty pbuilder create needs to be run as root
[02:28] <EagleScreen> if I am not root, I get this: Error: Could not find "pbuilder".
[02:29] <bcurtiswx> you have an interesting setup, hmm.  not sure how to help you from this point. sorry
[02:30] <EagleScreen> thanks anyway
[02:32] <ari-tczew> EagleScreen: I have installed debian-archive-keyring, not debian-keyring
[02:33] <EagleScreen> I too, i ma installing now debian-keyring
[02:34] <EagleScreen> remember that I am trying to create an ubuntu root in a Debian system
[02:36] <ari-tczew> EagleScreen: try:  sudo pbuilder-dist natty create --debootstrapopts "--keyring=/usr/share/keyrings/debian-archive-keyring.gpg"
[02:37] <EagleScreen> same error
[02:38] <ari-tczew> so I don't have an idea
[02:39] <ari-tczew> EagleScreen: maybe wiki will be helpful for you: https://wiki.ubuntu.com/PbuilderHowto
[02:57] <EagleScreen> I was using '--keyring' '/usr/share/keyrings/ubuntu-archive-keyring.gpg'  and the right option is "--keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg" in .pbuilderrc, not it works, but  sudo pbuilder-dist natty create --debootstrapopts "--keyring=/usr/share/keyrings/debian-archive-keyring.gpg" doesn't
[02:59] <ari-tczew> EagleScreen: so problem is fixeD?
[02:59] <EagleScreen> yes if I use my old way
[04:43] <Legendario> what should i do to package a software which upstream only releases the source as a zip package
[04:43] <Legendario> ?
[04:44] <micahg> Legendario: you can repack as tar.gz
[04:48] <Legendario> micahg, thanks
[04:48] <Legendario> :-)
[04:49] <micahg> Legendario: you should make a get-orig-source rule to do it
[04:50] <Legendario> micahg, how do i do that?
[05:03] <micahg> Legendario: here's an example for svn http://wiki.debian.org/SandroTosi/Svn_get-orig-source, you just need to replace the svn checkout bits with code to download the .zip file and decompress it
[05:04] <Legendario> thanks micahg
[05:05] <Legendario> micahg, do you have an example with cdbs
[05:05] <Legendario> ?
[05:08] <micahg> Legendario: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball
[05:10] <micahg> http://cdbs-doc.duckcorp.org/en/cdbs-doc.xhtml#id392217
[07:22] <dholbach> good morning
[11:26] <batronix> I've put a changelog file into the DEBIAN folder of my package and get a "W: ... unknown-control-file changelog" from lintian
[11:29] <akheron> batronix: changelog doesn't go to DEBIAN, it goes to /usr/share/doc/yourpkg/
[11:29] <akheron> you shouldn't copy these files by hand, use debhelper instead
[11:31] <batronix> thank you. I'll take a look at debhelper.
[12:43] <mok0> Jeez I am having a hell of a time trying to build a source package under bzr control
[12:43] <mok0> this close to giving up on bzr
[12:45] <mok0> I wish there was a source package format where you could define what you want to go in there and not rely on debuilds flawed logic
[12:48] <Bachstelze> I've never worked bith bzr really but yeah, I'm not particularly eager to try
[12:48] <Bachstelze> It really seems like just overhead to me
[12:52] <mok0> Bachstelze: it is a convinient way to keep track of your changes
[12:52] <Bachstelze> meh
[12:52] <Bachstelze> debian/changelog is good enough for me
[12:52] <mok0> But a.t.m. we have a whole range of tools and they are all getting on each other's toes
[12:53] <Bachstelze> often I have just skipped over a package that I could have fixed because I don't really have the time to figure out how bzr works
[12:53] <mok0> Bachstelze: yeah it's a problem
[12:55] <mok0> Bachstelze: It would be very convienient, because you can check out and unpack the sources very easily. The really really dumb thing is that you _still_ need an .orig.tar.gz tarball like before.
[12:55] <mok0> So why doesn
[12:55] <mok0> t dpkg-buildpackage just check out the sources from bazaar instead of unpacking the tarball???
[12:56] <mok0> My problem is that there are differences between upstream's bzr tree and the tarball that can be produced using "make dist"
[12:57] <mok0> so dpkg-buildpackage tries to represent those differences, but they are _meaningless_
[12:57] <mok0> If there was at least some way to say: only represent diffs in debian/ ignore the resst
[12:58] <akheron> mok0: can't you repack the upstream's bzr tree as the orig.tar.gz?
[12:58] <mok0> akheron: yes I could
[12:59] <mok0> akheron: I will probably have to do that
[12:59] <mok0> akheron: but it just illustrates how the tools work at cross-purposes
[13:02] <mok0> akheron: and doing it that way means I have to extract the version number from configure.in
[13:02] <mok0> grr
[13:06] <akheron> but if you're packaging software that releases tarballs, why do you want to use the code in their bzr repo?
[13:07] <akheron> if they were using git, would you use git-buildpackage?
[13:07] <akheron> why don't you use your own favorite tool and the tarball?
[13:08] <akheron> at least git-buildpackage supports working with the upstream tarballs so that your debian changes live in a different branch and when a new upstream version is released, you import it to your _packaging_ tree and merge accordingly
[13:08] <akheron> the packaging git tree is completely separate from the upstream source tree
[13:21] <mok0> akheron: they are not releasing tarballs
[13:22] <akheron> ah
[13:22] <mok0> akheron: but it's a gnu autotools project, so the easiest way to do it is to do "make dist"
[13:22] <akheron> so won't your bzr tool do an upstream tarball for you then, without using make dist?
[13:22] <akheron> at least git-buildpackage does
[13:22] <akheron> it just takes the sources
[13:22] <mok0> akheron: perhaps it can do that
[13:23] <akheron> mok0: if it's an autotools project you should not ship ./configure or any generated stuff in the tarball
[13:23] <akheron> and run autoreconf -f -i as the first thing when building
[13:23] <mok0> akheron: well, yes, but...
[13:23] <akheron> and depend on autoconf, automake and libtool (or whatever is needeD)
[13:23] <mok0> that's not the autotools way
[13:23] <akheron> it's the debian way if there are no tarballs
[13:23] <akheron> (I think)
[13:24] <mok0> akheron: make dist creates all you need to build the package, on ANY system
[13:24] <akheron> so does "autoreconf -f -i; ./configure"
[13:24] <mok0> akheron: true :-)
[13:24] <mok0> akheron: I am doing that anyway :-)
[13:25] <akheron> I've been struggling with this myself
[13:25] <mok0> akheron: ... because upstream's version of libtool is causing problems
[13:25] <mok0> *sigh*
[13:25] <akheron> well, that's a different problem then :)
[13:25] <mok0> akheron: my problem is getting bzr-builddeb to *run* in the first place
[13:27] <mok0> akheron: which it doesn't because it complains about a whole bunch of changes that can't be represented in diff... changes which I don't _care_ about.
[13:28] <akheron> what versions do you have with libtool?
[13:28] <akheron> how can you bootstrap the autotools if there are problems with libtool?
[13:29] <mok0> akheron: it seems the ltmain.sh shipped in the bzr repo is out-of-sync versionwise with some of the other tools...
[13:29] <mok0> akheron: autoreconf -i -f fixes that
[13:29] <akheron> why do they ship ltmain.sh?
[13:29] <akheron> are there other generated files in the bzr repo too?
[13:29] <mok0> akheron: don't know
[13:30] <mok0> akheron: afair, yes
[13:30] <akheron> sigh
[13:30] <akheron> :)
[13:30] <mok0> akheron: *sigh*
[13:30] <akheron> do they depend on a certain version of some of these tools?
[13:30] <mok0> akheron: I think the tools depend on the right versions of each other...
[13:31] <akheron> yes but does the project require a specific version of e.g. libtool to build at all?
[13:31] <akheron> or something like that
[13:32] <mok0> akheron: no, I don't think so... I got an error message at some point... can't remember the exact circumstances... I just fixed it using -f -i
[13:33] <mok0> akheron: I just continued with that and didn't do a post-mortem
[13:33] <akheron> well, if autoreconf makes it work, why don't you just run autoreconf on build and be happy with a tarball that contains only the stuff in the bzr tree?
[13:33] <mok0> akheron: it's definitely an option
[13:33] <akheron> that would *not* work only if they required a specific version of some of the tools
[13:33] <akheron> and that specific version is not available for ubuntu/debian
[13:33] <mok0> akheron: they don't
[13:34] <mok0> akheron: ... I think that is rather typical if you include the generated files in the repo
[13:35] <mok0> because then, if upstream is ahead of you in terms of system upgrading, you are in trouble
[13:35] <akheron> you mean they use never versions of the tools than you have available?
[13:35] <mok0> akheron: yes
[13:35] <mok0> akheron: newer macros and so on
[13:36] <akheron> then you should get a "make dist" tarball on a system that has the new tools and not use the upstream bzr at all
[13:36] <mok0> akheron: indeed
[13:37] <mok0> akheron: anyway, thanks for the ping-pong. I am more relaxed now :-)
[13:37] <akheron> np :)
[13:41] <akoskm> Hi! How can I modify the java.library.path while I'm installing my package? I have precompiled native libraries (by ant) what I want to include their directory in java.library.path.
[14:04] <BlackZ> ScottK: hello, can you please have a look at bug #697844 if you have time?
[14:04] <ScottK> Sure
[14:04] <BlackZ> ScottK: thanks :)
[14:08] <ScottK> Done
[18:58] <evaluate> hello dapal :-)
[19:51] <dapal> evaluate: moo :)
[19:51] <dapal> evaluate: I just replied to your mail -- I read it before today, but I was quite tired, so I delayed it to tonight ;)
[19:55] <evaluate> awesome. I'll read it right now.
[20:10] <evaluate> dapal, could I PM you for a minute?
[20:10] <dapal> yup
[20:20] <tumbleweed> what actually is our policy on maintainer e-mail addresses for ubuntu-only packages? I see many REVU packages using ubuntu-developers as the maintainers, with the original packager as XBSC-O-M.
[20:21] <tumbleweed> bdrung's recent update-maintainer change sets ubuntu-developers if the maintainer doesn't end in @ubuntu.com, is that the best approximation to our policy?
[20:37] <siloxid> has there been any word recently of the ubuntu app center taking paid apps?  it seems like it was there for a short time and then got taken down