=== blueyed__ is now known as blueyed [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] AlanBell: What's the issue? [08:37] recipe is here https://code.edge.launchpad.net/~alanbell/+recipe/daily-dash-of-dasher [08:37] pointing at lp:dasher which is an import of the gnome git tree [08:38] and lp:~alanbell/dasher/debian which is the /debian directory of the maverick dasher package [08:38] and it fails to build [08:39] 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] 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] the maverick build seems to be complaining about missing build deps http://launchpadlibrarian.net/58159102/buildlog.txt.gz [08:47] 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] but I have no idea which or why [08:48] Um. [08:48] That's interesting. [08:48] I think those are all missing. [08:48] Which means that it didn't install anything. [08:49] oh, right. That is the full list certainly [08:50] It may mean that pbuilder-satisfydepends hates you. [08:51] Let's see. [08:59] AlanBell: Somehow the comment at the top of debian/control prevents pbuilder-satisfydepends from working. [09:00] oh, the bit about it being autogenerated! [09:00] Yeah. [09:00] bother [09:00] Ah. [09:00] Remove the blank line. [09:00] pbuilder-satisfydepends' behaviour is correct, but unobvious. [09:02] (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] hmm, so is that a bug in something? [09:03] Your package. [09:03] in the control.in file? [09:03] Unless something else inserts that blank line. [09:03] or the thing that converts the control.in to control [09:03] Hmm, interesting. [09:03] Looks like the thing that converts it. [09:04] Which is probably some GNOME cdbs helper that I haven't touched in years. [09:05] is there some other way to do packaging than cdbs? [09:08] <\sh> plain debhelper? [09:09] so is it worth throwing away the /debian directory and starting from scratch with debhelper? [09:11] looks like it is going better this time https://code.edge.launchpad.net/~alanbell/+recipe/daily-dash-of-dasher/+build/5619 [09:26] still failed http://launchpadlibrarian.net/58171530/buildlog_ubuntu-maverick-i386.dasher_4.11%2B3139%2B11~maverick1_FAILEDTOBUILD.txt.gz [09:44] AlanBell: build-aux/mkversion: 7: git: not found [09:45] fairly clear error, no? [09:45] not to me :) does it need git as a build-dep? [09:45] * AlanBell is a newbie at all this packaging lark [09:45] apparently [09:45] Which is a bit silly really [09:46] You might have to beat this buildsystem into submission and make it saner [09:46] I don't get why it needs more build-deps when done as a recipe [09:47] 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] It sounds like the tree you get from the VCS isn't the same as the one in the tarballs. [09:47] Check their release docs to see what they run to prepare the tree. [09:49] hmm, where might I find that? not in the manual for dasher certainly === wgrant changed the topic of #launchpad to: Launchpad https://launchpad.net/ | Read https://help.launchpad.net/ for help | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/ === wgrant changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/ [09:59] maxb: what about the missing .m4 files it seems to want from /aclocal? are they important? [10:00] what missing files? [10:00] about 10-20 lines above the message about git not found [10:01] codeset.m4 etc [10:40] https://edge.launchpad.net/~bobmorton smells like a spammer [10:40] https://bugs.edge.launchpad.net/gwibber/+bug/259830/comments/56 testing the waters.. [10:40] Launchpad bug 259830 in Gwibber "Honor gnome proxy setting (affected: 73, heat: 434)" [Medium,In progress] [10:47] is there a way to enable user creation on a local instance? [11:00] Tak: Not in the testopenid OpenID provider. But you're not meant to use that for production. [11:00] yeah - I'm trying to set up a local test environment for evaluation [11:00] I did find utilities/make-lp-user , however [11:00] That is a handy one. [11:02] is there any support (from launchpad teams/canonical/anybody) for companies running local launchpad instances against proprietary codebases? [11:02] I don't believe so. But you can purchase a commercial subscription to host a proprietary project on Launchpad.net. [11:03] yeah, that's not really an option :-/ [11:05] but a support subscription would be === LinuxJedi is now known as LinuxJedi|away [12:38] hmm, the code browser's not picking up my pushes :-/ [13:10] Tak: https://dev.launchpad.net/Code/HowToUseCodehostingLocally [13:11] erm, although I see bits there which I know are out of date. But the essence should be valid [13:12] ah - so I have to manually make sync_branches [13:13] 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] mmm, it appears to succeed, but lp's still telling me there's no content in the branch(es) === apachetransit is now known as udslogger === bilalakhtar_ is now known as bilalakhtar === bilalakhtar_ is now known as bilalakhtar === adeuring1 is now known as adeuring === Meths_ is now known as Meths === mtaylor is now known as 52AACIHR4 [16:06] please someone succeeded to connect to launchpad web API with PHP ? [16:07] i tried "Step 1: Get a request token" [16:07] but i can't get it working :( [16:07] i got : 400 Bad Request === deryck_ is now known as deryck === mordred_ is now known as mtaylor === Meths_ is now known as Meths === oubiwann-away is now known as oubiwann === LinuxJedi|away is now known as LinuxJedi === Ursinha is now known as Ursinha-lunch === matsubara is now known as matsubara-lunch === beuno is now known as beuno-lunch === matsubara-lunch is now known as matsubara === Ursinha-lunch is now known as Ursinha === beuno-lunch is now known as beuno === Meths_ is now known as Meths === matsubara is now known as matsubara-afk [20:05] Is there a way to join a launchpad-hosted mailing list without having a launchpad account? [20:07] no [20:07] gah. === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [20:08] Signing up for a Launchpad account should not be hard (other than the whole "Yes, it's yet another web account" [20:09] sure, just seems like a hassle for a mailing list... what happened to good ol' mailman :-) [20:11] LP lists actually are Mailman under the hood [20:12] 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] what is the launchpad filesize attachment limit for bugs? === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Lcawte is now known as Lcawte|Away [23:04] 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] 2. When i create a bug with private=True i got the following error: http://pastebin.com/bNr8iVD3 [23:07] The bug is posted as it should be, but the error stays and stops my script [23:08] what permissions does your script have? [23:08] can it read private bugs? [23:09] and write private data? (don't know if it's needed to file private bugs) [23:13] 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] geser. if i look on staging.launchpad.net the bug is posted, even when the script returns an error [23:17] ronnie_vd_c: WRITE_PUBLIC is not full permissions. [23:17] ronnie_vd_c: That's WRITE_PRIVATE. [23:17] WRITE_PUBLIC doesn't allow access to private data (like private bugs). [23:17] wgrant, ah ill try that [23:18] wgrant: problem 2 solved. Any thoughts on problem 1? [23:19] ronnie_vd_c: IIRC login_with should only prompt the first time. [23:19] Is that not the case? [23:20] 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] I think that's probably best, unless you want to reimplement login_with in a way that is not completely clear. [23:21] wgrant, thats defenitly not my intention [23:21] thx for the help [23:21] geser, you too ofc ;) === LinuxJedi is now known as LinuxJedi|away