[00:10] fta: i use the non-Free Nvidia driver, so for me, no. [00:10] crimsun, me too so thanks, i keep xorg on hold [00:12] fta: no ... cannot handle automatically. its a driver issue in the end [00:12] you can do you own hacky scripts though in user space ;) [00:13] can't it be properly done in jaunty? [00:13] unsure. maybe a few more drivers get fixed to do it properly [00:14] i know that there is work in progress [00:14] to make option drivers do the same as the ones that already work [07:26] Hi. I was looking at flashblock package, because the version in Jaunty wasn't the last, one, and I saw that this package is built from CVS checkout, ignoring the normal upstream versions (jaunty => flashblock-1.3.11a~snapshot20081113, author = 1.5.7.1). Won't it be better to repackage it from scratch? [07:28] fabrice_sp: looking at the version (snapshot date), 1.5.7.1 wasn't available. [07:29] fabrice_sp: now that it is, you should be able to modify it if you feel up to it =) [07:29] sure, but isn't there a risk of checking out a non stable version if you use directly CVS? [07:30] sure, but you can modify the packaging... [07:30] crimsun,: as it would be a repackaging, it should go through REVU? [07:31] why would it be a repackaging? [07:31] you're changing debian/rules [07:31] ohhh, you're right [07:32] and I can download the xpi file, and uncompress it [07:33] will create the bug report and assign it to myself (Hoping to find a sponsor to ack it afterwards :-) )thanks for your answer [07:34] yw === rzr is now known as RzR [10:00] i just missed fabrice [10:01] hi fabrice_sp [10:01] let me explain [10:01] i just read your posts [10:02] the author has a weird release process [10:02] and I still think using the CVS tree is better for us [10:02] current one is working on jaunty right ? [10:06] Hi RzR. [10:07] This is partly why I asked, because if it has been done this way, I assume it's for some good reason. [10:07] Anyway, it's hard to know which version we have in ubutnu, since we only have the cvs date, and no real release in front of that [10:10] I have to check how it works in Jaunty, but you agree with me that there is a risk to get a buggy version using CVS [10:13] it the CVS belonging to the release [10:13] I should explain this into debian/README.source [10:14] I am afraid CVS is the only way to get the sources [10:14] am i right ? [10:15] so please contact me if you plan to help to flashblock, we'll work toguether [10:16] remaining tasks is to test jaunty version and backport it to intrepid and hardy [10:16] I'll work on it debian side if you can take care of this [10:16] what do you mean by source? Because you can get a .xpi with the watch file [10:17] I want to rebuilt it from scratch then anyone can understand this [10:17] Anyway, as I am nobody here, I won't discuss decisions that have already been taken by more senior people... [10:17] my mess came from the version scheme [10:18] ok I'll doccument it [10:18] have you tested jaunty ? [10:19] I just tested the 1.5.7.1 in Intrepid [10:19] that's all [10:19] (I packaged it in the meanwhile) [10:20] can you install jaunty deb into intrepid just to test [10:21] ok [10:21] I'll do that [10:22] great [10:22] (and it would be great if next version of package would have the real upstream based version) [10:22] :-) [10:22] I'll explain you how it works [10:22] because it's weird [10:23] it took me time to understand [10:23] :-) [10:24] anyway welcome to this channel [10:24] i didnt notice you were there [10:25] the same happened to me with you (I was wondering who were rzr@users.sf.net) :-) [10:25] btw i have an other project pending for this team [10:26] it's testing a VRML plugin [10:26] but everyone seems busy [10:27] logical: between updates and new release, there is a lot to do [10:27] I came to flashblock doing merge/sync for jaunty, [10:29] By the way, I create a bug report for that 'update' and I was working on it (bug #315718). What do I do with it? [10:29] Launchpad bug 315718 in flashblock "Please upgrade flashblock to the latest upstream version (1.5.7.1)" [Undecided,In progress] https://launchpad.net/bugs/315718 [10:32] fabrice_sp: I think it's prefered to merge jaunty one into intrepid, you can close it and open an other one [10:32] just branch update debian/changelog and propose it [10:32] i'll do this if i can test intrepid [10:33] but I dont have intrepid [10:33] i am gone [10:33] thx again fabrice_sp === RzR is now known as rZr [10:46] I'll check the Jaunty versions in Intrepid, anyway [10:47] thanks ! [11:47] Hello! I have a question I was hoping for some help with: The setting "nglayout.initialpaint.delay" in FF about:config is nifty. BUT, is there any way to have customized per page settings for this variable? Like, 250ms for www.example.com and 1000 for www.otherexample.com? === halkok is now known as notrelevant [12:25] fta_: could you push bzr rev 404 of 1.9.2 xul to your PPA? [12:26] not now ;) ... i think DX flks would be happy to havea libnotify xul for testing [12:27] fabrice_sp: talk to Jazzva_ please about extensions [12:28] fabrice_sp: if you do something please do it in the bzr branches ;) [12:28] and let us sign off your work before you get it uploaded. thanks! [12:55] Hello! I have a question I was hoping for some help with: The setting "nglayout.initialpaint.delay" in FF about:config is nifty. BUT, is there any way to have customized per page settings for this variable? Like, 250ms for www.example.com and 1000 for www.otherexample.com? [13:03] notrelevant: why do you want that? [13:04] anyway ... i doubt there is a per-page setting [13:04] Because at my work.. there is one specific page.. which needs to be updated often.. and in addition it is slow response... and after working full time a week it drives me mad [13:05] I know there isn't a plugin or anything.. [13:05] but maybe there is a clever way to do it [13:06] What I would achieve is that I don't have to see the redrawing of the page every interval it refreshes... (as the page only modifies slightly everytime changing that setting will make it update seamlessly) [13:07] anyone got any ideas how to cook up something ? [13:08] let me check [13:10] you need to make layout/base/nsPresShell.cpp aware of per-page prefs for pagination delay [13:14] hmm [13:14] ok. [13:14] This is only for one single page [13:14] the rest can be set to default [13:15] So basically this is something I need to script [13:15] ? [13:15] there's noe simple fix/one-liners ? [13:15] :) [13:22] notrelevant: script isnt possible ... thats in c++ [13:22] you need to add a new feature in that code [13:26] @time [13:26] Current time in Etc/UTC: January 10 2009, 13:26:07 - Next meeting: LoCo Council in 3 days [13:29] allright... that is above my head. Thanks for pointing me in the right direction anyway :) [13:29] sorry ...ur welcome notrelevant [13:34] hi hny2k9, are you guys going to fosdem ? [13:36] asac, DX folks? === fta_ is now known as fta [13:59] fta: those folks doing the new notification stuff [14:00] rZr: not yet sure [14:05] asac, done [14:11] thx [14:12] ok travelling [14:12] i need to add a depend on libcanberra0 too [14:12] i am unsure too [14:12] but this will be good [14:13] i'll may also go the gsm expo in barcelonna [14:24] asac, damn, libcanberra0 is not on all arches, and not on hardy. === asac_ is now known as asac [15:50] at beenm added to ffox too? [15:50] fta: oops ... i means : was libcanberra been added to ffox too? or just for tbird? [15:50] * asac cannot type with gloves on [15:58] * jaunty sparc Successfully built (DONE) [15:58] * jaunty powerpc Successfully built (DONE) [15:58] * jaunty lpia Successfully built (DONE) [15:58] * jaunty ia64 Successfully built (DONE) [15:58] * jaunty i386 Successfully built (DONE) [15:58] * jaunty hppa Successfully built (DONE) [15:58] * jaunty armel Successfully built (DONE) [15:58] * jaunty amd64 Successfully built (DONE) [15:58] libcanberra that is [15:59] but right. a bit of a pity ... but we can add that lib to PPA just [15:59] as backports [16:01] ok off for a while ... preparing for train ride ;) [16:01] cu later [16:30] bye [17:34] asac, it's loaded dynamically so it's meant for ff and tb, or xul and tb. with the latter, xulapps get it for free [17:35] asac, http://packages.ubuntu.com/search?keywords=libcanberra&searchon=sourcenames&suite=all§ion=all [18:10] fta: how is it dynamically loaded? dlopen or by being linked against an optional component like mozgnome? [18:14] asac, http://hg.mozilla.org/mozilla-central/rev/a873ac2554396b2984523c13952fe89c4758daf2#l89 [18:15] there's nothing in configure :( [18:16] fta: looks good. we dont need it at build time ;) [18:17] so adding a Recommends to xulrunner should be sufficient [18:17] (unless KDE folks go mad again) [18:17] (in that case Suggests) [18:17] sure but if it's not at build time, we look the ${shlibs:Depends} magic [18:17] fta: yes. thats why we should add a Recommends [18:17] it isnt mandatory anyway [18:17] i checked, it could be in Depends, it doesn't drag gnome libs with it [18:18] fta: it does [18:18] fta: libpulse [18:18] Recommends is good [18:18] thoguh [18:18] question is whether suggests. depends isnt needed i think [18:18] * asac on a call [18:18] no, it doesn't drag pulse in, http://packages.ubuntu.com/intrepid/libcanberra0 [18:20] $ apt-cache show libcanberra0 | grep libpulse [18:20] Depends: libasound2 (>> 1.0.18), libc6 (>= 2.4), libltdl7 (>= 2.2.4), libogg0 (>= 1.0rc3), libpulse0 (>= 0.9.8), libtdb1, libvorbis0a (>= 1.1.2), libvorbisfile3 (>= 1.1.2) [18:21] hm [18:21] look in jaunty (http://packages.ubuntu.com/intrepid/libcanberra0 is intrepid) [18:21] bad then [18:22] Recommends: is ok imo ... does what we want on gnome and probably kde will complain ... but lets wait for that first [18:22] or add it as Depends: explicitly of -gnome-support [18:22] s/of/to/ [18:24] i need to ask to mventnor if there's a minimum version of libcanberra required, otherwise, it need to put that in my ppa too [18:24] I already have 99 packages :P [18:25] fta: you can ... but you dont need to ;) [18:25] its optional after all ;) [18:25] * fta should not type with frozen hands [18:26] hopefully the SONAME version properly reflects canberra requirements: [18:26] libcanberra = PR_LoadLibrary("libcanberra.so.0"); [18:26] so if we believe in the mightiness of canberra folks this means that they didnt break ABI ;) [18:27] it's a really young library, i have serious doubts [18:27] yeah ;) ... we should discover that then and request demotion from main if they proofed that they didnt care about ABI [18:28] but from what i see just a very few symbols are used by moz [18:28] it's a dep of epiphany-* [18:28] http://paste.ubuntu.com/103214/ [18:28] so hopefully those are stable [18:28] yeah. i assume its properly tracked ABI then [18:28] if it breaks we have to hunt them down [18:29] so in theory intrepid version should be ok too [18:30] well, read the bug [18:30] > +typedef struct _ca_context ca_context; [18:30] > [18:30] > Is it worth copying this stuff from libcanberra, or should we just have a [18:30] > configure check so that this code is only built when libcanberra dev headers [18:30] > are installed? [18:30] Definitely worth it, maybe reconsider at a later stage. libcanberra is very [18:30] new, only GNOME 2.24 has it as a new dependency. [18:30] yes ... so all fine imo [18:31] either make a hard depends on moz-gnome-support [18:31] or a Recommends: on xulrunner-1.9 [18:31] i guess the former is what we want without causing fud among kde folks [18:32] i already made it Recommends: of xul 1.9.1/2. i'm tempted to make it a Dep of -*gnome-* too but for that, i must push it to my ppa [18:33] because i do all my stuff for hardy too [18:33] fta: hmm ... didnt you say you pushed a new xul 1.9.2 snapshot with my last commit? [18:33] all fine. just have find out what you referred to with "done" ;) [18:33] too bad i don't have stats for my ppa, i would seriously consider dropping things that are no longer needed [18:34] last commit of when? i did xul yesterday eve [18:34] fta: you should ask pitti ... i think he has some nice scripts used to identify rotten things in the main archive [18:34] e.g. stuff that is in main, but doesnt have a depends in main anymore [18:34] and so on [18:35] how will it help me? [18:35] and a bunch of other consistency scripts [18:35] fta: it will find stuff that isnt required anymore ;) [18:35] i just need usage stats [18:35] hmm [18:35] well [18:35] thats a differen thing then ;) [18:35] yes [18:35] i would say that you shouldnt feel obliged to continue stuff for which you never get any feedback [18:36] just keep the head builds for now ... until we have ~ubuntu-mozilla-daily or something [18:36] :) [18:36] i just feel relucaant to add new teams for each and every use case... since soon multi-ppas-per-user/team will be available [18:38] i thought about ubuntu-mozilla-releases with just milestones, not snapshots [18:38] fta: yeah. we can have plenty of topics [18:39] ubuntu-mozilla-milestones, ubuntu-mozilla-per-commit [18:40] i will check when multi PPAs will land [18:40] if thats longer than one month ahead i am not sure i want to wait ;) [18:41] also stuff like: [18:41] ubuntu-mozilla-ports-1.9.2 (e.g. every embedding stuff built against 1.9.2 snapshots) [18:42] auto triggered respins when xulrunner receives a new commit ;) [18:42] fun [18:42] probably a waste of power though ;) [18:47] no way it could work with our work-flow. It would need partial rebuilds [18:47] at least for trunk [18:50] asac: about your previous comment. Does that mean that all the extension changes has to be done in bazar? Even things like the one in Bug #286225? [18:50] Launchpad bug 286225 in vimperator "[intrepid] iceweasel-vimperator: Depends: iceweasel (>= 3.0~) but it is not instalable" [High,Confirmed] https://launchpad.net/bugs/286225 [18:51] (and is there a kind of tutorial/wiki on bazar usage. If for extension, better!) [18:51] I'm refering to this one: fabrice_sp: if you do something please do it in the bzr branches ;) [18:54] fabrice_sp: no. would be beneficial to move that to bzr, but if its synched from debian we can keep it out [18:56] fabrice_sp: if you start to package something new, take a look at https://wiki.ubuntu.com/MozillaTeam/Extensions ... there are packaging links too [18:56] fta: what do you mean by "partial rebuilds"? [18:56] you mean PPAs wont be able to catch up? [18:57] to produce a package for each and every commit in -central? [18:57] jcastro: gwibber crashed on me :/ no crash file though [18:58] i sent something ... it disappeared ... i thought it was not send and i rewrote it and posted ... suddenly both popped up [19:04] maybe we should restart update-notifier, it keeps a file descriptor open [19:05] Warning: The following processes are using deleted files: [19:05] Process: /usr/bin/update-notifier PID: 8061 File: /var/lib/update-notifier/user.d/firefox-3.1-restart-required [19:07] Upload Warnings: [19:07] PPA exceeded its size limit (6319.00 of 5120.00 MiB). Ask a question in https://answers.launchpad.net/soyuz/ if you need more space. [19:09] i had sudden death of system [19:09] * asac rebooted [19:09] darn [19:09] this upgrade wasnt good [19:09] everything is slow as hell [19:09] damn [19:09] damn damn [19:09] all worked well [19:09] now i am doomed [19:10] maybe Xorg breakage for sure [19:12] wft XOrg 97% :( [19:12] fail! [19:13] * Disable terminal function entirely * Add x11fnc.sh to provide several general purpose X bash functions [19:14] could it be that? [19:15] donno, i have X on hold until they solve the nvidia mess [19:18] * asac tries something [19:24] fta: 20:22 < asac> bryce: tjaalton: seems like enabling exa caused this. going for Xaa makes things go back to normal (https://edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/1:6.9.0.91-1ubuntu3) [19:24] 20:22 < asac> bryce: tjaalton: what info do you need? i would love to have this fixed ... but in worst case we have to exclude this card from exa i think. let me knew [19:24] so i am lucky and back to normal :) [19:24] * asac rides the bleeding edge [19:24] :) [19:27] i have a bunch of /tmp/plugtmp/plugin--xxxx left behind [19:27] Warning: File '/tmp/plugtmp/plugin--1171' (score: 210) contains some suspicious content and should be checked. [19:27] Warning: File '/tmp/plugtmp/plugin--2758' (score: 200) contains some suspicious content and should be checked. [19:27] Warning: File '/tmp/plugtmp/plugin-' (score: 210) contains some suspicious content and should be checked. [19:27] Warning: File '/tmp/plugtmp/plugin--1012' (score: 210) contains some suspicious content and should be checked. [19:27] etc.. [19:27] firefox ? [19:33] hmm [19:33] short live bug 315889 [19:33] Launchpad bug 315889 in xserver-xorg-video-ati "EXA has severe performance impact on ATI R580 (X1900)" [Critical,Confirmed] https://launchpad.net/bugs/315889 [19:59] Hi [19:59] I would like to swap button set on awesomebar activation/deactivation event [20:00] I have found openAutocompletePopup method, but I need rather something like popuphidde [20:00] method [20:06] asac : ping [20:09] saivann: yes? [20:09] fta: what's the diff between install/$(DEB_MOZ_APPLICATION):: and the .install files ? [20:10] asac : I wanted to know if you still have someone who's working to setup rosetta for thunderbird/sunbird/lightning translation in ubuntu? [20:10] wikz, in the *.install files, you cannot rename anything, and you can't do anything conditionally [20:10] fta: apart from permissions can be set in the rules file? [20:10] saivann: hard to say ;) ... i hoped for full xpi support before the roll out [20:11] fta: and which one superseedes the other? I mean if I have the same set of files, will it have any adverse effect [20:11] Where can I find help about developing firefox [20:11] asac : Does that need some changes in rosetta itself? If no, I can start working on this [20:11] ddeath: http://developer.mozilla.org/ [20:12] wikz, both are applied, i think the files are first but you should not depend on that [20:13] saivann: i think there are multiple steps: 1. get the template whitelisted, so that builds/uploads get digested and the template taken from there [20:13] asac, http://www.sofaraway.org/ubuntu/tmp/mozcentral-commits.png [20:13] fta: reason is that I need to get rid of the executable-not-elf-or-script warnings and I was thinking if I take the install -m route, it is the best. what do you say ? [20:13] 2. get me to enabling more applications for po2xpi on an internal host that does the translation for rosetta now [20:14] fta: mark said that he would like to be able to have per-commit builds in his opening speech at UDS ... didnt he say that ;)? [20:14] wikz, i have a fix perm rule already in the xul & ff packages [20:14] afair he explictily mentioned firefox in his example ;) [20:14] asac, yes, i wanted to have details on that but noone i asked knew [20:15] fta: the details are: do it ;) [20:15] asac, I have the bot but not the h/w [20:15] fta: i think if we have it and there are not enough resources, we can probably raise this and disable the "per-commit" thing to be a "three-builds a day" or something [20:16] asac : Mmh :-/ I guess there's nothing in these steps that I can work on? [20:16] fta: can you plumber a script together that does that so i can run that on some internal host from where we can upload tarballs in a second? [20:16] saivann: you can [20:16] saivann: you can get the first step done ... talk to arnegoetje [20:16] saivann: ask him "why arent the thunderbird templates there" [20:17] but first: [20:17] check that after a tbird build there is a directory debian/lp-xpi-export/ or something [20:17] but now that i think about it ;) [20:17] saivann: can you please try to build depend on mozilla-devscripts for tbird [20:18] and look in debian/rules of firefox 3 [20:18] # translation flags [20:18] MOZ_TRANSLATION_AUTO_XPI_OUTDIR := debian/lp-export-xpis/ [20:18] MOZ_TRANSLATION_AUTO_XPI_SEARCHDIRS := debian/$(DEBIAN_NAME) [20:18] MOZ_TRANSLATION_AUTO_XPI_LOCALE := en-US [20:18] include /usr/share/mozilla-devscripts/lp-locale-export.mk [20:19] also look at the binary-post-install/$(DEBIAN_NAME):: in firefox 3 debian/rules [20:19] asac, I can upload in a few secs from work too ;) [20:19] there we add the install.rdf to the en-US.xpi (which is produced from lp-locale-export.mk automagically) [20:19] asac : I see, this is how Firefox is actually translated, right? That means that I can use it as a good example for Thunderbird? [20:20] saivann: yes [20:20] saivann: you need to provide the template to launchpad [20:20] putting a en-US.xpi in debian/lp-export-xpis/ serves for that purpose [20:20] the lp-export-export.mk is what produces a langpack .xpi from a build-tree [20:21] asac : This is the first time that I do this, I'll begin and see if I get some relevant work [20:21] saivann: yeah. should be not too hard. first stell. add the lines from above to debian/rules [20:21] second step: verify that a build really has something in MOZ_TRANSLATION_AUTO_XPI_OUTDIR after the build has finished [20:22] There's not seperate IRC channel?? [20:22] if thats the case you just need to add the install.rdf somehow ... because that file cannot be magically produced by lp-locale-export.mk [20:22] ddeath: for what? [20:22] For developing question [20:22] what kind of question? [20:22] For example for extension maker [20:22] extension stuff is definitly different channel than firefox core stuff ;) [20:22] I will changing icons on awesomebar in some events(on focus) [20:22] And I can do it. [20:23] asac : Thank you very much for these informations, I'll start working and get back to you once I'll have some work done [20:23] But I cannot receive situation if user exit from popup [20:23] ddeath: you mean "mouse leave" event? [20:24] saivann: thanks. start with tbird from bzr branch is probably the best ;) [20:24] Not. [20:24] (or apt-get source jaunty) ;) [20:24] Somethink like focus stollen [20:24] Events which occurs when popup hiddes [20:24] (disappear) [20:28] ddeath: maybe you could use .css to achieve what you want? [20:29] :focus pseudoclass?? [20:29] Maybe [20:29] something like that yes. [20:29] I don't see [20:29] i think would be more practical as doing all the addEvent/removeEventListener [20:29] at some point forgetting something and then messing memory up ;) [20:29] hehe [20:29] asac : Oh, thanks for the hint :) [20:31] ddeath: you can basically listen for everything for everything: like: http://mxr.mozilla.org/mozilla-central/search?string=addEventListener shows a bunch of things [20:31] ddeath: anyway, I think #extdev on irc.mozilla.org is the resource you want ;) [20:32] Thank [20:47] fta: the file spicebird in the root directory is the main app launcher and is marked executable but doesn't start with a #!/bin/sh which and so lintian complains. what should I do? use a lintian override? [20:48] fta: the fix-perm worked wonderfully otherwise, thanks :) [20:48] wikz, the idea of my fix perm is also to log, so it could be reported and fixed upstream [20:49] wikz, by app launcher, you mean *.desktop file or a script in /usr/bin? [20:49] fta: yes [20:49] fta: in fact it has a #!/bin/sh line but it's commented out. I will report upstream who sits next to me :) [20:50] fta: http://paste.ubuntu.com/103268/ [20:51] yep bad, line 37 must be 1st [20:52] fta: also about the xpm warning. since 0.7 has already been tagged how should I rectify the warning, we had a png for a menu icon [20:53] you have both? [20:54] we have an xpm but it's 48X48 [20:54] so another problem [20:54] so even if I link to it, it complains [20:54] menu-icon-too-big /usr/share/pixmaps/spicebird.xpm: 48x48 > 32x32 [20:55] don't you have a png somewhere in the tree? [20:55] yup I do [20:57] can't you use that? [20:59] fta: but lintian says not to use pngs for menu :E: spicebird: menu-icon-not-in-xpm-format /usr/share/pixmaps/spicebird.png . If that is acceptable, then I will go for a lintian override. [21:01] wikz, i would use a png or a svg and use "Icon=foo" without extension in the desktop file, that's perfectly fine. imho, xpm should be deprecated [21:02] fta: :) [21:03] perfectly fine.. in ubuntu. for debian, i don't know how picky they are for that [21:07] fta: well, I will tell them upstream doesn't provide any ;) [21:10] mozilla dropped support for xpm last year [21:15] https://edge.launchpad.net/ubuntu/jaunty/+source/openoffice.org/1:3.0.1~rc1-2ubuntu1 !! [21:15] at last [21:18] urgh ... scary [21:18] update-initramfs: Generating /boot/initrd.img-2.6.27-7-generic [21:18] Segmentation fault [21:19] help ... now its: [21:19] update-initramfs: Generating /boot/initrd.img-2.6.27-9-generic [21:19] Illegal instruction [21:19] Segmentation fault [21:19] the beginning of the end? [21:21] you're doomed [21:21] * asac doesnt want a broken initramfs :( [21:21] and this happens after i invested about an hour to get this system working without monitor (e.g. had to remove graphics card) [21:23] openoffice.org_3.0.1~rc1-2ubuntu1.diff.gz (95.8 MiB) [21:23] lol, 100M compressed [21:23] openoffice.org_3.0.1~rc1.orig.tar.gz (319.7 MiB) d'oh! [21:24] ok creawting a new ramfs [21:24] please please please [21:24] it worked \o/ [21:25] but dpkg --configure -a tries it again :( [21:25] * asac prays [21:25] and reboots [21:26] ok no ping anymore :( ... lets hope it comes back ;) [21:27] what makes this even more shaky is the fact that its the first server running with NM-only in the universe i guess ;) [21:27] its back!!!! [21:27] i always new that NM is superior :-) [21:28] s/new/knew/ [21:33] fta: why doesn't sb not show up in system>preferences>preferred applications ? isn't a .menu file enough? [21:34] s/not// [21:35] preferred application is not using .menu [21:38]