[00:00] so apt still wants to upgrade it [00:01] fta: kick calc in -devel about it [00:01] fta: he should still be there [00:01] bug 192310 [00:01] Launchpad bug 192310 in openoffice.org-hyphenation "package openoffice.org-hyphenation-en-us None [modified: /var/lib/dpkg/info/openoffice.org-hyphenation-en-us.list] failed to install/upgrade: trying to overwrite `/usr/share/myspell/dicts/hyph_en_US.dic', which is also in package openoffice.org-hyphenation" [High,Confirmed] https://launchpad.net/bugs/192310 [00:01] nope [00:02] ok [00:02] calc is the openoffice man in charge here i guess ;) [00:03] no calc in -devel [00:04] most likely by accident :) [00:07] there he is ;) [00:12] hehe [00:22] I have a question... I made a folder under inbox and now for some reason it won't show up... I even subscribed to the folder and can't get it to come back. Any ideas? [00:23] this is in Thunderbird [00:23] not sure. i think inbox is special [00:23] all my other folders show up fine [00:23] i think there is a setting somewherein the gutsy of imap server settings to change that [00:25] Sergeant_Pony: try to enable "server supports folders that contain sub-folders and messages maybe" [00:25] in imap server settings -> advanced [00:27] asac: where is that? [00:27] in imap server settings -> advanced ;) [00:28] if yo don't have an imap account then i don't know [00:28] it is an imap account [00:28] then you have that advanced dialog :) [00:28] looking for settings advanced [00:28] Sergeant_Pony: account settings -> server settings- > advanced that is [00:31] that is already checked off [00:31] check it on :) [00:31] e.g. check it [00:31] if that doesn't help then its most likely a server issue [00:32] all my other folders under inbox show up [00:33] got it [00:33] ? [00:33] got the folder to show up [00:33] Sergeant_Pony: what was it? [00:33] I had imap show all imap folders... [00:34] Sergeant_Pony: so the setting helped? [00:52] yes [00:54] I unchecked "Show only subscribed folders" [00:54] and it appeared even tho I am subscribed to it [00:56] ok [00:56] server issue then i guess [00:57] I don't care... as long as I can display all my folders [00:58] hehe [00:58] hope you still see messages ;) [01:00] yup, can see my messages in the folder [01:01] now to figure out if I can have the mail deposited into certain folders. [01:01] filter i guess ;) [01:02] fta, thanks for the comment on teatime :) [01:23] 2 days till release :) [02:20] can tb be set to automatically run a filter to sort mail? or do I need to run it by hand? [02:22] it can ... but we are not focussed on that depth of user-support here in this channel in general. try the forums.mozillazine.org for such tb general questions. [02:25] most likely your question has already been asked there, so use the search facility there [02:25] Sergeant_Pony: ^^ === asac_ is now known as asac [09:05] * asac *yawns* [09:05] Hi there, anyone successfully using an LDAP Directory as an Address Book while offline - I do say, that I want to have it off-line and it replicates fine, but as soon as I switch thunderbird off-line I get zero results from queries... [09:19] mdke: you gave me a loitered branch with additional changes :( [09:23] mdke: uploading a cherry pick of the latest checkin on top of the 8.04.1 package shipped as 8.04.2~hardy [09:37] mdke: why does the .deb has lots more changes than the links? [09:37] thats a mystery [10:02] mdke: ok the -docs are up ... once they are published on LP we should integrate the changelog into the bzr branch [10:02] maybe ping me about it [10:21] phoenix24: hmm [10:21] phoenix24: i guess thats a bug [10:21] phoenix24: but online it works fine? [10:24] phoenix24: in advanced config .. there is a isOffline config for each ldap provider [10:24] whats the value for that? [10:25] I'm sorry which; extension are we talking about ? [10:26] phoenix24: ? [10:27] you asked a bout LDAP directory [10:27] offline [10:27] remember? [10:27] No, not me. [10:27] oh ;) [10:27] 10:05 < phoenix> Hi there, anyone successfully using an LDAP Directory as an Address Book while offline - I do say, that I want to have it off-line and it replicates fine, but as soon as I switch thunderbird off-line I get zero results from queries... [10:27] I Dont work with LDAP :( [10:27] hehe [10:27] someone spoofing you then ;) [10:27] not the 24 of course [10:28] Oh! [10:28] are you giving any talk at the upcoming UDW ? [10:28] yes .... again about extension packaging ... this time more focussed on the mass-maintenance part i hope [10:29] but mostly depends on how far we get with the procedure, but i think with the help of fta and Jazzva we can have something initially [10:29] Nice!! looking forward to it again. [10:29] what are these? fta & Jazzva. [10:30] i would have done more complex things like "porting applications to xulrunner 1.9" ... but was told that that I should rather use something more basic ;) [10:31] phoenix24: fta wrote a script that automatically checks if there are new upstream releases available [10:31] now we need to tools to automatically upgrade the upstream branch and so on [10:31] and do releases ;) [10:31] and procedures [10:31] that's great [10:32] 29th 1800 UTC iirc [10:33] I had a problem fetching sources from CVS repos, it will be great if you could shed few lines on it too :) [10:33] huh? about what? [10:33] CVS usage? [10:33] fetching the latest code. [10:33] tags and stuff. [10:33] ok [10:33] ill see how it fits in there [10:33] ok [10:34] Or maybe you could include Thunderbird extensions packaging too ? [10:35] phoenix24: yeah. that should be similar [10:35] yep [10:37] hmm ... maybe i should have added another sessino about "mozilla translations in launchpad - how it works and how to test" :) [10:39] yeah, I'd love to see attend that. [10:40] in the topic, "firefox b5 in final hardy? p > 95% :(" ; [10:41] What does "p>95%" mean ? [10:41] probability > 0.95 :) [10:41] ah! === asac changed the topic of #ubuntu-mozillateam to: https://wiki.ubuntu.com/MozillaTeam | Mailing List: ubuntu-mozillateam@lists.ubuntu.com | Mozilla QA tracker https://mozilla.qa.stgraber.org/ => please subscribe to help out | firefox b5 in final hardy? p == 100% :-D [10:42] shouldn't the topic be updated? [10:42] ah [10:42] just noticed ;) === asac changed the topic of #ubuntu-mozillateam to: https://wiki.ubuntu.com/MozillaTeam | Mailing List: ubuntu-mozillateam@lists.ubuntu.com | Mozilla QA tracker https://mozilla.qa.stgraber.org/ => please subscribe to help out | firefox b5 rocks! [10:42] :D [10:42] hehe :) [10:43] What's that? 0.0 b5? :P [10:43] Just kidding :) === asac changed the topic of #ubuntu-mozillateam to: https://wiki.ubuntu.com/MozillaTeam | Mailing List: ubuntu-mozillateam@lists.ubuntu.com | Mozilla QA tracker https://mozilla.qa.stgraber.org/ => please subscribe to help out | firefox 3 b5 rocks! [10:43] :) [10:46] jetsaredim: ok, can we have a bug about the firebug issue so we can start working on a -proposed update? [10:50] Jazzva: so how should the workflow for updating extensions work? [10:50] one probably runs a derivate of fta script to see which extension needs update [10:51] but whats next ;)? [10:51] If there's a new upstream, download it, extract it in upstream and then push it as upstrem branch ... that should be automatical :) [10:51] ok concur on that [10:52] And ... where are we gonna download from? a.m.o xpi, then unzip it? That's uniform for (almost) all extensions [10:52] but thats not even 10% of the work ;) [10:52] good question [10:53] we have extensions from svn/cvs atm ... and those from .xpi [10:53] most likely every extension should provide its own update target ... for which we can implement a default for AMO sources in xpi.mk [10:53] That would be good. [10:54] so if you have an extension with source from AMO you just would add a MOZ_AMO_ID=XXX to rules [10:54] If not, MOZ_SOURCE? :) [10:55] maybe a MOZ_GET_SOURCE_CMD would be good ... that would implement a default that uses the MOZ_AMO_ID to get the latest [10:55] and extensions could override it [10:55] Ok, since packagin doesn't change sources we could try to make a new dir, copy the new upstream and old debian dir there, and try to run the build. If it builds OK, the maintainer would be suggested to try it and see if everything works. [10:55] but that also means that we can only use the current script for AMO extensions [10:56] *packaging [10:56] current script? [10:56] Jazzva: yes, ftas [10:56] it only detects divergence based on AMO ids i guess [10:56] Oh... I think it does... [10:57] Well, that maybe isn't that big problem for now, I think there's only one or two extensions that are not on a.m.o... [10:57] yeah [10:57] most likely we need to blacklist them from auto upgrading [10:58] Mhm ... And to say that's not implemented for now :) [10:58] e.g. just a warning "this extension might need a manual update on branch X,Y,Z" [10:59] Jazzva: i think for testing auto upgrade we should upgrade .upstream [10:59] then run bzr merge ... and add a new changelog entry in that commit if no conflicts are detected during merge [10:59] Then comes the testbuild... I forgot we should unzip the chrome/*.jar, since most of them come with zipped chrome [10:59] then it should be pushed automatically to some staging area from where we manually push it to the release area once we have verified that it works [11:00] Jazzva: right ... i think the default upstream upgrade impl should properly deflate the upstream .xpi [11:00] pushed to bzr staging area :)? [11:01] yes, something like extension.ubuntu.hardy-backports.staging branch [11:01] if its supposed to go into the hardy-backports branch [11:01] Aha ... ok [11:02] We would need to provide a code in rules for jarring chrome dir, if it was unjarred. [11:02] Jazzva: right. i think the ubufox build.sh script should work for most cases [11:02] Same here :)... [11:02] Jazzva: actually we don't need that imo ... the current BUILD_CMD also delas with jarring up [11:03] i think we just need to figure how to unjar them in a way that the build script still likes it [11:03] hmm [11:03] What's the current BUILD_CMD? [11:03] Jazzva: each extension specifies that [11:03] for instance ubufox specifies "build.sh" [11:03] others use ant XXXX [11:03] Oh... What if the extension doesn't? ;) [11:04] Jazzva: if it doesn't then its shipping a .xpi in source [11:04] otherwise the xpi.mk won't work [11:04] or its not using xpi.mk ;) [11:05] Hmm ... I'm using xpi.mk for some, don't issue BUILD_CMD, and manually provide a rule for jarring/unjarring ;) [11:06] Jazzva: thats bad practice for sure ;) [11:07] hmm ... Didn't know about ant :) [11:07] he? [11:07] you can use anything you want [11:07] If the upstream doesn't provide a build script? [11:08] we add one in that case. you can also provide a rule in rules and call that fro CMD [11:08] That's what I did... although, I left xpi.mk to call it :) [11:08] like $(MAKE) -f $(CURDIR)/debian/rules RULENAME [11:09] Jazzva: in any case ... the rules file should be capable of jarring up [11:09] if there is no .jar [11:10] Ok [11:10] i don' think it matters for us [11:11] even if .upstream branch ships a .jar the merge should succeed unless we edit the .jar in ubuntu branch [11:11] its just important that the build matches the extract part [11:11] Yep :). After the testbuild... If it's ok, then it should be just tested; else, notify a maintainer to check the code? [11:12] Jazzva: right ... i think we need a tool that displays what .staging branches have updates [11:12] so a maintainer with power to merge and release can do that job [11:12] Jazzva: let me think about the error case :/ [11:12] hmm [11:12] Well, we could just modify fta's script to include check for staging branches [11:13] yes, but maybe we should not punch everything into a single script [11:13] but not sure what can go into a single script [11:14] Hmm, ok. We could make initial staging branches from current upstream, and then just check them [11:14] right [11:14] At the end of updataing cycle, if everything is ok, just push it to the upstream branch, and there we have it :) [11:15] bzr diff + a check for changelog version maybe [11:15] to the upstream branch? [11:15] you mean ubuntu branch? [11:15] Right :) [11:15] and *updating [11:15] ok, so how does changeing the packaging work? [11:16] Changing the packaging? [11:16] how does the script detect that a staging branch might be outdated? [11:16] Jazzva: well. in a perfect world we won't need to edit the .ubuntu branch [11:16] but maybe there are improvements to be done [11:17] now i do 0.2-0ubuntu2 in the .ubuntu branch ... but staging has 0.3-0ubuntu1 ... based on 0.2-0ubuntu1 [11:17] Check it's version ... check amo version ... if amo version > staging version, then it's outdated :) [11:17] (that's for the outdated) [11:17] Right, upstream could change the build script, or include some other directories, or change the package layout, or ... [11:18] hmm ... its not about the upstream version, but about the -packaging revision [11:18] 0.3-0ubuntu1 on top of 0.2-0ubuntu1 would still be higher than 0.2-0ubuntu2, but it would have an outdated packaging [11:18] but i have an idea [11:18] Hmm... why would we use 0.2-0ubuntu1 packaging, if we have 0.2-0ubuntu2? [11:19] Shouldn't the ubuntu branch contain 0.2-0ubuntu2 already [11:19] ? [11:19] Jazzva: because that might be what the auto upgrade script did for us [11:19] Jazzva: its probably not instantaneous [11:19] e.g. there might be time where its out of sync (for a day or so) [11:19] we should be able to detect it [11:19] but i think its easy [11:19] branch the .ubuntu branch [11:20] try to _pull_ the staging branch [11:20] if that hsa *diverged* we are out-of-sync and should wait for the next merge to happen [11:20] but still the script would need to recognize that it should trash the current .staging and remerge the latest upstream to the latest ubuntu branch [11:21] Sounds good ... [11:21] And not too complicated :) [11:23] So, we have the process done, but without the error cases, right? [11:23] dholbach: thanks. [11:23] hi asac [11:24] Jazzva: i think so yes [11:25] Yay :). Just to think of all the possible error cases... [11:25] *Now just ... [11:26] Jazzva: so rehab: auto upgrade upstream branch [11:26] how? [11:26] I'll have to go in 5-10 minutes ... School from 14:00. I think I will be back around 18, 18:30... [11:27] ok fine [11:27] lets talk then later [11:27] Auto upgrade upstream :) [11:28] so... if we're doing everything in staging branch, then we can check the if amoversion > staging version. If it is, then download the source from amo, use it in staging branch, and at the end, push the clean source to the upstream branch... [11:28] I think... [11:29] asac ^ [11:30] Jazzva: yes. that sounds sane [11:30] Jazzva: so we only support a default source layout? [11:30] I've a problem that ff 3.0b5 segfaults for me (hardy amd64) during startup. the interesting thing is that if I remove extensions.cache from my profile or start firefox -safe-mode once (and quit it immediately), I can start firefox without problems (but only once) and second start segfaults again [11:30] what could that be? [11:31] geser: Bad extension(s)? [11:31] geser: what locale are you using? [11:31] LANG=en_IE.UTF-8 [11:31] what is IE? [11:32] ireland [11:32] geser: what language pack is that? [11:32] is that any? [11:32] asac: "default source" as in "chrome with contant, locale, skin dirs and stuff"? Hmm, if the upstream doesn't change the source layout, then we could handle all :). [11:33] Jazzva: i just wonder about the jar thing now ;) [11:33] but maybe we can always extract any jar to a dir like $JARNAME!/ [11:33] asac: the addons window listen en-GB (for firefox and xulrunner) at languages [11:34] asac: I think I handled it ok in rules files ... even if it's a bit "wrong" ;) [11:34] Let me paste how I did it :) [11:35] geser: hmm i doubt that its due to the locale. we don't have a gnome-en-gb language pack [11:35] geser: does moving away your profile help? [11:36] e.g. fresh profile? [11:36] asac: it's not the prettiest zip commands ever, those should be changed :)... http://paste.ubuntu.com/7755/ [11:37] asac: fresh profile works [11:37] geser: try to disable extensions one by one and see which causes this crash [11:37] geser: firebug? [11:38] asac: As far for the xpi zip, I think the main point is to exclude debian/ and temp-xpi-*/ dirs. [11:38] Jazzva: i think the layout is too specific [11:38] asac: firebug was a good guess. Known issue? [11:39] geser: yes. do you have adblock as well? [11:39] i think the combo is pretty painful [11:39] asac: Ok, I'll think about producing jar and xpi files today :). Off to school now... [11:40] adblock plus 0.7.5.4 and firebug 1.1.0b12 [11:40] we will push a new upstream version to -proposed once jetsaredim comes around ... maybe stay here so we can ask you to verify that its gone [11:40] See you later [11:40] geser: yes, thats a known thing then [11:40] Jazzva: good. cu later [11:41] geser: ill try to remember to ask you to verified the -propsed update [11:41] ok [11:41] geser: you could try the latest firebug upstream release (1.2.0) that came out two days ago or so [11:43] asac: where? www.getfirebug.com lists 1.0 and 1.1beta [11:44] geser: not 100% sure, jetsaredim would know better. what i find is http://getfirebug.com/releases/firebug/1.2/firebug-1.2.0a21X.xpi [11:45] geser: https://code.edge.launchpad.net/~jetsaredim/firefox-extensions/firebug.ubuntu [11:45] try tat [11:46] that [11:46] just debuild -b it [11:46] thats the suggested update for -proposed afaict [11:47] asac: I tried the xpi and firefox doesn't crash anymore (and firebug seems to work again) [11:47] geser: could you uninstall that xpi and try that branch as well? [11:47] should be just a minute or so to build and install and would help me to get confidence about it ;) [11:48] yes, wanted to do that just now [11:48] thanks [11:48] maybe open a bug against https://bugs.edge.launchpad.net/ubuntu/+source/firebug which we can name in changelog [11:48] to gather feedback in -proposed [11:49] let me open a bug [11:50] geser: bug 220562 [11:50] Launchpad bug 220562 in firebug "frequent crashes with firebug 1.1.0" [Undecided,New] https://launchpad.net/bugs/220562 [11:51] maybe confirm it ;) [11:52] ok i added the branch to the bug as well [11:53] ok subscribed you geser ;) [11:58] asac: I tried to build the firebug package in a uptodate hardy pbuilder -> FBTFS http://paste.ubuntu.com/7757/ [12:00] geser: please comment on bug then. jetsaredim will fix it i guess [12:00] thanks [12:01] i updated the branch whiteboard on the bug already -> * FTBFS [12:01] but comment won't hurt ;) [12:02] the archive is now locked down anyway, so i guess we have another two days before we need a real fix [12:02] but good to know that upstream xpi at least fixes it [12:03] jetsaredim: remember to look at bug 220562 [12:03] Launchpad bug 220562 in firebug "frequent crashes with firebug 1.1.0" [High,New] https://launchpad.net/bugs/220562 [12:08] bug commented, anything still missing? [12:11] geser: i think thats all for now. stay tuned ... the bug will surely have some activity soon. [12:19] asac: I think there is some sort of disconnect in their build system [12:20] jetsaredim: disconnect? [12:20] what does that mean? [12:20] broken? [12:21] eh - looks like they updated the svn since yesterday [12:21] which would account for the version differences [12:22] jetsaredim: the build failure is in the bzr branch. [12:22] the package that i built was 1.2b20 [12:22] no sure that i understand why thats related to upstream svn [12:23] build failure? [12:23] yeah :-P [12:23] jetsaredim: read bug 220562 [12:23] Launchpad bug 220562 in firebug "frequent crashes with firebug 1.1.0" [High,Confirmed] https://launchpad.net/bugs/220562 [12:23] i just read it a minute ago - must not have sunk in though i guess [12:24] hehe ... yeah, i frequently fail to believe what i see too ;) [12:24] lemmie try in a clean dir [12:36] wow - something's screwy [12:36] must have missed a commit somewhere [12:37] cause what's in the dir I was using builds [12:37] but when I branch from my branch - it doesn't [12:44] jetsaredim: no worries ... we have 2 days to fix :) [12:58] hmm [12:58] helps when you add all new files [12:59] i thought I had done that - but apparently not [12:59] ;) [12:59] in .upstream or ubuntu? [12:59] if .upstream pleaes update .upstream and merge over again [13:02] jetsaredim: ^^ [13:02] * asac prepares for lunch ;) [13:16] ok - i've updated the ubuntu branch [13:17] jetsaredim: ill look after lunch. thanks [13:17] * asac out for lunch [13:26] geser: have a look at the new branch and let me know [13:31] jetsaredim: rev23 builds and works fine [14:15] geser: excellent [15:03] jtv: there? [15:03] jtv: i think we need a midbrowser template enabled. what would be the steps to get this? [15:03] asac: here [15:03] hi! [15:04] asac: "midbrowser"... as in MID browser? [15:04] yeah [15:04] its basically firefox + a few strings [15:04] And by "enabled," you mean "imported? [15:05] jtv: well. no clue ;) ... if there is nothing to be done up-front we can directly go and import the template, right. [15:05] thought maybe there is something needed to enable midbrowser template. [15:05] Probably. It's probably a bit of an exceptional situation, so some hackery may be in order. [15:05] I have _no_ _idea_ what a midbrowser template involves. [15:06] jtv: its en-US.xpi [15:06] like what we have for firefox and xulrunner [15:06] Plus extra strings... different translations as well? [15:07] we don't have translations for the strings that came on top of firefox [15:07] thats what we want to do in launchpad [15:07] the midbrowser en-US.xpi is firefox en-US.xpi + a few more strings in there [15:07] asac: if that is more or less guaranteed, could you treat it simply as a superset of Firefox? [15:08] In other words, pretend like all firefox is firefox-mid, and let the regular firefox ignore some strings it doesn't know about? [15:08] hi all. i'm rebuilding firefox 3 from the hardy repo with some changes. its finishing after ~2 or 3 minutes. is this how it should be? firefox 1.5 took an hour. i do notice that xul is gone, but even so i'm worried Stuff Is Wrong. [15:08] jtv: no, we shouldn't couple those too tightly. the releases might diverge [15:08] :( [15:08] further it needs a special en-US.xpi [15:08] * jtv thought he was soo smart [15:09] otherwise we cannot produce value midbrowser langpacks as the install.rdf is different [15:09] asac: right now, Launchpad doesn't give a hoot about the install.rdf [15:10] so your scripts could replace it in the template that's copied into the exports. [15:10] jtv: we use the en-US.xpi we get from midbrowser [15:10] grumble [15:10] jtv: whats the problem of making midbrowser has its own template? [15:11] Shouldn't be a problem, really, except I don't know off the top of my head how the auto-approval logic will deal with it. [15:11] You should be able to have two templates in the same product/package, but it'd be a pain if each upload required a manual approval. [15:12] jtv: why would i need two templates in the same product? [15:12] jtv: i just want to have midbrowser as its own application [15:13] approval is something intel has to do [15:13] asac: oh, I assumed that was what you wanted. Are you talking about two separate products/packages? That's easy. [15:13] no ... its completely separate [15:13] asac: in that case, forget what I said. :) [15:13] its just that we could use the firefox translations to get initial translations [15:13] for most of the strings [15:13] :) [15:13] That should be a doddle, yes. [15:13] approval is not a big problem because we can push this to intel folks [15:14] i just want to provide them the infrastructure to do the translations :) [15:14] Well, approvals on the translations import queue go through Yours Truly [15:15] oh ... me? [15:15] But after the first approval, if the templates live on separate products/packages, auto-approval should just work. [15:15] jtv: ok. so what would be required to enable midbrowser being a project that supports en-US.xpi templates? [15:15] asac: no, Yours Truly means "the person writing this." It's a joke about the traditional way to finish a letter. [15:15] ah ;) [15:16] asac: just set up a regular product and upload the XPI. [15:16] jtv: ok. www.launchpad.net/midbrowser thats the project i have [15:16] can i just enable translations there? [15:16] asac: sure, or you can do the uploads first. [15:17] jtv: ok, you pointed me to tools that help to upload. are those required? [15:17] asac: no, not at all. Just there to help, but they're built on top of the http[s] UI. [15:18] jtv: ok, so i basically can just go to https://translations.edge.launchpad.net/midbrowser/trunk/+translations-upload and upload the en-US.xpi ? [15:18] asac: exactly [15:19] asac: there won't be any automatic cross-pollination of translations, except of course that the translations from the one will show up as suggestions for the other. [15:19]