[00:00] get-install-rdf-version.sh (from actual upstrem branch) [00:00] newer.sh [00:00] that have the new name [00:00] sorry [00:00] he? [00:00] get-new-imports.sh [00:00] didnt we rename those? [00:00] ah [00:00] yeah [00:00] those are ready, but for a full test I have a little master.sh to test the whole process and I need the branches [00:01] so now I write the simple init-branches.sh [00:01] to have all from start to the list of versions to be merged [00:01] Volans: yeah. we should also do a "mirros-branches.sh" [00:01] /merged/updated/ [00:01] or let me think [00:01] and what should do this script? [00:02] ok [00:02] most likely we want [00:04] mirror-branches.sh [00:04] hmm [00:04] mirror-branches.sh [00:05] that would branch: DIRECTORY/AMOID/SOURCE_PACKAGE_NAME.upstream [00:05] and [00:05] that would branch: DIRECTORY/AMOID/SOURCE_PACKAGE_NAME.ubuntu [00:05] and [00:05] that would branch: DIRECTORY/AMOID/SOURCE_PACKAGE_NAME.ubuntu.hardy [00:05] ... [00:06] e.g. for development release and all stable releases [00:06] but for now just .ubuntu ;) [00:06] ok [00:06] and .upstream [00:06] bzr branch or get/checkout? [00:06] Volans: if no branch exists [00:06] mkdir -p DIRECTORY/AMOID/SOURCE_PACKAGE_NAME.upstream [00:06] and bzr init DIRECTORY/AMOID/SOURCE_PACKAGE_NAME.upstream [00:07] same for .ubuntu i guess [00:07] Volans: branch [00:07] ok [00:07] quite simple [00:23] bug 271446 [00:23] Launchpad bug 271446 in network-manager "NM 0.7: GSM connect failed with "pppd_timed_out(): Looks like pppd didn't initialize our dbus module"" [Undecided,Triaged] https://launchpad.net/bugs/271446 [01:11] asac: one problem... the branches bzr url depends on the user that have uploaded it, in particular for .upstream branches [01:11] should we put also this info in the AMOID - SOURCE PACKAGE NAME list? [06:50] asac: re bug 247157 - i'm happy to try and make anotehr patch to have $otheraction, as long as $otheraction is decided on. the most obious way to fix it in my mind was install the certs (as thats how i fixed it). [06:50] Launchpad bug 247157 in ubuntu-dev-tools "dget/dgetlp should have ca-certificates in their Recommends field." [Wishlist,Fix released] https://launchpad.net/bugs/247157 [09:57] asac: network-manager crashed im letting apport give me details [09:58] lol nothing so far maybe apport script on LP helps [10:21] my connection is extreamly slow for some reason [11:19] something wrong here :( [11:20] bug 269656 <- in progress \o/ [11:21] Launchpad bug 269656 in ubufox "AN IRRELEVANT LICENSE IS PRESENTED TO YOU FREE-OF-CHARGE ON STARTUP" [High,In progress] https://launchpad.net/bugs/269656 [11:21] ah nevermind i found it [11:21] asac: that is the same as the firefox EULA and afaik it was removed from init start up [11:21] ok brb need to fix connection issues [11:37] asac: is dput working for you? [11:38] gnomefreak: the bug above is the "INFAMOUS" EULA bug :) [11:38] gnomefreak: not sure if you havent noticed it [11:38] i did [11:38] ah [11:38] i thought it was on ff3 not ubfox [11:38] ubufox [11:38] anyway. i am starting to commit fixes. [11:38] gnomefreak: ubufox and firefox-3.0 [11:38] ah [11:38] both contribute [11:39] someone in #xubuntu yesterday said it was fixed [11:41] bzr bd is fucked up :( [11:42] its putting everything in work/ except the source.changes [11:42] source.changes is being placed in build-area [11:46] asac: is LP slow for you? [11:46] like more than 2 minutes to open homepage [11:50] ok time to work on connection sincei cant even ping google [11:50] now its good [12:02] asac: if you don't already know it: http://lwn.net/Articles/299135/rss "Mozilla admits 'giant error' with Firefox EULA move (NetworkWorld)" [12:04] fixed [12:07] Volans: yeah [12:08] asac: I have a problem with the branches [12:08] gnomefreak: there will be a post-update fix for launchpad afaik [12:08] today [12:08] asac: thanks [12:08] * gnomefreak has issue with extension and cant remember what we did to fix it last time [12:08] many *.upstream branches are uploaded by users so ~volans/..../branch.upstream and so on... for every user that have upload a branch [12:09] Volans: yeah i read that yesterday but you were gone ;) [12:09] Volans: _all_ upstream branches will be in the same realm [12:09] most likely ~mozillateam at the beginning [12:09] but probably we will have a new team for that [12:09] at some point [12:10] Volans: same goes for the the .ubuntu branches [12:10] Volans: all will be in the same realm [12:10] ok, other issue, some of those have binary_package_name instead of source_package_name [12:10] I hope this will be fixed with the transition to the same realm [12:10] Volans: only .ubuntu branches that matter are 1) release branches and 2) proposed merges [12:10] release branches will be (in the beginning) in ~ubuntu-dev (or -core-dev in case the extension is in main) [12:11] the merge branches will be put into ~mozilla-extensions-dev [12:11] Volans: yeah. but i think source/binary isnt reawlly important for our task (maybe i miss something) [12:11] Volans: lets say its "branch-prefix" for now [12:12] ok [12:12] at some point we should consolidate them ... yes [12:12] so all have source-package [12:12] but i think that the scripts dont need to interpret those names for anything [12:13] for test that all works fine I have to mirror branches and now I can't automatically, I can download some branches manually to check that [12:13] Jazzva: with firegpg when it wouldnt install we changed the ID from xxxx-xx-xxxx to firegpg.firegpg.com? and it fixed it. well same issue with wizz-rss where would i look for the replacement for the ID numbewr [12:13] another way can be that I assume that there aren't branches and create new branches from hardy source packages, but in this way we lost che history of past branches commits [12:13] number [12:13] Volans: right. we could create an initial config file [12:13] Volans: with columns: [12:14] [12:14] if that helps [12:14] I already assume that at this stage [12:14] [12:14] but it's the same :) [12:14] yeah [12:14] so whats the problem then? [12:15] that is not sufficient to find the branch atm... [12:15] Volans: why? [12:15] i think i found the problem now to figure out how to fix :( [12:15] Volans: i think we need a general configuration: BRANCH_REALM: [12:15] thats lp:~ubuntu-dev/firefox-extensions/ [12:15] for ubuntu branches [12:15] and [12:16] thats lp:~mozillateam/firefox-extensions/ [12:16] for upstream branches [12:16] then the branch name would be: [12:16] $BRANCH_REALM_UPSTREAM/$BRANCH_PREFIX.upstream [12:16] and [12:16] $BRANCH_REALM_UBUNTU/$BRANCH_PREFIX.ubuntu [12:16] the problem is that the branch realm are: lp:~jazzva/firefox-extensions/snowl.upstream [12:16] and so on... [12:16] so maybe its branch-name-prefix (to avoid confusion) [12:17] depends on the users [12:17] Volans: ah [12:17] Volans: well. for those that have the .upstream branch somewhere else we need to fix them manually initially [12:17] and if we use the mozilla extensions team for uoload? [12:17] Volans: for upload? [12:17] *upload [12:18] for upstream branches [12:18] lp:~mozilla-extensions-team/firefox-extensions/snowl.upstream [12:18] Volans: anyone in that team can delete the branches then [12:18] oh right... [12:18] Volans: we probably want mozilla-extensions-upstream [12:18] at some point [12:18] yes [12:18] Volans: but you can surely test with lp:~volans/+junk/ ... unti its working [12:19] so at this point can be the complete url [12:19] Volans: no [12:19] Volans: as i said: we need two global configs [12:19] ok ok [12:19] BRANCH_REALM_UPSTREAM [12:19] and [12:19] BRANCH_REALM_UBUNTU [12:19] Volans: in theory we dont even need .upstream [12:19] when you look at the bzr log of .ubuntu [12:19] you can see the revision number of the last upstream merge [12:19] its for instance 7.1.5 [12:20] if you do bzr branch -r 7.1.5 branch.ubuntu branch.upstream [12:20] you will have the upstream branch again [12:20] howver, we still need them [12:20] but at least we can recover lost .upstream branches to get them started [12:20] we need them because its too hard to guess which version is upstream in a script ... and also we need them in case a auto-merge fails [12:21] so the user can do the merge based on an updated upstream branch. [12:21] ok, so for testing purposes I can manually branch the actual ones and put all to volans/+junk and test with it? [12:22] yeah... should work [12:22] ok thanks [12:22] Volans: you can also branch the branches you want to test locally [12:22] and use a local file path as BRANCH_REALM_* [12:22] so you dont need to do everything over network [12:22] oh, yeah, good idea [12:24] [reed]: is beltzner based in MV? [12:39] hi [12:40] asac: im getting a checksum mismatch in control files [12:40] how do i fix this, rebuild doesnt fix it [12:41] * gnomefreak hopes something easy that i forgot [12:41] or overlokked === Volans is now known as Volans_away [12:51] ok anyone tell me what im missing/overlooking? http://pastebin.mozilla.org/539806 [12:51] im so close to being done i can taste it :( [12:54] gnomefreak: well [12:55] i got it asac [12:55] gnomefreak: at best cleanup all those bits manually [12:55] and respin [12:55] i was respinning wrong version [12:56] nope i guess not [12:56] i dont get it ~jjv doesnt error [12:58] http://pastebin.mozilla.org/539820 [12:58] its the same frigging build just with ~jjv on end [12:58] gnomefreak: really. remove all the clutter [12:59] gnomefreak: did you put the orig in tarballs/ directory? [12:59] asac: what clutter are you seeing [12:59] asac: yes [13:00] could it be caused by the placement of files? sources.changes goes into build-area where as the rest go into work/ ~jjv gets placed in build-area [13:00] not sure why that is happening with smer command [13:00] same [13:01] packaging wise there cant be an issue since ~jjv doesnt error on lintian [13:01] only change is in changelog version [13:01] gnomefreak: right [13:01] i think the files are just out-of-sync [13:01] gnomefreak: so ... remove everything in build-area and work/ [13:02] e.g. clutter ;) [13:02] no need to grab branch again? [13:02] gnomefreak: where is the branch? [13:02] in work/ [13:02] ? [13:02] gnomefreak, I suppose you figured it out, but look for em:id field in install.rdf [13:02] asac: in work [13:02] gnomefreak: remove all files that get produced during build [13:03] and at least all files that complained about [13:03] Jazzva: thats not the issue i dont think but i will look if it fails again [13:03] em:id is numbers btw [13:03] k [13:04] ok respinning again [13:04] they all went into build-area now [13:05] asac: your good [13:05] now lets see if that ws the issue [13:05] was [13:06] ok wtf [13:08] building source it went into build-area when i built bins. everything was removed from build-area and placed into work except for the sources.changes file [13:08] why would bzr do that [13:08] i shouldnt have to remove build-area for every build [13:09] gnomefreak: yeah [13:09] bzr builddeb is a bit broken right now [13:09] i think the sources end up at a different place [13:09] then the binaries [13:10] e.g. the sources are put in the parent dir and the binaries in build-area [13:10] if foud this confusing too [13:10] and still havent figured the line [13:11] thats what im seeing i just asked in #bzr too see if something can be worked around or a PPA with fixed verion [13:12] gnomefreak: james_w is the one to ask [13:12] gnomefreak: he is in this channel ;) [13:16] hes in every channel ;) [13:17] he answered me before in motu now he answered me in bzr oh and -sa isnt a valid in bzr bd [13:21] gnomefreak: you can use it by specifying a builder, but you can't pass it to "bzr bd" directly [13:21] "bzr bd -sa" -> "bzr: ERROR: No such option -s" [13:22] james_w: it is in the builder [13:22] if you did "bzr bd --builder 'debuild -S -sa'" to build the source package then that will be why it didn't get moved [13:22] james_w: youll see it on the paste i gave you [13:22] "bzr bd -S --builder 'debuild -S -sa'" will work [13:24] ok, so you didn't tell it you were building a source package (bzr bd -S) the first time, so it didn't know to look for _source.changes instead of _i386.changes, so it didn't move the files [13:24] you then built the binary package, it saw the _i386.changes, and moved the results [13:24] it was a full source upload, so the _i386.changes included the .dsc, and so they were moved as well [13:24] james_w: i gave the -S option int he builder [13:25] gnomefreak: yeah, but bd doesn't know that [13:25] james_w: isnt there a regression as well for those "changes"? [13:25] no reason why i should have to give it 2 times [13:25] asac: I'm not sure what you mean [13:25] james_w: it regularly complains to me that some changes are missing ... appears to be a non-fatal warning [13:25] that would be a regression or a feature in new version [13:25] this was working fine last week [13:26] gnomefreak: if you don't want them moved then make ~/.bazaar/builddeb.conf [13:26] and put [13:26] [BUILDDEB] [13:26] result-dir = ../build-area [13:26] james_w: what will end up in build-area by default ? [13:26] nothing? [13:26] thats all i put in it? [13:26] or the binary parts? [13:26] unfortunately that will break until I get the next bug fix release in the archive [13:27] asac: it should be nothing [13:28] james_w: [13:28] build-dir = /var/builddir/asac/ [13:28] result-dir = /var/builddir/asac/results/ [13:28] all deps end in build-dir [13:28] deps? [13:28] james_w: this shoudl work? http://pastebin.mozilla.org/539844 [13:29] james_w: debs ;) [13:29] s/shoudl/should [13:29] james_w: actually that was how it behaved a few days ago [13:29] gnomefreak: no, ~/.bazaar/builddeb.conf [13:29] now that i am looking _everything_ ends up in build-dir :( [13:29] oh dmn [13:29] oh wait ... maybe i didnt build sources for a logn time [13:29] lets check [13:29] gnomefreak: and if you set it now then it will cause a failure on every build unfortunately === Volans_away is now known as Volans [13:30] well thats not helpful :( ok ill wait to set it than [13:31] ok made note [13:31] james_w: ok [13:32] james_w: i think i understand where this confusion comes from :) [13:32] james_w: appears to behave like "implemented" [13:32] its just that all my binary builds i did in the past failed due to gpg key [13:32] and i just ignored that [13:33] didnt really think about that as being an error that prevents the packages from being moved to results [13:33] but makes sense ;) [13:34] Jazzva: nope what i thought was issue wasnt. the em:id's match in .rdf and rules [13:36] Jazzva: install.rdf http://pastebin.mozilla.org/539853 and rules http://pastebin.mozilla.org/539857 [13:37] it builds fine and installs but it doesnt show up in browser anywhere (in addons or anyother menu) [13:37] gnomefreak, try uncommenting MOZ_XPI_EMID line in debian/rules. [13:37] ok [13:37] Also, if you're specifying MOZ_XPI_MOZILLA_DIRS, uncomment it too :) [13:38] gnomefreak, you can remove iceweasel and icedove, we're not shipping them afaik [13:38] Jazzva: as haad me add them to xpi.temp [13:38] gnomefreak, another thing... afaik, you shouldn't use "_" in the package name. [13:38] huh? [13:38] where do you see _ [13:38] MOZ_EXTENSION_PKG := wizz_rss_news_reader [13:39] its upsteams name [13:39] upstreams [13:40] i changed name to wizz-rss maybe i should have that in rules instead? [13:40] wizz-rss should be ok, I think [13:40] if you need to keep this one, replace "_" with "-" [13:44] this looks better [13:44] will let you know [13:45] Jazzva: worked perfectly ;) thanks [13:47] no problem :) [13:59] it works too ;) [14:11] hi [14:12] hi [14:12] ok this toolbar is cool ;) [14:12] asac, I guess i should wait to merge your last ff3.0 change to the 3.1 branches, right? still looks like wip to me [14:15] asac: ok i have 4 feeds and the options in tool bar all work so far. can you please review firegpg chatzilla and wizz-rss in my PPA the ~jjv1 versions are the right ones not a lintian warning or error in any [14:29] fta: wip? [14:29] sorry, wip = work in progress [14:30] yes. its in progress ;) [14:30] better not diffuse that too much in the branch jungle ;) [14:31] in case we have to go a different approach or who knows what ;) [14:45] asac, any idea how i can fix the error in prism ? this is the only issue left to update prism [14:45] i'd like to push prism if it's not too late [14:46] fta: does that happen with en-US as well? [14:46] i'm using en-US [14:48] fta: show me the error and the source sourrounding that error ;) [14:49] from what i remember its a missing translatable entity ... which causes the xml parser to choke [14:50] i figured that out but why? [14:50] fta: which resource is it that is missing [14:50] cant tell more without knowing that [14:50] Sep 18 15:45:37 XML Parsing Error: undefined entity [14:50] Sep 18 15:45:37 Location: chrome://mozapps/content/extensions/update.xul [14:50] Sep 18 15:45:37 Line Number 14, Column 1: fta: that doesnt give me enough context [14:50] i need the code of update.xul [14:51] sourrounding that line [14:51] lol, hold on, i'm looking in the code [14:51] (there is not even anm entity visibly in that error [14:51] ) [14:51] which is always painful for these parser errors [14:53] mostlikely &updateWizard.title; [14:54] open chrome://mozapps/locale/extensions/update.dtd and see if the title is defined there [14:54] that refers to &brandShortName; in 3.0 [14:54] that makes sense [14:54] fta: prism has to provide brand.properties and brand.dtd [14:54] when running as standalone app [14:54] fta: ^^ [14:55] most likely doesnt ship that ... or the build we are doing misses those files [14:55] ok ... off for a break [14:55] havent had lunch yet [14:56] that update.xul is in xul, not in prism [14:56] yes [14:56] but xul doesnt have a brand [14:56] so the app has to provide brand.properties and brand.dtd [14:58] ./prism/runtime/chrome/locale/en-US/brand/brand.dtd [15:00] it is packed in the jar: http://launchpadlibrarian.net/17734266/buildlog_ubuntu-intrepid-i386.prism_0.9.1%2Bsvn20080918r18380-0ubuntu1~fta1_FULLYBUILT.txt.gz [15:04] asac, http://ubuntuforums.org/showthread.php?t=924136 [15:32] <[reed]> asac: no, Toronto [15:33] <[reed]> asac: but he's in MV quite often [17:25] if anyone is using ff-3.1 under intrepid (either my builds or the official ones) could you please tell me if you have proper sound when viewing a