=== Mook_ is now known as Mook
=== davida is now known as davidascher
=== yofel_ is now known as yofel
=== jorge is now known as jcastro
=== BUGabundo1 is now known as BUGabundo
[15:58] <Al_1> kbrosnan: should I repeat the question here?
[16:00] <Al_1> hi, do you guys know if firefox-next ppa https://launchpad.net/~mozillateam/+archive/firefox-next?field.series_filter=maverick is going to be updated soon to the new beta?
[17:51] <Al_1> micahg: hi, is firefox-next ppa https://launchpad.net/~mozillateam/+archive/firefox-next?field.series_filter=maverick going to be updated soon to the new beta? :)
[17:51] <micahg> Al_1: yes, I forget what we're waiting on ATM
[17:51] <micahg> chrisccoulson: ^^
[17:52] <Al_1> ok, thanks micahg :)
[17:53] <micahg> Al_1: I can't wait myself to get the new JS engine :)
[18:51] <Al_1> ;)
[19:53] <fta> jcastro, http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/eaf3923ca175bd34#  may be interesting to follow for someone on our side, please forward
[20:08] <bdrung> micahg, chrisccoulson, asac: we have a problem in natty: bug #674171 - it probably will break all new builds of extensions
[20:08] <ubot2> Launchpad bug 674171 in mozilla-devscripts (Ubuntu) (and 1 other project) "[NATTY] Adblock 1.3.1doesn't load up in FF 3.6.12 (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/674171
[20:15] <micahg> bdrung: I saw that, so is that the bug that question marks are added?
[20:15] <bdrung> micahg: yes
[20:15] <micahg> bdrung: ok, do you want me to try to fix it?
[20:15] <micahg> I can't look at it until the weekend though
[20:17] <chrisccoulson> well, all extensions will stop working next week anyway
[20:17] <chrisccoulson> (once FF4 is in)
[20:17] <micahg> chrisccoulson: no, abp is ready for FF4
[20:17] <chrisccoulson> oh, that's ok then. but, i guess most others will stop working ;)
[20:18] <micahg> chrisccoulson: right :)
[20:18] <micahg> chrisccoulson: I'll try to finish up TB on lucid tonight if I can otherwise by Monday
[20:18] <chrisccoulson> thanks
[20:18] <bdrung> micahg: thanks for the offer. it yours unless i have the time to digg into it before the weekend.
[20:19] <micahg> bdrung: k, np
[20:19]  * micahg guesses subscribing would be a good thing
[20:20] <micahg> bdrung: would this be a 0.25 release to Debian experimental or 0.24.1?
[20:20] <micahg> or just take dch -i's default
[20:21] <chrisccoulson> m'eh, using strings in firefox is so confusing
[20:22] <bdrung> micahg: 0.25
[20:22] <micahg> bdrung: k
[20:25] <asac> chrisccoulson: whats going on with debian ... they dont even have iw 3.6 in unstable/testing?
[20:25] <asac> 3.5.15-1
[20:25] <micahg> asac: no because SeaMonkey can't be built on 1.9.2
[20:25] <asac> is that the version they want to release as stable? thought its already EOL
[20:25] <chrisccoulson> asac - yeah, it's crazy that they're going to release with a browser that's pretty much EOL
[20:25] <asac> what has sm to do with iw ?
[20:26] <asac> i thought they dont use xr as base anymore too
[20:26] <chrisccoulson> we're going to be 2 whole releases ahead of debian within the next week or so ;)
[20:26] <asac> or are they still stuck with that approach ;)
[20:27] <asac> and all because they think the rational  "duplication of code makes security support harder" ;)
[20:28] <micahg> asac: yeah, they want to build ID, IW, and IA all off of one xulrunner
[20:28] <chrisccoulson> i don't think duplication of code makes security support harder in this case, when we still have to deal with the same number of tarballs ;)
[20:28] <asac> id even?
[20:29] <asac> i think i will start calling my id guy again ;)
[20:30] <micahg> asac: here's the thread on debian-devel: http://lists.debian.org/debian-devel/2010/06/msg00535.html
[20:30] <asac> i am not sure i want to read that ;)
[20:31] <asac> " there is not enough hand power to maintain several versions of
[20:31] <asac>   xulrunner in the same suite (especially stable)
[20:31] <asac> "
[20:31] <asac> i remember how i was bashed to use versioned xulrunner source
[20:31] <asac> i mean ... atm, they dont maintain it at all
[20:32] <asac> "Security support
[20:32] <asac> for stable will be easier if there is only one branch to support for the
[20:32] <asac> whole gecko ecosystem.Security support
[20:32] <asac> for stable will be easier if there is only one branch to support for the
[20:32] <asac> whole gecko ecosystem."
[20:32] <micahg> asac: makes some sense, since they won't jump versions, they're stuck backporting patches for only one xul version
[20:34] <asac> right. but thats the problem
[20:34] <asac> if you bump into walls for years and fail constantly its time to take a step back and look for a different route
[20:34] <micahg> asac: indeed, but it's Debian, if you want to bump versions in a stable release, you need to be in volatile
[20:34] <asac> if there is no other path, you have to build one, rather than running against known walls again
[20:34] <micahg> which was actually proposed and shot down on the ML
[20:35] <asac> thats all bull shit. when i started doing security backports for debian they couldnt even do minor version upgrades
[20:35] <asac> i was able to ensure that this can happen by working hard
[20:35] <asac> its really just some egos that dont want to adopt ubuntu approaches ;)
[20:35] <asac> i mean ... even if you cannot security maintain xulrunner, at least do it for iceweasel
[20:35] <asac> and make a standalone package for it
[20:35] <asac> same for icedove ;)
[20:36] <asac> anyway .... me stops now
[20:36] <micahg> asac: they still won't jump minor versions (i.e. lenny has 3.0.6)
[20:36] <asac> yes they do
[20:36] <asac> well ... no clue why that is
[20:36] <asac> but a while back we were able to do minor version bumps
[20:36] <asac> and it was perfectly fine... its just that noone does those uploads i figure
[20:36] <asac> and they hide under some pseudo arguments that are completely untrue ;)
[20:37] <asac> as a matter of fact the debian maintainer just cares about unstable
[20:37] <asac> but well... /me stops ;)
[20:38] <micahg> chrisccoulson: oh, BTW, pyxpcom was FTBFS and I said I'd look into it, are we blacklisting or can we make it work?
[20:53] <chrisccoulson> micahg - we shouldn't take pyxpcom atm, it just won't work with the way we package xulrunner
[20:53] <chrisccoulson> and i don't want to have to update pyxpcom every time we do a firefox update ;)
[20:54] <micahg> chrisccoulson: so blacklist, as unmaintainable for the moment?
[20:56] <chrisccoulson> yeah, that would be best
[20:56] <micahg> chrisccoulson: k, thanks, I'll take care of it
[20:56] <chrisccoulson> thanks
[21:13] <asac> chrisccoulson: whats actually the reason for the plugin-container always looping even though there is no website open?
[21:14] <asac> is that a known bug or just me?
[21:15] <chrisccoulson> asac - hmmmm, is it actually using the CPU?
[21:15] <chrisccoulson> i think it's by design that plugin-container keeps running
[21:16] <asac> chrisccoulson: not sure... i looked at powertop a few times and found that its under top 6 of wakeup reasons all the time ;)
[21:16] <asac> interestingly right now its not doing it
[21:17] <chrisccoulson> asac - along with firefox? ;)
[21:17] <asac> but i am sure it was doing it all day even though no tab was open
[21:17] <asac> chrisccoulson: yeah. firefox is also always there
[21:17] <asac> but plugin-container was more astonishing as there was no plugin active for sure
[21:17] <chrisccoulson> yeah, firefox is pretty bad for wakeups
[21:17] <asac> e.g. just a grey tab
[21:17] <asac> right. i dont know if firefox problem can be fixed ever ;)
[21:18] <chrisccoulson> yeah, i'm not sure either. i'd love to be able to fix it ;)
=== maxb_ is now known as maxb