[13:59] any bzr expert around? [13:59] when i do bzr commit bzr+ssh://bhuvan@bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-karmic [13:59] bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/ubuntu-karmic/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() [13:59] i'm facing that error, any clue on why it occurs? [14:00] bzr break-lock didnt help [14:04] You're suppose to just 'bzr commit' and then 'bzr push' to that location. [14:04] bhuvan: are you ssh keys on LP up to date? [14:04] bhuvan: I think you get different error when that happens though [14:04] sommer: i think so. i did not change it et all [14:05] i suspected the issue is because i co using http, i changed .bzr/branch/branch.conf and set as bzr+ssh [14:05] Why it's saying http:// when you're using bzr+shh:// I don't know. [14:05] now when i did bzr commit it complains: [14:05] Permission denied (publickey). [14:05] bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [14:06] bhuvan: maybe try re-uploading your key? [14:06] jpds, i think it was because i checked out using http:// [14:06] ok, will do sommer [14:10] bhuvan: ya, I usually just do bzr branch lp:ubuntu-doc, then bzr commit followed by bzr push to commit up to LP [14:11] bhuvan: you can also bind to the branch, but if you remember to do bzr pull before committing any changes it's pretty much the same thing... from what I understand anyway :) [14:12] sommer: re-uploading the key seem to help [14:12] bzr commit says ... Committed revision 258. [14:12] bzr push says ... No new revisions to push. [14:13] sommer: do you think [14:13] i'm alright? [14:13] bhuvan: did you make any changes? [14:13] yes to mail.xml [14:14] bhuvan: try bzr push lp:ubuntu-doc [14:14] maybe it just needs to know where to push [14:16] sommer: i'll try it. righ tnow, i'm doing bzr branch lp:ubuntu-doc [14:16] once it is complete, i will run bzr push lp:ubuntu-doc [14:16] thanks! [14:20] bhuvan: np [19:53] bhuvan: no, not lp:ubuntu-doc - we are in string freeze so you need to commit to the karmic branch only [19:53] sommer: ^^ [19:55] oh right, I guess I assumed lp:ubuntu-doc was now karmic [19:55] I'll change it shortly [19:55] party! [22:08] hola [22:08] anybody around this time o' day? [22:09] LaserJock: yep [22:09] oh, you're still up [22:09] LaserJock: to reply to your last in -devel [22:10] LaserJock: you'll need to ship them with the doc itself [22:10] I got to looking at what you guys were doing a bit more in depth [22:10] LaserJock: if you use /usr/share/edubuntu-docs, it won't work [22:10] I'm not sure why you're symlinking "libs" but it's a bit interesting [22:10] LaserJock: go ahead [22:11] well, basically ubuntu-doc is taking an exclusive lock on "libs" which has been a fairly generic directory in the past [22:12] LaserJock: yes, it doesn't really account for derivatives which also use Gnome, I suppose [22:12] if one installs the new ubuntu-docs and *then* installs edubuntu-docs then it'd be fine I guess, but it's a bit hackish it seems [22:12] and which might not use ubuntu-docs [22:13] for me it's not much of a problem as Edubuntu only has one doc [22:13] but it might be something to think about in the future [22:13] yes, we should think that through and clean things up a bit for karmic [22:14] do you have an easy alternative solution? I guess the other way around may work better (ship /usr/share/gnome/help/libs/ and symlink from /usr/share/ubuntu-docs/libs) [22:15] well [22:15] what was the point of doing the symlinking? [22:16] we used to just dump in /usr/share/gnome/help/libs/ [22:17] I can't remember what the reasoning was :( [22:18] probably there was some, even if twisted [22:18] well, I would have maybe called it ubuntu-libs and left the "libs" as generic if you had a particular purpose for symlinking [22:19] off the top of my head, I can't think of a reason for having /usr/share/ubuntu-docs at all [22:19] maybe I'm missing something [22:20] presumably ubuntu-serverguide uses it [22:20] I'll certainly take a look at these issues in the next release [22:22] well, in any case I can fix the immediate issue [22:23] my problem is how to deal with a package that hasn't been updated in 1 year and trying to get it all to work in one shot [22:24] * mdke nods [22:24] LaserJock: sorry if the symlink has increased that pain [22:25] well, the only thing I'm wondering about is translations [22:25] https://translations.edge.launchpad.net/ubuntu/jaunty/+source/edubuntu-docs [22:26] quite a few templates there :( [22:26] are the .ents translated? [22:26] they are transposed directly into the translated xml [22:27] i.e. the translated xml files don't use .ents [22:29] ok [22:29] so it just comes down to me needing to move my 2 files somewhere else [22:29] I guess if the structure is /usr/share/gnome/help/$$doc/$$lang/ then I could put the .ents in usr/share/gnome/help/$$doc/ [22:30] what I think you should do is to put the ents directly inside the xml file for the relevant document [22:30] ah, well, yeah, I could do that too ;-) [22:30] heh, they are all of 8 lines [22:31] yeah, that's pretty ridiculous to separate out anyway [22:31] LaserJock: you can eliminate any ents which aren't actually used [22:32] if you have time :) [22:32] then regenerate the pot files for safe keeping [22:32] but no strings should change [22:38] it's ok for the pot to change a little isn't it? [22:38] I need to get "Hardy" and "8.04" updated to "Jaunty" and "9.04" [22:39] LaserJock: yeah, for serious typos like that it's ok, but notify the translators so that they can update the translations if they wish [22:42] LaserJock: that is, assuming that you'll be downloading the translations before Jaunty release :) [22:48] ah crap [22:48] this is just not going to be easy [22:48] hmm? [22:50] right now I can't generate a .pot correctly [22:50] error? [22:50] it spits out one giant msgid [22:51] whuahu? [22:51] well, I could just grab the .pots off of LP [22:51] and s/Hardy/Jaunty/ [22:52] then they wouldn't fit the xml [22:52] presumably [22:52] well, it would fit the xml, just not the .pot generated from the xml [22:53] I'm not sure [22:54] hmmpf, get-pot.sh is the same between the two [22:54] sorry? [22:58] ok, I've got to crash now, catch up tomorrow