[09:53] <Renegade15> good day; how do I make launchpadlib use the /devel/ version of the API, instead of 1.0?
[09:53] <geser> specify it in you login() call
[09:54] <Renegade15> would that be a named or a positional parameter?
[09:55] <geser> named: login_with(..., version='devel')
[09:56] <Renegade15> ah, thank you :)
[13:04] <penguin42> can someone explain why bug 863504 keeps settings it's importance back to 'Unknown'?
[13:07] <rick_h> penguin42: i think because it's syncing hte status from the upstream bug
[13:07] <penguin42> rick_h: But that's an odd thing to do to the importance field isn't it? (It looks like the only bug in lp/ubuntu set like that)
[13:08] <rick_h> penguin42: is this done/fixed released then?
[13:09] <penguin42> rick_h: Don't think so
[13:10] <rick_h> penguin42: ok, the changes 3/9 from nitrof22 and 4/5 simplehuman seemed to mark each as fixed released
[13:10] <penguin42> rick_h: The Status of the 'ubuntu' component is fix released (which is probably bogus) but the status of the linux (ubuntu) component is 'new' - it's also 'assigned' to a debbug, which I'm not sure is the right thing anyway for a bug in linux(ubuntu)
[13:10] <penguin42> rick_h: And if you manually change the Importance the bug follower flips it back to Unknown
[13:11] <rick_h> penguin42: right
[13:12] <penguin42> rick_h: It doesn't seem right for it to do that
[13:16] <rick_h> penguin42: yea, I've not done much with upstream, but this seems wrong. The first bug task is on ubuntu without any package/etc. The assigned to the deb bug vs a 'also effects...' seems strange. looking through how it's supposed to work
[13:17] <rick_h> penguin42: I think this is because the linux (ubuntu) task is linked to the debian bug report.
[13:21] <penguin42> rick_h: So I suspect one fix is to remove that link, and to make a linux(debian) or similar link to the debian report; however is there a lp bug here ? I mean should it allow a linux(ubuntu) bug to have an assign to a debian bug? And even if it does I think there should never be a way for something to set the importance of an ubuntu bug to unknown?
[13:25] <rick_h> penguin42: I've got a call in a sec and I'll make sure I'm not leading you astray, but I think you'd need to add that it effects another project, udev, link that to the deb bug. and it'd track separately.
[13:26] <penguin42> rick_h: OK, I'm also about to disappear - but even then I still think there's a lp bug
[13:26] <rick_h> penguin42: well I think it's doing what it's told. It's thold to watch this upstream and if the status there is unknow/new it'll keep updating it
[13:27] <wgrant> penguin42, rick_h: Normally you'd have a linux (Debian) task with the link to the external bug.
[13:27] <wgrant> But that bug has its linux (Ubuntu) task linked to the Debian bug, which doesn't make sense.
[13:28] <penguin42> wgrant: Yeh, so I'm thinking there is either a bug in that it lets you link linux(Ubuntu) up to the debian one, and another one that it should never set an ubuntu package to unknown since there is no other way anywhere in lp of setting an ubuntu package to unknown
[13:28] <rick_h> wgrant: and that debian bug is on udev package so it should be against that vs linux?
[13:28] <dobey> also, there's no "Debian" option in the "Distribution" list when you try to change it
[13:28] <wgrant> penguin42: The remote bug syncer is the only thing that's ever meant to use the Unknown status and importance
[13:29]  * wgrant fixes the bug.
[13:30]  * penguin42 pops out for a while
[13:32] <wgrant> penguin42, rick_h: It is a bit more sensible now.
[13:32] <rick_h> wgrant: ty much
[13:47] <ahasenack> hi, I'm getting a huge javascript error when trying to make bug #977097 private
[13:47] <ahasenack> can someone help?
[13:52] <ahasenack> a web-op marked it as private, but now I can't see it anymore
[13:52] <ahasenack> and I'm in the landscape team
[13:54] <rick_h> deryck: do you have perms to fix that? I can't see it. ^^
[13:56] <wgrant> ahasenack: How did they make it private?
[13:56] <ahasenack> wgrant: I don't know, I'm trying to reach them now but they don't answer, must be busy putting out some fire
[13:57] <ahasenack> wgrant: can you see it? I get a 404 now
[13:57] <wgrant> No.
[13:57] <wgrant> And I can see most Landscape private bugs.
[13:57] <ahasenack> must be really private now
[13:58] <deryck> rick_h, I doubt I can see it either.  let me look....
[13:59] <deryck> rick_h, yeah, sorry, I can't either.  Think webops has to get involved.
[15:12] <penguin42> wgrant: Thanks
[16:09] <jono> hey all
[16:10] <jono> quick question - I have a project that has a daemon codebase and a GUI codebase - should I use the same LP project and just have a series for the daemon and a series for the GUI, or should they be two separate LP projects?
[16:18] <maxb> jono: You should make your decision based on: 1) Do they live in separate version-controlled directory trees, or a single one, and; 2) do they have a single version number covering both, or are they released separately
[16:57] <jono> maxb, they are in different trees, but in lp:foo/daemon and lp:foo/gui
[16:58] <jono> as for releases, we could conceivably release them seperately
[17:45] <maxb> jono: Sounds to me like they are logically separate projects then
[17:47] <dobey> if they are both required for the client to work, they probably shouldn't be. unless you are hoping for other people to write different UIs to do the exact same thing as your current GUI does
[17:53] <kirkland> anyone around who can help me with a new private/commercial launchpad project?
[17:54] <kirkland> jono: I've done quite a bit of that, and personally, I've found separate projects work best for me
[18:01] <jono> thanks kirkland
[20:42] <yofel> someone around that could abort all builds on https://code.launchpad.net/~neon/+recipe/soprano please? They're stuck
[22:28] <BarkingFish> Evening guys! I wonder if someone could help me. I'm logged into launchpad, trying to get to the bugs list, and receiving a constant time out, complete with an OOPS id
[22:28] <BarkingFish> I wonder if someone could tell me what's happened, please?
[22:28] <BarkingFish> (Error ID: OOPS-dd8a8db066683c21c1419bcf10b2cd79)