[00:47] fta: asac: any ideas on how to get FLASH to "see" my webcam ? === ripps is now known as ripps|sleep === asac_ is now known as asac === mac_v_ is now known as \vish [13:48] * jdstrand wanders in [13:48] hi jdstrand [13:48] o/ [13:48] jdstrand: can I ask you a few questions? [13:48] hi jdstrand ;) [13:49] asac: hi [13:49] micahg comes first ;) ... second, i hoped you could bin NEW kick netbook-launcher-efl ;) [13:49] micahg: if they are amazingly fast-- I've gotta head out in under 5 [13:49] hmm [13:49] :-P [13:49] asac: netbook-launcher-efl accepted [13:49] * asac dances [13:50] jdstrand: did you intend apparmor to be on by default for 3.6 and 3.7 dailies? [13:50] * asac would assume yes. [13:51] micahg: only if the 3.5 profile was already on [13:52] jdstrand: my 3.7 is enabled even though my 3.5 was disabled [13:56] micahg: that is the type of question I don't have time to answer. the basic idea is that if the last apparmor profile matching /etc/apparmor.d/usr.bin.firefox-*[0-9] is not disabled, enable the new profile [13:56] jdstrand: ok, can I ping you later? === mac_v is now known as \vish [13:56] sure [13:56] micahg: what is the output of this command: [13:56] ls -rt /etc/apparmor.d/usr.bin.firefox-*[0-9]| tail -n1 [13:57] /etc/apparmor.d/usr.bin.firefox-3.5 [14:00] micahg: what is the output of this command: test -e /etc/apparmor.d/disable/usr.bin.firefox-3.5 || echo enabled [14:00] nothing [14:00] * micahg thinks it's still enabled since I was testing some apparmor stuff [14:00] but when I installed 3.7 originally it was disabled [14:01] micahg: if you can try it in a chroot or vm, that would be great [14:01] (I did( [14:01] (I did) [14:01] ok [14:02] micahg: feel free to look at debian/firefox-3.7.preinst.in as well [14:02] there could be a bug [14:02] jdstrand: ok, I'll try to take a look later [14:02] thanks [14:03] asac: are we going back to firefox as a source package name? [14:03] micahg: keep in mind, it isn't 3.5 specific-- eg, if you have 3.5 disabled, but 3.6 enabled, it will enable it for 3.7 [14:03] of if you had 3.6 disabled, but 3.5 with modifications enabled, it will enable [14:03] jdstrand: ok, but my 3.6 doesn't have apparmor yet (running beta 5) [14:04] sure, just pointing out what it is doing [14:04] micahg: most likely. i think about firefox firefox-next firefox-trunnk .... but not really sure if that is enough [14:04] * micahg will have to run some tests [14:04] * jdstrand -> outta here [14:04] jdstrand: have a great new year ;) [14:04] see you around in a few [14:04] asac: thanks! you too :) [14:05] micahg: waiting for upstream decision what they plan for branches etc. [14:05] mconnor said its soon TBA [14:05] so i thought better wait before having to throw away everything again [14:05] asac: ok, great, in the mean time, I'm leaving bugs in firefox-3.5 for 3.5+ [14:05] yeah === mac_v is now known as \vish === \vish is now known as mac_v === mac_v is now known as \vish === ripps|sleep is now known as ripps [15:58] asac: it looks like the TB31 binary isn't being created === micahg1 is now known as miCHg === miCHg is now known as micahg [16:17] micahg: is it in dist/bin ? [16:17] asac: where should that dist dir be? [16:18] micahg: build-tree/mozilla/dist/bin ... or mozilla/mozilla/dist/bin [16:18] not sure [16:18] there's no dist in the /usr/libtb31 [16:18] in the build tree [16:18] there's no dist dir [16:19] asac: I found it [16:19] yes. so mozilla doesnt care about make install [16:19] asac: so, do I have to have our scripts copy it from dist/bin? [16:19] they produce stuff in dist/bin [16:20] so if it is there then the make install target is broken [16:20] no [16:20] its upstream build system that is supposed to copy that [16:20] ok [16:20] ask in maildev. those are the folks that did their own build system stuff [16:21] its not the same as xulrunner afaik [16:21] asac: it's looking for thunderbird-3.1 in dist/bin and only gets thunderbird [16:21] ah [16:21] yeah [16:21] thats a problem with APP_NAME somewhere [16:21] we have a patch for that, right? [16:21] that probably needs to also patch a new file [16:22] yes [16:24] we seem to be changing the moz app name [16:25] but we do it in 3.0 and it works [16:25] I guess I have to go see what changed upstream the day it broke, right? [16:30] micahg: upstream changed something that requires the patch to be adjusted ... yes. [16:39] asac: they landed the unofficial branding but it was not enabled yet [16:41] micahg: link to commit? [16:42] asac: actually, I think it was something different [16:42] they moved to a single manifest install [16:42] http://hg.mozilla.org/comm-central/rev/c87ebb61ec41 [16:45] micahg: didnt that happen to ffox 3.7 before? [16:45] anyway ... i think you can fix DEFINES += -DAB_CD=$(AB_CD) -DMOZ_APP_NAME=$(MOZ_APP_NAME) -DPREF_DIR=$(PREF_DIR) [16:45] instead of the manifest [16:46] should be "easier" to maintain it there [16:46] here's the unofficial branding commit: http://hg.mozilla.org/comm-central/rev/328bf422b19a [16:50] asac: what's AB_CD? [16:54] micahg: its en-US for us [16:54] mozilla spins full builds for each locale [16:54] thats the locale [16:54] we build everytihng with en-US afaict [16:56] ah, the localization [16:56] yes [16:56] so, I just need to change $(MOZ_APP_NAME) ? [16:58] i would think you should use -DMOZ_APP_NAME=$(MOZ_APP_NAME)-3.1 [16:58] changing MOZ_APP_NAME everywhere will probably cause bad issues [16:58] ok, I'll make the change a little later an try to test before the bot spins tonight [16:58] in the long run moz biuld system should have MOZ_PROG_NAME rather than MOZ_APP_NAME imo [16:59] sounds good [16:59] asac: should I file a bug for that [17:07] i doubt they will work upstream on that [17:07] if we have a patch we should open a bug and get it approved [17:10] * micahg doesn't know enough yet to make a patch for that [17:11] bbiab [19:22] asac: around? [21:16] bdrung_: for a moment [21:16] not sure i can really contribute though [21:17] asac: I think he wanted to ask about the stuff he sent to the ML [21:17] asac: i have a discussion about XB-Xul-AppId on #debian-devel [21:18] asac: what do you think about http://bazaar.launchpad.net/~mozillateam/firefox/firefox-3.5.head/revision/508 ? [21:19] bdrung_: can you please propose merges if you are unsure ;) [21:20] we only need Eol? [21:20] asac: i was sure, but then the discussion start and now i am back at the start. [21:20] which discussion? [21:21] can you summarize in one sentence? [21:22] asac: summary: we can't rely on /var/lib/apt/lists/*_Packages [21:24] why would we? [21:24] bdrung_: ? [21:24] we can even automaintain a list in the archive [21:24] asac: for dynamically generating a list of xul apps: http://bazaar.launchpad.net/~mozillateam/mozilla-devscripts/dh_xul-ext/annotate/head%3A/src/dh_xul-ext [21:24] just that we regularly update it [21:25] bdrung_: you can do that in python directly [21:25] well. not on the builders [21:25] which was the blocker;) [21:25] so yes. the list would be in a archive package and then that list would be regularly updated [21:26] does that make sense? [21:26] the headers are easy to add to apps. and gives maintainers a way to automatically update the entries appropriately [21:26] on top you can include thirs party repositories etc. [21:26] asac: that was one idea [21:26] beceause you would use a list of sources rather than what is in debian [21:27] sure. so go for that. the python script that des the magic of pulling down apt indexes and extracting information is in the ubufox database updater