[00:00] <[reed]> jemalloc [00:00] <[reed]> jason evans [00:00] <[reed]> :p [00:00] fta: can you please check if epiphany crashes as well [00:01] thats important to know. if it does there is no way to put this into libxul [00:12] [reed]: commented (with some uncertainty) - well bugzilla is still processing my submit :) [00:12] something going on? [00:14] <[reed]> hmm, go back and submit again? [00:14] i cannot even open https://bugzilla.mozilla.org/show_bug.cgi?id=423334 [00:14] anymore [00:14] [reed]: ? [00:15] <[reed]> oh, looks like server problems [00:15] yeah :) [00:16] [reed]: http://paste.ubuntu.com/5849/ [00:16] my comment [00:16] i go to bed in a minute or tw [00:16] o [00:16] have meeting in about 6h [00:17] <[reed]> I'll post your comment if bugzilla doesn't come back in a few [00:17] thanks [00:28] well, my build failed: [00:28] http://paste.ubuntu.com/5850/ [00:28] it's not related [00:29] <[reed]> cvs up [00:29] <[reed]> I think that got fixed [00:29] yes, saw a few bustages earlier [00:29] but it's 1:30am for me [03:17] 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] 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] I set content-type: text/calendar but got no luck, I get an error [03:19] the wierd thing is if I download it locally and import it, it works just fine [07:00] fta: there? [07:00] fta: so without the static patch things work well? [07:01] fta: i have to know that, so i know if its ok for us to have jemalloc at all [07:01] (e.g. is backing out the static patch good enough) [07:01] please test epiphany as well [07:02] thanks a lot [07:55] 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] fta_: i doubt that works and thats why i would vote to not use jemalloc at all for the time being [07:56] but i need verification for that ... if you have a package with the backed out patch i can test that as well === fta_ is now known as fta [09:03] hi [09:03] asac, as i said, trunk works when i revert that patch [09:04] see the 2 .head branches i've just pushed [09:04] epy works too [09:46] fta: well i know that it works without that [09:46] question is if it works as well if you rename the xul dir [09:46] (without respinning) [09:47] fta: so did you push latest trunk to PPA? or do i need to do a rebuild here? [09:53] fta: mozclient is broken here ... get-orig-source DEBIAN_DATE=... doesn't work [09:54] the date is properly transformed for checkout of client.mk [09:54] but not for make -f client.mk checkout [09:55] there is a bug [09:56] k found it [09:59] now it fails to get the modules [10:00] http://paste.ubuntu.com/5861/ [10:05] yeah ... mozilla-devscripts is completely borked right now [10:08] even without date i get: http://paste.ubuntu.com/5862/ [10:08] thats with 0.05 [10:08] 0.06 is worse ... latest branch is the same as 0.05 [10:10] strange ... is moz cvs broken? [10:11] [reed]: wake up ... big big issue with CVS :) ... http://paste.ubuntu.com/5863/ === Greenery_ is now known as Greenery [10:12] [reed]: ok. i think there are plenty of people on it for now [10:12] :) [10:13] i guess its time to get my cvs account [10:17] * asac doing breakfast [12:42] cvs is still broken [12:42] wth [12:52] mozilla bug 423835 [12:52] sigh [12:52] *sigh* [12:52] 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] [reed]: thx. switch failure? [13:47] what does that mean? [13:47] is it still a network/routing issue? [13:48] asac: uploaded useragentswitcher extension last night [13:48] jetsaredim: great. i think i will do the upload batch if you have finished webdeveloper :) [13:49] or is that ready as well? [13:49] can't figure it out [13:49] was going to ask you to take a look at my branch [13:49] for some reason it's not calling the build command (ant) during debuild [13:49] show :) [13:49] I'm sure I've done something wrong, but not sure what [13:49] url? [13:50] http://bazaar.launchpad.net/~jetsaredim/firefox-extensions/firefox-webdeveloper.ubuntu/annotate/jgreenwa%40d620-20080319110706-akcupz1vlllaxpff?file_id=rules-20080318131529-7rzcyz4htw13mt6r-32 [13:50] pretty much the identical rules file to what is in useragentswitcher and that one works fine [13:53] and if I just run "ant" from the top of that tree - it works like a champ [13:55] does userswitcher use ant as well? [13:55] yea [13:56] http://bazaar.launchpad.net/~jetsaredim/firefox-extensions/useragentswitcher.ubtuntu/annotate/jgreenwa%40d620-20080319044826-00d0v66vnmtjaazq?file_id=rules-20080319034613-dcsqz3umdthkvygg-6 [13:56] jetsaredim: ok i see [13:57] the EXTENSION_PKG must be the _binary_ package name that will ship the extension. not the source package [13:57] that should fix it [13:57] e.g. firefox-webdeveloper [13:57] in control? [13:58] e.g. in xpi.mk its hooked in like: [13:58] build/$(MOZ_EXTENSION_PKG):: [13:58] ifneq (,$(MOZ_XPI_BUILD_COMMAND)) $(MOZ_XPI_BUILD_COMMAND) [13:58] endif [13:58] build/webdeveloper ... will never be run by cdbs [13:58] o in rules [13:58] hmm [13:58] only build/firefox-webdeveloper [13:58] youll figure [13:58] ok [13:58] i'll play around with it [13:58] there is no EXTENSION_PKG in control [13:59] i will try to bail out in xpi.mk if a package not matching any binary package is used [14:00] jetsaredim: in xpi.mk the documentation is accurate: [14:00] # MOZ_EXTENSION_PKG (MANDATORY): [14:00] # define the binary package name used to ship this xpi [14:00] good [14:01] ok - that seems better [14:02] :) [14:02] does it work now? [14:03] jetsaredim: you imported the complete package into the .upstream branch [14:03] thats wrong [14:03] just the orig.tar.gz [14:03] does it really matter? [14:03] yes [14:03] since I ditched it and replaced it with the new tree [14:03] otherwise the upstream doesn't make sense [14:03] it matters in any case [14:03] the current .upstream branch has commits for debian/ [14:04] importing the current package helps you to learn the procedure [14:04] though not mandatory [14:04] but still the .upstream branch must not contain any debian/ directory :) [14:05] jetsaredim: i don't see that you replaced the .upstream code with new files yet [14:05] at least thats not in the log [14:05] https://code.edge.launchpad.net/~jetsaredim/firefox-extensions/firefox-webdeveloper.upstream [14:05] 1. By Jared Greenwald on 2008-03-18 [14:05] * import of existing package [14:05] i made a .ubuntu branch [14:05] thats good [14:05] yes the ubuntu branch should never receive new upstream files [14:05] only through merge from .upstream branch [14:05] awesome [14:06] jetsaredim: i don't see any new files in log of .ubuntu branch as well [14:06] jetsaredim: i think you accidentially pushed the .ubuntu branch to .upstream [14:06] you can uncommit till you are at revision 1 again and push --overwrite to .upstream [14:07] but still i am not sure where you upgraded the upstream sources ... if you did that at all [14:07] um [14:07] so ... un .upstream branch you would have 2 commits [14:07] 1. import existing upstream (v. XXXX) <- please name the version here [14:07] 2. upgrade to new upstream (v. XXXX) <- [14:08] the ubuntu branch would get [14:08] bzr branch -r 1 /path/to/upstream xxx.ubuntu [14:08] revision 2. import debian/ from packaging (version XXX) [14:08] either you fix build system then or do it after upstream merge [14:08] lets assume you fix it now [14:09] 3. fix build system to make use of xpi.mk and add build-depends on mozilla-devscripts accordingly [14:09] 4. merge new upstream sources from .upstream branch (v. XXX) [14:09] (revision 4 you are doing like:) [14:09] bzr merge /path/to/upstream/branch [14:09] while inside the .ubuntu branch [14:09] and then just bzr commit [14:10] why would a merge be necessary since I would have branched after importing the new sources [14:10] jetsaredim: you branched after revision 1 (current package) [14:10] so you need to merge revision 2 (new upstream) [14:11] ok - so when you say existing upstream - you mean the current package minus the debian dir? [14:11] jetsaredim: the current orig.tar.gz [14:11] nothing more [14:11] expanded? [14:11] there might be differences outside the debian/ dir in the diff.gz [14:11] so minus debian/ dir is not accurate [14:12] yes of course [14:12] makes sense? [14:12] (i mean in general) [14:12] in general [14:12] i think [14:13] i think I'll just blow away the bzr branches and start over [14:13] as you wish ... save the current debian/ dir so you can use that once you have arrived at that stage :) [14:13] right [14:13] and I modified the build.xml file too [14:14] yes. that only goes to .ubuntu branch [14:14] right [14:14] thats why importing debian package minus debian/ dir is not .upstream [14:14] only .orig.tar.gz should be upstream [14:15] 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] i just think that after doing this once you will be able to use that easily [14:16] sure you do ;) [14:18] jetsaredim: i see that you have a wierd dupe branch :) ... ~jetsaredim/firefox-extensions/firefox-webdeveloper.ubtuntu [14:18] read "ubtuntu" :) [14:19] heh [14:19] ~jetsaredim/firefox-extensions/firefox-webdeveloper.ubuntu exists as well ... so i think its a glitch :) [14:19] yea [14:19] i do that all the time when typing ubuntu [14:19] jetsaredim: yeah. bzr will remember where you initially pushed to [14:19] so you just need to do it once [14:19] after that just bzr push should be enough [14:20] jetsaredim: you can see where it would pull/merge and push to when running bzr info [14:20] crap - i think i just nuked the useragentswitcher.ubuntu branch [14:21] jetsaredim: yes ... if you still have it on your system you don't need to bother [14:21] you can just push it again [14:22] that would be convenient wouldn't ot [14:22] *it [14:22] well - at least I built the new package and can recover it from there [14:22] do you still have it on your disc? [14:23] yes ... you could just branch from .upstream and apply the .diff.gz [14:23] yea [14:37] asac: better...? https://code.edge.launchpad.net/~jetsaredim/firefox-extensions/firefox-webdeveloper.upstream [14:37] the comment looks good [14:38] how did you do it? like i said: rm -rf * .. and then extract new upstream source and run bzr add . [14:38] ? [14:38] yep [14:38] yes great [14:38] now branch the initial revision to an .ubuntu branch [14:38] apply the current .diff.gz [14:38] (as current package) [14:38] wait - what? [14:39] what do you mean by "branch the initial version"? [14:39] the idea is to create a .ubuntu branch that has the initial packaging [14:39] that should be done on revision 1 of course [14:39] ok [14:39] so bzr branch -r 1 /path/to/upstream ...ubuntu [14:39] then apply diff.gz [14:39] commit that as "* import packaging as of XXXX-0ubuntu1"! [14:40] or something [14:40] once that is done you can merge the other revision over by just running bzr merge /path/to/upstream [14:40] bump the changelog [14:40] fix the packaging ... and so on [14:40] :) [14:45] ok - so now I've got the upstream and ubuntu [14:45] upstream is current - ubuntu is old but has packaging [14:45] now I merge? [14:46] shoot [14:46] yeah [14:46] something got munged [14:46] you go to .ubuntu [14:46] bzr merge /path/to/upstream [14:47] what happened? [14:47] you can return to last committed state by running bzr revert [14:47] 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] yes [14:47] revision 2 most likely? [14:47] i suppose I can just create the dir and move them in [14:47] yea [14:47] he? [14:48] jetsaredim: maybe retry to apply the diff [14:48] i have things like control and rules at top of tree [14:48] if you are in the branch you run [14:48] patch < patchfile [14:48] gunzip -c /path/to/diff.gz | patch -p1 [14:48] ah p1 [14:48] yes [14:48] that's prolly the problem [14:48] then you most likely (if there are no conflicts) you run bzr add . [14:49] yea [14:49] and commit that saying "packaging for 1.0.5-0ubuntuX" [14:49] or something [14:49] i had done that, but like i said the thing got fuxed [14:49] how do I roolback a revision? [14:49] actually - i can just branch r1 [14:50] jetsaredim: what got committed? [14:50] you can bzr uncommit [14:50] bzr revert [14:50] that should bring you to the revision below [14:50] bzr ensure with bzr status that you don't have any unknown files [14:51] otherwise you might add them accidentially when you commit next time [14:51] jetsaredim: but remember that bzr uncommit is evil and should usually _never_ be done for branches already pushed to a remote place [14:51] you can use it for local reshuffeling of changes though [14:51] right - i already pushed it [14:51] jetsaredim: well ... in this case you can redo [14:52] was thinking that I could branch r1 re-apply the patch and then push [14:52] its like an excersize [14:52] and nobody is currently depending on it ... just "evil as a general rule" [14:52] jetsaredim: well rebranching revision 1 is similar to uncommit from the evilness ... do what you like more [14:52] it doesn't matter in this case [14:59] is there something magic that happens during the merge? [14:59] because the dev changed some of the directory structure and it seems completely different [14:59] he? [14:59] whats different? [15:00] please do a bzr diff [15:00] and show me the output [15:00] and bzr status [15:01] jetsaredim: is the new directory structure wrong? [15:01] no [15:01] the old dir structure is [15:01] they work for the package they are with [15:02] the old works with the old extension - new with the new extension [15:02] so why do you see a problem? [15:03] jetsaredim: bzr could track moves, but it doesn't know that things got moved [15:03] i don't think that there should be a problem [15:04] is the merge going to get rid of all of the old files? [15:04] jetsaredim: yes. if they are removed from the upstream branch it will (unless you have modified them ... then you would get conflicts) [15:04] jetsaredim: bzr status should yield something like this: [15:04] http://paste.ubuntu.com/5873/ [15:04] you see which files where removed [15:04] which added [15:04] and which modified [15:05] (you would also see meta info at the bottom about the merge) [15:08] is there a way to resolve conflicts? [15:09] what kind of conflicts do you get? [15:09] not sure [15:09] there shouldn't be any [15:09] which files are which? [15:09] he? [15:09] there is BASE, OTHER and THIS? [15:09] show me bzr st [15:09] where do you get the conflict? [15:10] 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] http://paste.ubuntu.com/5877/ [15:11] jetsaredim: ok. so the original debian package indeed hat the build.xml touched [15:11] jetsaredim: you can open build.xml and search for the conflict markers [15:11] "<<<<<<<<" [15:11] ====== [15:11] >>>>>> [15:11] resolve them :) [15:11] why not just bring in the OTHER? [15:12] since this is just a temporary branch [15:12] because then you loose the changes in build.xml. its better to review manually [15:12] further there might be other parts sucessfully merged in already [15:13] 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] 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] looks like he just re-wrote the build.xml file for the most part - there's like 85 changes [15:21] he did do similar stuff to the build file that I had to do [15:23] 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] so I'm going to plaster on my patched version of the new build.xml [15:36] jetsaredim: yes [15:36] thats ok [15:36] jetsaredim: but if you do so please document that in commit log [15:36] jetsaredim: and add an initial changelog bump in the same commit using [15:36] dch -v NEWPACKAGE-0ubuntuversion -D UNRELEASED [15:37] you can do that in a second commit as well [15:42] jetsaredim: all going well? [15:42] :) [15:44] I think so [15:44] I'm just pushing a new version [15:45] with the new build.xml and new debian/* files [15:47] good [15:47] does it build? [15:48] 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] lemmie check [15:49] * jetsaredim screams obscenities at the screen [15:49] 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] cp: cannot stat `./chrome': No such file or directory [15:49] sry for the paste [15:50] jetsaredim: there is something wierd [15:50] asac: you're telling me? [15:51] thing is that I had it all working [15:51] jetsaredim: no .. i mean .. what happened to the original debian/rules [15:51] still have the dir from that around - lemmie see what is different [15:51] aeh sorry ... the changelog [15:51] i look at the commit revision 4 [15:51] there is a complete new changelog in [15:51] isn't that supposed to be in revision 2 already? [15:52] uh - i suppose [15:52] * jetsaredim goes back to square one... [15:54] jetsaredim: ah ... you forgot to bzr add [15:54] after diff.gz patch :) [15:55] i coulda swore I did [15:55] ;) [15:58] this is a pain [15:59] well :) [15:59] learning by doing [15:59] one doesn't do such mistakes often [15:59] then things get efficient [16:00] then they suddenly appear to be done by instinct :-D [16:00] yea [16:00] true [16:00] not like i've never used vcs systems before [16:01] making me feel like an amateur [16:01] :) [16:01] gotta run for lunch [16:01] bbl [16:02] well, but you must admit that bzr is quite comprehensible :) [16:02] its just the procedures for debian packaging that are different ;) [16:34] asac, i have rendering issues on http://en.wikipedia.org/wiki/Biang [16:34] the [edit] on the right below each pictures are misplaced [16:35] and if you zoom several times, the background becomes black [16:43] * asac looking [16:48] fta2: whats the problem? the edit links are all three next to each other slightly to the right [16:49] how is it supposed to be (i can't remember) [16:49] i don't see any edit for other pictures [16:49] are those edit things related to the pictures at all? [17:21] asac, http://www.sofaraway.org/ubuntu/tmp/biang.png [17:22] ok i had to fix the ip for cvs-mirror to get a cvs checkout going again [17:22] fta2: yes, but from which elements are they? [17:22] the one next to mnemonics looks ok [17:23] ok its most likely for the paragraphs [17:23] above [17:23] summary + about the noodle and phonetic sub. [17:23] maybe yes [17:23] but this looks weird anyway [17:24] at least the 3 on the same line overwriting the text [17:27] leaving.. it's raining here, lots of fun with my e-bike on perspective. [17:28] how are those implemented in html? floats? [17:31] donno, select the text and use view selection source [17:31] * fta2 gone [17:32] jetsaredim: thats about right, yes. [17:33] jetsaredim: aber brnach you don't need to commit [17:33] you don't need to push until you are finished either [17:35] but thats all that you should fix besides the merge conflicts [17:35] jetsaredim: ^^^ [17:44] * asac jetsaredim well, nobody is perfect. nothing to bother about [17:45] jetsaredim: just go ahead [17:45] * jetsaredim proceeds with caution [17:46] I don't really need these firefox-webdeveloper.{dirs,links,install} do I? [17:49] jetsaredim: no you don't need them [17:59] * asac off traveling === dholbert is now known as dholbert_lunch [20:12] * jetsaredim uses pidgin [20:16] asac: ok - so something I'm doing is not right [20:17] cause I keep getting a fatal error during dh_install on debuild -b [20:17] whats the problem? [20:17] lemmie paste the output [20:17] y [20:17] http://paste.ubuntu.com/5900/ [20:17] that's just the end of the debuild -b, but the relevant part [20:18] jetsaredim you still have any debhelper file in debian/ ? [20:18] like *install ? [20:18] o duh [20:18] you need to drop all of them [20:18] its all automatically handled now [20:18] e.g. *install, *links *dirs [20:19] bzr rm FILENAME :) [20:20] ahh better [20:21] now to update the changelog [20:21]