[08:03] <\sh> why do answers in "Open" state expire after 15 days? (because of no activity is not a good statement)
[08:04] <\sh> and how can someone change this state again to "Open" or "not expired"?
[08:21]  * AlanBell is struggling with daily builds
[08:35] <wgrant> AlanBell: What's the issue?
[08:37] <AlanBell> recipe is here https://code.edge.launchpad.net/~alanbell/+recipe/daily-dash-of-dasher
[08:37] <AlanBell> pointing at lp:dasher which is an import of the gnome git tree
[08:38] <AlanBell> and lp:~alanbell/dasher/debian which is the /debian directory of the maverick dasher package
[08:38] <AlanBell> and it fails to build
[08:39] <AlanBell> discussing in -motu revealed it might be because the vcs doesn't include the configure script and needs autogen.sh running so I modified the debian rules to run that first, it still fails
[08:40] <AlanBell> it claims to be succesfull on lucid but I think that is just the source package, I don't think it has actually built anything useful
[08:47] <AlanBell> the maverick build seems to be complaining about missing build deps http://launchpadlibrarian.net/58159102/buildlog.txt.gz
[08:47] <AlanBell> dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 5.0.0) cdbs gnome-pkg-tools (>= 0.6) intltool (>= 0.40.1) libexpat1-dev libglib2.0-dev (>= 2.16.0) libgtk2.0-dev (>= 2.12.0) libx11-dev libxtst-dev libgnomeui-dev libgnome-speech-dev libbonobo2-dev liborbit2-dev libatspi-dev libatk1.0-dev libgconf2-dev gnome-doc-utils (>= 0.9.0) scrollkeeper gnome-common
[08:47] <AlanBell> but I have no idea which or why
[08:48] <wgrant> Um.
[08:48] <wgrant> That's interesting.
[08:48] <wgrant> I think those are all missing.
[08:48] <wgrant> Which means that it didn't install anything.
[08:49] <AlanBell> oh, right. That is the full list certainly
[08:50] <wgrant> It may mean that pbuilder-satisfydepends hates you.
[08:51] <wgrant> Let's see.
[08:59] <wgrant> AlanBell: Somehow the comment at the top of debian/control prevents pbuilder-satisfydepends from working.
[09:00] <AlanBell> oh, the bit about it being autogenerated!
[09:00] <wgrant> Yeah.
[09:00] <AlanBell> bother
[09:00] <wgrant> Ah.
[09:00] <wgrant> Remove the blank line.
[09:00] <wgrant> pbuilder-satisfydepends' behaviour is correct, but unobvious.
[09:02] <wgrant> (The source paragraph must be the first paragraph in the file, and a blank line delineates the end of a paragraph. So the comment was itself the first paragraph, albeit an empty one.)
[09:03] <AlanBell> hmm, so is that a bug in something?
[09:03] <wgrant> Your package.
[09:03] <AlanBell> in the control.in file?
[09:03] <wgrant> Unless something else inserts that blank line.
[09:03] <AlanBell> or the thing that converts the control.in to control
[09:03] <wgrant> Hmm, interesting.
[09:03] <wgrant> Looks like the thing that converts it.
[09:04] <wgrant> Which is probably some GNOME cdbs helper that I haven't touched in years.
[09:05] <AlanBell> is there some other way to do packaging than cdbs?
[09:08] <\sh> plain debhelper?
[09:09] <AlanBell> so is it worth throwing away the /debian directory and starting from scratch with debhelper?
[09:11] <AlanBell> looks like it is going better this time https://code.edge.launchpad.net/~alanbell/+recipe/daily-dash-of-dasher/+build/5619
[09:26] <AlanBell> still failed http://launchpadlibrarian.net/58171530/buildlog_ubuntu-maverick-i386.dasher_4.11%2B3139%2B11~maverick1_FAILEDTOBUILD.txt.gz
[09:44] <maxb> AlanBell: build-aux/mkversion: 7: git: not found
[09:45] <maxb> fairly clear error, no?
[09:45] <AlanBell> not to me :) does it need git as a build-dep?
[09:45]  * AlanBell is a newbie at all this packaging lark
[09:45] <maxb> apparently
[09:45] <maxb> Which is a bit silly really
[09:46] <maxb> You might have to beat this buildsystem into submission and make it saner
[09:46] <AlanBell> I don't get why it needs more build-deps when done as a recipe
[09:47] <AlanBell> the instructions seem to indicate if you lift the /debian directory from the package and merge it in a recipe with the VCS import then it should just all work
[09:47] <wgrant> It sounds like the tree you get from the VCS isn't the same as the one in the tarballs.
[09:47] <wgrant> Check their release docs to see what they run to prepare the tree.
[09:49] <AlanBell> hmm, where might I find that? not in the manual for dasher certainly
[09:59] <AlanBell> maxb: what about the missing .m4 files it seems to want from /aclocal? are they important?
[10:00] <maxb> what missing files?
[10:00] <AlanBell> about 10-20 lines above the message about git not found
[10:01] <AlanBell> codeset.m4 etc
[10:40] <popey> https://edge.launchpad.net/~bobmorton smells like a spammer
[10:40] <popey> https://bugs.edge.launchpad.net/gwibber/+bug/259830/comments/56 testing the waters..
[10:47] <Tak> is there a way to enable user creation on a local instance?
[11:00] <wgrant> Tak: Not in the testopenid OpenID provider. But you're not meant to use that for production.
[11:00] <Tak> yeah - I'm trying to set up a local test environment for evaluation
[11:00] <Tak> I did find utilities/make-lp-user , however
[11:00] <wgrant> That is a handy one.
[11:02] <Tak> is there any support (from launchpad teams/canonical/anybody) for companies running local launchpad instances against proprietary codebases?
[11:02] <wgrant> I don't believe so. But you can purchase a commercial subscription to host a proprietary project on Launchpad.net.
[11:03] <Tak> yeah, that's not really an option :-/
[11:05] <Tak> but a support subscription would be
[12:38] <Tak> hmm, the code browser's not picking up my pushes :-/
[13:10] <maxb> Tak: https://dev.launchpad.net/Code/HowToUseCodehostingLocally
[13:11] <maxb> erm, although I see bits there which I know are out of date. But the essence should be valid
[13:12] <Tak> ah - so I have to manually make sync_branches
[13:13] <maxb> The out of date for certain bit is that there's no more branch puller, the hosted and mirrored areas were collapsed into a single area
[13:30] <Tak> mmm, it appears to succeed, but lp's still telling me there's no content in the branch(es)
[16:06] <kervala> please someone succeeded to connect to launchpad web API with PHP ?
[16:07] <kervala> i tried "Step 1: Get a request token"
[16:07] <kervala> but i can't get it working :(
[16:07] <kervala> i got : 400 Bad Request
[20:05] <infohigh> Is there a way to join a launchpad-hosted mailing list without having a launchpad account?
[20:07] <maxb> no
[20:07] <infohigh> gah.
[20:08] <maxb> Signing up for a Launchpad account should not be hard (other than the whole "Yes, it's yet another web account"
[20:09] <infohigh> sure, just seems like a hassle for a mailing list... what happened to good ol' mailman :-)
[20:11] <maxb> LP lists actually are Mailman under the hood
[20:12] <infohigh> then it's a shame they removed the feature of being able to subscribe to their mailing lists with mailman's friendly mechanism ;)
[20:27] <vadi2> what is the launchpad filesize attachment limit for bugs?
[23:04] <ronnie_vd_c> So, now that UDS talks are over, i have a few questions about the LP API. I run into two problems. 1. i have a script that will ba called with piped data. But launchpad login_with also uses the os.stdin. It appears those two are in conflict. If i run the script without pipe, the authentication works great, but with pipe it fails
[23:07] <ronnie_vd_c> 2. When i create a bug with private=True i got the following error: http://pastebin.com/bNr8iVD3
[23:07] <ronnie_vd_c> The bug is posted as it should be, but the error stays and stops my script
[23:08] <geser> what permissions does your script have?
[23:08] <geser> can it read private bugs?
[23:09] <geser> and write private data? (don't know if it's needed to file private bugs)
[23:13] <ronnie_vd_c> geser, it has my permissions. im the admin of the porject where i post. I gave the script my full permissions launchpad = Launchpad.login_with(IDENTIFIER, SERVICE, CACHEDIR, allow_access_levels=["WRITE_PUBLIC"])
[23:14] <ronnie_vd_c> geser. if i look on staging.launchpad.net the bug is posted, even when the script returns an error
[23:17] <wgrant> ronnie_vd_c: WRITE_PUBLIC is not full permissions.
[23:17] <wgrant> ronnie_vd_c: That's WRITE_PRIVATE.
[23:17] <wgrant> WRITE_PUBLIC doesn't allow access to private data (like private bugs).
[23:17] <ronnie_vd_c> wgrant, ah ill try that
[23:18] <ronnie_vd_c> wgrant: problem 2 solved. Any thoughts on problem 1?
[23:19] <wgrant> ronnie_vd_c: IIRC login_with should only prompt the first time.
[23:19] <wgrant> Is that not the case?
[23:20] <ronnie_vd_c> yes, thats the case. so i could make a separate script that is run once, which set authentication. and then run the script with the piped data all the other times
[23:21] <wgrant> I think that's probably best, unless you want to reimplement login_with in a way that is not completely clear.
[23:21] <ronnie_vd_c> wgrant, thats defenitly not my intention
[23:21] <ronnie_vd_c> thx for the help
[23:21] <ronnie_vd_c> geser, you too ofc ;)