[01:42] I'd like to layoutmy Homepage Content area using html
and

ardchoille: it is not possible at the moment. [01:44] Is there any way to layout things in paragraphs? carriage returns don't seem to work [01:45] ardchoille: Works fine for me... [01:46] wgrant: Doesn't work here: https://launchpad.net/~ardchoille42 [01:46] carriage returns there [01:48] Oh, I just added "About me:" and a link,and the link isn't parsed either. [01:48] Ah, it's probably because you have no karma. [01:49] Users without karma don't get formatted, due to spam concerns. [01:49] That's just plain silly, IMHO [01:49] File a bug about it. Then you'll have karma and it'll work! :D [01:49] I had lots of karma, must have been taken away since I didn't have much input lately [01:49] Peng: hehe [01:49] Right, it should probably instead detect whether you have any karma actions, not whether you have any karma. [01:49] KArma decreases over time so that'd be a waste of time [01:49] https://launchpad.net/launchpad-registry/+filebug [01:50] Thanks folks. [01:50] Is he going to file a bug? [01:50] Probably not. [01:50] If I don't see one soon, I will file it. [01:51] <3 [05:08] is anyone else seeing staging.launchpad.net as down? [05:09] mrooney: It should be back in about 25 minutes. [05:09] It's currently updating. [05:09] oh I see, is that normal and happens every time it syncs? [05:11] now that I've automated packaging and uploading to PPAs, I'm exciting to start LP API scripting and automating release process stuff as well! [05:12] I don't know whether it's normal. But it has been the case for a few days now. [05:12] I was thinking of something that you give a milestone, and it will create a release, mark all fix committed as fixed released, upload tarballs/debs, and such, make LP announcement [05:12] That would be nice. [05:12] though I don't want to reinvent anything, is there similar public stuff out there? [05:12] (although announcements aren't yet exposed in the API) [05:12] ah, alas [05:13] though adding stuff to the API isn't that hard, right? [05:13] maybe if I get up to that point, I can find a mentor and add that [05:13] No. [05:13] I think somebody's already working on it. [05:13] * wgrant looks. [05:14] Bug #409090 [05:14] Launchpad bug 409090 in launchpad-registry "Announcements not exposed in launchpadlib" [Low,Triaged] https://launchpad.net/bugs/409090 [05:15] oh I wonder if quickly is doing some LP release automation? [05:16] that appears to be the case. [05:16] I shall ask in the appropriate channel! [05:16] thanks for the bug link :) [05:28] oh no, the instructions for launchpadlib on help.lp.net are quite broken in multiple ways [05:28] should I file a bug somewhere? [05:30] mrooney: Sure you're not just using an old version? [05:35] wgrant: the first step of getting the latest launchpadlib is "bzr branch lp:oauth" [05:35] at least for me that's quite an error [05:37] can anyone else confirm or deny my sanity? [05:39] Ah, yes, it has no default branch. [05:39] Odd. [05:39] yeah I looked at the branches and don't see an obvious "right" one [05:40] I'll grab malept's he's a good guy :) [05:50] How long does it take for Ubuntu uploads to get merged into the package branches? [05:52] RAOF: That's probably more of an #ubuntu-devel question. It's not actually part of Launchpad. [05:52] Really? Launchpad isn't responsible for the package import service? [05:53] No. [05:53] it's run by james_w, using launchpadlib. [05:53] Colour me surprised. [05:53] Aaah. [06:01] okay staging is back, albeit a few weeks at least out of date, odd === cjohnston is now known as wikipirate [15:30] hi. got a question about packaging.. I have the package, called "foo", and want to create the same package with the unstable version, called "foo-testing".. but other packages are depending on "foo".. so what do I have to do? [15:36] thopiekar: This channel is for Launchpad, which is a webapplication. I think you should ask your question in #ubuntu-motu. [16:56] hi at all [16:57] how can i compile a project with py file for upload to launchpad ppa? [17:34] is it possible to disable sending of the failed builds logs to all team members? [18:30] hey, would be nice if we could use launchpad ppa for lenny packages, would be a nice way to give back to debian [18:57] branching an LP branch doesn't work from a hardy machine [18:57] It says: ERROR: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n' [18:57] :-( [18:58] I don't think that has anything to do with Launchpad, per se [18:58] oh? [18:59] bzr | 1.6.1-1 | intrepid | source, amd64, i386 [18:59] mok0: the branch format is determined by whoever put the branch there [19:00] or perhaps I should say, whoever created the branch [19:00] idnar: that was on a karmic system [19:00] idnar: but I need to branch onto servers that run hardy [19:00] idnar: and supposedly, hardy should still be supported [19:01] you need to pick a format that's supported by the version in hardy [19:02] idnar: Can I convert the already existing branch or do I need to zap it [19:02] ? [19:02] I'm not sure of the details; you might be better off asking in #bzr, though [19:02] idnar: ok, thanks, will do... [19:03] It is a bad idea to change the repo format to something that is not backward compatible [19:03] ...forward I should say [19:18] Heh. Now I have converted the LP branch so it is compatible with hardy. However, now I can't push to the repo from my karmic workstation. Bah [19:23] mok0: the repo on your karmic workstation probably needs to be in the same format [19:24] idnar: it is. I branched it from LP but can't push to it [19:24] idnar: conclusion is that you can't work across distributions with LP [19:24] idnar: which is _really_ bad given that hardy is supported for another 2.5 years [19:31] What's the quickest way to get from a bug object to a project object using launchpadlib? [19:31] Is it task = bug.bug_tasks; task.target ? [21:37] plpower [21:38] mok0: What goes wrong when you push it? All version of bzr >= 0.92 can push to pack-0.92 branches, which is the hardy default. [21:38] wgrant: I got an error message [21:38] doctormo: A bug can have multiple tasks, each on a different project, distribution or package. You would need to pick one of them. [21:38] mok0: That's not terribly descriptive. [21:39] wgrant: Aye, I got it working. Thanks. [21:39] wgrant: I know, but I got very annoyed and upgraded my hardy server to bzr-2.02 [21:39] wgrant: so I can't reproduce sorry [21:39] wgrant: I'm in work mode, which means I become impatient :-) [21:40] wgrant: and Ubuntu doesn't seem to care about older releases anyway [21:40] mok0: s/Ubuntu/Bazaar/, and only sort of. [21:45] wgrant: AFAIAC, it is outrageous to introduce a bzr version on LP that is not backwards compatible with hardy *without* making sure that there's a new version of bzr in -updates [21:46] wgrant: I wasted a lot of time on this today, but at least I was able to fix it for myself. [21:46] mok0: It's nothing to do with Launchpad. It doesn't choose the format. [21:46] The client chooses the format. [21:46] wgrant: then it shouldn't have been upgraded [21:46] And I don't see how you got a 1.6 branch without explicitly upgrading to it, since IIRC the default was never 1.6. [21:47] wgrant: I have bzr on my mac to [21:47] too [21:47] wgrant: I don't know what version, I just made the repo and pushed it to LP. [21:47] mok0: Anyway, this is entirely a #bzr problem. [21:48] wgrant: then I couldn't use that from hardy. Then I zapped the repo and made it from hardy, but that didn't work with the newer versions of bzr [21:48] wgrant: yeah I guess. [21:48] mok0: It did work with newer versions of bzr. [21:49] wgrant: it didn't work the way I described [21:49] mok0: In the normal case, they interoperate fine. [21:50] wgrant: I don't know what the reason was. Creating a repo from hardy, pushing to LP, I couldn't branch that on karmic [21:50] wgrant: as I said, I was annoyed and not in debug-mode [21:51] wgrant: so I didn't make note of my steps [21:52] It was fortunate that bzr-2.0.2 builds fine as a hardy package [21:52] It should be pushed to backports ASAP [21:53] That is difficult, because of the default incompatible format change. [21:54] wgrant: that seems to be an integral problem of bzr. You'll just have to make a new repo [21:58] mok0: See ppa:bzr [22:07] wgrant: I hope the bzr devs will take note NOT to change the format again [22:08] mok0: They will again. But it seems that they're going to be less insane about it. [22:09] wgrant: well, perhaps we should take care to properly test the bzr package before it's introduced in Ubuntu [22:10] mok0: Why? [22:10] wgrant: we really can't upgrade bzr as long as there are supported releases that don't support the newest format [22:11] mok0: But then we can never introduce a new bzr, because we can never introduce a new format. [22:11] (also, further testing is unnecessary. the format changes are well documented,) [22:11] wgrant: not true, the new format will be rolled out at a slower pace [22:12] wgrant: I.e. when hardy goes away, we can move to the next level, when intrepid dies, the next, etc. [22:12] mok0: So you mean that the *default* format should not be changed? [22:12] wgrant: right [22:13] mok0: That would be the right solution, but LTSes live just about forever. [22:13] wgrant: I don't see git or the other VCSes have the need to update their formats at the same insane pace [22:14] wgrant: In fact, I can still access svn repos I created years ago [22:14] Accessing old branches is fine. [22:15] wgrant: It failed for me [22:15] mok0: I suspect that you did something slightly wrong. It normally Just Works. [22:16] wgrant: I can't say [22:16] wgrant: As I said, I was impatient and annoyed... [22:17] wgrant: But changing the format so that old (but recent) versions don't work anymore, is criminal [22:17] IMO [22:18] I have the most recent bzr on my mac, and it is 1.18 [22:18] most recent from fink, that is [22:18] Then Fink is six months out of date. [22:19] wgrant: so you mean, if you have a version 6 months old, it's just tough luck that it suddenly can't read the repos? [22:19] mok0: I strongly disagree with how the 2a migration was done (making it the default before support was in any Ubuntu release, and right in the middle of the LTS cycle -- it could hardly have been worse timing). [22:20] wgrant: I agree with that. [22:20] 2a is a very good thing. [22:20] But the migration path is suboptimal. [22:20] wgrant: I doubt most users care [22:21] wgrant: it may matter if you maintain an extremely large repo [22:21] mok0: It's an awful lot faster and smaller. That was probably the main complaint about bzr. [22:22] wgrant: most users have < 100 files, I don't think you can notice any speed difference there [22:22] wgrant: If I needed a VCS for a large project, I would choose git [22:23] mok0: Why? [22:23] wgrant: it's better [22:23] Apart from the bad release/format cycle, which is now history? [22:23] wgrant: faster [22:23] Why? [22:23] wgrant: I don't know why, but it is [22:24] wgrant: great design perhaps [22:24] mok0: 2.0+ narrows the margin immensely. [22:24] wgrant: hm ok [22:24] It's a really, really big difference. [22:24] wgrant: I can try to upgrade my 0.92 repo now, and see if it makes a difference [22:26] wgrant: ah, I can't... I still need my mac to work [22:28] mok0: I think 1.18 should support 2a. [22:29] wgrant: I wont risk it to try... I [22:29] wgrant: 0.92 is actually fast enough for me ;-) [22:30] wgrant: It works, which is #1 [22:30] wgrant: ... but it would work with LP [22:30] would not [22:31] It does. [22:31] Lots of branches are still 0.92 [22:32] I work with 0.92 branches from bzr 2.1 RCs. [22:32] ah ok. But I don't want this repo on LP anyway... it's just my personal documents [22:33] wgrant: so what's the problem with bzr 2 on hardy again? [22:34] wgrant: the package builds w/o problems [22:34] mok0: Right, backporting is no problem. It's all in the bzr PPA. But 2.0 changes the default format! [22:34] Backporting something which will then start making incompatible branches is probably a seriously bad idea. [22:35] wgrant: perhaps that could be fixed in the backport? [22:35] I don't know. You should ask #bzr. [22:35] (Like it should have been in the first place) [22:36] wgrant: yeah I will look at it [22:38] wgrant, how many times have they changed the format? [22:41] mok0: I don't know. [22:42] wgrant: there's a whole bunch of them, I just don't know how many of them have been default at some point [22:43] mok0: pack-0.92 was the last default before 2a. [22:43] wgrant: and knit was the default in 0.8 [22:45] mok0: dirstate-tags was the default until the end of 2007. [22:46] So it was the default for nearly two years. [22:46] Heh [22:46] Er, 'it' being pack-0.92. === niko is now known as Guest77462 === nik0 is now known as niko [23:42] Changing the default format is like one line of code, not counting imports. In fact, a plugin already exists to use an older default format. [23:42] IMO it would be confusing if Ubuntu had a 2.0 that used an older default format, though. [23:42] But probably still worth it. [23:47] Why do all translations in launchpad have to be bsd-licensed? [23:48] hey all, any API experts know if there is a faster alternative to: for bug in milestone.searchTasks(): bug.transitionToStatus(status="Fix Released") ? [23:48] I assumed I could do bug.status = "Fix Released" but no matter what object I call lp_save on it doesn't get persisted or ends up with an error [23:51] mrooney: You need to call lp_save on every object. [23:52] oh, that results in an error, and probably wouldn't be faster anyway, right? [23:52] Right. [23:52] okay, I will stick with the transitionToStatus call then, thanks :)