[01:40] quilt edit always says patch is located below debian/patches/ [01:40] how do I fix that? [01:41] are you trying to do something like "quilt edit debian/patches/my_new_awesome_patch.patch"? [01:42] bcurtiswx: with QUILT_PATCHES env var? [01:42] ebroder, yes. i have it pushed to that patch, and am trying to quilt edit [01:42] yes i have that in my .bashrc [01:42] bcurtiswx: you use quilt edit to edit files in a patch. you use quilt create to make a new patch [01:42] bcurtiswx: quilt automatically works on the last patch that you pushed [01:43] OK, so it will edit a chunk in a patch? [01:43] ebroder, ^^ [01:44] bcurtiswx: or create a new one as needed [01:46] ebroder, ty [01:50] ebroder, how would I delete a chunk from a patch? [01:52] manually the only way? [01:53] I ma trying to create a natty enviroment with pbuilder in Debian testing, I get this: http://pastebin.ca/2039969 [01:54] this is my pbuilderrc http://pastebin.ca/2039984 [01:54] EagleScreen, pbuilder-dist natty ? [01:55] bcurtiswx: I use sudo DIST=natty pbuilder create [01:56] how do I do it in your way? [01:56] do you get the same error with pbuilder-dist natty create ? [02:00] yes bcurtiswx, the same [02:04] EagleScreen, could be your pbuiderrc, comment the entire thing out and see if my command works then [02:05] bcurtiswx: the DEBOOTSTRAPOPTS= line? [02:06] seems to be where your issues are.. so its a good start [02:09] bcurtiswx: the same for your command [02:10] EagleScreen, try commenting out the entire pbuilderrc just to see if it is really something with that in the first place [02:11] ok [02:11] i will mv it [02:12] EagleScreen, yes, didn't think of that [02:13] the same error [02:15] :( [02:15] EagleScreen, pastebin plz [02:16] here is http://pastebin.ca/2039993 [02:18] EagleScreen: have you got installed debian-archive-keyring ? [02:18] will check it, but shouldn't I need ubuntu-archive-keyring? [02:18] debian-archive-keyring is installed [02:19] EagleScreen, is the ubuntu one installed? [02:19] ubuntu-archive-keyring (or ubuntu-keyring) isn't because it is not packaged in Debian [02:19] do I need it? [02:19] I can install it [02:20] EagleScreen, its ubuntu-keyring [02:20] got it ? [02:21] I have installed it [02:21] the same problem with sudo pbuilder-dist natty create [02:22] patebin plz [02:22] ok -> http://pastebin.ca/2040000 [02:23] hmm, whats the version of the key ? [02:23] i have installed this one -> http://packages.ubuntu.com/natty/all/ubuntu-keyring/download [02:25] the same happens trying to create a maverick or lucid enviroment [02:26] EagleScreen, you're running as root [02:26] i don't usually [02:27] I always run pbuilder as root as the root tar.gz are stored out of home [02:27] sudo DIST=natty pbuilder create needs to be run as root [02:28] if I am not root, I get this: Error: Could not find "pbuilder". [02:29] you have an interesting setup, hmm. not sure how to help you from this point. sorry [02:30] thanks anyway [02:32] EagleScreen: I have installed debian-archive-keyring, not debian-keyring [02:33] I too, i ma installing now debian-keyring [02:34] remember that I am trying to create an ubuntu root in a Debian system [02:36] EagleScreen: try: sudo pbuilder-dist natty create --debootstrapopts "--keyring=/usr/share/keyrings/debian-archive-keyring.gpg" [02:37] same error [02:38] so I don't have an idea [02:39] EagleScreen: maybe wiki will be helpful for you: https://wiki.ubuntu.com/PbuilderHowto [02:57] 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] EagleScreen: so problem is fixeD? [02:59] yes if I use my old way [04:43] what should i do to package a software which upstream only releases the source as a zip package [04:43] ? [04:44] Legendario: you can repack as tar.gz [04:48] micahg, thanks [04:48] :-) [04:49] Legendario: you should make a get-orig-source rule to do it [04:50] micahg, how do i do that? [05:03] 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] thanks micahg [05:05] micahg, do you have an example with cdbs [05:05] ? [05:08] Legendario: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball [05:10] http://cdbs-doc.duckcorp.org/en/cdbs-doc.xhtml#id392217 [07:22] good morning === ara_ is now known as ara === yofel_ is now known as yofel [11:26] 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] batronix: changelog doesn't go to DEBIAN, it goes to /usr/share/doc/yourpkg/ [11:29] you shouldn't copy these files by hand, use debhelper instead [11:31] thank you. I'll take a look at debhelper. [12:43] Jeez I am having a hell of a time trying to build a source package under bzr control [12:43] this close to giving up on bzr [12:45] 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] I've never worked bith bzr really but yeah, I'm not particularly eager to try [12:48] It really seems like just overhead to me [12:52] Bachstelze: it is a convinient way to keep track of your changes [12:52] meh [12:52] debian/changelog is good enough for me [12:52] But a.t.m. we have a whole range of tools and they are all getting on each other's toes [12:53] 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] Bachstelze: yeah it's a problem [12:55] 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] So why doesn [12:55] t dpkg-buildpackage just check out the sources from bazaar instead of unpacking the tarball??? [12:56] My problem is that there are differences between upstream's bzr tree and the tarball that can be produced using "make dist" [12:57] so dpkg-buildpackage tries to represent those differences, but they are _meaningless_ [12:57] If there was at least some way to say: only represent diffs in debian/ ignore the resst [12:58] mok0: can't you repack the upstream's bzr tree as the orig.tar.gz? [12:58] akheron: yes I could [12:59] akheron: I will probably have to do that [12:59] akheron: but it just illustrates how the tools work at cross-purposes [13:02] akheron: and doing it that way means I have to extract the version number from configure.in [13:02] grr [13:06] but if you're packaging software that releases tarballs, why do you want to use the code in their bzr repo? [13:07] if they were using git, would you use git-buildpackage? [13:07] why don't you use your own favorite tool and the tarball? [13:08] 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] the packaging git tree is completely separate from the upstream source tree === Quintasan_ is now known as Quintasan === gnomelogger is now known as markeylogger [13:21] akheron: they are not releasing tarballs [13:22] ah [13:22] akheron: but it's a gnu autotools project, so the easiest way to do it is to do "make dist" [13:22] so won't your bzr tool do an upstream tarball for you then, without using make dist? [13:22] at least git-buildpackage does [13:22] it just takes the sources [13:22] akheron: perhaps it can do that [13:23] mok0: if it's an autotools project you should not ship ./configure or any generated stuff in the tarball [13:23] and run autoreconf -f -i as the first thing when building [13:23] akheron: well, yes, but... [13:23] and depend on autoconf, automake and libtool (or whatever is needeD) [13:23] that's not the autotools way [13:23] it's the debian way if there are no tarballs [13:23] (I think) [13:24] akheron: make dist creates all you need to build the package, on ANY system [13:24] so does "autoreconf -f -i; ./configure" [13:24] akheron: true :-) [13:24] akheron: I am doing that anyway :-) [13:25] I've been struggling with this myself [13:25] akheron: ... because upstream's version of libtool is causing problems [13:25] *sigh* [13:25] well, that's a different problem then :) [13:25] akheron: my problem is getting bzr-builddeb to *run* in the first place === markeylogger is now known as apachelogger [13:27] 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] what versions do you have with libtool? [13:28] how can you bootstrap the autotools if there are problems with libtool? [13:29] akheron: it seems the ltmain.sh shipped in the bzr repo is out-of-sync versionwise with some of the other tools... [13:29] akheron: autoreconf -i -f fixes that [13:29] why do they ship ltmain.sh? [13:29] are there other generated files in the bzr repo too? [13:29] akheron: don't know [13:30] akheron: afair, yes [13:30] sigh [13:30] :) [13:30] akheron: *sigh* [13:30] do they depend on a certain version of some of these tools? [13:30] akheron: I think the tools depend on the right versions of each other... [13:31] yes but does the project require a specific version of e.g. libtool to build at all? [13:31] or something like that [13:32] 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] akheron: I just continued with that and didn't do a post-mortem [13:33] 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] akheron: it's definitely an option [13:33] that would *not* work only if they required a specific version of some of the tools [13:33] and that specific version is not available for ubuntu/debian [13:33] akheron: they don't [13:34] akheron: ... I think that is rather typical if you include the generated files in the repo [13:35] because then, if upstream is ahead of you in terms of system upgrading, you are in trouble [13:35] you mean they use never versions of the tools than you have available? [13:35] akheron: yes [13:35] akheron: newer macros and so on [13:36] 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] akheron: indeed [13:37] akheron: anyway, thanks for the ping-pong. I am more relaxed now :-) [13:37] np :) [13:41] 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] ScottK: hello, can you please have a look at bug #697844 if you have time? [14:04] Launchpad bug 697844 in maverick-backports "Please backport amsn 0.98.4-0ubuntu1 from Natty" [Undecided,New] https://launchpad.net/bugs/697844 [14:04] Sure [14:04] ScottK: thanks :) [14:08] Done === hanska is now known as dapal === leagris is now known as virtuald [18:58] hello dapal :-) [19:51] evaluate: moo :) [19:51] 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] awesome. I'll read it right now. [20:10] dapal, could I PM you for a minute? [20:10] yup [20:20] 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] 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] 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