[00:00] <[reed]> jemalloc
[00:00] <[reed]> jason evans
[00:00] <[reed]> :p
[00:00] <asac> fta: can you please check if epiphany crashes as well
[00:01] <asac> thats important to know. if it does there is no way to put this into libxul
[00:12] <asac> [reed]: commented (with some uncertainty) - well bugzilla is still processing my submit :)
[00:12] <asac> something going on?
[00:14] <[reed]> hmm, go back and submit again?
[00:14] <asac> i cannot even open https://bugzilla.mozilla.org/show_bug.cgi?id=423334
[00:14] <asac> anymore
[00:14] <asac> [reed]: ?
[00:15] <[reed]> oh, looks like server problems
[00:15] <asac> yeah :)
[00:16] <asac> [reed]: http://paste.ubuntu.com/5849/
[00:16] <asac> my comment
[00:16] <asac> i go to bed in a minute or tw
[00:16] <asac> o
[00:16] <asac> have meeting in about 6h
[00:17] <[reed]> I'll post your comment if bugzilla doesn't come back in a few
[00:17] <asac> thanks
[00:28] <fta> well, my build failed:
[00:28] <fta> http://paste.ubuntu.com/5850/
[00:28] <fta> it's not related
[00:29] <[reed]> cvs up
[00:29] <[reed]> I think that got fixed
[00:29] <fta> yes, saw a few bustages earlier
[00:29] <fta> but it's 1:30am for me
[03:17] <acesfull9> does anyone know the proper way to create a icalendar feed so that it can be imported as a remote calendar in sunbird
[03:18] <acesfull9> I am using php to generate it, and I can download it and import it just fine, but I want to be able to subscribe to it remotely
[03:18] <acesfull9> I set content-type: text/calendar but got no luck, I get an error
[03:19] <acesfull9> the wierd thing is if I download it locally and import it, it works just fine
[07:00] <asac> fta: there?
[07:00] <asac> fta: so without the static patch things work well?
[07:01] <asac> fta: i have to know that, so i know if its ok for us to have jemalloc at all
[07:01] <asac> (e.g. is backing out the static patch good enough)
[07:01] <asac> please test epiphany as well
[07:02] <asac> thanks a lot
[07:55] <asac> fta_: if it works, can you please try to rename the xulrunner directory (and fix the system.conf obviously) ... to see if firefox would still be able to load jemalloc library
[07:56] <asac> fta_: i doubt that works and thats why i would vote to not use jemalloc at all for the time being
[07:56] <asac> but i need verification for that ... if you have a package with the backed out patch i can test that as well
[09:03] <fta> hi
[09:03] <fta> asac, as i said, trunk works when i revert that patch
[09:04] <fta> see the 2 .head branches i've just pushed
[09:04] <fta> epy works too
[09:46] <asac> fta: well i know that it works without that
[09:46] <asac> question is if it works as well if you rename the xul dir
[09:46] <asac> (without respinning)
[09:47] <asac> fta: so did you push latest trunk to PPA? or do i need to do a rebuild here?
[09:53] <asac> fta: mozclient is broken here ... get-orig-source DEBIAN_DATE=... doesn't work
[09:54] <asac> the date is properly transformed for checkout of client.mk
[09:54] <asac> but not for make -f client.mk checkout
[09:55] <asac> there is a bug
[09:56] <asac> k found it
[09:59] <asac> now it fails to get the modules
[10:00] <asac> http://paste.ubuntu.com/5861/
[10:05] <asac> yeah ... mozilla-devscripts is completely borked right now
[10:08] <asac> even without date i get: http://paste.ubuntu.com/5862/
[10:08] <asac> thats with 0.05
[10:08] <asac> 0.06 is worse ... latest branch is the same as 0.05
[10:10] <asac> strange ... is moz cvs broken?
[10:11] <asac> [reed]: wake up ... big big issue with CVS :) ... http://paste.ubuntu.com/5863/
[10:12] <asac> [reed]: ok. i think there are plenty of people on it for now
[10:12] <asac> :)
[10:13] <asac> i guess its time to get my cvs account
[10:17]  * asac doing breakfast
[12:42] <asac> cvs is still broken
[12:42] <asac> wth
[12:52] <asac> mozilla bug 423835
[12:52] <asac> sigh
[12:52] <asac> *sigh*
[12:52] <ubotu> Mozilla bug 423835 in Server Operations ""cannot find module" errors at checkout from cvs-mirror" [Critical,New] http://bugzilla.mozilla.org/show_bug.cgi?id=423835
[13:45] <[reed]> the sysadmins are trying to fix major problems from last night's switch failure
[13:47] <asac> [reed]: thx. switch failure?
[13:47] <asac> what does that mean?
[13:47] <asac> is it still a network/routing issue?
[13:48] <jetsaredim> asac: uploaded useragentswitcher extension last night
[13:48] <asac> jetsaredim: great. i think i will do the upload batch if you have finished webdeveloper :)
[13:49] <asac> or is that ready as well?
[13:49] <jetsaredim> can't figure it out
[13:49] <jetsaredim> was going to ask you to take a look at my branch
[13:49] <jetsaredim> for some reason it's not calling the build command (ant) during debuild
[13:49] <asac> show :)
[13:49] <jetsaredim> I'm sure I've done something wrong, but not sure what
[13:49] <asac> url?
[13:50] <jetsaredim> http://bazaar.launchpad.net/~jetsaredim/firefox-extensions/firefox-webdeveloper.ubuntu/annotate/jgreenwa%40d620-20080319110706-akcupz1vlllaxpff?file_id=rules-20080318131529-7rzcyz4htw13mt6r-32
[13:50] <jetsaredim> pretty much the identical rules file to what is in useragentswitcher and that one works fine
[13:53] <jetsaredim> and if I just run "ant" from the top of that tree - it works like a champ
[13:55] <asac> does userswitcher use ant as well?
[13:55] <jetsaredim> yea
[13:56] <jetsaredim> http://bazaar.launchpad.net/~jetsaredim/firefox-extensions/useragentswitcher.ubtuntu/annotate/jgreenwa%40d620-20080319044826-00d0v66vnmtjaazq?file_id=rules-20080319034613-dcsqz3umdthkvygg-6
[13:56] <asac> jetsaredim: ok i see
[13:57] <asac> the EXTENSION_PKG must be the _binary_ package name that will ship the extension. not the source package
[13:57] <asac> that should fix it
[13:57] <asac> e.g. firefox-webdeveloper
[13:57] <jetsaredim> in control?
[13:58] <asac> e.g. in xpi.mk its hooked in like:
[13:58] <asac> build/$(MOZ_EXTENSION_PKG)::
[13:58] <asac> ifneq (,$(MOZ_XPI_BUILD_COMMAND)) $(MOZ_XPI_BUILD_COMMAND)
[13:58] <asac> endif
[13:58] <asac> build/webdeveloper ... will never be run by cdbs
[13:58] <jetsaredim> o in rules
[13:58] <jetsaredim> hmm
[13:58] <asac> only build/firefox-webdeveloper
[13:58] <asac> youll figure
[13:58] <jetsaredim> ok
[13:58] <jetsaredim> i'll play around with it
[13:58] <asac> there is no EXTENSION_PKG in control
[13:59] <asac> i will try to bail out in xpi.mk if a package not matching any binary package is used
[14:00] <asac> jetsaredim: in xpi.mk the documentation is accurate:
[14:00] <asac> #        MOZ_EXTENSION_PKG (MANDATORY):
[14:00] <asac> #               define the binary package name used to ship this xpi
[14:00] <asac> good
[14:01] <jetsaredim> ok - that seems better
[14:02] <asac> :)
[14:02] <asac> does it work now?
[14:03] <asac> jetsaredim: you imported the complete package into the .upstream branch
[14:03] <asac> thats wrong
[14:03] <asac> just the orig.tar.gz
[14:03] <jetsaredim> does it really matter?
[14:03] <asac> yes
[14:03] <jetsaredim> since I ditched it and replaced it with the new tree
[14:03] <asac> otherwise the upstream doesn't make sense
[14:03] <asac> it matters in any case
[14:03] <asac> the current .upstream branch has commits for debian/
[14:04] <asac> importing the current package helps you to learn the procedure
[14:04] <asac> though not mandatory
[14:04] <asac> but still the .upstream branch must not contain any debian/ directory :)
[14:05] <asac> jetsaredim: i don't see that you replaced the .upstream code with new files yet
[14:05] <asac> at least thats not in the log
[14:05] <asac> https://code.edge.launchpad.net/~jetsaredim/firefox-extensions/firefox-webdeveloper.upstream
[14:05] <asac> 1. By  Jared Greenwald <jgreenwa@d620>   on 2008-03-18
[14:05] <asac> * import of existing package
[14:05] <jetsaredim> i made a .ubuntu branch
[14:05] <asac> thats good
[14:05] <asac> yes the ubuntu branch should never receive new upstream files
[14:05] <asac> only through merge from .upstream branch
[14:05] <jetsaredim> awesome
[14:06] <asac> jetsaredim: i don't see any new files in log of .ubuntu branch as well
[14:06] <asac> jetsaredim: i think you accidentially pushed the .ubuntu branch to .upstream
[14:06] <asac> you can uncommit till you are at revision 1 again and push --overwrite to .upstream
[14:07] <asac> but still i am not sure where you upgraded the upstream sources ... if you did that at all
[14:07] <jetsaredim> um
[14:07] <asac> so ... un .upstream branch you would have 2 commits
[14:07] <asac> 1. import existing upstream (v. XXXX) <- please name the version here
[14:07] <asac> 2. upgrade to new upstream (v. XXXX) <-
[14:08] <asac> the ubuntu branch would get
[14:08] <asac> bzr branch -r 1 /path/to/upstream xxx.ubuntu
[14:08] <asac> revision 2. import debian/ from packaging (version XXX)
[14:08] <asac> either you fix build system then or do it after upstream merge
[14:08] <asac> lets assume you fix it now
[14:09] <asac> 3. fix build system to make use of xpi.mk and add build-depends on mozilla-devscripts accordingly
[14:09] <asac> 4. merge new upstream sources from .upstream branch (v. XXX)
[14:09] <asac> (revision 4 you are doing like:)
[14:09] <asac> bzr merge /path/to/upstream/branch
[14:09] <asac> while inside the .ubuntu branch
[14:09] <asac> and then just bzr commit
[14:10] <jetsaredim> why would a merge be necessary since I would have branched after importing the new sources
[14:10] <asac> jetsaredim: you branched after revision 1 (current package)
[14:10] <asac> so you need to merge revision 2 (new upstream)
[14:11] <jetsaredim> ok - so when you say existing upstream - you mean the current package minus the debian dir?
[14:11] <asac> jetsaredim: the current orig.tar.gz
[14:11] <asac> nothing more
[14:11] <jetsaredim> expanded?
[14:11] <asac> there might be differences outside the debian/ dir in the diff.gz
[14:11] <asac> so minus debian/ dir is not accurate
[14:12] <asac> yes of course
[14:12] <asac> makes sense?
[14:12] <asac> (i mean in general)
[14:12] <jetsaredim> in general
[14:12] <jetsaredim> i think
[14:13] <jetsaredim> i think I'll just blow away the bzr branches and start over
[14:13] <asac> as you wish ... save the current debian/ dir so you can use that once you have arrived at that stage :)
[14:13] <jetsaredim> right
[14:13] <jetsaredim> and I modified the build.xml file too
[14:14] <asac> yes. that only goes to .ubuntu branch
[14:14] <jetsaredim> right
[14:14] <asac> thats why importing debian package minus debian/ dir is not .upstream
[14:14] <asac> only .orig.tar.gz should be upstream
[14:15] <asac> i don't want to be picky about the exact procedure. i only care the in the end .upstream has the pure upstream sources. and .ubuntu is based on that branch
[14:16] <asac> i just think that after doing this once you will be able to use that easily
[14:16] <jetsaredim> sure you do ;)
[14:18] <asac> jetsaredim: i see that you have a wierd dupe branch :) ... ~jetsaredim/firefox-extensions/firefox-webdeveloper.ubtuntu
[14:18] <asac> read "ubtuntu" :)
[14:19] <jetsaredim> heh
[14:19] <asac> ~jetsaredim/firefox-extensions/firefox-webdeveloper.ubuntu exists as well ... so i think its a glitch :)
[14:19] <jetsaredim> yea
[14:19] <jetsaredim> i do that all the time when typing ubuntu
[14:19] <asac> jetsaredim: yeah. bzr will remember where you initially pushed to
[14:19] <asac> so you just need to do it once
[14:19] <asac> after that just bzr push should be enough
[14:20] <asac> jetsaredim: you can see where it would pull/merge and push to when running bzr info
[14:20] <jetsaredim> crap - i think i just nuked the useragentswitcher.ubuntu branch
[14:21] <asac> jetsaredim: yes ... if you still have it on your system you don't need to bother
[14:21] <asac> you can just push it again
[14:22] <jetsaredim> that would be convenient wouldn't ot
[14:22] <jetsaredim> *it
[14:22] <jetsaredim> well - at least I built the new package and can recover it from there
[14:22] <asac> do you still have it on your disc?
[14:23] <asac> yes ... you could just branch from .upstream and apply the .diff.gz
[14:23] <jetsaredim> yea
[14:37] <jetsaredim> asac: better...? https://code.edge.launchpad.net/~jetsaredim/firefox-extensions/firefox-webdeveloper.upstream
[14:37] <asac> the comment looks good
[14:38] <asac> how did you do it? like i said: rm -rf * .. and then extract new upstream source and run bzr add .
[14:38] <asac> ?
[14:38] <jetsaredim> yep
[14:38] <asac> yes great
[14:38] <asac> now branch the initial revision to an .ubuntu branch
[14:38] <asac> apply the current .diff.gz
[14:38] <asac> (as current package)
[14:38] <jetsaredim> wait - what?
[14:39] <jetsaredim> what do you mean by "branch the initial version"?
[14:39] <asac> the idea is to create a .ubuntu branch that has the initial packaging
[14:39] <asac> that should be done on revision 1 of course
[14:39] <jetsaredim> ok
[14:39] <asac> so bzr branch -r 1 /path/to/upstream ...ubuntu
[14:39] <asac> then apply diff.gz
[14:39] <asac> commit that as "* import packaging as of XXXX-0ubuntu1"!
[14:40] <asac> or something
[14:40] <asac> once that is done you can merge the other revision over by just running bzr merge /path/to/upstream
[14:40] <asac> bump the changelog
[14:40] <asac> fix the packaging ... and so on
[14:40] <asac> :)
[14:45] <jetsaredim> ok - so now I've got the upstream and ubuntu
[14:45] <jetsaredim> upstream is current - ubuntu is old but has packaging
[14:45] <jetsaredim> now I merge?
[14:46] <jetsaredim> shoot
[14:46] <asac> yeah
[14:46] <jetsaredim> something got munged
[14:46] <asac> you go to .ubuntu
[14:46] <asac> bzr merge /path/to/upstream
[14:47] <asac> what happened?
[14:47] <asac> you can return to last committed state by running bzr revert
[14:47] <jetsaredim> when I applied the diff it just put the files that should go into the debian dir at the top of the tree
[14:47] <asac> yes
[14:47] <asac> revision 2 most likely?
[14:47] <jetsaredim> i suppose I can just create the dir and move them in
[14:47] <jetsaredim> yea
[14:47] <asac> he?
[14:48] <asac> jetsaredim: maybe retry to apply the diff
[14:48] <jetsaredim> i have things like control and rules at top of tree
[14:48] <asac> if you are in the branch you run
[14:48] <jetsaredim> patch < patchfile
[14:48] <asac> gunzip -c /path/to/diff.gz  | patch -p1
[14:48] <jetsaredim> ah p1
[14:48] <asac> yes
[14:48] <jetsaredim> that's prolly the problem
[14:48] <asac> then you most likely (if there are no conflicts) you run bzr add .
[14:49] <jetsaredim> yea
[14:49] <asac> and commit that saying "packaging for 1.0.5-0ubuntuX"
[14:49] <asac> or something
[14:49] <jetsaredim> i had done that, but like i said the thing got fuxed
[14:49] <jetsaredim> how do I roolback a revision?
[14:49] <jetsaredim> actually - i can just branch r1
[14:50] <asac> jetsaredim: what got committed?
[14:50] <asac> you can bzr uncommit
[14:50] <asac> bzr revert
[14:50] <asac> that should bring you to the revision below
[14:50] <asac> bzr ensure with bzr status that you don't have any unknown files
[14:51] <asac> otherwise you might add them accidentially when you commit next time
[14:51] <asac> jetsaredim: but remember that bzr uncommit is evil and should usually _never_ be done for branches already pushed to a remote place
[14:51] <asac> you can use it for local reshuffeling of changes though
[14:51] <jetsaredim> right - i already pushed it
[14:51] <asac> jetsaredim: well ... in this case you can redo
[14:52] <jetsaredim> was thinking that I could branch r1 re-apply the patch and then push
[14:52] <asac> its like an excersize
[14:52] <asac> and nobody is currently depending on it ... just "evil as a general rule"
[14:52] <asac> jetsaredim: well rebranching revision 1 is similar to uncommit from the evilness ... do what you like more
[14:52] <asac> it doesn't matter in this case
[14:59] <jetsaredim> is there something magic that happens during the merge?
[14:59] <jetsaredim> because the dev changed some of the directory structure and it seems completely different
[14:59] <asac> he?
[14:59] <asac> whats different?
[15:00] <asac> please do a bzr diff
[15:00] <asac> and show me the output
[15:00] <asac> and bzr status
[15:01] <asac> jetsaredim: is the new directory structure wrong?
[15:01] <jetsaredim> no
[15:01] <jetsaredim> the old dir structure is
[15:01] <jetsaredim> they work for the package they are with
[15:02] <jetsaredim> the old works with the old extension - new with the new extension
[15:02] <asac> so why do you see a problem?
[15:03] <asac> jetsaredim: bzr could track moves, but it doesn't know that things got moved
[15:03] <asac> i don't think that there should be a problem
[15:04] <jetsaredim> is the merge going to get rid of all of the old files?
[15:04] <asac> jetsaredim: yes. if they are removed from the upstream branch it will (unless you have modified them ... then you would get conflicts)
[15:04] <asac> jetsaredim: bzr status should yield something like this:
[15:04] <asac> http://paste.ubuntu.com/5873/
[15:04] <asac> you see which files where removed
[15:04] <asac> which added
[15:04] <asac> and which modified
[15:05] <asac> (you would also see meta info at the bottom about the merge)
[15:08] <jetsaredim> is there a way to resolve conflicts?
[15:09] <asac> what kind of conflicts do you get?
[15:09] <jetsaredim> not sure
[15:09] <asac> there shouldn't be any
[15:09] <jetsaredim> which files are which?
[15:09] <asac> he?
[15:09] <jetsaredim> there is BASE, OTHER and THIS?
[15:09] <asac> show me bzr st
[15:09] <asac> where do you get the conflict?
[15:10] <asac> BASE is probably the current file on your branch ... OTHER the onmodified file from the other branch and THIS the result of the merge
[15:10] <jetsaredim> http://paste.ubuntu.com/5877/
[15:11] <asac> jetsaredim: ok. so the original debian package indeed hat the build.xml touched
[15:11] <asac> jetsaredim: you can open build.xml and search for the conflict markers
[15:11] <asac> "<<<<<<<<"
[15:11] <asac> [15:11] <asac> >>>>>>
[15:11] <asac> resolve them :)
[15:11] <jetsaredim> why not just bring in the OTHER?
[15:12] <jetsaredim> since this is just a temporary branch
[15:12] <asac> because then you loose the changes in build.xml. its better to review manually
[15:12] <asac> further there might be other parts sucessfully merged in already
[15:13] <asac> in this case it might turn out that OTHER would have been right, but manually looking is required as a general rule to not drop things by mistake
[15:13] <asac> jetsaredim: if the changes conflicting tried to do something similar you have to do for the new packaging, you can also do it in this step
[15:20] <jetsaredim> looks like he just re-wrote the build.xml file for the most part - there's like 85 changes
[15:21] <jetsaredim> he did do similar stuff to the build file that I had to do
[15:23] <jetsaredim> fyi - i asked the bzr folks and they said i can just plaster whatever over and it won't screw anything up from vcs point of view
[15:25] <jetsaredim> so I'm going to plaster on my patched version of the new build.xml
[15:36] <asac> jetsaredim: yes
[15:36] <asac> thats ok
[15:36] <asac> jetsaredim: but if you do so please document that in commit log
[15:36] <asac> jetsaredim: and add an initial changelog bump in the same commit using
[15:36] <asac> dch -v NEWPACKAGE-0ubuntuversion -D UNRELEASED
[15:37] <asac> you can do that in a second commit as well
[15:42] <asac> jetsaredim: all going well?
[15:42] <asac> :)
[15:44] <jetsaredim> I think so
[15:44] <jetsaredim> I'm just pushing a new version
[15:45] <jetsaredim> with the new build.xml and new debian/* files
[15:47] <asac> good
[15:47] <asac> does it build?
[15:48] <jetsaredim> ok - so now I have a tree that should be the 1.1.5 source + my changes to the debian/* files and build.xml
[15:48] <jetsaredim> lemmie check
[15:49]  * jetsaredim screams obscenities at the screen
[15:49] <jetsaredim> dh_install -pfirefox-webdeveloper temp-xpi-NQFL5237/chrome temp-xpi-NQFL5237/chrome.manifest temp-xpi-NQFL5237/install.js temp-xpi-NQFL5237/install.rdf temp-xpi-NQFL5237/license.txt /usr/share/firefox-webdeveloper
[15:49] <jetsaredim> cp: cannot stat `./chrome': No such file or directory
[15:49] <jetsaredim> sry for the paste
[15:50] <asac> jetsaredim: there is something wierd
[15:50] <jetsaredim> asac: you're telling me?
[15:51] <jetsaredim> thing is that I had it all working
[15:51] <asac> jetsaredim: no .. i mean .. what happened to the original debian/rules
[15:51] <jetsaredim> still have the dir from that around - lemmie see what is different
[15:51] <asac> aeh sorry ... the changelog
[15:51] <asac> i look at the commit revision 4
[15:51] <asac> there is a complete new changelog in
[15:51] <asac> isn't that supposed to be in revision 2 already?
[15:52] <jetsaredim> uh - i suppose
[15:52]  * jetsaredim goes back to square one...
[15:54] <asac> jetsaredim: ah ... you forgot to bzr add
[15:54] <asac> after diff.gz patch :)
[15:55] <jetsaredim> i coulda swore I did
[15:55] <asac> ;)
[15:58] <jetsaredim> this is a pain
[15:59] <asac> well :)
[15:59] <asac> learning by doing
[15:59] <asac> one doesn't do such mistakes often
[15:59] <asac> then things get efficient
[16:00] <asac> then they suddenly appear to be done by instinct :-D
[16:00] <jetsaredim> yea
[16:00] <jetsaredim> true
[16:00] <jetsaredim> not like i've never used vcs systems before
[16:01] <jetsaredim> making me feel like an amateur
[16:01] <jetsaredim> :)
[16:01] <jetsaredim> gotta run for lunch
[16:01] <jetsaredim> bbl
[16:02] <asac> well, but you must admit that bzr is quite comprehensible :)
[16:02] <asac> its just the procedures for debian packaging that are different ;)
[16:34] <fta2> asac, i have rendering issues on http://en.wikipedia.org/wiki/Biang
[16:34] <fta2> the [edit] on the right below each pictures are misplaced
[16:35] <fta2> and if you zoom several times, the background becomes black
[16:43]  * asac looking
[16:48] <asac> fta2: whats the problem? the edit links are all three next to each other slightly to the right
[16:49] <asac> how is it supposed to be (i can't remember)
[16:49] <asac> i don't see any edit for other pictures
[16:49] <asac> are those edit things related to the pictures at all?
[17:21] <fta2> asac, http://www.sofaraway.org/ubuntu/tmp/biang.png
[17:22] <asac> ok i had to fix the ip for cvs-mirror to get a cvs checkout going again
[17:22] <asac> fta2: yes, but from which elements are they?
[17:22] <asac> the one next to mnemonics looks ok
[17:23] <asac> ok its most likely for the paragraphs
[17:23] <asac> above
[17:23] <asac> summary + about the noodle and phonetic sub.
[17:23] <fta2> maybe yes
[17:23] <fta2> but this looks weird anyway
[17:24] <fta2> at least the 3 on the same line overwriting the text
[17:27] <fta2> leaving.. it's raining here, lots of fun with my e-bike on perspective.
[17:28] <asac> how are those implemented in html? floats?
[17:31] <fta2> donno, select the text and use view selection source
[17:31]  * fta2 gone
[17:32] <asac> jetsaredim: thats about right, yes.
[17:33] <asac> jetsaredim:  aber brnach you don't need to commit
[17:33] <asac> you don't need to push until you are finished either
[17:35] <asac> but thats all that you should fix besides the merge conflicts
[17:35] <asac> jetsaredim: ^^^
[17:44]  * asac jetsaredim well, nobody is perfect. nothing to bother about
[17:45] <asac> jetsaredim: just go ahead
[17:45]  * jetsaredim proceeds with caution
[17:46] <jetsaredim> I don't really need these firefox-webdeveloper.{dirs,links,install} do I?
[17:49] <asac> jetsaredim: no you don't need them
[17:59]  * asac off traveling
[20:12]  * jetsaredim uses pidgin
[20:16] <jetsaredim> asac: ok - so something I'm doing is not right
[20:17] <jetsaredim> cause I keep getting a fatal error during dh_install on debuild -b
[20:17] <asac> whats the problem?
[20:17] <jetsaredim> lemmie paste the output
[20:17] <asac> y
[20:17] <jetsaredim> http://paste.ubuntu.com/5900/
[20:17] <jetsaredim> that's just the end of the debuild -b, but the relevant part
[20:18] <asac> jetsaredim you still have any debhelper file in debian/ ?
[20:18] <asac> like *install ?
[20:18] <jetsaredim> o duh
[20:18] <asac> you need to drop all of them
[20:18] <asac> its all automatically handled now
[20:18] <asac> e.g. *install, *links *dirs
[20:19] <asac> bzr rm FILENAME :)
[20:20] <jetsaredim> ahh better
[20:21] <jetsaredim> now to update the changelog
[20:21] <asac> yes
[20:22] <jetsaredim> what was the example of the changelog you wanted me to follow again?
[20:23] <asac> jetsaredim: look firefox-3.0.head for instance
[20:23] <asac> or xulrunner-1.9.head
[20:23] <asac> (those are branch names)
[20:23] <asac> or look at the changelog of apt-get source xulrunner-1.9
[20:23] <asac> but looking at branch you can also see how we document during commit
[20:24] <asac> which is basically the same as in changelog
[20:31] <fta> damn, i have a corrupted oo file :(
[20:32] <jetsaredim> that sounds like a personal problem ;)
[20:33] <fta> it was fine up to yesterday
[20:37] <jetsaredim> asac: ok - this is looking much much better
[20:38] <jetsaredim> though this file list is looking odd... http://paste.ubuntu.com/5902/
[20:38] <asac> jetsaredim: yes indeed
[20:38] <asac> does it work
[20:38] <jetsaredim> seems to
[20:38] <jetsaredim> I'm no webdeveloper expert user
[20:39] <jetsaredim> but I suddenly have the webdeveloper toolbar
[20:39] <jetsaredim> so i'm guessing that's a good sign
[20:40] <jetsaredim> it could be part of the xpi
[20:40] <jetsaredim> cause useragentswitcher looks similar
[20:42] <asac> yeah ... thats good enough i guess
[20:43] <jetsaredim> going to push it and then upload to my ppa
[20:44] <asac> yep
[20:45] <[reed]> asac / fta: check #developers on moznet
[20:45] <[reed]> talking about the --with-libxul-sdk jemalloc crash bug
[20:49] <fta> [reed], what did i miss ?
[20:49] <[reed]> fta: they don't want to consider it a b5 blocker
[20:50] <[reed]> and I'm trying to change their mind
[20:51] <fta> oh
[20:53] <fta> [reed], should I let you handle this or do you need me to say something ?
[20:53] <[reed]> fta: please speak up
[21:05] <jetsaredim> asac: to reconstitute that useragentswitcher tree I should be able to just use the tree from an apt-get source, right?
[21:05] <asac> jetsaredim: no idea what you are planning to do
[21:06] <jetsaredim> i accidentally nuked the useragentswitcher.ubuntu tree
[21:06] <jetsaredim> so I was trying to re-constitute it
[21:07] <jetsaredim> since I already built the package and its in my ppa
[21:07] <fta> [reed], why a block on 418016 ? 418016 has been committed/fixed
[21:07] <[reed]> because that's how we mark regressions
[21:07] <[reed]> they block the bug that caused them
[21:08] <fta> and btw, i don't see a discussion there. it's no, b5 is not concerned by -with-libxul-sdk against we need it
[21:08] <[reed]> er, what?
[21:12] <[reed]> asac / fta: can one of you post a mozconfig?
[21:12] <[reed]> for firefox
[21:12] <[reed]> that includes --with-libxul-sdk
[21:12] <fta> we don't really use a mozconfig but i can post either our configure lines or about:buildconfig
[21:14] <[reed]> do you --enable-libxul ?
[21:22] <jetsaredim> asac: I'll have to figure this out later
[21:30] <fta> [reed], posted
[21:30] <[reed]> fta: where?
[21:30] <fta> bug
[21:30] <[reed]> er
[21:30] <[reed]> I meant let me see
[21:30] <[reed]> lo
[21:30] <[reed]> lol
[21:31] <fta> it's public anyway
[21:31] <[reed]> k
[21:31] <fta> anyone could dl our source package or read our bzr branches
[21:32] <[reed]> patch in bug
[21:32] <[reed]> try it?
[21:33] <[reed]> you'll need to reapply the jemalloc in libxul patch ;)
[21:33] <asac> hey hey ... calm down :)
[21:33] <asac> i am sure its not working with-libxul-sdk
[21:33] <asac> and bsdsmedberg things so too
[21:34] <asac> if it works for caillon then its his --enable-libxul flag (whcih conflicts with libxul-sdk)
[21:34] <asac> ... but that means that he is not using system xul ... another option would be that he uses some wierd linker tweaks
[21:34] <asac> like LD_PRELOAD ... and so on.
[21:34] <asac> but all that is not an option for me :)
[21:35] <asac> ok let me look in bug again
[21:35] <asac> no that doesn't make sense with-libxul-sdk
[21:35] <asac> oops
[21:35] <asac> backscrolled answer ;)
[21:36] <[reed]> ugh, fta
[21:36] <armin76> asac: fta: you guys are still using myspell? :P
[21:36] <[reed]> stop overwriting bug options!
[21:36] <fta> I did nothing at all except add a comment
[21:36] <[reed]> did you not get a "Mid-air" page ?
[21:36] <fta> got caught in mid air, yes
[21:37] <[reed]> yes, you don't go through the mid-airs
[21:37] <[reed]> heh
[21:37] <[reed]> you killed the blocking flag
[21:37] <[reed]> and two other things
[21:37] <armin76> lolz
[21:37] <fta> sorry
[21:37] <armin76> thats what happens when you aren't used to bugzilla :P
[21:38] <fta> bad bugzilla, it should ask me if i want to do that
[21:38] <asac> why would it
[21:38] <asac> if you change the form fields it changes it
[21:38] <fta> i didn't
[21:38] <armin76> and asac fails as well :P
[21:38] <asac> you did by accident
[21:38] <fta> ?
[21:38] <armin76> he didn't
[21:39] <armin76> he just had an old version of the bug page
[21:39] <fta> yes
[21:39] <asac> ok, whatever :)
[21:39] <armin76> fta: when you get a mid air collision, just go back with your browser, reload the page, and resubmit
[21:39]  * fta got shot in mid-air
[21:40] <asac> hehe
[21:41] <asac> so what was the bugid?
[21:42] <fta> https://bugzilla.mozilla.org/show_bug.cgi?id=423334
[21:42] <ubotu> Mozilla bug 423334 in XPCOM "crash at startup in [@ NS_CompareVersions] when using --with-libxul-sdk" [Critical,New]
[21:42] <asac> thx
[21:43] <asac> fta: ok will you take the patch instead of the drop?
[21:43] <asac> that looks good
[21:45] <fta> i can try it for sure
[21:46] <asac> yes, please do _with_ static jemalloc
[21:49] <armin76> what happened with mozilla bug 386904
[21:49] <armin76> its fixed or?
[21:49] <ubotu> Mozilla bug 386904 in Build Config "DIST_FILES and DIST_CHROME_FILES not implemented for install:: target in config/rules.mk" [Normal,Resolved: invalid] http://bugzilla.mozilla.org/show_bug.cgi?id=386904
[21:58] <fta> pulseaudio crashed, again
[22:51] <fta> asac, [reed], it crashes again
[22:51] <fta> same place
[22:53] <fta> asac, epiphany crashes too
[22:57] <asac> when does it crash?
[22:57] <asac> what did you do?
[22:57] <fta> asac, http://paste.ubuntu.com/5904/
[22:58] <asac> what did you do?
[22:58] <fta> as we just discussed, _with_ static jemalloc + the leak patch
[22:58] <asac> i don't know how the initial ephy crash looked like. get backtrace from firefox
[22:59] <asac> is it still in jemalloc
[22:59] <fta> hm hold on
[23:00] <fta> ff3, yes, same place
[23:00] <fta> http://paste.ubuntu.com/5905/
[23:01] <fta> crappy trace
[23:09] <asac> but wierd that it happens there at all
[23:11] <fta> not really, if i understand what bs said, the malloc is from system (because libxul has not been loaded yet) while the free is from jemalloc
[23:14] <asac> fta: yes thats clear. wierd that it happens there ;)
[23:14] <fta> why ?
[23:15] <asac> look at the function ... it allocates the bits it frees.
[23:15] <asac> libxul is not loaded in between allocation and freeing
[23:17] <asac> only thing that might be  is that the prototypes for version strings strduped are allocated differently. but can't see how that would break the free of the fresh strdups
[23:18] <asac> NS_CompareVersions(appData.minVersion, gToolkitVersion
[23:18] <asac> appData.minVersion is most likely libc malloced
[23:18] <asac> while gToolkitVersion might be jemalloc
[23:18] <asac> howver those are strduped
[23:19] <asac> so both should be allocated through the same mechanism thereafter
[23:20] <fta> maybe, my brain is too tired to tell
[23:20] <fta> i don't know if it's a greader bug or a xul regression but reading articles with the space key is no longer possible
[23:22] <fta> it used to jump to the next one, now it does more than one so it often skips the next
[23:22] <fta> in both prism and firefox
[23:23] <asac> i would bet on xul as the source
[23:24] <fta> I need a non gecko browser
[23:25] <fta> maybe I could give webkit a try
[23:25] <fta> [reed], what is litmus ?
[23:33] <[reed]> fta: litmus.mozilla.org
[23:34] <fta> thx