[00:00] i wish gwibber had a way to show URLs fully resolved, like the Attachments in the identi.ca web pages [00:02] me too [00:02] I hate short links [00:03] I think I have a bug for that [00:08] hm, sometimes, when i want to submit a dent, gwibber just adds a carriage return in the textfield but doesn't send anything [00:12] eheh [00:12] I'm back on 1.2 [00:12] I couldn't take it anymore [00:38] http://arstechnica.com/tech-policy/news/2009/09/does-less-evening-internet-mean-europeans-lead-better-lives.ars [01:31] asac, all-in didnt appear on NEW [01:31] asac, plus I received no NEW mail [01:32] asac, something went wrong then [01:32] going to sleep [01:32] cya tomorrow [08:46] * asac goes and gets some coffee === zbraniecki is now known as gandi [09:45] ejat: there? [09:45] bdrung: hi! [09:45] bdrung: saw you got added to the team ... congrats ;)! [09:53] bdrung: did your MOTU application work out well? [10:08] asac, aren't MOTU nearly dead? i mean, with the archive reorg in progress [10:14] d'oh! http://www.youtube.com/watch?v=0qqxjO5nr8k&feature=featured [11:00] morning gnomefreak [11:08] asac, hi [11:09] asac, had a problem with the upload yesterday? :) [11:26] andv: no orig [11:26] its now done [11:27] asac, yeah :) [11:27] saw it on new [11:32] hey asac :) [11:45] hi eagles0513875 [11:46] how goes it asac [11:48] pretty good ... still catching up a bit on vacation stuff ;) [12:23] ok how the hell do i get normal gwibber back? [12:27] asac: thanks. the MOTU application was deferred because they had no quorum [12:28] bdrung: during meeting? [12:28] hmm [12:28] gnomefreak: no way ... just keep using it ;) [12:29] asac: i cant figure out how to send message [12:29] brings you down to next line to type [12:29] asac: no, before :) [12:29] gnomefreak: i dented about that and got an answer [12:30] gnomefreak: http://identi.ca/notice/9277389 [12:30] thanks lookinhg [12:30] http://identi.ca/conversation/9276118#notice-9277389 [12:30] I DONT LIKE IT [12:31] asac: i cant move it up [12:31] there's a pref in the menu [12:32] not here there isnt [12:32] at least not in pref [12:32] i have same ui for new as was for old versions [12:33] for pref [12:33] not in pref, just View / Editor [12:33] fta2: i can typw but i cant send it [12:33] s/typw/type [12:33] it's enter, as before [12:33] fta2: brings me down a line in editor [12:33] but sometimes, it just adds a carriage return [12:33] it's a bug [12:34] scroll up, and enter [12:34] same thing [12:35] gnomefreak: you can drag it up ... just try a bit more ... its tiny grab thing like where the separator line is right at bottom [12:36] asac: not here it just brings the text back to editor as if it is not permitted [12:36] well then you already have the editor [12:36] which was what i didnt have [12:36] sending worked for me [12:36] i have editor since i typed in it but no way to send it [12:37] iirc, View / Editor is disabled by default, which is bad [12:37] gnomefreak: i hit enter and it works [12:37] i have the editor that part i knew from other releases its sending it that isnt working [12:38] fta2: for the searchplugins we actually should add replaces to all lower firefox versions on all firefox branches i think [12:39] or we should get rid of the common firefox-addons/searchplugins dir [12:40] asac, or make a dedicated src package [12:40] yeah [12:40] cant clear window either let me see if there is an update for it [12:42] bug in apturl too :( [12:45] asac, i like the dedicated source package, so we can add/remove/update searchplugins independently of ff [12:46] fta2: technically i agree. problem is that it bears the risk that we miss if upstream changes their default searchplugins [12:47] and we are obliged to have them unless we explicitly applied/communicated for a change [12:47] wonder if there is a way to add a safety net [12:47] like "if we are package that ship default package, verify that the searchplugins in the other package are all the same" [12:48] we can just pull that from trunk, like today [12:51] thats not what we do today [12:51] we pull them from the branch of the package installed [12:51] the package with highest version is supposed to win [12:51] but in default install we have the plugins of firefox-3.5 as shipped by upstream unless someone installs firefox-3.7 et al [12:52] so i guess we should need to pull them from current default branch [12:52] 3.7 doesnt provide those searchplugins, just a link [12:52] as thats where mozilla wants trademark being inforced [12:53] fta2: yes. so i think what we should do is provide a firefox-searchplugins package which is produced from the same package where we have the meta package [12:53] does that sound about right? [12:53] and everything depends on firefox-searchplugins in turn [12:53] yes [12:54] ok so no standalone source package [12:54] just an unversioned package for the current METAPACKAGE thing [12:54] at some point we probably want to assemble debian/control on-the-fly ;) [12:54] hehe [12:58] jdstrand: so at best the apparmore profile feature would become independent from the firefox version by some template magic [12:58] i would like to able to just land it in firefox-(3.0?)/3.5/3.6/3.7 [12:59] jdstrand: ok ... so i think the general 3.* and 1.9* things can be kept that way [12:59] but the firefox-3.5.* would probably be better replaced during build with @DEB_SOURCE_PACKAGE@.* or something [13:00] if it makes things cleaner (as we use templating anyway) we could also replace the 1.9* and 3.* with proper template things [13:01] asac: I'm cool with that conceptually, but will it make it too easy to not verify it? I intentionally did it this way so someone would need to look at it. ie, 3.0's profile didn't work with 3.5 [13:01] it mostly worked, but needed tweaking [13:04] jdstrand: yes. but we usually have those branches right from day zero where 3.5 == 3.6 for instance [13:04] jdstrand: so its more a continous process anyway [13:04] so assume we have it for firefxo-3.6 and then 3.7 got created the files would be the same anyway without verification needed [13:04] only while upstream changes we need to adjust [13:04] so i dont think it provides a safety net for us [13:05] asac: if that works better with your process then I'll update it [13:05] would be precious. let me check if i can see something else [13:12] jdstrand: not sure if i am just confused, but isnt [13:12] + if [ ! -e "$APP_CONFFILE" ]; then [13:12] + ln -sf $APP_CONFFILE $APP_DISABLE [13:12] wrong? [13:13] e.g. APP_CONFFILE does not exist => then we link it? [13:13] it looks wrong but isn't [13:13] shouldnt it be the other way around? [13:13] it is based on https://wiki.ubuntu.com/ApparmorProfileMigration [13:13] the idea is this happens in preinst, and we know our package supplies the file after unpacking [13:14] so yes it dangles for a second, but then is resolved at unpack [13:15] keep in mind ApparmorProfileMigration is mostly geard for files moving from apparmor-profiles to a package which provides its own profile, but many of the ideas are the same [13:16] you think we can use $0 in the pre/post stuff to prevent templating there? [13:16] e.g. for firefox-3.5 etc. [13:16] ? [13:18] hmm postinst.in is alrady a template. so i guess we are fine with making .in out of everything [13:19] asac: I should be able to do something with preinst [13:19] asac: I'll work on making it all generalized [13:20] jdstrand: thanks. i dont like all the maintainer script stuff, but if its really needed then i am fine with the changes once they are generic [13:22] asac: the idea is to protect the user. if they upgrade from jaunty to karmic, the profile is disabled. if they already have a profile they wrote or they upgrade from karmic to karmic-security we don't want to automatically disable it again [13:23] that said, I'm confident I can generalize it [13:25] jdstrand: yes. i figured that and accepted it ;) [13:25] all fine [13:26] jdstrand: you might want to investigate at some point if you can do some debhelper magic to automatically add the right snippets [13:26] so you dont need to duplicate all the things in all maintainer scripts ;) [13:26] but not karmic topic of course [13:26] dh_installapparmor ;) [13:26] or something [13:27] yeah, the problem is they tend to be different enough for each package... but it has been something I've thought about [13:27] thanks :) [13:28] no problem ;) /me likes giving easy advices for not-so-easy things :) [13:30] !grub2 [13:30] GRUB2 is the default Ubuntu boot manager in Karmic. For more information on GRUB2 please refer to https://wiki.ubuntu.com/Grub2 [13:46] jdstrand: you think i should wait for the karmic ppa security upload for your new merge request? [13:47] i think release is still 1-2 weeks away so we can wait a bit if you would like to get that into the first .14 upload [13:48] asac: well, I'd personally like it sooner than later, but I'll leave ff release management up to you :) [13:48] jdstrand: we only ship profile in firefox package right? not xulrunner? [13:48] asac: correct [13:48] jdstrand: when do you think can you do the generalization? [13:48] asac: I'm building a package with my changes right now [13:48] so... soon? [13:48] :) [13:50] great [13:50] i will wait a bit then [13:50] asac: do you have any objections to me adding something to the apport hook? [13:51] asac: I did it with evince and it has worked out fantastically [13:51] (is that a word?) [13:53] jdstrand: i am happy to retrieve apport hook love [13:53] ;) [13:53] of course depends on what you want to append ;) [13:53] cool, I get that going then too [13:53] no root passwords for instance :) [13:53] heh [13:54] in general who last touched the hook owns it until someone else touches it ;) [13:54] eek [13:54] that is a big committment! [13:55] not so big [13:55] just a joke ;) [13:55] :) [14:18] fta2: i think there are localized search plugins in the locale hg tree ... which are not in the .xpi translation packages we ship === asac_ is now known as asac [16:09] asac: ok, I committed r459 for apparmor/firefox [16:10] asac: it should be generalized completely [16:10] asac: it also will add apparmor stuff to the apport report if the profile is not disabled [16:11] asac: https://code.launchpad.net/~jdstrand/firefox/firefox-3.5-apparmor/+merge/11061 [16:12] let me check [16:12] asac: I think I did all the LP right this time too, so the 'Review Diff' should now be accurate [16:12] yeah saw that the other is properly marked as superseded ... well done ;) [16:12] heh [16:12] jdstrand: have you tested the apport hook? [16:13] this also smeels like something that could be factored into apport general package i think [16:13] asac: yes, works great (both when disabled and enabled) [16:13] we have similar generic functions for wifi etc in there now [16:13] jdstrand: thx for confirming [16:13] asac: yeah, I thought of that too, but too late for FF [16:13] (on my todo) [16:13] imo thats not FF relevant ;) [16:14] but thats just me ;) [16:14] I'll talk to pitti when I have more time, and if I can get to it, I will and will update this packaging [16:14] the feature is there ... just not in the central apport hook library ;) [16:14] * jdstrand nods [16:15] jdstrand: no problem [16:16] [ Jamie Strandboge wrong (i will fix it during merge) [16:16] ;) [16:17] asac: fyi, I compared all the old maintainer scripts with the newly generated ones and they're the same [16:17] asac: re changelog> oops! :) [16:17] thanks [16:19] asac: fyi, I fixed the typo in debian/changelog in r460 [16:20] jdstrand: there is also DEBIAN_NAME_OTHER ... for abrowser ... not sure if we can make that work easily ... without copying the full block [16:20] asac: oh, I forgot-- you probably should wait to upload until the next kernel is uploaded [16:20] jdstrand: what will happen with old kernels? [16:21] asac: as it is disabled by default, nothing, but if someone enables it, it won't load cause I use PUx for evince [16:22] jdstrand: there is no new dependency added [16:22] is that because its installed by default? [16:22] since when are the binaries used available? [16:22] asac: not a huge issue-- the patches are committed to the kernel and just awaiting upload [16:22] like aa-... ? [16:23] asac: this will work fine without apparmor installed, so no Depends or Recommends. sometimes I add a Suggests, but didn't here [16:23] (tried to keep the packaging changes to a minimum) [16:24] jdstrand: but it calls apparmor_parser and aa-status without checking that the binaries actually exist [16:24] hmm ... but only if APP_PROFILE exists for postinst [16:24] jdstrand: point is that we build the .head branch everywhere: hardy - karmic [16:25] so if possible it would not break there ;) [16:25] ok seems ok [16:25] asac: well, 'aa-status' will fail if it isn't around [16:25] do you see anything that might break? [16:25] yeah true [16:25] and I 2>/dev/null it [16:26] asac: I'm reminding you about the fixed-3.5.3 and fixed-3.0.14 tags [16:26] asac: this is the same recipe I use all over the place [16:26] I saw the branches committed for the next ff release [16:26] micahg: huh ;) [16:26] asac: I have tested it here and am comfortable with it [16:26] thanks [16:26] micahg: that was last minute ;9 [16:26] asac: I'll of course fix anything that breaks [16:26] micahg: though i already uploaded xulrunner ;) [16:26] but thats ok i guess [16:26] next time i should remember it better [16:27] jdstrand: ok. i think its ok. lets merge it and see if the daily mob shouts ;) [16:27] heh [16:28] jdstrand: but we need to fix abrowser later [16:28] does the name need to match the binary? or just this: /usr/lib/@APPNAME@.*/firefox { ? [16:28] oh its referring to firefox [16:28] /usr/lib/@APPNAME@.*/firefox [16:28] so i guess only question is if usr.bin.firefox.apparmor [16:28] has any meaing [16:28] but i guess not [16:29] ok great [16:29] lets go for it [16:29] whatever uses that binary is confined [16:30] jdstrand: ok merged ... i will check if its easy to just pull that over to 3.7 and 3.6 branch and if not i will poke you ;M) [16:30] asac: if it makes sense to rename the profile to simply apparmor.profile, we can do that. [16:30] asac: cool, I will be more than happy to fix anything wrt this [16:30] asac: thanks for the review and merge! :) [16:31] micahg: bug 236853 ... is that really fixed by ffox? not by nss? [16:31] Launchpad bug 236853 in firefox "firefox crashed with SIGSEGV in NSSRWLock_LockRead_Util()" [Unknown,Fix released] https://launchpad.net/bugs/236853 [16:31] * asac checks upstream bug [16:32] ok its fixed in ffox/xul [16:32] thx [16:33] I just followed whatever they said upstream [16:36] micahg: documented. thanks a bunch for that ;) [16:36] micahg: you were right. [16:43] are they actually releasing 3.0.14 or did it go t oRC? [16:48] asac: I made my patch better, but now it fails to build for bug 66015 [16:48] http://launchpadlibrarian.net/31218684/buildlog_ubuntu-jaunty-amd64.xulrunner-1.9.1_1.9.1.2%2Bnobinonly-0ubuntu0.9.04.1~ppa10_FAILEDTOBUILD.txt.gz [16:48] Launchpad bug 66015 in hundredpapercuts "Duplicate spell checking dictionaries for every entry" [Low,Confirmed] https://launchpad.net/bugs/66015 [16:48] micahg: beta [16:48] ok [16:48] usually it goes 1-2 weeks before release to beta channels [16:48] thats when i try to upload stuff to PPA [16:48] if all goes well they dont respin and the same binary will be the release [16:49] jdstrand: remember to mark your branch as merged (if launchpad didnt do that yet) [16:51] asac: done [16:52] asac, here's the new patch http://pastebin.com/f3982e877 [16:53] Apparently, I don't have PRUniChar loaded [16:55] micahg: but thats still the same approach [16:55] how about the idea replacing _ with - (or vice versa) [16:55] and then checking whether a dictionary with that name is alread in the mDictionaries map? [16:55] btw its PRUnichar [16:55] ah [16:56] why not stop it at the source though [16:56] prevent the file from loading [16:56] the file isnt loaded if you dont put it in the dictionarie [16:56] my original patch actually worked [16:57] ok [16:57] why not use a simpler patch though? [16:57] because its fragile [16:57] nobody knows what is wanted [16:57] why? [16:57] _ or - [16:57] ah [16:57] so better safe than sorry [16:57] and allow both [16:57] I can add a commet [16:57] oh [16:58] that's what you mean [16:58] I looked at the upstream binaries [16:58] and they ship - in the files [16:58] it seems to be a mozilla thing [16:58] just allow both variants, but just normalize the key [16:58] (e.g. dict) [16:58] the other alternative is to resolve an eventual link first [16:58] well [16:59] like if file == link -> resolve ... then use leafName, normalize like discussed (e.g. replace _ by -) [16:59] what I'm wondering is why it doesn't display the whole name for the _ dicts but does for - [16:59] micahg: that logic was at the other place [16:59] ah [16:59] what bug id was it again? [16:59] bug 66015 [16:59] Launchpad bug 66015 in hundredpapercuts "Duplicate spell checking dictionaries for every entry" [Low,Confirmed] https://launchpad.net/bugs/66015 [16:59] the other patch touched the source that assembles the name [17:00] would that type of patch be worthy of upstreaming then? [17:00] content/global/inlineSpellCheckUI.js [17:00] micahg: http://launchpadlibrarian.net/31020349/inlineSpellCheckUI.patch shows that it only shows the full name for "-" most likely [17:00] at least thats what is processed properly [17:00] (without that patch) [17:01] ok [17:01] micahg: what are the links for us? [17:01] so I'll work on it tongiht [17:01] the _ or the -? [17:01] - [17:01] _ is the normal file [17:01] - are links to the _ files? [17:01] hmm [17:01] apparently the ISO standard is _ [17:01] but mozilla likes - [17:01] ok so what we want is to use the dict key normalization to use "-" (because thats what mozilla uses) [17:01] ok [17:02] I have to leave for work soon [17:02] and then we want to first split with "-" [17:02] so I'll work on this tonight [17:02] so i think in best case we dont need to touch the .js [17:02] yeah [17:02] i think you dont need to resolve the link [17:02] though upstream might want us to do that [17:03] but lets first try to just normalize to use "-" as the key [17:03] and check that for (var i = 0; i < list.length; i ++) { [17:03] ok [17:03] list here is that key [17:03] but i think its right then [17:03] as long as we normalize to use - [17:03] ok [17:03] BTW, is ABrowser the official branded name of the unbranded browser? [17:04] we have bug 413076 [17:04] its our unbranded browser name [17:04] Launchpad bug 413076 in firefox-3.5 "abrowser: Change menu label to just "Web Browser"" [Undecided,New] https://launchpad.net/bugs/413076 [17:04] there is no official unbranded branding ;) [17:04] so, can we change the menu to ABrowser vs A Web Browser so it doesn't seem so weird on other languages? [17:06] abrowser was ment to be short for "A Web Browser" [17:06] it was considered rougue to just use "Web Browser" [17:06] because other browsers would then want that name too [17:06] yes, but if it's like that, it would seem that it should be localized in other langauges [17:06] i will think about it [17:07] not if "A Web Browser" is considered a brand name [17:07] but well [17:07] oh [17:07] oops [17:07] ;) [17:07] got it mixed up [17:07] it is translating it [17:07] yeah [17:07] but only patially [17:07] so technically its right [17:07] *partially [17:07] question is if the bug has a point about confusion. i dont think so for now [17:07] but have to think more [17:08] ok [17:08] ok to mark as triaged then? [17:08] yes assign it to me and triaged stating this is pending decision [17:09] you can also project that we probably won't go for just "WebBrowser" [17:09] Rather "A Browser" ;) [17:09] given the rational against taking Web Browser from above [17:09] I was thinking without the space and have it be an actually name - ABrowser [17:09] Yeah [17:10] but firefox == "Firefox Web Browser" .... abrowser = "A Web Browser" or "ABrowser Web Browser" [17:10] which would be odd too ;) [17:10] * micahg likes the last one actually [17:10] ABrowser web browser [17:10] then the description can be localized [17:10] but the name remains [17:10] we intentionally picked the most generic name so we wont need to enforce any trademarks on it as its probably not trademarkable on its own [17:11] yeah [17:11] but ABrowser Web Browser is double ;) [17:12] do you think it's worth throwing up on brainstorm? [17:12] definitly not [17:12] thtough branding discussion in the wild and you get a fully raged rant [17:12] everybody in the end being unhappy [17:12] ah, right [17:12] * micahg remembers the Shiretoko rants [17:34] micahg: fyi: https://developer.mozilla.org/en/XPCOM/Strings [17:34] Mozilla internal string guide [17:35] https://developer.mozilla.org/en/String_Quick_Reference [17:47] * mac_v seems nothing rogue about using "Web Browser" [17:47] *sees [18:12] mac_v: we would claim a generic name that other browsers would want to use if it was open for discussion [18:12] so everyone agrees to not use such a generic name [18:39] hmm... too bad , now we have to confuse the user ;p [18:49] mac_v: ?? [18:50] micahg: the "AWeb Browser" , i was replying to asac ;) [18:50] sorry, I must've caught the last line of that [19:49] asac, http://launchpadlibrarian.net/31252914/buildlog_ubuntu-intrepid-i386.firefox-3.7_3.7~a1~hg20090902r32157%2Bnobinonly-0ubuntu1~umd1~intrepid_FAILEDTOBUILD.txt.gz [19:54] asac, all-in-one accepted [19:55] asac, I pinged a friend, who is ftp-assistant [19:55] ;) [21:55] andv and asac: thanks a lot for your help and sponsorship getting all-in-one-sidebar into Debian [21:55] ;) [21:56] sveinung, np [21:56] :) [21:56] sveinung, let me know when there will be a new upstream release [21:57] andv: sure [21:57] sveinung, I gonna sponsor the package from now on [22:07] sveinung, do you know how Debian BTS work? [22:08] andv: yes, at least part of it [22:08] ok, both me and you will receive bug mails [22:08] ok [22:08]