=== stevel__ is now known as stevel [04:32] asac [04:32] you there? [04:38] LLStarks: can I help with something? [04:38] did that new build work? [04:39] is it merged? [04:39] i was wondering if the "set as background" is firefox or ubuntu-added code. [04:39] no, on the mozilla bug, one of the developers posted a new build to try for the 1.9.1 branch [04:39] asac wanted to get the patch in upstream if at all possible [04:40] there will be a 3.5.4 release before karmic is released [04:40] oh, he asked for it in 3.5.5 [04:40] which bug? [04:40] mozila bug 486065 [04:40] mozilla bug 486065 [04:41] * micahg kicks ubottu [04:41] Error: Launchpad bug 486065 could not be found [04:41] Mozilla bug 486065 in Layout: Block and Inline "hidden scrollbars get drawn anyway when Gtk theme gives scrollbars borders" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=486065 [04:42] is either fix in the umd? [04:44] LLStarks: not yet [04:44] lemme try that other fix. [04:44] LLStarks: can you download the build from the link in the mozilla bug to see if the problem still exists? [04:46] it doesn't. [04:46] does it fix either of the issues? [04:46] does asac know about the second fix? [04:46] idk, he was pinged and he got a copy of fthe mozilla bug [04:46] it fixes the trough-border boxes, not click events. [04:47] LLStarks: I don't know if it was meant to fix click events [04:47] but can you reply in the mozilla bug with that? [04:47] at least maybe we can land the trough-border fix for 3.5.5 [04:50] maybe [04:51] is asac in touch with other people on the art team besides psyke? [04:51] idk [04:53] did you see the patches for 486065? [04:54] yeah, one was the one I used in my test build, the other was code a little later [04:54] the ones posted this evening? [04:56] no [04:56] I didn't see new posts this evening [05:00] there were a few [05:01] also, did you put in a merge request for the modified trough-border fix? [05:01] yes, but I think asac would rather do it this way [05:05] LLStarks: sorry, pulled my cable out by accident === micahg1 is now known as micahg [05:05] what way? [05:06]  yes, but I think asac would rather do it this way [05:06] LLStarks: try to get the patch in upstream [05:06] ah [05:07] LLStarks: more local patches means more maintenance for us [05:08] i see [06:31] asac: will need to talk to you this afternoon regarding bindwood and dev scripts 0.16 === asac_ is now known as asac === micahg1 is now known as micahg [07:47] morning === dpm__ is now known as dpm [10:16] https://build.mozilla.org/tryserver-builds/dholbert@mozilla.com-try-b28226f038b0/ [10:17] hi asac === micahg1 is now known as micahg [10:18] asac: LLstarks tried it and said it worked correctly [10:19] he should be more verbose [10:19] in the upstream bug [10:19] I saw that but didn't know how much he needed to say [10:19] Yes, it is fixed most likely means that he tried the buiöld [10:19] yeah, I was chatting with him earlier [10:20] well. you need to be clear about a) what is fixed ... b) when is it fixed [10:20] ok [10:20] did he try the tryserver build for instance [10:20] could also be he just lurked on the bug and commented that its fixed in 3.7/3.6 [10:20] yes, he tried the special build that dholbert posted [10:21] sure. but thats not clear from his comment [10:22] anyway. in case they dont take it upstream we need to take the other patch too that dbaron referred to [10:22] ok, should I add that to the patch I made? [10:22] not sure. so far it sounds like they are not against taking that on 1.9.1 ;) [10:22] we should just not forget in case we have to do that on our own [10:22] yeah, they seem to be willing [10:22] ok [10:23] asac: if we didn't split out xulrunner, could we jump versions with an SRU? [10:23] "jump version" means what? [10:23] major version update? [10:23] yep [10:24] we can also do that with xulrunner split out if its really needed [10:24] well, I'm thinking LTS [10:24] but until 3.0 is not end of life its nothing we do [10:24] yeah [10:24] i am thinking about that every second day ;) [10:24] 3.7 should be close to ready for Lucid [10:24] ah [10:24] but that will only last for about a year [10:25] yeah. for lucid i am currently leaning towards getting xulrunner out of ffox [10:25] howver, the next problem we will face is hardy [10:25] so by 11.10, we'll be in trouble with browser support [10:25] yes [10:25] 3.5 will only last until 10.04 [10:26] so even that's not a good solution [10:26] we will have trouble with browsers upport in 10.01 ;) [10:26] micahg: 3.5 will be EOL 6 month after 3.6 is out [10:26] well, I was saying even if we could push 3.5, it won't solve the problem [10:26] yes, which will be around 10.04/05 [10:26] thats 10.06 _if_ they release in december ... which i dont think will happen [10:26] hi asac :) [10:26] hi# [10:27] oh, BTW, can we get 3.6 in karmic? [10:27] universe [10:27] micahg: we need to go through the rdepends of xulrunner-1.9 and firefox-3.0 one more time. then remove those [10:27] and then we can try to get freeze exception [10:28] ok, so only 2 versions per release? [10:28] yeah. even that is too much work [10:28] ok [10:28] and given how much folks rant about the naming of 3.5 in jaunty i am not sure its worth it ;) [10:28] but well. [10:28] I'll try to look at that next week, they said 3.6b1 around oct 13 [10:29] thats ok. [10:29] i am just concerned to get the other stuff out [10:29] i will do a hard transition for ffox 3.0 after beta [10:29] but xulrunner 1.9 needs to be reviewed [10:29] ok [10:29] e.g. is there still something not ported to 1.9.1 [10:29] i dont think there is something missing [10:29] bt could be that something sneaked in [10:30] after i made the list of the stuff that needs to be ported [10:30] https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-firefox-3.5 [10:31] what you could do is check https://edge.launchpad.net/~asac/+archive/sandbox [10:31] there is a classpath build [10:31] that somewhat failed on builders [10:31] i am sure it built locally [10:31] thats the last thing to get rid of xulrunner _1.8_ [10:32] De-libxul-dev'ification (LP: #352968): [10:32] * debian/control: build-depend on xulrunner-dev (and not libxul-dev) [10:32] checking for gtk+-2.0 >= 2.8 gthread-2.0 >= 2.2 gdk-pixbuf-2.0... Package @GDK_PRIVATE_PACKAGES@ was not found in the pkg-config search path. Perhaps you should add the directory containing `@GDK_PRIVATE_PACKAGES@.pc' to the PKG_CONFIG_PATH environment variable Package '@GDK_PRIVATE_PACKAGES@', required by 'GDK', not found [10:32] configure: error: Library requirements (gtk+-2.0 >= 2.8 gthread-2.0 >= 2.2 gdk-pixbuf-2.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. [10:32] make: *** [config.status] Error 1 [10:32] not sure what that is [10:33] either we really lack some builddepends [10:33] or the control file is busted or something [10:33] or some .pc file in my ppa [10:34] let me retry the amd buid [10:34] build [10:34] i had some gtk hacking package in sandbox at that point [10:34] not sure if that was bogus [10:35] asac: I created branch and tested my package with 'debuild -b'. Created deb package and tested install. Working great. Next step? [10:36] sevoir: push the branch somewhere [10:36] (e.g. publish) [10:36] so we can review [10:37] it's here: https://code.launchpad.net/~sevoir/firefox-extensions/firefox-ubuntu-hu-menu.ubuntu [10:37] yeah. usually you would post that in your NEED PACKAGING bug too [10:38] ok. I post it. [10:38] * asac cannot look because launchpad gives internal error [10:38] i will check later [10:38] ah now it works [10:38] * Initial release. (Closes: #422206) -> thats the debian bug syntax [10:38] for launchpad its: LP: #XXXX [10:39] firefox-ubuntu-hu-menu (1.7.0.0 -> thats a native version ... use a upstream + ubuntu revision approach [10:39] like 1.7.0-0ubuntu1 (if your upstream relesae is 1.7.0) [10:39] Maintainer: Szenográdi Norbert Péter [10:39] put yourself in XSBC-Original-Maintainer [10:40] and use Mozilla Extensions Developmenet Team <....> as Maintainer: [10:40] Vcs-Browser: https://code.launchpad.net/~sevoir/firefox-extensions/firefox-ubuntu-hu-menu.upstream [10:40] -> dont use upstream branch [10:40] also use the projected release branch [10:40] which will be either ~ubuntu-dev or ~mozilla-extensions-dev [10:40] same for Vcs-Bzr [10:40] sevoir: ^^ [10:41] ahhh [10:41] :D [10:41] learning, learning, learning [10:41] ;) [10:41] in debian/copyright -> dont put a full GPL copy [10:41] if your license is in /usr/share/common-licenses [10:41] just refer to that file [10:42] and only put a short header in copyright file [10:42] sevoir: you say that your import is 1.7.0.0 ... but your install.rdf says version=1.7 [10:43] MOZ_XPI_EMID := {8c08a1b5-387b-4486-b4e3-77786ff7fd16} [10:43] is that needed? [10:43] in most cases it should just work without that [10:43] okay, I check these errors now. [10:43] sevoir: thats it ... oh. since you are upstream, please please pretty please put your LICENSE in the top level upstream .xpi [10:44] (also would be in the import upstream) [10:44] thx [10:49] sevoir: thanks. btw, even i had a lot comments its not bad ;) ... so keep up the work!! [10:51] just the first is hard, after more easier :-) [10:52] yep [10:52] I dont give up, I would like to see my extensions in repository :P [10:53] sevoir: oh..we shouldnt use the firefox prefix i would think [10:53] ubuntu-hu-menu is okay? [10:53] we are currently working with debian on a standard [10:54] that standard says that the binary package should be xul-ext- [10:54] prefix [10:54] some stuff for the new standard is http://wiki.debian.org/Teams/DebianMozExtTeam [10:55] but dont take everythig for granted there yet ;) [10:56] many info :D [10:57] yeah [10:57] just address the comments i had [10:57] the XPI.TEMPLATE you used should have most stuff proper [10:57] so you should be fine in general ;) [11:24] bazaar not work ? [11:25] bazaar works [11:25] not sure what you mean [11:25] ;) [11:25] ERROR: Connection error: while sending POST /~mozillateam/firefox-extensions/XPI.TEMPLATE/.bzr/smart: [Errno 113] [11:25] :o [11:25] not sure [11:25] what url are you triny got push to? [11:26] e.g. you should not push to XPI.TEMPLATE [11:26] thats for sure [11:26] bzr branch http://bazaar.launchpad.net/~mozillateam/firefox-extensions/XPI.TEMPLATE [11:27] but this okay, I copied other dir. [11:27] I cant put my branch [11:27] bzr push bzr+ssh://sevoir@bazaar.launchpad.net/~sevoir/firefox-extensions/ubuntu-hu-menu.upstream [12:10] asac, do you know of any waterfall like tool for bzr and/or pbuilder? [12:11] fta2: i know the waterfall model ;) [12:11] i'd like to setup something like that to do continuous builds and track perf & memory per commit [12:12] you want to do those per-commit builds in ppa ;)? === jtv is now known as jtv-afk [12:19] asac: new debian/copyright file is okay? : http://paste.ubuntu.com/282916/ [12:20] i think so [12:20] and new debian/control file: http://paste.ubuntu.com/282917/ [12:21] sevoir: have you checked our ubuntu-it-menu ? [12:21] yes [12:21] but only license file [12:22] I check ubuntu-it-menu debian/copyright file [12:22] ok [12:22] sevoir: how did you produce the orig tarball? using med-xpi-unpack? [12:23] the package from addons page > xpi unpack [12:24] yeah [12:24] good [12:24] sevoir: so the top level license file should be included in your addons .xpi [12:24] like license.txt ... or COPYING in the top level of the xpi [12:25] makes it easier ;) [12:26] I have license file in http://bazaar.launchpad.net/~sevoir/firefox-extensions/ubuntu-hu-menu.upstream/files [12:26] this from ubuntu-it-menu ;-) [12:28] it's wrong or wrong place? [12:51] that lnk doesnt work [12:51] if its in top level dir of the upstream tree then its fine [12:57] asac: please check it now: https://code.launchpad.net/firefox-extensions [12:58] it think, these same as ubuntu-it-menu [12:58] -t [13:41] asac, no, not in a ppa, this is not open source, at least not yet [13:56] not that i don't want it to be... [14:35] asac: I think its done, buildeb -b working fine. Deb is okay, installable [14:44] sevoir: thx. i will check that in a few [14:44] ok, Im waiting [14:44] thx [14:47] sevoir: ok i requested review from myself and bdrung on your branch [14:47] https://code.edge.launchpad.net/~sevoir/firefox-extensions/ubuntu-hu-menu.ubuntu/+merge/12718 [14:47] you should get mails with our comments etc. [14:48] okay. and I subscribed to mailing list too ;-) [15:11] sevoir: i made a quick comment up front ... but wait a bit till bdrung_ had a look at it too [15:11] fta2: wlll you drop the python-tlslite depends in chromium? [15:11] or shall i? doko said you said its not needed anymore [15:12] asac, it's used as a 3rd party because i dropped the tiny patch needed to use the system one [15:13] it's just a matter of /usr/bin/tls (policy compliant) vs /usr/bin/tls.py (expected by chromium) [15:14] doko 1st wanted that package into the distro, until he realized the last version was from 2005 [15:15] okay [15:16] asac: but If my extension contain a jar file, what can I do? should I unpack and upload it? [15:22] sevoir: yes, unpack it (already in the source file) [15:23] sevoir: you produce the upstream tree by just running med-xpi-unpack [15:23] with the .xpi [15:23] ok, I check it now [15:24] fta2: ok great. point is that we still build-depend on it. so we can just drop it? [15:24] or is there anything needed (like tls.py link) [15:26] by default, the install rule creates /usr/bin/tls.py, that's why google expects it, but it's not compliant with the debian policy to put *.py, *.sh, *.pl in /usr/bin, so i changed it, but it needs a patch in chrome, which i had for a long time, until i removed it for a reason i don't remember [15:27] so either i re-add this patch and we can drop a 3rd party dir, or i drop the build-dep and keep that 3rd party [15:30] bdrung_ , asac: unpacked and uploaded [15:52] bye all [15:52] I will come back tomorrow :) [16:09] am i here? [16:09] !test [16:09] yes, I'm alive. [16:09] good [16:16] am I? [16:16] i've disconnected for a while [16:19] fta2: you are ;) [16:19] !test [16:19] yes, I'm alive. [16:19] seems to be a good test ;) [16:19] yep [16:34] fta2: what would be the implication of dropping the build-dep ... would we still ship tls.py in usr/bin ? [16:34] if not then we definitly want that [16:34] dtchen: not sure if that is sound related, but i think so. [16:35] dtchen: yesterday i upgraded my X61s lenovo thing [16:35] no, it's just used during the tests, it's not shipped [16:35] dtchen: (one week suspended) [16:35] dtchen: now it makes some strange click sounds [16:35] no really sure when it does that [16:35] but it definitly happens from time to time [16:35] something every other minute [16:35] fta2: good. will you drop the build-dep? [16:36] and repush (if the builders are not too busy) [16:36] why repush? is there an emergency or something? [16:41] fta2: no. [16:41] fta2: just thought we would know if it fails earlier [16:41] committed [16:41] otherwise just keep it [16:41] we will see tomorrow [16:42] i made the test failures non fatal anyway, should not be a problem [17:30] hey asac you there [17:42] asac: is it normal for an extension to not work one min then work another. cuz today i got on linux at school and i tried out firefox and as soon as i got on bindwood which i built using devscripts 0.16 worked O_o without adding any extra lines as mentioned in the wiki [19:15] asac, http://www.sofaraway.org/ubuntu/tmp/chromium-verbose.png *sigh* [19:47] fta: heh. make the font smaller ;) j.k. [20:00] asac: you still here [20:00] did you see my message that i left you earlier [20:06] i dont understand the question [20:07] works != is proper [20:07] its usually less [20:58] hey every one. guud evening [20:58] fta: chromium is stupid [20:58] a single download is hogging one of my cores [20:58] luckly since it has PID separation [20:58] I can run it with CPU limit -l 20 :) [20:59] BUGabundo: it is a nightly [20:59] always daily :) [20:59] also this morning version had some bug with cookies [21:02] asac: now time to sync m-d [21:17] BUGabundo, don't tell me, find existing bugs or file one [21:31] (re) BUGabundo, don't tell me, find existing bugs or file one [22:49] asac: can bug #440239 be ff fault? [22:49] Launchpad bug 440239 in pwdhash "< key not dead" [Undecided,New] https://launchpad.net/bugs/440239