=== Logan_ is now known as Guest85790
=== Logan__ is now known as Logan_
=== Guest85790 is now known as Logan_
=== Logan_ is now known as Guest12
=== Guest88453 is now known as Logan_
=== Logan_ is now known as Guest11294
=== Logan__ is now known as Logan_
[07:09] <dholbach> good morning
=== huats_ is now known as huats
[20:29] <Legendario> hi. I'm trying to package a software and I'm having the following error. I have no clue about how to solve it: bzr: ERROR: Unable to find the needed upstream tarball for package
=== Guest12 is now known as Logan_
[20:30] <Legendario> the orig.tar.gz package is right above on the directory
[20:35] <Legendario> anyone can help?
[20:35] <Legendario> those are my first attempts to create a package
[20:41] <jtaylor> Legendario: probably its looking in ../tarballs
[20:43] <Legendario> jtaylor, should i create such a directory and copy the tarball to this place?
[20:43] <jtaylor> yes
[20:45] <Legendario> jtaylor, let me try it :-)
[20:48] <Legendario> jtaylor, now I got another error... bzr: ERROR: Not a branch: "/home/kemel/devel/debian-packages/dukto/".
[20:48] <Legendario> :-(
[20:51] <Legendario> jtaylor, no... same error. I was in the wrong directory
[20:52] <jtaylor> is the file named correctly?
[20:52] <jtaylor> version number the same
[20:56] <Legendario> jtaylor, yes... I guess it was that
[20:57] <Legendario> jtaylor, thanks. I'll try to go ahead here
[21:12] <mfisch> Legendario: are you using bzr-buildpackage?
[21:24] <Legendario> mfisch, sim
[21:25] <Legendario> mfisch, yes
[21:25] <mfisch> sorry I don't know what sim is
[21:26] <mfisch> but if you are using bzr-buildpackage you need to do it from your bzr tree, thats the second error
[21:26] <mfisch> that command rebuilds the .orig so I thought
[21:30] <Legendario> thanks guys
[21:30] <Legendario> gotta leave
[21:52] <alo21> hi..crtools has been built for 64 bit arch only...
[21:53] <alo21> now I am going to merge/sync it, and my questions is: Is ok if I built crtools only for 64 bit (32 bit failed)?
[21:57] <jtaylor> its amd64 only
[21:57] <jtaylor> I'd wait until the new version is in unstable
[21:57] <jtaylor> I doubt it works with the raring kernel anyway
[21:58] <jtaylor> hm interesting, it does not need kernel support
[21:59] <alo21> jtaylor, how much time does import from experimental take?
[22:00] <jtaylor> ask the maintainer
[22:00] <jtaylor> its probably in experimental for a reason
[22:00] <jtaylor> its early enough in the cycle so we can just wait
[22:02] <jtaylor> also you again picked an incredible complicated package
[22:02] <jtaylor> you have a nack for that
[22:02] <jtaylor> (the packaging might be simple, didn't check, but the functionality is non trivial)
[22:05] <alo21> wow... that's incredible.... anyway thanks.
[22:25] <jtaylor> Logan_: will you merge gevent soon?
[22:26] <Logan_> jtaylor: It appears to be synced with Debian, no?
[22:27] <jtaylor> oh
[22:27] <jtaylor> why is my autoppkgtest still failing then :O
[22:27] <Logan_> Oh, because of a bug I reported. D'oh.
[22:27] <Logan_> https://bugs.launchpad.net/ubuntu/+source/python-gevent/+bug/1181942
[22:27] <ubottu> Launchpad bug 1181942 in python-gevent (Ubuntu) "Sync python-gevent 0.13.7-4 (main) from Debian unstable (main)" [Wishlist,Fix released]
[22:27] <Logan_> I do way too much syncing and merging for my own good. :P
[22:27] <jtaylor> ok its jsut autopkgtest bugging out
[22:27] <jtaylor> all tests pass
[22:28] <jtaylor> s/autopkgtest/jenkins/
[22:28] <Logan_> Oh, cool.