[00:05] <Lns> I have a "quick hack patch" from a while ago that uses LD_PRELOAD to replace attempts to access /dev/random with /dev/urandom... I'm not knowledgeable enough to know if i should rely on this, rather than the actual nspr fix I see was made
[00:22] <Lns> I guess i'll plan on using the "nasty hack" - if anyone has some insight on how someone like me can possibly, "more reliably" test the issue, please comment in https://bugs.launchpad.net/ubuntu/+source/nspr/+bug/269188 - thanks all!
[12:14] <[reed]> fta / asac: http://www.fosscamp.org/HowToAttend
[12:14] <[reed]> " Stephen Lau
[12:14] <[reed]> 	
[12:14] <[reed]> Songbird
[12:14] <[reed]> 	
[12:14] <[reed]> system-wide XULRunner anyone?"
[12:14] <[reed]> except there is system-wide XULRunner
[12:15] <[reed]> just that Songbird can't use it since they patch it!
[12:25] <asac> [reed]: i wont even be at fosscamp :/
[12:25] <asac> i arrive on sat evening
[12:25] <asac> [reed]: and yes. not sure what thats about
[12:26] <asac> [reed]: we discussed with songbird folks a bunch of times that we need to get their patches sorted
[14:40] <fta> 172 tabs, gasp
[14:52] <fta> [reed], i'm now suffering from mozilla bug 404314
[14:53] <fta> it regressed for me recently :(
[15:02] <[reed]> fta: it has to be something gtk-related...
[15:02] <[reed]> I've hit the same bug just using gedit
[15:22] <asac> fta: is it really random or just when you accidentially move your mouse while clicking?
[15:28] <fta> not really random, it seems it selects the 1st entry
[15:29] <fta> i was used to click a menu to open it, now, i need to click and hold otherwise it selects the 1st entry
[15:44] <asac> fta: yeah. then its the "non-random" part of the bug
[15:44] <asac> fta: have you tried to release button and explicitly dont move the mouse?
[15:45] <asac> i dont see how it can select a menu entry if you dont move the3 mouse at all
[17:39] <asac> heh. i am twice on the hall of fame ;)
[17:39] <asac> busiest sponsor ... thats actually the last category i would have expected me
[17:40] <asac> they apepar not to count the mozilla sponsorships
[17:41] <fta> i'm not sure if i should push my stuff or not
[17:42] <asac> fta: which stuff?
[17:42] <fta> what we discussed in the last meeting
[17:43] <asac> do those packages have "need-packaging" bugs?
[17:43] <asac> if so, i can peer-review things and then it should be fine.
[17:43] <asac> i talked a bit about all this
[17:43] <asac> with folks
[17:43] <asac> seems to be that peer review (e.g. what persia said) is not required, but a guideline
[17:43] <fta> no, because i'm not sure what you want, snapshots vs releases
[17:43] <asac> which we should encourange
[17:44] <asac> usually releases i would say
[17:44] <fta> i just packaged python-tlslite
[17:44] <asac> or if you are sure there will be a release before feature freeze pushing pre-snapshots might work
[17:44] <fta> if it's releases, i have nothing to push, period
[17:44] <asac> releases != final releases .... beta sounds good if hte package is usable
[17:45] <asac> i dont even care if you push snapshots. its just that things going up to archive should be more stable than daily snapshots pushed to PPA ;)
[17:45] <asac> archive should just get something more or less stabilized.
[17:46] <asac> if there are no releases we have to do the stabilization somehow.
[17:46] <asac> but starting with a beta for initial upload sounds sensible
[17:46]  * sebner is too shy to ask asac for an autograph :P
[17:46] <asac> hehe
[17:46] <asac> i won't give any anyway ;)
[17:47] <sebner> bah :P
[17:47] <sebner> how do you treat your fans :P
[17:47] <asac> only when i reach the first rank for bug tracking ;)
[17:47] <fta> then it confirms i have nothing to upload
[17:47] <asac> fta: why?
[17:47]  * fta going back to more chromium work
[17:49] <asac> fta: its hard to say that random snapshots are good in general. if you think something is usable we can look at individual cases
[17:50] <fta> i don't care, early or not, nothing gets in
[17:50] <asac> your call ;)
[17:55] <fta> moz-central is about to jump to 3.2a1pre, and 3.1* is still only in my ppa. what should i think of all that ? huge loss of time ?
[18:00] <asac> i dont understand what you mean
[18:00] <asac> 3.1 is certainly at beta
[18:00] <asac> so thats ok to upload for sure.
[18:01] <asac> just pick a milestone for the archive upload
[18:04] <asac> 18:46 < asac> but starting with a beta for initial upload sounds sensible
[18:04] <asac> and surely that work is not loss of time because 3.1 will definitly be in the archive ... if not today, then tomorrow :)
[18:08]  * asac off to grocery store ... bb soon
[18:53] <asac> back
[22:05] <asac> debian bug 482415
[22:06] <asac> debian bug 495311
[22:09] <asac> good ... not affected :-P
[22:48] <fta> asac, http://launchpadlibrarian.net/19844522/buildlog_ubuntu-jaunty-amd64.xulrunner-1.9.1_1.9.1~b2~hg20081121r21862%2Bnobinonly-0ubuntu1~fta1_FAILEDTOBUILD.txt.gz
[22:48] <fta> the new cairo now does directfb too
[22:49] <fta> strangely, it doesn't fail on i386
[22:51] <fta> oh damned, my chroot still has the old cairo
[22:57] <asac> fta: holded back locally?
[22:57] <asac> fta: did you do the new cairo? :-P
[22:58] <fta> no, my ppa line was still intrepid
[22:58] <fta> yes
[22:58] <fta> to late for a1 so it's still only in my ppa
[22:58] <fta> too
[22:58] <fta> http://ppa.launchpad.net/fta/ubuntu/pool/main/c/chromium-browser/
[23:19] <fta> asac, what i mean is that we've never built a xul with a cairo doing directfb
[23:19] <fta> debian does now, at least with their experimental cairo
[23:42] <directhex> asac, remember the plugin-detector-manglement for the plugin finder to get invoked instead of javascriot-based "please install fooplugin to use this site" stuff you were talking about a while back... is that anywhere on your jaunty TODO?