[00:00] <asac> bug 427295
[00:00] <asac> micahg: ^^
[00:00] <asac> ;)
[00:00] <asac> gnomefreak: ^^1
[00:00] <micahg> ah
[00:00] <micahg> yes
[00:00] <asac> gnomefreak: is that the bug you are seeing?
[00:00] <asac> are you seeing it atm?
[00:02] <asac> ok guess thats the final bug i will be focussing on after all is done ;)
[00:03] <gnomefreak> 'aslooking but sounds like it
[00:03] <asac> just have to find the profile with which i could reproduce that issue
[00:09] <thunderstruck> 3.6~b2~hg20091016r32516+nobinonly-0ubuntu1~umd1  <<< bot problem? fta asac
[00:10] <asac> why?
[00:10] <asac> thats a firefox ~b2 build
[00:10] <thunderstruck> hg20091016
[00:10] <asac> i think we have breakage
[00:11] <asac> micahg provided a branch and most likely i failed to apply it :/
[00:11] <asac> is that the story?
[00:11] <fta>   - thunderbird-3.0 (3.0~hg20091017r4190+nobinonly -> 3.0~hg20091019r4193+nobinonly) [60.10MB (+0kB, +0.00%)]
[00:11] <micahg> I think so
[00:11] <fta> today
[00:12] <micahg> yep, that should be fixed in the proposed merge
[00:12] <fta> looks fine to me: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+packages?field.name_filter=thund&field.status_filter=&field.series_filter=karmic
[00:12] <fta> lol, 3.6, not tb3, n-m
[00:12] <asac> yeah
[00:13] <fta> too late for me, i seriously need some sleep
[00:13] <asac> fta: gooooo
[00:13] <asac> d night ;)
[00:13] <fta> yeah, thanks
[00:14] <micahg> altohough I think my ff build will fail now :)
[01:15] <asac> micahg: so did you check xulrunner-1.9 in universe/main too?
[01:15] <micahg> not yet
[01:15] <asac> micahg: ok.
[01:16] <asac> micahg: but firefox-3.0 was done, right? can you comment your findings in the bug?
[01:16] <asac> at best the firefox-3.0 ones for now ;)
[01:17] <micahg> done
[01:18] <micahg> I tried to build 3.6~b1 with m-dev 0.12
[01:18] <micahg> didn't work too well
[01:18] <asac> micahg: yeah better use the latest m-dev
[01:18] <micahg> I backported it to Jaunty
[01:19] <asac> hmm
[01:19] <asac> micahg: well. you just need the orig.tar.gz
[01:19] <asac> you can produce that in karmic if its bad in jaunty m-dev
[01:19] <asac> though it should work afaik
[01:19] <asac> not sure though because of tip/default etc.
[01:19] <asac> but i thought the hg stuff worked for a while and we didnt change how its integrated in pacakge
[01:20] <asac> but maybe fta redid something i didnt see ;)
[01:20] <micahg> it might not have been the m-dev script
[01:20] <micahg> but I figured it was easy enough to backport
[01:20] <asac> k
[01:20] <asac> micahg: daily ppa has no backport for that afaik
[01:21] <asac> and works too ;)
[01:22] <micahg> hmm
[01:22] <micahg> mist be somethign else
[01:22] <asac> micahg: seahorse-plugins depends on ffox? thought on xulrunner ;)
[01:23] <micahg> oh
[01:23] <micahg> hmmm
[01:23] <asac> hehe
[01:23] <asac> ok so that means you alredy checked main for xulrunner?
[01:23] <asac> e..g just universe and sources missing?
[01:23] <micahg> yeah
[01:23] <asac> or did you search sources?
[01:23] <micahg> I search sources in main
[01:23] <asac> ok ... so binaries and sources+binaries from universe still missing for xul-1.9
[01:24] <micahg> Fixed
[01:27] <micahg> asac: hmm...seems to be working with the new m-dev
[03:30] <micahg> asac: ff3.6build1 and xul1.9,2build1 built fine
[03:39] <LLStarks> asac. micahg. are there any outstanding firefox bugs that need testing or fixing?
[03:39] <LLStarks> *for karmic
[03:52] <micahg> hmm
[04:15] <LLStarks> ...
[04:16] <micahg> idk
[04:18] <micahg> I still have about 180 bugs to triage :)
[04:22] <LLStarks> what about this one?
[04:23] <LLStarks> https://bugs.edge.launchpad.net/firefox/+bug/438868
[04:23] <LLStarks> i hate this bug because i run into every day.
[04:23] <LLStarks> and so will joe windows-user
[04:23] <LLStarks> when he tries karmic
[04:27] <micahg> that's one of the ones I need to get to
[04:28] <micahg> does it happen after an upgrade?
[04:29] <micahg> nevermind...it's already upstreamed
[05:22] <LLStarks> micahg, link?
[06:00] <micahg1> LLStarks: it's in the bug
[06:45] <micahg> asac: I added tasks for all the depends I found in universe
[08:21] <micahg> asac: I found a quick bug that might be worth throwing in ... bug 448683
[09:35] <asac> micahg: is that list complete?
[09:35] <asac> micahg: are those main or universe?
[09:35] <micahg> I checked main already
[09:35] <micahg> that's universe
[09:35] <micahg> should be it
[09:36] <asac> whats going on with prism
[09:36] <micahg> idk
[09:37] <micahg> oh, BTW, when I build 3.6b1+build1, it built with the official branding
[09:38] <micahg> asac: ^^
[09:39] <micahg> ok, time for sleep
[09:39] <micahg> night
[09:39] <asac> thx
[11:54]  * asac merged micahs ffox 3.6 branch
[12:01] <|eagles0513875|> hey asac
[12:02] <asac> hi
[12:04] <|eagles0513875|> how goes it in the office this week
[12:12] <|eagles0513875|> be back from home
[12:17] <av`> asac, are you doing devhelp update?
[12:18] <av`> asac, I did it for debian already
[12:18] <av`> saw your name on the package's page
[12:18] <av`> assigned to devhelp
[12:36] <asac> av`: devhelp == new tarball?
[12:36] <asac> is that gnome?
[12:42] <av`> asac, yes
[12:43] <asac> av`: bug 451864 ?
[12:43] <asac> or something newer?
[12:43] <av`> should be it
[12:47] <av`> asac, why they give you GNOME stuff to do?
[12:49] <asac> why do you think they gave it to me?
[12:49] <asac> at some point i ported it to xulrunner 1.9
[12:49] <asac> since then i more or less take care if it needs new porting
[12:50] <av`> asac, seahorse-plugins failed to build
[12:50] <av`> you enabled ephy plugin  --> enabling epiphany plugin...
[12:50] <av`> but you deleted the depends
[12:50] <asac> annoying
[12:50] <av`> of course it fails trying to find gecko to really build the plugin
[12:52] <asac> sure
[12:52] <asac>  had it right here. but then robert prepared the update and i took it which reverted the configure flags thing
[12:52] <asac> iu shouldnt take care for credits in future
[12:52] <asac> av`: so i just dropped the --enable-gecko ... thats ok?
[12:53] <av`> asac, which credits?
[12:54] <av`> asac, -with-gecko=libxul-unstable is a bit non-sense
[12:54] <av`> if you remove ephy stuff and you leave that
[12:54] <av`> it will fail for sure
[12:54] <av`> let me test build
[12:54] <asac> now i remember ... you said that it will auto detect the that there are no build deps
[12:55] <asac> but that doesnt work
[12:55] <asac> the --disable-epiphany is even needed ;)
[12:55] <av`> in debian wasnt needed
[12:55] <asac> fixing that now
[12:55] <av`> k
[12:55] <asac> yeah
[12:55] <asac> i think it would work without disable on buildds
[12:55] <asac> but if there is gecko it will still take it
[12:55] <av`> exactly
[12:55] <av`> maybe ubuntu still has gecko
[12:56] <av`> asac, did you upload this latest revision?
[12:56] <asac> well. things should never be automagic
[12:56] <asac> always put in --disable-epiphany
[12:57] <asac> otherwise your local builds will differ from real builds
[12:57] <av`> asac, I've removed gecko thing in rules
[12:57] <av`> let's see
[13:02] <av`> asac, and anyway it will auto-detect that there ano B-Ds only if the configure flag --gecko-... is removed
[13:02] <av`> if you leave it you asks configure to find gecko bits
[13:02] <av`> but the B-D is not there
[13:03] <asac> yes. the fault was on my side not dropping it
[13:03] <asac> just saying that not adding --disable-epiphany is also wrong
[13:04] <av`> well, it depends
[13:04] <av`> it won't fail the build
[13:04] <asac> no. but it will pick up gecko if you have it on your disk
[13:04] <asac> which is also wrong ;)
[13:05] <asac> if a package doesnt work ... it shouldnt be build
[13:05] <av`> asac, if you disable gecko and remove the flag
[13:05] <av`> it will say ephipanu plugin disabled
[13:06] <av`> that's what we want
[13:06] <asac> av`: not if you ahve xulrunner-1.9-dev installed
[13:06] <asac> av`: you need to do --disable-epiphany
[13:06] <asac> i just tried it
[13:06] <asac> i expect a reasonable upstream build system to not build epiphany if there is no epiphany--dev installed
[13:06] <asac> but they look for gecko and then flip it on
[13:09] <av`> asac, pretty bad then
[13:09] <av`> removing epiphany-dev should do the work with a correct configure run
[13:09] <asac> av`: no. thats the point ;)
[13:09] <asac> i dont have epiphany-dev installed
[13:09] <asac> hmm i have
[13:09] <asac> so yeah
[13:09] <av`> that's it :)
[13:09] <asac> anyway... all the automagic is painful
[13:10] <asac> explicit flags for the world ;)
[13:10] <asac> nevermind
[13:10] <av`> I'm building it on my buildd
[13:10] <av`> to check
[13:10] <asac> av`: its already uploaded
[13:10] <asac> and accepted
[13:10] <asac> if it fails again i will resign from my job
[13:10] <asac> ;)
[13:12] <asac> av`: so devhelp might have a chance as its not on CD
[13:13] <av`> asac, yeah, seb told me it's not really needed atm
[13:16] <av`> asac, it ftbfs again
[13:16] <av`> asac, jk :P
[13:17] <asac> av`: dont do that :-Ü
[13:17] <asac> i am completely overworked ... hung over and what not atm
[13:17] <av`> ehehe :)
[13:17] <asac> so these kind of jokes make me jump out of window
[13:17] <av`> lol
[13:17] <av`> sorry then :)
[13:17] <asac> https://edge.launchpad.net/ubuntu/+source/seahorse-plugins/2.28.1-0ubuntu3
[13:18] <av`> asac, if it would really ftbfs I would have done it for you so you could have moved to something else
[13:18] <av`> but worked
[13:18] <asac> but seriously. i think for next release i should create a bunch of pbuilder tarballs and actualyl test something
[13:18] <av`> yep
[13:18] <asac> av`: well. the problem would not to do it, but that release managers will kill me ;)
[13:18] <av`> :D
[13:18] <asac> slangasek probably didnt sleep for the whole night and waits for all the bits to be there so he can fire up the ISO run
[13:19] <asac> and i stressed him completely by my xulrunner/firefox etc. uploads today
[13:19] <av`> yeah, so another ftbfs on seahorse-plugins wouldnt be accepted by him
[13:20] <asac> it probably would
[13:20] <asac> but i am not sure i would get anything in after that
[13:20] <asac> like a High importance bug in network-manager -> blocked ;)
[13:20] <asac> you can basically always argue that high importance bugs in apps are not important for the whole release
[13:20] <asac> especially at this time
[13:20] <av`> but everything went fine, good work
[13:20] <av`> going to study now
[13:20] <asac> av`: thx.
[13:21] <av`> see ya late night
[13:21] <asac> av`: btw, i think your work is improving quite a lot
[13:21] <asac> since you came back :)
[13:21] <asac> just wanted to say that ... but forgot yesterday
[13:21] <av`> asac, thanks a lot, I'm doing a focused work and yeah, it's going great so far
[13:21] <asac> i think your work got better when you switched to the most recent nick name
[13:22] <av`> lol
[13:22] <asac> not really sure you are still the same ;)
[13:22] <asac> like a butterfly ;)
[13:22] <av`> maybe im not the old bluekuja
[13:22] <asac> the new one ;)
[13:22] <av`> I'm his transformation
[13:22] <av`> yeah :)
[13:22] <asac> meta-morphosis
[13:23] <asac> ttyl
[13:23] <av`> yeah, it happened for a human
[13:23] <av`> not only for animals then :)
[13:23] <av`> cya later
[13:23] <av`> have a nice day
[13:23] <asac> u2
[13:34] <eagles0513875> back
[14:25] <eagles0513875> hey bdrung
[14:26] <bdrung> eagles0513875: hi
[14:26] <eagles0513875> how are you
[14:28] <bdrung> busy. the term started again
[14:30] <eagles0513875> trust me i know the feeling of being back in lectures :(
[14:30] <eagles0513875> 3rd week and already have 3 tests one down 2 to go this week
[15:33] <LLStarks> asac. bug 438868 is probably compiz related
[16:29] <asac> LLStarks: yes. thats what i thought
[16:29] <asac> bdrung: term? university?
[16:30] <bdrung> asac: yes
[16:31] <asac> have fun
[16:31] <asac> 3g is good during lectures ;)
[16:31] <bdrung> i won't ;)
[16:31] <asac> ... if you lost the wifi password ;)
[16:31] <bdrung> LAN is even better.
[16:32] <bdrung> download with GBit ;)
[16:32] <bdrung> GBit/s
[16:33] <asac> nah. 3g is much better i tell you ;)
[16:33] <asac> especially when everone has lan + wifi ...
[16:33] <asac> ;)
[16:48] <bdrung> asac: how fast is 3g?
[16:48] <asac> quite good
[16:49] <asac> normally you get like 300k
[16:49] <asac> down
[16:49] <asac> and up is almost the same
[16:49] <asac> sometimes much more
[16:49] <asac> and sometimes ... especially if you are in a train its far less
[16:51] <asac> the good is that you can use it almost everywhere
[16:51] <asac> so no need to bother about stationary behaviour
[16:54] <asac> free-flying mode possible ;)
[17:43] <asac> mac_v: did you drop nm-device-active icon from last theme?
[17:43] <asac> or was that link shuffeling?
[17:43] <asac> something must have changed
[17:43] <asac> 18:41 < NoelJB> ** (nm-applet:2390): WARNING **: Icon nm-active-device missing: Icon 'nm-active-device' not present in theme
[17:44] <asac> that was seen during upgrade
[17:44] <asac> could be that its harmless - but could be pretty bad
[17:45] <mac_v> asac: i dont think there was ever an icon by that name. that icon is for what device?
[17:46] <asac> mac_v: well. that icon must exist if nm-applet complains about it ;)
[17:46] <asac> its odd though
[17:46] <mac_v> asac: i meant in humanity theme :)
[17:46] <asac> mac_v: maybe you guys shipped a link to that and now you retargetted that link?
[17:47] <asac> mac_v: this guy uses human theme
[17:48] <asac> is that humanity-icon-theme?
[17:48] <mac_v> bug # ?
[17:48] <asac> mac_v: no bug. its hot. was pinged in nm while that guy updated his sytstem
[17:48] <asac> with todays theme
[17:48] <asac> well... with todays updates ;)
[17:49] <asac> its definitly transitional . just want to understand why that icon was there before ... and was used ... and now is gone
[17:49] <mac_v> i dont remember any icon or symlink being made as "nm-active-device"
[17:49] <asac> only explain i have is that you guys shipped nm-active-device ... linked it maybe as nm-device-wired ... and now moved the nm-device-wired link somewhere else
[17:49] <asac> mac_v: who did todays changes?
[17:50] <asac> i got it too now
[17:50] <asac> upgraded to todays theme
[17:50] <asac> ** (nm-applet:3496): WARNING **: Icon nm-active-device missing: Icon 'nm-active-device' not present in theme
[17:51] <mac_v> there was no humanity had an update today , the latest is 0.4.1ubuntu5
[17:51] <mac_v> asac: i think the icon is a new name from nm applet which humanity doesnt have
[17:51] <bdrung> asac: 300 kB/s or kBit/s?
[17:52] <mac_v> there was no humanity update today*
[17:55] <asac> mac_v: ok its really applet. sorry for the alarm ;)
[17:55] <asac> bdrung: i never use bits
[17:55] <asac> a byte is the minimum full data unit i consider ;)
[17:55] <bdrung> ;)
[17:55] <mac_v> asac: what is that icon for? is it a new naming where -active- is used for panel and ...
[17:55] <asac> bdrung: its pretty decent. when secondary home had broken wifi i used it as primary work connection for a few weeks ;)
[17:55] <asac> even uploading mozilla stuff etc.
[17:56] <bdrung> asac: yes really fast then (compared to dsl, wlan)
[17:56] <asac> and uploads were not much slower than normal dsl
[17:56] <bdrung> asac: but lan at the university is still faster
[17:56] <asac> bfiller: from german mirror i usually get like 1100K down and just 180K up
[17:56] <asac> hehe
[17:56] <asac> sure
[17:56] <asac> but you cannot be in free-flying mode
[17:56] <asac> ;)
[17:56] <mac_v> asac: even so why isnt the nm applet falling back to the default icons from hicolor? i think nm didnt ship the icon too ;)
[17:57] <asac> freedom is more important than speed ;)
[17:57] <asac> mac_v: its something unrelated
[17:57] <mac_v> phew :)
[17:57] <asac> mac_v: its happening when a icon gets removed from disk that is already opened etc.
[17:57] <asac> nothing to do with fallback
[17:57] <asac> would be a theme "fallover feature"
[17:57] <asac> sounds like an interesting idea ;)
[17:58] <bdrung> asac: i only need a fast server to test the speed there (the maximum was 8 MB/s)
[18:00] <asac> i think fta uploads chromium in like 3 seconds ;)
[18:00] <bdrung> asac: that's fast
[18:01] <asac> yes ;)
[18:01] <asac> bdrung: he told me that the rotating dput thing in terminal causes CPU to peak ;)
[18:01] <bdrung> wow
[18:01] <asac> which i find ... interesting ;)
[18:02]  * asac wants that problem ... would promise to fix it ;)
[18:02] <bdrung> ;)
[18:02] <asac> bdrung: so finland folks hav a right to get 100Mbit/s by law by 20015
[18:02] <asac> 2015
[18:03] <asac> bdrung: deutsche telkom reiterated a year ago that they think copper is the future
[18:03] <bdrung> by 20015 we have 100 Mbit/s, too :p
[18:03] <asac> i wouldnt be so sure ;)
[18:03] <asac> i wanted to kill myself when i read that telekom statement :)
[18:03] <asac> actually kill someone else ;)
[18:04] <bdrung> asac: please don't. let someone other do that ;)
[18:05] <asac> hehe
[18:06] <bdrung> asac: hopefully we have 30 Mbit/s at home next year
[18:09] <asac> i wanted to go for kabeldeutschaldn when i move to a new home
[18:09] <asac> i definitly deny to be a customer of DTAG again even if they have the 50 thing ;)
[18:10] <asac> also i have this inner feeling that dsl is a major problem in my life ... ;) so i am looking forward to do something else
[18:10] <asac> i just remember me sitting here and replugging modems/routers all the time ... or just getting hourly resets etc.
[18:14] <micahg> asac: there's no xulrunner metapackage AFAICT
[18:15] <asac> micahg: whats the context? hi ;)
[18:16] <micahg> hi, depends on xulrunner (>=1.9~
[18:16] <micahg> xulrunner refers to 1.8
[18:17] <asac> micahg: hmm. which packages did i close that way?
[18:17] <asac> can you reopen them?
[18:18]  * asac had hoped that this mess is over
[18:18] <micahg> xulrunner-dev points to 1.9
[18:18] <micahg> I mean 1.9.1
[18:19] <micahg> conkeror and galeon
[18:19] <asac> micahg: indeed. what a mess
[18:20] <asac> wonder why i mixed that up ;)
[18:20] <asac> wee only hav e-dev as meta package for xulrunner
[18:21] <micahg> asac: also, did you get my not about 3.6 building with official branding
[18:21] <micahg> *note
[18:21] <asac> micahg: email? i didnt even look at email today :/
[18:21]  * asac feels miserable ;)
[18:21] <micahg> no
[18:21] <micahg> in here
[18:21] <asac> oh
[18:21]  * asac scrolls up
[18:21] <micahg> 3.6b1+build1 built with official branding
[18:22] <asac> if no mail i should really get whats going on here ;)
[18:22] <micahg> it was about 9 hours ago
[18:22] <asac> micahg: hmm. ok.
[18:22] <micahg> is that ok?
[18:22] <asac> micahg: so in the past we shipped betas as official branding
[18:22] <micahg> ok
[18:22] <asac> that was when firefox-3.0 was out
[18:22] <asac> but now we stopped doing that for 3.5
[18:22] <micahg> does mozilla ship betas as official branded?
[18:23] <asac> my guess is that the rules script changes were done on 3.5 branch only
[18:23] <asac> and need to be also applied to 3.6 and 3.7 branches
[18:23] <asac> can you check that?
[18:23] <micahg> yeah
[18:23] <micahg> It says (alpha) in the menu
[18:23] <asac> micahg: unclear. i am sure they did for 3.0 betas. but not so sure about 3.5. but we definitly do not do that anymore
[18:23] <micahg> ok
[18:24] <micahg> I was wondering why I was so lucky to have FIrefox 3.6 :)
[18:24] <asac> micahg: essentially, now that final is out, we need to review  _all_ changes that were committed to 3.5 branch and check that everything is also on 3.6 branch
[18:24] <asac> i think we also made changes how the .desktop files are treated etc.
[18:24] <asac> so before doing that we shouldnt look at these things in the branches directly
[18:24] <asac> rather first be sure we have everything in sync ;)
[18:25] <asac> also identify why things were just committed there
[18:25] <asac> so we can learn how to better do it in future ... e.g. almost every time we should commit everything first to current highest version branch
[18:25] <asac> then  to next ... and then eventually to current default ubuntu brnch
[18:26] <asac> jdstrand: btw, i think we get worst timing again
[18:26] <asac> jdstrand: afaik sec update is 28th. so lets hope they do another respin or something ;) ... though i think its unlikely its going back for a full other week
[18:27] <asac> so mabe 28th is best if we want to update same day ... or friday is best if we want to update three days after.
[18:27] <asac> but given how huge this update is we might want to wait a full week ;)
[18:28] <LLStarks> asac, are you glad that that bug is compiz related?
[18:28] <asac> [reed]: is nss/nspr you talked about in .4 or .5?
[18:28] <asac> LLStarks: why would i be glad about a bug
[18:28] <asac> LLStarks: i am not the person that is happy when bugs go somewhere else
[18:29] <asac> i prefer them to stay in my domain of expertise because thats where i can best help
[18:29] <LLStarks> glad, as opposed to something more profound and deeply-ingrained in the code
[18:29] <jdstrand> asac: hmmm... I think friday has to be the way to go. otherwise we are messing with CD respins, especially if there are regressions
[18:29] <asac> LLStarks: i am glad that you could track down
[18:29] <asac> jdstrand: friday is day-after-release?
[18:30] <jdstrand> asac: yeah
[18:30] <asac> jdstrand: ok. and since we have soyuz we are not blocked by ugly archive copies or something?
[18:30] <jdstrand> asac: if it is super serious, then I advise talking to slangasek
[18:30] <jdstrand> asac: no-- soyuz is not an issue
[18:31] <asac> jdstrand: i dont think talking to slangasek will change anything on whether we can or cannot do that ;)
[18:31] <asac> jdstrand: i definitly dont want to put the update out on wed
[18:31] <asac> and thu is release ... so fri sounds quite good
[18:32] <jdstrand> alright, good. :)
[19:02] <fta> jdstrand, i'm still stuck with my kvm. and #ubuntu-virt is desperately quiet :(
[19:03] <fta> asac, acroread (from the partner repo) installs tons of copies of the pdf plugin: http://paste.ubuntu.com/297683/
[19:04] <fta> asac, .. but nothing in our xul dir
[19:04] <asac> fta: i think the mozilla location also works
[19:05] <asac> shouldnt be installed in all those 3.* versions
[19:05] <asac> oh
[19:05] <asac> thats a link thing right?
[19:05] <asac> odd
[19:05] <asac> yeah
[19:05] <asac> dpkg -L ?
[19:05] <fta> it does. i just wanted to remove the plugin (i prefer the system/external pdf viewer for the web)
[19:06] <asac> fta: most plugins dirs are a link there
[19:06] <asac> so its probably two or even just one copy
[19:06] <asac> i guess three: firefox/ ... mozilla/ ... and firefox-addons/plugins
[19:06] <asac> what is /usr/lib/firefox-minefield/plugins/nppdf.so
[19:06] <asac> ?
[19:07] <asac> why do you have a  firefox-minefield
[19:07] <asac> ?
[19:08] <fta> http://paste.ubuntu.com/297686/
[19:08] <fta> i think it's in postinst
[19:08] <fta> firefox-minefield is from m-d, my upstream nightly repacks
[19:10] <asac> fta: is that upstream nightly repack in a branch? or are you really repacking the upstreamtar.gz thigns=?
[19:11] <fta> the latter
[19:11] <asac> urgh
[19:11] <asac> in postinst?
[19:11] <asac> oh now
[19:11] <asac> please tell me its in firefox-addons/plugins ;)
[19:11] <asac> oh no
[19:11] <asac> so much dirt :(
[19:11] <fta> fta@ix:~ $ pastebinit /var/lib/dpkg/info/acroread.postinst
[19:11] <fta> http://paste.ubuntu.com/297690/
[19:12] <asac> hmm cannot see where they copy it in the firefox folders
[19:12] <fta> that's acroread jaunty, as there's no version for karmic :(
[19:13] <asac> still
[19:13] <asac> where are the .so things coming from
[19:13] <asac> also ... whats going on with the icons
[19:13] <asac> why is that needed in postinst
[19:13] <fta> i use acroread (even if i hate non free stuff) because evince takes too much cpu, and the rendering is ugly (both text and pictures)
[19:14] <asac> fta: do you have a link to the .dsc at hand?
[19:14] <fta> http://archive.canonical.com/ubuntu/pool/partner/a/acroread/
[19:14] <asac> anyway
[19:14] <fta> http://archive.canonical.com/ubuntu/pool/partner/a/acroread/acroread_9.1.3-1jaunty1.dsc
[19:15] <asac> i think all the versioned firefox things arent a problem
[19:15] <asac> at least there is a link
[19:15] <asac> so it would overwrite the firefox-addons location multiple times
[19:17] <asac> ouch
[19:17] <asac> acroread-9.1.3$ ls
[19:17] <asac> AdbeRdr9.1.3-1_i386linux_enu.deb  debian
[19:17] <asac> no. i will not proceed down that road ;)
[19:18]  * asac forgets what he just saw
[19:19] <jdstrand> fta: ask kirkland and/or soren in #ubuntu-server then. I saw them earlier
[19:19] <jdstrand> fta: though someone else might be able to help in there too
[19:20] <fta> jdstrand, i guess i should just file a bug :( http://paste.ubuntu.com/297586/
[19:20] <jdstrand> fta: possibly, but they may know about it already
[19:21] <fta> but i have no error to paste for the boot failing, other that it doesn't work, i have no other info
[19:21] <jdstrand> fta: I vaguely recall seeing a bug regarding Windows and kvm
[19:22] <jdstrand> fta: soren and kirkland are the ones who maintain kvm and libvirt in Ubuntu. they should be able to help
[19:22] <asac> does *bsd work well with kvm too?
[19:22] <jdstrand> asac: it certainly used to, though I haven't tried recently
[19:23] <jdstrand> I had openbsd in a vm and I believe kees had freebsd (6?) in there
[19:23] <asac> good. probably worth trying to get netbsd on that ;)
[19:23] <jdstrand> heh, you picked the one I don't know about :P
[19:23] <asac> heh. i like netbsd best (based on a real low amount of work i did)
[19:24] <asac> i tried all and when i ended up in issues netbsd was always quiet obvious by reading scripts etc.
[19:24] <asac> imo freebsd tried to introduce more smartness ... which seems to more difficult
[19:24] <jdstrand> possibly unsurprisingly, I was a fan of openbsd
[19:24] <asac> hehe
[19:24] <asac> yeah. i found openbsd to be a a bit unobvious too
[19:24] <asac> ;)
[19:24] <asac> but last time i really used it was a bit ago ;)
[19:25] <jdstrand> I've been phasing out my obsd installs in favor of ubuntu. I down to maintaining one obsd machine
[19:25] <jdstrand> s/I/I'm/
[19:25] <asac> jdstrand: right. now i remember why i didnt like openbsd ;) ... it wasnt possible to tune the uptime ;)
[19:25] <asac> jdstrand: like here: http://www.jwsdot.com/tuptune/#freebsd
[19:26] <asac> thats the dumpest thing i ever did ;)
[19:26] <asac> openbsd resets the tcp timestamps for each connection
[19:26] <jdstrand> heh
[19:26] <asac> so no uptime with nmap ;)
[19:27] <asac> "The good of NetBSD is that the 2 Hz timestamp ticker is able to produce really great values like 5 years or something." ;)
[19:27] <asac> not even sure if thats still true
[19:28] <jdstrand> wow. if they can go 5 years without a CVE in the kernel, that is pretty impressive
[19:28] <jdstrand> granted, all the BSDs have far fewer CVEs in their kernels
[19:28] <asac> jdstrand: i think its 8 years or something at max
[19:29] <asac> if you dont have any port open
[19:29] <jdstrand> and by far, I mean *far*
[19:29] <asac> when was the last tcp/ip exploit?
[19:29] <asac> like in 2.2?
[19:29] <asac> (on linux)
[19:29] <jdstrand> there was an sctp one relatively recently
[19:30] <jdstrand> but I don't recall offhand
[19:30] <jdstrand> but it you can get a user account on a system with a local root exploit, that is nearly as good
[19:30] <jdstrand> (eg, bad cgi/php script...)
[19:31] <asac> sure
[19:31] <jdstrand> most of the linux CVEs are DoS
[19:31] <asac> yeah. but there must be a http server without a vulnarability that allows you to exploit a normal html static load ;)
[19:31] <jdstrand> local DoS
[19:32] <asac> yeah
[19:32] <jdstrand> and a local DoS is kinda like 'so?'
[19:32] <jdstrand> it is easy enough to do that without an 'exploit'
[19:32] <asac> i assume a local DoS is usually a memleak in kernel?
[19:32] <asac> at least a real dos ... wouldnt htink that just overload can be a Dos
[19:33] <jdstrand> it's usually stuff that'll make it oops
[19:33] <asac> ah ok
[19:33] <asac> yeah. but thats a real issue on a multi-user system ;)
[19:35] <jdstrand> sure. but a user can do an overload type of thing to achieve something similar
[19:35] <asac> jdstrand: is there a thing like ulimit for CPU?
[19:36] <asac> guess VM ;)
[19:36] <jdstrand> ulimit -a
[19:37] <asac> oh ;)
[19:37] <asac> cpu time               (seconds, -t) unlimited
[19:37] <asac> err ... is that an absolute value? per-process?
[19:38] <jdstrand> I don't consider resource exhaustion interesting. I was just saying that if you can perform a resource exhaustion attack, and you can make the kernel oops, there isn't a tremendous practical difference
[19:39] <asac> New package: synce-multisync-plugin (universe) [0.9.0-4.1 → 0.9.0-6ubuntu1]
[19:39] <asac> odd package name ;)
[19:40]  * asac off ... will check later for things
[20:20] <micahg> oh, apt-pinning for a PPA doesn't seem to work right
[20:21] <micahg> asac: http://packages.ubuntu.com/karmic/prism
[20:21] <micahg> xulrunner-1.9.1-dom-inspector  	                 Package not available
[20:23] <micahg> hmm
[20:23] <micahg> apt-pinning is working in aptitude, but not in update-manager
[20:26] <fta> jdstrand, fyi, i just file bug 456602
[20:28] <jdstrand> fta: cool, I'll try to confirm it
[20:28] <micahg> asac: ugh
[20:29] <asac> ugh
[20:29] <micahg> you made a ff3.0 package in ff.35?
[20:29] <fta> lol, i typed guess instead of guest
[20:29] <asac> micahg: sorry ... what do you mean?
[20:29] <micahg> http://pastebin.com/f327d82ca
[20:29] <asac> so yes. i think i invented a non-existing abrowser-3.0 ;)
[20:29] <asac> yes
[20:29] <fta> oh, we can edit comments now
[20:29] <micahg> but that caused bug 456598 and possibly more
[20:30] <asac> micahg: thats a transitional package ... thats the way to ensure that users dont get stuck with something old, not supported, not working etc.
[20:30] <asac> micahg: transitaional packages is: you put in the empty package into the new source that is supposed to take over
[20:30] <asac> that transitaional package depends on what the new installed package should be
[20:30] <micahg> yes, but in this case, I think a transitional for ff3.0 uis a bad idea
[20:30] <asac> and you add provides: oldpackage, replaces: oldpackage (<=newversion)
[20:30] <micahg> it'll screw with depends
[20:30] <micahg> and stuff
[20:31] <asac> micahg: not sure
[20:31] <asac> what you mean
[20:31] <micahg> https://launchpad.net/bugs/456598
[20:31] <fta> who are all those poor "Also notified" people? i pitty them, zillions of emails a day
[20:32] <asac> fta: subscribers of the package
[20:32] <asac> so if you subscribe to the whole package you get listed thre
[20:32] <asac> fta: but its per package ... you can also do that on "ubuntu" i think
[20:32] <asac> but thats a bad idea ;)
[20:32] <asac> micahg: afaik mozvoikko does not work in firefox-3.5
[20:33] <micahg> asac: well, then the package itself has an incorrect control file
[20:33] <asac> most likely
[20:33] <micahg> and apparently the user was using it in 3.5
[20:33] <fta> asac, i see the same names in ff, libvirt, kernel, lp, whatever, i guess they are bug control or something
[20:33] <asac> i mean ... the breaks probably wasnt added there for nothing
[20:33] <micahg> it breaks 3.0
[20:34] <asac> micahg: if mozvoikko was fixed the breaks should have been dropped
[20:34] <fta> or just crazy
[20:34] <asac> micahg: mozvoikko breaks 3.0?
[20:34] <micahg> yes
[20:34] <micahg> that's the problem
[20:34] <asac> it should break 3.0 << 3.1~
[20:34] <asac> not in general
[20:34] <micahg> and the transitional package has 3.0
[20:34] <asac> thats a mozvoikko bug then
[20:34] <micahg> I wonder how many other packages like that?
[20:34] <asac> i would think not many
[20:35] <asac> we ensured that everything was transitioned
[20:35] <micahg> transitional ff3.0 seems counterintuitive
[20:35] <asac> no
[20:35] <asac> thats the _only_ way
[20:35] <micahg> transitional ff makes sense
[20:35] <asac> no
[20:35] <asac> firefox-3.0 can be installed alone
[20:35] <jdstrand> fta: how much ram do you have?
[20:35] <asac> we cannot not transition them
[20:35] <heikki> mozvoikko works with ff-3.5
[20:35] <asac> heikki: sure.
[20:35] <jdstrand> fta: and did the iso boot or you saw the error before the iso booted?
[20:36] <asac> the Breaks: was simply a packaging bug
[20:36] <asac> even my bug ;)
[20:36] <heikki> :)
[20:36] <heikki> could you fix it?
[20:36] <fta> jdstrand, i have 2GB of RAM + 6GB of swap, i tried with 512M and 1.5G, same result
[20:37] <heikki> afaik it is not necessary to have that Breaks-field, is it?
[20:37] <jdstrand> fta: did the iso boot? ie, did you start install and then later see the error, or did it error out after storage completed?
[20:38] <fta> jdstrand, the libvirt error is when installing.. the thing in text mode asking you to accept the license, choose the partitioning. it seems to work fine until it asks to reboot
[20:38] <asac> heikki: yes. thats true. i think when i added that i was not sure if the template install.rdf makes the right thing
[20:38] <jdstrand> fta: http://www.mail-archive.com/fedora-list@redhat.com/msg51978.html
[20:38] <asac> heikki: so good point.
[20:38] <asac> heikki: oh
[20:38] <asac> heikki: so what is generated as minVersion?
[20:39] <asac> isnt that 3.0?
[20:39] <fta> the shutdown part produces the error, then nothing. if i manually start the resulting vm, i see nothing past the bios
[20:39] <jdstrand> fta: https://bugzilla.redhat.com/show_bug.cgi?id=500968
[20:39] <asac> problem i think was that it was 3.0, but the binary was not compatible with 3.0 because its built against xulrunner 1.9.1
[20:39] <heikki> MOZVOIKKO_FF_MIN  = 3.0a9pre
[20:39] <jdstrand> fta: I'll update the bug
[20:40] <asac> heikki: yeah. so i will just patch that
[20:40] <heikki> file mozvoikko.config
[20:40] <jdstrand> fta: you said this works with jaunty?
[20:40] <heikki> ok, thanks
[20:41] <heikki> um, i'm not sure if that file is used at all, there is also a setting MOZVOIKKO_FF_MAX  = 3.0
[20:41] <asac> heikki: http://paste.ubuntu.com/297760/
[20:41] <asac> does that look ok?
[20:42] <asac> heikki: huh. for me that max is 3.6a1pre
[20:42] <heikki> oh, wait..
[20:42] <heikki> could be some old version then...
[20:42] <fta> jdstrand, yes, i've used several VMs created with that same ISO file on the same H/W. it was fine. i stopped using those VMs for a while, but I recently needed to use them again, my old VMs refused to boot, then i tried to create new ones, and here i am
[20:42] <heikki> yes it is 3.6a1pre
[20:43] <heikki> so your paste looks good
[20:43] <asac> heikki: ok.. i changed tbird and sm too
[20:43] <asac> randomly took 3.0b2 ... as i think that was already against 1.9.1 branch
[20:43] <asac> for sm i used 2.0b1 ... also imo 1.9.1 branch build
[20:43] <asac> fta: do you remember when sm and tb switched to 1.9.1?
[20:43] <fta> micahg, asac: ff 3.5 FTBFSed
[20:43] <asac> is 3.0b2 and 2.0b1 a good guess?
[20:44] <heikki> thunderbird doesn't use xulrunner for a spellchecking
[20:44] <micahg> ugh
[20:44] <micahg> daily?
[20:44] <asac> upstream landed something?
[20:44] <asac> thats odd
[20:44] <asac> thought they are in build3 freeze or something
[20:44] <asac> heikki: tbird 3?
[20:45] <heikki> afaik it won't work yet
[20:45] <asac> heikki: http://paste.ubuntu.com/297766/ thats the thing i will land
[20:45] <asac> doing a quick test build and then uploading
[20:45] <asac> micahg: actually you are somewhat right about the ffox-3.0 transitional package ... the initial plan was to not do that
[20:46] <heikki> looks good
[20:46] <asac> micahg: but we found out that _all_ packages are marked as manually by germinate ... so all CD install would have got stuck
[20:46] <asac> that was not the plan ;)
[20:46] <asac> so we go for good old transitional packages
[20:46] <asac> a tad late in cycle of course
[20:46] <asac> but usually you just do it and then fix all the rdepends
[20:46] <fta> asac, http://hg.mozilla.org/comm-central/log/3645d6bc085b/mail/config/version-191.txt
[20:47] <fta> 2009-01-07
[20:47] <asac> ok a1pre
[20:47] <asac> hmm
[20:47] <fta> well, no
[20:47] <asac> well b2pre is probably good guess
[20:47] <fta> that's the 3.0 / 3.1 split
[20:47] <asac> or are we even not ahead of that?
[20:47] <asac> ah ok
[20:48] <fta> 3.1 is using moz-central, so 1.9.3 now
[20:48] <asac> heikki: ok seems that min version is honored, but max version not
[20:49] <asac> heikki: like http://paste.ubuntu.com/297769/
[20:49] <asac> fta: whats the current tbird version? b3?
[20:49] <heikki> I think that upstream has left it for a packager to decide
[20:49] <asac> hmm seems we are at 3.0pre
[20:49] <fta> 3.0pre
[20:49] <asac> yeah
[20:49] <asac> good so 3.0b2 is at least not higher ;)
[20:50] <asac> heikki: micahg: uploaded
[20:51] <heikki> thanks.
[20:53] <asac> welcome. good that it was spotted ;)
[20:53]  * asac gett a bit more confident that important issues somehow bubble up and are not missed
[20:56] <asac> sigh awesomebrowser patch _again_
[20:56] <asac> have to check how to get rid of that somewhat
[20:56] <asac> fta: micahg: oh
[20:56] <asac> i know whats going on
[20:56] <asac> we have to drop a patch
[20:56] <fta> feel free
[20:57] <asac> i had to prepatch the branding fixes i committed to the branding branch
[20:57] <fta> less patches is always good for us
[20:57] <asac> hehe
[20:57] <asac> yeah. well that was just thzere for today
[20:57] <asac> i will create the karmic branch now
[20:57] <asac> and then uncommit from .head
[20:57] <asac> err uncommit ;) ... remove i mean
[20:57] <fta> yeah (not uncommit plz)
[21:22] <fta> jdstrand, *sigh*
[21:23] <fta> and there's not even a ppa up to the task
[21:28] <micahg> asac: did you see the issue with prism?
[21:28] <asac> micahg: no
[21:28] <asac> i assume it doesnt work at all
[21:29] <micahg> depends on xul-1.9.1-dom-inspector
[21:29] <micahg> whcih doesn't exist
[21:29] <asac> heh
[21:29] <asac> i have to check that
[21:29] <asac> prism should have been updated in karmic
[21:29] <micahg> should I file a bug?
[21:29] <asac> maybe we can do that in this turn
[21:30] <micahg> asac: do you need a bug to remind you?
[21:30] <fta> xul-1.9.1-dom-inspector should exist, otherwise, if you drop xul 1.9 for the archive, dom-inspector would be lost
[21:30] <asac> micahg: bugs only remind me by new mail ;)
[21:30] <asac> micahg: but i think we need a bug
[21:30] <micahg> ok
[21:30] <micahg> I'll file one
[21:31] <asac> fta: well. dom-inspector is gone from upstream source
[21:31] <asac> micahg: thx
[21:31] <asac> micahg: if you want to can do the update too ... but we probably should check that it actually works while we are at it
[21:31] <fta> really? hm, maybe, i don't remember
[21:31] <asac> fta: yes. they dropped it ... and put it in an independent projet ... just like pyxpcom
[21:31] <micahg> update prism, or a new package without the depends?
[21:31] <asac> or it was constantly broken
[21:31] <asac> cant remember anymore, but explicitly dropped it
[21:32] <asac> micahg: well. first try if a new package works with 1.9.1 at all
[21:33] <micahg> asac: is this high or critical?
[21:33] <asac> micahg: dont know. i think high is high enough ;)
[21:33] <asac> critical is probably more like: if you install it wipes your hard-disk ;)
[21:33] <micahg> well, package won't install in karmic now
[21:33] <micahg> so isn't that critical for the package?
[21:34] <asac> there are no strong definitions imo
[21:34] <asac> i guess its probably quite critical for the package ... yes
[21:34] <asac> though removal of data would be worse ;)
[21:34] <asac> its a personal thing
[21:35] <asac> whatewver you want ;)
[21:35] <asac> fact is: we have to fix this
[21:35] <micahg> yes
[21:35] <asac> and high is high enough to justify an upload in freeze
[21:35] <micahg> I can test tonight
[21:35] <asac> thx
[21:35] <asac> its no real hurry. universe fixes canstill be done
[21:35] <asac> just main is done now
[21:35] <micahg> high is correct :)
[21:36] <asac> didnt know there is a "correct" ;)
[21:36] <micahg> I checked in the -bugs channel :)
[21:36] <asac> k
[21:36] <asac> probably good for a second opinion
[21:36] <asac> the importance is kind of mixed thing in ubuntu
[21:37] <micahg> asac: there is a wiki page
[21:37] <asac> usualy its "package" importance ... until you milestone and target for release
[21:37] <asac> then its more like "how bad is it for the whole release"
[21:37] <micahg> actually, should I assign the prism bug to me?
[21:37] <micahg> yeah, importance seems to be distro wide
[21:38] <asac> micahg: sure. in case you find that you cannot follow up, just reassign to me :)
[21:38] <micahg> I originally thought it was package wide
[21:38] <asac> and ping ;)
[21:38] <micahg> ok
[21:38] <micahg> so, I'll look at it tonight
[21:38] <asac> my personal word is: dont take importance too serious ;)
[21:38] <asac> just rough estimate is good enouhg ... it should suite your own worklist workflow
[21:38] <asac> and not confuse others ;)
[21:39] <asac> fta: should i keep the 3.1 name for .karmic branches?
[21:39] <asac> and we fix that in one run ?
[21:40] <asac> or start using 3.5 now and we fix the others later?
[21:40] <asac> fta: oh also ... i saw that the branding branch for abrowser is kind of hard coded in mozclient
[21:40] <fta> asac, we should rename asap
[21:40] <asac> can we move that to the package itself ?
[21:40] <asac> now i created a -3.5 branch
[21:41] <asac> but bot still pulls from non veresioned
[21:41] <asac> which is ok atm, but we should fix that before we bust our security updates
[21:41] <fta> "branding branch for abrowser", i think we only have 1 for the 3 firefox
[21:42] <asac> fta: thats not possible
[21:42] <asac> fta: they changed branding entities
[21:42] <asac> so i had to fix that
[21:42] <asac> luckily we had one for 3.0 already
[21:42] <asac> and its also used in mozclient
[21:42] <asac> and i expect them to change branding entities again in future ... so we need major version branches
[21:43] <asac> https://code.edge.launchpad.net/~mozillateam/firefox/awesome-browser-branding-3.5
[21:43] <asac> https://code.edge.launchpad.net/~mozillateam/firefox/awesome-browser-branding-3.0
[21:43] <asac> https://code.edge.launchpad.net/~mozillateam/firefox/awesome-browser-branding
[21:43] <fta> but http://paste.ubuntu.com/297801/
[21:44] <asac> fta: oh cool. so its in the package
[21:44] <asac> grewat
[21:44]  * asac needs to commit that before doing the .karmic branch
[21:44] <fta> so awesome-browser-branding-3.5 is not used
[21:44] <asac> fta: atm. es.
[21:44] <asac> fta: but 3.0 is used
[21:44] <asac> and since i had to fix the non versioned branch now
[21:44] <asac> i made a -3.5 branch
[21:46] <fta> asac, rename all the branches in lp, i'll rename in the bot
[21:47] <asac> fta: one second
[21:47] <asac> currently pushing this commit
[21:47] <asac> then lets do it
[21:47] <asac> fta: only .head branches ... ;)
[21:47] <fta> yes
[21:47] <asac> and the new .karmic branch will be 3.5
[21:47] <asac> ok
[21:48] <asac> fta: ok i have an up-to-date copy ... so i am safe ;)
[21:48] <fta> please do 3.6 too
[21:48] <asac> yes
[21:49] <fta> and .head.daily too
[21:49] <asac> ok renamed firefox-3.1.head to firefox-3.5.head
[21:49] <asac> renamed firefox-3.2.head to firefox-3.6.head
[21:49] <asac> https://code.edge.launchpad.net/~mozillateam/firefox/firefox-3.6.head
[21:49] <asac> https://code.edge.launchpad.net/~mozillateam/firefox/firefox-3.5.head
[21:50] <asac> looking at dailies now
[21:50] <asac> ok done
[21:50] <asac> https://code.edge.launchpad.net/~ubuntu-mozilla-daily/firefox/firefox-3.5.head.daily
[21:50] <asac> https://code.edge.launchpad.net/~ubuntu-mozilla-daily/firefox/firefox-3.6.head.daily
[21:50] <asac> thats all=
[21:50] <asac> ?
[21:52] <asac> ok me prepares .karmic branches
[21:53] <micahg> I wish you could throw '/me' in the middle of a sentance
[21:56] <asac> shit
[21:56] <asac> can someone try to branch the karmic branch?
[21:56] <asac> https://code.edge.launchpad.net/~mozillateam/firefox/firefox-3.5.karmic
[21:56] <micahg> sure
[21:57] <fta> it's huge
[21:57] <fta> done
[21:57] <fta> Branched 489 revision(s).
[21:57] <asac> good
[21:58] <fta> Standalone tree (format: 1.6)
[21:58] <micahg> asac: I think the icons that tb2-gnome-support uses have changed in karmic
[21:58] <asac> i got this: http://paste.ubuntu.com/297808/
[21:58] <asac> zr: ERROR: exceptions.AssertionError: second push failed to complete a fetch set
[21:58] <asac> dont know if i want to file abug ;) ... probably should
[21:58] <fta> hm
[21:59] <asac> ok .karmic branch lowered version
[22:00] <asac> so now xulrunner
[22:01] <fta> hm, i still have an old firefox-3.1-qt.head branch
[22:01] <fta> and an even older firefox-4.0.head
[22:01] <asac> yeah
[22:01] <asac> maybe mark as abandoned for now?
[22:01] <asac> in launchpad?
[22:01] <asac> and rename?`
[22:02] <asac> like firefox-4.0.head.thatbecame.3.1.abandoned
[22:02] <asac> or
[22:02] <fta> watching my 100+ branches locally
[22:02] <asac> fta: remote is more important to get rid of clutter ;)
[22:02] <asac> for us at least :)
[22:02] <asac> not sure how many living-dead branches i have though
[22:03] <fta> i'm concerned by my --remember, if i just push, i will recreate the old branches
[22:03] <asac> like things that havent been touched for 130 weeks ;)
[22:03] <asac> i assume those are obviously abandoned
[22:03] <asac> lp:~mozillateam/iceape/debian-1.1.x   	  	 1  Development   	 2007-04-24 11:42:11 CEST
[22:03] <asac> 130 weeks ago
[22:03] <asac> 78. * New security/stability upstream rel...
[22:03] <fta> lol
[22:03] <asac> fta: at best go through all branches you have locally and push --remember to some randome location that isnt a real location
[22:04] <asac> hmm
[22:04] <LLStarks> debian's license-anal attitude doesn't make sense.
[22:04] <asac> shouldnt matter  as long as you dont just do --force
[22:04] <micahg> LLStarks: Ubuntu's license schema is a little more open
[22:05] <asac> LLStarks: it doesnt make sense based for projects with some goals ... if your goal is to provide an always free distribution that cannot disappear because it gets sued and so on
[22:05] <asac> then it makes sense
[22:05] <asac> also debian isnt really that strict
[22:05] <asac> they have non-free
[22:05] <asac> there are other distros with _only_ free stuff
[22:05] <asac> if you say they are anal because they dont let in licenses that conflict
[22:05] <asac> then its plain wrong
[22:06] <asac> its illegal to ship stuff that uses GPL and is itself licensed whatever else ... i
[22:06] <asac> f its incompatible its illegal ;)
[22:06] <asac> ubuntu has a similar attitude to licensing
[22:06] <asac> only big difference is that we allow non-free icons in
[22:06] <LLStarks> yet we love mozilla's public license and binary graphic stacks
[22:06] <asac> under the assumption that they can be easiyl replaced
[22:06] <micahg> and we allow Firefox in main :)
[22:07] <asac> LLStarks: somewhat yes. but MPL is really a mess
[22:07] <asac> its not really feasible to require you to keep your stuff 6 month online
[22:07] <asac> what happens if you dont have money anymore or something happens with your hosting etc. ;)
[22:07] <LLStarks> would people have a ****-fit if we shipped abrowser?
[22:07] <asac> or the world blows up
[22:08] <asac> LLStarks: not sure. we intentionally didnt choose iceweasel
[22:08] <asac> not because we think its wrong for debian. but because we think there is too much wrong understanding about why and what caused this
[22:08] <asac> like: mozilla thinks that debian wanted to ship low-quality ;)
[22:09] <asac> mozilla == mozilla community folks
[22:09] <asac> and the world thinks something that is highly biased by misinformation
[22:09] <asac> they might have read a slashdot article or a bunch of rants etc. ;)
[22:16] <micahg> asac: is that menu translation worth throwing in?
[22:18] <asac> micahg: prism?
[22:18] <micahg> bug 448683
[22:18]  * micahg kicks ubottu
[22:18] <micahg> bug 448683
[22:18] <asac> launchpad is really bad mood today
[22:19] <micahg> https://launchpad.net/bugs/448683
[22:19] <asac> identi.ca is also in bad shape :/
[22:19] <asac> cannot send a dent through webinterface
[22:19] <micahg> change  slovak translation of menu entry     in firefox-3.5
[22:20] <asac> hmm
[22:20] <asac> micahg: for karmic?
[22:20] <micahg> yeah
[22:21] <asac> can you tag that as karmic-updates ... and since thats afe enough we can also add it to the branch already ... maybe verify that this guy is really LP admin of slovak
[22:21] <asac> i might do another upload of trivial stuff
[22:21] <asac> so we can stack that alrewady
[22:22] <asac> in worst case it goes out in sec update
[22:22] <asac> tag == milestone ;)
[22:24] <asac> BUGabundo: hi buga
[22:25] <asac> ;)
[22:25] <asac> BUGabundo: so ... i heard that a huawei linux patch landed?
[22:25] <asac> i duped your bug ... was that uploaded yet?
[22:25] <asac> duped your duped bug ;)
[22:25] <micahg> asac: done
[22:26] <asac> micahg: proposed against .head or .karmic?
[22:26] <BUGabundo> boas noites
[22:27] <BUGabundo> hey asac
[22:27] <asac> bonas evening
[22:27] <BUGabundo> asac: let me check bug mail
[22:27] <asac> k
[22:27] <BUGabundo> I read the linux bug two days ago
[22:27] <micahg> idk, I didn't do anything yet?
[22:27] <BUGabundo> very *very* nasty bug
[22:27] <asac> yes. but i thought it was fixed and i duped your bug into that
[22:27] <asac> micahg: no
[22:27] <BUGabundo> if we go GOLD without a fix
[22:27] <asac> micahg: https://code.edge.launchpad.net/~mozillateam/firefox/firefox-3.5.head ... https://code.edge.launchpad.net/~mozillateam/firefox/firefox-3.5.karmic
[22:28] <asac> micahg: imo its enough if you propose it against .head and tell that you want a cherry-pick to .karmic
[22:28] <micahg> ok, so you want me to make a branch for it?
[22:28] <asac> at best add your name like [...] in .head changelog so the cherry pick will automatically do the right thing
[22:28] <asac> micahg: no ... just propose the .desktop update against .head
[22:28] <micahg> the reported is a member of the slovak translators
[22:28] <asac> and say that you want it to be cherry-picked to .karmic
[22:28] <micahg> ok, a merge request?
[22:29] <asac> micahg: thats the usual way
[22:29] <micahg> ok
[22:29] <asac> we should talk about a better way soon i guess ;)
[22:29] <micahg> that's what I was asking
[22:30] <micahg> So I assigned to em
[22:30] <micahg> me
[22:30] <asac> yeah
[22:30] <asac> micahg: so basically we want this everywhere
[22:30] <asac> not sure if we have translations for 3.7/3.6 at all
[22:30] <micahg> asac: probably
[22:30] <micahg> I'll check
[22:30] <asac> but if .desktop has it we should follow the rule of thumb to not land something on branches if it isnt landed on more experimental branches
[22:30] <micahg> at least for the desktops
[22:30] <asac> yes
[22:46] <fta> grrr, karmic ships with a 2~3 months old libvirt, 2 upstream releases late
[22:48] <fta> where are our package bzr branches?
[22:50] <asac> good question
[22:50] <asac> maybe code.launchpad.net/ubuntu/package ?
[22:50] <asac> fta: you just need to find a bug that was fixed
[22:50] <asac> usually the branches get auto attached there
[22:50] <asac> well ... fixed in upload ,)
[22:50] <asac> checking ffox upload
[22:50] <asac> something a bit older
[22:51] <asac> https://edge.launchpad.net/bugs/236853
[22:51] <fta> i expected something like http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/libvirt
[22:51] <asac> fix uploaded end of sep
[22:51] <asac> launchpad doesnt like me ;)
[22:51] <asac> slow
[22:51] <asac> fta: yes. there are brnaches
[22:51] <asac> lp:ubuntu/jaunty-proposed/firefox-3.5
[22:51] <asac> https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/jaunty/firefox-3.5/jaunty-proposed
[22:51] <asac> hah
[22:51] <asac> ~ubuntu-branches
[22:52] <asac> https://code.edge.launchpad.net/~ubuntu-branches/
[22:52] <asac> that must be huge ;)
[22:52] <asac> guess launchpad goes down now ;)
[22:52] <asac> wow
[22:52] <asac> 1  → 100  of 179152 results
[22:52] <asac> too bad
[22:52] <asac> one cannot step down ... like
[22:52] <asac> https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/
[22:52] <asac> or https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/karmic
[22:53] <fta> found it, https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/karmic/libvirt/karmic
[22:53] <asac> yeah
[22:53] <asac> now we understand ;)
[22:53] <asac> !libvirt
[22:53] <asac> !firefox
[22:54] <asac> that should probably also have the launchpad and the branch page
[22:54] <asac> and also respond to source package names ;)
[22:54] <asac> !source karmic
[22:54] <asac> !source firefox
[22:54] <asac> !libvirt source
[22:54] <asac> hmm
[22:54] <asac> !package firefox
[22:54] <asac> !package firefox-3.0
[22:54] <asac> !info firefox
[22:54] <asac> ah
[22:54] <asac> ok
[22:54] <asac> that one i mean
[22:54] <asac> hehe
[22:54] <asac> !info libvirt
[22:54] <asac> !info libvirt0
[22:55] <BUGabundo> asac: just got a strange pop up
[22:55] <asac> !info libvirt/source
[22:55] <BUGabundo> and nm-applet blew
[22:55] <asac> BUGabundo: yes
[22:55] <asac> BUGabundo: thats a daily bug
[22:55] <BUGabundo> soemthing about not albe to find necessary resources
[22:55] <BUGabundo> ok
[22:55] <fta> debian has 0.7.1 and they already moved to policykit
[22:55] <asac> we targetted it for karmic-updates
[22:55] <asac> one second
[22:55] <fta> i need 0.7.2
[22:55] <BUGabundo> reported :)
[22:55] <asac> today
[22:55] <asac> i got it NoelJB got it ... now you
[22:55] <asac> guess its High
[22:55] <asac> ;)
[22:56] <asac> bug 456468
[22:59] <BUGabundo> bug 456468
[22:59] <BUGabundo> bots like me better :)
[22:59] <BUGabundo> subbing
[23:00] <micahg> asac: your patch got accepted :)
[23:02] <asac> micahg: which one?
[23:02] <asac> the one?
[23:02] <asac> ;)
[23:02] <asac> one liner
[23:02] <micahg> mozilla bug 521780
[23:02] <asac> good
[23:03] <asac> well. i was sure it was
[23:03] <asac> wouzld
[23:03] <asac> ;)
[23:03] <micahg> so, I know what I'm working on, asac, you're fixing the FTBFS for ff3.5 daily?
[23:04] <asac> micahg: yes right now
[23:04] <asac> ;)
[23:04] <asac> thx for remidng
[23:04] <micahg> ok
[23:07] <asac> done
[23:07] <asac> rev 490
[23:08] <BUGabundo> asac: this FF annoying yellow bar about restarting FF, is *annoying*
[23:09] <micahg> BUGabundo: I think it's supposed to be :)
[23:09] <BUGabundo> its ANNYOING
[23:09] <BUGabundo> I already pressed the cross
[23:09] <BUGabundo> I don't want to hear more about it!!!
[23:09] <asac> BUGabundo: screenshot
[23:09] <asac> BUGabundo: if you get that ... you are close to getting a bad firefox ... so better restart
[23:10] <asac> the warning does what its supposed to do ... it stays there
[23:10] <asac> ;)
[23:10] <BUGabundo> uploading
[23:10] <asac> if you dont restart your ffox will go bad
[23:10] <BUGabundo> http://dl.getdropbox.com/u/112892/Screenshot.png
[23:10] <asac> yes
[23:10] <asac> restart
[23:10] <asac> ;)
[23:10] <asac> more i cant say ;)
[23:10] <jcastro> know your rights!
[23:11] <asac> well. if you dont restart soon worst thing is that in some rare occasions you might even loose data
[23:11] <micahg> asac: I hope you didn't delete debian/patches/series :X
[23:11] <micahg> :x
[23:11] <asac> or end up with otherwise corrupted data in profile etc
[23:11] <asac> shit
[23:11] <asac> micahg: i will uncommi and fix comment
[23:11] <asac> sorry ... bad practice ... i know
[23:12] <fta> how come will we ship karmic with 78 outstanding merges and 255 updated merges just for main??
[23:13] <BUGabundo> restarting FF
[23:14] <micahg> asac: better ;)
[23:17] <asac> fta: i think there is no general answer
[23:17] <asac> fta: i will try to figure out if this cycle something went wrong in our process
[23:17] <asac> but lots of outstanding merges are most likely packages maintained here
[23:18] <asac> like network-manager
[23:18] <micahg> asac: where can I find tagged builds from mozilla?
[23:18] <asac> not sure if someone blacklisted it from that list already
[23:18] <asac> good question
[23:18] <asac> http://ftp.mozilla.org/pub/mozilla.org/firefox/
[23:18] <asac> i would think there
[23:18] <micahg> releases?
[23:18] <asac> maybe
[23:18] <asac> mostlikely
[23:18] <asac> but not sure
[23:18] <asac> [reed]: ^^ ?
[23:19] <asac> hmm. i know there are build3 builds out there for 3.5.4
[23:19] <asac> but no folder like that
[23:19] <asac> micahg: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.5.4-candidates/
[23:19] <asac> so here http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
[23:19] <micahg> ah
[23:19] <asac> seems they put candidates there
[23:20] <micahg> so I need to respin my 3.6b1
[23:20] <asac> not sure if they keep them around though
[23:20] <micahg> build2 is out
[23:20] <asac> micahg: if you made a build1 ... then yes.
[23:20] <micahg> I do the same process?
[23:21] <asac> micahg: so if you simulate what we would do in a "normal" security/stability update you would just flip the text you added in current topmost changelog
[23:21] <asac> but besides from that follow same procedure
[23:21] <asac> e.g. not a full new release
[23:21] <asac> changelog-wise
[23:21] <asac> but not sure if you have branches at all for those
[23:21] <micahg> but I get-orig-source again like alst time?
[23:21] <asac> yes
[23:21] <micahg> ok
[23:21] <asac> just with new tag
[23:21] <micahg> got it
[23:21] <asac> micahg: check out how i document security stability updates in stable branches like .jaunty etc.
[23:22] <asac> i think for beta build1,2,3 it should be similar
[23:22] <fta> https://merges.ubuntu.com/main-trend.png
[23:22] <asac> not stability/security update of course ;) but rather "beta release build1 (FIREOFX_...BUILD1)
[23:23] <fta> our libvirt is too different from debian, too much work for me just to try if it fixes my problem :(
[23:24] <micahg> DO I add a new comment or just edit the current one, since it's not official?
[23:28] <asac> micahg: what i meant above is that you edit the build1 comment
[23:28] <micahg> ok
[23:28] <asac> open it with UNRELEASED again
[23:28] <asac> edit
[23:28] <asac> upload ;)
[23:28] <asac> adjust version of course
[23:29] <micahg> it should say unreleased?
[23:29] <asac> so if you previously had like 3.5.1+build1-0ubuntu6 ... you would go to
[23:29] <asac> 3.5.1+build2-0ubuntu1
[23:30] <asac> micahg: well. if things go to anywhere official we close changelogs. as they might potentially get released. if you want to simulate that process, then you close it for the upload
[23:30] <asac> but reopen in case build2 comes ... because that basically means that the build1 got never released
[23:30] <micahg> well, I changed unreleased to karmic since I needed to upload
[23:30] <asac> so process is: "release" a +build1 to some staging area
[23:30] <asac> in case that gets officially released later upstream we copy that to the real release area
[23:30] <asac> in case it doesnt we upload +build2 to t he staging area
[23:31] <asac> same game
[23:31] <asac> thats why build2 is not a new changelog entry
[23:31] <micahg> I didn't make a bzr branch for it
[23:31] <asac> because build1 never hits the release channel ... just staging
[23:32] <asac> micahg: right. for upload you always need to release (technically)
[23:32] <micahg> ok
[23:32] <micahg> just wanted to make sure I didn;t mess something up
[23:33] <asac> no. if you do it in your ppa and dont do a branch you want to get into .head
[23:33] <asac> then you cannot do much wrong
[23:33] <asac> except choosing a wrong version
[23:34] <BUGabundo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446146 still no updates :(
[23:34] <asac> oh ok
[23:34] <asac> so it was really just committed
[23:34] <asac> too bad
[23:34] <asac> BUGabundo: its a karmic-updates bug
[23:34] <asac> will get released in first kernel SRU
[23:34] <asac> which i would think will happen pretty soon after release
[23:34] <BUGabundo> asac: SO BAD :(
[23:35] <BUGabundo> SRU is really bad
[23:35] <BUGabundo> anyone using livecds won't have internet
[23:35] <asac> well. thats the process
[23:35] <micahg> I hope they fix ath9k
[23:35] <BUGabundo> so how are those users expected to upgrade?
[23:35] <asac> its like a big boat ... driving through a whole with high speed
[23:35] <asac> so you cannot really stop at some point or change a different route
[23:36] <asac> micahg: what ath9k issues do you see?
[23:36] <asac> regular disconnects (like NM disconnects) ... or regular packet loss?
[23:36] <micahg> wireless disconnects semi-frequently still
[23:36] <asac> or bad state and need reboot
[23:36] <micahg> need to modprobe -r and add back after suspend
[23:36] <asac> disconnects like: really drops or package loss?
[23:36] <micahg> both
[23:37] <BUGabundo> asac: for me and lot of users
[23:37] <BUGabundo> it warrants the ship date to be changed
[23:37] <BUGabundo> its a critical bug
[23:38] <micahg> BUGabundo: maybe go poke #ubuntu-kernel
[23:38] <asac> they wont do a kernel upload before release i think
[23:38] <asac> problem is that we release time based
[23:38] <BUGabundo> let me update the bug then
[23:38] <BUGabundo> asac: it's a critical bug
[23:38] <asac> that has risks and has benefits
[23:38] <BUGabundo> should be considered
[23:39] <asac> it is considered
[23:39] <asac> its fix committed
[23:39] <BUGabundo> leaving users stranded without internet
[23:39] <BUGabundo> is not a solution
[23:39] <asac> it is not considered to hold back the release
[23:39] <BUGabundo> ok
[23:39] <asac> i cannot say thats right or wrong :) ... answer is that i dont know
[23:39] <BUGabundo> so bye bye internet
[23:39] <asac> i know that if one is struck by a bug
[23:39] <BUGabundo> me and many other users depend on 3G modems
[23:39] <asac> then its critical for one self
[23:40] <BUGabundo> I haven't been able to access intenet on my laptop for 3 weeks now
[23:40] <asac> BUGabundo: so basic idea is that you upgrade with jaunty on ... and all the updates get automatically installed.
[23:40] <micahg> asac: last release was after freeze
[23:40] <asac> BUGabundo: so in theory it could be added to release notes
[23:40] <micahg> they could upload another fix
[23:40] <BUGabundo> prob here is no updates!
[23:40] <BUGabundo> those with net to get updates will get the newer kernel too
[23:40] <BUGabundo> as long as it is available as soon as release
[23:41] <BUGabundo> the prob here is users on livecd installing a fresh system
[23:41] <asac> the problem with the kernel is that you cannot just upload it and hope all is fine
[23:41] <asac> so if you upload it and everything breaks its a mess
[23:41] <asac> its a real huge overhead to do a release
[23:41] <asac> firefox is a huge overhead too for security updates
[23:41] <asac> lots of testing
[23:41] <asac> but by far not as much that you need on a kernel
[23:42] <asac> so you upload that and then all different hardware testing and all stuff needs to be rerun etc.
[23:42] <asac> and QA has to stop ...s tart from scratch
[23:42] <asac> all vedded and community tested images, trashed
[23:42] <BUGabundo> I understand that
[23:42] <asac> its not easy ... not saying that there is no potential improvement ;)
[23:43] <BUGabundo> if it can't be done on time
[23:43] <BUGabundo> it should be delayed
[23:43] <BUGabundo> I know its bad pub
[23:43] <BUGabundo> I know pleanty of ppl are counting on it
[23:43] <BUGabundo> but a critical bug for a big subset of users
[23:43] <BUGabundo> is not acceptable
[23:43] <asac> yes. but problem is that all hardware that doesnt work or regressed will be critical for whoever has that hardware
[23:43] <asac> so you woul dhave to fix _all_ hardware regressions
[23:43] <BUGabundo> its a 3 week bug
[23:43] <asac> thats not possible
[23:43] <BUGabundo> an huge regression
[23:44] <asac> for the hardware affected
[23:44] <asac> yes.
[23:44] <asac> the closer you get to release the higher threshold you get on things that will be considered release critical
[23:45] <asac> i agree that its not obvious what would hold back a release
[23:46] <BUGabundo> 10% users affected enough?
[23:46] <micahg> asac: is this ok for a changelog entry?   * Test release of 1.9.2 beta 1 build 2 (FIREFOX_3_6b1_BUILD2)
[23:46] <BUGabundo> how about all the bad pub??
[23:46] <asac> micahg: yes.
[23:46] <BUGabundo> its not something that can be fixed _after_ install!!!
[23:46] <asac> BUGabundo: users usually boot livecd
[23:46] <asac> if that device does not work you know that you cannot use it
[23:46] <BUGabundo> and no net there
[23:47] <asac> so you wouldnt install
[23:47] <BUGabundo> how many will test 3G there before install?
[23:47] <BUGabundo> if I give a CD to someone
[23:47] <asac> if you upgrade ... you know that upgrading on first day is proably a bad idea - just out of common sense
[23:47] <BUGabundo> they install it
[23:47] <BUGabundo> and endup without net
[23:47] <BUGabundo> I know, 2 years ago
[23:47] <BUGabundo> we didn't even had support for it :)
[23:47] <asac> BUGabundo: you give a CD to someone to test. they test it and if it works for them well they install it
[23:47] <BUGabundo> but now, we depend on it
[23:47] <asac> thats how it should be imo
[23:48] <asac> BUGabundo: yes. its a problem. as i said, all hardware regression is critical for those that have that hardware
[23:48] <asac> if we follow through with what you would like we would never release
[23:48] <asac> because every new kernel version will hav hardware regressions
[23:48] <BUGabundo> I know
[23:48] <micahg> BUGabundo: you can fix after install with a wired connection
[23:49] <asac> so thats why if it doesnt really matter when you release
[23:49] <asac> we would need to look at "how much hardware regressed"
[23:49] <asac> compre that to jaunty
[23:49] <asac> yes. and in worst case most people will be able to get net somewhere
[23:49] <asac> wifi from friend/neighbour
[23:49] <asac> or lan
[23:49] <asac> in internet cafe
[23:49] <asac> opf course annoying
[23:50] <asac> but checkout what happens if you give a random guy to install a pure windows
[23:50] <asac> on a blank system
[23:50] <asac> they will have no net ...m aybe no keyboard, nothing ;)
[23:50] <asac> ugly vga graphics card. ;)
[23:51] <asac> so user has to go to internet cafe and download all kind of drivers ... on a separate machine and then copy that somehow over ;)
[23:51] <asac> not saying thats something we should compare with
[23:51] <asac> just that we should compare same things
[23:51] <asac> and not forget what how good/bad other things are
[23:51] <asac> still we should have an idealistic goal ... zero bugs
[23:52] <micahg> asac: currently at 70k+ open :)
[23:52] <BUGabundo> asac: I've entered my view on the bug :)
[23:52] <BUGabundo> lets hope for the best
[23:52] <asac> but what any OS needs is not a "easy way to get a perfect install on random hardware you found or build together"
[23:52] <asac> BUGabundo: yeah
[23:53] <asac> continue .... it needs "mass factory installs of LTS" ... ;)
[23:55] <micahg> asac: can I use the same tarball for xulrunner and firefox?
[23:56] <asac> micahg: no
[23:56] <micahg> ok
[23:56] <asac> micahg: well. its probably the same inside
[23:56] <asac> but i wouldnt rely on it
[23:56] <asac> needs knowledge of the mozclient details
[23:56] <micahg> ok, I'm building a new one for firefox
[23:56] <asac> micahg: you could help fixing the LOCAL_BRANCH feature for mercurial
[23:56] <asac> so you can just have one local branch
[23:56] <asac> ;)
[23:57] <micahg> maybe someday
[23:57] <asac> hehe
[23:57] <asac> right
[23:57] <micahg> where is that, in mozclient?
[23:57] <micahg> or in actual hg?
[23:57] <asac> micahg: you can do ./debian/rules get-orig-source ... LOCAL_BRANCH=/path/to/local/clone/of/hg/or/git/or/bzr/tree ;)
[23:57] <asac> so it will not get the initial clone from the remote location
[23:57] <asac> rather update the existing checkout/clone
[23:58] <asac> and use that to prepare orig
[23:58] <asac> much faster
[23:58] <asac> ;)
[23:58] <asac> micahg: oh "where" ;M)
[23:58] <asac> its in Mercurial.pm
[23:58] <asac> or something
[23:58] <micahg> yes, but in m-dev?
[23:59] <asac> micahg: yes
[23:59] <asac> ther eis a mozclient/ directory in source
[23:59] <micahg> is there a bug for it?
[23:59] <asac> i had it on my personal todo list
[23:59] <asac> let me check
[23:59] <fta> asac, there's a bug in my LOCAL_BRANCH code in m-d, remember?
[23:59] <asac> yes
[23:59] <asac> thats what i am talking about
[23:59] <fta> oh, ok