| [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:00 |
| asac | thats important to know. if it does there is no way to put this into libxul | 00:01 |
| asac | [reed]: commented (with some uncertainty) - well bugzilla is still processing my submit :) | 00:12 |
| asac | something going on? | 00:12 |
| [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:14 |
| [reed] | oh, looks like server problems | 00:15 |
| asac | yeah :) | 00:15 |
| 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:16 |
| [reed] | I'll post your comment if bugzilla doesn't come back in a few | 00:17 |
| asac | thanks | 00:17 |
| fta | well, my build failed: | 00:28 |
| fta | http://paste.ubuntu.com/5850/ | 00:28 |
| fta | it's not related | 00:28 |
| [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 | 00:29 |
| 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:17 |
| 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:18 |
| acesfull9 | the wierd thing is if I download it locally and import it, it works just fine | 03:19 |
| asac | fta: there? | 07:00 |
| asac | fta: so without the static patch things work well? | 07:00 |
| 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:01 |
| asac | thanks a lot | 07:02 |
| 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:55 |
| 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 | 07:56 |
| === fta_ is now known as fta | ||
| fta | hi | 09:03 |
| fta | asac, as i said, trunk works when i revert that patch | 09:03 |
| fta | see the 2 .head branches i've just pushed | 09:04 |
| fta | epy works too | 09:04 |
| 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:46 |
| asac | fta: so did you push latest trunk to PPA? or do i need to do a rebuild here? | 09:47 |
| asac | fta: mozclient is broken here ... get-orig-source DEBIAN_DATE=... doesn't work | 09:53 |
| asac | the date is properly transformed for checkout of client.mk | 09:54 |
| asac | but not for make -f client.mk checkout | 09:54 |
| asac | there is a bug | 09:55 |
| asac | k found it | 09:56 |
| asac | now it fails to get the modules | 09:59 |
| asac | http://paste.ubuntu.com/5861/ | 10:00 |
| asac | yeah ... mozilla-devscripts is completely borked right now | 10:05 |
| 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:08 |
| asac | strange ... is moz cvs broken? | 10:10 |
| asac | [reed]: wake up ... big big issue with CVS :) ... http://paste.ubuntu.com/5863/ | 10:11 |
| === Greenery_ is now known as Greenery | ||
| asac | [reed]: ok. i think there are plenty of people on it for now | 10:12 |
| asac | :) | 10:12 |
| asac | i guess its time to get my cvs account | 10:13 |
| * asac doing breakfast | 10:17 | |
| asac | cvs is still broken | 12:42 |
| asac | wth | 12:42 |
| 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 | 12:52 |
| [reed] | the sysadmins are trying to fix major problems from last night's switch failure | 13:45 |
| asac | [reed]: thx. switch failure? | 13:47 |
| asac | what does that mean? | 13:47 |
| asac | is it still a network/routing issue? | 13:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| jetsaredim | and if I just run "ant" from the top of that tree - it works like a champ | 13:53 |
| asac | does userswitcher use ant as well? | 13:55 |
| jetsaredim | yea | 13:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| asac | i will try to bail out in xpi.mk if a package not matching any binary package is used | 13:59 |
| 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:00 |
| jetsaredim | ok - that seems better | 14:01 |
| asac | :) | 14:02 |
| asac | does it work now? | 14:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| asac | i just think that after doing this once you will be able to use that easily | 14:16 |
| jetsaredim | sure you do ;) | 14:16 |
| asac | jetsaredim: i see that you have a wierd dupe branch :) ... ~jetsaredim/firefox-extensions/firefox-webdeveloper.ubtuntu | 14:18 |
| asac | read "ubtuntu" :) | 14:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| asac | yes ... you could just branch from .upstream and apply the .diff.gz | 14:23 |
| jetsaredim | yea | 14:23 |
| jetsaredim | asac: better...? https://code.edge.launchpad.net/~jetsaredim/firefox-extensions/firefox-webdeveloper.upstream | 14:37 |
| asac | the comment looks good | 14:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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? | 14:59 |
| asac | please do a bzr diff | 15:00 |
| asac | and show me the output | 15:00 |
| asac | and bzr status | 15:00 |
| 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:01 |
| jetsaredim | the old works with the old extension - new with the new extension | 15:02 |
| asac | so why do you see a problem? | 15:02 |
| 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:03 |
| 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:04 |
| asac | (you would also see meta info at the bottom about the merge) | 15:05 |
| jetsaredim | is there a way to resolve conflicts? | 15:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| jetsaredim | looks like he just re-wrote the build.xml file for the most part - there's like 85 changes | 15:20 |
| jetsaredim | he did do similar stuff to the build file that I had to do | 15:21 |
| 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:23 |
| jetsaredim | so I'm going to plaster on my patched version of the new build.xml | 15:25 |
| 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:36 |
| asac | you can do that in a second commit as well | 15:37 |
| asac | jetsaredim: all going well? | 15:42 |
| asac | :) | 15:42 |
| jetsaredim | I think so | 15:44 |
| jetsaredim | I'm just pushing a new version | 15:44 |
| jetsaredim | with the new build.xml and new debian/* files | 15:45 |
| asac | good | 15:47 |
| asac | does it build? | 15:47 |
| 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:48 |
| * 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:49 |
| asac | jetsaredim: there is something wierd | 15:50 |
| jetsaredim | asac: you're telling me? | 15:50 |
| 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:51 |
| jetsaredim | uh - i suppose | 15:52 |
| * jetsaredim goes back to square one... | 15:52 | |
| asac | jetsaredim: ah ... you forgot to bzr add | 15:54 |
| asac | after diff.gz patch :) | 15:54 |
| jetsaredim | i coulda swore I did | 15:55 |
| asac | ;) | 15:55 |
| jetsaredim | this is a pain | 15:58 |
| 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 | 15:59 |
| 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:00 |
| jetsaredim | making me feel like an amateur | 16:01 |
| jetsaredim | :) | 16:01 |
| jetsaredim | gotta run for lunch | 16:01 |
| jetsaredim | bbl | 16:01 |
| 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:02 |
| 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:34 |
| fta2 | and if you zoom several times, the background becomes black | 16:35 |
| * asac looking | 16:43 | |
| asac | fta2: whats the problem? the edit links are all three next to each other slightly to the right | 16:48 |
| 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? | 16:49 |
| fta2 | asac, http://www.sofaraway.org/ubuntu/tmp/biang.png | 17:21 |
| 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:22 |
| 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:23 |
| fta2 | at least the 3 on the same line overwriting the text | 17:24 |
| fta2 | leaving.. it's raining here, lots of fun with my e-bike on perspective. | 17:27 |
| asac | how are those implemented in html? floats? | 17:28 |
| fta2 | donno, select the text and use view selection source | 17:31 |
| * fta2 gone | 17:31 | |
| asac | jetsaredim: thats about right, yes. | 17:32 |
| 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:33 |
| asac | but thats all that you should fix besides the merge conflicts | 17:35 |
| asac | jetsaredim: ^^^ | 17:35 |
| * asac jetsaredim well, nobody is perfect. nothing to bother about | 17:44 | |
| asac | jetsaredim: just go ahead | 17:45 |
| * jetsaredim proceeds with caution | 17:45 | |
| jetsaredim | I don't really need these firefox-webdeveloper.{dirs,links,install} do I? | 17:46 |
| asac | jetsaredim: no you don't need them | 17:49 |
| * asac off traveling | 17:59 | |
| === dholbert is now known as dholbert_lunch | ||
| * jetsaredim uses pidgin | 20:12 | |
| jetsaredim | asac: ok - so something I'm doing is not right | 20:16 |
| 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:17 |
| 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:18 |
| asac | bzr rm FILENAME :) | 20:19 |
| jetsaredim | ahh better | 20:20 |
| jetsaredim | now to update the changelog | 20:21 |
| asac | yes | 20:21 |
| jetsaredim | what was the example of the changelog you wanted me to follow again? | 20:22 |
| 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:23 |
| asac | which is basically the same as in changelog | 20:24 |
| fta | damn, i have a corrupted oo file :( | 20:31 |
| jetsaredim | that sounds like a personal problem ;) | 20:32 |
| fta | it was fine up to yesterday | 20:33 |
| jetsaredim | asac: ok - this is looking much much better | 20:37 |
| 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:38 |
| jetsaredim | but I suddenly have the webdeveloper toolbar | 20:39 |
| jetsaredim | so i'm guessing that's a good sign | 20:39 |
| jetsaredim | it could be part of the xpi | 20:40 |
| jetsaredim | cause useragentswitcher looks similar | 20:40 |
| asac | yeah ... thats good enough i guess | 20:42 |
| jetsaredim | going to push it and then upload to my ppa | 20:43 |
| asac | yep | 20:44 |
| [reed] | asac / fta: check #developers on moznet | 20:45 |
| [reed] | talking about the --with-libxul-sdk jemalloc crash bug | 20:45 |
| fta | [reed], what did i miss ? | 20:49 |
| [reed] | fta: they don't want to consider it a b5 blocker | 20:49 |
| [reed] | and I'm trying to change their mind | 20:50 |
| fta | oh | 20:51 |
| fta | [reed], should I let you handle this or do you need me to say something ? | 20:53 |
| [reed] | fta: please speak up | 20:53 |
| 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:05 |
| jetsaredim | i accidentally nuked the useragentswitcher.ubuntu tree | 21:06 |
| jetsaredim | so I was trying to re-constitute it | 21:06 |
| 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:07 |
| 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:08 |
| [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:12 |
| [reed] | do you --enable-libxul ? | 21:14 |
| jetsaredim | asac: I'll have to figure this out later | 21:22 |
| 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:30 |
| fta | it's public anyway | 21:31 |
| [reed] | k | 21:31 |
| fta | anyone could dl our source package or read our bzr branches | 21:31 |
| [reed] | patch in bug | 21:32 |
| [reed] | try it? | 21:32 |
| [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:33 |
| 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:34 |
| 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:35 |
| [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:36 |
| [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:37 |
| 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:38 |
| 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:39 | |
| asac | hehe | 21:40 |
| asac | so what was the bugid? | 21:41 |
| 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:42 |
| asac | fta: ok will you take the patch instead of the drop? | 21:43 |
| asac | that looks good | 21:43 |
| fta | i can try it for sure | 21:45 |
| asac | yes, please do _with_ static jemalloc | 21:46 |
| 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:49 |
| fta | pulseaudio crashed, again | 21:58 |
| fta | asac, [reed], it crashes again | 22:51 |
| fta | same place | 22:51 |
| fta | asac, epiphany crashes too | 22:53 |
| asac | when does it crash? | 22:57 |
| asac | what did you do? | 22:57 |
| fta | asac, http://paste.ubuntu.com/5904/ | 22:57 |
| 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:58 |
| asac | is it still in jemalloc | 22:59 |
| fta | hm hold on | 22:59 |
| fta | ff3, yes, same place | 23:00 |
| fta | http://paste.ubuntu.com/5905/ | 23:00 |
| fta | crappy trace | 23:01 |
| asac | but wierd that it happens there at all | 23:09 |
| 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:11 |
| asac | fta: yes thats clear. wierd that it happens there ;) | 23:14 |
| fta | why ? | 23:14 |
| asac | look at the function ... it allocates the bits it frees. | 23:15 |
| asac | libxul is not loaded in between allocation and freeing | 23:15 |
| 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:17 |
| 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:18 |
| asac | so both should be allocated through the same mechanism thereafter | 23:19 |
| 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:20 |
| 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:22 |
| asac | i would bet on xul as the source | 23:23 |
| fta | I need a non gecko browser | 23:24 |
| fta | maybe I could give webkit a try | 23:25 |
| fta | [reed], what is litmus ? | 23:25 |
| [reed] | fta: litmus.mozilla.org | 23:33 |
| fta | thx | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
