[00:02] Mook_sb: yeah. thats kind of tough ... but interesting [00:03] and yeah. seems like they want to shake off all reuses of their platform [00:04] i am not sure they want. but this way will probably mean there is no chance for embedders or even other xulapps to keep up to speed [00:05] but its also consequent ... and i personally accepted that this will happen [00:05] they're having trouble with their own apps keeping up SM/TB [00:06] I guess that's why everyone's migrating away from GRE [00:07] i guess TB will survive a bit longer [00:07] than SM [00:08] well, the SM team is hyped up about the new release [00:08] they plan on launching soon [00:08] hyped up? [00:08] ah [00:08] ok [00:08] very excited [00:09] sure. the problem is that last release was from same branch as ffox 2.0 [00:09] so it took till now to get the new release done [00:09] granted, there was quite some work done too (not just porting) [00:09] but now they hear that they need to get things ready for 1.9.2 ... :) [00:10] yeah, well, we're kinda in the same boat as they are in terms of migration (granted our migration is a little easier) [00:12] easier? [00:12] cool [00:12] i have need help porting hardy to 3.6 [00:12] ;) [00:13] are we going to try to do that? [00:13] and yes. we sit in the same boat ... but more on the outside ;) [00:13] Tb3 is pretty awesome, fwiw [00:13] yes it is [00:13] only thing is mem consumption [00:13] but the new search rocks ;) [00:14] the UI is a bit inconsistent ... i would think in the long run the main mailvinwdow will move more in a similar direction [00:14] micahg: we kind of have to [00:14] reinvent ourselve. tracking full upstream releases [00:15] because it's LTS? [00:15] somehow ... dont ask me how now [00:15] micahg: yes. 1.5 years to go when 3.0 goes eol [00:16] but same for jaunty [00:16] but i think hardy is a bit tougher [00:16] yes, but jaunty has 3.5 already [00:16] micahg: jaunty doesnt have 3.5 [00:16] yes it does [00:16] it has a preview ... [00:16] in universe [00:16] yes. its not a so big issue to move the app [00:16] it's the same app with the branding turned off [00:17] but we also have other embedders that use the same rendering engine [00:17] we probably have to port all apps that have remote content exposure [00:17] ugh [00:17] thats probably the minimum set we can argue. and all apps that are in main of course [00:17] that means backporting what we jsut did for karmic to jaunty [00:17] and hardy [00:17] micahg: only that in hardy there are more apps ;) ... asa webkit is almost non-existing ;) [00:18] and in jaunty too [00:18] i think hardy has the most [00:18] with intrepid having no real difference [00:18] and jaunty slightly less because webkit started to grow [00:18] but epiphany in main is a mess [00:18] the 1.9.1 port will be not so nice ;) [00:19] and epiphany-webkit is not feature complete enough to just drop that in as a forced replacement [00:19] what is debian doing with this stuff? [00:19] they probably will surrender. usually i gave them all the backports i made [00:19] and even did the uploads [00:19] now they ride the upstream minor updates [00:20] but major updates will be a tough thing for them [00:20] if not impossible [00:20] asac: http://browsing.justdiscourse.com/2009/10/08/debug-version-of-prism-1-0b2-for-ubuntu/ [00:20] so debian will be back where they were when i startred to do security support for mozilla like a bunch of years ago ... no security support [00:20] ugh [00:20] maybe we can help them with our patches [00:21] what will they do with epiphany htough [00:21] but its even tougher for them [00:21] they also need to get all archs properly working [00:21] micahg: epiphany is gecko ... so they dont have suport. in future its webkit so thats ok [00:21] no, I meant epiphany in debian [00:21] i think they will not release mozilla at all [00:22] or go the same road as we do [00:22] no r-depends [00:22] and major updates [00:22] micahg: yes. in debian its also gecko ... and if they cannot support xulrunner its automatically not supported [00:22] but debian does only support "1 year" after relase of stable [00:23] so they will be off the hook sooner than we will ;) [00:23] one thing is clear. in lucid we need to have everything in place so we can ride the usptream releases for 3 years ;) [00:24] well, easiest is to go back to just "firefox" and push every update [00:24] yes. but we need to get all the xulrunner consumers with remote access out of the archive too [00:24] but then you can't package extensions [00:24] just firefox isnt good enough [00:24] i am not cared about firefox [00:24] that will sort out on its own [00:24] just the rest [00:24] ah [00:24] but i guess we just need to be harder about killing apps that use gecko [00:25] I was wondering, why are you trying to get more extensions in the archive anyway? [00:25] e.g. removing from archive [00:25] if we can't reliably update them during the release cycle [00:25] we could ;) [00:25] a matter of resources [00:25] but basically the idea is: if they work at release time [00:26] they shouldnt stop working while release is maintained [00:26] so they deliver a "stable" experience [00:26] stable in the sense that you know the bugs and you dont get new bugs tomorrow [00:27] yes, but stuff like noscript where they find new vulnerabilities all the time [00:27] don't get updated [00:27] thats a mistake [00:27] and needs fixing [00:27] version in archive 1.9.2.8-1ubuntu1 latest: 1.9.9.11 [00:28] can you automate extension building from amo? [00:28] s/you/we/g [00:28] like we do the dailies [00:28] but maybe weekly instead of daily [00:28] in general i agree that we should balance work spend on maintenance vs. new extensions [00:28] and stop doing new if the maintenance is too much [00:29] micahg: we started on having auto syncs ... yes. [00:29] micahg: we have a set of scripts that basically already does that [00:29] it just needs to be plumbered together [00:29] fta: yeah, the SDL bit is known. I'm going to look at it this evening (in an hourish). [00:29] that was one of the plans that ended up short before the end ;) [00:30] micahg: https://code.edge.launchpad.net/~mozillateam/firefox-extensions/med-auto-scripts [00:30] micahg: what that does is it syncs the registered extension ids and detects if there are newer xpis than what is currently in branch [00:30] or something [00:30] i think whats missing is the branch updating [00:30] but maybe thats even there too [00:31] * micahg wants to know how to recruit more triagers for bugs... [00:31] thats a communication thing. [00:31] more blocking [00:31] reporting status [00:32] oh, also, should update my 3.6b1 test build to not use system sqlite? [00:32] micahg: if it still works it measn that your version is high enough [00:32] you should just have the right minversion in debian/rules [00:32] at least atm [00:33] no, because of the compile flags that reed pointed out [00:33] if we go back to all in-source, w can probably do that [00:33] ah. maybe. i will upload the update tomorrow [00:33] to security ppa and then to -proposed for some baking for hardy-jaunty [00:34] ok [00:58] micahg: i fixed tb3 head ... i think ... did you see what was wrong with 1.9.3 patches? [00:59] asac: I thought it was cairo that was the issue with 1.9.3 [01:00] yeah [01:00] ok [01:00] then all is fixed [01:00] the patches applied and its building here [01:00] good [01:11] asac: https://edge.launchpad.net/builders/bohrium [01:28] hanging? [01:31] yeah [01:31] I'm trying to figure out who to contact [01:31] it's that build machine [01:32] that's why we didn't have a build yesterday though [01:38] hmm [01:38] micahg: in #launchpad [01:38] ask there [01:38] maybe there is someone on duty [01:38] otherwise i can ask around tomorrow [01:38] now dropping out [01:38] already did [01:39] night [01:39] oh. no answer? [01:39] not yet [01:42] ok if noone ansewrs just drop a line ... enjoy! [01:42] ok [03:35] micahg: when you post that a bug is reported upstream in mozilla please do an "also affects project" and paste the bug in the url field [03:36] jcastro: what are you referring to? [03:36] If I have the bug I add it [03:36] https://bugs.edge.launchpad.net/firefox/+bug/448686 [03:36] Launchpad bug 448686 in firefox-3.5 "CSS table borders do not display" [Medium,Triaged] [03:36] weird [03:37] I usally do [03:37] I just linked it, I have a report that goes through bugs with comments with links in comments that aren't link, to catch them. :D [03:37] it's ok it's my job to catch the ones that get away [03:37] was 1AM [03:37] but I find that some people never know about the feature so I always follow up. [03:37] * micahg knows [03:37] I also add them for people if I catch it [03:37] I am currently working with the lp guys to make it not so annoying to do though [03:37] <3 awesome [03:38] well, you don't want to entirely automate it [03:38] oh no [03:38] it won't be automated for sure [03:38] but something inlineable so you don't have to do a page load I think would be much easier [03:39] yeah [03:42] perhaps a flag next to a bugwatch if the upstream project is labeled [03:42] s/labeled/set [03:43] yeah [03:43] and I think "also affects project" is confusing [03:43] there should be a specific "link to an upstream bug project" or something [03:44] jcastro: well, there's 2 functions for it [03:44] 1 is to mark upstream [03:44] yeah, I think that's the problem [03:44] 2 is to mark another project affected [03:44] but we'll see what UI people say [03:44] LP UI team is reluctant to add more buttons [03:44] * jcastro nods [03:45] I'm going to have a session about this at UDS, so if you have any feedback or concerns feel free to just mail me [03:45] I am going to video some people upstreaming bugs to get more data, etc. [03:46] * micahg wishes he could attend UDS [04:14] intriguing [05:54] hey all [05:55] lately there have been no Chromium nightly updates [05:55] anyone happen to know why? === micahg1 is now known as micahg [05:57] really? [05:57] I thought I got an update [05:58] maybe not :) [05:58] markey: daily is broke :) [05:58] wanna fix it? [05:59] not really, I'm not much of a packager :) [05:59] what's borked with it? [05:59] idk [08:09] hello everybody [08:09] i'm here again about the problem I discuted yesterday w/ asac [08:09] well, [08:09] I think I got it [08:10] the apparmor profile for FF is wrong in karmic. [08:10] this statement is true for users on an active directory domain, that has been joined, for example, with likewise-open [08:11] for these users, the home directory looks like /home/DOMAIN/user [08:11] and this, IMHO, prevents FF from setting a lock on the .parentlock file. [08:12] well, now the evidences of this misbehavior: [08:12] Oct 22 11:13:52 ly-qa-bellinux kernel: [ 8549.052195] type=1503 audit(1256202832.201:81): operation="file_lock" pid=6085 parent=5539 profile="/usr/lib/firefox-3.5.*/firefox" requested_mask="wk::" denied_mask="k::" fsuid=1893211406 ouid=1893211406 name="/home/ESKERCORP/bellin-salarin/.cache/event-sound-cache.tdb.f1b0a25408a48159af64e77c486e058d.i486-pc-linux-gnu" [08:12] I think I'm going to open a log, I will file it against mozilla-firefox [08:12] and apparmor [08:12] (log=bug report) [09:48] hmm [09:48] jdstrand: ^^^ [09:49] http://paste.ubuntu.com/299642/ [09:49] jdstrand: ^^ [09:49] apparmore ;) [09:49] asac: already responded to his bug [09:49] bug #458846 [09:49] Launchpad bug 458846 in apparmor "apparmor prevents firefox from starting for an user who belongs to an Active Directory domain (dup-of: 447292)" [Undecided,Won't fix] https://launchpad.net/bugs/458846 [09:49] Launchpad bug 447292 in apparmor "AppArmor does not allow access when @{HOME} is not /home" [Low,Won't fix] https://launchpad.net/bugs/447292 [09:50] ah ;) [09:50] he simply needs to read https://wiki.ubuntu.com/DebuggingApparmor#Adjusting%20Tunables [09:50] jdstrand: isnt it way too early? [09:50] ;) [09:50] i mean ... i just got up :-P [09:50] asac: yeah-- dog woke me up and then I couldn't get back to sleep [09:50] (a tad late i agree) [09:50] heh [09:50] ok ... feels like i should get a dog soonish ;) [09:51] heh [09:51] just don't get a male [09:51] :) [09:51] yeah. my girl wants a girl ;) [09:51] I'm sure some males are fine. ours is stubborn and a digger (wakes us up scratching his bed) [09:56] asac: I don't understand the difference between LIBXUL_SDK and SKIP_COPY_XULRUNNER [09:57] micahg: SKIP_COPY_XULRUNNER? [09:57] isnt that a patch by us? [09:58] micahg: so bascially if you build a libxul-sdk based aplication and want to ship it [09:58] you need to ship it side by side with xulrunner ... [09:58] unless you are a distributor that knows that there is xulrunner on system [09:58] thats when you SKIP_COPY_XULRUNNER [09:59] i guess LIBXUL_SDK Is clear? [09:59] i would think [09:59] so if you build mozilla apps with --with-libxul-sdk [09:59] it means it will just use the system xulrunner [09:59] and not build the full xulrunner on its own [10:00] thats why SKIP_COPY_XULRUNNER comes into play [10:00] why do you need SKIP_COPY_XULRUNNER if you're building with LIBXUL? [10:00] e.g. if you dont build xulrunner you need to copy it if you want to ship a bundle with everything [10:01] why 2 variables? [10:01] 10:58 < asac> micahg: so bascially if you build a libxul-sdk based aplication and want to ship it [10:01] that's what I don't get [10:01] 10:58 < asac> you need to ship it side by side with xulrunner ... [10:01] 10:58 < asac> unless you are a distributor that knows that there is xulrunner on system [10:01] 10:58 < asac> thats when you SKIP_COPY_XULRUNNER [10:01] thats what i tried to explain i nthose lines [10:01] i saw [10:01] hmm [10:01] but I don't understand [10:01] I thought building with libxul-sdk implies system xul [10:01] micahg: xulrunner is not only made for distros [10:02] so thin kabout windows [10:02] oh [10:02] if you build a xulapp .... with libxul-sdk [10:02] I think I get it [10:02] you want to ship something that works [10:02] one is for building and one is for running [10:02] so you need the full xulrunner copy [10:02] thats what it does by default [10:02] and thats why one needs to explicitly SKIP that on linux distro packages [10:03] micahg: yes. if you do --wit-libxul-sdk it will build against that ... and in the end copy the full xulrunner [10:03] so you have it in the same tree and can ship a complete solution that works independently of the system [10:03] yes. what you said is about right [10:07] so I messed up the patches...I'm trying again now [10:17] ok, so there's a ifdef SYSTEM_LIBXUL in there now [10:18] yeah [10:18] where we had LIBXUL_SDK [10:18] should I update our patches with the upstream CONSTANT? [10:20] micahg: if that constant is now used ... why not [10:21] micahg: so SKIP_COPY_XULRUNNER imo was also defined elsewhere [10:21] iirc [10:21] but its there for ages, so i am not sure [10:21] to give you a 100% sure answer i would have to read the code. but if you think the upstream constant is a better way, then propose it and i will check [10:22] ugh [10:22] something's not right [10:23] LIBXUL_SDK is still used [10:25] I think this is too much for me at this hour [10:26] I'll try again when I get up [10:31] hehe [10:31] micahg: yes. try to take a step back ... and then lets seee [10:31] micahg: what are you doing actually? [10:32] fixing the patches as they no longer cleanly apply [10:33] oh ok ... ffox ... right [10:33] LIBXUL_SDK will be used for sure [10:33] no [10:33] prism [10:33] i dont think this will ever get removed [10:33] thought the SKIP_COPY_XULRUNNER was removed by something else [10:34] micahg: oh yeah. [10:34] micahg: lets check that when you wake up [10:34] i am then in weekend mode and can probably give better input ;) [10:34] ok [14:52] bdmurray: hey ;) [14:53] bdmurray: can you give cyphermox the intro wiki page for bugcontrol and add him to that team once he confirms he understands? he is NM team member and needs to be able to work on bugs ;) [16:23] asac, how do i add a tab in a bzr branch? [16:23] tag [16:25] fta: for package releases? [16:25] fta: basically same approach as we do ... release commit ... just use decommit -r -e [16:25] that will do the right thing and allows you to be more concrete [16:25] i think we should adjust debcommit code to be more of the format that we use in mozillateam [16:25] it just says: "relesaing x.1.2-0ubuntu2" [16:26] while it should say "releaseing x.y.a.s. to karmic" ... at least [16:26] fta: otherwise its just bzr tag 1.2; bzr push [16:26] if you do an upstream release [16:26] could it be done afterwards? i mean, adding tags to older revisions? [16:28] fta: sure [16:28] i think you can do bzr tag -r xxx TAGNAME [16:28] yeah [16:29] you can do that accoreding to bzr help tag [16:29] you can see all tags with bzr tags [16:29] or delete tag with bzr tag --delete TAGNAME [16:30] would be nice to be able to commit with a user specified date too. so i can re-create a branch for a 15y+ project i'm still working on [16:31] fta: is that in svn or cvs? [16:31] they are easy to import [16:31] and dates etc. shouuld be fine then [16:31] i think [16:32] otherwise set date before commit ;) [16:32] no, nothing, no vcs at all, i just have my old tarballs and changelogs [16:32] [16:32] hmm [16:32] yeah. sounds like a plugin [16:32] e.g. tarball-series import [16:33] not existing. just saying that that should probably be done as s plugin [16:37] fta: bzrtools ... bzr help import [16:38] Purpose: Import sources from a directory, tarball or zip file [16:38] Usage: bzr import SOURCE [TREE] [16:38] This command will import a directory, tarball or zip file into a bzr [16:38] tree, replacing any versioned files already present. If a directory is [16:38] ... [16:38] might be worth a try [16:38] though not with date tweakage [16:38] not sure how smart it is [16:38] but maybe give the tarball an old timestamp and see if it uess that ;) [16:40] import does not commit on its own though [16:49] fta: i think should be easy to do [16:50] let me see [16:50] * asac pulls bzr bzr [16:50] grr ... branch format outdated [17:43] bug 443028 [17:43] Launchpad bug 443028 in evolution "evolution hangs when trying to open/save attachments in an email with 2 ppt attachments" [Medium,Incomplete] https://launchpad.net/bugs/443028 [17:43] cool, i'm not alone === dpm is now known as dpm-afk [18:02] fta: great. thats a start [18:02] fta: i will write the timestamp patch for bzr ;) [18:02] but it took 1h or so to convert my bzr branch to a format so i can pull the latest ;) [18:02] not sure it's the same freeze, i don't have logs for mine [18:02] so if you wait till tomorrow you can use bzr import + bzr commit [18:03] they happen only on my x64 box [18:03] fta: can you get a threaddump if it freezes? [18:03] i should try, but i'm at home (32bit) [18:07] seems virtualbox can't do d3d10, too bad [18:07] no aero with W7 [18:14] hmm [18:14] yeah [18:19] funny, d3d is in fact using the wine driver [18:24] Rejected: File gwibber_2.0.0~bzr476.orig.tar.gz already exists in Primary Archive for Ubuntu, but uploaded version has different contents. [18:24] i wonder if the bot should be smarter and 1st look at the archives before calling get-orig-sources [18:25] or if it's a marginal case for dailies [18:25] (not worth the efforts) [18:35] fta: http://pastebin.com/f72bb14ce [18:35] fta: i am not sure. i had the feeling that we get a bit often rejections because of bad version in some way [18:36] yes, but here it's different [18:36] isnt it the "if on top there is released, it should bump version rather than lowering"? [18:36] fta: the patch above works great for me ... e.g. [18:36] /home/asac/local_bzr/bin/bzr commit --commit-time='2009-10-16 08:59:00 +0100' [18:37] a --commit-from-reference=some_file would be nice too [18:37] er, --commit-time-from-reference [18:37] similar to 'touch -r' [18:38] ah [18:38] yeah well ;) [18:38] you can wrote a wrapper for now [18:38] like ls -l /path/to/tarball -> make date [18:38] use that to commit after bzr import /path/to/tarball [18:38] fta: i think that should rather in a "import-and-commit" ;) [18:39] i will think about it ... now that i am the bzr master ;) [18:39] lol [18:39] fta: can you open a wishlist but for the --commit-date thing against bzr upstream so i can request a merge? [18:46] not sure i can change upstream bug status [18:47] or is wishlist a tag? [18:48] nope, it's "importance", i can't change that [18:50] asac, ^^ bug 459276 [18:50] Launchpad bug 459276 in bzr "user specified commit date" [Undecided,New] https://launchpad.net/bugs/459276 [18:54] heh yeah [19:11] tb3/chromium/o3d red [19:11] songbird too [19:11] gwibber out [19:12] not a good day for dailies :P [19:28] anyone else notice that the folders with mail in them in tbird3 are not bold anymore? [19:28]