[00:23] Ubulette: did mozclient patch work? [00:36] asac, it still ftbfs at the same place, even with MOZ_CO_DATE="2008/01/17 11:16 PST" [00:51] Ubulette: could you verifiy that that patch is in your ball? [10:32] ]reed[: thanks for the checkin :) [10:32] <]reed[> np [11:20] bug 183886 [11:20] Launchpad bug 183886 in xine-lib "XS-Vcs-Hg url in debian/control doesn't exist" [Undecided,New] https://launchpad.net/bugs/183886 [11:23] <]reed[> mozilla bug 399590 just landed [11:23] Mozilla bug 399590 in Security: PSM "Update Mozilla trunk to use NSS tag NSS_3_12_BETA1" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=399590 [11:24] <]reed[> so, you all will need to rebuild the nss packages [11:43] beta1? [11:44] <]reed[> for firefox 3 === asac_ is now known as asac [13:20] ]reed[: will you stick to that tag for beta3? [13:20] (nss) [13:21] <]reed[> yes, unless something drastically changes that causes us to pull a new tag [13:21] <]reed[> but most likely, yes === ]reed[ is now known as [reed] [13:21] ok ... hopefully it doesn't doesn't break bin compat to previous builds [13:22] <[reed]> it does [13:22] is just "reed" taken on freenode? [13:22] <[reed]> yeah, reed is taken :/ [13:22] it does? [13:22] have you checked if its actually used? [13:22] <[reed]> it adds a new .so / .dll [13:22] <[reed]> so, if you don't have the .so packaged, runtime will fail [13:23] ill try ... in the past we could upgrade without a respin of the other (even when .so where added) [13:23] <[reed]> k [13:24] if reed has not been used for some time you can take it over [13:24] http://freenode.net/faq.shtml#userexpirations [13:24] <[reed]> yeah [13:24] <[reed]> I'll ask my friend [13:25] <[reed]> I happen to know a senior staffer in real life ;) [13:25] <[reed]> hmm, I'm eating lunch with him today [13:25] <[reed]> I'll ask [13:25] yeah :) [13:25] freenode staff? [13:25] <[reed]> yeah [13:28] [reed]: the NSS tag is already set, right? [13:28] <[reed]> yes [13:29] <[reed]> check client.mk [13:29] <[reed]> NSPR_CO_TAG = NSPR_HEAD_20080113 [13:29] <[reed]> NSS_CO_TAG = NSS_3_12_BETA1 [13:29] thats why i ask :) -.. client.mk disappeared for me when using that tag :) [13:29] <[reed]> lol [13:30] http://paste.ubuntu.com/3635/ [13:31] http://paste.ubuntu.com/3636/ [13:32] <[reed]> I guess they only tag client.mk on release tags? [13:32] <[reed]> dunno [13:32] <[reed]> do you even really need it, as the client.mk on trunk is correct... [13:33] apparently yes ... unfortunately our mozclient that produces proper tarballs for our projects appears to rely on the tag being set on client.mk [13:33] Ubulette: ^^^ [13:33] mozclient chokes for pristine NSS tags (which don't exist on client.mk) [13:35] Ubulette: i think we have to reconsider how we produce NSS/NSPR a bit [13:37] Ubulette: maybe we should just blatently use cvs co -r $(TAG) $(nss_DIRS) ? [13:42] <[reed]> somebody broke something with the latest security update [13:42] <[reed]> for gutsty [13:43] <[reed]> gutsy [13:43] <[reed]> I'm getting "NOT AUTHENTICATED" [13:43] there was no mozilla update [13:43] oh ... unrelated? [13:43] <[reed]> not mozilla [13:43] <[reed]> ubuntu [13:43] yeah ... thought ubuntu mozilla security update :) [13:43] <[reed]> the latest update that got pushed out to people [13:43] where do you get that? [13:43] <[reed]> lol [13:43] <[reed]> Update Manager [13:43] <[reed]> complains [13:44] <[reed]> for libxfont1, xserver-xorg-core-dbg, and xserver-xorg-core [13:45] hmm [13:46] <[reed]> weird... I did an apt-get update and then tried it again [13:46] [reed]: can you try to "check" ? [13:46] <[reed]> no warning [13:46] hmm ... so its not reproducible? [13:46] <[reed]> not now, no [13:47] maybe the update manager download was interrupted by reboot or reconnect? [13:47] so the signature wasn't valid? [13:48] if you see it again, please keep the state so we can eval [13:50] [reed]: will there be a beta4? [13:50] <[reed]> unknown [13:50] <[reed]> b4 isn't _wanted_, but if it comes to it, they will do it [13:51] ok ... so there is at least hope that it will go to RC1,2,3? [13:51] <[reed]> who knows :) [13:51] :) [13:51] do you dial in to the firefox3/gecko meetings regularly? [13:54] <[reed]> yes [13:54] <[reed]> every Tuesday [13:54] <[reed]> :) [13:54] <[reed]> and I dial in to the project meeting on Mondays [13:54] <[reed]> plus any release driver meetings that are specially scheduled like post mortems [13:54] <[reed]> since I'm part of release-drivers [13:55] oh cool. i think i should start to listen again [13:56] <[reed]> are you awake at that time? [13:56] <[reed]> lol [13:56] its still 1100 PST, right? [13:56] <[reed]> yeah [13:56] thats ok its 2000 here or something (not perfect, but works) [13:56] <[reed]> k [13:57] oh ... gecko and firefox3 meetings have been merged again. good [13:57] oh ... have been for a long time :) [13:57] <[reed]> :) [14:08] wtf, mozilla-nss.pc.in now uses: Version: %MOZILLA_VERSION% ... why isn't Version: %NSS_VERSION% ok anymore? [14:09] (nspr sill has %NSPR_VERSION%) === rhelmer|afk is now known as rhelmer === rhelmer is now known as rhelmer|afk [14:09] <[reed]> who changed that? [14:11] oh ... shame on me ... that wasn't changed ... it was just the Libs: line that conflicted here [14:11] but MOZILL_VERSION doesn't sound right either [14:12] anyway, its my fault, because i failed to post my patches to support system-nspr/nss properly [14:12] <[reed]> yes, it is your fault [14:12] <[reed]> :) [14:12] <[reed]> submit patches! [14:14] well ... we are pretty good so far [14:14] <[reed]> how many non-ubuntu-only patches do you still use on top of CVS? [14:16] just three [14:16] http://paste.ubuntu.com/3639/ [14:16] those bzXXX are those we want to push up [14:16] though the gre_extension_plugin patch is apparently not wanted by :bs [14:17] the one with bug number wait for review/landing [14:17] well bz384304 has landed now [14:17] pyxpcom is not in ffox build (so easy commit) [14:18] [reed]: can you look at mozilla bug 233371 and tell me who should do the superreview? bs said he cannot review that (lack of expertise) ... timeless appeared unresponsive [14:18] Mozilla bug 233371 in Embedding: GTK Widget "Long tooltips should wrap instead of being cropped in gtkmozembed" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=233371 [14:19] <[reed]> mgritti? [14:19] <[reed]> he's not an sr, but he owns gtkmozembed [14:20] so ask him for review or superreview ... or doesn't matter? [14:21] [14:21] mgritti did not match anything [14:22] <[reed]> hmm, does marco@gnome.org ? [14:22] well ... i should tackle the comments first i guess :) [14:22] noted marco@gnome.org [14:50] i have trouble compiling with external nss-3.12_beta1... [14:50] * armin76 blames asac [14:50] * asac ducks [14:50] asac: and yes, you fail, it's always been MOZILLA_VERSION [14:51] yes ... my patch does that :) [14:51] there's no bug number [14:51] ? [14:57] armin76: its bzXXX :) [14:57] e.g. to be submitted [14:57] why? [14:57] you fail? :P [14:57] no because i do things in batches ... i hate to submit things if i cannot be responsive [14:57] so looks like something is wrong with my nss build... [14:58] but that stuff is since ff2 or so :P [14:58] armin76: try the patch ... it doesn't fix xulrunner build ... just embedders and firefox that don't explicitly add nss to CFLAGS [14:59] armin76: if you still use the same packaging as in ff2 you probably need to update it [14:59] there are more libs ... and the dir structure has been shuffled [15:00] woot? [15:00] it just worked before nss-3.12_beta1 :P [15:19] fails with included nss as well...shrug [15:19] * armin76 tries updating snapshot [16:00] /usr/bin/gmake -j1: *** No rule to make target /var/tmp/portage/net-libs/xulrunner-1.9_pre20080118/work/mozilla/dist/lib/libsoftokn.a. Stop [16:00] fun [16:00] asac: fix :P [16:00] in which dir? [16:01] http://rafb.net/p/cLSMYj18.html [16:04] he? the build tries to go on and fails in mangle? === \sh_away is now known as \sh [16:06] armin76: why is that build at all? with system-nspr/nss it shouldn't try to build shlibsign et al afaict [16:07] err, no, i'm not using system nss/nspr [16:07] since it failed i just tried to build with the one included [16:07] so it fails using included nss/nspr [16:09] ah ok [16:09] but the tinderbox is still ok? [16:10] maybe just get a more recent snapshot? [16:17] no idea, will check later, meanwhile i'm going to do a new snapshot without nss-3.12_beta1 [16:48] armin76: for me latest trunk works fine with whatever nss we have [16:48] builds + runs [16:48] yes, but it fails with nss-3.12_beta1 [16:49] hmm https works ... but adding exception crashes it now ... so we probably really need to upgrade [16:51] wfm with nss-3.12_alpha2b === greenery_ is now known as Greenery [17:23] found the root of the problem, nvidia driver causes the restart of X [17:23] whoops [17:24] Greenery: np :) [17:37] asac: ping [17:59] cwong1: yes` [17:59] ? [17:59] will be out for sports soon ... anything important -> hurry ... otherwise, lets talk later today ;) [17:59] asac: I like to merge in some changes I made to preference pages and the windowservice before we push WORKING to main. [18:00] ok? [18:00] cwong1: ok, if you use git merge und checked out WORKING branch its fine [18:00] i tried it yesterday and it worked [18:01] ok [18:01] talk 2 u later [18:01] there shouldn't be much conflicts during merge [18:01] k [18:03] cwong1: you most likely have to drop the changes in toolkit because it won't build ... libxul cannot depend on any application component in ffox 3 [18:03] but give it a try [18:04] but merging the midbrowser/ code would be beneficial anyway ... so we don't loose it and reuse it once we figured out the proper way. [18:04] ok out [18:12] Hey [18:13] Someone filled many bugs about packages that have "Iceweasel" in their description.. [18:14] Should the name "Iceape" also be replaced (for ex. in tabextensions) or is it fine (as there are both iceape and seamonkey in the repo)? [18:17] asac: https://bugzilla.mozilla.org/show_bug.cgi?id=399590#c20 [18:17] Mozilla bug 399590 in Security: PSM "Update Mozilla trunk to use NSS tag NSS_3_12_BETA1" [Normal,Resolved: fixed] [18:17] [reed]: you broke it :P [18:18] <\sh> RainCT, see u-d ml and motu-ml...we raised a question about it [18:19] \sh: you mean the "Do we have a Mozilla packaging policy?" thread? [18:20] <\sh> RainCT, yepp... [18:20] <\sh> RainCT, I think it covers also the description :) [18:53] I'm working on a debdiff to rename iceweasel-scrapbook to firefox-scrapbook. Should I also provide a transitional package? [19:03] <[reed]> armin76: how is it my fault? :p [19:05] i have to blame someone :P [19:21] yuck, and cairo 1.5.6 sigbus on sparc again [19:25] asac, Are you there, [19:32] <[reed]> armin76: YOUR PROBLEM [19:32] * [reed] resolves it INVALID [19:36] lol [19:44] can someone check bug #184115? [19:44] Launchpad bug 184115 in scrapbook "iceweasel-scrapbook should be firefox-scrapbook" [Low,In progress] https://launchpad.net/bugs/184115 [19:57] wtf xulrunner-stub it's prestripped? [19:58] oh... [20:17] [reed]: well, fix sparc then :P [20:17] it's not cairo this time [20:17] <[reed]> lol [20:17] <[reed]> bug #? [20:18] no bug yet [20:18] need to check when was the last time it worked === Ubulette_ is now known as Ubulette [21:44] gee [21:45] so something is broken since beta2 and it's not cairo [21:46] it's broken at least in 20080108 [21:46] in sparc, btw [21:53] can't you get a backtrace ? [21:53] raji: ? [21:55] will do [21:55] asac, Network-Manager having problem 'create new network' with ath_pci driver, did anybody report about this before [21:56] raji: what kind of problem? [21:57] asac, I am expecting that an adhoc network is created when I click on create new network. But that is not happening, looking at the log, cause appears as 'association taking too long to activate the network' and the action of creating network is cancelled. [21:58] asac, I can use iwconfig to connect to an AP in ad-hoc mode... [21:59] raji: to be honest, i never heard of anyone who successfully created an ad-hoc network with nm [21:59] and i never managed to find my chipsets when manually setting them to ad-hoc mode [22:00] either ... but yeah. there should be plenty of bugs already. [22:00] raji: do you see in log if NM tries to get an IP? [22:00] (which would naturally time out i guess) [22:01] asac, NM tries to associate [22:01] asac, and timesout [22:01] can you please paste full log from beginning to end of connect attempt? [22:01] asac, sure. [22:07] asac, Here is the log ,http://ubuntu.pastebin.com/m79b64941 [22:11] raji: so what kind of node is that ... the one that wants to setup the AP ? [22:13] asac, it is samsung q1, UMD device [22:13] nevermind [22:15] raji: look ... it finishes stage 2 ... but never even tries stage 3 or 4 [22:16] asac, what does that indicate? [22:17] have to look in the code for a few [22:17] asac, ok [22:33] raji: ok ... looks like either the parameters send to supplicant are wrong, or the supplicant doesn't get feedback to the driver that adhoc mode has been properly setup [22:34] to evaluate you need to stop NM ... then run wpasupplicant in daemon mode ... use wpa_cli to connect and run the commands you see in thelog you posted [22:34] then see if supplicant ever gives you any feedback about that ad-hoc has been properly created [22:35] asac, I see. I will try that. thanks a lot [22:36] np [22:37] raji: as soon as we know how supplicant behaves, we can match that with what nm does with that [22:38] <[reed]> mmm, new cairo [22:38] asac, ok will let you as soon as I find out. [22:38] [reed]: in tree? [22:38] <[reed]> yeah [22:38] .16? [22:40] <[reed]> not sure [22:40] * [reed] looks [22:41] <[reed]> 1.5.4-141-g57c2b75 [22:41] <[reed]> and pixman-0.9.6-25-ge0af592 [22:41] 1.5.4 sounds scary old [22:41] <[reed]> it's the latest from git [22:41] <[reed]> supposedly [22:41] well we have 1.5.6 :) [22:41] <[reed]> odd [22:46] <[reed]> [04:44:03PM] vlad: ubuntu says they have cairo 1.5.6, yet the README for your upgrade says you landed 1.5.4-141-g57c2b75... is that right? [22:46] <[reed]> [04:45:30PM] reed: yes [22:46] <[reed]> [04:45:46PM] reed: I dunno why the hell ubuntu has 1.5.6, since 1.5 is a development branch [22:46] mozilla bug 411224 [22:46] Mozilla bug 411224 in GFX: Thebes "Upgrade cairo to latest git version" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=411224 [22:46] [reed]: welll ... we have 1.5.x because vlad started with that :) [22:47] (and that is really the truth) ... otherwise we would have waited a bit longer (though not much) [22:48] and we have it in hardy ... which is a development branch as well :) [22:52] raji: you could also try the wpasupplicant 0.6.1~gitxxx ... maybe thats better doing ad-hoc ... you can take sources and build for gutsy from my ppa: http://ppa.launchpad.net/asac/ubuntu/pool/main/w/wpasupplicant/ [22:54] Ubulette: has mozilla-devscripts_0.2~fta5 been baking long enough in your ppa to declare it stable enough for upload? or do you plan to integrate a fix for NSS or something to it? [22:55] asac, will try 0.6.1 code first. [22:57] raji: don't hope too much :) [22:58] raji: this samsung thing uses ralink driver, right? [22:58] asac, No, ath_pci [22:58] oh [22:58] ok [22:58] asac, well, yesterday, xul still ftbfsed within webservice even with fta5 so i'm puzzled [22:59] raji: have you tried to use just wext? [22:59] instead of madwifi? [22:59] (on supplicant side) [23:00] asac, No [23:00] SUP: sending command 'INTERFACE_ADD ath0^I^Imadwifi^I/var/run/wpa_supplicant2^I' [23:00] raji: thats definitly worth a shot as well [23:00] asac, I dont know how to do it [23:00] you need to remove the special cases in the nm-device*wireless.c file [23:00] line 3702 [23:00] and 3703 ... just remove them or comment them or whatever [23:00] asac, ok, [23:02] raji: http://madwifi.org/ticket/462 [23:04] asac, Added to it my list of things to try :) [23:05] raji: but the CLI instructions on https://help.ubuntu.com/community/WifiDocs/Adhoc work? [23:05] Configuration + Activation? [23:06] asac, yes , with iwconfig ad-hoc association and activation worked. [23:06] raji: oh [23:06] do you loa ath_pci like: [23:06] sudo modprobe ath_pci autocreate=adhoc [23:06] ? [23:06] asac, yes [23:11] raji: do you have an ad-hoc network where you can get the ip through dhcp? [23:12] asac, No I dont, [23:13] then nm won't work anyway [23:13] you have to wait for 0.7 to get static ips [23:14] raji: but still ... we should try to get to stage 4 [23:14] if dhcp fails it might at least work :) [23:14] asac, when is 0.7 released? [23:15] unknown ... current state is: its more or less feature equivalent to 0.6.5, but has an improved architecture and afaics it already allows you to confiugre static ips [23:15] through a system config plugin (that i have to finish first) that reads from /etc/network/interfaces [23:16] fedora 8 released with 0.7 beta [23:16] but are having a long-term release, which is why we are evaluating it [23:17] asac, I see,