[02:25] <dtchen> Preparing to replace firefox-3.5 3.5.2+nobinonly-0ubuntu2 (using .../firefox-3.5_3.5.3+build1+nobinonly-0ubuntu1_amd64.deb) ...
[02:25] <dtchen> ln: creating symbolic link `/etc/apparmor.d/disable/usr.bin.firefox-3.5': No such file or directory
[02:25] <dtchen> dpkg: error processing /var/cache/apt/archives/firefox-3.5_3.5.3+build1+nobinonly-0ubuntu1_amd64.deb (--unpack): subprocess new pre-installation script returned error exit status 1
[02:37] <jdstrand> :/
[02:37] <jdstrand> dtchen: I'll fix that
[02:42] <jdstrand> dtchen: do you have a /etc/apparmor.d/disable directory?
[02:47] <dtchen> jdstrand: no.
[02:47] <jdstrand> dtchen: did you remove apparmor?
[02:48] <dtchen> looks like it: un  apparmor                                       <none>                                         (no description available)
[02:49] <jdstrand> dtchen: that explains it
[02:49] <jdstrand> dtchen: ok, thanks
[02:49] <dtchen> apparmor doesn't seem to be seeded at all for ubuntu-desktop, either
[02:50] <jdstrand> interesting
[02:50] <dtchen> i guess it gets pulled in via ubuntu-standard's apparmor-utils Recommends
[02:50] <jdstrand> dtchen: yes, Recommends. you aren't required to have it installed
[02:51] <jdstrand> dtchen: I'll fix up the packaging
[02:51] <dtchen> thanks
[02:58] <jdstrand> asac: please pull r462 from bzr+ssh://bazaar.launchpad.net/~jdstrand/firefox/firefox-3.5-apparmor/ to fix dtchen's problem
[02:58] <jdstrand> asac: I forgot to do a mkdir in preinst :(
[02:58] <jdstrand> (I have it in the ApparmorProfileMigration page but it got missed)
[02:58] <jdstrand> dtchen: sorry about that
[02:59] <dtchen> jdstrand: np
[02:59]  * jdstrand wanders off again
[08:58] <asac> hi
[09:05] <asac> jdstrand: uploaded
[09:05] <asac> bdrung: 180 N   Sep 02 Archive Administrator     (0.7K) all-in-one-sidebar_0.7.10-1_amd64.changes ACCEPTED
[09:05] <asac> nice
[09:06] <asac> first NEW package using the new xpi:Depends made it into debian ;)
[09:09] <asac> fta: didnt we put the _modules link in ia32libs yet?
[09:09] <fta> i never pushed my last update
[09:09] <asac> sigh
[09:10] <asac> whats the problem?
[09:12] <fta> it was crashing remember?
[09:13] <asac> fta: yeah. but it doesnt crash now ;)
[09:13] <asac> all seems to be good
[09:14] <asac> if we dont add anything new, and drop atk-bridge and add the link i think all should be fine
[09:20] <fta> the idea was to add gvfs and libgail-common
[09:21] <asac> ok. and thats still broken?
[09:21] <asac> in any case we shouldnt block no bug 369498 because we cannot add new stuff imo
[09:22] <fta> btw https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[09:22] <asac> grr ... canonical seems to have disabled access to all the developers machines ... now i need to open a ticket to get it reenabled
[09:23] <fta> i didn't try ia32 recently, now that chromium is native x64, the pressure on me is gone
[09:23] <asac> yeah
[09:23] <asac> would be precious if you could do this one update and then go off the hook ;)
[09:24] <asac> just add the link and remove the atk-bridge module ... i am sure it works. if not someone else has to take over ;)
[09:24] <asac> the build failure for 3.7 looks odd
[09:25] <asac> same for 3.5
[09:25] <asac> was that me who broke it? feels like upstream committed bad things
[09:26] <fta> no idea, i didn't look into this
[09:28] <asac> could be that this was caused by me dropping the nss/nspr patch
[09:28] <asac> but strange that it didnt happen here: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/ppa
[09:29] <fta> yeah, that and 3.5 and 3.7 broke, but not 3.6
[09:29] <asac> hmm
[09:30] <asac> i tried to commit everything on all three branches
[09:30] <asac> maybe i missed something ...
[09:30] <asac> well. i guess its really upstreawm bug _after_ 3.5.3 release
[09:30] <asac> have no other explanation how the 3.5 can build in security
[09:30] <asac> the packaging should be identica
[09:30] <asac> l
[09:31] <asac> undefined reference to `PR_AtomicDecrement'
[09:31] <asac> nsGnomeVFSProtocolHandler.cpp
[09:33] <asac> g++ -o nsGnomeVFSProtocolHandler.o -c -I../../dist/include/system_wrappers -include ../../config/gcc_hidden.h -DOSTYPE=\"Linux2.6\" -DOSARCH=Linux -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gnome-vfs-module-2.0   -I. -I. -I../../dist/includ
[09:33] <asac> rm -f libnkgnomevfs.so
[09:33] <asac> g++  -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -g -fno-strict-aliasing -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions  -fPIC -shared -Wl,-z,defs -Wl,-h,libnkgnomevfs.so -o libnkgnomevfs.so  nsGnomeVFSProtocolHandler.o     -lpthread   -Wl,-rpath-link,/usr/lib/x
[09:34] <asac> last line on working build is:
[09:34] <asac> g++  -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -g -fno-strict-aliasing -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions  -fPIC -shared -Wl,-z,defs -Wl,-h,libnkgnomevfs.so -o libnkgnomevfs.so  nsGnomeVFSProtocolHandler.o     -lpthread   -Wl,-rpath-link,/usr/lib/x
[09:34] <asac> so yeah ... nspr link stuff is not in there anymore
[09:35] <asac> -lplds4 -lplc4 -lnspr4
[09:35] <asac> feels like it has to do with my droppage of the nss/nspr patch
[09:36] <asac> but then again it uses the same packaging ;/
[09:36] <asac> hmm
[09:37] <asac> ok here it is:
[09:37] <asac> http://paste.ubuntu.com/264271/
[09:38] <asac> seems they bumped nspr lower bound
[09:38] <bdrung_> asac: nice.
[09:38] <asac> and the fallback to non-system one does not work without the patch i dropped
[09:38] <asac> failed build has:
[09:38] <asac> checking for NSPR - version >= 4.8.0... no
[09:38] <asac> Package mozilla-nspr was not found in the pkg-config search path.
[09:39] <asac> working 3.5 build in security has:
[09:39] <asac> checking for nspr-config... /usr/bin/nspr-config
[09:39] <asac> checking for NSPR - version >= 4.7.0... yes
[09:39] <asac> checking for nss-config... /usr/bin/nss-config
[09:39] <asac> checking for NSS - version >= 3.12.0... yes
[09:39] <asac> c4fc12311fd3 Kevin Brosnan - Bug 499144 - system-nspr dependency outdated in configure.in (4.7 -> 4.8), r=bsmedberg, a=dveditz
[10:52] <fta> hm, ok
[11:01] <fta> asac, a while ago, I wanted to simplify our backports by creating a build-deps ppa: https://edge.launchpad.net/~ubuntu-webtech/+archive/build-deps
[11:01] <fta> asac, i hit some cdbs issues
[11:06] <asac> fta: do you know if dist/bin/nspr-config gets put  into the sdk if we dont use system libs?
[11:06] <asac> fta: what issues?
[11:07] <asac> AIL: distutils-2.sh
[11:07] <asac> FAIL: distutils-3.sh
[11:07] <asac> FAIL: distutils-4.sh
[11:07] <asac> FAIL: distutils-5.sh
[11:07] <asac> FAIL: distutils-6.sh
[11:07] <asac> FAIL: distutils-7.sh
[11:07] <fta> yep
[11:07] <asac> FAIL: distutils-8.sh
[11:07] <asac> what do those test do?
[11:07] <fta> probably a python issue
[11:14] <fta> asac, did you say that you now longer need the nmt emails i forward you?
[11:15] <asac> fta: no. i want mails
[11:15] <asac> i just got them twice
[11:16] <asac> already deleted the daily mails from today
[11:16] <fta> i mean, should i stop my redirection?
[11:16] <asac> will remember t check tomorrow
[11:16] <fta> ok
[12:01] <asac> fta: chromium-browser -> LICENSE
[12:01] <asac> status?
[12:02] <fta> needs a refresh
[12:02] <fta> they keep adding stuff :(
[12:02] <asac> fta: i am mostly interested in the licensecheck thing that shows the parts that are not documented
[12:06] <fta> asac, grab the latest tarball, extract it, run ".../chromium-browser.head/debian/licensecheck.pl ." on it
[12:06] <asac> thx
[12:06] <fta> add -a to skip my white list
[12:08] <fta> my tarball is now 30% bigger than since i last stripped it
[12:13] <fta> the bot now reports tarball growths
[12:18] <asac> nice
[12:58] <fta> asac, ok, finally took the time to setup a multi dist-arch pbuilder
[12:58] <fta> asac, the cdbs issue is "error: option --install-layout not recognized" when calling cd . && python setup.py install --root=/tmp/buildd/cdbs-0.4.59ubuntu2~fta1~hardy/test/workdir/cdbs-testsuite-0.1/debian/python-cdbs-testsuite/ --no-compile -O0 --install-layout=deb
[12:59] <asac> hmm
[12:59] <asac> where is setup.py shipped?
[13:11] <fta> asac, http://paste.ubuntu.com/264376/
[13:17] <asac> what i mean is: why would setup.py not have that argument if its really shipped in the cdbs sources
[13:17] <asac> my guess is that it copies it from somewhere
[13:17] <asac> anyhow ... lunch
[13:17]  * asac still fought the nspr things
[13:35] <fta> asac, my multi-pbuilder script, http://paste.ubuntu.com/264389/
[13:35] <fta> but i guess you already have something to do that
[14:02] <asac> fta: maybe that should go into pbuilder package?
[14:02] <asac> no i dont have that as i dont use pbuilder ;)
[14:03] <fta> i didn't use pbuilder until recently
[14:03] <asac> for pbuilder i would need faster disks
[14:03] <asac> like SSD or something
[14:04] <fta> with my quad-core, pbuilder is really nice ;)
[14:05] <fta> it's nice to quickly fix the dailies
[14:06] <fta> the only thing i miss is a way to pass variables to the build from bd, like our USE_XXX
[14:07] <asac> remind me when i say that i have a new system ;)
[14:07] <asac> i am regularly looking at those i7 beasts ;)
[14:07] <asac> with 24G mem :)
[14:09] <asac> the problem is the more you move to christmas the more you are sure that prices are artificially high :)
[14:09] <asac> and when i assemble such a system i always get an itchy finger thinking about gaming
[14:09] <asac> which adds costs on top ;)
[14:10] <fta> eheh
[14:11] <asac> otoh those i7 seem to not move price wise at all
[14:11] <asac> i think they were at that price for 6 month
[14:11] <asac> http://www.kmelektronik.de/shop/index.php?show=subgroup&group=5&subgroup=837
[14:11] <asac> most likely something else is in the pipeline
[14:12] <asac> and no ... i wont pay 900 € for a CPU
[14:12] <fta> hm, wth? open link in browser in xchat now opens in epiphany!
[14:13] <asac> feels like i will end up with AMD again ;)
[14:13] <asac> xchat is a mess ;)
[14:13] <asac> use irssi
[14:14] <fta> iirc, it was less than 1000€ for my whole system, 24", 1TB, quad-core, 8GB, etc..
[14:14] <asac> with monitor?
[14:14] <asac> thats odd
[14:14] <fta> 24"
[14:14] <asac> cant be a that great one ;)
[14:15] <asac> well
[14:15] <fta> asus
[14:15] <asac> a good one should be about 350 €
[14:15] <asac> monitor i mean
[14:15] <asac> yeah
[14:15] <asac> fta: what graphics chip?
[14:15] <asac> i think 700€ for a system like that is ok ... but most likely not a high end graphics thing
[14:15] <fta> GeForce 9600 GT
[14:16] <asac> how much MB? on graphic? 512?
[14:16] <fta> yes
[14:16] <asac> ok 9600GT is at 98 €
[14:17] <asac> are you happy with that?
[14:17] <fta> yes
[14:17] <asac> hmm
[14:17] <asac> wonder if that would be good enough for me ;
[14:17] <fta> i wanted one without a fan
[14:18] <fta> i have a 7600 GT at home
[14:20] <fta> setup.py is just calling the system distutils.core
[14:20] <asac> ah ok
[14:20] <asac> i think cdbs should just skip those tests
[14:20] <asac> that involve =deb
[14:20] <asac> iirc it was only added in karmic
[14:29] <asac> ok i think i am close fixing the nspr-config stuff
[14:30] <asac> wont get to 1.9.1 branch today though
[14:30] <asac> (just 1.9.3/3.7 for today)
[14:31] <asac> fta: actually i think the reason why 1.9.1 and -central failed is that thy didnt bump the lower version for nspr in 1.9.2 branch et
[14:31] <asac> the build error only happens if no system nspr is used
[14:32] <fta> eh? it would have broken upstream builds then
[14:37] <asac> no
[14:37] <asac> only in combination with our patches
[14:37] <asac> and yes
[14:37] <asac> upstream --with-libxul-sdk is broken i am pretty sure
[14:37] <asac> but they dont build like that
[14:41] <asac> http://paste.ubuntu.com/264417/
[14:41] <asac> thats the new patch on firefox side
[14:42] <asac> in turn the old bad nspr_nss patch has to go
[14:42] <asac> which i am really happy about i must say ;)
[14:43] <asac> and i did some packaging smarties in xulrunner ... but those should actually be done in the upstream build system
[14:43] <asac> like: create nspr-config link to system nspr-config if system nspr is used
[14:43] <asac> same for the sdk/include/nspr/
[14:43] <asac> which is now a link to /usr/include/nspr
[14:43] <asac> both should be done in upstream dist/... and packager
[14:44] <asac> like this: http://paste.ubuntu.com/264419/
[14:45] <asac> fta: should i move the new binary-install/...-dev rule below the binary-predeb?
[14:46]  * asac wonders if 1.9.1 already has the flag include dir
[14:46]  * asac installs 1.9.1-dev
[14:51] <asac> too bad 1.9.1 needs a different fix as it has old style include dir still
[14:51] <asac> hmm
[15:05] <asac_> reconnect
[15:07] <asac_> fta: i see we pass system-nss/-nspr unconditionally for firefox .... did this never cause any issues?
[15:07] <asac_> e.g. even if nspr is too low etc.
[15:08] <fta> hm, do we do that?
[15:08] <asac_> yes
[15:08] <asac_> i think configure.in itself has a safety net though
[15:12] <asac_> so it probably does the right thing
[15:15] <fta> right, and i did it.. a cryptic "Re-add --with-system-nspr / --with-system-nss" a sunday at 5am o_O
[15:16] <asac_> hehe
[15:16] <asac_> i think its ok
[15:17] <asac> the idea is that we get to a point where --system-nspr/nss dont matter at all if you use--with-libxul-sdk
[15:17] <asac> and we are pretty close with our xul -dev package now
[15:17] <asac> just that the stuff i did in rules should be done somewhere in proper xul code
[15:18] <asac> maybe firefox build should actually error out if someone tries to set with or without-system-nspr/nss in libxul-sdk case
[15:18] <asac> as it makes no sense
[15:20] <fta> hm
[15:21] <fta> i hate those /usr/bin/*-config
[15:32] <jcastro> morning moz team!
[15:50] <fta> jcastro, hi!
[15:51] <fta> jcastro, i wonder if the cxchromium growth we see is not just new people sending stats, instead of new installs
[15:55] <fta> the gwibber client seems to be silently dying
[15:55] <jcastro> my backend freezes sometimes
[15:55] <jcastro> kenvandine is fixing it, right? :)
[15:56] <kenvandine> jcastro, i haven't seen that
[15:57] <kenvandine> my wife has been running r393 on jaunty for about a week... and it is still working... no crashes and hasn't restarted
[15:57]  * kenvandine restarts constantly running from a checkout :)
[15:58] <fta> i don't see crashes, but each time i want to have a look at what's new, gwibber is no longer in the systray
[16:04] <asac> well
[16:04] <asac> for me closing window quits gwibber
[16:04] <asac> its a bug
[16:04] <asac> you have to click on tray to hide it instead if you want to keep it open
[16:04] <asac> fta: ^^
[16:04] <asac> kenvandine: ^^
[16:05] <kenvandine> ok
[16:05] <kenvandine> we will look at that
[16:05] <kenvandine> should be easy
[16:05] <fta> asac, i know that, i'm never using the close button to minimize an app to tray
[16:06] <fta> it's in tray when i go to bed, it's gone when i wake up
[16:07] <fta> asac, SEAMONKEY_2_0b1_RELEASE
[16:11] <fta> pace_t_zulu, hi, i read you're setting up a chromium buildbot, are you working on a new package?
[16:11] <pace_t_zulu> hi fta
[16:11] <pace_t_zulu> the build bot is for mac os x
[16:12] <pace_t_zulu> i like working with different operating systems
[16:12] <pace_t_zulu> trying to find a place where i am useful
[16:12] <fta> doesn't upstream already have one?
[16:13] <pace_t_zulu> fta: yes
[16:13] <pace_t_zulu> fta: they build against 10.5 sdk
[16:13] <pace_t_zulu> i suppose it is purely academic
[16:14] <pace_t_zulu> i'm trying to find a place where i can contribute
[16:15] <pace_t_zulu> i am capable... but i've yet to find a place where my contributions are wanted and useful
[16:15] <pace_t_zulu> but i'm trying
[16:15] <fta> ok :)
[16:16] <pace_t_zulu> just installed snow leopard this weekend... there's a need for compatibility work there... it seems
[16:17] <pace_t_zulu> right now i'm trying to figure out how launchd handles environment variables
[16:17] <pace_t_zulu> i have a quad core xeon machine at work... so i want it to be working when i'm not here
[16:18] <fta> pace_t_zulu, yeah, i know the feeling, i do all my dailies on a quad-core @ work too
[16:19] <pace_t_zulu> do you have a job outside of the ubuntu project?
[16:19] <fta> sure
[16:19] <fta> full time
[16:20] <fta> asac, i'm experimenting with a summary in the bot emails, what do you think?
[16:21] <asac> i like how the emails improved
[16:22] <asac> summaries are great. might be that i missed them today.
[16:22] <fta> look at the last ucd, 10 min ago
[16:22] <asac> yeah
[16:22] <asac> looks good
[16:22] <asac> i will think about other things that might go in there ;)
[16:22] <fta> sure
[16:23] <asac> maybe the upstream and bzr changelogs
[16:23] <asac> would be good
[16:23] <asac> not sure how long that would be
[16:23] <fta> hmm, the 1st part is now an attachment, bad
[16:23] <pace_t_zulu> fta, what is it you do for your *real* job?
[16:23] <asac> like: "what was changed since yesterdays build:"
[16:23] <pace_t_zulu> i work in a neuroscience lab
[16:23] <asac> "ubuntu: ..."
[16:23] <asac> upstream: ...
[16:24] <fta> pace_t_zulu, i'm an engineer. but i don't talk much about my real life on irc
[16:25] <pace_t_zulu> i studied electrical engineering in school
[16:25] <fta> asac, for moz and chromium, the upstream changelogs are too big to fit in a summary :P
[16:25] <pace_t_zulu> fta: why is it you don't talk much about your real life on irc?
[16:26] <fta> pace_t_zulu, well, private life
[16:26] <pace_t_zulu> fta, right
[16:34] <asac> fta: i really like the idea of using mime parts
[16:34] <asac> like: 1. summary
[16:34] <asac> 2. changes
[16:34] <asac> 3. log
[16:36] <fta> asac, yep, so far, i have 1/ summary, 2/ update (the tarball part), 3/ sync (the merge & dput parts) and 4/ tarball clean-up
[16:36] <fta> i should probably split 2 and 3 per package, it's too big for umd and ucd
[16:37] <asac> fta: yeah. having the hg log and bzr logs in there would still be nice ;)
[16:37] <asac> lik in 1a. changes
[16:38] <asac> ok verified that 1.9.3+3.7 also build with in-source nss
[16:38] <asac> nice
[16:39] <asac> fta: we really need 3.0 dailies (just firefox not xulrunner)
[16:39] <asac> everything < karmic is currently in a state with 3.0 and 3.5 fighitng over being the default
[16:39] <asac> imo firefox 3.0 should be small enough to just include in the bot
[16:40] <asac> is 3.0 ready for dailies?
[16:40] <fta> yep, but ff3 is in cvs, and it doesn't support the local branch feature (yet)
[16:41] <asac> is that a problem?
[16:42] <fta> i 1st introduced that local branch thing in m-d for hg, but it's half broken, and it's not implemented for cvs
[16:42] <asac> fta: i think weekly would be enough
[16:42] <asac> its just important to be always higher than what is in real archive
[16:42] <asac> e.g. one upload for each security update
[16:43] <asac> let me know if we need LOCAL_BRANCH first
[16:43] <fta> it's not a bandwidth/cpu/size problem, dailies are fine. it's more that i want those to be in a consistent state
[16:43] <fta> so yes, i want LOCAL_BRANCH
[16:43] <asac> yeah. but ffox 3.0 is a special case
[16:43] <asac> we want that just to unbreak
[16:44] <asac> not really because we want dailies from 1.9 branch
[16:44] <fta> no special case ;) they always create troubles at some point
[16:44] <asac> its a good corner case for your bot
[16:44] <asac> as long as its supposed to work without LOCAL_BRANCH ;)
[16:45] <asac> ... its better to have a use case for that :)
[16:45] <asac> let me know
[16:47] <fta> gwibber doesn't have a local branch, i don't mind, it's really small and bzr is not verbose, so logs also small
[17:05] <fta> asac, uh? Rejected: xulrunner-1.9.1_1.9.1.1~hg20090903r26325+nobinonly-0ubuntu2~umd1.dsc: Version older than that in the archive. 1.9.1.1~hg20090903r26325+nobinonly-0ubuntu2~umd1 <= 1.9.1.4~hg20090902r26316+nobinonly-0ubuntu2~umd1
[17:06] <asac> 1.9.1.1
[17:07] <asac> not sure howthat can happen
[17:07] <asac> is the version info busted=
[17:07] <asac> ?
[17:14] <fta> asac, http://paste.ubuntu.com/264506/
[17:18] <fta> asac, got it
[17:18] <fta> fta@cube:/data/bot/upstream/mozilla-1.9.1 $ hg cat -r 26325 browser/config/version.txt
[17:18] <fta> 3.5.1pre
[17:19] <fta> asac, the tip of the mozilla-1.9.1 branch is the seamonkey tag containing an old xul :P
[17:19] <fta> damn, i can't blame reed, he's not here
[17:22] <asac> urgh
[17:22] <asac> go into #developers on irc.mozilla.org
[17:22] <asac> sounds bad enough to rant there
[17:24] <fta> i'm no longer on that network
[17:24] <fta> http://code.google.com/p/chromium/issues/detail?id=18113  hmm
[17:24] <asac> i just think you can better explain than me
[17:25] <asac> 26325
[17:25] <asac> what is that revision?
[17:26] <fta> hg clone ...; hg log -r-1; hg update -r26325 => bingo
[17:26] <fta> the tip
[17:26] <asac> why do you need the tip?
[17:27] <asac> sorry ... stupid questions i guess
[17:28] <fta> to have an atomic tarball, i 1st get the rev-id of tip, and later on, i update to that rev-id
[17:28] <fta> more commits could arrive in between, i don't want them
[17:28] <fta> as i already figured out the package version for that rev
[17:29] <asac> what is -r-1 ?
[17:33] <asac> 18:32 < bhearsum> seamonkey did a 1.9.1 release, which makes tip on a relbranch
[17:33] <asac> 18:32 < asac> we rely on the tip somewhat
[17:33] <asac> 18:32 < bhearsum> you should rely on 'default'
[17:33] <asac> 18:32 < bhearsum> tip is not guaranteed to be on the default branch
[17:33] <asac> fta: ^^
[17:35] <asac> http://paste.ubuntu.com/264506/
[17:35] <asac> there is nothing about 1.9.1.1 in that paste
[17:37] <fta> asac, http://paste.ubuntu.com/264525/ then
[17:37] <asac> thx
[17:37] <asac> fta: so use default instead of tip
[17:38] <fta> well, the hg log -r 26325 should be -r -1
[17:39] <fta> asac, i don't specify tip or default or anything, i let hg choose, so the default is tip..  o_O
[17:40] <asac> fta: i think he means that there is a "default" tag/revision or something
[17:42] <fta> hmmmm, iirc, mozclient does use -r -1 to get the rev id, but wget .../pushlog or something like that
[18:37] <fta> kenvandine, would it be difficult to re-add the avatar cache? it's really annoying to see everything disappear at each refresh and slowly coming back
[18:37] <kenvandine> it is coming
[18:37] <kenvandine> just a little busted now
[18:39] <fta> ok
[18:57] <fta> SEAMONKEY_2_0b2_RELEASE; lol 2 beta in 2 hours?
[19:22] <fta> asac, ff trunk is crashing when viewing a video (totem plugin)
[20:36] <fta> asac, i tried with a bzr log in the summary, it's too much, i want the summary to stay readable in one glance. there's already a bzr diff in the merge logs
[21:21] <BUGabundo> boas
[21:22] <BUGabundo> fta: FF3.7 acting weird
[21:22] <BUGabundo> keeps opening in something that looks like safemode
[21:22] <BUGabundo> not a single addon is enabled
[21:57] <fta> BUGabundo: wfm
[21:57] <BUGabundo> :(
[21:57] <BUGabundo> totally broken for me
[21:57] <BUGabundo> re-started it already 4 times
[21:58] <fta> asac, the cdbs issue is it uses python 2.6 stuff now, hardy and intrepid have 2.5
[21:58] <fta> BUGabundo, started today?
[21:59] <BUGabundo> fta started on this boot
[21:59] <BUGabundo> was working ok All day
[22:00] <fta> boo, etckeeper borken for me
[22:26] <BUGabundo> fta douh! ff was running in background
[22:27] <BUGabundo> so even if I closed it , it remaind running
[22:27] <BUGabundo> killed all 3 pids
[22:27] <BUGabundo> testing again
[22:28] <BUGabundo> WIN
[22:28] <BUGabundo> now it works
[22:32] <fta> good