| bcurtiswx | quilt edit always says patch is located below debian/patches/ | 01:40 |
|---|---|---|
| bcurtiswx | how do I fix that? | 01:40 |
| ebroder | are you trying to do something like "quilt edit debian/patches/my_new_awesome_patch.patch"? | 01:41 |
| 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:42 |
| bcurtiswx | OK, so it will edit a chunk in a patch? | 01:43 |
| bcurtiswx | ebroder, ^^ | 01:43 |
| ebroder | bcurtiswx: or create a new one as needed | 01:44 |
| bcurtiswx | ebroder, ty | 01:46 |
| bcurtiswx | ebroder, how would I delete a chunk from a patch? | 01:50 |
| bcurtiswx | manually the only way? | 01:52 |
| EagleScreen | I ma trying to create a natty enviroment with pbuilder in Debian testing, I get this: http://pastebin.ca/2039969 | 01:53 |
| EagleScreen | this is my pbuilderrc http://pastebin.ca/2039984 | 01:54 |
| bcurtiswx | EagleScreen, pbuilder-dist natty ? | 01:54 |
| EagleScreen | bcurtiswx: I use sudo DIST=natty pbuilder create | 01:55 |
| EagleScreen | how do I do it in your way? | 01:56 |
| bcurtiswx | do you get the same error with pbuilder-dist natty create ? | 01:56 |
| EagleScreen | yes bcurtiswx, the same | 02:00 |
| bcurtiswx | EagleScreen, could be your pbuiderrc, comment the entire thing out and see if my command works then | 02:04 |
| EagleScreen | bcurtiswx: the DEBOOTSTRAPOPTS= line? | 02:05 |
| bcurtiswx | seems to be where your issues are.. so its a good start | 02:06 |
| EagleScreen | bcurtiswx: the same for your command | 02:09 |
| bcurtiswx | EagleScreen, try commenting out the entire pbuilderrc just to see if it is really something with that in the first place | 02:10 |
| EagleScreen | ok | 02:11 |
| EagleScreen | i will mv it | 02:11 |
| bcurtiswx | EagleScreen, yes, didn't think of that | 02:12 |
| EagleScreen | the same error | 02:13 |
| EagleScreen | :( | 02:15 |
| bcurtiswx | EagleScreen, pastebin plz | 02:15 |
| EagleScreen | here is http://pastebin.ca/2039993 | 02:16 |
| 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:18 |
| 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:19 |
| bcurtiswx | EagleScreen, its ubuntu-keyring | 02:20 |
| bcurtiswx | got it ? | 02:20 |
| EagleScreen | I have installed it | 02:21 |
| EagleScreen | the same problem with sudo pbuilder-dist natty create | 02:21 |
| bcurtiswx | patebin plz | 02:22 |
| EagleScreen | ok -> http://pastebin.ca/2040000 | 02:22 |
| 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:23 |
| EagleScreen | the same happens trying to create a maverick or lucid enviroment | 02:25 |
| bcurtiswx | EagleScreen, you're running as root | 02:26 |
| bcurtiswx | i don't usually | 02:26 |
| 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:27 |
| EagleScreen | if I am not root, I get this: Error: Could not find "pbuilder". | 02:28 |
| bcurtiswx | you have an interesting setup, hmm. not sure how to help you from this point. sorry | 02:29 |
| EagleScreen | thanks anyway | 02:30 |
| ari-tczew | EagleScreen: I have installed debian-archive-keyring, not debian-keyring | 02:32 |
| EagleScreen | I too, i ma installing now debian-keyring | 02:33 |
| EagleScreen | remember that I am trying to create an ubuntu root in a Debian system | 02:34 |
| ari-tczew | EagleScreen: try: sudo pbuilder-dist natty create --debootstrapopts "--keyring=/usr/share/keyrings/debian-archive-keyring.gpg" | 02:36 |
| EagleScreen | same error | 02:37 |
| ari-tczew | so I don't have an idea | 02:38 |
| ari-tczew | EagleScreen: maybe wiki will be helpful for you: https://wiki.ubuntu.com/PbuilderHowto | 02:39 |
| 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:57 |
| ari-tczew | EagleScreen: so problem is fixeD? | 02:59 |
| EagleScreen | yes if I use my old way | 02:59 |
| Legendario | what should i do to package a software which upstream only releases the source as a zip package | 04:43 |
| Legendario | ? | 04:43 |
| micahg | Legendario: you can repack as tar.gz | 04:44 |
| Legendario | micahg, thanks | 04:48 |
| Legendario | :-) | 04:48 |
| micahg | Legendario: you should make a get-orig-source rule to do it | 04:49 |
| Legendario | micahg, how do i do that? | 04:50 |
| 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:03 |
| Legendario | thanks micahg | 05:04 |
| Legendario | micahg, do you have an example with cdbs | 05:05 |
| Legendario | ? | 05:05 |
| micahg | Legendario: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball | 05:08 |
| micahg | http://cdbs-doc.duckcorp.org/en/cdbs-doc.xhtml#id392217 | 05:10 |
| dholbach | good morning | 07:22 |
| === ara_ is now known as ara | ||
| === yofel_ is now known as yofel | ||
| 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:26 |
| 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:29 |
| batronix | thank you. I'll take a look at debhelper. | 11:31 |
| 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:43 |
| 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:45 |
| 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:48 |
| 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:52 |
| 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:53 |
| 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:55 |
| mok0 | My problem is that there are differences between upstream's bzr tree and the tarball that can be produced using "make dist" | 12:56 |
| 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:57 |
| akheron | mok0: can't you repack the upstream's bzr tree as the orig.tar.gz? | 12:58 |
| mok0 | akheron: yes I could | 12:58 |
| mok0 | akheron: I will probably have to do that | 12:59 |
| mok0 | akheron: but it just illustrates how the tools work at cross-purposes | 12:59 |
| mok0 | akheron: and doing it that way means I have to extract the version number from configure.in | 13:02 |
| mok0 | grr | 13:02 |
| akheron | but if you're packaging software that releases tarballs, why do you want to use the code in their bzr repo? | 13:06 |
| 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:07 |
| 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:08 |
| === Quintasan_ is now known as Quintasan | ||
| === gnomelogger is now known as markeylogger | ||
| mok0 | akheron: they are not releasing tarballs | 13:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| === markeylogger is now known as apachelogger | ||
| 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:27 |
| akheron | what versions do you have with libtool? | 13:28 |
| akheron | how can you bootstrap the autotools if there are problems with libtool? | 13:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| mok0 | akheron: ... I think that is rather typical if you include the generated files in the repo | 13:34 |
| 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:35 |
| 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:36 |
| mok0 | akheron: anyway, thanks for the ping-pong. I am more relaxed now :-) | 13:37 |
| akheron | np :) | 13:37 |
| 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. | 13:41 |
| BlackZ | ScottK: hello, can you please have a look at bug #697844 if you have time? | 14:04 |
| ubottu | Launchpad bug 697844 in maverick-backports "Please backport amsn 0.98.4-0ubuntu1 from Natty" [Undecided,New] https://launchpad.net/bugs/697844 | 14:04 |
| ScottK | Sure | 14:04 |
| BlackZ | ScottK: thanks :) | 14:04 |
| ScottK | Done | 14:08 |
| === hanska is now known as dapal | ||
| === leagris is now known as virtuald | ||
| evaluate | hello dapal :-) | 18:58 |
| 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:51 |
| evaluate | awesome. I'll read it right now. | 19:55 |
| evaluate | dapal, could I PM you for a minute? | 20:10 |
| dapal | yup | 20:10 |
| 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:20 |
| 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:21 |
| 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 | 20:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!