[00:14] what's the about:config option to allow incompatible extension to install? [00:15] I'm presuming that the difference between b3 and b4pre isn't really gonna make things worse :p [00:15] extensions.checkCompatibility [00:16] ah, thanks [00:17] i would recommend the Nightly Tester Tools addons instead [00:17] oooo, that sounds like fun. wazzat? [00:18] http://www.oxymoronical.com/web/firefox/nightly [00:20] looks handy [00:20] it's also available at https://addons.mozilla.org/en-US/firefox/addon/6543 [00:35] Setting up firefox-3.1-gnome-support (3.5~b4~hg20090317r23798+nobinonly-0ubuntu1~umd1) ... [00:35] touch: cannot touch `/usr/lib/firefox-3.1*/.autoreg': No such file or directory [00:36] boohhh, big rename needed [01:21] asac, just upgraded my nc10 from a6 to current, can't connect to wifi anymore [01:25] what are your thoughts on a greasemonkey script that replaces settimeout and setinterval with versions that a rather large minimum delay to address my (imagined?) issues of firefox's resting cpu being ~25% with no plugins or addons present? [01:26] s/that a/that have a/ [01:27] at 2:30am, no thought at all :P [01:28] :p [03:28] Is there any place to apply a css rule when printing any document? [03:59] you know, my firefox session had 57 days of up-time until today :p [09:01] cwillu: 57 days up calls for trouble ;) [09:46] fta Firefox daily failing to install http://paste.ubuntu.com/132937/ [10:03] BUGabundo, i know, i fixed 3.1 yesterday, but i didn't respin the bot yet [10:24] fta ok [11:03] fta: http://www.golem.de/0903/65978.html [11:05] asac, :) [11:05] fta: you understand that? [11:06] for the most part yes [11:06] fta: it basically gives all the credits for the chromium linux port to you and ubuntu ;) [11:06] lol [11:06] angenommen? [11:07] what does that mean? approved? [11:07] fta: "hat sich Fabien Tassin einer Portierung angenommen. " -> that translates to: "fabien tassin took care of the port" [11:07] took care [11:07] oh [11:07] so it's wrong [11:07] yeah. but in a good way [11:08] so it reads: "because google doesnt provide a linux version of chrome, fabien took this over and ported it to linux" ;) [11:11] that part i understood, so just s/ported/packaged/ and that's correct [11:11] fta: right ;) ... feel free to complain [11:11] or maybe just wait and see if this becomes fully known truth knowledge ;) [11:11] ahahah [11:12] so who was the real guy/gal/team behing the port? [11:12] BUGabundo: the chrome linux developers? [11:12] yes [11:12] google folks [11:13] that's mostly google itself, and a bunch of contributors [11:13] so is it packaged now for ubunt and Linux in general? [11:13] also running on 64 bits? [11:13] in my ppa, yes, sort of [11:14] it's crashy on amd64 because of nss [11:14] so https doesn't work for some reason [11:14] and my dailies are broken too [11:14] https://edge.launchpad.net/~chromium-daily/+archive/ppa?field.name_filter=&field.status_filter=any&field.series_filter=jaunty [11:15] no idea why amd64 only btw [11:19] how can i tweak the brightness of this thing, it's too dim during the day, even when set to the maximum [11:19] for some reason, wifi is back (nc10) [11:20] fta: is that atheros? [11:25] yes [11:26] i didn't upgrade anything today [11:27] i did yesterday, massive upgrade. rebooted a few times, even on the previous kernel, nada, wifi broken. power off for the night, now wifi is back [11:27] fta: maybe your AP? [11:27] modinfo ath5k? [11:28] sigh. i am having pulseaudio issues [11:28] will it ever get to a usable state? [11:28] dtchen_: are there any fixes in the pipeline still for this cycle? [11:29] there was no wifi at all listed in nm, not even my neighbors [11:29] and in dmesg, there was some strange logs [11:33] like this: [11:33] Mar 18 02:15:03 nano kernel: [ 60.506824] ath5k phy0: noise floor calibration failed (2412MHz) [11:33] Mar 18 02:15:03 nano kernel: [ 60.833875] ath5k phy0: gain calibration timeout (2457MHz) [11:33] Mar 18 02:15:03 nano kernel: [ 60.833888] ath5k phy0: can't reset hardware (-11) [11:44] asac: my NM gets turned of after every hibernate/resume cycle [11:44] its reproduclba with both -10 and -9 [11:46] BUGabundo: yes. please /usr/lib/pm-utils/sleep.d/55NetworkManager [11:46] BUGabundo: and add a --reply to the wake up and sleep dubs-send lines [11:47] that will fix it [11:47] please verify [11:51] sorry? [11:51] got confused [11:51] multitasking is hard [11:54] dbus_send --system \ --dest=org.freedesktop.NetworkManager \ /org/freedesktop/NetworkManager \ org.freedesktop.NetworkManager.sleep \ --reply [11:54] } [11:54] like this? asac ^^ [11:57] BUGabundo: not sure [11:57] he is gone [11:57] i would think you should put the option further before [11:57] e.g. before the --system [12:02] asac: not sure? didn't you asked me to add the --reply there? [12:03] BUGabundo: yes. but with some human snese ;) [12:04] 12:57 < asac> he is gone [12:04] 12:57 < asac> i would think you should put the option further before [12:04] 12:57 < asac> e.g. before the --system [12:04] http://paste.ubuntu.com/132988/ [12:04] BUGabundo: adding flags to the end usually doesnt work in unix [12:04] there are cases where it does [12:04] but if there is a "string" only argument it doesnt [12:04] ah ok. putting higher [12:04] BUGabundo: put it in the same block [12:04] that other arguments use [12:04] BUGabundo: you can run the command on your own to test [12:05] BUGabundo: just replace the _ with - in dbus_send [12:05] to test on commadn line [12:05] http://paste.ubuntu.com/132990/ [12:05] like this? [12:06] $ dbus-send /usr/lib/pm-utils/sleep.d/55NetworkManager [12:06] Usage: dbus-send [--help] [--system | --session | --address=ADDRESS] [--dest=NAME] [--type=TYPE] [--print-reply=(literal)] [--reply-timeout=MSEC] [contents ...] [12:07] dbus-send --reply --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.wake [12:07] Usage: dbus-send [12:07] doesn't work either [12:25] BUGabundo: thats insane [12:25] why would you run the command that way? [12:25] oh [12:25] ;) [12:25] sorry didnt see the last command [12:25] BUGabundo: ok its --print-reply ;) [12:26] ah [12:26] nope [12:26] doesn't work [12:26] wait [12:26] typo on my part [12:26] BUGabundo: you need to be root i would think [12:26] Error org.freedesktop.NetworkManager.AlreadyAsleepOrAwake: Already awake [12:26] BUGabundo: good [12:26] works [12:26] so add the --print-reply to the file [12:26] editing file [12:26] and then suspend and resume a few times [12:27] i think that should fix the issue [12:27] will do during lunch break [12:27] BUGabundo: oh ... you might want to append 2>&1 > /dev/null at the end [12:27] not sure if pm-utils doesnt like scripts printing stuff [12:27] i would think without the /dev/null would work. but i havent tried that [12:54] Hi, does anyone know how much memory is needed to build xulrunner-1.9 on armel? I'm running into swap issues which bring the platform down during the build... [12:54] dave_m_: hard to say for armel [12:54] dave_m_: but in x86 it takes about 1.4 G [12:54] to link the libxul.so [12:54] which should be the memory peak [12:54] maybe 1.2G [12:54] armel could be less depending on how the binaries are built [12:55] OK... I should have plenty then. I enabled 5G, which should be enough for anyone. I'm running into I/O errors when swapping, so I'll try using a different swap partition and see whether that helps. [12:55] dave_m_: 5G mem or swap? [12:56] I should be so lucky :) 512MB ram + 5G swap [12:56] yeah. thought that [12:56] will definitly be slow slow slow [12:56] How much RAM on the Marvell boards? [12:56] dave_m_: i think they have 512 too. but i am not really involved in arm port [12:57] OK... I think this is probably a hardware issue, not a porting issue anyway. [12:57] dave_m_: could be. i just say that building with 512 will take a while ;) ... in theory it should work [12:57] Btw, I pulled the latest published source packages, and the config.guess issue on armv7 now seems fixed. [12:58] dave_m_: what is "source packages"? [12:58] dave_m_: ubuntu? [12:58] or firefox-3.2? [12:58] Ubuntu, I meant (xulrunner-1.9) [12:58] * asac pulls latest moz-central [12:59] dave_m_: so without updating config.* files it works? awesome [12:59] * asac wonders if we added magic to auto update those during build [12:59] I didn't do anything... but the problem objects get built now without me interfering [13:00] sounds good. i would think we should still get the upstrea config.* files updated [13:00] or get that rolled to hardy/intrepid [13:00] Various packages were updated in the meantime, so it may have been resolved by something outside the xulrunner-1.9 package itself... [13:00] dave_m_: so the fix happend in jaunty for you? [13:00] Yes, seems fine for me (when my hardware works, anyway) [13:01] When I have a complete build, I'll let you know if I had any additional problems. [13:01] dave_m_: if the OS_TEST string wasnt changed on system, then its probably that we automagically update the config.* files during build and you get cured by recent autoconf packages [13:01] dave_m_: thanks. much appreciated. [13:02] OK [13:09] Btw, xulrunner produces a _lot_ of compiler warnings (I estimate about 80000 when the build is complete, though with many duplicates...) Do I need to be careful about optimisation options? Currently I'm using -O3 [13:09] dave_m_: is it ok to reply here? [13:09] argh [13:09] ah thanks [13:09] dave_m_: problem is that my irc setup is not really made for private chatter ;) [13:09] Reposting that remark [13:09] Btw, xulrunner produces a _lot_ of compiler warnings (I estimate about 80000 when the build is complete, though with many duplicates...) Do I need to be careful about optimisation options? Currently I'm using -O3 [13:10] dave_m_: so. yeah. please be careful [13:10] dave_m_: dont use --enable-optimization="-O3" [13:10] well. at least i would think you should just use --enable-optimization [13:10] also for -O3 i am not sure how huge libxul.so linking is ;) [13:10] maybe 3G? [13:10] my number came from the default mozilla optimization mix [13:11] which is -Os in many places [13:11] and -O3 in some places (like js engine afaik) [13:11] I need to customize, since I'm doing an experimental build with VFP support in arm. [13:11] But I'll remove -O3 [13:11] dave_m_: yes. please do that outside of the configure flags [13:11] CFLAGS might be honoured [13:11] No [13:11] Unfortunately :( [13:12] phone [13:12] There might be some other route, but I didn't find it. At the moment, I just want to see whether there's a real performance benefit. [13:15] asac: I have to disappear in a moment, but we can discuss later if need be. [13:21] dave_m_: i really think it works. i mean we use that to tweak LDFLAGS. have you tried CXXFLAGS? [13:21] dave_m_: otherwise i can check for you [13:21] dave_m_: which option do you want to get added for arm? [13:21] dave_m_: also what do you get for dpkg-architecture -qDEB_BUILD_ARCH [13:25] asac: I thought I tried CXXFLAGS, but I will try it again just in case. It's possible I forgot it. [13:26] dave_m_: look at debian/rules [13:26] asac: DEB_BUILD_ARCH = armel [13:26] we just override CXXFLAGS there [13:26] dave_m_: add your flags there ... also for CFLAGS which means mozjs [13:27] asac: Assume it works for now, and I'll try again if (when) I have to restart the build. [13:28] dave_m_: right. let me know [13:30] asac: For ARM, I am experimenting with adding -mfpu=vfp -mfloat-abi=softfp in addition to the default options. But we can't add this universally because not all platforms have VFP (i.e., hardware floating-point). [13:30] If there's a significant performance benefit (I have reason to believe there might be a 2x speedup for page rendering), then it may be worth investigating how to package an extra version. I'll probably take this up with lool in the first instance. [14:07] jdstrand: is gutsy EOL? or is that in 5 days ;)? [14:08] asac: is it only 5 days? I always treated it as the day before the next release [14:08] asac: I suppose it is on a schedule somewhere... [14:09] jdstrand: could be. i am out of sync ;) [14:09] jdstrand: would make sense if its around the 9.04 release date [14:09] only thing i know is that after gutsy its not that long that dapper will RIP [14:10] heh [14:10] 6.06 ;) [14:11] few more months yet :) [14:11] jdstrand: yeah. but _after_ gutsy is gone its just a breath ;) [14:12] :) [14:13] fwiw, gutsy was released on Oct 18th, so I guess Apr 17th? [14:13] jdstrand: bug 344746 [14:13] Launchpad bug 344746 in nss "Hibernation unreliable after security update" [High,Incomplete] https://launchpad.net/bugs/344746 [14:13] odd [14:13] jdstrand: yeah ;) [14:14] some avatars i see on identi.ca make me feel old. this webkit guy looks like 12 years old ;) [14:14] hopefully he uses his kids pic [14:15] http://identi.ca/stemp [14:15] or even 8 years? [14:15] asac: that is a weird bug. I did actually test evolution with pop3 and imap tls yesterday... [14:15] jdstrand: good. i just asked on the bug because i couldnt test [14:16] jdstrand: he claims its NM ... which indeed links against nss [14:16] at least the daemon does [14:16] but the diff is really just the certificate [14:16] not sure how that can break that [14:16] yeah [14:17] perhaps he didn't restart his session? [14:30] jdstrand: lets hope [14:30] lets check what he says [14:33] jdstrand: hmm. thought it was hardy [14:33] but its intrepid [14:33] did we do a full upstream bump there or also just the backport? [14:33] let me check [14:34] seems like its the backport [14:34] odd [14:46] fta: just installing UNR image i noticed that installer asked you if you want password or auto login [15:56] asac: Me again... tried restarting my build of xulrunner with suitable CFLAGS and CXXFLAGS in the environment, but they are definitely not used. configure picks them up, but they are not used on any cc or g++ command line (~1200 .o files built so far...) Are you sure this technique for overriding the compiler flags really works with mozilla's configure system? [15:59] dave_m_: did you try to add that to rules [15:59] dave_m_: or are you not building with packages? [16:00] dave_m_: i am not 100% sure. but i can find out what you should do. i am sure for LDFLAGS though [16:00] dave_m_: if you tried what i suggested (fix CFLAGS and CXXFLAGS that get overriden in debian/rules) [16:00] then i will check [16:00] but pleaes confirm that you did that ;) [16:10] asac: OK, I see. I had CFLAGS and CXXFLAGS exported in the environment when running dpkg-buildpackage. I thought this was generally supposed to work? (It certainly works for some packages, the the dpkg-buildpackage man page implies that it is sane) [16:11] dave_m_: arguably a packaging bug. [16:11] 14:26 < asac> dave_m_: look at debian/rules [16:11] 14:26 < asac> dave_m_: add your flags there ... also for CFLAGS which means mozjs [16:12] asac: OK, I have CFLAGS = -g and CXXFLAGS = -g in debian/rules. Do you recommend I edit here? [16:14] asac: ... I will try it (and I'll read your instructions more carefully next time ;) [16:23] hi asac, fta! I'm the guy who's trying to get libipc.so and ipc.xpt more easily packageable for debian to streamline fireGPG builds (and future xul-based apps and extensions which rely on the stuff available in IPC). i wanted to ask your advice on packaging/building a XUL component for debian/ubuntu/etc [16:24] background: http://mozdev.org/pipermail/enigmail/2009-March/010959.html [16:24] good news is that i think i've got xulrunner-ipc building against xulrunner-dev with only a simple batch of makefiles [16:25] but that's probably not the Right Way in the long term (and it doesn't resolve the packaging questions about how to distribute the builds) [16:30] dave_m_: yes. for now just edit it there. [16:30] any thoughts on how i should move forward with this? How should individual architecture-dependent XPCOM components be distributed within debian-derived systems? [16:30] dkg0: [16:31] hi [16:31] ;) [16:31] hi asac -- thanks for the invitation ;) [16:31] dkg0: thanks for showing up. [16:31] * dkg0 is still not sure that he's even asking the right questions yet [16:31] heh [16:32] yeah well. question is: "how to properly build components/extensions/xulapps using xulrunner-sdk" [16:32] thats at least my understanding [16:32] that's at least 3 questions ;) [16:33] yeah. but in the end its one solution ;) [16:33] good! [16:33] the real question is "how can we ship mozilla build system as part of xulrunner-sdk" [16:34] we should wait for fta to give us an overview of current state [16:34] that would be a good first-half of a solution. [16:34] but then there's still the question of "once the things are built, how do you distribute a solitary XPCOM component maintainably?" [16:34] second half would be using that for ipc/enigmail/xulapps [16:35] dkg0: right. [16:35] dkg0: there are multiple options [16:35] for example, are there SONAME version issues? [16:35] a) ship them as an extension [16:35] b) ship them as components [16:35] and what's the difference between xulrunner/stable and xulrunner/unstable [16:35] (i don't mean lenny vs sid, i mean what i see in the xulrunner-dev package) [16:35] dkg0: are you talking about debian in particular here (stable/unstable)? [16:36] ah [16:36] yeah well thats a different thing and probably becomes irrelevant once we fix the xulrunner sdk [16:36] to deliver the pieces for a build system [16:36] dkg0: so. there are multiple types of components [16:37] a) components that use frozen xpcom interfaces only [16:37] b) componetns tuat use frozen and non frozen xpcom interfaces [16:37] c) components that also interface with system libs that are known to be not-yet-abi stable [16:37] are there other corner cases? [16:37] can you explain c more? [16:38] dkg0: yes. so if you build a component that wants to use libsuperhotbutnotabistable [16:38] i mean, if a library ships in debian or ubuntu, it's expected to be abi-stable w.r.t. its current SONAME, right? [16:38] dkg0: doing that would extend the compatilibility issue to things that are beyond xpcom world [16:39] libmozjs would be one of those [16:39] libmozjs is not abi-stable? [16:39] right. there are no guarantees [16:39] in practice it might be stable, but i am currently wrangling with upstream to get a committment [16:39] as we currently cannot support software that uses mozjs [16:40] which is kind of suboptimal at best [16:40] is that why it's libmozjs1d in debian? [16:40] especially since there seems to be a new push for innovation on the desktop based on javascript usag [16:40] e [16:40] so basically you need to treat libmozjs usage like libsuperhotbutnotabistable for now [16:40] "d" meaning "we might need to do an SONAME version bump without upstream's approval" [16:41] only thing that should use that library is xulrunner which ships it as part of the package [16:41] dkg0: well. its kind of easily fixable by using either our own soname; but we can probably convince upstream to use libmozjsX.so [16:41] in debian there is a package libmozjs1d (built by the xulrunner package) [16:41] thats a sure bet [16:42] dkg0: yeah. thats not good [16:42] not only because it breaks upstream compatilibity in some ways [16:42] but also it pretends that we are safe [16:42] and a libmozjs-dev, apparently :( [16:42] technically you can track abi easily and just bump to 1d [16:42] but practically you will be screwed when they change abi for a security fix [16:43] right. that'd be a nightmare transition to try to pull off. [16:43] the decision to make a top level lib out of mozjs without upstream agreeing on backing this, is a wrong one done in debian [16:43] Have you brought this up with Mike Hommey? [16:44] not really this. but i talked to him about other things. i dont think he will back out this [16:44] its also understandable. he did this and even if its bad you cannot just dump that feature in the next relelase [16:44] hrm. right. [16:44] also there are packages that started to use it [16:44] so things become more complicated [16:45] in short, libmozjs is not supported, but it doesnt really matter for our discussion ;) [16:45] ok, fair enough! thanks for the background, though. [16:45] i just took this as an example what i mean with "interface with native libs might cause compatibility issues" [16:45] dkg0: so back to topic compatibility [16:46] dkg0: in general there is no problem if your component is of a) or b) kind ... or even of c) kind (assuming that the lib properly tracks abi) [16:46] dkg0: what happens if its incompatible is that it wont get loaded [16:47] e.g. xpcom interfaces have a uuid. when the interface is changed, the uuid changes and components will fail to load that want the old uuid [16:47] because ldd won't be able to pull in the necessary libs? [16:47] dkg0: for c) thats the case [16:47] for a) b) its the xpcom mechanism [16:48] so for c) ldd guards us ... for a) b) we are guarded by xpcom [16:48] ok, i think i see. [16:48] dkg0: we have to do it right though. for instance when you built a plugin against xulrunner 1.8.0 in debian (the one shipped in etch), you couldnt use the same [16:48] in xulrunner 1.9 [16:48] so if the IPC xpcom extension relies on xulrunner/unstable [16:49] because it was linked in the wrong fashion [16:49] then the xpcom build embeds the UUIDs from the unstable APIs that it's using [16:49] the right way of linking is the xpcom glue [16:49] asac: Thanks for the advice; my build is proceeding better now. I'll keep you posted. [16:49] there is standalone glue (for standalone applications) ... and the dependent glue (for everything that gest loaded into xulrunner) [16:49] dave_m_: great. [16:50] dkg0: but that shouldnt matter much as the mozilla build system should do it right on its own (i would hope ;)) [16:50] dkg0: its just if you use automake you would use pkg-config --cflags --libs libxul(-unstable) for the dependent glue [16:50] and libxul-embedding(-unstable) for the standalone glue [16:50] well, when i built IPC against the xulrunner sources, in pulled in xpcomglue_s.a [16:51] sounds like that was the wrong thing, though? [16:51] dkg0: yes thats correct. luckily mike followed our example in this case and uses the glue now in debian too [16:52] dkg0: it should be ok. check the output of pkg-config --libs libxul-unstable [16:52] checking on my buildd... [16:52] dkg0: so if that uses the right flags it means that the mozilla build system does the right thing for us [16:52] dkg0: i assume with "built IPC against the xulrunner source" you mean "i built IPC by doing a full xulrunner build with ipc included"? [16:53] close; i meant that i build the xulrunner package [16:53] and then unpacked ipc into extensions [16:53] yeah. thats the same [16:53] and followed the ipc build instructions from there. [16:53] thats the "old" in source way ;) [16:54] here's the pkg-config output: [16:54] -L/usr/lib/xulrunner-devel-1.9/lib -lxpcomglue_s -lxul -lxpcom -lplds4 -lplc4 -lnspr4 -lpthread -ldl [16:54] right. thats the good dependent glue [16:54] (that's from a sid installation that was up-to-date yesterday. [16:54] ) [16:54] this will allow you to reuse components build against 1.9 in 1.9.1 and 1.9.2 (of course assuming you dont use incompatible xpcom components) [16:55] even components built against 1.8 with the glue work on 1.9 and above [16:55] ok, that's beginning to make sense to me. [16:55] dkg0: so ... maybe to complete the picture for you: [16:55] two ways to properly do this: [16:55] 1. use automake modern build system -> easy. just use pkg-config -> done. [16:56] 2. use mozilla build system -> cons: not yet available without copying huge parts of xulrunner; pros: properly works everywhere. also on windows. also it doesnt rely on pkg-config files that are only shipped by distro packages, but not part of the xulrunner sdk [16:57] i see. so for the distros, 1 makes sense. [16:57] everywhere else, we probably should document 2. [16:57] dkg0: if you do something that only works on distros yes. [16:57] but usually mozilal extension authors want to be cross platform [16:57] so they use the mozilal build system (like enigmail and ipc and others) [16:57] yeah, understood. [16:58] so we need to make 2. better [16:58] thats what our effort is about. [16:58] we do that for xulapps which face the same problem ;) [16:58] all want to use mozilal build system and all currently need full code copy [16:58] seems like mozilla has re-invented a large part of the wheel here. :( [16:59] i suppose it's necessary to bridge the gap to non-free, non-POSIX systems, though. [16:59] dkg0: yeah. reasons: old -> this predates automake, cross-platform: this makes this stick around; it works on lots of platforms [17:00] yeah. but even posix systems could be old and dont have support for all the good things we would want [17:00] but not sure what those unix things are that are supported (like IRIX) ;) ... i doubt they are posix [17:00] true! (does mozilla run on IRIX?) [17:01] its supported by code. havent heard anything back yet [17:01] but parts of it definitly still take care [17:01] cool. [17:01] for instance NSS [17:01] and nspr [17:01] right, those are important libs. [17:01] yes. NSS has suffered a bit by lack of a openssl compatibility api [17:01] but that changes i think [17:01] i need to start digging around in the NSS source at some point too (but that's a different discussion) [17:01] and once thats achieved they want to take over the world [17:02] i want NSS to be able to support OpenPGP certificates as well as X.509 certificates. [17:03] but that's way off-topic [17:03]