[02:31] hello [02:33] firefox 3 b4 is out :D:D! [08:50] hmm b4 as a bad regression for me [08:50] i cannot close ephy ... nor can i close tabs in ephy [08:56] Ubulette: ^^^ [10:28] [reed]: i have a bad regression here :) ... epiphany cannot getService the login manager anymore. any idea which commit might have introduced this? [10:29] hmm ... might be my fault [10:29] lets check [10:41] no luck [12:42] Ubulette: empty white pages in seamonkey-2.0 from your PPA - does that ring a bell? [13:27] damn epiphany regression :( [13:27] everything else looks good [13:27] whats going on === Greenery_ is now known as Greenery [15:14] you guys have ppa for beta 4? cos I'm still on Gutsy [15:28] <[reed]> asac: yes [15:28] <[reed]> that sounds familiar [15:29] [reed]: it looks that the regression appears to be a freed contentviewer still living in docshell [15:29] on closing tab [15:29] not yet sure whats going on [15:30] tried to backout a patch against docshell/ tree that sounded familiar, but no result [15:30] <[reed]> is it only the login manager? [15:30] no the login manager was my problem [15:30] <[reed]> ah, k [15:30] i had a hacked version and did a bad conflict resolvation [15:30] <[reed]> k [15:31] http://paste.ubuntu.com/5580 [15:32] thats the crash that i see if i close an ephy tab [15:32] in beta 3 it worked [15:32] htmlDoc is freeded apparently [15:39] [reed]: do you remember a patch that tried to resolve some memory/leakage issue? [15:40] <[reed]> uh, there's been a lot of them [15:40] no ... i mean between b3 and b4 :) [15:40] most likely in the content/docshell/view area :) [15:42] <[reed]> yeah [15:42] <[reed]> I'll ask [15:42] <[reed]> and look [15:43] <[reed]> let me catch up on bugmail [15:44] [reed]: when did trunk open for b4 development? (so i can checkout a version in the middle :)) [15:44] <[reed]> looking [15:44] <[reed]> tagged at 2008-03-03 11:15 PST [15:45] <[reed]> oh [15:45] <[reed]> b4 development [15:45] <[reed]> one sec [15:45] <[reed]> tagged at 2008-02-04 17:20 PST [15:45] <[reed]> so, sometime between 2008-02-04 17:20 PST and 2008-03-03 11:15 PST [15:45] <[reed]> checkout in the middle? [15:46] yeah [15:46] [reed]: is there anything special i have to take care of ? [15:46] <[reed]> special? [15:46] <[reed]> such as what? [15:46] or just MOZ_CO_DATE="..." checkout ? [15:46] <[reed]> that should work [15:46] no ... to release any tag i have in my tree :) [15:47] <[reed]> ah [15:47] <[reed]> -A releases tags [15:47] i know that thats true for cvs [15:47] <[reed]> but MOZ_CO_DATE should work [15:47] but how to tell client.mk [15:47] ok [15:47] whats the middle [15:47] ? [15:47] 19th deb? [15:49] <[reed]> deb? [15:49] hmm [15:49] feb [15:49] <[reed]> ah [15:49] <[reed]> 17th or so? [15:50] <[reed]> something like that [15:50] <[reed]> binary search, woo! [15:52] yeah [15:52] but pretty slow [15:52] unfortunately there are no daily xul builds [15:52] [reed]: cvs up -A client.mk didn't help [15:52] just MOZ_CO_DATE ... didn't help (as it still carried the release tag) [15:52] <[reed]> hmm [15:53] [reed]: oh sorry -A worked :) [15:53] <[reed]> http://developer.mozilla.org/en/docs/Mozilla_Source_Code_(CVS)#Specific_Time [15:53] i am c [15:53] getting the 20th now (hopefully) [15:57] i don't think binary-search-compiling mozilla trees is a really fruitful approach :( [15:58] but well ... here we go. first spin :) [15:58] how many spins do i need at max to find the proper date? [15:58] and how many to find the proper checkin (how many checkins are average per day?) [16:15] 5000 [16:49] [reed]: can you please commit a bunch of approved1.8.0.15 patches? at best all distributed over a few days ... so we can find regressions in the daily builds ;) ? [16:56] <[reed]> asac: I committed a ton last week [16:56] <[reed]> er [16:56] <[reed]> Friday night [16:56] <[reed]> I'll take a look later [17:35] [reed]: ok thanks [17:36] [reed]: its good to distribute them over multiple days i get [17:36] we approved a bunch more today [17:36] so there should be work todo ;) [17:36] [reed]: any idea if i can get email notification if bonsai burns for a certain branch? [17:37] aeh tinderbox i mean ;) [17:37] <[reed]> no such thing, no... you could set up buildbot yourself to do that :p [17:37] <[reed]> or write a script to parse tinderbox [17:38] lolz [17:38] [reed]: yeah. i think at some point we need our own buildbot anyway [17:39] (i think we have ~4 weeks time until they go offline) [17:39] <[reed]> you better hurry ;) [17:39] in worst case i will do daily PPA builds [17:39] but that is just debs [17:40] would love to build proper tarballs [17:51] asac: any possibility of ffb4 hitting hardy? [17:51] no [17:51] :( [17:52] armin76: don'te tell me u asked the same question/query :) [17:52] he is working for microsoft now [17:52] so he doesn't care [17:52] >.< [17:52] armin76: are u serious, asac is working for MS ? [17:53] hahaha [17:53] no :) [17:53] thank god, that would be the day [17:53] armin76: what about ffb4 hitting the official repos? [17:54] no idea [17:54] i don't use ubuntu, so don't ask me :) [17:54] armin76: u're a BSD user? [17:54] or a gentoo one [17:54] lol [17:55] so, if i don't use ubuntu, i use bsd? great :P [17:55] being a gentoo dev what do you think? :) [17:55] shirish: the package is ready [17:55] i just have a serious regression for epiphany [17:55] asac: cool, is it in queue [17:55] thats why i haven't uploaded yet [17:55] ah ok [17:55] once thats sorted out i will upload [17:55] but no ETA yet [17:55] asac: sure that would be nice. [17:55] i can upload the package to PPA if you want [17:56] everything except ephy works well [17:56] I love ephy as well :) [17:56] [reed]: ok looks like 20th feb already had that regression [17:57] next build ;) [17:57] 12th? or 10th= [17:57] <[reed]> :) [17:57] ? [17:57] you decide [17:57] give me a good guess ;) [17:57] asac: I went to the epiphany web-site but curiously the site is pretty parse [17:57] doesn't have much content. [17:58] 11 [17:58] <[reed]> yeah [17:58] <[reed]> 11! [17:58] ok ... 11 is a reasonable day [17:58] am i being helpful? :D [17:58] armin76: no idea ... does gentoo have epiphany on top of xul yet? [17:58] ah so you guys are working backwards to see if u find a build that works with that. [17:59] if so you could test other dates ... so we can narrow down the regressoin window quicker [17:59] does it even work? :P [17:59] shirish: yes ... finding regression window [17:59] and finall finding the commit that introduced this is the primary objective right now [17:59] hrm...but what version of xul? 1.8 or 1.9? [17:59] ok cool, I'll be away for a while but will be back [17:59] armin76: 1.9 obviously [17:59] ok that's cool enough. [17:59] what ephy ver? [17:59] armin76: epiphany upstream has committed my xul patch yesterday [18:00] so it should build out of the box [18:00] oh...then no, it doesn't build on top of xul, only with 1.8 [18:00] armin76: yeah. you should move ahead now that ephy trunk supports 1.9 [18:00] otherwise gentoo will suffer from out-of-dateness [18:00] :) [18:01] don't you think? [18:01] that's up to the gnome team :P [18:01] get them in here [18:01] already pinged the guy :P [18:02] [reed]: why doesn't export GRE_PATH=/path/to/my/xul/ ... not work? [18:02] is it GRE_DIR? [18:02] <[reed]> sorry, in Firefox 3/Gecko 1.9 call [18:03] k [18:03] raise the regression thing there :) ... this is completely unacceptable [18:06] asac: leio, leio: asac [18:06] hey leio :) [18:07] leio: latest epiphany head now supports xulrunner 1.9 [18:07] still some bugs to flesh out, but definitly usable [18:08] wonder if you plan to switch to xul 1.9 soonish [18:10] he fears you :P [18:10] why? [18:10] am i too verbose? [18:10] haha, no idea, i was kidding :) [18:12] asac: it doesn't seem like we specify the version, so doesn't it just pick up 1.9? [18:19] leio: no it won't [18:19] you need to specify another gecko engine: [18:19] --with-engine=mozilla --with-gecko=libxul-embedding [18:19] i think it will use that in case ... but only as last option [18:21] epiphany is about to enter the official tree, while xulrunner isn't there yet, so it's a hard sell right now, but once it can be done, sure, I'm at least interested in doing that. And also interested in making webkit a choice for the user [18:22] having an epiphany using xulrunner-1.9 in the same overlay and/or visibility might be a good idea though [18:23] whats needed to get xulrunner in the official tree? [18:23] should be a reasonable decisoin to build firefox on top of xulrunner [18:23] armin76: ?? [18:23] didn't you do that already? [18:23] a woot [18:23] no [18:23] well [18:23] it'll break epiphany-2.18 that has to stick around [18:23] i didn't put it yet because it broke a lot of stuff [18:24] but something might be possible to work out, such as appropriate blockers and ensuring that ephy-2.22 and xul-1.9 will stay at the same visibility level at all times [18:26] (an ephy revision that is made to use xulrunner-1.9 mind you, a xulrunner-1.8 and 1.9 user can co-exist, just at different visibilities - what you'd call testing and stable tree) [18:26] sorry ... i don't know how and if you do releases at all? [18:26] we have a moving tree. There is no dist-upgrade alike thing [18:27] hmm. ok [18:27] must be hard to do a "complete gnome" migration for instance [18:27] e.g. from 2.18 -> 2.22 [18:27] and then approx. twice a year a snapshot of the package tree (the ebuild instructions of building them) is taken, and shaped into a package tree that will get used to build installation media [18:28] you get 2.18 -> 2.22 if you haven't updated stuff for over a year [18:30] as soon as a GNOME release comes out and all bad kinks are worked out, we add it to the tree with ~arch keywords (all arches in an equivalent of your testing tree), then in about 30 days architecture teams upgrade the keyword to stable by GNOME teams request. Then stable users can upgrade immediately, and not when a new debian stable or ubuntu release comes out and they go dist-upgrading [18:30] so that's the principles :) [18:30] ok [18:30] makes sense [18:30] so in the same package tree we typically have about 2-3 epiphany versions [18:31] and xulrunner lives in the same tree, and they shouldn't break eachother [18:31] yikes 39 pkgs reverse rdepend on mozilla-firefox! [18:31] it'd be perfect if xulrunner-1.8 and 1.9 could simply coexist side by side [18:31] ah ok [18:31] and stuff still depend on firefox and not on xul [18:31] leio: they can coexist [18:31] then armin76 should make that happen in gentoo and there are no problems [18:31] (both binary + source) [18:32] we use a different pkglibdir for xulrunner-1.9 [18:32] just a different SLOT, we slot depend on the one we build against and that's it [18:32] e.g. /usr/lib/xulrunner (1.8) [18:32] haha [18:32] /usr/lib/xulrunner-1.9b3 (1.9b3) [18:32] he'll have fun with all the USE=firefox stuff though [18:32] USE? [18:33] http://tinderbox.dev.gentoo.org/misc/rindex/www-client/mozilla-firefox [18:33] :( [18:33] firefox can also coexist [18:33] we have firefox-3.0 and firefox package ... both can be installed in parallel [18:33] probably won't be a pretty sight in the menus and such [18:34] pretty short list :) ... we have patches for all of them in ubuntu. [18:34] armin76: could help to clean those patches up so they don't break builds against 1.8 [18:34] :) [18:35] mostly breakage of 1.8 builds with our patches is considered a bug/glitch [18:45] Ubulette: we have a reporter.jar in xulrunner and firefox? [18:45] thought we don't build with reporter at all [18:45] whats going on? [18:47] Ubulette: btw, i think nspr.head and nspr are _unrelated_ branches [18:48] i couldn't diff them ... and ofc ourse couldn't merge them so i had to duplicate what you already did [18:53] hi [18:55] hi [18:55] nspr is the one i used for the last hardy upload, head is HEAD (a bit behind as I don't really have time those days) [18:55] Ubulette: ok ... yes. i think i updated the correct one then [18:55] please take a look [18:55] (nss + nspr) [18:56] i didn't try to merge down from nss.head ... but i guess merging down after the release should be fine as well [18:56] (as long as we merge soon) [18:56] Ubulette: anyway ... shouldn't nspr.head be based on nspr? [18:56] currently they don't have a common ancestor at all from what i see [18:57] they only diverge because of the naming ~cvs vs ~1.9b [18:57] are you sure nspr for b4 is still 4.7.0 and not 4.7.1 beta ? [18:57] hmm. [18:57] most likely wrong yes. [18:58] but lower version isn't really a disaster [18:58] but pleeeeeese, don't up 4.7.1~1.9* [18:58] no i won't [18:58] so its fortunate :) [18:58] we can use 4.7.1~beta1~1.9* i guess [18:59] either use what we discussed yesterday or we need to discuss more [18:59] is the above version ok? [18:59] there's no such thing as beta1 [19:00] there is beta right :O) [19:00] NSS_HEAD_BEFORE_RFC4507BIS [19:00] ** The format of the version string is [19:00] ** ".[.] []" [19:00] just the last 2 [19:01] what does that tell me? [19:01] but as i said, mozclient is doomed with that [19:01] just read my new nspr.mk.in [19:03] reconnect [19:03] reconnect [19:04] Ubulette: do you see epiphany-browser regression? [19:04] what does that tell me? [19:04] but as i said, mozclient is doomed with that [19:04] just read my new nspr.mk.in [19:04] ok [19:05] yes, i told you twice earlier [19:05] really [19:05] hmm ... when did it start [19:05] my regression window is currently down to 2nd feb - 11th feb [19:06] (e.g. the 11th feb build still has that) [19:06] does that match with your experience? [19:06] Feb 04 22:00:44 epi doesn't quit on "File / Close" [19:06] e.g. that it happened quite early in the b4 release cycle [19:06] oh cool [19:06] so it happened between feb 2 and feb 4 :) [19:06] Mar 01 02:13:30 asac, File / Close in Epiphany doesn't do anything for me. [19:07] for me it takes some time ... then it crashes [19:07] thanks [19:07] i should listen more carefully i gues [19:07] i guess so [19:08] ok lets see if its really not in 2nd feb [19:12] Bug 414894 - Remove content arena. r=smaug, sr=sicking, a=schrep === asac_ is now known as asac [19:23] * RainCT just uploaded adblock-plus :) [19:29] * asac hugs RainCT [19:30] any other extensions you are using? :) [19:34] if 2nd feb build really fixes this, there shouldn't be much commits that might have caused the ephy extension. [19:34] s/extension/regression/ [19:35] * asac should gracefully exit other contexts before writing to a channel ;) [19:47] * RainCT hugs asac back :) (was away) [20:00] I hate when scrollkeeper-update starts during an upgrade [20:01] yeah ... takes ages [20:01] uninstall ;) [20:02] it's within libcupsimage2 [20:02] anyone has ipw2200 or ipw2100 ? [20:02] or iwl3945? [20:04] asac, xulrunner-1.9-1.9~b4~cvs20080215t0338+nobinonly/debian/tmp/usr/lib/xulrunner-1.9b4pre/chrome/reporter.jar [20:04] seamonkey-1.1.8+nobinonly/debian/tmp/usr/lib/seamonkey/chrome/reporter.jar [20:04] firefox-3.0-3.0~b4~rc1+nobinonly/debian/firefox-3.0/usr/lib/firefox-3.0b4/chrome/reporter.jar [20:06] asac: btw, you probably already know, but just to be sure.. there are some extension packages for review on the firefox-launchpad project [20:08] RainCT: yes. i planned to upgrade a few more in the archive and do them all in a row [20:08] if you want to upload and file the appropriate bugs, we can certainly accelerate this :) [20:10] damn, python-pysqlite2 also runs scrollkeeper-update [20:10] hm.. but they wouldn't need a mozillateam ack anyways. or? [20:11] acking the report if the extension is pre-tested should be easy to do [20:50] asac, why didn't you merge nss for nss.head ? [20:51] well, nm. this versionning is a mess [20:59] Ubulette: one reason. the other i explained above (iirc) [20:59] nss was mergeable easily [20:59] nspr too [21:00] nspr doesn't have a common ancestor (at least the branch i was looking at) [21:00] really ? [21:00] yes [21:00] thats what i complained about initially [21:00] not that they diverge, but that they are not related at all [21:01] here, they are [21:02] http://paste.ubuntu.com/5595/ [21:02] i looked at nspr.head [21:03] (out of my mind) [21:03] that's my nspr.dev locally [21:03] old mess [21:04] now it's even more difficult [21:45] <[reed]> asac: CC me to all bugs from this query, please -- https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&keywords_type=nowords&keywords=fixed1.8.0.15%2C+verified1.8.0.15&chfieldto=Now&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=approval1.8.0.15%2B&field0-1-0=bug_group&type0-1-0=equals&value0-1-0=security [21:46] <[reed]> security bugs that have approval1.8.0.15+ but haven't been checked-in [21:47] why don't cc yourself? :P [21:48] oh [21:48] its empty [21:51] <[reed]> armin76: I'm not in the security group? :) [21:52] <[reed]> I'm in two of the three security groups [21:57] [reed]: can you give me a tinyurl? [21:57] <[reed]> you can't use the url I posted above? :) [21:57] terminal is too dump to alow to copy that long link [21:57] <[reed]> lol [21:57] <[reed]> k [21:57] well ... i could. but not easily [21:58] <[reed]> http://tinyurl.com/29kell [21:58] reed@reedloden.com? [21:59] <[reed]> yes, or you can use :reed [21:59] <[reed]> that matches me [21:59] <[reed]> since my address will change when the summer starts [21:59] yay, why? [21:59] <[reed]> reed@mozilla.com -- summer internship [22:00] about time :P [22:00] <[reed]> heh [22:00] <[reed]> I was an intern last summer, too :) [22:00] [reed]: done [22:01] 4 bugs [22:01] <[reed]> asac: thx [22:01] thx 2 u :)( [22:03] [reed]: i see 19 with approval+ [22:03] not fixed [22:29] asac, does the dell inspiron have (wired) ethernet ? I can't see it on their web site [22:30] haven't heard of any laptop that doesnt [22:30] the ubuntu inspiron almost certainly has [22:34] ok, found it === Ubulette_ is now known as Ubulette [23:44] debian bug 470438 [23:44] Debian bug 470438 in iceape "iceape: FTBFS: (.text+0x526): undefined reference to `SECITEM_CopyItem_Util'" [Serious,Fixed] http://bugs.debian.org/470438 [23:44] libnss3-1d.symbols: SECITEM_CopyItem_Util@NSSUTIL_3.12 3.12.0~1.9b3 [23:45] in libnssutil3.so.1d [23:45] asac, ^^ [23:45] yes [23:46] just wanted to see the title [23:46] someone said icedove might be hit by that :) === Ubulette is now known as fta === fta is now known as Ubulette [23:48] damned, taken [23:49] hmm ... try to figure how long not active [23:49] if its longer than 2 month or so you can high-jack [23:49] how could I know? [23:50] not sure .... you can ask an #op on freenode to high jack. [23:50] they can probably tell you inactivity as well [23:50] but i think there is a service running that you can use to take a look [23:51] it's a registered nick [23:51] yes [23:51] well, maybe another day [23:51] sure [23:53] mozilla bug 422122