[11:06] <asac> Jazzva: prod --export-upstream=. still broken :(
[11:06] <fta> builders are seriously broken :(
[11:07] <fta> https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[11:07] <fta> 16 hours, some are still not built, even if all queues are empty
[11:08] <fta> and some packages took 7h to build, like this one: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/922877
[11:13] <BUGabundo> hey guys, good morning
[11:13] <Jazzva> asac: bzr --export-upstream?
[11:14] <asac> Jazzva: sorry. wanted to prod james_w who isnt here
[11:14] <asac> james_w: oh he is ;)
[11:14] <asac> odd
[11:14] <asac> prod --export-upstream=. still broken :(
[11:14] <Jazzva> ah, ok :)
[11:16] <fta> 11522 chromium-browser                1998    95     0  1903     0 (Unknown)
[11:16] <fta> 11785 firefox-3.1                     1887   337   780   711    59 (Unknown)
[11:16] <fta> 31499 firefox-3.5                       98     6     0    92     0 (Unknown)
[11:16] <fta> lol, more chromium-browser users than ff 3.1+3.5 :)
[11:18] <BUGabundo> fta: eheh
[11:18] <BUGabundo> how can that be?
[11:19] <asac> Jazzva: so what about flash ;)
[11:19] <asac> err nspluginwrapper
[11:19] <BUGabundo> fta I'm RTing that quote
[11:19] <asac> i would like to use kind of "nsp-recreate-wrappers" in next .postinst of flashplugin-nonfree
[11:19]  * asac has a dream ;)
[11:20] <Jazzva> asac: I need to check pointers. I promise I will finish it soon :). Sorry for the delay. When is the nex upload of flash?
[11:20] <asac> Jazzva: heh. i am here to ask ;)
[11:21] <Jazzva> asac: ah, ok. It will be soon. I'll start checking right now :)
[11:34] <asac> err
[11:34] <asac> does the weather clock thing work for anyone?
[11:35] <asac> moving to #..desktop
[11:42] <BUGabundo> it does here
[12:04] <asac> odd
[12:04] <asac> but thats a fresh install i guess
[12:04] <asac> fta: did the clock applet break for you?
[12:04] <asac> at some point during jaunty?
[12:10] <Jazzva> asac: works for me
[12:11] <asac> the location wizard is kind of broken too
[12:11] <asac> at least Germany/Berlin is in africa
[12:12] <Jazzva> it's in europe for me. though, I updated the system two days ago. maybe it broke at some point after that.
[12:12] <BUGabundo> Porto works here
[12:12] <asac> hmm
[12:12] <BUGabundo> let me test berlin
[12:12] <asac> let me upgrade
[12:12] <BUGabundo> berlin is fine here
[12:12] <BUGabundo> updated 2h ago
[12:15] <Jazzva> hmm. I'm trying to use read(), as it is used throughout npw (afaics)... and I want it to read line by line. Is there any way to do that with read(), or should I just use fgets()?
[12:17] <Jazzva> ok, nspluginwrapper uses fgets too. I'll use that :)
[12:25] <asac> Jazzva: what are you trying to do?
[12:25] <asac> i mean where ;)
[12:25] <asac> reading a file with a list of files`?
[12:25] <Jazzva> asac: yes.
[12:25] <asac> err list of directories ;)
[12:25] <Jazzva> read just returned something like "/bla/file1\n/bla/file2\n..."
[12:25] <asac> Jazzva: i dont think we need to put that part in C
[12:26] <asac> we can use NSPLUGINDIRS=/path/1:/path/2
[12:26] <asac> and then write a wrapper script
[12:26] <asac> does that sound better?
[12:26] <Jazzva> asac: um, I thought we wanted to make npw envdir-conscious in "nspluginwrapper --list"
[12:26] <asac> yes
[12:27] <asac> but why do you need to parse a file?
[12:27] <asac> i would think you use getenv ("NSPLUGINDIRS")
[12:27] <asac> and then tokenize it by ':'
[12:27] <Jazzva> so it can use them process_list
[12:28] <Jazzva> and what about using something like /var/lib/nspluginwrapper/dirs.d/ for storing meta-files?
[12:28] <Jazzva> I think you mentioned that :)
[12:29] <asac> Jazzva: yeah. but thats on the packaging level
[12:29] <asac> Jazzva: nspw on its own just need a way to get other directories configured
[12:30] <asac> we can write a wrapper script that assembles NSPLUGINDIRS=... from /var/lib/nspluginwrapper/dirs.d/
[12:30] <asac> hmm
[12:30] <asac> yeah i would think thats ok
[12:30] <Jazzva> asac: well, it's almost done in C :). if it's really bad I guess we can remove it
[12:30] <asac> sure go ahead
[12:31] <asac> to parse lines you should just pull the full buffer
[12:31] <asac> and then search for the \n tokens
[12:31] <Jazzva> so running "nspluginwrapper --list" would process our env dirs
[12:31] <Jazzva> if they exist
[12:31] <asac> yeah
[12:31] <Jazzva> um, let me rephrase it
[12:31] <Jazzva> would process files listed in meta-files in /var/lib/npw/dirs.d
[12:31] <Jazzva> brb, late breakfast
[12:32] <asac> Jazzva: see, its a bit of a problem that you cannot opt out of that behaviour
[12:32] <asac>  /var/lib/npw/dirs.d will usually exist, and then the user cannot use the normal "--list" anymore
[12:33] <asac> personally i think NSPLUGINDIRS env is right to do that.
[12:33] <asac> everything else means more work ;)
[12:34] <asac> like adding --list-from-dirs.d=/var/lib/npw/dirs.d
[12:38] <Jazzva> asac: that sounds good
[12:38] <asac> for me it doesnt ;)
[12:38] <Jazzva> so, --list-from-dirs=... should be implemented
[12:38] <Jazzva> I meant "--list-from-dir="
[12:38] <asac> yeah ;)
[12:39] <asac> i still think its really too high level ;)
[12:39] <asac> so saying --list-from-dirs=/real/dirs/
[12:39] <asac> that would make sense
[12:39] <asac> but --list-from-dirs-you-can-find-in-files-in-dir=/
[12:39] <asac> ;)
[12:40] <Jazzva> ok, so you just want to check few specified dirs? :)
[12:40] <asac> but even for --list-from-dirs=/real/dirs
[12:40] <Jazzva> so, how are we going to do "update all wrappers" on nspluginwrapper update :)?
[12:40] <asac> i would really suggest to add parameter used for everything like: --nspluginwrapper-dirs=/real/path
[12:40] <asac> so you can either use NSPLUGINDIRS= ... or --nspluginwrapper-dirs=
[12:41] <asac> Jazzva: packages shipping wrapped plugins should call:
[12:41] <asac> update-npwrappers
[12:41] <asac> which would look at /var/lib/npw/dirs.d/
[12:42] <asac> get the directories in there and calls
[12:42] <asac> NSPLUGINDIR=... --list
[12:42] <asac> or --upgrade
[12:42] <asac> also they ship their own dir in a file in /var/lib/npw/dirs.d/
[12:43] <Jazzva> and what happens on nspluginwrapper upgrade?
[12:43] <asac> Jazzva: the same. nspluginwrapper calls update-npwrappers
[12:44] <asac> only difference is that nspluginwrapper doesnt ship a dir in /var/lib/npw/dirs.d/
[12:44] <Jazzva> mhm, ok
[12:44] <asac> maybe wrapper plugins dont even need to run update-npwrappers
[12:44] <asac> just --install
[12:44] <asac> so just nspluginwraopper would call that
[12:45] <asac> Jazzva: anyway. if the code is there you can also keep it
[12:45] <asac> just name it --with-conf-dir=/var/lib/npw/dirs.d/
[12:45] <asac> ;)
[12:45] <asac> or something
[12:45] <Jazzva> I will use it, since we will need it with NSPLUGINDIRS=... --list
[12:45] <asac> Jazzva: you definitly will need parts of it
[12:46] <Jazzva> we can keep it here where it is now, and it will be called if getenv(NSPLUGINDIRS) != NULL
[12:47] <Jazzva> if that's the case, then npw --list will list wrappers in default and env dirs. that can be used in update-all, which only needs to be called on nspluginwrapper update
[12:47] <asac> Jazzva: i would think so, yes.
[12:48] <Jazzva> (I think that's the only occasion when we need to list wrappers in env dirs)
[12:49] <Jazzva> and packages that need wrappers would ship a meta-file to NSPLUGINDIR
[12:49] <asac> Jazzva: i would think that fixing get_mozilla_dirs function would be the right thing
[12:49] <asac> are there any issues with that?
[12:50] <Jazzva> asac: yeah, it's a list of predefined directories
[12:50] <asac> i would think that nspw looks at that dir list in update-all ... and we just need to call that
[12:50] <asac> Jazzva: right. but shouldnt we just extend that by adding NSPLUGINDIRS=... directories?
[12:51] <Jazzva> we still need a way to process meta-files. I don't see any other way to list/update all wrappers in env dirs on nspluginwrapper update.
[12:52] <asac> Jazzva: auto_update_plugins uses get_mozilla_plugin_dirs
[12:52] <asac> so if we add our NSPLUGINDIRS to it it should work?
[12:52] <asac> shouldnt it?
[12:53] <asac> and yes. we need meta-files
[12:53] <asac> but only on a package base
[12:53] <Jazzva> asac: how do we determine NSPLUGINDIRS in case where we upgrade nspluginwrapper?
[12:54] <asac> yes
[12:54] <asac> oh
[12:54] <asac> how ;)
[12:54] <asac> nspluginwrapper.postinst gets shell code to
[12:54] <asac> make that env from the files in /var/lib//...
[12:55] <asac> does that make sense?
[12:55] <asac> or am i getting something completely wrong now?
[12:56] <asac> whats the problem again ;)?
[12:56] <Jazzva> asac: I think that's ok too.
[12:56] <asac> yeah i think its ok
[12:56] <Jazzva> It's just that the code is already written for that in C :). I just need to change readdir("/var/lib/...") to readdir(getenv(NSPLUGINDIRS));
[12:57] <asac> readdir?
[12:57] <Jazzva> it will return a list of env dirs, which are written in meta-files
[12:57] <asac> for NSPLUGINDIRS?
[12:57] <Jazzva> oh, opendir :)
[12:57] <asac> i thought its already a list of dirs
[12:58] <Jazzva> i thought it contains files which contain list of env dirs...
[12:59] <asac> heh
[12:59] <asac> no i ment that we just have directories in there
[12:59] <Jazzva> asac: and where do we keep files with env-dirs?
[13:00] <asac> Jazzva: we keep them in /var/lib/ ... its just that the logic moves to the package postinst
[13:00] <gnomefreak> what does it mean when mozilla bugs are grayed out while others are normal? this is on bugzilla.mozilla
[13:02] <Jazzva> so, package postinst would parse them and return something like NSPLUGINDIRS=/some/file1:/some/file2:...?
[13:02] <Jazzva> asac ^
[13:02] <asac> yes.
[13:02] <Jazzva> asac: and then we process that in npw --list..
[13:03] <asac> Jazzva: i think we just extend the get_mozilla_plugins_dir function
[13:03] <asac> to include them
[13:03] <asac> that should fix --list
[13:03] <asac> and update-all
[13:03] <Jazzva> mhm... ok
[13:03] <asac> Jazzva: if you really want we can drop the env approach
[13:04] <asac> and use something like: --with-extra-dirs/path/to/directory/with/links/ ;)
[13:04] <asac> e.g. /var/lib/npw/extra-dirs.d/flash -> /var/lib/flashplugin-nonfree
[13:04] <Jazzva> asac: no, I'm fine. at least I refreshed my pointers and I/O in C knowledge :)
[13:04] <asac> hehe
[13:04] <asac> great
[13:05] <Jazzva> programming all school projects in Java (which is a usual requirement) makes you don't worry about pointers, string manipulation and stuff...
[13:07] <asac> Jazzva: i am currently not exactly sure if we really want to add NSPLUGINDIRS to get_mozilla_plugins_dir or replace the other list
[13:08] <asac> we need to test whether it deliberately wipes the update-alternatives links i guess
[13:08] <asac> if it doesnt do that its good to just add it
[13:08] <Jazzva> asac: I think we can keep the other list. It's no harm and there might be a case where there is a wrapper installed in some of those dirs
[13:08] <Jazzva> wipes links? when?
[13:09] <fta2> asac, we no longer have the notification from ff to restart it in jaunty. this was annoying but needed, so it is bad
[13:09] <asac> fta2: we have the ubufox notification
[13:09] <asac> but i see your point
[13:09] <asac> Jazzva: heh. just add the dirs for now
[13:10] <asac> we can check wehther that works as expected
[13:11] <Jazzva> asac: ok. I have to go get ready for school. But I'll maybe work on it during school in case we lose classes.
[13:13] <asac> sure ;)
[14:00] <gnomefreak> How do i get a list of all bugs i filed or commented on to show up in my "bug list" for my account with upstream Mozilla bug tracker?
[14:01] <gnomefreak> right now it only shows the one i just reported none of the other ones are there filed or not
[14:22] <fta2> asac, bug 158570
[14:23] <fta2>  bug 158570
[14:36] <fta2> asac, you last xul broke prism (because of python)
[14:38] <fta2> bug 351308
[14:41] <gnomefreak> was this caused by the broken Python in Jaunty last week?
[14:44] <asac> fta2: what is "last xul"?
[14:45] <asac> 1.9.0.8?
[14:45] <fta2> yes
[14:46] <fta2> asac, /usr/lib/xulrunner-1.9.0.8/xulrunner-bin: symbol lookup error: /usr/lib/xulrunner-1.9.0.8/libpyxpcom.so: undefined symbol: PyUnicodeUCS2_DecodeUTF16
[14:46] <fta2> it's the very old prism so it was calling xul directly, not the stub
[14:48] <asac> nm -D /usr/lib/xulrunner-1.9.0.8/libpyxpcom.so | grep PyUnicodeUCS2_DecodeUTF16
[14:48] <asac> asac@hector:~$
[14:48] <asac> fta2: can you run that on i386?
[14:48] <asac> i dont have any reference to it
[14:49] <fta2> it's not me, i pasted from th ebug
[14:49] <fta2> i'm using a fresh prism everywhere
[14:52] <BUGabundo> asac: setting my system to 96 DPIs still has some apps looking strange!
[14:57] <asac> fta2: the bug suggests that prism calls xulrunner-bin
[14:57] <asac> which has no such symbol reference here on amd64
[14:58] <asac> thougth maybe the i386 got bad symbols because being built against old bad pytho
[14:58] <asac> n
[14:58] <BUGabundo> do Notifications bubble make your screens flash too, when using a FulScreen app?
[14:58] <asac> e.g. the one we had to fix right after beta
[14:58] <asac> no
[15:01] <BUGabundo> asac: is that to me?
[15:03] <asac> no its about prism/python
[15:03] <asac> i dont know
[15:03] <asac> you need to reset everything to 10pt
[15:03] <asac> if there are still apps behaving wrong let me know and show screenshots
[15:03] <asac> but only after resetting everything ;)
[15:03] <BUGabundo> Filezilla
[15:04] <BUGabundo> is the only one bad as far as I can see
[15:06] <asac> is that 1.8 branch?
[15:06] <asac> not sure what filezilla is ;)
[15:12] <fta2> a kind of ftp/fxp addon
[15:12] <fta2> clinet
[15:12] <fta2> client
[15:13] <asac> yeah. is that mozilla based?
[15:13] <asac> or just named as such
[15:17] <fta2> donno, i haven't used it in years
[15:40] <gnomefreak> bug 310128
[15:44] <gnomefreak> fta2: is bug 351150 the same as the problem you mentioned above about python/prism breakage?
[15:46] <asac> fta2: fixed the prism build
[15:46] <asac> but there are other issues i think
[15:46] <asac> doesnt start here.
[15:46] <asac> guess we should bump the snapshot a bit at least
[15:56] <fta2> the ppa has the latest snapshot
[15:57] <asac> err ... latest snapshot doesnt even build ;)
[15:57] <asac> fixed
[16:15] <gnomefreak> is Ubuntu Netbook Remix only for netbooks?
[16:16] <asac> gnomefreak: not sure
[16:16] <asac> could be that they strip off not needed drivers ;)
[16:16] <asac> if not i dont see a reason why it would be just netbooks
[16:19] <BUGabundo> gnomefreak: no
[16:19] <BUGabundo> you can use it on anything
[16:19] <BUGabundo> its just a skin
[16:19] <BUGabundo> but I guess I'm to used to the Desktop
[16:19] <BUGabundo> to loose it
[16:20] <gnomefreak> it says that its used with desktop cd or something like that and and boot thing needs to be installed so im guessin gyou cant just use the theme
[16:20] <BUGabundo> I already did it
[16:20] <BUGabundo> on old mobile
[16:20] <BUGabundo> on a 903 eeepc
[16:20] <BUGabundo> did regular ubuntu and then change to UNR
[16:21] <BUGabundo> didn't liked it so went to MID... got even worse UI
[16:21] <BUGabundo> so got Mobile look....
[16:21] <BUGabundo> don't know where that is now
[16:22] <asac> i think you can just install a package in normal ubuntu
[16:23] <BUGabundo> yep
[16:23] <BUGabundo> but you still need to hack some startup daemons
[16:23] <BUGabundo> https://wiki.ubuntu.com/UNR/
[16:24] <BUGabundo> "s there isn't a configuration package available yet, you will need to setup the gnome-panel to mimic the standard UNR set-up. The applet order is as follows: "
[16:24] <BUGabundo> go-home-applet | window-picker-applet | notifcation-area-applet | mixer-applet | clock
[16:28] <gnomefreak> BUGabundo: thanks
[16:28] <BUGabundo> np
[16:28] <BUGabundo> I've been keeping an eye on the project
[16:28] <BUGabundo> its a shame its almost stopped now
[16:29] <asac> what is stoped?
[16:30] <BUGabundo> afaik not enough man power for mobile edition
[16:30] <BUGabundo> some OEMs are pushing UNR
[16:30] <BUGabundo> but other then that.... stall
[16:34] <asac> fta2: ok now all works again as it seems
[16:36] <fta2> good
[16:39] <asac> so will there be a release or what?
[16:45] <asac> fta2: so how do we get tags for moz-central stuff?
[16:46] <asac> e.g. get-orig-source DEBIAN_TAG=... probably doesntw ork
[16:55] <fta2> asac, it does
[16:55] <asac> ok
[16:55] <asac> good
[17:18] <BUGabundo> asac: did you find Bug 151869 as funny as I did?
[17:28] <asac> i stopped finding bugs funny some time agao ;)
[17:29] <BUGabundo> eheheh
[17:30] <BUGabundo> the guy is ilarious
[17:34] <Jazzva> asac: I think it works. I wrote tokenizer for NSPLUGIN_DIRS env variable and modified get_env_plugin_dirs to use returned dirs. It only works if env var NSPLUGIN_DIRS is set. So, now just to append those dirs to get_mozilla_plugin_dirs, right?
[17:39] <asac> hmm
[17:40] <asac> not sure
[17:40] <asac> i thought we would just put it in get_mozilla-plugin_dirs
[17:40] <asac> if we can move that part to get_env_plugin_dirs its ok i guess
[17:40] <asac> but i dont have get_env_plugin_dirs in the upstream branch here
[17:40] <asac> so cannot tell
[17:40] <asac> most likely that works
[17:45] <Jazzva> asac: I added get_env_plugin_dirs, so it will be inside a patch. I thought to call it from get_mozilla_plugin_dirs, and merge it to the current list
[17:46] <asac> yeah
[17:46] <asac> good
[17:46] <Jazzva> It should work. I just left it as it was before (as in few hours ago :)), but added part to read env variable.
[17:46] <asac> give it a try ;)
[17:46] <asac> should be easy to test
[17:46] <asac> --list
[17:46] <asac> or even --update-all
[17:48] <Jazzva> there is no --update-all yet ;). We need to add that too
[17:48] <Jazzva> (at least it wasn't there before IIRC)
[17:49] <Jazzva> but list should work :)
[17:57] <Jazzva> Ok, going back home now, will be online in about an hour or so.
[18:06] <BUGabundo> gym time ppl! see you tomorrow
[19:03] <asac> james_w: yeah list works
[19:03] <asac> err jazzva ;)
[19:03] <asac> sorry
[19:03] <james_w> np :-)
[19:03] <james_w> I have the --export-upstream issue fixed in my branch, just collecting some other fixes before upload
[19:05] <fta> there's definitely something weird with the builders. https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa  most should be done by now
[19:10]  * asac hugs james_w 
[19:10] <asac> shall i test?
[19:11] <asac> fta: xul started 35 minutes ago
[19:11] <asac> seems still in line
[19:11] <james_w> asac: please: lp:~bzr-builddeb-hackers/bzr-builddeb/2.1
[19:16] <asac> james_w: now do i build it at best?
[19:17] <asac> just debuild?
[19:17] <james_w> you mean build bzr-builddeb itself?
[19:18] <asac> yeah
[19:18] <asac> now using debuild -b ;)
[19:24] <asac> james_w: http://paste.ubuntu.com/140882/
[19:25] <asac> james_w: http://paste.ubuntu.com/140883/
[19:25] <james_w> odd
[19:25] <asac> thats what is in .bzr-builddeb/default.conf
[19:25] <james_w> damn
[19:25] <james_w> pushed
[19:26] <asac> heh ;)
[19:26] <asac> ok let me pull again
[19:26] <james_w> sorry about that, was a stupid mistake
[19:27] <asac> thats why i am testing ;)
[19:27] <asac> so no need for excuse;)
[19:29] <asac> james_w: looks good. thanks a lot.
[19:43] <fta> could bd also consider a non-hidden conf file, something like debian/bzr-builddeb/default.conf
[19:43] <fta> ?
[19:46] <asac> fta: we can commit a link ;)
[19:46] <asac> ln -s debian/bzr-builddeb.conf .bzr-builddeb/default.conf
[19:48] <asac> not sure if diff.gz goes mad ;)
[19:52] <fta> i want to make it more obvious that a package is bd ready
[19:53] <fta> asac, http://launchpadlibrarian.net/24543134/buildlog_ubuntu-hardy-i386.prism_0.9.1%2Bsvn20090309r23002-0ubuntu1~umd2~hardy_FAILEDTOBUILD.txt.gz
[19:53] <fta> tar: /usr/lib/xulrunner-devel-1.9.0.8/sdk/build-system.tar.gz: Cannot open: No such file or directory
[19:53] <fta> i thought you took it since 1.9.0.7 ?!?
[20:06] <asac> fta: i dont know what to tell ;) ... since ever i have been asking what it takes to take that  ;)
[20:06] <asac> i never got an answer on that
[20:07] <asac> or maybe i got it last time ;9 ... then excuse
[20:07] <fta> there's no possible regression, i jsut tar a few files before the build begins, and i ship that tar in the sdk
[20:07] <asac> yeah
[20:07] <asac> i see that now
[20:07] <asac> its the script
[20:08] <asac> plus some rules code
[20:08] <asac> fta: just that or also some patch?
[20:10] <fta> asac, what is the delta between your branch and head?
[20:10] <fta> there shouldn't be much
[21:03] <fta> [reed], how far is 1.9.1 b4
[21:03] <fta> ?
[21:04] <[reed]> fta: https://wiki.mozilla.org/Releases/Firefox_3.5b4
[21:05] <fta> hmm
[21:05] <fta> asac, ^^ too late for jaunty?
[21:25] <jcastro> asac: fta: ok so I think ryan was  able to work around that webkit crasher
[21:28] <fta> jcastro, great, will he commit the fix to trunk soon? i remember he was supposed to commit something else too, never happened
[21:28] <fta> jcastro, that: http://identi.ca/notice/2944178
[21:29] <jcastro> yeah he merged that this weekend
[21:29] <jcastro> afaik
[21:29] <jcastro> I need to track him down, he's busy and the clock is ticking
[21:29] <jcastro> plus the keyring is crashing now
[21:29] <fta> really?
[21:30] <fta> for me, gwibber freezes or crashes almost daily, but i suspect it's webkit
[21:30] <jcastro> mine doesn't, but I am running 1.0 branch not trunk
[21:31] <fta> (maybe not daily, but several times a week)
[21:31] <fta> the two branches are really close
[22:58] <asac> fta: should be ok
[22:58] <asac> i assume that they release later anyway
[22:59] <asac> but we have committed to maintainer 3.5 in jaunty
[23:28] <fta> Bug 351988
[23:30] <fta> asac, ^^
[23:43] <fta> asac, Bug 350594