[01:13] <Ubulette> from a pretended free service
[01:13] <asac> cwong1: i think i tested it here before my image broke
[01:13] <asac> cwong1: now i have no chance to test it anymore
[01:14] <cwong1> asac: It should be back up tonight
[01:14] <asac> Ubulette: well its free ... but you get something when you donate :)
[01:14] <asac> cwong1: ok i will try tomorrow
[01:14] <cwong1> ok
[01:14] <asac> cwong1: but please fix the chroot
[01:14] <asac> :)
[01:15] <Ubulette> receiving only when you donate, in my country means pay
[01:15] <asac> Ubulette: yeah ;) ... if i donate to greenpeace i get a brochure :)
[01:15] <asac> Ubulette: though i consider this a waste of money ... i don't think i pay for it
[01:16] <asac> Ubulette: the difference between pay and donate is a contract :)
[01:16] <asac> Ubulette: if you donate you have no right to get something ... while when you pay you usually do
[01:16] <Ubulette> it's even worse
[01:17] <Ubulette> well, forget about this, i'll never connect from anywhere but home then
[01:21] <asac> oftc doesn't cloak at all
[01:21] <asac> i think irc.gnome.org and mozilla.org do though
[01:21] <asac> (by default)
[01:54] <Ubulette> i give up with songbird. it's not ready to be packaged. too much work to do to get rid of all the stuff bundled
[01:54] <Ubulette> no support at all for any system libs
[01:55] <Ubulette> just ugly, or too young, or both
[01:59] <Ubulette> i've already made a dozen of patches and it still doesn't compile without the prebuilt deps in the source tree
[01:59] <Ubulette> 'night
[10:29] <Bernardo> good morning
[10:36] <asac> hi
[10:36] <asac> Bernardo: you had ipw3945?
[10:39] <Bernardo> yes, I have one
[10:39] <Bernardo> I debugged it with you a few days ago, had to enable showing the ssid for it to connect under gutsy
[10:43] <Bernardo> asac: do you want me to do more tests?
[10:52] <asac> yeah right
[10:52] <asac> actually we fixed the driver for a bunch of bugs ... would still be curious to see though why it doesn't connect to hidden
[10:53] <asac> but not right now ... will you be here later? or tomorrow?
[10:54] <Bernardo> yes, it's even better  for me if it is later, as I  about to leave
[10:55] <Bernardo> I managed to connect fine just now, after the latest bunch of updates to kde, etc.,  AFTER restarting NetworkManager. I even had to do a couple "kill -9" to get it to die
[10:55] <Bernardo> before that it would just hang (I had just restarted X after the updates) claiming that there was a scheduled activation to eth1, and would sit there for ever
[10:58] <asac> hmm strange
[10:58] <asac> we haven't uploaded a thing
[10:58] <asac> ;)
[10:59] <Bernardo> I think it was possibly some "communication error" between knetworkmanager and NetworkManager
[11:00] <Bernardo> the update might have broken something temporarily
[11:20] <asac> Bernardo: cu
[12:10] <gnomefreak> Ubulette: you here?
[12:10] <gnomefreak> cant grab the trunk package i want
[12:11] <gnomefreak> https://code.launchpad.net/~mozillateam/firefox/trunk gives error
[12:11] <gnomefreak> nvm i missed something
[12:21] <gnomefreak> asac: how did iceape go?
[12:22] <gnomefreak> i go to dr today i hope
[12:22] <gnomefreak> in about 4 hours (to be on safe side) the gutsy repo is ready the feisty should already be ready
[12:23] <gnomefreak> ok trunk is uploading im out for a bit again
[12:25] <asac> gnomefreak: i will take a look tomorrow
[12:25] <asac> aeh today :)
[12:26] <gnomefreak> asac: k
[12:56] <gnomefreak> damn trunk orig is huge
[01:33] <asac> ffox?
[01:34] <asac> hi TheMuso
[01:34] <TheMuso> Hey asac
[01:34] <asac> Ubulette: TheMuso found out why ffox ftbfs on powerpc :)
[01:34] <TheMuso> I have worked out why firefox-granparadiso FTBFS on PowerPC if anybody is interested.
[01:35] <asac> sure!
[01:35] <TheMuso> Thanks to some autoconf/automake changes somewhere.
[01:36] <TheMuso> Exactly what was changed I haven't figured out, but I at least know of a hacky solution to get it to build.
[01:36] <asac> you found the right place to fix it?
[01:36] <asac> ok let us know :)
[01:36] <TheMuso> I'm currently test-building trunk, just to be sure it works.
[01:37] <TheMuso> The problem is that all the Makefile code, particularly for xptcall, checks OS_ARCH and OS_TEST joined together for the string Linuxppc
[01:38] <TheMuso> For some reason, since alpha7 I think, this string with these two vars represents Linuxpowerpc, which makes the xptcall code compilation fail with a not implemented message, since it doesn't match any checks.
[01:38] <TheMuso> The hacky solution is to place a reassignment call in configure.in/configure to force OS_TEST to be ppc, if a powerpc cpu is detected.
[01:39] <TheMuso> asac: WOuld it be easier if I were to show you with a patch?
[01:42] <asac_> sorry was offline
[01:42] <asac_> 13:36 < TheMuso> The problem is that all the Makefile code, particularly for xptcall, checks OS_ARCH and OS_TEST joined together for the  string Linuxppc
[01:43] <asac_> 13:38 < asac> right
[01:43] <asac_> 13:38 < asac> now its ppc64? or what?
[01:43] <asac_> thats the last i had
[01:43] <asac_> TheMuso: ?
[01:43] <TheMuso> ok hang on a sec.
[01:43] <TheMuso> For some reason, since alpha7 I think, this string with these two vars represents Linuxpowerpc, which makes the xptcall code compilation fail with a not implemented message, since it doesn't match any checks.
[01:44] <TheMuso> The hacky solution is to place a reassignment call in configure.in/configure to force OS_TEST to be ppc, if a powerpc cpu is detected.
[01:44] <asac_> you mean it changed in ubuntu ... or in firefox?
[01:44] <TheMuso> The hacky solution is to place a reassignment call in configure.in/configure to force OS_TEST to be ppc, if a powerpc cpu is detected.
[01:44] <TheMuso> asac_: Sorry, in firefox.
[01:44] <TheMuso> Trunk shows similar behavior.
[01:44] <asac_> well ... i mean did firefox change code?
[01:45] <asac_> TheMuso: please go to bonsai.mozilla.org
[01:45] <TheMuso> in configure.in, yes, but what they changed to break this, I don't yet know.
[01:45] <asac_> then search on HEAD (preselected) for configure.in file ... and select "since beginning of time"
[01:45] <asac_> at the button
[01:45] <asac_> then you should see modifications to configure.in ... if you find the checkin that changed it let me know
[01:46] <TheMuso> asac_: Ok.
[01:46] <asac_> s/button/bottom/ :)
[02:03] <TheMuso> asac: When was alpha5 released? I need a date to work from.
[02:09] <asac> hmm end of may?
[02:09] <TheMuso> asac: Ok, I've found out.
[02:21] <TheMuso> asac: If I am viewing a diff, is there a way I can actually download a copy of the diff to be applied with patch?
[02:25] <TheMuso> asac: nvm go one.
[02:30] <TheMuso> asac: I have a tentative finding. I backed out the changes to that commit, and am testing.
[02:30] <TheMuso> asac_: ^^
[02:42] <TheMuso> asac: The commit on 2007-07-14 15:00, version 1.1843 for configure.in, committed by asquella@gmail.com for mozilla bug 372428, to fix a bug allowing a 64-bit kernel and a 32-bit userspace seems to be the commit that broke linux ppc building.
[02:42] <ubotu> Mozilla bug 372428 in Build Config "firefox configure.in does not work currently with a 64 bit kernel and a full 32 bit userland" [Normal,Resolved: fixed]  http://bugzilla.mozilla.org/show_bug.cgi?id=372428
[02:42] <asac> TheMuso: ok i will oook after lunch
[02:42] <asac> now out for lunch
[02:42] <TheMuso> sure.
[04:13] <asac> TheMuso: i think this has to be fixed for real ... there are multiple places that match for ppc which probabyl should now match for powerpc
[05:43] <asac> Ubulette: ok lets prepare xulrunner and firefox-granparadiso for gutsy
[05:48] <asac> ;)
[05:50] <asac> Ubulette: i can do the work needed to get things going for paradiso ... just wanted to know if you see any issues up-front?
[07:25] <Ubulette> hi
[07:27] <Ubulette> asac, i wanted to do that directly with a8
[07:39] <asac> ok cool ...
[07:39] <asac> let me look
[07:40] <asac> ok next tuesday
[07:40] <asac> today is freeze for m8
[07:40] <asac> is there anything we can do upfront? ... e.g. merging trunk branch to paradiso and switching to without-system-{nss,nspr} ?
[07:41] <asac> or better do that right after release?
[07:42] <Ubulette> it's better to have a8 tarball 1st. otherwise, patches will have to be updated twice
[08:03] <asac> Ubulette: ok
[09:16] <Bernardo> hi
[09:18] <Bernardo> asac: had to reboot because strigi filled my home partition and crashed X, and networkmanager seems to be working fine, connected without problems.
[10:10] <shirish> asac: Ubulette: hey guys
[10:10] <shirish> what's up?
[10:10] <Ubulette> hi
[10:11] <shirish> Ubulette: nice to know that you're up, btw you should start writing a blog or something
[10:11] <shirish> Ubulette: with the cool links you know & stuff you do, me mere mortals can learn a thing or two from you for sure :)
[10:12] <shirish> Ubulette: and at the same time come to know what new is cooking :)
[10:12] <shirish> Ubulette: so were/are you able to get songbird up?
[10:12] <Ubulette> people in gutsy's forum already asked me the same thing
[10:12] <Ubulette> songbird is too young i'm afraid
[10:13] <Ubulette> it's filled with binaries
[10:13] <Ubulette> it needs a serious rework of the build system to be packaged in an acceptable way
[10:13] <shirish> Ubulette: oh sorry to repeat the query then
[10:14] <shirish> Ubulette: see ;) a rant/query/whatever it is makes for a very good blog post.
[10:15] <shirish> Ubulette: any idea as to what's happening with gnash by any chance? I know you're not involved with it but as asac is perhaps you know what's going on in there
[10:15] <Ubulette> sorry, no clue
[10:17] <shirish> Ubulette: ok no issues, just do me a favour, if & when asac's around & if you do remember to ask him, please ask him about the status of gnash, although I'm equally looking forward to trying out swfdec as & when that can happen :)
[10:18] <Ubulette> sure
[10:19] <Ubulette> hmm, addons now need to be secured in trunk
[10:19] <shirish> Ubulette: thanx, and either of you drop me a mail whenever things are moving
[10:19] <Ubulette> http://www.sofaraway.org/ubuntu/tmp/addons-no_secure_updates.png
[10:19] <Ubulette> http://www.sofaraway.org/ubuntu/tmp/addons-no_secure_updates2.png
[10:20] <Ubulette> should work around that
[10:20] <Ubulette> hm, easy
[10:21] <shirish> Ubulette: secure updates, something on the lines of having some kind of digital signature or something, from let's say mozilla foundation or what?
[10:21] <shirish> or a.m.o ?
[10:22] <Ubulette> no, just updates through https i guess
[10:23] <shirish> hmm... that shouldn't be so hard but then its not so hard to forge through https:// also
[10:24] <Ubulette> forge https ? no
[10:25] <Ubulette> as the update url is in the package, it's good enough as long as the original install was genuine and from a secured site
[10:26] <shirish> I attended a security conference some days ago & they showed how easy its to manipulate, but whatever
[10:27] <shirish> simply speaking, either its becoming harder to take assumptions or I'm becoming more paranoid with all the hacks happening all over the place ;)
[10:28] <shirish> dunno what else to say
[10:30] <shirish> Ubulette: anyways, so we can expect this in today's build? the no_secure_updates thing, its actually better than before for sure.
[10:31] <Ubulette> was already there yesterday as i'm still in the middle of today's upgrade
[10:31] <Ubulette> hmm, strange. gusty's ahead of my bot for file-roller
[10:32] <shirish> Ubulette: that's curious as I didn't get it. I downloaded couple of add-ons from a.m.o
[10:33] <Ubulette> probably because all yours are updating on https
[10:33] <Ubulette> tabmix+ dev is over http
[10:33] <Ubulette> plain tabmix+ doesn't work with trunk
[10:34] <shirish> ah ok, will try that for kicks, let this update/upgrade happen & let's see what happens ;)
[10:34] <shirish> Ubulette: didn't we pass m8 , feature-freeze or they pushed back the dates?
[10:37] <Ubulette> hmm, no bump yet
[10:37] <shirish> Ubulette: ok cool
[10:38] <shirish> Ubulette: I might have asked you this question before, if so please pardon me, but do you know who's packaging Kazehakase ?
[10:38] <Ubulette> that should be automatic in my repo
[10:38] <Ubulette> nope
[10:39] <shirish> Ubulette: you have Kazehakase in your repo. ?
[10:39] <Ubulette> nope
[10:39] <shirish> any idea if you will go for it sometime?
[10:40] <Ubulette> maybe as it would be interesting to make it work with our new xulrunner 1.9
[10:40] <TheMuso> asac: SO what do you mean exactly? As I said, changing that one commit has caused things to work here on PowerPC.
[10:41] <shirish> Ubulette: I'm sure it would be, just lemme know if you do something on that front, I do like Kazehakase, maybe because it's so different in some ways
[10:52] <shirish> Ubulette: also unlike ff, its pretty lightweight at 1.4 MiB or even less.
[10:54] <Ubulette> ff is light now :)
[10:59] <shirish> it is but Kazehakase is much lighter than it ;)
[11:00] <shirish> anyway, gotta sleep , see you tomorrow, take care
[11:00] <shirish> bye
[11:00] <Ubulette> cu
[11:02] <cwong1> asac: Question on MOZ_NO_REMOTE
[11:11] <Ubulette> asac, is Kazehakase maintained in a vcs ?
[11:24] <asac> Ubulette: debian? no idea
[11:24] <asac> cwong1: what question?
[11:25] <asac> TheMuso: i am not sure ... but now the use target_cpu instead of OS_TEST=$(uname -m) to match the arch
[11:25] <asac> apparently its powerpc instead of ppc ... while for other archs it appears to work
[11:27] <asac> Ubulette: does it look doable to move kazehakase to xulrunner-1.9?
[11:28] <cwong1> asac: I was looking into the problem why midbrowser wouldn't start in the new target. It appears to be screwed up somewhere in the XRemoteClient's SendCommandLine.  If I set MOZ_NO_REMOTE to yes and it ran ok since it doesn't use remoteclient. The question really is should it go thru XRemoteClient?
[11:30] <asac> cwong1: XRemote client is used to open new windows/tabs if you click on links in other applications ... i think we cannot live without it
[11:30] <asac> cwong1: why the hell would it break?
[11:30] <asac> that sounds like a rather big bug in the xserver
[11:30] <cwong1> asac: I don't know yet.  I don't think the problem is in our code
[11:31] <cwong1> asac: I have a version of the browser that ran in the old target but as soon as I did an upgrade it started failing
[11:31] <TheMuso> asac: We  need to know where TARGET_CPU/target_cpu is getting its value from...
[11:31] <TheMuso> I guess.
[11:32] <asac> cwong1: currently the image is still broken for me
[11:32] <asac> cwong1: i couldn't even open xeyes
[11:32] <asac> and the marque panel crashes when clicking on the application switcher
[11:32] <asac> and the application menu doesn't look reasonable as well
[11:33] <asac> http://people.ubuntu.com/~asac/screen1.png
[11:33] <asac> thats an up-to-date image-creator created chroot about 12 hours ago.
[11:33] <cwong1> asac: somthing is wrong with the hildon-desktop.  They know about it. Would that be the causeof the problem?
[11:33] <Ubulette> looks fun. too bad i don't have such a device :)
[11:37] <asac> Ubulette: its just a xephyr window :)
[11:37] <asac> cwong1: i think we should not bother until i can at least open such basic applications like xeyes
[11:38] <asac> export DISPLAY=:2
[11:38] <asac> xeyes
[11:38] <asac> doesn't start for me
[11:51] <cwong1> asac: I agree.  We should wait til things settle.
[11:55] <asac> cwong1: its a bit wierd so
[11:55] <asac> just xephyr + matchbox doesn't allow me to start midbrowser as well
[11:56] <asac> maybe i will take a look again tomorrow
[11:56] <asac> but since there was a xephyr upload yesterday i assume that i might have broken something
[11:56] <cwong1> ok
[12:03] <Ubulette> asac, Kazehakase's patch contains much more than just debian/*, is that right ?
[12:04] <Ubulette> asac, http://pastebin.mozilla.org/194347
[12:05] <asac> let  me look
[12:05] <asac> Ubulette: its probably the diff needed to build against debian xulrunner
[12:05] <asac> maybe we can drop that
[12:06] <asac> i would just start with debian/ dir and see whats going on
[12:07] <asac> maybe you can see in changelog what was done to the Makefile's
[12:11] <Ubulette> debian bug 352084
[12:11] <ubotu> Debian bug 352084 in kazehakase "kazehakase: Build-Dep on mozilla (library), should transition to xulrunner" [Serious,Fixed]  http://bugs.debian.org/352084
[12:14] <Ubulette> mike patched configure to look for his xul 1.8, is/was not supported upstream
[12:15] <asac> yeah thats what i thought
[12:15] <asac> does upstream support our sdk?
[12:15] <Ubulette> don't know yet
[12:16] <Ubulette> the makefile patches are all for:
[12:16] <Ubulette> -       -DGTK_DISABLE_DEPRECATED=1 \
[12:16] <Ubulette> -       -DGDK_DISABLE_DEPRECATED=1 \
[12:16] <Ubulette> -       -DG_DISABLE_DEPRECATED=1
[12:16] <Ubulette> bug 137269
[12:16] <ubotu> Launchpad bug 137269 in kazehakase "[FTBFS]  kazehakase" [Undecided,Fix released]  https://launchpad.net/bugs/137269
[12:20] <Ubulette> the web site is messy
[12:21] <Ubulette> hm, the japanese version is better
[12:32] <Ubulette> if test "$gecko_version_major" != "1" -o "$gecko_version_minor" -lt "7" -o "$gecko_version_minor" -gt "9"; then
[12:32] <Ubulette>         AC_MSG_ERROR([Unsupported Gecko version $gecko_version_major.$gecko_version_minor] )
[12:32] <Ubulette> fi
[12:32] <Ubulette> asac, seems good
[12:33] <Ubulette> if test "$gecko_version_major" = "1" -a "$gecko_version_minor" -ge "9"; then
[12:33] <Ubulette>         AC_DEFINE([HAVE_GECKO_1_9] ,[1] ,[Define if we have gecko 1.9] )
[12:33] <Ubulette> fi
[12:34] <asac> nice
[12:35] <Ubulette> GECKO=
[12:35] <Ubulette> AC_ARG_WITH([gecko_engine] ,
[12:35] <Ubulette>         AS_HELP_STRING([--with-gecko-engine@<:@=mozilla|firefox|thunderbird|seamonkey|xulrunner@:>@] ,
[12:35] <Ubulette>                        [Whether to use mozilla, firefox or thunderbird or seamonkey xpcom (default: mozilla)] ),
[12:35] <Ubulette>         [GECKO="$withval"] )
[12:37] <Ubulette> $PKG_CONFIG --exists xulrunner-xpcom
[12:37] <Ubulette> gasp, we don't provide that so far
[12:41] <Ubulette> seems moz guys renamed those .pc files
[12:43] <TheMuso> asac: I guess it wouldn't make sense to put a test case in for Linux and powerpc, to use uname -m, or force OS_TEST to ppc...
[12:44] <asac> Ubulette: isn't xulrunner-xpcom a debianism? or is that shipped somewhere in dist ?
[12:44] <asac> TheMuso: i don't think that its the right thing to do
[12:44] <Ubulette> asac, the $PKG_CONFIG --exists xulrunner-xpcom test is from kaze cvs
[12:45] <asac> Ubulette: yes it is
[12:45] <Ubulette> asac, xul 1.9 seems to ship libxul.pc and libxul-embedding.pc
[12:45] <asac> ah right
[12:45] <asac> 1.8 shipped xulrunner-xpcom
[12:45] <asac> ok
[12:45] <asac> maybe they changed that recently and kaze code is not yet adapted
[12:46] <Ubulette> libxul-embedding is for -lxpcomglue
[12:46] <asac> yes kaze should use that i guess
[12:46] <Ubulette> libxul.pc is for -lxpcomglue_s -lxul -lxpcom
[12:46] <asac> -lxpcomglue? thats not static?
[12:47] <Ubulette> -lxpcomglue_s is static
[12:49] <Ubulette> well
[12:49] <asac> right which makes me wonder if libxul-embedding is right
[12:49] <Ubulette> both are static
[12:49] <asac> iirc there is no shared glue available by default ... is there?
[12:49] <asac> ok
[12:49] <Ubulette> libembed_base_s.a  libembed_base_standalone.a  libmozreg_s.a  libunicharutil_external_s.a  libxpcomglue.a  libxpcomglue_s.a  libxpcom.so  libxul.so
[12:50] <Ubulette> in /usr/lib/xulrunner-devel-1.9a8pre/sdk/lib/
[12:52] <Ubulette> so for kazehakase, that means tweaking configure to call pkg-config on libxul-1.9
[12:53] <asac> i think kaze should use -embedding
[12:53] <asac> its not a xul app ... just gecko embedder
[12:55] <Ubulette> yep right. it's just that they are looking for xpcom everywhere
[12:56] <Ubulette> just to get the gecko version at the end
[12:56] <TheMuso> asac: An alternative is to change all the Makefile checks to check for Linuxpowerpc instead of Linuxppc... - Just thinking out loud here...
[12:56] <asac> TheMuso: look in the .mk files
[12:56] <asac> you will find where it is
[12:58] <Ubulette> it would be nice to *print* those $OS_whatever during build so we can see them in the logs.. instead of guessing
[12:58] <TheMuso> asac: I know its there, as thats how I found out what the problem is. I am just trying to think of sane ways to fix it.
[12:59] <TheMuso> Ubulette: I found the settings for OS_TEST and OS_ARCH by looking in config.status.
[12:59] <TheMuso> Doesn't help while building, but still useful.
[12:59] <Ubulette> because you have access to a ppc box :) we don't
[12:59] <Ubulette> or at least, i don't
[01:00] <TheMuso> Ubulette: As I've said. I know what the problem is, and its just a matter of working out a sane fix.
[01:00] <Ubulette> (that's why i never fixed the ftbfs of granparadiso)
[01:00] <TheMuso> Ubulette: Yeah I thought as much.
[01:04] <TheMuso> target_cpu is worked out from the target, which varies from arch to arch. On powerpc its powerpc-linux-gnu, i386 its i386-linux-gnu, etc.
[01:05] <TheMuso> Found out from looking at the configure script, and getting it to spit out the values of target and target_cpu.
[01:10] <TheMuso> asac: Turns out that out of the whole source, there is only one lot of code who's makefile needs to check for Linuxppc. That is the xptcall code.
[01:15] <asac> maybe they match *-linux-gnu) somewhere?
[01:16] <TheMuso> asac: Well the first part of that is used to determine the CPU type, which obviously helps with the 32-bit userspace on 64-bit kernel.
[01:17] <asac> yes
[01:17] <TheMuso> And yes they do match it, but only to set optimization/CFLAGS.