[00:14] <cwillu> what's the about:config option to allow incompatible extension to install?
[00:15] <cwillu> I'm presuming that the difference between b3 and b4pre isn't really gonna make things worse :p
[00:15] <fta> extensions.checkCompatibility
[00:16] <cwillu> ah, thanks
[00:17] <fta> i would recommend the Nightly Tester Tools addons instead
[00:17] <cwillu> oooo, that sounds like fun.  wazzat?
[00:18] <fta> http://www.oxymoronical.com/web/firefox/nightly
[00:20] <cwillu> looks handy
[00:20] <fta> it's also available at https://addons.mozilla.org/en-US/firefox/addon/6543
[00:35] <fta> Setting up firefox-3.1-gnome-support (3.5~b4~hg20090317r23798+nobinonly-0ubuntu1~umd1) ...
[00:35] <fta> touch: cannot touch `/usr/lib/firefox-3.1*/.autoreg': No such file or directory
[00:36] <fta> boohhh, big rename needed
[01:21] <fta> asac, just upgraded my nc10 from a6 to current, can't connect to wifi anymore
[01:25] <cwillu> 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] <cwillu> s/that a/that have a/
[01:27] <fta> at 2:30am, no thought at all :P
[01:28] <cwillu> :p
[03:28] <cwillu> Is there any place to apply a css rule when printing any document?
[03:59] <cwillu> you know, my firefox session had 57 days of up-time until today :p
[09:01] <asac> cwillu: 57 days up calls for trouble ;)
[09:46] <BUGabundo> fta Firefox daily failing to install http://paste.ubuntu.com/132937/
[10:03] <fta> BUGabundo, i know, i fixed 3.1 yesterday, but i didn't respin the bot yet
[10:24] <BUGabundo> fta ok
[11:03] <asac> fta: http://www.golem.de/0903/65978.html
[11:05] <fta> asac, :)
[11:05] <asac> fta: you understand that?
[11:06] <fta> for the most part yes
[11:06] <asac> fta: it basically gives all the credits for the chromium linux port to you and ubuntu ;)
[11:06] <fta> lol
[11:06] <fta> angenommen?
[11:07] <fta> what does that mean? approved?
[11:07] <asac> fta: "hat sich Fabien Tassin einer Portierung angenommen. " -> that translates to: "fabien tassin took care of the port"
[11:07] <asac> took care
[11:07] <fta> oh
[11:07] <fta> so it's wrong
[11:07] <asac> yeah. but in a good way
[11:08] <asac> so it reads: "because google doesnt provide a linux version of chrome, fabien took this over and ported it to linux" ;)
[11:11] <fta> that part i understood, so just s/ported/packaged/ and that's correct
[11:11] <asac> fta: right ;) ... feel free to complain
[11:11] <asac> or maybe just wait and see if this becomes fully known truth knowledge ;)
[11:11] <BUGabundo> ahahah
[11:12] <BUGabundo> so who was the real guy/gal/team behing the port?
[11:12] <asac> BUGabundo: the chrome linux developers?
[11:12] <fta> yes
[11:12] <asac> google folks
[11:13] <fta> that's mostly google itself, and a bunch of contributors
[11:13] <BUGabundo> so is it packaged now for ubunt and Linux in general?
[11:13] <BUGabundo> also running on 64 bits?
[11:13] <fta> in my ppa, yes, sort of
[11:14] <fta> it's crashy on amd64 because of nss
[11:14] <fta> so https doesn't work for some reason
[11:14] <fta> and my dailies are broken too
[11:14] <fta> https://edge.launchpad.net/~chromium-daily/+archive/ppa?field.name_filter=&field.status_filter=any&field.series_filter=jaunty
[11:15] <fta> no idea why amd64 only btw
[11:19] <fta_> how can i tweak the brightness of this thing, it's too dim during the day, even when set to the maximum
[11:19] <fta_> for some reason, wifi is back (nc10)
[11:20] <asac> fta: is that atheros?
[11:25] <fta_> yes
[11:26] <fta_> i didn't upgrade anything today
[11:27] <fta_> 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] <asac> fta: maybe your AP?
[11:27] <asac> modinfo ath5k?
[11:28] <asac> sigh. i am having pulseaudio issues
[11:28] <asac> will it ever get to a usable state?
[11:28] <asac> dtchen_: are there any fixes in the pipeline still for this cycle?
[11:29] <fta_> there was no wifi at all listed in nm, not even my neighbors
[11:29] <fta_> and in dmesg, there was some strange logs
[11:33] <fta_> like this:
[11:33] <fta_> Mar 18 02:15:03 nano kernel: [   60.506824] ath5k phy0: noise floor calibration failed (2412MHz)
[11:33] <fta_> Mar 18 02:15:03 nano kernel: [   60.833875] ath5k phy0: gain calibration timeout (2457MHz)
[11:33] <fta_> Mar 18 02:15:03 nano kernel: [   60.833888] ath5k phy0: can't reset hardware (-11)
[11:44] <BUGabundo> asac: my NM gets turned of after every hibernate/resume cycle
[11:44] <BUGabundo> its reproduclba with both -10 and -9
[11:46] <asac> BUGabundo: yes. please /usr/lib/pm-utils/sleep.d/55NetworkManager
[11:46] <asac> BUGabundo: and add a --reply to the wake up and sleep dubs-send lines
[11:47] <asac> that will fix it
[11:47] <asac> please verify
[11:51] <BUGabundo> sorry?
[11:51] <BUGabundo> got confused
[11:51] <BUGabundo> multitasking is hard
[11:54] <BUGabundo> 	dbus_send --system                         \		--dest=org.freedesktop.NetworkManager  \		/org/freedesktop/NetworkManager        \		org.freedesktop.NetworkManager.sleep \ --reply
[11:54] <BUGabundo> }
[11:54] <BUGabundo> like this? asac ^^
[11:57] <asac> BUGabundo: not sure
[11:57] <asac> he is gone
[11:57] <asac> i would think you should put the option further before
[11:57] <asac> e.g. before the --system
[12:02] <BUGabundo> asac: not sure? didn't you asked me to add the --reply there?
[12:03] <asac> BUGabundo: yes. but with some human snese ;)
[12:04] <asac> 12:57 < asac> he is gone
[12:04] <asac> 12:57 < asac> i would think you should put the option further before
[12:04] <asac> 12:57 < asac> e.g. before the --system
[12:04] <BUGabundo> http://paste.ubuntu.com/132988/
[12:04] <asac> BUGabundo: adding flags to the end usually doesnt work in unix
[12:04] <asac> there are cases where it does
[12:04] <asac> but if there is a "string" only argument it doesnt
[12:04] <BUGabundo> ah ok. putting higher
[12:04] <asac> BUGabundo: put it in the same block
[12:04] <asac> that other arguments use
[12:04] <asac> BUGabundo: you can run the command on your own to test
[12:05] <asac> BUGabundo: just replace the _ with - in dbus_send
[12:05] <asac> to test on commadn line
[12:05] <BUGabundo> http://paste.ubuntu.com/132990/
[12:05] <BUGabundo> like this?
[12:06] <BUGabundo> $ dbus-send /usr/lib/pm-utils/sleep.d/55NetworkManager
[12:06] <BUGabundo> Usage: dbus-send [--help] [--system | --session | --address=ADDRESS] [--dest=NAME] [--type=TYPE] [--print-reply=(literal)] [--reply-timeout=MSEC] <destination object path> <message name> [contents ...]
[12:07] <BUGabundo> dbus-send --reply --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager  org.freedesktop.NetworkManager.wake
[12:07] <BUGabundo> Usage: dbus-send
[12:07] <BUGabundo> doesn't work either
[12:25] <asac> BUGabundo: thats insane
[12:25] <asac> why would you run the command that way?
[12:25] <asac> oh
[12:25] <asac> ;)
[12:25] <asac> sorry didnt see the last command
[12:25] <asac> BUGabundo: ok its --print-reply ;)
[12:26] <BUGabundo> ah
[12:26] <BUGabundo> nope
[12:26] <BUGabundo> doesn't work
[12:26] <BUGabundo> wait
[12:26] <BUGabundo> typo on my part
[12:26] <asac> BUGabundo: you need to be root i would think
[12:26] <BUGabundo> Error org.freedesktop.NetworkManager.AlreadyAsleepOrAwake: Already awake
[12:26] <asac> BUGabundo: good
[12:26] <BUGabundo> works
[12:26] <asac> so add the --print-reply to the file
[12:26] <BUGabundo> editing file
[12:26] <asac> and then suspend and resume a few times
[12:27] <asac> i think that should fix the issue
[12:27] <BUGabundo> will do during lunch break
[12:27] <asac> BUGabundo: oh ... you might want to append 2>&1 > /dev/null at the end
[12:27] <asac> not sure if pm-utils doesnt like scripts printing stuff
[12:27] <asac> i would think without the /dev/null would work. but i havent tried that
[12:54] <dave_m_> 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] <asac> dave_m_: hard to say for armel
[12:54] <asac> dave_m_: but in x86 it takes about 1.4 G
[12:54] <asac> to link the libxul.so
[12:54] <asac> which should be the memory peak
[12:54] <asac> maybe 1.2G
[12:54] <asac> armel could be less depending on how the binaries are built
[12:55] <dave_m_> 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] <asac> dave_m_: 5G mem or swap?
[12:56] <dave_m_> I should be so lucky :)  512MB ram + 5G swap
[12:56] <asac> yeah. thought that
[12:56] <asac> will definitly be slow slow slow
[12:56] <dave_m_> How much RAM on the Marvell boards?
[12:56] <asac> dave_m_: i think they have 512 too. but i am not really involved in arm port
[12:57] <dave_m_> OK... I think this is probably a hardware issue, not a porting issue anyway.
[12:57] <asac> dave_m_: could be. i just say that building with 512 will take a while ;) ... in theory it should work
[12:57] <dave_m_> Btw, I pulled the latest published source packages, and the config.guess issue on armv7 now seems fixed.
[12:58] <asac> dave_m_: what is "source packages"?
[12:58] <asac> dave_m_: ubuntu?
[12:58] <asac> or firefox-3.2?
[12:58] <dave_m_> Ubuntu, I meant (xulrunner-1.9)
[12:58]  * asac pulls latest moz-central
[12:59] <asac> 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] <dave_m_> I didn't do anything... but the problem objects get built now without me interfering
[13:00] <asac> sounds good. i would think we should still get the upstrea config.* files updated
[13:00] <asac> or get that rolled to hardy/intrepid
[13:00] <dave_m_> Various packages were updated in the meantime, so it may have been resolved by something outside the xulrunner-1.9 package itself...
[13:00] <asac> dave_m_: so the fix happend in jaunty for you?
[13:00] <dave_m_> Yes, seems fine for me (when my hardware works, anyway)
[13:01] <dave_m_> When I have a complete build, I'll let you know if I had any additional problems.
[13:01] <asac> 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] <asac> dave_m_: thanks. much appreciated.
[13:02] <dave_m_> OK
[13:09] <dave_m_>  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] <asac> dave_m_: is it ok to reply here?
[13:09] <dave_m_> argh
[13:09] <asac> ah thanks
[13:09] <asac> dave_m_: problem is that my irc setup is not really made for private chatter ;)
[13:09] <dave_m_> Reposting that remark
[13:09] <dave_m_> 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] <asac> dave_m_: so. yeah. please be careful
[13:10] <asac> dave_m_: dont use --enable-optimization="-O3"
[13:10] <asac> well. at least i would think you should just use --enable-optimization
[13:10] <asac> also for -O3 i am not sure how huge libxul.so linking is ;)
[13:10] <asac> maybe 3G?
[13:10] <asac> my number came from the default mozilla optimization mix
[13:11] <asac> which is -Os in many places
[13:11] <asac> and -O3 in some places (like js engine afaik)
[13:11] <dave_m_> I need to customize, since I'm doing an experimental build with VFP support in arm.
[13:11] <dave_m_> But I'll remove -O3
[13:11] <asac> dave_m_: yes. please do that outside of the configure flags
[13:11] <asac> CFLAGS might be honoured
[13:11] <dave_m_> No
[13:11] <dave_m_> Unfortunately :(
[13:12] <asac> phone
[13:12] <dave_m_> 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] <dave_m_> asac: I have to disappear in a moment, but we can discuss later if need be.
[13:21] <asac> dave_m_: i really think it works. i mean we use that to tweak LDFLAGS. have you tried CXXFLAGS?
[13:21] <asac> dave_m_: otherwise i can check for you
[13:21] <asac> dave_m_: which option do you want to get added for arm?
[13:21] <asac> dave_m_: also what do you get for dpkg-architecture -qDEB_BUILD_ARCH
[13:25] <dave_m_> asac: I thought I tried CXXFLAGS, but I will try it again just in case. It's possible I forgot it.
[13:26] <asac> dave_m_: look at debian/rules
[13:26] <dave_m_> asac: DEB_BUILD_ARCH = armel
[13:26] <asac> we just override CXXFLAGS there
[13:26] <asac> dave_m_: add your flags there ... also for CFLAGS which means mozjs
[13:27] <dave_m_> asac: Assume it works for now, and I'll try again if (when) I have to restart the build.
[13:28] <asac> dave_m_: right. let me know
[13:30] <dave_m_> 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] <dave_m_> 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] <asac> jdstrand: is gutsy EOL? or is that in 5 days ;)?
[14:08] <jdstrand> asac: is it only 5 days? I always treated it as the day before the next release
[14:08] <jdstrand> asac: I suppose it is on a schedule somewhere...
[14:09] <asac> jdstrand: could be. i am out of sync ;)
[14:09] <asac> jdstrand: would make sense if its around the 9.04 release date
[14:09] <asac> only thing i know is that after gutsy its not that long that dapper will RIP
[14:10] <jdstrand> heh
[14:10] <jdstrand> 6.06 ;)
[14:11] <jdstrand> few more months yet :)
[14:11] <asac> jdstrand: yeah. but _after_ gutsy is gone its just a breath ;)
[14:12] <jdstrand> :)
[14:13] <jdstrand> fwiw, gutsy was released on Oct 18th, so I guess Apr 17th?
[14:13] <asac> jdstrand: bug 344746
[14:13] <asac> odd
[14:13] <asac> jdstrand: yeah ;)
[14:14] <asac> some avatars i see on identi.ca make me feel old. this webkit guy looks like 12 years old ;)
[14:14] <asac> hopefully he uses his kids pic
[14:15] <asac> http://identi.ca/stemp
[14:15] <asac> or even 8 years?
[14:15] <jdstrand> asac: that is a weird bug. I did actually test evolution with pop3 and imap tls yesterday...
[14:15] <asac> jdstrand: good. i just asked on the bug because i couldnt test
[14:16] <asac> jdstrand: he claims its NM ... which indeed links against nss
[14:16] <asac> at least the daemon does
[14:16] <asac> but the diff is really just the certificate
[14:16] <asac> not sure how that can break that
[14:16] <jdstrand> yeah
[14:17] <jdstrand> perhaps he didn't restart his session?
[14:30] <asac> jdstrand: lets hope
[14:30] <asac> lets check what he says
[14:33] <asac> jdstrand: hmm. thought it was hardy
[14:33] <asac> but its intrepid
[14:33] <asac> did we do a full upstream bump there or also just the backport?
[14:33] <asac> let me check
[14:34] <asac> seems like its the backport
[14:34] <asac> odd
[14:46] <asac> fta: just installing UNR image i noticed that installer asked you if you want password or auto login
[15:56] <dave_m_> 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] <asac> dave_m_: did you try to add that to rules
[15:59] <asac> dave_m_: or are you not building with packages?
[16:00] <asac> dave_m_: i am not 100% sure. but i can find out what you should do. i am sure for LDFLAGS though
[16:00] <asac> dave_m_: if you tried what i suggested (fix CFLAGS and CXXFLAGS that get overriden in debian/rules)
[16:00] <asac> then i will check
[16:00] <asac> but pleaes confirm that you did that ;)
[16:10] <dave_m_> 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] <asac> dave_m_: arguably a packaging bug.
[16:11] <asac> 14:26 < asac> dave_m_: look at debian/rules
[16:11] <asac> 14:26 < asac> dave_m_: add your flags there ... also for CFLAGS which means mozjs
[16:12] <dave_m_> asac: OK, I have CFLAGS = -g and CXXFLAGS = -g in debian/rules.  Do you recommend I edit here?
[16:14] <dave_m_> asac: ... I will try it (and I'll read your instructions more carefully next time ;)
[16:23] <dkg0> 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] <dkg0> background: http://mozdev.org/pipermail/enigmail/2009-March/010959.html
[16:24] <dkg0> good news is that i think i've got xulrunner-ipc building against xulrunner-dev with only a simple batch of makefiles
[16:25] <dkg0> 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] <asac> dave_m_: yes. for now just edit it there.
[16:30] <dkg0> 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] <asac> dkg0:
[16:31] <asac> hi
[16:31] <asac> ;)
[16:31] <dkg0> hi asac -- thanks for the invitation ;)
[16:31] <asac> dkg0: thanks for showing up.
[16:31]  * dkg0 is still not sure that he's even asking the right questions yet
[16:31] <asac> heh
[16:32] <asac> yeah well. question is: "how to properly build components/extensions/xulapps using xulrunner-sdk"
[16:32] <asac> thats at least my understanding
[16:32] <dkg0> that's at least 3 questions ;)
[16:33] <asac> yeah. but in the end its one solution ;)
[16:33] <dkg0> good!
[16:33] <asac> the real question is "how can we ship mozilla build system as part of xulrunner-sdk"
[16:34] <asac> we should wait for fta to give us an overview of current state
[16:34] <dkg0> that would be a good first-half of a solution.
[16:34] <dkg0> but then there's still the question of "once the things are built, how do you distribute a solitary XPCOM component maintainably?"
[16:34] <asac> second half would be using that for ipc/enigmail/xulapps
[16:35] <asac> dkg0: right.
[16:35] <asac> dkg0: there are multiple options
[16:35] <dkg0> for example, are there SONAME version issues?
[16:35] <asac> a) ship them as an extension
[16:35] <asac> b) ship them as components
[16:35] <dkg0> and what's the difference between xulrunner/stable and xulrunner/unstable
[16:35] <dkg0> (i don't mean lenny vs sid, i mean what i see in the xulrunner-dev package)
[16:35] <asac> dkg0: are you talking about debian in particular here (stable/unstable)?
[16:36] <asac> ah
[16:36] <asac> yeah well thats a different thing and probably becomes irrelevant once we fix the xulrunner sdk
[16:36] <asac> to deliver the pieces for a build system
[16:36] <asac> dkg0: so. there are multiple types of components
[16:37] <asac> a) components that use frozen xpcom interfaces only
[16:37] <asac> b) componetns tuat use frozen and non frozen xpcom interfaces
[16:37] <asac> c) components that also interface with system libs that are known to be not-yet-abi stable
[16:37] <asac> are there other corner cases?
[16:37] <dkg0> can you explain c more?
[16:38] <asac> dkg0: yes. so if you build a component that wants to use libsuperhotbutnotabistable
[16:38] <dkg0> 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] <asac> dkg0: doing that would extend the compatilibility issue to things that are beyond xpcom world
[16:39] <asac> libmozjs would be one of those
[16:39] <dkg0> libmozjs is not abi-stable?
[16:39] <asac> right. there are no guarantees
[16:39] <asac> in practice it might be stable, but i am currently wrangling with upstream to get a committment
[16:39] <asac> as we currently cannot support software that uses mozjs
[16:40] <asac> which is kind of suboptimal at best
[16:40] <dkg0> is that why it's libmozjs1d in debian?
[16:40] <asac> especially since there seems to be a new push for innovation on the desktop based on javascript usag
[16:40] <asac> e
[16:40] <asac> so basically you need to treat libmozjs usage like libsuperhotbutnotabistable for now
[16:40] <dkg0> "d" meaning "we might need to do an SONAME version bump without upstream's approval"
[16:41] <asac> only thing that should use that library is xulrunner which ships it as part of the package
[16:41] <asac> 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] <dkg0> in debian there is a package libmozjs1d (built by the xulrunner package)
[16:41] <asac> thats a sure bet
[16:42] <asac> dkg0: yeah. thats not good
[16:42] <asac> not only because it breaks upstream compatilibity in some ways
[16:42] <asac> but also it pretends that we are safe
[16:42] <dkg0> and a libmozjs-dev, apparently :(
[16:42] <asac> technically you can track abi easily and just bump to 1d
[16:42] <asac> but practically you will be screwed when they change abi for a security fix
[16:43] <dkg0> right.  that'd be a nightmare transition to try to pull off.
[16:43] <asac> 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] <dkg0> Have you brought this up with Mike Hommey?
[16:44] <asac> not really this. but i talked to him about other things. i dont think he will back out this
[16:44] <asac> its also understandable. he did this and even if its bad you cannot just dump that feature in the next relelase
[16:44] <dkg0> hrm.  right.
[16:44] <asac> also there are packages that started to use it
[16:44] <asac> so things become more complicated
[16:45] <asac> in short, libmozjs is not supported, but it doesnt really matter for our discussion ;)
[16:45] <dkg0> ok, fair enough!  thanks for the background, though.
[16:45] <asac> i just took this as an example what i mean with "interface with native libs might cause compatibility issues"
[16:45] <asac> dkg0: so back to topic compatibility
[16:46] <asac> 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] <asac> dkg0: what happens if its incompatible is that it wont get loaded
[16:47] <asac> 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] <dkg0> because ldd won't be able to pull in the necessary libs?
[16:47] <asac> dkg0: for c) thats the case
[16:47] <asac> for a) b) its the xpcom mechanism
[16:48] <asac> so for c) ldd guards us ... for a) b) we are guarded by xpcom
[16:48] <dkg0> ok, i think i see.
[16:48] <asac> 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] <asac> in xulrunner 1.9
[16:48] <dkg0> so if the IPC xpcom extension relies on xulrunner/unstable
[16:49] <asac> because it was linked in the wrong fashion
[16:49] <dkg0> then the xpcom build embeds the UUIDs from the unstable APIs that it's using
[16:49] <asac> the right way of linking is the xpcom glue
[16:49] <dave_m_> asac: Thanks for the advice; my build is proceeding better now. I'll keep you posted.
[16:49] <asac> there is standalone glue (for standalone applications) ... and the dependent glue (for everything that gest loaded into xulrunner)
[16:49] <asac> dave_m_: great.
[16:50] <asac> dkg0: but that shouldnt matter much as the mozilla build system should do it right on its own (i would hope ;))
[16:50] <asac> dkg0: its just if you use automake you would use pkg-config --cflags --libs libxul(-unstable) for the dependent glue
[16:50] <asac> and libxul-embedding(-unstable) for the standalone glue
[16:50] <dkg0> well, when i built IPC against the xulrunner sources, in pulled in xpcomglue_s.a
[16:51] <dkg0> sounds like that was the wrong thing, though?
[16:51] <asac> dkg0: yes thats correct. luckily mike followed our example in this case and uses the glue now in debian too
[16:52] <asac> dkg0: it should be ok. check the output of pkg-config --libs libxul-unstable
[16:52] <dkg0> checking on my buildd...
[16:52] <asac> dkg0: so if that uses the right flags it means that the mozilla build system does the right thing for us
[16:52] <asac> 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] <dkg0> close; i meant that i build the xulrunner package
[16:53] <dkg0> and then unpacked ipc into extensions
[16:53] <asac> yeah. thats the same
[16:53] <dkg0> and followed the ipc build instructions from there.
[16:53] <asac> thats the "old" in source way ;)
[16:54] <dkg0> here's the pkg-config output:
[16:54] <dkg0> -L/usr/lib/xulrunner-devel-1.9/lib -lxpcomglue_s -lxul -lxpcom -lplds4 -lplc4 -lnspr4 -lpthread -ldl
[16:54] <asac> right. thats the good dependent glue
[16:54] <dkg0> (that's from a sid installation that was up-to-date yesterday.
[16:54] <dkg0> )
[16:54] <asac> 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] <asac> even components built against 1.8 with the glue work on 1.9 and above
[16:55] <dkg0> ok, that's beginning to make sense to me.
[16:55] <asac> dkg0: so ... maybe to complete the picture for you:
[16:55] <asac> two ways to properly do this:
[16:55] <asac> 1. use automake modern build system -> easy. just use pkg-config -> done.
[16:56] <asac> 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] <dkg0> i see.  so for the distros, 1 makes sense.
[16:57] <dkg0> everywhere else, we probably should document 2.
[16:57] <asac> dkg0: if you do something that only works on distros yes.
[16:57] <asac> but usually mozilal extension authors want to be cross platform
[16:57] <asac> so they use the mozilal build system (like enigmail and ipc and others)
[16:57] <dkg0> yeah, understood.
[16:58] <asac> so we need to make 2. better
[16:58] <asac> thats what our effort is about.
[16:58] <asac> we do that for xulapps which face the same problem ;)
[16:58] <asac> all want to use mozilal build system and all currently need full code copy
[16:58] <dkg0> seems like mozilla has re-invented a large part of the wheel here. :(
[16:59] <dkg0> i suppose it's necessary to bridge the gap to non-free, non-POSIX systems, though.
[16:59] <asac> dkg0: yeah. reasons: old -> this predates automake, cross-platform: this makes this stick around; it works on lots of platforms
[17:00] <asac> yeah. but even posix systems could be old and dont have support for all the good things we would want
[17:00] <asac> but not sure what those unix things are that are supported (like IRIX) ;) ... i doubt they are posix
[17:00] <dkg0> true!  (does mozilla run on IRIX?)
[17:01] <asac> its supported by code. havent heard anything back yet
[17:01] <asac> but parts of it definitly still take care
[17:01] <dkg0> cool.
[17:01] <asac> for instance NSS
[17:01] <asac> and nspr
[17:01] <dkg0> right, those are important libs.
[17:01] <asac> yes. NSS has suffered a bit by lack of a openssl compatibility api
[17:01] <asac> but that changes i think
[17:01] <dkg0> i need to start digging around in the NSS source at some point too (but that's a different discussion)
[17:01] <asac> and once thats achieved they want to take over the world
[17:02] <dkg0> i want NSS to be able to support OpenPGP certificates as well as X.509 certificates.
[17:03] <dkg0> but that's way off-topic
[17:03] <asac> heh
[17:03] <asac> yeah
[17:03]  * dkg0 gets back on topic
[17:03] <dkg0> ok, so i think what you describe for the build system makes sense.
[17:03] <asac> dkg0: so summary of the above is that the first-half is probably the full solutiuon as the other half is already solved by xpcom and ldd
[17:04] <asac> thats the current understanding we have here and which is mostly shared by some key xulrunner folks i think
[17:04] <dkg0> cool.  I'll reconfigure my build system for the distros to use the pkg-config approach yer describing for now.
[17:04] <dkg0> and i totally support your goal of getting the moz build system into xulrunner-dev
[17:04] <asac> so what we currently do in ubuntu is to ship the xulrunner build system as a tarball in the -dev package
[17:04] <asac> e.g. in the sdk
[17:04] <asac> of course thats not the final solution
[17:05] <dkg0> right.  it'd be better for upstream to package the build system as an integral part of the SDK.
[17:05] <asac> dkg0: thats the plan
[17:05] <dkg0> makes sense to me.
[17:06] <dkg0> is there a buzilla ticket i can +1 for that?
[17:06] <asac> dkg0: but thats ok ... ubuntu ships the sdk
[17:06] <asac> and we want to extend it
[17:06] <asac> /usr/lib/xulrunner-devel-1.9.0.7/
[17:06] <asac> dkg0: so whate we probably want is kind of a .m4 macro
[17:07] <asac> that easily adds the ability of --with-libxul-sdk=/path/to/unpacked/sdk/
[17:07] <asac> at best that should be it
[17:07] <asac> all the magic should happen automatically then ;)
[17:08] <dkg0> assuming that the code you're building can use that path, right?
[17:08] <asac> dkg0: so all mozilla build stuff does this at the top:
[17:08] <asac> DEPTH           = ..
[17:08] <asac> topsrcdir       = @top_srcdir@
[17:08] <asac> srcdir          = @srcdir@
[17:08] <asac> VPATH           = @srcdir@
[17:08] <asac> include $(DEPTH)/config/autoconf.mk
[17:09] <dkg0> right.  that looks familiar.
[17:09] <asac> i would think that the m4 should take care that this is created during configure
[17:09] <asac> maybe configure should copy the build system from the sdk actually
[17:09] <dkg0> DEPTH seems to assume that you're already in the build tree.
[17:09] <asac> at best that wouldnt be needed
[17:09] <dkg0> otherwise it would be "SDK_BUILD_PATH" or something
[17:09] <asac> dkg0: yes. but thats how the extension trees are always layed out
[17:10] <asac> we have to workaround or make use of that fact for us
[17:10] <dkg0> if the sdk build mechanism is distributed in a package, then normal users won't be able to build within that tree, right?
[17:11] <asac> dkg0: yes.
[17:11] <asac> we have to check how many variables need to be replaced
[17:11] <dkg0> that's what you mean by "copy the build system from the sdk", right?
[17:11] <asac> i expect that a bunch of them should be predefined by sdk anyway
[17:11] <asac> dkg0: yeah. ./configure -> creates the build/ tree for instance
[17:11] <asac> dkg0: would be a simple solution
[17:12] <asac> i hope that at some point we can workaround that by magic
[17:13] <dkg0> without the magic, it sounds like it could lead to a repeat of the config.guess and config.sub mess.
[17:13] <asac> dkg0: in which sense?
[17:14] <dkg0> just that for packagers using autotools, when upstream ships config.guess and config.sub
[17:14] <dkg0> there always seems to be confusion over whether to use those bits from the local system
[17:14] <dkg0> or use the bits from upstream
[17:14] <dkg0> and if you make changes, do you include them in the diff.gz, etc.
[17:15] <dkg0> i suppose upstream XPCOM authors aren't in the habit of shipping the build tree in their tarballs at the moment, though.
[17:15] <asac> dkg0: upstream wouldnt ship config.guess imo
[17:16] <asac> upstream would just ship configure.in
[17:16] <asac> and maybe the macro
[17:16] <asac> but even that should be shipped in sdk
[17:16] <asac> make distclean should remove the build system
[17:16] <dkg0> that makes some sense.  i confess that my head swims when i get into the complexities of autotools :(
[17:17] <asac> heh
[17:17] <asac> take your time ;)
[17:17] <asac> if you just started to think about this build system thing you should now go back
[17:17] <asac> and read a bit of the build system
[17:17] <dkg0> d'you have any pointers of where to start?
[17:18] <asac> e.g. start with config/config.mk config/rules.mk
[17:18] <asac> dkg0: those two have allmost all the magic
[17:18] <asac> dkg0: e.g. look at  a directory that ships some components
[17:18] <asac> see what variables are defined in the Makefile there
[17:18] <asac> then check what it does in the rules/config.mk
[17:19] <dkg0> ok, thanks.  i'll do some reading.
[17:20] <asac> dkg0: look at toolkit/system/gnome/Makefile.in on trunk
[17:20] <asac> thats a shared component
[17:21] <asac> what is probably what we would target for components/extensions
[17:21] <dkg0> still has DEPTH = ../../..
[17:21] <asac> dkg0: yes. DEPTH will always be there
[17:21] <asac> dkg0: just assume that its always right ... e.g. it will always point to our top_srcdi
[17:21] <asac> r
[17:22] <dkg0> even if it doesn't, because we're not in an actual build tree?
[17:22] <asac> dkg0: dont be bothered about how the solution will look like ;) ... for now understand a bit how the build system does what
[17:22] <asac> i mean: we dont even know how the solution will look like
[17:23] <asac> maybe we will require that build trees have the right layout for DEPTH
[17:23] <asac> maybe we will workaround ;)
[17:23] <asac> maybe we have to fix rules.mk to be smarter
[17:23] <asac> and ignore DEPTH ;)
[17:23] <dkg0> right, OK.
[17:24] <asac> dkg0: when fta is back he will probably be able to give us a bug or too
[17:24] <asac> most likely not about the complete thing
[17:24] <asac> rather for sub problems ;)
[17:24] <dkg0> So i've got some reading to do there, but i feel like i have a much better handle on how and why the build should go how it goes than i did before.
[17:24] <asac> ;)
[17:24] <asac> dkg0: thats good
[17:25] <dkg0> thanks for explaining.  i'd like to do some of this work before the Right Fix gets put in place
[17:25] <asac> its a bit of hard task. so please dont expect a solution within a few days ... just dont drop the ball on that ;) ... ohterwise i would have talked a lot for nothing ;)
[17:25] <dkg0> because right now firegpg at least really needs an update in sid.
[17:25] <dkg0> i don't expect a solution immediately!  i know how much work and time these things take.
[17:25] <asac> dkg0: oh. firgpg .. we have that in ubuntu fixed already
[17:26] <asac> or do yoiu mean the new ipc thing?
[17:26] <dkg0> if it was just a technical fix it'd be easier, but it sounds like this involves a technical fix plus some social/political consensus building.
[17:26] <dkg0> asac: yeah, i mean the ipc thing.
[17:26] <dkg0> because i'd like to see the ipc module available independently as an XPCOM component.
[17:26] <asac> dkg0: the idea is to just get the right approach into xulrunner and make it as easy as possible for most users to adapt it
[17:26] <asac> i think we can do it in a way that will only require minimal adjustments
[17:27] <asac> to current best practice
[17:27] <asac> at least that should be our goal
[17:27] <asac> https://code.edge.launchpad.net/~ubuntu-dev/firefox-extensions/firegpg.ubuntu
[17:27] <asac> dkg0: i would think that this works for you too
[17:27] <asac> might need mozilla-devscripts from ubuntu
[17:28] <asac> but yeah. i know that you want to build ipc now in a separate package
[17:29] <asac> ok back to my job ;)
[17:29] <asac> but first "killall pulseaudio" ... what a mess
[17:29] <dkg0> if you think that ipc in a separate package isn't the way to go, i'd like to hear that.
[17:29] <dkg0> seems to me like it would be useful to have it more easily available, though.
[17:30] <asac> dkg0: i think its ok in general. however, i think its more important to fix the harder build system issue ;)
[17:30] <dkg0> right, i can see why that's important.
[17:30] <asac> you can probably do a hand made build system easily for ipc
[17:31] <asac> but for enigmail and some other stuff its really inefficient
[17:31] <fta2> asac, pulse from the ppa is quite nice for me now. I no longer have to kill it, or restart it after infamous asserts, it no longer has clicks, stuttering, jumps, cracks, etc..
[17:31] <dkg0> yeah, if we want to encourage general xpcom compnent development within the distros, the build system should be there.
[17:31] <asac> fta2: for me pulseaudio is a turbo boost ;)
[17:31] <asac> everything will play 100 times as fast ;)
[17:32] <asac> dkg0: right. its not even in the distros ... its of greater good for the general xulrunner ecosystem
[17:32] <dkg0> yup.
[17:32] <asac> dkg0: we should also come up with a "project" skeleton creator
[17:32] <asac> that directly copies proper LICENSE in the directory ;)
[17:32] <asac> like autoproject
[17:32] <dkg0> that'd be nice.
[17:32] <asac> there are so many mozilla folks out that dont care about licensing that suggesting them something might help ;)
[17:33] <dkg0> so if such a thing was created, and the build system was in place, and lots of people were using it to create these things...
[17:33] <asac> hopefully it improves
[17:33] <asac> also it should include the LICENSE in produced xpis ;)
[17:33] <dkg0> how would you go about shipping an standalone XPCOM component in debian or ubuntu?
[17:33] <asac> those are usually shipped without license
[17:33] <asac> dkg0: depends
[17:34] <dkg0> yes, agreed!  poorly-licensed code drives me nuts (because i want to use it and i want to respect the author's wishes, and i don't want to have to hassle the author about it)
[17:34] <asac> dkg0: usually you put such stuff into $XULDIR/distribution/$projectname/
[17:34] <asac> but we dont ship hooks for that in neither ubuntu nor debian
[17:34] <asac> dkg0: right. i also have a bug open for AMO to require license files in the .xpi
[17:34] <asac> seems they will adapt that at some point
[17:34] <asac> not sure how long it can take
[17:35] <asac> i will poke someone i guess ;)
[17:37] <dkg0> asac: i'm not seeing any $XULDIR/distribution/$projectname anywhere.
[17:37] <dkg0> what do you mean by $XULDIR?
[17:37] <dkg0> XULDIR=/usr/lib/xulrunner-1.9 ?
[17:47] <asac> dkg0: yes
[17:47] <asac> GRE_DIR ;)
[17:47] <asac> like in /etc/gre.d/*.conf
[17:48] <asac> dkg0: as i said.
[17:48] <asac> 18:34 < asac> but we dont ship hooks for that in neither ubuntu nor debian
[17:48] <asac> but if you create the directories it should work
[17:48] <asac> give it a try ;)
[17:51] <dkg0> ok, will do.
[17:52] <dkg0> thanks for your help with this, asac.
[17:52] <dkg0> i'm sure i'll have more questions later ;)
[17:53] <asac> dkg0: so its like: distribution/bundles/MYBUNDLE/components/
[17:53] <asac> or distribution/bundles/MYBUNDLE/chrome
[17:53] <dkg0> ok, thanks.  where is that documented?
[17:53] <asac> but in general i think making an extension out of it is better
[17:54] <asac> just use targetapplication toolkit@mozilla.org
[17:54] <asac> that means: this is a "xulrunner" extension
[17:54] <asac> dkg0: not sure where the bundles are documented
[17:54] <dkg0> ah, i see: make it a generic extension so that it can target any xulrunner app?
[17:55] <asac> yeah
[17:55] <asac> you can even hide it from addons dialog if you want
[17:55] <asac> but i think its ok to have IPC there
[17:55] <dkg0> and then can extensions depend on other extensions?
[17:55] <asac> we use the same for xulrunner translations in ubuntu
[17:55] <asac> dkg0: thats definitly planned. maybe you can already do some simple depends
[17:56] <asac> so current solution is usually to ship a meta extension
[17:56] <asac> but imo even if thats not there is not worse than distributing the components by hand
[17:56] <asac> we have "distro package" distribution -> thats good
[17:56] <asac> "xpi distribution" -> maybe can be improved, but we are not worse off
[17:57] <asac> dkg0: https://wiki.mozilla.org/Extension_Manager:Extension_Dependencies
[17:57] <asac> mozilla bug 298497
[17:57] <asac> dkg0: so seems to be fixed
[17:58] <asac> not sure where
[17:58] <asac> fixed even in 1.8
[18:01] <dkg0> hrm.  ok, even more for me to read ;)
[18:02] <dkg0> btw, i've been logging this chat so i can refer to it later in my own work.
[18:02] <dkg0> are you ok if i publish it (in whole or in part)?
[18:02] <asac> dkg0: just give me a ping before so i can proof read ;)
[18:02] <dkg0> i have no plans to do so, but it might be handy to share it if other people are doing the same thing.
[18:03] <asac> dkg0: we should discuss stuff in mozilla bugs imo
[18:03] <asac> i mean the technical facts and the options and reasions and so on
[18:03] <dkg0> yeah, having the requests filed where upstream can see them is good.
[18:42] <asac> fta: last call
[19:05] <asac> fta: let me know how fontconfig_2.6.0-1ubuntu10_source.changes goes for you (uploaded)
[19:16] <fta> asac, what am i supposed to check?
[19:17] <asac> fta: if all is good in firefox using the default /etc/fonts/ directory
[19:17] <asac> as shipped by fontconfig-config
[19:24] <fta> i'm running 2.6.0-1ubuntu9, i looks identical to me. but a long time ago, i manually removed some files
[19:24] <fta> it
[19:28] <asac> fta: yes. please check after ubuntu10 comes
[19:28] <asac> and paste your ls /etc/fonts/conf.d then
[19:29] <asac> so i can see if you have everything thats in the package ... or more
[19:29] <asac> fta: do you have ~/.fonts.conf ?
[19:29] <fta> ok
[19:29] <asac> great
[19:29] <asac> fta: do you run firefox with "allow sites to select fonts" (default) or have you turned that off?
[19:29] <fta> i have one
[19:30] <fta> asac, http://paste.ubuntu.com/133177/
[19:38] <asac> fta: dump that
[19:39] <asac> autohint is bad for you ;)
[19:39] <asac> i would think ;)
[19:39] <asac> fta: maybe you even have /etc/fonts/conf.d/10-autohint.conf?
[19:39] <asac> dump that too then
[19:39] <asac> also give me dpkg --query fontconfig-config ;)
[19:40] <asac> err
[19:40] <asac> --status
[19:40] <asac> thanks!
[19:43] <fta> asac, http://paste.ubuntu.com/133183/
[19:43] <fta> that's still u9, not u10
[19:43] <fta> http://paste.ubuntu.com/133184/
[19:44] <asac> fta: so md5sum of /etc/fonts/conf.d/unhinted.conf is different for you?
[19:45] <asac> fta: are you really sure you have fontconfig-config ubuntu9?
[19:53] <fta> fta@ix:~ $ dpkg -l | grep fontconfig-config
[19:53] <fta> ii  fontconfig-config                                       2.6.0-1ubuntu9                                        generic font configuration library - configu
[20:01] <fta> asac, i read you installed UNR too, do you like it?
[20:01] <asac> fta: i already had it before. just the hardy version
[20:01] <asac> havent looked closer yet
[20:02] <asac> just wanted to check something with fonts and dpi ;)
[20:02] <asac> fta: its a bit odd. the ubuntu9 postinst was supposed to remove a bunch of those files
[20:03] <asac> fta:  /etc/fonts/conf.d/sub-pixel.conf does that file still exist?
[20:03] <asac> or even this: /etc/fonts/conf.d/yes-bitmaps.conf ?
[20:03] <fta> yes
[20:04] <fta> if it's the same as postinst in xul, it's always one upgrade late
[20:04] <asac> hmm
[20:04] <asac> my defaults thing didnt really work
[20:04] <asac> relogging in
[20:05] <fta> if you have a conf file in v1, remove it in v2, postint will only drop it in v3
[20:09] <asac> fta: thought so. i should have used preinst
[20:09] <asac> fta: just wonder if you have those files or not
[20:09] <asac> if not all is fine for the time being
[20:09] <asac> i will think about moving it to preinst ;)
 asac, http://paste.ubuntu.com/133183/
[20:21] <asac> fta: so why do you still have /etc/fonts/conf.d/no-sub-pixel.conf
[20:21] <asac> thats a mystery
[20:21] <asac> /etc/fonts/conf.d/no-bitmaps.conf
[20:21] <asac> also
[20:21] <asac> hmm
[20:22] <asac> fta: wtf is /etc/fonts/conf.d/CJK_aliases
[20:22] <asac> ?
[20:25] <fta> fta@ix:~ $ dpkg -S  /etc/fonts/conf.d/CJK_aliases
[20:25] <fta> language-selector-common: /etc/fonts/conf.d/CJK_aliases
[20:49] <asac> fta: ok
[20:49] <asac> fta: seems you have slected CJK fonts then
[20:49] <asac> thats ok
[20:50] <asac> fta: can you please ponder the postinst and see why the hell all those files i wanted to remove didnt get remove for you?
[20:50] <asac> of fontconfig?
[20:50] <asac> all those without number (except the CJK_...) where supposed to get deleted in u8/9
[20:52] <asac> fta: lp332992_ancient_conf_leftover="autohint.conf no-bitmaps.conf no-sub-pixel.conf sub-pixel.conf unhinted.conf yes-bitmaps.conf"
[20:52] <asac> those at least
[20:52] <asac> maybew we need to add more in u11
[20:53] <asac> lets please find that out because we want the right fixes in beta
[20:53] <asac> just a few hours for u11
[20:54] <asac> fta: dam. i see the bug ;)
[20:54] <asac> ok
[20:54] <asac> i am on it
[20:57] <fta> cool
[20:57] <fta> gasp, http://paste.ubuntu.com/133215/  i hate ia32-libs
[20:59] <asac> fta: can you get ubuntu10
[20:59] <asac> and apply a patch
[20:59] <asac> and then check that installing fontconfig-config that comes out of that
[20:59] <asac> removes all those files from above for you?
[20:59] <asac> thanks!
[20:59] <asac> actually i can do that on my own i think
[20:59] <asac> thanks
[21:00] <asac> http://paste.ubuntu.com/133217/
[21:00] <asac> would be the patch
[21:03] <asac> urgh ... time is running low ;)
[21:03] <asac> 3h
[21:08] <fta> universe too?
[21:09] <asac> fta: hmm seems its not testable if its not a conffile
[21:09] <asac> fta: can you spin fontconfig with http://paste.ubuntu.com/133224/
[21:09] <asac> fta: its just a 1 minute build
[21:09] <asac> fta: dpkg -i fontconfig-config*deb
[21:15] <fta> from 2.6.0-1ubuntu9?
[21:15] <asac> fta: no u10
[21:15] <asac> as a start
[21:15] <asac> and the patch it with that
[21:16] <fta> i still don't see it
[21:16] <asac> fta: wget https://edge.launchpad.net/ubuntu/jaunty/+source/fontconfig/2.6.0-1ubuntu10/+files/fontconfig_2.6.0.orig.tar.gz https://edge.launchpad.net/ubuntu/jaunty/+source/fontconfig/2.6.0-1ubuntu10/+files/fontconfig_2.6.0-1ubuntu10.diff.gz https://edge.launchpad.net/ubuntu/jaunty/+source/fontconfig/2.6.0-1ubuntu10/+files/fontconfig_2.6.0-1ubuntu10.dsc
[21:16] <fta> just updated my chroot, it's u9
[21:16] <fta> cool, a dsc
[21:16] <asac> yeah ;)
[21:16] <asac> its just a second old
[21:20] <fta> building
[21:21] <fta> i have to update ia32lib now :P
[21:21] <asac> fta: please do that after testing fontconfig-config ;)
[21:21] <fta> i was supposed to bump ff3.1 too
[21:22] <fta> and fix the dailies
[21:22] <fta> gasp
[21:22] <asac> heh
[21:22] <asac> dailies are ok to fail for a few days imo ;)
[21:22] <asac> we are a small team after all
[21:22] <asac> ;)
[21:23] <fta> they broke the upgrade
[21:23] <fta> Setting up firefox-3.1-gnome-support (3.5~b4~hg20090317r23798+nobinonly-0ubuntu1~umd1) ...
[21:23] <fta> touch: cannot touch `/usr/lib/firefox-3.1*/.autoreg': No such file or directory
[21:23] <fta> dpkg: error processing firefox-3.1-gnome-support (--configure):
[21:23] <fta>  subprocess post-installation script returned error exit status 1
[21:23] <fta> i fixed this one already
[21:24] <fta> asac, nada
[21:24] <fta> # dpkg -i fontconfig-config*deb
[21:24] <fta> (Reading database ... 283810 files and directories currently installed.)
[21:24] <fta> Preparing to replace fontconfig-config 2.6.0-1ubuntu9 (using fontconfig-config_2.6.0-1ubuntu11_all.deb) ...
[21:24] <fta> Unpacking replacement fontconfig-config ...
[21:24] <fta> Setting up fontconfig-config (2.6.0-1ubuntu11) ...
[21:24] <fta> Installing new version of config file /etc/fonts/conf.avail/30-metric-aliases.conf ...
[21:24] <fta> Installing new version of config file /etc/fonts/conf.avail/30-urw-aliases.conf ...
[21:24] <fta> Processing triggers for man-db ...
[21:26] <fta> but i assume that's the 1 step late issue
[21:27] <fta> asac, ff3.2 regressed, it looks ugly now
[21:29] <asac> fta: are the files still there?
[21:29] <asac> you wouldnt see that on console
[21:31] <asac> fta: so ... no-sub-pixel.conf still in conf.d?
[21:32] <asac> fta: so as its ugly now ... i assume the files got finally removed ;)
[21:32] <asac> fta: you have a screen on what is ugly?
[21:32] <fta> http://paste.ubuntu.com/133243/
[21:32] <asac> thats crazy
[21:32] <asac> so one cannot remove stuff with rm_conffile in postinst or what?
[21:35] <fta> asac, http://www.sofaraway.org/ubuntu/tmp/ugly-ff3.2.png
[21:36] <asac> fta: thats the hinting level i guess
[21:36] <asac> fta: but well. with all those files not removed it could be anything
[21:39] <fta> so?
[21:52] <asac> fta: i am unsure. maybe trying to move that stuff to preinst is relaly the right thing here
[21:53] <fta> i assume that if i dowgrade, it will clean-up as expected
[21:57] <dtchen> asac: fixes for what?
[21:58] <dtchen> asac: if you mean PA - yes, there are some queued in bzr; i just need to tweak and merge, then push. if you mean linux - yes, i'm just now cloning to push to kernel.u.c
[21:59] <asac> dtchen: cool. so its yes, yes. thats the best possible answer for me ;)
[21:59] <asac> fta: it will cleanup as expected?
[21:59] <asac> in postinst?
[21:59] <asac> fta: i move stuff to preinst now
[21:59] <asac> fta: are those files visible as conffiles in dpkg-query ?
[22:00] <asac> fta: can you check that? otherwise i need to code a fallback if they are not found
[22:00] <fta> http://paste.ubuntu.com/133256/
[22:02] <asac> fta: http://paste.ubuntu.com/133258/
[22:02] <asac> fta: thats in preinst now
[22:03] <fta> please give me a file, not a paste
[22:03] <fta> oh, nm, plain text
[22:03] <asac> fta: sorry.
[22:03] <asac> revert all that
[22:05] <fta> ?
[22:05] <asac> fta: so the previous was a typo :(
[22:05] <asac> see -> -desktop ;)
[22:05] <asac> lp332992_acient_conf_leftover
[22:06] <asac> http://paste.ubuntu.com/133261/
[22:06] <asac> thats the patch that must work (plzzzz)
[22:07] <asac> me tests with his "not registered conffile"
[22:11] <fta> building
[22:11] <fta> i called it -12
[22:15] <fta> # dpkg -i fontconfig-config*deb
[22:15] <fta> (Reading database ... 283811 files and directories currently installed.)
[22:15] <fta> Preparing to replace fontconfig-config 2.6.0-1ubuntu11 (using fontconfig-config_2.6.0-1ubuntu12_all.deb) ...
[22:15] <fta> Unpacking replacement fontconfig-config ...
[22:15] <fta> Setting up fontconfig-config (2.6.0-1ubuntu12) ...
[22:15] <fta> Processing triggers for man-db ...
[22:15] <fta> asac, ^^ nada
[22:23] <asac> fta: why do you post the install log?
[22:24] <fta> it's not supposed to print what it removes?
[22:24] <asac> fta: no. thats what i am saying all the time ;)
[22:24] <fta> lol; ok
[22:25] <fta> i still have a bunch of obsolete
[22:25] <asac> fta: thats ok
[22:25] <asac> fta: i am only interested in the files in the ancient list
[22:25] <asac> have they been removed or renamed for you?
[22:25] <fta> http://paste.ubuntu.com/133273/
[22:26] <asac> fta: thast amazing
[22:26] <asac> i mean i created the no-sub-pixel.conf
[22:26] <asac> manually and it got renamed
[22:27] <asac> fta: maybe you did a typo in your typo fix?
[22:27] <fta> applied you stuff as a patch
[22:30] <asac> fta: well. problem for you almost certainly was that you didnt downgrade first
[22:30] <fta> asac, is universe frozing too?
[22:30] <asac> fta: so your version was higher
[22:30] <asac> fta: i think its semi frozen
[22:30] <asac> technically nothing will go in automatically, but RMs will just approve them in batches without looking at changes
[22:30] <fta> oh,ok
[22:30] <asac> fta: but better check with motu-relesae ;)
[22:30] <asac> who knows what they invented this time
[22:31] <asac> i am just sure that RMs will not look on their own
[22:31] <asac> ok lets hope that was it for fontconfig
[22:31] <asac> otherwise i have to fix that post-beta ;)
[22:32] <fta> slangasek told me to update ia32-libs myself as-i-was-a-motu-after-all
[22:32] <asac> fta: thats what i am telling you all the time ;)
[22:32] <asac> diy ;)
[22:33] <asac> ok i have to run out before the shop closes next to my entrance
[22:33] <asac> then i have 1h left ;)
[22:33] <asac> till 0:00 UTC
[22:33] <asac> @time
[22:33] <asac> @now
[22:33] <asac> ubottu: catch up
[22:33] <asac> ubottu: time?
[22:33] <fta> but i'm stuck because of isdnutils (in main)
[22:33] <asac> fta: why?
[22:33] <asac> fta: you want to maintain that?
[22:33] <asac> fta: we just decided to that to universe
[22:34] <asac> at least i thought that was consent
[22:34] <fta> https://edge.launchpad.net/ubuntu/jaunty/+source/isdnutils/1:3.12.20071127-0ubuntu4
[22:34] <fta> last failed
[22:34] <asac> if you have reason to believe that we need that in main, let me know
[22:34] <fta> so the script fetching both srcs & bins fails
[22:34] <asac> fta: do you use isdn?
[22:34] <fta> no idea what it is used for
[22:35] <fta> i'm updating ia32-libs as a whole, something in there needs it
[22:35] <asac> fta: urgh
[22:35] <asac> fta: see if we can dump it
[22:35] <asac> its kind of drop from archive candidate
[22:35] <fta> it's not directly listed unfortunately
[22:36] <fta>  isdnutils | 1:3.12.20071127-0ubuntu3 | http://archive.ubuntu.com jaunty/universe Packages
[22:36] <fta>  isdnutils | 1:3.12.20071127-0ubuntu4 | http://archive.ubuntu.com jaunty/main Sources
[22:36] <asac> nyway ... out for 10 minutes or so
[22:36] <fta> seems it moved from universe to main
[22:38] <asac> but when was ubuntu4 ;)
[22:39] <fta> https://edge.launchpad.net/ubuntu/jaunty/+source/isdnutils/1:3.12.20071127-0ubuntu4
[22:39] <fta>  2009-03-05
[22:43] <fta> asac, it's needed for libcapi20-3
[22:44] <fta> apparently for wine
[22:54] <asac> fta: what wine package pulls that in?
[22:54] <asac> i dont see it on rdepends here
[22:54] <fta> debian bug 479662
[22:57] <fta> damn, xorg too
[22:57] <fta> oh, it's building
[22:57] <fta> so we're supposed to update the ia32 package only when the archive is stable, without errors
[22:58] <fta> gasp
[23:07] <fta> asac, it seems our way to use dh_install/dh_links is wrong
[23:08] <asac_> 23:57 < fta> so we're supposed to update the ia32 package only when the archive is stable, without errors
[23:08] <asac_> 23:58 < fta> gasp
[23:08] <asac_> Day changed to 19 Mar 2009
[23:08] <asac_> 00:07 < asac> why do you think?
 gasp
 asac, it seems our way to use dh_install/dh_links is wrong
[23:10] <fta> damned xchat; it doesn't copy time stamps
[23:10] <asac_> fta: in which sense?
[23:10] <asac_> i mean it cant be completely wrong ;)
[23:11] <fta> it's suboptimal at best
[23:11] <asac_> define the problems we see
[23:11] <fta> we use a lot of dh_install -pfoo bar baz
[23:12] <fta> when we do that, dh_ install bar as baz but also installs everything from the corresponding *.install file
[23:12] <fta> so we do that over and over again, slowing the build for nothing
[23:13] <asac_> do we actually still have anything in the .install files?
[23:14] <fta> i think so
[23:14] <fta> ok, so xorg is ok, it seems i just need isdnutils to be fixed
[23:16] <fta> asac, could you do something about that? pleaaaaase?
[23:19] <fta> asac_, ^^
[23:19] <fta> asac_, even worse when we call dh_install without -p, it's re-installing *all* files for all packages
[23:22] <asac_> asac_: about what?
[23:23] <asac_> we should definitly use -p for dh_install i agree
[23:23] <asac_> if we dont do that properly
[23:23] <asac_> fta: actually without -p it always uses the first binary package in control
[23:23] <asac_> to run it for all you use -a
[23:23] <fta> nope
[23:24] <fta> it runs the 1st for the files listed on the command line, but it runs *all* install files
[23:25] <fta> i just got that in xul 1.2
[23:25] <fta> 9
[23:26] <asac> sounds a bit like a bug. but probably unfixable without breaking parts of archive
[23:27] <dkg0> asac_: thanks for your help today.  Really useful!  i just noticed that the versions of firegpg in ubuntu have known problems as well, so i filed a bug for that:
[23:27] <dkg0> https://bugs.launchpad.net/ubuntu/+source/iceweasel-firegpg/+bug/345141
[23:28] <asac> dkg0: yeah. i should get the bzr branch up i guess
[23:28] <asac> dkg0: are you doing that in debian?
[23:29] <asac> can you please drop the iceweasel- prefix?
[23:29] <asac> using the app target name was never a good idea ;)
[23:29] <dkg0> i'm not responsible for it in debian (just doing triage that got into a pretty wide-ranging digression), but yeah, i'll suggest that in my report.
[23:30] <asac> dkg0: are you doing this in some kind of official context or so?
[23:30] <dkg0> asac: fwict, the version in the bzr branch is out-of-date, too.
[23:30] <dkg0> asac: i'm going through NM
[23:30] <dkg0> and this is one of the bugs that i chose to work on to complete the NM process.
[23:30] <asac> ah ;)
[23:30] <dkg0> (you have to fix 1 RC bug and 2 important-or-higher bugs these days)
[23:30] <asac> ok
[23:31] <dkg0> bit of hoop-jumping, but i actually care about these bugs, so i'm nappy to try to get them sorted out.
[23:31] <asac> dkg0: you could help on a security update round ;)
[23:31] <asac> that should give you plenty of RC bugs ;)
[23:31] <asac> not in unstable though
[23:31] <asac> rather stable update
[23:31] <asac> but well ;)
[23:32] <asac> fta: do we need ozilla-devscript in for beta?
[23:32] <dkg0> i really want to see OpenPGP-based tools become functional and usable and sane.
[23:32] <dkg0> we're a ways off from that goal :(
[23:32] <asac> fta: i dont have the fix at hand. just tried for a few minutes
[23:32] <asac> fta: its a bit odd though. maybe its hte EM_ID not getting properly parsed or something
[23:32] <asac> maybe the XPI_FILE doesnt support directory names could be the issue too
[23:32] <fta> for what? prism?
[23:32] <asac> yeah
[23:33] <asac> i mean: if there is a fix required on moz client it wont make beta
[23:33] <asac> question is if we want current state in beta
[23:33] <fta> mozclient is fine
[23:33] <asac> fta: i use it as a synonym for the full package
[23:34] <fta> for xpi, i don't know, it's your stuff
[23:34] <asac> fta: i want to know whether there are important enough changes in current head that i need to upload or not ;)
[23:34] <asac> its just python2.4
[23:34] <asac> shouldnt be important
[23:35] <fta> i have nothing else
[23:35] <asac> ok. lets do the upload after beta then