[02:30] <fta> crimsun, bug 311334
[04:03] <crimsun> wrong package, but ok
[04:03] <crimsun> (fixed)
[12:23]  * asac back
[12:24] <asac> white: thanks
[12:24] <asac> let me know ... i will start to work on icedove 2.....19 today
[12:24] <asac> happy new year everyone
[12:31] <fta> hi
[12:32] <fta> what is icedove 2?
[12:32] <asac> 2.0.0.19 ;)
[12:32] <asac> fta: ^^
[12:32] <asac> hi
[12:33] <fta> tb2 ?
[12:33] <asac> yeah
[12:33] <asac> white is from debian security team and also seems to be iterested in helpign out a bit more
[12:33] <fta> the package looks like my tb3
[12:33] <asac> on tbird 3
[12:33] <asac> fta: no icedove package looks like the tbird 2 packages we have
[12:34] <asac> i mean the icedove 2 ;)
[12:34] <fta> really?
[12:34] <asac> fta: of course ... i am the icedove maintainer ;)
[12:34] <asac> fta: icedove 3 doesnt exist yet ... but white wnated to look at them and i told him to base this on tbird 2
[12:34] <asac> err 3
[12:36] <fta> asac, http://paste.ubuntu.com/98974/
[12:36] <fta> looks like icedove 3 to me
[12:36] <asac> fta: nice ... seems he already diud it then
[12:36] <asac> fta: yeah
[12:37] <asac> i never questioned that ;)
[12:37] <asac> i guess the branding dir is a bit fucked still ... but that shouldnt be hard to fix
[12:37] <fta> so a mozilla-devscripts file and it rocks
[12:38] <asac> we could move it there ... but i think it makes most sense to just use tbird 3 moz-devscript stuff
[12:38] <asac> and patch the branding and so in debian/rules
[12:38] <asac> if you want to add a icedove.mk ... why not ;)=
[12:38] <asac> though i thought we wanted to stop putting more orig logic into -devscripts
[12:38] <fta> remember the project file could live in the package now
[12:39] <BUGabundo> hi
[12:39] <asac> fta: right ... thats what i would want in this case
[12:39] <BUGabundo> will someone moderate my email on the ML?
[12:39] <BUGabundo> thanks in advance!
[12:39] <fta> i mean, use a project file instead of the new stuff in the diff
[12:39] <asac> BUGabundo: i would if i could
[12:39] <asac> remember
[12:39] <asac> ;)
[12:39] <asac> the pass
[12:39] <asac> usually gnomefreak does that
[12:39] <BUGabundo> ehehe
[12:39] <asac> fta: sure. can you guide white how to do that?
[12:42] <fta> yep
[12:48] <fta> asac, but that mean m-d in debian...
[12:57] <asac> fta: thats ok
[12:57] <asac> nobody raised any real concern and even if ... ;)
[12:57] <asac> who cares?
[12:57] <asac> :-Ü
[13:05] <asac> ok 64-bit native plugin backed out :)
[13:05] <fta> why?
[13:05] <asac> because we dont have a stable URL ;)
[13:06] <asac> already discussed that right?
[13:06] <fta> oh
[13:06] <asac> also kees dumped nspluginwrapper support
[13:06] <asac> which is supposed to be optional
[13:07] <asac> fta: native will come back when adobe has final ... so we can download it from partner
[13:07] <asac> also latest nspluginwrapper is quite perfect
[13:07] <asac> shouldnt make much a difference anymore ... except that ffox doesnt crash
[13:09] <asac> fta: give it a try on 32-bit
[13:09] <asac> for me it just rocks ;)
[13:34] <fta> is there a cdbs hook for lintian?
[13:35] <fta> i mean, an existing .mk
[13:35] <asac> fta: in which way?
[13:35] <asac> so that it gets run automatically?
[13:35] <fta> just build-dep on lintian, include a file and done
[13:35] <fta> yep
[13:35] <asac> fta: purpose: run auto?
[13:35] <asac> ah ok
[13:36] <asac> i dont think so ... i think the current hook is: "use debuild"
[13:36] <asac> not dpkg-buildpackage
[13:37] <asac> fta: what was the prob with mozilla bug 470379 ?
[13:38] <asac> breaks our gre patch?
[13:38] <asac> Jazzva: there?
[13:38] <asac> ;)
[13:38] <fta> well, no real problem, a chunk of code disappeared
[13:39] <fta> so part of the patch is gone now
[13:39] <asac> fta: did our code touch V10 function?
[13:40] <asac> _upgradeFromV10 i mean
[13:41] <fta> asac, http://bazaar.launchpad.net/~mozillateam/xulrunner/xulrunner-1.9.2.head/revision/396
[13:41] <Jazzva> asac: yep
[13:43] <asac> Jazzva: hi ... i uploaded nspluginwrapper ,)
[13:43] <Jazzva> asac: thanks :)
[13:43] <asac> Jazzva: we have one rather important feature we need for nspluginwrapper: auto-update of wrappers
[13:44] <asac> my current idea is that nspluginwrapper has a registry dir like: /var/lib/nspluginwrapper/wrapper.d/
[13:44] <asac> which nspluginwrapper looks at during postinst and recreates the wrappers
[13:45] <asac> i hope we can just put the wrapper.so's in there and nspluginwrapper is smart enough to find the "source" when using the -u flag
[13:45] <Jazzva> we can try that :)
[13:45] <asac> like nspluginwrapper -u /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so
[13:45] <asac> err
[13:46] <asac> but of course a different path
[13:46] <asac> nspluginwrapper -u /var/lib/nspluginwrapper/wrapper.d/npwrapper.libflashplayer.so
[13:46] <asac> if we cannput put the wrappers there directly we can have text files in there with lines like:
[13:46] <asac> /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplugin.so
[13:47] <asac> but i hope that nspluginwrapper -u just works
[13:47] <asac> (though it seems to not do anything - at least when i dont change the /usr/lib/flashplugin-nonfree/libflashplugin.so ...)
[13:48] <asac> nspluginwrapper  -v -n -u /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so
[13:48] <asac> Update plugin /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so
[13:48] <asac> nspluginwrapper  -v -n -u /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so
[13:48] <asac> Update plugin /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so
[13:48] <asac> oops
[13:48] <asac> ;)
[13:48] <asac> it doesnt touch it ... so maybe its rewally smart and checks md5sums?
[13:49] <asac> or its broken
[13:49] <Jazzva> maybe they're already updated :)?
[13:50] <asac> yes thats what i mean ... but that would mean its smart and checks md5sums ... or maybe it doesnt do anything if the api is ok?
[13:50] <Jazzva> the last time I needed to recreate wrappers was when we moved from 1.1.8 to 1.1.10
[13:50] <asac> no clue
[13:50] <asac> we should try
[13:50] <asac> yeah
[13:50] <asac> i am just curious if its smart enough or if its broken :)
[13:50] <Jazzva> let me downgrade to 1.1.8, and test
[13:51] <asac> http://paste.ubuntu.com/99011/
[13:51] <asac> thats the code
[13:51] <asac> yeah downgrade would help
[13:54] <asac> else if (strcmp(plugin_info.ident, NPW_PLUGIN_IDENT) != 0) {
[13:54] <asac> seems to do something smart at least
[13:54] <Jazzva> right, looking at that part
[13:54] <asac> else if (strcmp(plugin_info.ident, NPW_PLUGIN_IDENT) != 0) {
[13:55] <asac> oh so maybe a touch of the .so is enough
[13:55] <asac> to trigger it
[13:55] <Jazzva> brb, lunch time...
[13:55] <asac> yeah
[13:56] <asac> ok so upgrading plugins would work that way
[13:56] <asac> now just to check whether upgrading/downgradiung nspluginwrapper works too
[14:30] <Jazzva> asac, where does nspluginwrapper put its wrappers?
[14:31] <Jazzva> asac: npwrapper.libflashplayer.so -> /var/lib/flashplugin-nonfree//npwrapper.libflashplayer.so
[14:31] <asac> Jazzva: currently its undefined
[14:31] <Jazzva> but /var/lib/flashplugin-nonfree/ is empty...
[14:31] <asac> Jazzva: we can either say: they always have to be in /var/lib/nspluginwrapper/wrapper.d
[14:31] <asac> or we can say that they have to put a text file in that directory
[14:32] <asac> that describes where the parts are
[14:32] <asac> Jazzva: well ... it shouldnt be empty
[14:32] <asac> Jazzva: if you are on jaunty its because kees dropped nspluginwrapper support
[14:32] <asac> completely
[14:32] <asac> i uploaded a fixed version earlier today
[14:32] <Jazzva> ah... ok
[14:32] <asac> maybe its already on your mirror m
[14:32] <Jazzva> that explains it :)
[14:32] <asac> flashplugin-nonfree that is
[14:33] <asac> yeah ;)
[14:33] <asac> Jazzva: i think we should put the wrappers directly there
[14:33] <asac> and make a link in /var/lib/flashplugin-nonfree/flashplugin.so ... which is then used also if you dont use wrapper
[14:34] <asac> but i can fix the flashplugin-nonfree mess
[14:34] <asac> will do it when renaming the package to flashplugin-installer
[14:36] <asac> Jazzva: so the idea is to ship a script in /usr/sbin/update-npwrappers
[14:36] <asac> that updates the wrappers .... flashplugin-nonfree will then just call that in postinst
[14:36] <asac> hmm
[14:37] <Jazzva> we should still have an option for people that don't want to use npw for some reason...
[14:38] <Jazzva> can't we just call npw -u?
[14:38] <asac> Jazzva: imo thats independent ... postinst of flashplugin-nonfree should still check whether nspluginwrapper is on system before doing that
[14:39] <asac> urg ... http://paste.ubuntu.com/99048/
[14:39] <asac> fta: ^^
[14:39] <asac> whats up with launchpad cert?
[14:40] <Jazzva> asac: http://paste.ubuntu.com/99049/
[14:40] <asac> Jazzva: its a bit difficult
[14:40] <Jazzva> npw -u should work :)
[14:40] <asac> Jazzva: yeah i think thats ok
[14:40] <asac> Jazzva: i just wonder if we need more magic
[14:40] <asac> i mean: postinst would have to check whether a wrapper was already created
[14:41] <asac> question here is: does postinst know the name?
[14:41] <asac> and path ... where to look at?
[14:41] <asac> maybe nspluginwrapper should ship a ensure-npw <FILE> ... which would then do the magic of
[14:41] <asac> a) guessing whether its already wrapped
[14:41] <asac> b) run -u or -i depending on the result
[14:42] <asac> do we know whether its safe to guess the wrapper filename like: npwrapper.<ORIGINAL-FILENAME> ?
[14:43] <asac> imo we should put that logic in nspluginwrapper ... so we just have to change it at that place if that guessing changes at some point
[14:43] <fta> asac, tar: icedove-branding-2.0.0.x.tar.gz: Cannot open: No such file or directory
[14:43] <asac> fta: yeah but thats the followup issue
[14:43] <asac> fta: the issue is that bzr branch bails out due to cert issues
[14:43] <Jazzva> asac: I'll check in the source
[14:43] <asac> so i dont have a tarball
[14:44] <fta> asac, is that a signed branch ? or a branch with signed commits ?
[14:44] <asac> Jazzva: i think its curently safe ... what i mean is that we need a script to do the update-install stuff in nspluginwrapper ... so we dont have to put that guess-logic in each and every package
[14:44] <asac> fta: i think its a ssl cert issue
[14:45] <asac> because its a curl issue
[14:45] <asac> bzr: ERROR: pycurl.error: (60, 'server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt')
[14:45] <fta> do you have that file?
[14:45] <fta> i do
[14:45] <Jazzva> asac: right, we could run "nspluginwrapper -l" to check for installed wrappers, and then to run "nspluginwrapper -u" on them, if that works
[14:45] <asac> fta: try to run:
[14:45] <fta> i need to run, cu ~7pm
[14:46] <asac> sh -c "cd $tmpdir; bzr export --format=tgz --root= icedove-branding-2.0.0.x.tar.gz lp:~mozillateam/thunderbird/icedove-branding-2.0.0.x ; tar xzf icedove-branding-2.0.0.x.tar.gz"
[14:46] <asac> Jazzva: do you run jaunty? can you try the command above?
[14:46] <asac> fta: ok
[14:46] <asac> cu
[14:46] <Jazzva> asac: ok
[14:46] <james_w> bug 310675
[14:46] <asac> Jazzva: err sorry
[14:46] <asac> ;)
[14:46] <asac> Jazzva: rock thanks
[14:46] <asac> james_w: ^^
[14:47] <fta> "--root= icedove-branding-2.0.0.x.tar.gz" ?
[14:47] <asac> Jazzva: so nevermind ;)
[14:47] <asac> fta: thats ok ... it always worked
[14:47] <Jazzva> ok :)
[14:47] <asac> james_w: happy new year .... do you know that bzr bd _always_ recreates tar if we have .bzr-builddeb/default.conf magic?
[14:47] <fta> asac, http://paste.ubuntu.com/99053/
[14:47] <asac> james_w: that caused issue for me because the orig doesnt match everywhere
[14:47] <james_w> asac: yes
[14:47] <james_w> it's a known problem
[14:48] <asac> james_w: ok so its accepted as a problem. thanks
[14:48] <asac> james_w: is there a bug
[14:48] <asac> fta: yeah i was dumb
[14:49] <asac> fta: i pasted the wrong code ;) ... the code that fails uses https://code.launchpad.net/~mozillateam
[14:49] <asac> as branch
[14:49] <asac> fta: thanks anyway
[14:50] <james_w> asac: can't find one
[14:50] <Jazzva> asac: this should update wrappers, at least it seems logical to me :)... nspluginwrapper -v -n -u `nspluginwrapper -l | grep "npwrapper"`
[14:52] <asac> Jazzva: hmm ... for that we would need to teach nspluginwrappera bout our other locations
[14:52] <asac> e.g. xulrunner-addons/plugins firefox-addons/plugins/
[14:53] <asac> but i think thats the right way to go
[14:53] <asac> otoh what if users have their own wrapper installed?
[14:53] <Jazzva> shouldn't npw already know about it?
[14:53] <asac> Jazzva: how? i think the current -l logic is quiet dump. will probably scan a fixed set of directories (e.g. profile + system dirs)
[14:54] <asac> i dont think it checks whether the plugin originates from itself
[14:54] <Jazzva> ok, i'll check
[14:55] <asac> Jazzva: we could whitelist a bunch of locations
[14:56] <asac> Jazzva: but maybe we should really just do what you suggested
[14:56] <asac> and teach npw about more locations
[14:56] <asac> and later fix the "dont do that if its not generated by the packaged npw"
[14:56] <Jazzva> asac: it's in process_list, and it checks dirs returend by get_mozilla_plugin_dirs()
[14:57] <Jazzva> (in file npw-config.c)
[14:57] <asac> Jazzva: yes. do you see any meta info field that points to the npw lib?
[14:57] <asac> strings /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so | grep /usr/lib/nspluginwrapper/
[14:57] <asac> /usr/lib/nspluginwrapper/x86_64/linux/npwrapper.so
[14:58] <asac> Jazzva: ^^
[14:58] <asac> so there seems to be some meta info available that we could use to limit output of -l
[14:58] <Jazzva> ah... I see...
[14:58] <asac> of course at best fix -l itself and not write something around it
[14:58] <asac> ok lets go for it
[14:59] <asac> question now is whether we want to provide a convenice ensure-and-update-npw <FILE>
[14:59] <asac> convenience
[14:59] <asac> also we might want to have something like delete-npw <FILE>2D
[15:00] <Jazzva> NPW_PluginInfo should be the struct that holds all information about wrapper...
[15:00] <asac> yeah
[15:01] <asac> typedef struct __attribute__((packed)) { char ident[NPW_PLUGIN_IDENT_SIZE]; char path[PATH_MAX]; time_t mtime; char target_arch[65]; char target_os[65];
[15:01] <asac> } NPW_PluginInfo;
[15:01] <asac> in sysdeps.h
[15:02] <Jazzva> right...
[15:03] <asac> so is "path" the path from above?
[15:03] <asac> maybe a printf(..) would help
[15:03] <asac> ;)
[15:03] <Jazzva> asac: we could just add our dirs in "static const char *default_dirs[]" in npw-config.c, which I think we already do in one patch
[15:04] <asac> +static const char *debian_link_dirs[] = {
[15:04] <asac> thats all quiet messy imo
[15:04] <Jazzva> yeah ;)
[15:05] <asac> i think its really just a hack for the "instalL"
[15:05] <asac> doesnt register the dirs in there properly
[15:05] <asac> 000_debian_make_symlinks.diff
[15:05] <asac> or?
[15:06] <asac> Jazzva: so we have NSPLUGIN_DIR ... whiuch we use to installl "just" to a specific dir
[15:06] <asac> maybe we can just use the current dirs ... and the NSPLUGIN_DIR (if set) to implement -l
[15:07] <Jazzva> asac: btw, path field is the path to the original plugin "printf("  Original plugin: %s\n", plugin_info.path);"
[15:08] <asac> hmm
[15:08] <asac> so its not in that struct
[15:09] <asac> Jazzva: we have:
[15:09] <asac> src/npw-config.c:	&& strcmp(plugin_info.path, NPW_OLD_DEFAULT_PLUGIN_PATH) != 0;		// exclude ARCH npwrapper.so
[15:09] <asac> src/sysdeps.h:#define NPW_OLD_DEFAULT_PLUGIN_PATH NPW_LIBDIR "/" HOST_ARCH "/" NPW_WRAPPER
[15:09] <asac> src/npw-config.c:	&& strcmp(plugin_info.path, NPW_OLD_DEFAULT_PLUGIN_PATH) != 0;		// exclude ARCH npwrapper.so
[15:09] <asac> src/sysdeps.h:#define NPW_OLD_DEFAULT_PLUGIN_PATH NPW_LIBDIR "/" HOST_ARCH "/" NPW_WRAPPER
[15:09] <asac> for me this seems like plugin_info.path is really supposed to be the wrapper.so path
[15:09] <asac> and not the original plugin
[15:09] <asac> strange
[15:09] <asac> maybe there are two plugin_info ?
[15:11] <Jazzva> not sure...
[15:11] <asac> Jazzva: oh ok
[15:11] <asac> maybe the wrapper.so is a valid plugin and this function just ensures that it doesnt wrap itself
[15:11] <asac> so yeah
[15:11] <asac> so there is most likely no such info available
[15:11] <asac> too bad
[15:13] <asac> so we would need to extent this thing ... but well
[15:13] <asac> should be possible to do in future
[15:13] <asac> so nothing really blocking us imo
[15:14] <asac> Jazzva: i think if we have all right dirs registered, just running
[15:14] <asac> nspluginwrapper -u
[15:14] <asac> (without file) should just work
[15:14] <asac> well i mean its supposed to work
[15:14] <asac> ;)
[15:14] <asac> semantic like: upgrade all
[15:15] <Jazzva> asac: will work, if we change it :). I think I already tried running "npw -u" :)
[15:15] <Jazzva> npw -a?
[15:16] <Jazzva> asac: nspluginwrapper -v -a -u
[15:17] <asac> yeah ;9
[15:17] <asac> just found it too
[15:17] <asac> sudo nspluginwrapper -v -a -u
[15:17] <asac> hehe
[15:17] <Jazzva> :)
[15:17] <asac> i think we also need -n ?
[15:17] <Jazzva> which is done here: static int auto_update_plugins(void) on line 952 in npw-config.c
[15:18] <Jazzva> so, if we need to add more dirs, we can patch get_mozilla_plugin_dirs...
[15:19] <asac> yes. so hard code or use NSPLUGIN_DIRS=dir1,dir2,dir3 ... to extend that list?
[15:20] <asac> maybe hardcode and send upstream
[15:21] <asac> so adding xulrunner-addons firefox-addons mozilla and /var/lib/nspluginwrapper/wrapper.d/
[15:32] <Jazzva> asac, so are we going that way? to patch default_dirs?
[15:32] <asac> Jazzva: yep ... want to do that?
[15:32] <Jazzva> ok...
[15:33] <Jazzva> do we use /usr/lib64/firefox-addons and stuff for x64 sysstems?
[15:33] <asac> Jazzva: you could also adjust the nspluginwrapper dir used by the debian patch that creates symlinks
[15:33] <Jazzva> *systems
[15:33] <asac> it should use the wrapper.d too i think
[15:33] <asac> hmm
[15:33] <asac> yeah i thkink that would be right
[15:34] <asac> Jazzva: i think we dont need /usr/lib64/ for now ... just /usr/lib/ i think
[15:34] <asac> but we might want to revisit that situation when we come to 64-bit native plugin and stuff
[15:35] <Jazzva> asac: also, take a look at this :)
[15:35] <asac> s/situation/decision/ ;) i am stupid
[15:35] <Jazzva> asac: http://paste.ubuntu.com/99071/ hehe :)
[15:36] <Jazzva> 'n' for "native", and 'n' for "nosymlinks"
[15:37] <asac> lets use "z" then ;)
[15:37] <asac> for nosymlinks
[15:37] <asac> and send that changed patch to debian
[15:37] <Jazzva> and to also document it in print_usage
[15:37] <Jazzva> since it's documented in manpage, as -n parameter, and it's not documented in --help
[15:38] <asac> yeah
[15:38] <Jazzva> ok, I'll fix that later. I'm gonna work on school project a bit :)
[15:38] <Jazzva> so we can continue this later tonight :)
[15:38] <asac> yeah and iam going http://identi.ca/notice/1684595
[15:38] <asac> cu later
[15:38] <Jazzva> have fun, cu
[15:39] <asac> sport isnt much fun for me
[15:39] <asac> ;)
[15:39] <asac> but thanks!
[15:39] <asac> u2
[15:39] <Jazzva> heh
[15:39] <Jazzva> thanks
[18:31] <fta> crimsun, it's back ? http://paste.ubuntu.com/99150/
[19:41] <asac> fta: upload.ubuntu.com ftp is down?
[19:41] <fta> no idea
[19:46] <asac> so the glue in debian will go to icedove-dev
[19:47] <asac> as it seems
[19:47] <asac> and iceape will be dropped or EOL'ed once we find that we cannot provide sec support in lenny
[19:48] <fta> do you mean, no seamonkey at all in debian?
[19:56] <asac> yes
[19:56] <asac> nobody cares enough to prepare a build and QA that based on new tarballs
[19:57] <asac> for security updates
[19:57] <fta> maybe someone should inform upstream
[19:58] <asac> about what?
[19:58] <asac> that nobody wants to step up for iceape?
[20:01] <asac> or that they managed to make seamonkey become another victim of heavy maintenance burden due to mozilla security policy?
[20:01] <asac> ;)
[20:01] <asac> seriously, it shows how hard it is for mozilla software to stay in a distro
[20:12] <asac> Jazzva: ok so just running -u as root sounds a bit scary as it seems to update user profile wrappers too
[20:13] <Jazzva> asac: patching the source to add option --no-profile-dirs?
[20:14] <Jazzva> so, if that's set, then we can skip return of profile dir in get_mozilla_plugin_dirs :)...
[20:15] <fta> #rank name                            inst  vote   old recent no-files (maintainer)
[20:15] <fta> 4976  seamonkey-browser               9732  4262  4565   903     2 (Ubuntu Mozilla Team)
[20:15] <fta> 6136  iceape-browser                  6465   118  4236    13  2098 (Ubuntu Mozilla Team)
[20:15] <fta> 33581 seamonkey-2.0-browser             42    16    19     7     0 (Unknown)
[20:15] <asac> wow
[20:15] <asac> no-files ok
[20:15] <asac> quiet a bunch of gutsy users?
[20:16] <asac> i think no-files is transitional package
[20:16] <fta> 8565  seamonkey                       2993     0     6     0  2987 (Ubuntu Mozilla Team)
[20:16] <asac> and just iceape?`
[20:16] <fta> 10448 iceape                          1798     0     0     0  1798 (Ubuntu Mozilla Team)
[20:17] <asac> so seamonkey is probably
[20:17] <asac> ~ the same as the users thatinstalled it to use it
[20:17] <asac> the rest is pulled in by rdepends?
[20:17] <asac> are there rdepends?
[20:17] <asac> hmm
[20:18] <asac> fta: look at mozilla-noscript
[20:19] <asac> that has rank 5630 and pulls in seamonkey-browser?
[20:19] <fta> 5815  mozilla-noscript                7233   955  4953   801   524 (Arnaud Renevier)
[20:19] <asac> yeah ... that pulls in seamonkey-browser
[20:19] <asac> i have the feeling that this is an accident then
[20:19] <asac> almost everyone wanted -noscript
[20:19] <asac> but well ... quiet guesswork
[20:20] <fta> i dropped -noscript since ff3.0, adblock is enough
[20:20] <asac> just seems strange that almost every seamonkey user uses noscript ;)
[20:20] <asac> fta: yes :)
[20:20] <asac> fta: but it seems that we didnt transition it for firefox users
[20:20] <asac> and now users that used that in the past have seamonkey-browser ;)
[20:20] <asac> (just one/my theory)
[20:20] <fta> 1514  thunderbird                    180467 45689 122773 11956    49 (Alexander Sack)
[20:20] <fta> 1667  mozilla-thunderbird            131112   617 48249   114 82132 (Alexander Sack)
[20:20] <fta> 25793 thunderbird-3.0                  141    16    66    59     0 (Unknown)
[20:21] <fta> 141, lol
[20:21] <fta> most were at uds then ;)
[20:21] <asac> its b1?
[20:21] <asac> why not upload to jaunty?
[20:21] <fta> it's my ppa
[20:22] <fta> no reason
[20:22] <asac> ok will look and if i have any idea that we need something before let you know
[20:23] <fta> 14973 firefox-3.1                      891   146   312   433     0 (Unknown)
[20:23] <fta> 35431 firefox-3.2                       40     5     0    35     0 (Unknown)
[20:23] <asac> +EXTRA_SYSTEM_CONFIGURE_FLAGS
[20:23] <asac> why do we set that to NULL?
[20:23] <asac> what harmful stuff is in there by default?
[20:24] <asac> (xul ...head)
[20:24] <fta> nothing, i like to set default, habits
[20:24] <asac> the "fix permissions" commit is a good one ;)
[20:24] <asac> good catch
[20:25] <asac> fta: yeah lets dump it. otherwise its not easy to set from outside
[20:26] <asac> fta: so you are now officially a icedove uploader ;)
[20:26] <fta> ?
[20:26] <asac> oh you just ahve to send your key to the debian keyring thing
[20:26] <asac> ;)
[20:26] <asac> hmm ... too bad. i didnt sign your key right?
[20:26] <asac> dump
[20:27] <Nafallo> asac: you never signed mine either ;-)
[20:29] <asac> Nafallo: yeah. i am not really a fan of key-parties ;) not beerful enough
[20:30] <Nafallo> asac: ...we had an office... ;-)
[20:30] <fta> damn, i wanted to do that at UDS
[20:32] <asac> fta: you could visit mh ;)
[20:33] <asac> he probably is in paris (not sure)
[20:33] <fta> he's in the area, but i don't remember where
[20:33] <asac> hmm ... my fox hangs
[20:33] <asac> otherwise i would look
[20:33] <fta> ?
[20:34] <asac> ok lets see
[20:34] <asac> too bad that i had to kill ffox
[20:36] <fta> each time mine dies or freezes, it's sound related
[20:37] <asac> mine was "large" page
[20:40] <asac> fta: seems to live outside of paris
[20:40] <asac> 10km from centre north west
[20:40] <fta> i'm ~10k west
[20:41] <asac> quiet close then ;)
[20:41] <asac> hehe
[20:42] <fta> quite, yes
[20:45] <fta> are the *.install files bashisms or not?
[20:45] <asac> good question
[20:45] <fta> i mean, can i use {foo,bar} in there?
[20:45] <asac> /usr/bin/dh_install
[20:46] <fta> hm, perl globs
[20:46] <Nafallo> asac: pm :-)
[20:47] <asac> http://identi.ca/notice/1687030
[20:47] <asac> Nafallo: ^^
[20:47] <Nafallo> ah. hehe.
[20:49] <fta> well.. https://edge.launchpad.net/ubuntu/jaunty/+queue?queue_state=0&queue_text=fennec
[21:15] <fta> asac, http://paste.ubuntu.com/99213/
[21:23] <asac> fta: license file will make it fail anyway ;)
[21:26] <fta> maybe
[21:26] <fta> it's not clear what i should do with this testsuite now. is that even supposed to run fine?
[21:28] <fta> just tried one at random, it's scary: http://paste.ubuntu.com/99219/
[21:30] <asac> fta: are those mochitests failing?
[21:32] <fta> donno, this is what is installed with --enable-tests --enable-mochitest
[21:32] <asac> fta: try without mochitest
[21:33] <fta> i can run make check at build time, it looks nicer
[21:33] <asac> fta: i think you have to run "make check"
[21:33] <fta> it fails at some point: http://paste.ubuntu.com/99221/
[21:50] <asac> http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/tests/unit/test_handlerService.js#155
[21:51] <asac> fta: maybe gconf?
[21:51] <fta> mozilla bug 470307
[21:51] <asac> err gnome-support i mean ;)
[21:51] <asac>  do_check_eq(0, protoInfo.possibleApplicationHandlers.length);
[21:51] <asac>  do_check_false(protoInfo.alwaysAskBeforeHandling);
[21:51] <asac> thats for http
[21:51] <asac> what profile is the "test" using?
[21:52] <fta> i have no clue
[21:53] <fta> i'm walking in dark here
[22:05] <fta> i have a whole lot of TEST-UNEXPECTED-FAIL
[22:07] <fta> i should ship _tests too.
[22:07] <fta> but where?
[22:07] <fta> /usr/share/doc ? /usr/lib ?
[22:17] <fta> stuck..
[22:17] <fta> dpkg-buildpacka───rules───make───sh───make───sh───make───sh───make───sh───make───sh───run-mozilla.sh───test_all.sh───xpcshell───2*[{xpcshell}]
[22:18] <fta> or slow?
[22:24] <fta> asac, build-tree/mozilla/_tests/xpcshell-simple/test_update/profile/cookies.sqlite
[22:37] <asac> good
[22:38] <fta> it seems i'm stuck in test_0040_general.js
[22:38] <fta> log ends with: Testing: url constructed with %LOCALE% - http://localhost:4444/data/%LOCALE%/
[22:39] <fta> not sure what to expect
[22:41] <asac> fta: which test?
[22:41] <asac> pt1, 2, 3?
[22:42] <asac> probably updateChecker doesnt work
[22:42] <fta> not sure
[22:42] <fta> fta      18643  0.0  0.7  48972 14840 ?        Sl+  23:05   0:00 ../../../../dist/bin/xpcshell -j -s -f ../../../../tools/test-harness/xpcshell-simple/head.js -f ../../../../_tests/xpcshell-simple/test_update/unit/head_update.js -f ../../../../_tests/xpcshell-simple/test_update/unit/test_0040_general.js -f ../../../../tools/test-harness/xpcshell-simple/tail.js -f ../../../../tools/test-harness/xpcshell-simple/execute_test.js -f ../../../../_tests
[22:42] <fta> /xpcshell-simple/test_update/unit/tail_update.js
[22:42] <asac> http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/test/unit/test_0040_general.js.in#309
[22:43] <asac> yes i the tail is probably waiting for the async event to set something
[22:43] <fta> http://paste.ubuntu.com/99261/
[22:43] <asac> like "do_timeout" ;)
[22:43] <fta> there's a process listening on localhost:4444
[22:45] <fta> asac, http://paste.ubuntu.com/99264/
[22:46] <fta> btw, this is 1.9.1, not trunk
[22:48] <fta> mozilla Bug 446527
[22:49] <asac> fta: are you running stuff shipped in testsuite or in build tree?
[22:49] <asac> (testsuite - package)
[22:49] <fta> make check in the build tree for now
[22:50] <asac> fta: why does -testsuite conflict with 1.9.2?
[22:50] <asac> those ship different paths from what i see in .install
[22:50] <fta> because it installs files in the -dev dirs, and -dev conflicts
[22:51] <fta> (it installs idl/h files)
[22:51] <asac> fta: yes. but they already conflict
[22:52] <fta> doesn't matter much for now, it's still just an experiment
[22:53] <asac> yeah
[22:54] <fta> maybe it fails because i have no locales for 3.1..
[22:56] <asac> you know whether the same happens on 1.9.2?
[22:56] <asac> (i only have such a tree)
[22:57] <fta> donno
[23:22] <fta> asac, it seems make check is not what i want, according to this: https://bugzilla.mozilla.org/show_bug.cgi?id=421611#c5
[23:27] <[reed]> asac: upstream doesn't care about Debian's non-branded builds
[23:27] <[reed]> if you want an honest answer
[23:27] <[reed]> :)
[23:28] <fta> imho, upstream doesn't care enough about linux/unix as a whole
[23:28] <fta> and even worse, upstream cares only about firefox
[23:29] <[reed]> eh, I disagree
[23:29] <[reed]> they care about linux/unix, or else we wouldn't spend so much time on stuff... Linux/Unix is especially important with Mobile
[23:29] <[reed]> however, I can agree that upstream cares more about Firefox than anything else
[23:29] <[reed]> but that's just how things are
[23:30] <asac> i think its human to do that
[23:30] <fta> you don't care about desktop users, mostly because you can't count us
[23:30] <asac> but the weight is not perfectly balanced imo
[23:30] <[reed]> if your blocklist code isn't broken, we do count you
[23:30] <[reed]> Linux is just tiny
[23:30] <[reed]> even Mac is so much bigger
[23:31] <fta> we have more choices too
[23:32] <asac> problem with using stats to allocate investments is that it will bias the future ;)
[23:32] <asac> (not really saying that this is happening here ... more like a general statement)
[23:33] <[reed]> I think Linux is still being considered upstream pretty heavily, imho... now, packaging/embedding, maybe no, but support for Linux is definitely a priority
[23:34] <asac> i have no real complains about linux in specific
[23:35] <asac> my only criticism would be that resource allocation is done based on how popular a product is atm
[23:54] <asac> fta: TEST-UNEXPECTED-FAIL | ../../../_tests/xpcshell-simple/test_libjar/unit/test_bug407303.js | test failed, see log
[23:54] <fta> asac, as i said, i have tons of TEST-UNEXPECTED-FAIL
[23:55] <[reed]> that's not good
[23:55] <[reed]> you should be passing the test suite, as we do
[23:55] <[reed]> :(
[23:56] <fta> that's what i'm trying to do
[23:57] <[reed]> how are you running them? #developers and Waldo are two good sources of help
[23:58] <fta> make check for now
[23:59] <[reed]> I don't know enough about the test suite to help you that much... gavin and dolske might can help.