[12:15] <belkinsa>  Okay, my Ubuntu address is working again.  Thank you for the help
[16:08] <ybon> hi :)
[16:09] <ybon> Anyone using dh_virtualenv to build packages on launchpad? I've an error when dh_virtualenv try to fetch the python package, like if there is not Internet connection, so I may be missing a point
[16:09] <ybon> https://launchpadlibrarian.net/203371551/buildlog_ubuntu-trusty-amd64.addok_0.1.0-7_BUILDING.txt.gz for more details
[16:09] <wgrant> ybon: Launchpad builders can't connect to the Internet.
[16:10] <ybon> makes sense
[16:10] <ybon> but then any way to use dh_virtualenv?
[16:10] <ybon> like uploading the python package by hand
[16:10] <wgrant> I don't know what that is, but from the name I would suspect not.
[16:10] <wgrant> You need to either include your dependencies in your package, or specify them as packages in your Build-Depends field.
[16:11] <ybon> (http://dh-virtualenv.readthedocs.org/)
[16:11] <ybon> ok
[16:11] <dobey> you should probably package them properly in your ppa, if they are not already in ubuntu
[16:11] <ybon> I'm totally dumb in packaging, so I may be missing a point, but for what I understand dh_virtualenv try to dl the packages at build time
[16:12] <ybon> dobey: the idea of dh_virtualenv is not to need to repackage python packages :)
[16:12] <dobey> it's not virtualenv, but setuptools will do that as well
[16:12] <dobey> ybon: dh_virtualenv is an oxymoron then :)
[16:12] <ybon> hehe
[16:12] <wgrant> Sensible Debian packages build only using other packages.
[16:13] <dobey> exactly
[16:13] <ybon> yeah, I understand that
[16:13] <ybon> but mine is not sensible ;)
[16:13] <ybon> I just want to make it easier for people on Ubuntu to install the app I'm working on
[16:13] <dobey> having a tool for building python packages that is designed expressly not to use packages, is not sensible
[16:13] <ybon> but I'd prefer not to need to repackages every python dep
[16:14] <ybon> designed to use python packages ;)
[16:14] <dobey> how many python deps do you have which aren't packaged in ubuntu already?
[16:14] <ybon> I mean, building the .deb works perfectly, on local
[16:14] <ybon> good question :)
[16:14] <ybon> Let me check
[16:14] <dobey> "perfectly"
[16:14] <ybon> I confirm :)
[16:14] <ybon> I can build it and install it on my server ;)
[16:17] <dobey> sure, it appears to work for you. i wasn't questioning that. just that "perfectly" is a rather strong statement, particularly when you're doing something completely antithetical to debian packaging :)
[16:17] <ybon> ok, I remove "perfectly" from my statment, you won :)
[16:20] <ybon> so 1 package is missing, 5 are not up to date
[16:20] <dobey> besides, making debian packages of python libraries is generally pretty trivial
[16:21] <ybon> but I may consider using those versions anyway
[16:21] <dobey> on what version of ubuntu? and what packages?
[16:21] <ybon> only targetting LTS, so Precise and Trusty
[16:21] <ybon> the app I'm trying to package is https://github.com/etalab/addok
[16:22] <ybon> again, I'm totally new on Debian/Ubuntu packaging, so making my own pooding at the moment to try to eat something every day ;)
[16:28] <dobey> well, i don't know which one is missing. they all seem to be available
[16:28] <ybon> I don't see ngram
[16:28] <dobey> docopt and werkzeug can be backported easily from a newer release it seems; the others are all still older versions than you list in requirements.txt
[16:29] <dobey> oh right, ngram was missing, indeed
[16:30] <dobey> i think the "==" dependencies you have is a bit odd too
[16:30] <dobey> generally, you'd want >=
[16:32] <ybon> depends on the habit, I prefer to control them and to have requirements to warn me when I need to upgrade
[16:32] <ybon> anyway, seems I need to review my plans ;)
[16:33] <ybon> thanks for the assistance in seeying the reality :)
[16:33] <dobey> if you want to have more control over dependency versions like that and use your app inside virtualenv, then your best option is probably to just ship your tarball on pypi, and tell people to install it with virtualenv that way, rather than using debian packaging
[16:34] <dobey> so that people can set up a virtualenv container specific to your app
[16:35] <ybon> yep
[16:35] <ybon> I loved the idea of a Ubuntu package too, but it's a bit more work than just adding dh_virtualenv and having it automagically
[16:36] <ybon> dealing with virtualenv is still a bit messy for people not used to python ecosystem
[16:37] <ybon> so having an easier Ubuntu LTS copy-paste to deploy is a nice to have :)
[16:40] <dobey> well, if you need specific versions of python packages, it's going to be a problem, because those will change
[16:42] <ybon> well, this one is not really a strong need
[16:43] <dobey> it very rarely is :)
[16:44] <dobey> i can maybe help get some packages updated in a ppa if you need help with that, but i'm generally pretty short on time, and am doing actual work right now :)
[16:45] <ybon> thanks :)
[16:46] <ybon> I'm considering my options right now ;)
[16:46] <ybon> python-ngram
[16:47] <ybon> python-ngram seems not active, so it means that if I make a package, I will need to maintain it
[16:47] <ybon> which step I'm not sure I should do
[16:47] <ybon> being also pretty short in time, like all of us ;)
[16:55] <dobey> if upstream ngram is no longer active, then maybe you shouldn't use it :)
[16:57] <ybon> héhé ;)
[21:11] <KaZeR> hey there. Everytime i upload a .pot file, it ends up in "Need review". When reviewing it, I do not see why it isn't automatically processed. can someone help?
[21:56] <ki7mt> Hello all, I have project that is on SF right now, and want bring most of it over to LP for a new Ubuntu package. Must I create a new LP account and everything that goes with it or can I run it from my personal account on LP?
[21:57] <beuno> ki7mt, hi
[21:57] <beuno> you would create a team
[21:57] <beuno> and own that team yourself
[21:57] <dobey> you can do it personally, via a team, or as a new account
[21:57] <beuno> but that would disconnect it from you personally, and allow others to jump in
[21:57] <dobey> a team is generally the best way to do things
[21:58] <ki7mt> Ok, that sounds good, I'll read up on the team route. Thanks.
[22:01] <wgrant> ki7mt: You'd usually create a team at https://launchpad.net/people/+newteam, then a project owned by that team at https://launchpad.net/projects/+new
[22:04] <ki7mt> wgrant, ok, that seems logical. So then, users added to the team would also be part of the project yes?
[22:05] <beuno> yes
[22:05] <ki7mt> Ok, thanks. will read up a bit more before I dive it :-)
[22:05] <ki7mt> .. dive in ..
[22:12] <cjwatson> And in general it's pretty rare to need a new account.
[22:21] <dobey> yeah, usually the reason to create a new account would be to create a bot, which you add to a team, that uses the API to perform various things (like using tarmac to manage branch landings)
[22:21] <dobey> anyway, i am gone. later :)
[22:26] <mapreri> ki7mt: you might want to experiment thinks in staging.launchpad.net
[22:44] <ki7mt> mapreri, yes, thanks, I was thinking the same thing after reading about both teams and projects.