[00:00] asac, we were supposed to discuss the ppa reorg today :P [00:05] asac, bug 243344, grrrr. tons of dupes, filed 1.5y ago, no one cared :( [00:05] Launchpad bug 243344 in scim-bridge "scim-bridge crashed with SIGSEGV in scim::IMEngineInstanceBase::get_frontend_data()" [Medium,Confirmed] https://launchpad.net/bugs/243344 [01:13] fta: asac: I realized yesterday after I went offline it was probably comm-central branching that caused the issues with tb3 === micahg1 is now known as micahg [01:15] micahg, it was, i said so yesterday, i fixed 3.0 and created a new 3.1 branch [01:16] so, what is 3.0 dailiy pointing at now? [01:17] comm-1.9.1 [01:18] ok, are you going to make a 3.1 daily? [01:19] probably [01:19] ok, are you going to be on much longer? [01:19] nope, it's late [01:20] ok, fine, just wondering whether I should work on Prism now or a little later :) [02:07] hrm... bottom extension toolbar is missing chromium-daily... [04:20] asac: help...xpi.mk is driving me nuts [08:00] morning === ripps_ is now known as ripps [11:12] asac asac_ up yet? [11:34] hi asac__ [11:37] micahg, it's sunday, asac won't be here till evening / night [11:37] he's just lagging [11:37] he said he would be here [11:37] I was trying to finish up prism [11:38] but had some issues with m-dev [11:38] strange, he's usually away sunday morning [11:38] which issues? [11:38] prism won't build :) [11:38] paste me the error [11:38] ok, I just restored the orirginal m-dev [11:38] I"m building now [11:39] k [11:39] hey [11:39] hi [11:39] micahg, you were right :) [11:39] xpi.mk was driving me crazy [11:39] hmm [11:39] micahg: didnt the thing work? [11:40] i mean common-post-build-arch .... or wahtever i said? [11:40] oh, btw, ScottK wanted to know if anything needs to be done for bug 217908 [11:40] Launchpad bug 217908 in cairo "FFe: Pixellated Images in Firefox/Opera due to incorrect EXTEND_PAD implementation in several video drivers" [High,Fix released] https://launchpad.net/bugs/217908 [11:40] yeah, that wasn;t the issue [11:40] what wasnt the issue? [11:40] asac__, I mailed linux-bluetooth ML at kernel.org and they said me using udev to fix the rfkill thing it's really bad and shouldnt be done [11:40] changing to what you said [11:40] the refractor.xpi:: rule was clearly wrong [11:40] asac__, that's why rfkill is disabled for normal users [11:41] the problem seem to be wildcard (MOZ_XPI_FILE) doesn't resolve [11:41] at least the first problem [11:41] av`: well... you can do whatever you want in debian [11:41] http://pastebin.ubuntu.com/301253/ [11:41] av`: its a temporary workaround as i said [11:41] asac__, there should be a plan to build a rfkilld but who knows when it will be done, in the meantime I need to find out a working thing to do [11:41] bluez will get rfkill support [11:42] and then it can go away [11:42] asac__: the patch should be applied to bluez itself not gnome-bluetooth [11:42] thats what i explained yesterday [11:42] no [11:42] there is not patch for bluez [11:42] wlel you can put it in bluez [11:42] but i have no strong opinion ;) [11:42] don't misunderstand me, I meant bluez needs to be fixed [11:42] not gnome-bluetooth [11:42] go ahead and do it [11:43] or wait till bluez upstream does it [11:43] and gnome-bluetooth gets fixed to use that then new dbus api [11:43] ;) [11:43] asac, this is the line that doesn't seem to work http://pastebin.ubuntu.com/301253/ [11:43] oops XPI_FILE = $(wildcard $(MOZ_XPI_FILE)) [11:43] asac__, actually I wanted to use your workaround but the other maintainer stopped me from doing it [11:43] the pastebin is the end of the build [11:43] micahg: what diff did you do? [11:43] micahg: point is that you rannot use refractor.xpi:: rule anymore [11:43] that doesnt get called at all [11:44] it was called in older mozilla-devscripts [11:44] asac__, cause some developers at linux-bluetooth wrote that it's the wrong thing to do, but my question is: why they say it's wrong to do and they don't provide a patch to have it fixed asap? [11:44] av`: its understood that its the wrong thing to do [11:44] asac: http://bazaar.launchpad.net/~micahg/prism/prism-1.0b2-karmic/revision/117 [11:44] av`: i told you yesterday [11:44] so you didnt get any new info [11:44] asac__, yeah, but the problem here is how long will it take upstream to implement that^ [11:45] but its the only feasible thing to do atm [11:45] until its fixed [11:45] we can't leave that thing for ages, so it would be nice to know upstream's roadmap for it [11:45] it will ge tdone [11:46] we discussed it all when we added it [11:46] its on roadmpa ... or even already in bluez [11:46] you can check [11:46] micahg: maybe you still need the zip -d? [11:47] thta produced the .xpi in the past [11:47] thought it woudl do that automatically [11:47] no, the XPI is there [11:47] this line isn't working XPI_FILE = $(wildcard $(MOZ_XPI_FILE)) [11:47] if I take out the wildcard, it gets to the next step [11:48] micahg: [11:48] ifneq (,$(MOZ_XPI_FILE)) [11:48] XPI_FILE = $(wildcard $(MOZ_XPI_FILE)) [11:48] else [11:48] XPI_FILE = $(wildcard *.xpi) [11:48] endif [11:48] thats only used if you specify MOZ_XPI_FILE [11:49] which yo dont, right? [11:49] that is specified [11:49] that shouldnt [11:49] asac__, yeah, I hope so, kernel 2.6.31 is in NEW now so gnome-bluetooth will rock now on debian as well [11:49] thats why we moved it to common now [11:49] asac__, the last thing that needs fixing is the rfkill thing [11:49] asac, so this line I get rid of: MOZ_XPI_FILE := refractor.xpi [11:49] asac__, are the patches you applied the ones taken from the new upstream release? [11:49] av`: do what we did [11:50] av`: no i didn them before ... then he did it on his own [11:50] they are more or less equivalent [11:50] but i have to rebase them to say if anything is left [11:50] the leak is probably still left [11:50] asac__, I wanna keep in sync debian's package with ubuntu [11:50] but also he took some other approach ... so not sure [11:50] so we don't diverge it [11:50] currently we are ahead [11:50] we have 2.28.3 [11:50] so you can just upload the ubuntu package [11:51] then its your decision [11:51] and ubuntu has 2.28.1 [11:51] i wont check for debian stuff on my own :) [11:51] av`: yes. but because you bumped th eversion [11:51] so add the .rules file [11:51] asac__, the 2.28.3 release integrates the crash fixes you applied I guess [11:52] so apart the .rules thing it's the same [11:52] i said something different above [11:52] 12:50 < asac__> but i have to rebase them to say if anything is left [11:52] 12:50 < asac__> the leak is probably still left [11:52] 12:50 < asac__> they are more or less equivalent [11:52] 12:50 < asac__> but i have to rebase them to say if anything is left [11:52] 12:50 < asac__> the leak is probably still left [11:52] asac: commenting out MOZ_XPI_FILE didn't help [11:52] yeah, but you'll have to adapt them to the latest release anyway [11:52] they are taken from the gnome svn [11:52] micahg: remove it [11:52] that wildcard command seems to be the issue [11:53] so they should be into the latest snapshot already [11:53] micahg: without MOZ_XPI_FILE it should use the other wildcard [11:53] $(wildcard *.xpi) [11:53] that should definitly work [11:53] but it's worth to give it a check [11:53] you just repeat what i said three times already [11:53] nope [11:53] i need to rebase them to check what is left [11:53] thats it [11:53] yep :) [11:54] i said that exactly that 4 times ;) [11:54] asac__ no go [11:54] micahg: well. how does it fail now [11:54] same [11:54] wildcard doesn't seem to expand [11:54] asac__, I gonna start doing stuff for the desktop-team with lucid [11:54] hmm [11:54] when I changed wildcard MOZ_XPI_FILE to just MOZ_XPI_FILE it got further [11:55] av`: not sure what you mean ... [11:55] asac__, e.g updating gnome stuff, merges, syncs like I do for the debian team [11:55] micahg: where does that stop then? [11:56] no [11:56] i dont like gnome stuff [11:56] well [11:56] there are neough folks doing that [11:56] some packages i do [11:56] like epiphany, etc. [11:56] asac__, seb told me the team requires some help [11:56] but synching and merges are easy enough ... so usually the gnome team can cover that [11:57] could be. but not my help ;) [11:57] i mean ... everyone needs help [11:57] i need help too [11:57] indeed [11:57] micahg: how does it fail when yo drop the wildcard? [11:57] * micahg is learning to help :) [11:57] micahg: you are helping a lot [11:57] asac__ rebuilding now :) [11:58] No rule to make target `install-refractor.xpi-stamp', needed by `xpi-install' [11:58] asac__, actually I saw tons of uploads made by robert [11:58] it doesn't seem to expand the % [11:58] av`: yes. he is sebs helper [11:58] asac__, so I guess that he can't do everything alone with seb [11:59] why do you discuss that with me ;) [11:59] there surely is need for more folks helping out [11:59] asac__, you said before ' there are neough folks doing that' [11:59] seb and me and a few others work more like 14h a day in average ;) [11:59] yes. there are enough folks so i dont need to drop my other work and help our there [11:59] so I thought that means no help is required [11:59] out there [11:59] asac freeze in 10 seconds... [12:00] freeze? [12:00] universe freeze [12:00] ah [12:00] ok [12:00] ScottK said we could fudge a little [12:00] i think it shouldnt be a problem [12:00] but what do you think of that next error I posted [12:01] asac__, I'm seeing you a bit nervous today, slept bad? [12:01] micahg: i think unzip-%-stamp: $(XPI_FILE) [12:01] didnt work [12:01] micahg: are you sure there is a .xpi on top level dir? [12:01] yes [12:02] av`: i dont see me nervous :) [12:02] I see refractor.xpi in the top dir [12:03] yeah [12:03] let me check it. have absolutely no idea from here what it could be [12:04] * asac__ branches micah branch [12:05] odd the version in changelog does not match the version produced by get-orig-source [12:05] yess [12:06] feels like moz-devscripts is wrong there [12:06] that's a problem with svn devscript maybe? [12:06] i mean the version [12:06] I changed it to 1.0~b2 [12:06] it should produce 1.2~b... and not 2b [12:06] asac__, how can I avoid this: https://buildd.debian.org/fetch.cgi?&pkg=gnome-bluetooth&ver=2.28.3-1&arch=ia64&stamp=1256303819&file=log [12:06] yeah [12:06] asac__, it fails to build on ia64 cause of that [12:06] asac__, e.g missing network [12:06] asac, also get-orig-source failed until I made the dir [12:07] how anoying ;) ... why does debian use https for that? ;) [12:08] av`: usually thats done using some catalog file [12:08] av`: the current build seems to need network access [12:08] which is bad [12:08] asac__, is there a way to fix that? [12:09] i havent used xsltproc lately, but other xml/xslt things can use a catalog file so they dont try to lookup stuff remotely [12:09] question is why it works on other buildds [12:09] yeah :) [12:09] i dont know that [12:09] maybe xsltproc is OK with a "no net" error, [12:09] but not if its a HTTP error like that [12:10] check with the ia64 porters [12:10] this could be a buildd bustage [12:10] at least if you are sure [12:10] it built fine on ubuntu [12:10] ia64 [12:10] that it works on other buildds its likely a buildd configuration that is different [12:10] av`: not sure. do we produce those docs? [12:10] in ubuntu? [12:11] if we do then yes. [12:11] try to find the owner of those machines and bug him ;) [12:11] cool, debian is fixing secure delete in sqlite [12:11] good [12:11] asac__, problem is pkern is now filing an RC bug against my package [12:11] cause it shouldnt require network access [12:11] but why it works everywhere and fails there [12:14] yes. network-access is probably bad [12:14] i agree with that [12:14] but as i said [12:14] maybe it has no problem if ther eis no net [12:15] but has a problem if there is some kind of net [12:15] that gives bogus stuff [12:15] like here [12:15] so it could be that the problem is that the ia64 builder has a bad network setup [12:15] av`: you can easily test ... tear down all your network [12:15] and see if it works [12:15] if so, its a ia64 buildd setup problem imho [12:16] you're right [12:16] I should test if it builds [12:16] without network [12:16] micahg: so with refractor.xpi being in place at the start it works [12:16] * av` grabs the sources [12:16] what, how? [12:16] micahg: try a debuild -b ... then after the fail, run debuild -nc -> success [12:17] so problem really is that the XPI_FILE thing gets somewhat evaluated too early [12:17] asac__, brb, shutting down my network [12:17] the odd thing is that it works for things that specify a build command [12:18] like all the other extension packages [12:18] asac__: is there a pre-build arch? [12:18] so $(wildcard file.xpi) -> empty if that file doesnt exist yet [12:18] but it doesnt exist for other extenion packages [12:18] micahg: touching a file would be a hack. and we dont do that for other packages [12:19] i think the only difference is that we have no build command [12:19] I'm saying, can we move the copy up? [12:20] ok, I'm testing installing now [12:21] micahg: no ... refractor.xpi gets produced during build [12:21] so its not there in pre-build:: [12:21] or something [12:21] you can run a touch refractor.xpi there most likely [12:21] ;) [12:21] but thats a hack [12:22] ok trying something [12:22] asac__, builds fine *without* network access ;) [12:23] well, the.debs seem to work [12:23] av`: ok then setup a proxy on that host that gives you HTTP/1.1 504 Gateway Time-out [12:23] although the window might not be wide enough [12:23] asac__, a proxy that doesnt work then [12:24] av`: e.g. setup a host with http proxy, but no other network [12:24] yeah. i think setting up a proxy on localhost [12:24] k [12:24] and then tearing donw the network will give that timeout [12:24] and i expect that xsltproc will then baild out [12:24] because it gets a real http error [12:24] rather than a network error [12:24] done [12:25] closing down network [12:25] brb [12:25] av`: if you run wget http://www.google [12:25] you get the same error [12:25] then you are ready for test [12:25] bdrung: there? [12:25] asac: yes [12:26] any clue why XPI_FILE gets evaluated early for prism, but late for all the other stuff? [12:26] e.g. for prism its always empty [12:26] prism has a NULL build command [12:26] thats the only difference i can see [12:26] do you have a link to the sources? [12:27] http://bazaar.launchpad.net/~micahg/prism/prism-1.0b2-karmic/revision/117 [12:27] bdrung: you want a full tree that you can debuild? [12:27] let me get that for you [12:27] that would be nice [12:28] tarball here: https://edge.launchpad.net/~micahg/+archive/mozilla-test/+files/prism_1.0~b2+svn20090813r49078.orig.tar.gz [12:28] http://people.canonical.com/~asac/tmp/pp.tar.gz [12:28] hmm [12:28] ok [12:28] the pp.tar.gz is a build tree you can use for debuid -.b [12:29] bdrung: so only difference i see is BUILD_COMMAND=0 ...with using common-post-build-arch to do that [12:29] asac__, it built fine anyway [12:30] it worked with a proxy as well === av`_ is now known as av` [12:30] going to eat, brb [12:30] asac, while he's looking into that, can you see if anything needs to be done with bug 217908 before release? [12:30] Launchpad bug 217908 in cairo "FFe: Pixellated Images in Firefox/Opera due to incorrect EXTEND_PAD implementation in several video drivers" [High,Fix released] https://launchpad.net/bugs/217908 [12:30] k [12:31] that should clearly happen upstream [12:31] yeah, and upstream still seems to be working on it [12:31] exactly. so the story here is that the fix only works with most recent X server [12:32] which is fine for karmic, right? [12:33] * bdrung builds it now. [12:34] I'll let ScottK know [12:35] once upstream issue landed on trunk [12:36] i can at least think about trying to cherry pick that here [12:36] but before that its tough ;) [12:37] so, it's not blocking release is it? [12:43] no [12:43] ok [12:43] is a visual glithc [12:43] asac, I have one more big bug you should look at: bug 453616 [12:43] Launchpad bug 453616 in firefox-3.5 "abrowser depends on abrowser-3.5-branding but it won't be installed" [Undecided,Confirmed] https://launchpad.net/bugs/453616 [12:43] Is the problem with synaptic? [12:44] aptitude properly suggests the install [12:44] workd for ms [12:44] me [12:44] in synaptic? [12:45] i would think its a old bug [12:45] hmm [12:45] when did i do th elast firefox update? [12:45] when I marked abrowser for installation, it didn't work [12:45] last week? [12:45] I just tested it an hour ago [12:45] yeah [12:45] with the latest updates [12:45] so thats where i fixed a few abrowser issues [12:45] hmm [12:45] sudo apt-get install abrowser-3.5 works [12:45] sudo apt-get install abrowser works [12:46] yes, but the bug was reported with using synaptic [12:46] SHould I move to synaptic and subscibe mvo? [12:46] micahg: does apt-get work for you too? [12:46] e.g. just try to run it and see if it complains or would allow it [12:46] asac: the common-post-build-arch produces this issue. workaround: "MOZ_XPI_FILE := dist/xpi-stage/refractor.xpi" [12:46] no [12:47] sudo apt-get install abrowser fails [12:47] asac: fyi the clean rules does not clean enough [12:47] right [12:47] so thats working for me [12:47] and synaptic too [12:47] weird [12:47] micahg: what packages do you have instlaled? [12:47] dpkg -l firefox\* [12:48] http://pastebin.com/f4d222bc3 [12:57] micahg: what is the exact error? [12:57] if you run apt-get install ... [12:58] bdrung: why does it the early evaluation happen if we have common-post? [12:58] and why would the $(wildcard dist/xpi-stage/refractor.xpi) be not empty? [12:58] oh ... did we hook up the stuff in common-post ? [12:59] hmm [12:59] then we can probably also do it in build/prism:: [12:59] testing build in ppa [12:59] asac http://pastebin.com/f312e6403 [13:00] pastebin is for abrowser [13:00] micahg: try apt-get install abrowser-3.5-branding and see what that gives you [13:00] ah [13:01] abrowser-3.5-branding: Depends: firefox-3.5 (= 3.5.3+build1+nobinonly-0ubuntu2) but 3.5.3+build1+nobinonly-0ubuntu6 is to be installed [13:01] because I have the security PPA enabled I think [13:01] at 501 [13:01] micahg: maybe some pinning? [13:01] yeah [13:02] ok ... probably means that the pinned archive doesnt have that trantiion [13:02] transition [13:02] so it it security? or somehting else that is pinned to ubuntu2? [13:02] no, it has abrowser [13:02] micahg: so yeah [13:03] testing [13:04] http://pastebin.com/f22dbabc7 [13:04] thats what i would suggest for prism [13:04] currently trying [13:05] oh [13:05] I changed MOZ_XPI_FILE as bdrung suggested and then got rid of the cp command [13:05] seems that the evaluation of XPI_FILE is somewhat hooked into the common-post [13:05] i would think the build/... is better [13:06] as its better suitable as an example [13:06] ok [13:06] for other packages that dont have a build command [13:07] trying again... [13:09] micahg: so is the abrowesr issue gone with all up-to-date? [13:09] didn't test that yet [13:09] kk [13:09] had to upload new version of prism :) [13:09] micahg: imo the bug was fixed [13:09]