[00:05] let me ceck [00:06] yes [00:06] i often do it that way too [00:06] sometimes not if i am the only one [00:06] but its more beautiful ;) [00:07] asac: pushed xul again [00:07] working on ff3.5 [00:09] asac: m-d 0.19 with dh 7 makefile: http://paste.debian.net/55730/ [00:09] asac: do you like it? [00:10] yes ;) [00:10] asac: pushed ff3.5 as well [00:10] asac: the best: it works already :) [00:10] cool. lets hope it doesnt cause regressions ;) [00:11] to earn credits we should do an extension respin ;) [00:11] ooops [00:11] forgot to check for targetted bugs [00:11] hehe [00:11] see what i mean ;) [00:11] micahg: include them in firefox only then [00:11] asac: now I see why this is so complicated :) [00:11] asac: nothing for 3.5.7 [00:11] so we're good [00:11] 3.5.8 has some [00:12] good. [00:12] so just prep release and then wait ;) ... i am currently doing the tarballs. that will take a bit ;) [00:14] k, I need to get back to what I was working on [00:15] asac: so you normally merge the rev's from head for the update into the older releases? [00:15] no [00:15] the stable release branches are stable [00:15] they are independent [00:16] however, if i find that i need a patch updated [00:16] i cherry pick that change down usually [00:16] because of lazyness [00:16] (to all branches that all have that patch) [00:16] so i start on .karmic branch ... if there are patch adjustments needed i do that by copying those from .head manually [00:16] then on jaunty intrepid hardy branches i bzr merge -c REVNO lp:....karmic [00:16] them [00:17] asac: updated http://wiki.debian.org/mozilla-devscripts [00:18] why do you use $(null) ... we use $(NULL) everywhere ;) [00:19] asac: where do we use $(NULL)? [00:19] ah, so you merge in the stable branches [00:19] I see [00:20] in all mozilla packages [00:20] micahg: only if i need to merge something [00:20] but only using -c (e.g. one commit cherry picks) [00:20] and only for patches [00:20] or for something critical needed everywhere in a stable update [00:21] k, BTW there was a patch dropped for 3.5 [00:21] 1.9.1.7 [00:21] asac: in xpi.mk is no $(NULL) - so i can't know it ;) [00:21] asac: correct it if you want [00:22] hmm need to login ;) [00:22] no idea what credentials i had [00:22] or if i had any at all ever [00:23] super. it doesnt tell me if a mail was sent ;) [00:23] for recovering pass [00:23] hmm. when creating an account there are two buttons: [00:23] "Create Profile" ... "Create Profile + Email" [00:23] hell [00:23] usability ftw [00:24] * asac hits the first button ... hoping for the best [00:25] done [00:31] asac: can "rdf_graph.parse" work directly on text (and not filenames)? [00:33] i am a drive-by contributor ... i dont know nothing about rdflib api and work by using APIDOC for every step :) [00:36] asac: some ppl is complaining for the rfkill thing not working anymore, any news that side? [00:42] and`: depends on hardware etc. [00:43] most dell stuff should be fixed [00:43] but afaik there are still issues [00:44] ok off [00:44] ttyt [00:44] bdrung: i will see if i can find something for buffer tomorrow [00:44] asac: thanks [00:45] asac: then i could check the install.rdf before extracting everything [00:48] asac: do you need me to do anything more later tonight? [00:51] bdrung: use a StringInputSource [00:51] asac: release was an hour ago [00:51] http://www.rdflib.net/rdflib-2.4.0/html/private/_xmlplus.sax.xmlreader.InputSource-class.html [00:52] bdrung: ^^ [00:52] subclass of that [00:52] and then you can use that in the parse argument from what i understand [00:52] ok [00:53] parse(self, source, publicID, format, **args) [00:53] so for source [00:53] not sure what we have now [00:53] asac: we have "rdf_graph.parse(install_rdf)" no [00:53] w [00:54] yeah. apidoc is messy [00:55] maybe it type checks for a string and implicitly makes a URLINputSource out of it [00:55] so try the StringInputSource approach [00:55] you need to pass a publicID most likely because buffers have no pubID ;) [01:02] :) [01:03] will test it tomorrow [01:03] it's now bed time [01:04] asac: you need me to do anything when I get home? [01:05] micahg: prepare all the stable branches ;)? [01:05] hehe [01:05] well. basically its just the changelog entry. and then trying if all patches apply [01:05] oh and the patch drop [01:05] if you dont want to do that [01:05] asac: if you want me too [01:05] I can try [01:06] asac: what about the m-dev change in ff35.head? [01:06] and dh_xul [01:06] micahg: i would expect each branch to be three commits ... first commit is new changelog with UNRELEASED and the USN-.. stuff ... second commit is the patch droppage (like i usually document) [01:07] micahg: changing packaging in any way is off for stability/security updates [01:07] so no [01:07] just bumping changelog ... doing the minimal changes needed (like dropping patches dropped upstream, rebasing patches) ... and then releasing [01:07] asac: so how can we call it the same version? [01:07] if you look at the .jaunty or .intrepid branches you will see that its always really simple [01:08] micahg: if you checkout the branches you will see how the versioning is done [01:08] asac: yes, I know [01:08] basically same upstream version, but with 0ubuntu0.9.10.1 [01:08] for first upload to 9.10 [01:08] while head is ubuntu1 [01:08] yes, but how can the lucid and karmic version be essentially the same (think same contents) but have different contents? [01:08] micahg: the man page is buggy. it must say: "available since 1.9.1.7 in lenny" [01:08] or lucid [01:09] debian probably wont push that to security either ;) [01:09] micahg: we have two parts for packages: a) upstream ... b) packaging [01:09] upstream gets bumped to new upstream [01:09] while packaging gets forked when released [01:09] all new stuff we do will not be done on the stable branches [01:10] like dh_... here is a good example of what doesnt happen in stable branches [01:10] asac: is it mozilla team specific that 1.9.1.7-0ubuntu1 and 1.9.1.7-0ubuntu0.09.10.1 aren't the same? [01:10] similarly we wouldnt rename or move around files [01:10] etc. [01:10] while we might do that in lucid [01:11] micahg: we are kid of unique because we bump upstream [01:11] usually upstream is never bumped in stable releases [01:11] only backported patches added [01:11] k, that's what I was wondering because I never saw this before in other packages [01:11] but mozilla needs full new upstream [01:11] so we are a bit special, yes. [01:11] asac: what about the slovak translation thing we said we'd do for karmic [01:11] otherwise you would have to add up to 300 patches or something ;) [01:11] (happened in the past) [01:11] well... maybe too much. but i definitly saw 200+ bug fixes in security updates [01:12] when we still had the long security cycle [01:12] micahg: what did we say? [01:12] asac: nothing officially :) [01:13] originally targetted to karmic-updates but released to lucid [01:13] hmm. not sure ;) [01:13] in doubt drop it [01:13] and wait for someone complaining ;) [01:13] k, well, there's always 3.6 :) [01:14] or lucid ;) [01:14] so .desktop file translations probably can be added. but we shouldnt do that while preparing the release ;) [01:14] asac: so, I'll try to do the stable 1.9.1 and 3.5 branches [01:14] rather directly [01:14] a little later [01:14] if i didnt commit it to other branches, i would say i didnt want it there for now [01:15] yes. that would be great [01:15] i will upload the lucid bits to the -security PPA now :) [01:15] for 1.9.1 and 3.5 [01:16] * asac checks builders status [01:16] micahg: oh. did we drop the patch because it was applied upstream? [01:16] asac: yep [01:16] or because i was annoyed by it? [01:16] ok [01:16] then we need to drop it [01:16] or you dropped it ... just thought that only me would drop patches for being annoyed ;) [01:17] but it hink that was on 1.9.2 and 1.9.3 [01:17] Drop patch after upstream landing of (bmo: 521780) :) [01:19] micahg: oh. ffox 3.5 and xul 1.9.1 get the _same_ USN [01:19] in case you didnt do that on 3.5 [01:19] * asac should check [01:19] asac: I did [01:19] the other USN is for 3.0 and 1.9 [01:19] because they have a different set of security issues usually [01:19] asac: so technically 1 bug should have been targeted, but it was fix released already with our patch [01:20] ok pushing to http://launchpad.net/~ubuntu-mozilla-security/+archive/ppa [01:20] micahg: yes. thats ok. we dont need to mention as "dropping because of upstream fix" already implies that [01:20] maybe we should explicitly rename the bug number in such a comment [01:21] but well ;) [01:21] thinks must be imperfect [01:22] hmm. somehow feel the urge to also do a 3.0/1.9 upload now [01:22] to get these orig beasts up ;) [02:28] ffox orig also up [02:28] in sec === ripps|sleep is now known as ripps [03:37] fta: okay, the change actually builds the source packages now, but the .changes files are still have the epoch in the name and for some reason, dput wouldn't upload them at the end. [03:38] okay, it seems the dput upload at the end was expecting an epoch, but the actual .changes in /ppa didn't have an epoch === asac_ is now known as asac [05:00] micahg: already started? [05:00] on xul? [05:00] no, trying to fix a bug in something else [05:00] ok [05:01] so i will do karmic now [05:01] asac: I started building 1.9.2~rc1 :) [05:01] for xulrunner [05:01] right cause those take a while [05:01] just noticed that we only have 1 hppa builder [05:01] I can do jaunty right now then [05:01] so better get the big stuff up ;) [05:01] ok cool [05:02] * micahg is still at work [05:02] and you're either up early or late :) [05:04] early and late [05:05] wanted to finish xul 1.9 [05:05] then bandwidth broken and so on :) [05:06] micahg: last dch before release commit is dch -r -Dkarmic-security fwiw and jaunty-security etc. ;) [05:07] asac: we never had the patch in jaunty [05:07] thats even better then [05:08] so no need to do that ... just simple changelog ;) [05:08] i usually try a bzr bd ... --builder='debuild -b' and abort after patches [05:08] asac: the patch would be the same name, right? [05:08] e.g. if they applied [05:08] micahg: most likely [05:08] br the debuild -b and wait for patches test should reveal that [05:08] ;) [05:09] maybe we have something else there etc. [05:09] * micahg doesn't ahve the tarball [05:10] micahg: its in ppa [05:10] https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+files/xulrunner-1.9.1_1.9.1.7+nobinonly.orig.tar.gz [05:11] k [05:11] thaqnks [05:11] *thanks [05:12] i am taking jaunty firefox too i guess ;) [05:13] you're faster than I am :) [05:14] parallelizing ;) [05:14] not faster [05:14] oh, I can do that [05:14] * micahg has learned how to use byobu [05:14] also i did that a hundred times :( [05:15] nah ;) [05:15] i am parallelizing by working on four/five branches at the same time ;) [05:15] and by not doing a full test build ;) [05:15] just waiting till patches are done. thats fine [05:15] we will see the result in the staging ppa soon enough :) [05:18] asac: dies after patches with autoconf [05:19] dies? [05:19] paste? [05:19] I don't have the build deps [05:20] micahg: i run that on karmic ;) [05:20] asac: http://pastebin.ubuntu.com/352144/ [05:20] i do everything on karmic without chroots ;) [05:20] micahg: its ok i guess [05:20] just finish the commit stuff ... i cna do a quick test -b [05:20] before uploading [05:21] but looks weird [05:21] did you do bzr bd? [05:21] yeah, but I don't have the build deps [05:21] that should check for deps [05:21] I ran -d [05:21] how did it build then? [05:21] oh [05:21] ok [05:21] :) [05:21] yeah. go ahead then [05:21] let me know so i can pull ;) [05:21] * micahg is running these jobs on a headless server [05:22] asac: done [05:22] * asac checks [05:24] asac: lp refreshed [05:25] uploadewd [05:25] everything happily spinning i hope [05:25] at least we are still dominating builders ;) ... https://edge.launchpad.net/builders [05:26] 50% xulrunner ... other 50% is chromium-browser :) [05:26] ugh, lucky for us no one else is building anything [05:26] good ... 9.04.1 is also there [05:26] micahg: well. thats not really true ;) [05:26] the queues are growing [05:26] i think our ppa gets "main" priority [05:26] so all universe has to wait [05:27] asac: I think the security PPA uses the distro builders [05:27] we use [05:27] but look at the distro builders ;) [05:27] Official distributions build statu [05:27] powerpc2 306 jobs (20 hours) [05:28] sparc2 239 jobs (26 hours) [05:28] hehe [05:28] but not that bad [05:28] i think most are probably universe packages so they start with 1000 lower build score ;) [05:30] asac: what to do about sqlite conf test causing FTBFS on xul193 Lucid? [05:30] should I bump sqlite system requirement to 3.6.22 since that's what they're aiming for? [05:31] sure [05:32] sounds sane [05:32] asac: there's no official bug yet for that afaik [05:32] nm [05:32] mozilla 530667 [05:32] Mozilla bug 530667 in Storage "Upgrade to SQLite 3.6.22" [Normal,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=530667 [05:33] why would that fix it? [05:34] asac: should I say bump in advance of landing of bmo... [05:34] did they patch their sqlite in-source already? [05:34] asac: no, but it'll use their version for right now [05:34] or because they have higher requirements for system libs ;) :-Ü [05:34] we only have 3.6.21-2 [05:34] i think its ok. [05:34] we most likely will get that [05:34] what about the comment? [05:34] in lucid [05:34] comment? [05:35] bump in advance of landing of [05:35] bump sqlite for anticipated landing of 3.6.22 upstream - also workaround temporary configure bustage for system sqlite [05:35] something like that [05:36] asac: in changelog or bzr or both? [05:37] i dont think we have anything in changelog for .3? [05:37] then just bzr [05:37] yep, we have a changelog :) [05:38] asac: Bump system sqlite to 3.6.22 for anticipated upstream Mozilla landing [05:38] Also temporarily workaround broken configure test due to (bmo: 445164) [05:39] sure [05:40] asac: also, what to do if do people bump something like sqlite, do we keep both changelog entries? [05:40] *two people [05:40] we replace the previous entry if its in the same UNRELEASED cycle [05:40] ok [05:41] but we can check when that happens [05:41] I removed the old entry [05:41] debcommit is a lot easier than trying to edit the bzr commit [05:42] k, xul193 should build on lucid tomorrow night [05:43] cool. [05:43] ok i am off [05:43] taking a nap beffore i have to start ;) [05:43] in like 4h [05:43] heh, I need to get home so I can get some sleep too [05:44] guess tomorrow will be a short day for me [05:44] yes. thanks for your help ;) [05:44] asac: thanks for the training === jtv is now known as jtv-afk [07:42] hi [07:44] does anyone here use mozplugger? I noticed that it doesn't open .xls files correctly [07:44] it opens them with ooo writer instead of ooo calc [07:46] actually it calls ooffice on the file, which calls oowriter [07:46] anyone noticed this? [07:53] in any case, that really seems like an ooo bug [07:54] ooffice on foobar.xls works as expected, but ooffice foobar (without the extension, as are the files in the firefox cache) it doesn't [08:23] hello I have a odd question will the configs on thunderbird from Linux work on windows? [08:23] just the configs from thunderbird [08:51] hey guys [08:51] i have a question i have a friend who is migrating a pc to windows and would like ot keep the tbird configs will they also work on the windows version of tbird === jtv-afk is now known as jtv [10:21] ripps, strange, it worked for me. could you please show me the full logs + the content of the ppa dir (*dsc, *change, ..)? [10:35] morning [10:43] morning BUGabundo_work [11:07] fta: hmm.... it seems I'm going to need to run it again, because the ppa seems to be cleaned out when I run daily.sh on another pocket [11:08] ^ppa^ppa dir [11:08] yes, you have build_dir for that [11:15] fta: daily.sh log: http://pastebin.com/f23f87cfd [11:16] contents of ppa: http://pastebin.com/m77004c6 [11:17] pssh... poor time to try this, launchpad was experiencing problems at the time [11:18] jdstrand: so i have an action to figure out what kernel pieces from .32 we need on .31 for apparmor in lucid (we have .31 for some arm boards) [11:18] jdstrand: can you help me with that? [11:18] or is all fine in .31? [11:21] ripps, oh, i see. it's all fine except the final dput.. yesterday, i tested everything except that :P [11:21] fix is trivial, i'll do that later today [11:22] okay, that's all I was trying to say :) [11:22] thanx === BUGabundo_work is now known as BUGabundo_lunch === gandi_ is now known as gandi === BUGabundo_lunch is now known as BUGabundo_work [14:22] asac: the karmic kernel should be generally ok, but there are fixes in .32. best to talk to jjohansen about it (he does all the kernel bits) [14:24] ok [14:24] thx [14:30] jdstrand: u know what kernel Lucid is expected to have? [14:31] BUGabundo_work: .32 [14:31] everyone knows that ;) ... how come not you? [14:32] i've been spoty at covering lucid :\ [14:33] and ppl have been asking for .33 for some reason [14:33] most usually dont even know why they want it [14:33] just ask for the latest version that might be on market [14:33] this is LTS cycle [14:34] so we wont go or bleeding edge kernel [14:34] rather bake .32 till its most solid [15:08] ripps, could you try this: http://paste.ubuntu.com/352356/ ? i trashed my test package yesterday after my patch :( [15:16] [reed], https://bugzilla.mozilla.org/show_bug.cgi?id=531160 ignored :( [15:16] Mozilla bug 531160 in Libraries "libpkix ignores the P (trusted peer) trust flag" [Normal,New] [15:16] fta2: wah-teh certainly knows how to escalate stuff he he really wants it [15:17] he is long term nspr/nss developer that only recently moved to google [15:18] http://code.google.com/p/chromium/wiki/LinuxCertManagement [15:23] <[reed]> fta2: yeah, wtc is a NSS/NSPR developer [15:23] <[reed]> has been for years [15:23] <[reed]> asac: he's been at Google for a while now [15:23] sure [15:24] recently is relative [15:24] is was in the twenties recently too ;) [15:24] asac: we don't want Firefox to display local PHP source code, right? [15:24] stick to upstream behaviour [15:24] it should open that in an editor i guess [15:24] k, that's what I thought, I [15:25] 'll close it invalid (bug 503259) if you're interested [15:25] Launchpad bug 503259 in firefox-3.5 "php page not displayed" [Undecided,New] https://launchpad.net/bugs/503259 [15:26] if it opens that in editor its fine [15:26] its server job to send special mime type if the website wants to display inline [15:27] right, but it's a local file, so file:/// won't be getting a mime type [15:27] maybe I should dupe the Open With bug? [15:29] * micahg thinks he'll ask for more info... [15:49] fta2: patch works, it's dputting now [15:52] good, committing [16:09] jdstrand: the updates are up (and all build afaict). but i am out now because of lack of sleep so unless you want to test all we have to finish this tomorrow [16:10] asac: I'll work through them, but I think waiting til tomorrow and getting more testing would be good anyway [17:23] asac: i have news for you [17:23] *drum roll* === yofel_ is now known as yofel [17:24] i pushed my changes to m-d and merged the dh_xul-ext branch back into trunk [17:24] asac: can you please have a look at it and check if you find bugs? i will write the man pages and then it's ready for upload. [18:04] <[reed]> jdstrand: hey, I cc'd you on a secbug on bmo [18:04] <[reed]> and asked for some help [18:04] <[reed]> so, I'd appreciate if you would take a look sometime :) === ripps is now known as ripps|sleep === stevel_ is now known as stevel [19:21] hey guys, can you help me with a debian package version numbering problem? [19:21] Pavlov: just ask :) [19:22] hey [19:22] so, we have had fennec packages.. fennec-1.0b4, b5, etc up to fennec-1.0rc1 [19:22] now we've dropped rc1 [19:22] and we're not getting updates from rc1 to 1.0 [19:23] i'm assuming something thinks that 1.0rc1 is newer than 1.0 [19:23] Pavlov: yep, you should have used 1.0~rc1 [19:23] so i'm wondering if you guys either know how version numbers are compared for these things, or can point me to some place with info on it? [19:23] hmm [19:23] how does the ~ work? [19:23] Pavlov: dpkg --compare-versions. [19:24] Pavlov: ~ means lower [19:24] Pavlov: man dpkg :) [19:24] its not in there;) [19:24] Pavlov: what? [19:24] in my dpkg manpage [19:25] anything about ~ [19:25] Pavlov: yeah, but --compare-versions [19:25] oh, i see, these take strings [19:26] Pavlov: I don't know how mozilla guys handle this but you could use 1.0+something, ~ is lower and + is higher [19:27] we can change it [19:29] ah [19:29] hmm [19:30] ok, so we've had these versions: http://pastebin.mozilla.org/695132 [19:31]