[05:01] <DanaG> Odd: I only see two songs in my music player app.
[05:01] <DanaG> I assume /home/ume/media/sounds is where it goes?
[05:01] <DanaG> I made that a symlink to my host OS's music.
[05:09] <persia> DanaG: Do you have subdirectories in your host directory?  If so, are the two songs shown in the root directory?
[05:10] <persia> From testing on my install, it seems that /home/ume/media/sounds is not checked for directories
[05:11] <DanaG> Yeah.  But there are actually 4 files in the top-level dir.
[05:12] <DanaG> Correction: 3 files.
[05:12] <DanaG> 2 mp3 and one mod.  I guess that's why, for that dir.
[05:12] <persia> Very odd.  I showed about 20 when I dropped them in the top-level locally.  Is one of them a different codec, or not tagged cleanly?
[05:12] <persia> Ah, yes.  It's the .mod that doesn't show?
[05:12] <DanaG> Yeah, that makes sense.
[05:13] <DanaG> ﻿I have them in dirs, and that's how I organize things.  In fact, that's why I have an iAudio6, instead of countless alternatives.
[05:13] <DanaG> Oddly enough, the video player shows nothing, despite having several videos at the top level.
[05:14] <persia> That makes sense: especially for devices with >10GB, organisation makes sense.  Could you file a bug about that?
[05:14] <persia> At the top level of media/videos ?
[05:16] <DanaG> Right now I'm in a power outage (on a laptop, and cable modem and router on a UPS), so now's not a great time -- but where should I go file it?
[05:16] <DanaG> Yeah, I have several files there/  Let me check the codecs.
[05:16] <DanaG> Note: would having the thing it's symlinked to be RO mounted cause that breakage?
[05:16] <persia> http://bugs.launchpad.net/ubuntu/+source/moblin-media/ should show you the current list.  If it's not there, there's a link to file a bug.
[05:17] <DanaG> does that one package apply to both the audio and video players?
[05:17] <persia> I don't think blocking RO mounts makes sense.  Imagine the case where someone has a USB optical drive, and wants to play videos from there.
[05:17]  * persia double-checks
[05:18] <DanaG> One video is MPEG-1 video, MP1-layer2 audio (yep, obscure.  It's an old video.)
[05:18] <persia> DanaG: Music, Videos, and Photos.
[05:18] <DanaG> Another is XVID MPEG-4 video, MP3 audio.  The last is DivX5 video, MP3 audio.
[05:19] <DanaG> Oh yeah, and to build the virtualbox additions, I had to install lpiacompat stuff, since lpia stuff gave "disagrees on version of symbol" (don't remember the symbol name).
[06:40] <DanaG> Odd... wallpapers don't give scaling settings.
[06:40] <DanaG> And my VM seems to use the wrong resolution; what resolution is supposed to be default?
[06:41] <persia> DanaG: Most testing was done at 1024x600, and a fair amount at 800x480.  I don't think everything works for 800x480.
[06:42] <DanaG> Why do so many things use 1024x600?  That's an odd aspect ratio.  1024x640 is 16:10.
[06:43] <persia> DanaG: I suspect it's because the glass was cheap.
[06:43] <DanaG> Oh, and how do you use a bluetooth headset with the thing?
[06:43] <DanaG> (I've handed the VM my USB BT adapter)
[06:43] <persia> Personally, I'd rather have 1024x768, but maybe that's just me.
[06:44] <persia> Does the bluetooth icon show in the taskbar?
[06:44] <DanaG> Yup.  And I've even paired the headset.
[06:44] <DanaG> oddly enough, it shows up twice.  It offers both Headset and Handsfree profiles.
[06:44] <persia> That means you've got speakers & a mic.
[06:45] <DanaG> It doesn't show up in 'asoundconf list' or 'aplay -l' or 'aplay -L'
[06:49] <persia> I'm not sure.  I've never gotten bluetooth audio to work (although I haven't tried very hard with Ubuntu Mobile).
[06:49] <persia> I seem to remember there being some alsa module that needed loading, but I'm not sure if that is still true.
[06:49] <DanaG> You can supposedly do it with .asoundrc nowadays.
[06:49] <DanaG> However, oddly enough, I can't even RUN the "audio service" on the Intrepid ost.
[09:14] <ogra> oh, aldi has netbooks today here :)
[09:15] <ravocx> and where is here ?
[09:15] <ogra> germany 
[09:16] <ravocx> ah
[09:16] <ravocx> i was hoping the netherlands :P
[09:16] <ogra> aldi north ... (our aldi is split into two companies)
[09:40] <philn> hi
[09:40] <philn> i'm running mccaslin-lpia-hardy on a Q1... would like to calibrate the screen, anyone knows how to do that?
[09:41] <persia> philn: There ought be a calibration tool in the Preferences menu.
[09:43] <philn> where's that menu? i'm probably missing a package or fset
[09:46] <persia> philn: At the top of the screen, to the right of the home button, there ought be the word "All" and an arrow.
[09:47] <persia> Selecting "All" allows you to choose "Preferences", which shows some icons that are not included in "All", one of which should be the screen calibration tool.
[09:48]  * ogra thinks "all" should be renamed to "applications" or something if it doesnt really include "all" :)
[09:49] <ogra> lowers the confusion level :)
[09:49] <philn> i only see "all".. nothing related to preferences, either in that drop-down menu or in the launchers list
[09:51] <lool> philn: Which image is this?  one from ubuntu or self built?
[09:51] <philn> i used an image created with image creator
[09:51] <philn> self built
[09:52] <lool> philn: Do you have particular changes you care about in this image?
[09:52] <lool> philn: We use the Q1Full fset when building MIC images
[09:53] <lool> "crownbeach-full-mobile-stack"
[09:53] <philn> yes i care a bit ;) i compiled deps for elisa on it
[09:54] <lool> philn: Here's my tip: use a ppa, or pbuilder, or build packages natively instead
[09:55] <philn> well it's for some kind of demo, i'll do it better next time.. for now i just want to calibrate the touchscreen
[09:55] <lool> philn: Sure, I just wanted to save you the huge timesink that building images is
[09:55] <philn> and elisa 0.5 is not (ready to be) packaged yet anyway..
[09:56] <lool> philn: Did you install the ubuntu-mobile meta-package?
[09:56] <philn> yes
[09:57] <lool> You have moblin-applets?
[09:57] <philn> yes
[09:57] <philn> in fact i could launch the calibration tool from terminal
[09:58] <philn> but doesn't seem to work, i can't tap the damn blinking target ;)
[09:58] <lool> philn: image-creator --platform-name=menlow-lpia-ume --fset crownbeach-full-mobile-stack -c list-pkgs
[09:58] <StevenK> It's not menlow
[09:58] <lool> philn: Will tell you which packages get pulled for this fset
[09:59] <philn> i'm on mccaslin
[09:59] <lool> You get the idea, replace platform and fset with what you care about
[10:02] <lool> philn: moblin-touchscreen from terminal should do the calibration I would think
[10:02] <lool> it's in moblin-applets
[10:02] <lool> asac: Hey did you see my last message to bspencer and rustyl where I was saying you might send an up-to-date patch?
[10:03] <asac> lool: nope
[10:04] <lool> around Date: Wed, 25 Jun 2008 22:43:48 +0200
[10:04] <asac> oh
[10:04] <lool>  Alexander: could you push your git tree to the mbf hardy branch or to a
[10:04] <lool>  new branch rebased on top of master?  Or anything which allows Bob to
[10:04] <lool>  review the final changes or xulrunner 1.0 support.
[10:04] <lool> sorry, was in the middle of the msg
[10:04] <asac> lool: not sure if i have the final changes ;) ... i have my changes ... we need to sync them
[10:04] <asac> will get back to you later today on this. stay tuned
[10:05] <lool> asac: Cool
[10:05] <lool> asac: Can I grab you two secs on other xulrunner stuff?
[10:05] <asac> lool: just ask ;)
[10:05] <lool> asac: evolution-rss can be built against --gecko=libxul or libxul-embedding; how to pick the correct one?
[10:06] <lool> asac: And the second thing is I'm stuck porting galeon to xulrunner 1.9; I've given up on it and I've asked glandium and upstream to look at my in progress patches if they'd like to complete the port, but I didn't understand how to finish it
[10:07] <asac> lool: what is evolution-rss? a standalone application?
[10:07] <lool> So I'm pinging you as well in case you have some secret dependance on xul 1.9 porting; I wouldn't be surprized porting apps to xul 1.9 is the drug which keeps you awake
[10:07] <asac> ha
[10:07] <asac> ;)
[10:07] <lool> asac: It's a plugin for evolution, so I would think it should try to reuse evolution's xul if possible
[10:08] <asac> lool: does evo load xul at all?
[10:08] <asac> otherwise use the -embedding thing
[10:08]  * ogra thought evo still used gtkhtml 
[10:09] <lool> philn: Ah sorry it doesn't work; I saw it broken from time to time too; perhaps file a bug against moblin-applets (upstream project) or against ubuntu-mobile (upstream project)?
[10:09] <asac> lool: how did galeon fail? missing symbols?
[10:09] <lool> asac: Hmm indeed not sure evo uses xul at all
[10:09] <lool> asac: So libxul-embedding if there's no other xul to reuse and libxul if there's one, correct?
[10:09] <lool> asac: Yeah, ultimately missing symbols
[10:10] <lool> But to reach this point I did things which I'm not fully understanding
[10:10] <lool> All my notes are in the xulrunner 1.9 port bug reports in the Debian BTS
[10:10] <lool> asac: Oh heck, I'm not sure you want to spend time on galeon
[10:10] <ogra> evo: gtkhtml3.14
[10:10] <lool> Everybody says it's completely useless once ported anyway
[10:10] <lool> ogra: yes exactly
[10:10] <ogra> (from the deps)
[10:10] <lool> So no xul so should use -embedding
[10:30] <asac_> lool: i am sorry. my connection is really bad today
[10:31] <asac_> lool: whats the bug id?
[10:31] <asac_> just want to take a quick look
[10:31] <asac_> but i think galeon is definitly one of the more interesting pieces of software to port
[10:31] <lool> asac_: I was saying don't spend time on galeon; it's going to be useless even once ported
[10:32] <lool> asac_: Many critical features don't work at all with xul 1.9 and need to be rewritten  :-/
[10:32] <lool> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480799
[10:32] <lool> asac_: There are some inprogress patches, but the bulk of the acceptable patches are in svn.debian.org/svn/pkg-galeon/unstable/galeon already
[10:35] <asac_> lool:  if test "x$has_gtkmozembed" = "xno"; then
[10:35] <asac_> is that block to be ment 1.8 or 1.9?
[10:35] <asac_> (in your configure.in patch)
[10:35] <lool> asac_: There's a later check I thikn
[10:37]  * lool checking out from his hardy box
[10:39] <asac_> lool: the svn configure patch looks ok without looking at the target source
[10:39] <asac_> there is no glue startup code, but i guess thats already in upstream orig?
[10:39] <lool> asac_: It should be
[10:39] <lool> asac_: Upstream 2.0.5 *claims* to support xulrunner 1.9
[10:39] <asac_> lool: so how does it fail?
[10:40] <lool> But in practice it didn't build due to API changes
[10:40] <asac_> at least the NSPR switch is not turned on
[10:40] <lool> asac_: Well many things really
[10:40] <philn> lool: ok, i'll try a more recent image.. is it ok to try one your pre-built images?
[10:40] <lool> philn: definitely
[10:40] <lool> philn: I mean it can't hurt
[10:41] <asac_> lool: if you give me the orig for the latest svn i can run it in the background and see how bad if fails ;)
[10:41] <philn> lool: there? http://cdimage.ubuntu.com/mobile/releases/hardy/
[10:41] <lool> asac_: Well I've sent a combined patch of all ugly things I did, but I think it's highly incorrect
[10:41] <lool> philn: Yes
[10:42] <lool> asac_: Mike said I should drop the rpath setting
[10:42] <lool> asac_: Do you think I should drop it unconditionally for xulrunner 1.0?
[10:42] <lool> 1.9
[10:42] <lool> asac_: BTW I checked the fedora patches and these are a subset of mine; it seems they have an easier time building against xulrunner 1.9   :-(
[10:42] <asac_> lool: if we only support "-embedding", then yes. otherwise you need to drop if if we use libxul-embedding*
[10:42] <asac_> otherwise not
[10:43] <asac_> (for instance epiphany should work with libxul + rpath OR libxul-embedding
[10:43] <asac_> but embedding is definitly preferred
[10:43] <lool> I think we only need to support embedding as galeon typically bootstraps the xul
[10:43] <lool> asac_: Why does epiphany need to run with libxul?
[10:43] <asac_> lool: fedora did only care about getting things to compile
[10:44] <lool> Yeah
[10:44] <asac> lool: it doesnt need to. chpe just refused to believe the -embedding is the right way so i coded both options to make him happy
[10:44] <lool> asac_: Concerning that gtkmozembed conditional in configure.in, I thought it wasn't too important to touch as -lxul is probably added by the pkg-config flags earlier anyway and wasn't too useful
[10:44] <lool> asac: arf ok :)
[10:45] <asac> lool: -lxul must not be used in standalone glue either
[10:45] <asac> the only lib you link against is -lxpcomglue
[10:45] <asac> and maybe nspr if your need it
[10:45] <asac> so the output of pkg-config --libs libxul-embedding
[10:45] <lool> asac: What's hard in galeon is that they are compatible with last 10 years of xulruners
[10:46] <asac> lool: same is true for epiphany
[10:46] <lool> The configure and code are ifdefed all over the place, it's not only supporting the latest xul but everything
[10:46] <lool> asac: Indeed
[10:46] <asac> but nobody actually knows if the code still works
[10:46] <asac> they keep the configure stuff and make their own life harder
[10:46] <lool> asac: Except epiphany moved to some sensible m4 macros which do the work behind the scene; in galeon the configure.in script feels like a mess now
[10:47] <lool> Right epiphany still looks litlle complex
[10:47] <asac> lool: yeah ;) unfortunately all this appears to come from the same source. so other build systems have it too
[10:47] <asac> some follow the .m4 approach of epiphany
[10:47] <asac> others copy the in-configure code from whoknowswhere
[10:48] <lool> So should I set MOZILLA_GTKMOZEMBED=$gecko just like _XPCOM?
[10:48] <lool> And hence make the test succeed and hence don't append -lxul to the link flags?
[10:48] <asac> lool: the idea is to use the PKG_CHECK_MODULES result for libxul-embedding(-unstable) for every CFLAGS and LDFLAGS
[10:48] <lool> What I hate with the current approach is that it becomes unknown what serves which xulrunner versions
[10:49] <lool> I wouldn't mind having 10 macros one for each version, but having a huge snippet handling all cases is a mess  :-/
[10:49] <asac> lool: yeah. assume that all the manual LDFLAGS + CFLAGS things are ment for mozilla <=1.7
[10:49] <asac> maybe even << 1.7
[10:49] <lool> wow, that's old
[10:49] <asac> aka 1.4
[10:49] <lool> asac: What about rpath?  should I drop it?
[10:50] <asac> lool: i think i inserted a configure test to check if -DXPCOM_GLUE is defined by CFLAGS
[10:50] <asac> if you want to do it right, check for that and if that is defined, drop rpath
[10:51] <lool> asac: Ok; one build issue I had needed me to set some XPCOM_GLUE_US_NSPR define manually to build
[10:51] <lool> asac: i didn't quite understand how it was supposed to be set
[10:51] <asac> lool: http://paste.ubuntu.com/24672/
[10:52] <lool> Excellent
[10:52] <asac> lool: need to set CFLAGS to the CFLAGS with the xul flags of course
[10:53] <asac> but i guess you know how COMPILE macros are used ;)
[10:53] <asac> http://paste.ubuntu.com/
[10:54] <asac> thats more complete
[10:54] <asac> you need a LANG_POP at the end i guess
[10:54] <lool> asac: ELINK
[10:54] <asac> err sorry: http://paste.ubuntu.com/24675/
[10:54] <lool> asac: Should I bother setting mozilla_home?
[10:55] <asac> _GECKO_CFLAGS=`pkg-config --cflags $MOZILLA_XPCOM`
[10:55] <asac> lool: you need MOZILLA_HOME for non-standalone glue cases
[10:55] <asac> lool: in epiphany i added a --with-gecko-home=... flag
[10:55] <lool> Yeah, that's what I copied last week
[10:55] <asac> as you cannot get the MOZILLA_HOME anymore
[10:55] <lool> Exactly, didn't find it in .pc files
[10:56] <asac> so basically ... if GECKO >= 1.9 => --with-gecko-home is required for "normal" libxul
[10:56] <asac> for 1.8 you can still use the old auto-guess heuristic
[10:56] <asac> lool: but i wouldnt put too much work into the "libxul" part .... really
[10:56] <asac> even glandium agrees that standalone glue is the idea ;)
[10:57] <asac> lool: i'd say: if XPCOM_GLUE => drop -rpath and unset MOZILLA_HOME
[10:57] <asac> otherwise try the auto guess ... if that fails => bad luck
[10:58] <lool> asac: What should I use for CFLAGS in the general case for the -DXPCOM_GLUE?  Should I only run this test if libxul-embedding?
[10:58] <asac> lool: I'd suggest to just test for XPCOM_GLUE .... and drop -rpath + MOZILLA_HOME if its set
[10:58] <asac> and dont bother about any corner cases
[10:59] <asac> even 1.8 had a standalone glue iirc
[10:59] <asac> but nobody used it ;)
[10:59] <lool> asac: So which flags should I use for the xpcom glue test?  special flags for this test, the "xpcom" ones, the "embedded" ones?
[10:59] <asac> lool: so you always use your GECKO_CFLAGS
[10:59] <asac> lool: use the MOZILLA_XPCOM ones
[11:00] <lool> There's no such thing in galeon currently
[11:00] <asac> (i guess for 1.9 they are the same)
[11:00] <lool> Ok, will use _xpcom
[11:01] <asac> in epiphany i defined a conditional for HAVE_XPCOM_GLUE so i could remove the -rpath thing from Makefile.am
[11:01] <asac> if galeon adds the -rpath in configure you probably dont need it ... but i dont know
[11:01] <lool> Ok, I planned doing an AM_CONDITIONAL as well
[11:02]  * asac tries to remember what he wanted to do ;)
[11:02] <ogra> work on mobile stuff indeed :)
[11:02] <asac> haha
[11:03] <asac> ogra: i felt quite mobile yesterday when i experienced a great 3g connection throughout my whole RegionalBahn Trip ;)
[11:03] <asac> note: my cell-phone usually has no connection throughout most parts of the same trip ;)
[11:03] <ogra> regional ? 
[11:03] <ogra> wow
[11:03] <asac> yeah ... not even ICE
[11:03] <ogra> my ICEs all have wlan now
[11:04] <ogra> thats the advantage of living in the middle of the country :)
[11:04] <asac> ogra: NM connects much quicker to 3g ;)
[11:04] <asac> like in 1 second i get connection + IP
[11:04] <ogra> cool
[11:04] <asac> now I know what marcel ment with "dhclient is real crap" :)
[11:04] <ogra> heh
[11:05] <ogra> well, its good on servers (if you even use dhcp at all there)
[11:05] <asac> ogra: the lease feature is nice
[11:05] <asac> the point is that there apear to be a bunch of sleeps that slow down things by seconds (iiu him correctly)
[11:05] <lool> asac: What's that -dlopen self thing?
[11:05] <asac> lool: where?
[11:06] <lool> galeon_LDFLAGS = -R$(MOZILLA_HOME) -dlopen self
[11:06] <asac> never seen that before
[11:06] <asac> i guess this can be dropped
[11:07] <asac> together with the -R
[11:07] <lool> asac: BTW what do you plan to do with the xulrunner-dev xulrunner-1.9-dev pacakge name mismatch?
[11:08] <asac> lool: I will swallow that and provide a compatibility package
[11:08] <asac> lool: its unreasonable imo 
[11:08] <asac> and smells like intention
[11:08] <lool> :-/
[11:08] <lool> checking whether we have a xpcom glue... yes
[11:08] <lool> Using libxul-embedding-unstable version 1.9
[11:08] <asac> let me commit that now
[11:09] <asac> yay
[11:09] <asac> looks good 
[11:09] <lool> In file included from MozRegisterComponents.cpp:30:
[11:09] <lool> ProgressListener.h:75: warning: 'GProgressListener' declared with greater visibility than the type of its field 'GProgressListener::<anonymous>'
[11:09] <asac> anyone has lost his caret on gnome-terminal recently?
[11:09] <lool> That's the one where it looks like nspr isn't properly used
[11:09] <asac> mine is gnome here now ;)
[11:09] <asac> just black
[11:10] <asac> lool: does galeon still use MOZILLA_INTERNAL_API
[11:10] <lool> http://people.ubuntu.com/~lool/galeon_2.0.5-1_amd64.build
[11:10] <asac> maybe grep for that
[11:10] <lool> it does
[11:10] <lool> galeon-2.0.5/configure.in:              [[#define MOZILLA_INTERNAL_API
[11:10] <asac> yeah thats what has to go
[11:10] <lool> galeon-2.0.5/mozilla/GaleonJS.cpp:#define MOZILLA_INTERNAL_API
[11:10] <lool> galeon-2.0.5/mozilla/GaleonJS.cpp:#undef MOZILLA_INTERNAL_API
[11:10] <asac> to use standalone glue
[11:11] <asac> lool: drop that define ... and fix the build errors :-D
[11:11] <asac> well ... at least you can send the better configure upstream ... they should switch to frozen linkage
[11:11] <philn> ok, now the applet works, but only the 2 first targets works. i click on third and the applet thinks calibration is finished, asks me to save settings or not
[11:12] <asac> lool: http://developer.mozilla.org/en/docs/Migrating_from_Internal_Linkage_to_Frozen_Linkage
[11:13] <asac> the idea of frozen linkage is that you can use that, ship binaries to the world and they will always work in future ;)
[11:13] <lool> I don't quite understand how internal_api is set/not set
[11:13] <lool> I mean in galeon
[11:13] <asac> lool: if you define MOZILLA_INTERNAL_API you get symbols that are hidden in libxul
[11:13] <lool> There are many checks with mozilla_internal_api
[11:13] <asac> lool: so you just drop that define
[11:15] <lool> I mean, I'm trying to locate it
[11:15] <lool> It's not set in configure, configure only checks whether it needs to use that flag to get some API
[11:15] <lool> And it decides it doesn't I think
[11:16] <asac> lool: galeon-2.0.5/mozilla/GaleonJS.cpp
[11:16] <asac> explicitly defines it?
[11:17] <lool> in #ifdef HAVE_NSISCRIPTCONTEXT_INTERNAL_API
[11:17] <asac> ok and that is false?
[11:17] <lool> Define if nsIScriptContext is MOZILLA_INTERNAL_API */
[11:17] <lool> #undef HAVE_NSISCRIPTCONTEXT_INTERNAL_API */
[11:17] <lool> in config.h
[11:17] <asac> are you trying galeon 2.0?
[11:17] <lool> 2.0.5
[11:18] <lool> mozilla/MozillaPrivate.cpp also uses #ifdef HAVE_NSSTRING_INTERNAL
[11:18] <lool> which is undef
[11:19] <asac> but you see the define during compile?
[11:19] <lool> ah
[11:19] <lool> mozilla/GaleonAboutModule.cpp does it unconditionally
[11:19]  * asac looking
[11:20] <asac> ok its the same mess we had in epiphany
[11:20] <asac> nsString.h => nsStringAPI.h
[11:20] <asac> s/.*nsEscape.h.*/
[11:20] <lool> it's undefined
[11:20] <asac> what is undefined?
[11:21] <lool> MOZILLA_INTERNAL_API
[11:21] <asac> in AboutModule?
[11:21] <asac> for me its defined there
[11:21] <lool> asac: No in MozRegisterComponents.cpp
[11:21] <lool> where my build fails
[11:21] <asac> oh ok
[11:22] <lool> mozilla/GaleonAboutModule.cpp uses nsstring.h and #defines MOZILLA_INTERNAL_API but Im' not that far
[11:23] <lool> I don't see any nsescape there either
[11:23] <lool> There's one in mozilla/GaleonAboutModule.cpp
[11:24] <asac> lool: i think the only field of ProgressListener that might have hidden type is GulCString
[11:26] <lool> asac: BTW ATM I'm just running svn-buildpackage from the pkg-galeon tree
[11:26] <asac> lool: without the improved configure?
[11:26] <lool> asac: I committed the improved configure now
[11:26] <asac> lool: how do i run svn-buildpackage?
[11:27] <lool> asac: You run svn-buildpackage :)
[11:27] <lool> seriously, from the galeon dir
[11:27] <lool> you need to create ../tarballs
[11:27] <lool> and drop the upstream tarball in there with the .orig name
[11:27] <asac> k
[11:27] <lool> (or a symlink with that name)
[11:27] <lool> Or you forget about sbp and just copy the debian/ in an unpacked tarball :
[11:27] <lool> :)
[11:28] <asac> lool: i dont have the orig ;)
[11:29] <lool> galeon.sf.net
[11:29] <lool> http://sourceforge.net/project/downloading.php?group_id=6999&use_mirror=kent&filename=galeon-2.0.5.tar.gz&22444074
[11:29] <asac> it builts ;)
[11:29] <asac> err, started
[11:29] <lool> Cool
[11:30] <lool> I would have switched to quilt would I have known I would have to pile to many patches
[11:30] <asac> hehe
[11:30] <lool> When I read 2.0.5 was supporting xulrunner 1.9 I thought it was a one or two hour job to perhaps adjust things for Debian/Ubuntu
[11:30] <lool> How wrong I was
[11:31] <lool> I spent most of a sunday on it and a couple of evenings since
[11:31] <asac> well ... not sure why they wrote it. i looked at the sources at some point when they claimed xulrunner 1.9 and didnt understood ;)
[11:31] <lool> Even fedora people had to patch, but not so much as we're doing it now
[11:32] <asac> lool:                 rv = NS_NewGenericFactory(getter_AddRefs(componentFactory),
[11:32] <asac>                                           &(sAppComps[i]));
[11:32] <asac> lool: does it work on fedora?
[11:32] <lool> Ah I think they patched that
[11:32] <asac> thats non-frozen linkage
[11:32] <lool> http://cvs.fedoraproject.org/viewcvs/rpms/galeon/F-9/
[11:33] <lool> galeon-2.0.5-build-fix.patch  and galeon-2.0.5-xulrunner.patch 
[11:33] <lool> -	presShell->GetDocument(getter_AddRefs(doc));
[11:33] <lool> +	doc = presShell->GetDocument();
[11:33] <lool> It's not the same, sorry
[11:34] <asac> lool: let me look for the right pattern ;) 
[11:34] <lool> 05:23 < philipl> hgb: Ah. flashblock doesn't work, but adblock does.
[11:34] <lool> 05:24 < philipl> extensions that need xul don't work.
[11:34] <lool> that's from #galeon
[11:36] <asac> lool: http://bugzilla.gnome.org/attachment.cgi?id=100976
[11:36] <asac> search for "genericfactory"
[11:36] <asac> thats the inittial epiphany patch which still had that frozen linkage migration
[11:37] <asac> i have the feeling that after fixing this galeon will fly ;)
[11:37] <asac> hehe
[11:37] <asac> let me know when you have committed that to svn so i can test :)
[11:38] <lool> asac: Is that backwards compatible or do I need to enclose it in a fake test and tell upstream to add a test for it?  ;)
[11:38] <asac> lool: its backwards compatible
[11:39] <asac> the NS_New thing is just a short hand which is not available in frozen linkage
[11:39] <asac> lool: even if its not, upstream should polish this imo. we are working for 1.9 here only (same in debian)
[11:40] <asac> but i think thats good to have everywhere
[11:42] <asac> lool: some minor bad news. they dont have the xpcom glue startup code yet. that has to go to mozilla/mozilla-embed-shell.cpp
[11:44] <asac> the snippet is in http://bugzilla.gnome.org/attachment.cgi?id=102329 in the embed/mozilla/mozilla-embed-single.cpp patch
[11:44] <lool> asac: committed
[11:44] <lool> the generic factory part
[11:44] <asac> yeah
[11:45] <asac> lool: does it build already?
[11:45] <lool> I just kicked a build
[11:45] <asac> kk
[11:46] <lool> asac: Right that xul startup code I grepped for (remembered from mbf port), but didn't findin galeon
[11:46] <lool> It fails at:
[11:46] <lool> JSConsoleListener.cpp: In member function 'virtual nsresult JSConsoleListener::Observe(nsIConsoleMessage*)':
[11:46] <lool> JSConsoleListener.cpp:53: error: 'class nsIConsoleMessage' has no member named 'GetMessage'
[11:46] <lool> I think Fedora fixed that one though
[11:47] <lool> asac: debian/patches/66_non-threadsafe-gconsolemessage-isupports.patch what doyou think of the change?
[11:47] <lool> I copied it from the comments in the generated templates, but dropping the threadsafe part is scary
[11:47] <lool> -NS_IMPL_THREADSAFE_ISUPPORTS1(GConsoleMessage, nsIConsoleMessage)
[11:47] <lool> -
[11:47] <lool> +NS_IMPL_ISUPPORTS1(GConsoleMessage, nsIConsoleMessage)
[11:49] <asac> lool: GetMessage is now GetMessageMoz
[11:49] <lool> Yeah
[11:49] <asac> ok
[11:49] <lool> I just changed that, testing new patch
[11:49] <asac> lool: dont drop the THREADSAFE thing
[11:49]  * lool thanks his amd64 and ccache
[11:49] <asac> if we use XPCOM_GLUE_WITH_NSPR
[11:50] <lool> It's 3 times slower on i386
[11:50] <asac> (threadsafe requires nspr)
[11:50] <asac> lool: maybe fedora doesnt enable GLUE with NSPR?
[11:50] <lool> GaleonWrapper.cpp:1648: error: 'nsresult GConsoleMessage::GetMessageMoz(PRUnichar**)' cannot be overloaded
[11:50] <asac> do we do that?
[11:50] <lool> GaleonWrapper.cpp:1646: error: with 'virtual nsresult GConsoleMessage::GetMessageMoz(PRUnichar**)'
[11:50] <asac> lool: what did you change?
[11:51] <lool> So this looks like type mismatch -- and I don't understand how they could possibly get this to build
[11:51] <lool> asac: I just renamed GetMessage to GetMessageMoz
[11:51] <asac>         aMessage->GetMessage (&message); ?
[11:52] <asac> thats the line that fails for me here
[11:52] <asac> which should be aMessage->GetMessageMoz
[11:52] <lool> added patch in SVN
[11:52] <asac> works ;)
[11:52] <lool> asac: Uh sorry
[11:52] <lool> asac: I suck
[11:52] <asac> i just changed that line like above
[11:52] <philn> i don't have hw acceleration anymore :(
[11:52] <asac> now build ha sfinished ;)
[11:52] <asac> (well, the mozilla/ tree)
[11:52] <lool> philn: Ah you need the proprietary 3D driver for this
[11:53] <lool> philn: Uh no, not on Q1 sorry
[11:53] <asac> lool: ok. with that change we only need to add the proper standalone startup code
[11:53] <lool> asac: Well i also renamed the implementation
[11:53] <lool> -    NS_IMETHODIMP GetMessage(PRUnichar **result)
[11:53] <lool> +    NS_IMETHODIMP GetMessageMoz(PRUnichar **result)
[11:53] <asac> hehe
[11:53] <asac> thats wrong ;)
[11:53] <philn> DRI seems to be loaded fine, dixit my Xorg.log.. but glxinfo tells me otherwise
[11:53] <lool> which causes the new failure
[11:54] <lool> asac: Fedora did this :)
[11:54] <asac> hmm
[11:55] <lool> Anyway, I did like you suggested in my tentative patches this week, but got another issue later on I think
[11:55] <lool> In the end I was just flipping between the two during build; how ufly
[11:55] <lool> *ugly
[11:55] <philn> oh there are some updates to install, let's try that
[11:56] <lool> philn: Oh yes you definitely need to use all libdrm and xorg and driver updates
[11:56] <lool> philn: you want the -19 kernel
[11:56] <lool> asac: Cool it goes up to link now!
[11:56] <lool> asac: You did as well in a couple of hours as me in 3 days :)
[11:56] <philn> lool: ok, thx!
[11:56] <asac> lool: ok. now add the proper glue code and go ;)
[11:57] <asac> search for the first poing of startup ... e.g. usually looking for push_startup is a god start
[11:58] <lool> mozilla/mozilla-embed-shell.cpp looks like it
[11:58] <lool> Hmm it's all exploded in sub functions
[11:59] <asac> lool: i think shell_init
[11:59] <asac> is the place
[11:59] <lool> mozilla_init_profile() also need to be changed I think
[11:59] <asac> you need to remove all current startup code with #ifdef XPCOM_GLUE
[11:59] <asac> and replace that with the snippet
[11:59] <asac> lool: the mozilla_init_profile can probably stay
[12:00] <asac> (after the glue startup)
[12:00] <asac> but plugin_path is not required iirc
[12:00] <lool> mozilla_init_plugin_path should happen after push startup, but can it be kept?
[12:00] <asac> lool: if it works, it works
[12:00] <asac> cant tell
[12:01] <asac> at least the global plugins are definitly loaded by the xulrunner
[12:01] <lool> asac: Can I drop the non-xpcom glue case?
[12:01] <lool> and the whole define?
[12:01] <asac> lool: I'd say you should #else it
[12:01] <lool> hmm no, not for << 1.8
[12:01] <lool> I can probably the gecko 1.9 part in the else
[12:02] <lool> That I don't care about
[12:02] <asac> lool: even for 1.8 we need it as debian/ubuntu doesnt ship any glue in their 1.8 packages
[12:02] <lool> but for non-glue 1.9, I don't care, right?
[12:02] <asac> yes
[12:02] <asac> but the code should still work if you support libxul with -rpath and so on in configure (which you didnt do afaict)
[12:03] <lool> i'll consider non-glue means < 1.9
[12:03] <asac> yeah ... go for that for now
[12:03] <lool>         gtk_moz_embed_set_comp_path (mozilla_home);
[12:03] <lool> #ifdef HAVE_GTK_MOZ_EMBED_SET_PATH
[12:03] <lool>         gtk_moz_embed_set_path (mozilla_home);
[12:03] <lool> #endif
[12:03] <lool> Is what init_home does
[12:04] <lool> and you do one or the other based on xpcom glue
[12:04] <lool> should I keep galeon's way or yours?
[12:05] <lool> (so it would call both in our case)
[12:06]  * lool tries a combo
[12:07] <asac> lool: the set_path and set_comp_path wont work if mozilla_home is wrong
[12:08] <lool> asac: I dropped yours and kept galeon's
[12:08] <asac> mozilla_home is the GREPath you get from the standalone snipped
[12:08] <lool> Which happen in -------mozilla_init_home
[12:08] <asac> for 1.9
[12:08] <lool> I moved the push startup after init profile like it was
[12:08] <asac> GALEON_MOZILLA_HOME is not set for us
[12:08] <lool> oh
[12:08] <lool> indeed
[12:09] <asac> you need to use the path you get from the gre startup snippet
[12:09] <asac> e.g. rv = GRE_GetGREPathWithProperties(&greVersion, 1, nsnull, 0, xpcomLocation, 4096);
[12:09] <asac> +    if (NS_FAILED(rv)) {
[12:09] <lool> Ok; I'll keep yours and call mozilla_init_home() in the else
[12:09] <asac> xpcomLocation
[12:09] <asac> yeah
[12:10] <lool> GALEON_MOZILLA_HOME is also used in mozilla_init_plugin_path
[12:10] <asac> lool: is GALEON_MOZILLA_HOME set in Makefile?
[12:10] <asac> if so, you can just comment those snippets by
[12:10] <asac> #ifdef GALEON_MOZILLA_HOME
[12:11] <lool> asac: It's set in makefile unconditionally
[12:11] <asac> and take care that its not passed if we HAVE_XPCOM_GLUE
[12:11] <asac> lool: yeah. then you need the AM_CONDITIONAL HAVE_XPCOM_GLUE i guess
[12:11] <asac> or if you have a AC_DEFINE for that you can use that of course
[12:11] <philn> lool: using -19 kernel and available updates, still doesn't work :/
[12:11] <asac> but makes more sense to test for HOME imo
[12:11] <asac> in code
[12:14] <lool> philn: works for me; glxinfo shows plenty of stuff
[12:14] <lool> but I don't have dri hmm
[12:15] <lool> philn: I get slow 3D rendering too
[12:16] <lool> asac: Trying a build with that now
[12:17] <philn> lool: i don't have direct rendering either
[12:17]  * asac crosses fingers
[12:18] <lool> ah my trick didn't work need to rewrite the makefile.am part
[12:20]  * lool rekicks build
[12:21] <lool> I should make -j2 during these sessions, I always forget to do it
[12:21] <lool> mozilla-embed-shell.cpp:390: error: return-statement with a value, in function returning 'void'
[12:21] <lool> I shouldn't have copy-paster blindly
[12:24] <lool> asac: ../mozilla/.libs/libmozillaembed.a(GaleonWrapper.o): In function `nsTime':
[12:24] <lool> /usr/include/xulrunner-1.9/unstable/nsTime.h:68: undefined reference to `PR_ParseTimeString'
[12:24] <lool> and some others
[12:24] <lool> asac: build log at same location
[12:25] <lool> Not many really
[12:25] <lool> asac: ../mozilla/.libs/libmozillaembed.a(GaleonWrapper.o):(.data.rel.ro._ZTV15GConsoleMessage[vtable for GConsoleMessage]+0x28): undefined reference to `GConsoleMessage::GetMessageMoz(unsigned short**)'
[12:25] <lool> asac: That's the one where I told you I need to rename implementation as well :-(
[12:25] <asac> lool: ok so return statement is fixed?
[12:25] <asac> just nsTime thing?
[12:26] <asac> yeah
[12:26] <lool> Yes I cheated and just return instead of dealing properly with the error
[12:26] <asac> ok
[12:26] <asac> thats a good trick ;)
[12:26] <lool> see end of http://people.ubuntu.com/~lool/galeon_2.0.5-1_amd64.build
[12:26] <asac> lool: you could also exit (1) :)
[12:26] <asac> byebye
[12:26] <lool> haha
[12:27] <lool> anyway this is much better to anything I ever gotten, especially considering the fact that it's not cheer luck but you actually know what you're doing :)
[12:27] <lool> While I didn't :)
[12:28] <asac> lool: PR_Now should work
[12:28] <asac> lool: what you are missing is LDFLAGS for pkg-config --libs nspr
[12:28] <asac> which makes sense as you use XPCOM_GLUE_USE_NSPR
[12:28] <lool> I do?
[12:28] <philn> lool: fix proposed at https://bugs.edge.launchpad.net/ubuntu/+source/samsung-q1-ultra-config/+bug/207360 works for me
[12:28] <asac> lool: i think so ... otherwise THREADSAFE macros would fail
[12:29] <lool> I didn't set XPCOM_GLUE_USE_NSPR in today's build; I tried doing it this week though
[12:29] <lool> I removed the threadsafe macros
[12:29] <asac> hmm
[12:29] <asac> lool: we need that macro for sure
[12:29] <asac> _and_ threadsafe macros
[12:30] <lool> philn: Cool; can you poke the bug?
[12:30] <asac> the threadsafe thing is  a bug in xul which will not be fixed before 2.0
[12:30] <philn> sure
[12:30] <lool> asac: So should I revert the threadsafe macro removals I did?
[12:30] <lool> 66_non-threadsafe-gconsolemessage-isupports.patch and 67_nsimpl-support-gtknssclientauthdialogs.patch I think
[12:31] <lool> asac: ^
[12:31] <asac> lool: yes + link against nspr and use that macro
[12:31] <lool> asac: In which cases should I link to nspr?
[12:31] <asac> err that define (XPCOM_GLUE_USE_NSPR)
[12:32] <lool> ?
[12:32] <asac> lool: only in cases where you need the THREADSAFE MACROS
[12:32] <asac> which is unfortunately and breaches the ideal
[12:32] <lool> asac: So should I do this unconditionally in Galeon?
[12:32] <asac> (as you get nspr library dependencies)
[12:32] <asac> lool: yes, ifdef XPCOM_GLUE => define ...USE_NSPR
[12:33] <asac> and ifdef ...USE_NSPR => MOZILLA_XPCOM_LIBS="$MOZILLA_XPCOM_LIBS `pkg-config --libs nspr`"
[12:33] <lool> asac: And pkg-config as well?  ifdef xpcom_glue => pkgconfig nspr?
[12:33] <asac> yeah
[12:33] <lool> ok
[12:33] <lool> That's going to be mightly ugly hmm
[12:34] <lool> asac: I'm disappearing shortly for lunch, bbl
[12:34] <lool> asac: thanks a lot!
[12:34] <asac> well ... its in line with the current configure.in approach ;)
[12:34] <asac> hehe
[12:34] <asac> ok
[12:35] <asac> welcome
[12:35] <asac> if it serves our debian/upstream relationsship i am happy to help ;)
[12:35] <asac> and not doing it on my own helps me to spread know-how + i dont need to suffer the typing ;)
[12:41] <philn> launcher icon and .desktop file is no longer in /usr/share/mobile-basic-flash ?
[12:43] <ravocx> if i want to checkout ubuntu-mobile. which device should i buy?
[12:46] <persia> ravocx: You probably want to first test with a virtual image.  Any A110 or Atom device ought at least work, although the current images work best on a Samsung Q1U.
[12:46] <ravocx> good plan
[12:46] <ravocx> so the Samung Q1U is the platform most developed on ?
[12:47] <ravocx> that device looks really nice. love to develop my home automation project on that
[12:48] <lool> ravocx: It's not very representative of the technical characteristics of the target platform, but it's commnly available and maps well to the target form factor
[12:48] <lool> it's decently supported under linux except webcam
[12:48] <ravocx> what is the target platform then ?
[12:48] <persia> ravocx: If you're working on a home-automation platform, I wouldn't start with the Q1U: you'd do better to determine your target hardware based on your project requirements, and then get Ubuntu Mobile to work on that hardware.
[12:49] <lool> lpia
[12:49] <lool> menlow for now
[12:49] <persia> lool: Isn't Q1U lpia?  I thought those were A110s
[12:49] <ravocx> persia: the device will be more a frontend for the project
[12:49] <lool> persia: hmm right, it's already lpia
[12:50] <persia> ravocx: Right: if you want a tablet, you don't need the Q1U keyboard.  If you want a keyboard, you likely want a different device.
[12:51] <persia> Picking the right front-end is key, and you can run on any lpia device.
[12:51] <ravocx> that's true. don't need a keyboard for the front-end, you should do the main config on a desktop
[12:54] <persia> ravocx: So, pick a device that meets your ergonomic needs and runs A110 or Atom, and then you're 90% of the way there.
[12:54] <ravocx> indeed
[12:54] <ravocx> thanks
[12:56] <ogra> ravocx, will that be an opensource project or just rivate hacking ? 
[12:56] <ogra> *private
[12:57] <ravocx> at first private hacking
[12:58] <ravocx> but it will be an open source project
[12:58] <ogra> cool
[12:58] <ogra> make sure to get it packaged for ubuntu :)
[12:58]  * ogra has a big house and is tempted to try home automation ...
[12:59] <ogra> but short on time to invest into hacking and soldering :)
[12:59] <ravocx> hehe
[12:59] <ravocx> soldering and i dont go well together
[12:59] <ravocx> the project is based on x10 hardware
[13:00] <ravocx> just started the project, and don't have a lot of free time on my hands
[13:00] <ravocx> but i can dim my lights now through code
[13:08] <lool> asac: It's better now
[13:08] <lool> ../mozilla/.libs/libmozillaembed.a(GaleonWrapper.o):(.data.rel.ro._ZTV15GConsoleMessage[vtable for GConsoleMessage]+0x28): undefined reference to `GConsoleMessage::GetMessageMoz(unsigned short**)'
[13:08] <lool> ../mozilla/.libs/libmozillaembed.a(ExternalProtocolService.o):(.data.rel.ro._ZTV24GExternalProtocolService[vtable for GExternalProtocolService]+0x40): undefined reference to `GExternalProtocolService::GetProtocolHandlerInfoFromOS(nsACString const&, int*, nsIHandlerInfo**)'
[13:08] <lool> ../mozilla/.libs/libmozillaembed.a(ExternalProtocolService.o):(.data.rel.ro._ZTV24GExternalProtocolService[vtable for GExternalProtocolService]+0x48): undefined reference to `GExternalProtocolService::SetProtocolHandlerDefaults(nsIHandlerInfo*, int)'
[13:08] <lool> and:
[13:08] <lool> /usr/bin/ld: galeon: hidden symbol `GExternalProtocolService::SetProtocolHandlerDefaults(nsIHandlerInfo*, int)' isn't defined
[13:13] <asac> lool: ok GetMessageMoz needs to be implemented in Wrapper
[13:14] <lool> asac: If you like, checkout latest svn and try a build
[13:17] <asac> lool: and SetProtocolHandlerDefaults needs to be implemented two as far as i can tell here
[13:26] <lool> asac: So there's no implementation I can inherit from?
[13:27] <asac> lool: http://people.ubuntu.com/~asac/miscpatches/69_get-message-moz.patch
[13:27] <asac> lool: just implement it as empty to get things going ;)
[13:28] <asac> not sure why they do it at all
[13:28] <asac> as xulrunner-gnome-support should already use gconf
[13:28] <asac> but well. step by step ;)
[13:34] <asac> lool: http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#932
[13:41] <lool> asac: Thanks, getmessagemoz fixed with the change
[13:41] <lool> asac: I didn't think of moving out of the class def
[13:42] <lool> asac: (i'm in our weekly call since 40 mns hence not too repsonsive)
[13:44] <asac> lool: http://people.ubuntu.com/~asac/miscpatches/62_libxul-embedding-unstable.patch
[13:44] <asac> try that
[13:44] <asac> and update autotools
[13:45] <lool> Trying patch debian/patches/63_mozilla-config-no-path.patch at level 1 ... 0 ... 2 ... failure.
[13:46] <asac> lool: yeah maybe a bit bit shuffeling
[13:46] <asac> the idea is to ddisable the custom protocol handler by not building it at all
[13:52] <philn> my app doesn't launch correctly from the menu, is there a way to see what's going on?
[13:53] <philn> the .desktop file is probably wrong, but i have no clue what
[13:53] <lool> philn: .xsession-errors?
[13:57] <philn> ha forgot to install the dbus service file ;)
[14:01] <lool> asac: Is that valid with "!"?
[14:02] <lool> asac: Kicking a build with external service disabled for xpcom glue
[14:03] <philn> is the .desktop OnlyShownIn supported on "normal" desktops too? should i ship an UME-specific desktop file ?
[14:03] <lool> ../mozilla/.libs/libmozillaembed.a(MozRegisterComponents.o): In function `GExternalProtocolServiceConstructor':
[14:03] <lool> /home/lool/svn/debian/pkg-galeon/unstable/build-area/galeon-2.0.5/mozilla/MozRegisterComponents.cpp:82: undefined reference to `GExternalProtocolService::GExternalProtocolService()'
[14:03] <lool> asac: almost there
[14:03] <lool> asac: Should I ifdef that out?
[14:03] <lool> NS_GENERIC_FACTORY_CONSTRUCTOR(GExternalProtocolService)
[14:04] <lool> philn: It's supported on normal desktop too, but will hide your app in desktops which aren't listed there
[14:04] <lool> philn: For instance if your desktop is Xfce or KDE and you write OnlyShowIn=GNOME;Mobile; you wont see it on your desktop
[14:04] <philn> i see :/
[14:04] <lool> philn: It's something which we are reverting for itnrepid
[14:05] <philn> ok, so i drop that stuff?
[14:05] <lool> philn: You could provide a specific desktop file to workaround this in hardy
[14:05] <lool> e.g. elisa-mobile, with the same contents as elisa.desktop plus OnlyShowIn=Mobile;
[14:06] <philn> ok
[14:06] <lool> In file included from MozRegisterComponents.cpp:30:
[14:06] <lool> ProgressListener.h:75: warning: 'GProgressListener' declared with greater visibility than the type of its field 'GProgressListener::<anonymous>'
[14:06] <lool> ProgressListener.h:75: warning: 'GProgressListener' declared with greater visibility than its base 'nsSupportsWeakReference'
[14:06] <lool> asac: if I ifdef out the NS_GENERIC_FACTORY_CONSTRUCTOR(GExternalProtocolService) ^
[14:07] <philn> can i ship both .desktop files by default? i don't think it'd hurt
[14:08] <lool> philn: Yup, that's what I meant
[14:08] <philn> ok ;)
[14:08] <lool> philn: Sorry, this is really mbf being broken here
[14:08] <lool> persia would have lots to say here :)
[14:09]  * persia is being reserved, and suggests being prepared to remove the OnlyShowIn line as soon as intrepid becomes an interesting target.
[14:09] <persia> philn: What you want to do is have one .desktop file that you ship, that is normally policy compliant.
[14:10] <lool> persia: philn needs it to work with hardy; shipping two desktop files is the best way to work in all cases I would guess
[14:10] <persia> In your build for Ubuntu Mobile Hardy, you'll need to patch it to do OnlyShowIn~GNOME;Mobile;.  I'd recommend doing this as a distro-level patch, even if you are upstream, as it will be reverted soon.
[14:11] <persia> lool: Shipping two .desktop files is harder to clean up later, but I guess that could also work.
[14:12] <philn> hmm ok, so i do as persia advises? ;)
[14:12] <lool> persia: In the case of elisa, everything is runtime
[14:12] <lool> persia: He ships the same .deb for both hildon and gnome and kde
[14:12] <lool> No rebuild whatsoever
[14:12] <lool> There's no risk that this breaks in XDG compliant desktop
[14:12] <persia> lool: Right, but it's hacked to have OnlyShowIn for Ubuntu Mobile Hardy.
[14:12] <lool> They wont show the mobile version of the desktop file
[14:12] <persia> GNOME will show both.
[14:13] <lool> However in mobile intrepid, it will break for mobiel
[14:13] <lool> persia: GNOME shouldn't show OnlyShowIn=Mobile; it does?
[14:13] <persia> lool: Does m-b-f?  I thought it required "GNOME;Mobile"
[14:13] <persia> +;
[14:13] <lool> I think it only requires Mobile!
[14:13] <lool> I do hope so
[14:13]  * persia checks
[14:14] <lool> I'm quite sure it does
[14:14] <lool> It only checks for mobile
[14:15] <lool>                                                 if (!g_ascii_strcasecmp (onlyshowin[j], "MOBILE")) {
[14:15] <lool>                                                         show_app = TRUE;
[14:15] <philn> anyway, how do i play foobillard? :D
[14:15] <lool> despite the misleading comments ;)
[14:15] <lool> philn: You shake the Q1 in the air
[14:15] <lool> If you crash it on the floor, the balls you should hear a billard sound
[14:15] <lool> Once
[14:15] <lool> Repeat with next Q1
[14:15] <philn> hehehe
[14:16] <persia> lool: Right.  It's the code comment that says "files that don't have OnlyShowIn=GNOME;Mobile".  I shouldn't trust comments :)
[14:18] <philn> ok i'll keep 2 files for now then..
[14:19] <asac> lool: so did it work (sorry, was having lunch)
[14:20] <lool> asac: Sorry, were only warnings
[14:20] <asac> k
[14:20] <lool> the actual error is MozRegisterComponents.cpp:145: error: 'GExternalProtocolServiceConstructor' was not declared in this scope
[14:21] <lool> because I didn't properly comment out everything
[14:23] <lool> asac: Woohoo
[14:23] <lool> builds
[14:23]  * asac dancing
[14:25] <lool> asac: Do I need a xulrunner-1.9 dep?
[14:26] <asac> lool: yes
[14:30] <lool> asac: Crashes when rendering sadly
[14:30] <asac> lool: bt?
[14:31] <lool> asac: Need to get dbgsym
[14:32] <asac> lool: GALEON_MOZILLA_HOME is still defined i think (as -D..HOME=\"\")
[14:32] <asac> not sure if thats the problem
[14:33] <asac> gtk_moz_embed_push_startup should go after setting the directory provider (if its used in our build)
[14:33] <lool> indeed it is
[14:34] <lool> Ah if instead of if !
[14:38] <lool> And then another patch wasn't disabling enough
[14:41] <lool> asac: AND IT WORKS
[14:41]  * lool hugs asac and squeeze him to death
[14:42] <lool> even youtube with flash and working sound
[14:43] <asac> lool: rock the boat :)
[14:44] <lool> I owe you a beer column or whatever it's called
[14:49] <lool> asac: All committed
[14:56] <philn> is that for the ume browser?
[14:56] <lool> Not at all :)
[14:56] <lool> It's for galeon, the mozilla browser which was used as the beginning of the epiphany fork
[14:56]  * philn goes back to sleep ;)
[14:57] <lool> Sad that now that galeon is dead epiphany moves to webkit
[14:57] <lool> Means we have no real alternate xul browser
[14:57] <lool> (for GNOME)
[14:57] <lool> Firefox is better at it though
[14:57] <lool> And there's kazhekase for gtk+ alternative browsing but still
[14:57] <Uraeus> lool: the firefox GNOME intergration is quite decent these days though
[14:59] <lool> Uraeus: Yup, that's what I was implying with Firefox is better at it
[14:59] <lool> Uraeus: I'm using Firefox BTW
[15:01] <lool> asac: Tempted to do evolution-rss?
[15:02] <lool> http://paste.ubuntu.com/24727/
[15:02] <lool> I would guess it misses the xul bootstrap thihng
[15:02] <lool> asac: "ember" on #ubuntu-desktop is doing it
[15:02] <lool> Well he's in #gnome-debian for that ATM
[15:10] <K3rnelP4nic> hi
[15:10] <K3rnelP4nic> persia: are u here?
[15:10] <persia> K3rnelP4nic: Yes, although I encourage you to ask questions generally: I'm unlikely to be the most knowledgeable person here on any topic.
[15:11] <K3rnelP4nic> :P
[15:12] <K3rnelP4nic> /etc/event.d/services doesnt exist
[15:12] <persia> Should it?
[15:12] <K3rnelP4nic>  I'll tell you to consider tweaking /etc/event.d/session and creating an alternate xorg.conf <- You said yesterday
[15:13] <K3rnelP4nic> about screen blinking when X sever doesnt start
[15:13] <ogra> session != services ?
[15:13] <K3rnelP4nic> :P
[15:13] <K3rnelP4nic> session too,
[15:13] <persia> It doesn't?  From where did you get your image again?
[15:13] <ogra> you can boot with init=/bin/bash as kernel parameter to get into a rootshell
[15:13] <K3rnelP4nic> http://pastebin.ca/1061332
[15:14] <K3rnelP4nic> this is from Image Creator
[15:14] <ogra> tnn the X script wont fire and you can edit stuff
[15:14] <K3rnelP4nic> v0.44
[15:14] <K3rnelP4nic> ogra: im into chroot atm
[15:14] <K3rnelP4nic> and i can access via ssh
[15:14] <ogra> right, i meant if you are stuck at a respawning device that doesnt bring up X :)
[15:14] <persia> K3rnelP4nic: Right.  I suspect you're missing some essential FSet.  I don't pretend to understand FSets, so I can't tell you which.  Hold on a bit, and I'll tell you which package to install.
[15:16] <persia> K3rnelP4nic: Hmm.  I'm not sure how X is trying to start at all if you don't have that file.  Anyway, on my machine, I'm getting it from ume-config-samsung-qa-ultra (and no, I don't have a Q1U).  You can probably get one from any of the ume-config-specific-target packages.
[15:16] <K3rnelP4nic> kk, i try it now
[15:16] <K3rnelP4nic> ty :D
[15:19] <K3rnelP4nic> lol, is a fetch problem :P
[15:19] <K3rnelP4nic> E: Couldn't find package helix-cip-codecs
[15:38] <asac> lool: cool. if you give credits to me, use the @ubuntu.com address as i contributed during ubuntu time :)
[15:39] <asac> lool: i guess evolution-rss should be far easier
[15:41] <asac> lool: will you push to debien directly?
[15:41] <asac> debian
[16:11] <lool> asac: I pushed to Debian and it's syncable to Ubuntu
[16:11] <lool> asac: I crediter you by email at the top of the new patches and in the debian/changelog; I hope that's ok
[16:13] <asac> lool: thats fine. please send this stuff upstream if possible
[16:13] <asac> i think it should still biuld with xul 1.8
[16:14] <asac> lool: and thanks for your work on this. i feel delighted now!
[16:14] <lool> asac: I ahve pointed upstream at it before the changes, and just pointed them again
[16:14] <lool> They don't want to merge the configure bits because upstream doesn't ship .pc files
[16:14] <lool> 16:50 < philipl> lool: The main problem is that mozilla.org doesn't provide any  .pc files so that's left up to each distro to handle.
[16:14] <lool> 16:50 < philipl> I can merge the core patches but the configure stuff will need  to stay a distro patch, I think.
[16:14] <lool> I'm trying to convince Philip the other way around
[16:14] <asac> lool: err. make install ships .pc files
[16:14] <asac> not sure what they mean
[16:15] <ogra> woah, the openmoko costs $399 ? 
[16:15] <ogra> geez, thats expensive 
[16:15] <lool> ogra: USD!
[16:15] <lool> USD are like roubles
[16:15] <ogra> yeah
[16:15] <ogra> well, still
[16:15] <asac> lets see. 1.9.0.0 was actually released ;)
[16:15] <ogra> my GF is off to Aldi to buy a netbook for €399
[16:16] <asac> http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.9.0.0/sdk/xulrunner-1.9.en-US.linux-i686.sdk.tar.bz2
[16:16] <lool> ogra: It's cheaper to buy your own chunk of land in the US than a parcell of the moon these days
[16:16] <ogra> with atom/1G/80G and 
[16:16] <asac> (the sdk)
[16:16] <ogra> yeah
[16:16] <ogra> but for that price you still get some small lappie or something 
[16:17] <ogra> in th eend its only a mobile phone ... 
[16:17] <lool> Folks, I need to run to the post office
[16:17] <lool> I hope I'll be back for meeting
[16:17]  * lool &
[16:20] <asac> lool: btw, i probably will not get the spec done today :(
[16:21] <asac> too much support on gecko porting (not only you) ;)
[16:21] <asac> btw, now that you are a master of standalone glue you could add #ubuntu-mozillateam to the "always connect" list ;)
[16:25] <ogra> heh
[16:57] <davidm> Almost time for the weekly meeting.
[16:58]  * GrueMaster yawns
[16:58] <GrueMaster> morning.
[16:58] <davidm> morning GrueMaster 
[17:00] <davidm> #startmeeting
[17:00] <MootBot> Meeting started at 11:01. The chair is davidm.
[17:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:00] <davidm> OK good day everyone, the meeting is started.
[17:00]  * ogra waves
[17:00] <davidm> The wiki page is: https://wiki.ubuntu.com/MobileAndEmbedded/Meeting/20080702
[17:01] <davidm> From old business I was to poke amitk for info on sysfs, which I've done and info is on the wiki page from last weeks meeting and this weeks meeting.
[17:02] <davidm> Is there more we need to do on that topic?
[17:02]  * davidm suspects not
[17:03] <ogra> we will need a way to link from a device name back to an item in the sysfs tree was the base for that question iirc
[17:03] <davidm> OK then moving on.
[17:03] <davidm> On to new business.  And I don't see any on the wiki page.
[17:04] <davidm> Does anyone have any opens?
[17:04] <persia> I've a small item.
[17:04] <davidm> persia, OK go ahead
[17:04] <persia> I'd like to request that we push this meeting to the fridge each week to get on the schedule, and consider #ubuntu-meeting as a forum.  This reduces the chance of scheduling conflicts.
[17:05] <ogra> ++
[17:05] <cgregan> +1
[17:05] <ogra> but that meas someone constantly has to care for the fridge
[17:05] <davidm> what is the fridge?
[17:05] <ogra> there is no automatism
[17:05] <ogra> fridge.ubuntu.com
[17:05] <persia> ogra: It just means one email a week to the ubuntu-news-team.
[17:06] <ogra> its building the schedule for #ubuntu-meeting
[17:06] <persia> davidm: fridge.ubuntu.com
[17:07] <ogra> it has an ical file that many users in the community use 
[17:07] <davidm> I don't have a particular preference, who can do the maintenance at fridge and can we schedule a repeating meeting?
[17:08] <persia> No such thing as scheduling a repeating meeting, but I'll send email to the fridge.  16:00 on Thursdays?
[17:08] <davidm> Indeed, until the next time change and it will likely move again.
[17:09] <persia> Just remind me at the meeting before the changed one, as I'll be manually sending this each week :)
[17:09] <GrueMaster> iirc, the reason for the time change was for Intel people to align with their schedule.
[17:09] <davidm> So is there some chance that someone could schedule a meeting over or before us in the #ubuntu-meeting?  If so that is an issue.
[17:10] <persia> There is a chance, but we can be agressive about scheduling.  Once we build a regular pattern, it's unlikely that others will collide.
[17:10] <davidm> And may be why it's always been scheduled here.
[17:10] <cgregan> The QA team manages to keep their meeting regular using the fridge.
[17:10]  * persia is in two meetings now, and wants to avoid repeats :)
[17:10] <ogra> -meeting is the channel the community is aware of fo rmeetings ...
[17:11] <ogra> we will get better commuity involvement by using it
[17:11] <ogra> and its scheduling system
[17:12] <davidm> Does this work a week at a time or can we book the next 10 meetings now?
[17:12] <persia> It generally works a week or two in advance.
[17:12] <persia> I'll book the next two after this meeting, and try to keep two weeks in advance as we go forward.
[17:13] <ogra> we did it four in advance n the past for edubunu
[17:13] <ogra> you just have to remember sending the mail at the beginning of a month :)
[17:13] <davidm> persia, I like the sound of ogra's method 4 weeks in advance.
[17:13] <ogra> which is the annoyinfg part
[17:14] <davidm> Where is the calendar on there?  Or does it not really have a claendar?
[17:14] <persia>  /events
[17:14] <ogra> not anymore
[17:14] <lool> Right, and you can subscribe to an ics I think
[17:14] <ogra> they swtched t a different cal system
[17:14] <davidm> no events there
[17:14] <ogra> rss and ical
[17:15] <persia> Bah.  I'll ping a fridge person.  Hold on...
[17:15] <ogra> you can import the ical file into evo
[17:15] <lool> I'm using the rss feed though http://fridge.ubuntu.com/atom/feed
[17:16] <K3rnelP4nic> i got this error when i prepare the image:
[17:16] <K3rnelP4nic> /usr/lib/jvm/java-6-openjdk/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
[17:16] <lool> K3rnelP4nic: We're in a middle ATM, can you ask later?
[17:16] <lool> K3rnelP4nic: Thanks!
[17:16] <ogra> in a middle :)
[17:16] <lool> *the :)
[17:17] <K3rnelP4nic> sure :D
[17:17] <davidm> persia, please schedule the next 4 meetings, and we will take the rest off-line.  My next announcement email will use #ubuntu-meeting as it's location. 
[17:18] <persia> davidm: OK.  Thanks.
[17:18] <davidm> If we collide however it's a big issue I can't move this meeting time.
[17:19] <persia> Then we'll push :)
[17:19] <ogra> the channel used to be free at this time
[17:19] <davidm> OK so this topic is complete, anything else new?
[17:19] <ogra> and the java team only has its first meeting today there atm
[17:20] <persia> ogra: it wiill be free again from next week: the current meeting is at an exceptional time.
[17:20] <davidm> If they have the time slot we will have to stay here.
[17:20] <persia> Java is likely to move to 15:00
[17:20] <davidm> OK persia please let me know off line, if we can get this slot I'm fine with it, if not we stay here.
[17:20] <persia> davidm: We'll get the slot.
[17:21] <davidm> Next....
[17:21] <cgregan> Just a notice that US employees will be offline tomorrow
[17:21] <GrueMaster> What is the new process for image updates and upgrades?
[17:21] <davidm> new process? Has it changed?
[17:22] <GrueMaster> Not sure that it was ever ironed out. 
[17:22] <GrueMaster> For example, you now have the update manager available for spot updates.  This is good for small items, but on devices with limited storage, will fill up fast.
[17:23] <lool> GrueMaster: How do you recommend people upgrade for security fixes?
[17:23] <ogra> you need to regualry roll updated images i'd guess
[17:23] <lool> GrueMaster: is there are moblin recommendation on upgrades?
[17:23] <GrueMaster> I was wondering if anyone had explored a way of doing image updates, i.e. replacing rootfs.img with an updated version.
[17:23] <ogra> that wont work 
[17:23] <GrueMaster> I don't work directly with Moblin.
[17:24] <ogra> but you could (with external resource) resquash the image on a separate disk
[17:24] <GrueMaster> And I seriously doubt anyone in that group has considered it.
[17:24] <lool> We use moblin-image-creator in hardy, and it hardcodes the partioning scheme
[17:24] <lool> *partitioning
[17:25] <lool> The fact that the /boot partition is the one containing kernels and at the same time the rootfs image is a serious issue for any upgrade scenario
[17:25] <ogra> lool, i was workig on a concept for the cmpc ... but you will in any case need a second target device to roll the iage on
[17:25] <ogra> *image
[17:25] <GrueMaster> lool:  not really
[17:25] <lool> ogra: Another option is having a special partition for that
[17:25] <GrueMaster> It actually helps simplify it without overwriting user data.
[17:25] <ogra> just roll a squashfs out of the unionfs ... then reformat the cow partition and replace the image
[17:25] <lool> GrueMaster: What are you replying to?
[17:26] <ogra> that needs to much space i bet
[17:26] <ogra> i haven any measure data though
[17:26] <lool> We discussed this at UDS
[17:26] <GrueMaster> My thought is that there are weekly (or daily) updates (I don't know if there is a set schedule).
[17:26] <lool> There are security and stable updates
[17:27] <lool> Some cycles are scheduled
[17:27] <GrueMaster> Once or twice a month, you roll out a new compressed image with the updates slipstreamed in place.  
[17:27] <lool> We will do this every six months, at Ubuntu dot releases
[17:27] <GrueMaster> The tricky part is deleting the updates from the unionfs drive w/o removing the user data.
[17:28] <lool> Yeah, that's the part I'd call "not implemented yet"
[17:28] <GrueMaster> six months is too long for a device with only 4G.
[17:28]  * ogra uses a separate /home on the cmpc for that
[17:28] <GrueMaster> And that is an upgrade, not an update.
[17:29] <GrueMaster> That's kind of where I am going.  Right now, the rootfs.img has the entire drive structure.  If /home were separated out, then replacing the contents of /dev/sda1 would be all that is needed, plus deleting the os directories on the unionfs.
[17:29] <davidm> GrueMaster, we are spinning a new image for 8.04.1 which all updates will be in the image.
[17:30] <ogra> GrueMaster, and possible changes the user made to system configs ? 
[17:30] <GrueMaster> davidm:  ok, but what do you have in place for retaining user data on mids?
[17:30] <lool> The partitioning is hardcoded in moblin-image-creator
[17:30] <lool> The partitioning doesn't create a /home and puts rootfs on /boot, which makes it hard to maintain /boot
[17:31] <davidm> GrueMaster, nothing that is currently in the USB team's area case by case for the ODM
[17:31] <lool> There are many issues with it
[17:31] <GrueMaster> User config changes would need to be either kept or reviewed through a script during update.
[17:31] <ogra> imho the only proper way is to re-roll an image from the users actual system to not destroy anything
[17:31] <lool> Moblin doesn't provide an upgrader either (that I know of)
[17:31] <ogra> hey, we can be better :)
[17:31] <ogra> but thats surely bigger than just a meeting topic for discussing it 
[17:32] <GrueMaster> I'm just trying to throw ideas out there.  My job is system integration testing and development, I.e. getting all the different bits to work together.
[17:33] <lool> GrueMaster: Your remarks are valid, I'm just pointing that this situation is the consequence of software shortcomings from MIC (IMO)
[17:33] <GrueMaster> If I get time next week, I'll try to draft a paper outlining my ideas a little better.
[17:33] <GrueMaster> lool:  I fully agree.
[17:33] <lool> I also think this should be discussed during sprints, like it was discussed at UDS
[17:33] <ogra> send it to the ML and start a thread there :)
[17:33] <lool> GrueMaster: Did you attend the Moblin sprint last weeK?
[17:33] <GrueMaster> Unfortunately, I wasn't invited to teh last one.
[17:33] <ogra> right details should be discussed at sprints
[17:34] <lool> GrueMaster: Do you know what came out of it?
[17:34] <lool> GrueMaster: To UDS?
[17:34] <GrueMaster> Nope.
[17:34] <lool> We asked every week here who would come from Intel
[17:34] <GrueMaster> I'm technically only a contract employee.  In some circles, my opinion is moot.
[17:35] <GrueMaster> Believe me, I wanted to.
[17:35] <lool> GrueMaster: Were you invited to the Moblin sprint?
[17:35] <GrueMaster> come to UDS that is.
[17:35] <GrueMaster> No I wasn't.
[17:35] <lool> GrueMaster: You should voice your wish for next UDS
[17:35] <GrueMaster> I'm not an employee, so I would have to attend on my own time at my own expense.
[17:36] <GrueMaster> But I will keep it in mind.
[17:36] <GrueMaster> I was only $500 short from the last one (est $3k).
[17:36] <GrueMaster> Butthat's a different topic.
[17:37] <cwng> Just curious, who is expected to fix MIC's shortcomings?
[17:38] <davidm> I would assume Intel
[17:39] <davidm> They are the designers of it.  We make suggestions but ....
[17:39] <lool> cwng: I would have expected MIC's upstream; as nobody on our side has commit access and some ten patches or more are pending upstream merging, it's unlikely we continue working upstream on it
[17:39] <GrueMaster> From what I was told by the owners of MIC, "It's open source, fix it yourself".
[17:39] <cwng> So, if a user could not install an Ubuntu-UME image on a 2G drive, that would be a MIC issue, thus Intel should fix it?
[17:39] <lool> Sure, we fixed annoying issues on our tree
[17:39] <GrueMaster> Personally, I don't have time to learn yet another language.
[17:40] <lool> cwng: if the tool is meant for devices where full image upgrades have to be supported and the tool doesn't support it I blame the tool
[17:40] <HappyCamp> lool: smagoun has commit access to MIC
[17:40] <GrueMaster> And anyone should be able to email patches to the maintainer (I would assume).
[17:41] <lool> I would hope attaching patches to MIC bugs in its BTS is enough
[17:42] <GrueMaster> Unfrtunately, that was tried in the ALSA bug tool.  Unless you have enough people with time to review the bug reports, you can get overwhelmed very quickly.
[17:43] <lool> Also many changes piled, and no release happens anymore
[17:45] <ogra> GrueMaster, it works quite well in launchpad ...
[17:45] <lool> If you can't get patches reviewed and merged, don't get commit access, and no new release happen, you're not tempted to contribute or help a free software project, it looks defunct from the outside
[17:45] <ogra> (else ubuntu wouldnt be what it is ;) )
[17:45] <cwng> lool:  you are still talking about MIC, right?
[17:46] <lool> I'm happy to generalize on other projects such as mbf
[17:46] <lool> but then we're getting way off topic
[17:46] <lool> I'm sorry code exchanges have grinded to an halt with moblin
[17:46] <GrueMaster> One possible problem I see, after being at Intel for ~10 years, is that priorities change like the wind.  While MIC may be a very high priority this year, next year it could easily be backed into a corner.
[17:47] <GrueMaster> Moblin is a prime example.
[17:47] <lool> So what about moblin 2?
[17:47] <davidm> OK we are way off topic here so lets move on.
[17:48] <GrueMaster> Priorities have shifted to the next generation product line, and maintaining 1.0 conflicts with that.
[17:48] <GrueMaster> agreed
[17:48]  * lool apologizes for pulling into off topicness
[17:48] <davidm> I don't want to get into a conversation around Intel's priorities, that is outside my scope.
[17:48] <GrueMaster> understood.
[17:48] <davidm> So are there other open issues or I'll bring the meeting to a close.
[17:49] <GrueMaster> I guess part of why I started this topic in the first place was to find out when the latest video drivers were going to be included.
[17:49] <lool> So shall we discuss this now?
[17:50] <davidm> lool, go for it.
[17:50] <lool> [topic] -19v2 psb drivers
[17:50] <davidm> [topic] -19v2 psb drivers
[17:50] <MootBot> New Topic:  -19v2 psb drivers 
[17:50] <lool> thanks
[17:50] <GrueMaster> Currently, 2.0.1.32L.0016 is in the PV + updates.
[17:50] <lool> So these were merged for xorg and drm last week I think; one open issue was the displayed version of drm in xorg video driver
[17:51] <lool> Now everything except kernel should have 19 as a version
[17:51] <lool> Ubuntu's libdrm carries the psb drm headers, as other drm drivers do it, and it was carrying an older version of the headers
[17:51] <lool> the interface didn't change, but the version was misleading
[17:52] <lool> So we updated the copy of the headers there and rebuilt
[17:52] <lool> Latest version of kernel driver is in the ODM build's kernel and it's merged or being merged in the Ubuntu hardy tree and will be part of next hardy-updates upload
[17:53] <lool> I've filed a SRU bug on this update, but it might not warrant an upload immediately
[17:53] <GrueMaster> From what I know of the kernel modules, the interface didn't change, but there were changes for S3/S4 states.
[17:53] <lool> Once uploaded, it will take ~10 days to migrate from hardy-proposed to hardy-updates
[17:54] <lool> (it's all I have on the topic, I'm happy to clarify any part of it)
[17:55] <davidm> Five minute warning............
[17:55] <GrueMaster> Sounds good to me.  I wish there were an easier way to drop in the whole package, but I understand it takes time to sync.
[17:55] <lool> GrueMaster: Currently, it's the same source package for all kernels in hardy
[17:55] <lool> -- i386, amd64 lpia etc.
[17:56] <GrueMaster> I know.
[17:56] <lool> So if we update only for an arch, it forces a reboot for amd64/i386
[17:56] <lool> And we have to QA iton these arches as well
[17:56] <lool> In intrepid, it will live in a separate tree
[17:57] <GrueMaster> Hopefully, the powers here that are actively developing on it can get it into the upstream kernels before Intrepid, but I'm not holding my breath.
[17:57] <lool> Certainly going via upstream would help us a lot
[17:57] <GrueMaster> It really boils down to timing.
[17:58] <davidm> OK, about to close the meeting going once...................................
[17:59] <davidm> OK, about to close the meeting going twice....................
[18:00] <davidm> #endmeeting
[18:00] <MootBot> Meeting finished at 12:01.
[18:00] <lool> cwng HappyCamp: Hey were you at the Moblin 2 sprint?  How can one track what was discussed there?  Did you invite some upstream people?
[18:00] <lool> davidm: (thanks!)
[18:00] <persia> K3rnelP4nic: You had an issue?
[18:00] <davidm> lool, welcome
[18:00] <cwng> lool: Sorry, I was not
[18:01] <lool> cwng: If it's not confidential, could you send me a list of Intel attendees that I could talk to?
[18:02] <lool> HappyCamp: You were at the Moblin 2 sprint by any chance?
[18:02] <cwng> lool: I am not invited to Moblin 2 sprint and I am currently not involve with Moblin2.  May be HappyCamp could help?
[18:02] <lool> cwng: Hmm what about midbrowser?  it's still part of moblin 2, right?
[18:03] <lool> cwng: Ah well I guess we can discuss this when there's more public information on it
[18:04] <cwng> lool: Sorry.  I think I am more clueless than you are.  
[18:04] <lool> cwng: Nah, I'm just too curious :)
[18:04] <GrueMaster> lool  there are things about moblin 2.0 that neither of us a re privy to.
[18:06] <lool> Hmm /me forgot to buy eggs &
[18:07] <GrueMaster> ?
[18:08] <lool> I forgot to buy eggs and need to go buy some quicl
[18:08] <lool> I mean for real
[18:08] <lool> I need to go shopping if I want my dinner to succeed
[18:08] <lool> bbl
[18:09] <ogra> run loola run :)
[18:09] <ogra> (sorry couldnt resist)
[18:13]  * Sciri groans
[18:21] <lool> back
[18:22] <GrueMaster> I like my eggs over easy.
[18:22] <GrueMaster> Do you have any bacon to go with them?
[18:22] <ogra> so american
[18:23] <GrueMaster> Ok, canadian bacon.
[18:23] <ogra> heh
[18:23] <GrueMaster> :P
[18:23]  * lool has salmon
[18:23] <GrueMaster> Ooo.  Good stuff.
[18:24] <ogra> yummy
[18:24] <GrueMaster> Eggs Benedict with salmon is great.
[18:24] <GrueMaster> Or a 3 egg omlette.
[18:24] <GrueMaster> I'm not picky.
[18:25] <lool> I'm eating them separately, with eggs cooked to the point where the white is solid but the yellow is liquid
[18:26] <GrueMaster> shesh.  No culinary imagination.
[18:26] <persia> lool: cooked in-shell or out of shell?
[18:26] <lool> in shell
[18:26] <lool> with bread and butter
[18:28]  * ogra prefers shell to python in that case too
[18:29] <persia> ogra: In that case, you've never had good stuffed snake.
[18:29] <ogra> no, i didnt actually
[18:30] <ogra> the most exotic i have eaten (from a german POV) was horse during student exchange in france
[18:59] <lool> ogra: horse is less popular these days
[19:00] <ogra> that was early 80s :)
[20:25] <katie> could someone tell me if Ubuntu MID edition will be able to work on my Asus eee 901?
[20:26] <katie> thank you
[20:48] <mapomapo> hi all
[20:48] <mapomapo> is there anybody who has tested ubuntu mid on an asus eeepc 701 ?
[20:49] <mapomapo> (if it's possible to do the installation)
[21:17] <GrueMaster> ﻿mapomapo:  I have heard it is possible to use the McCasslin build for the 701 with some minor changes.  The mid builds are designed for touch screen use, though.
[21:20] <mapomapo> thank you GrueMaster, now i'm enjoying myself trying to find one "ad-hoc" distro for my baby-eee :D
[22:48] <amortvigil> hey i have a samsung f770v can i put ubuntu in there?
[22:49] <amortvigil> f700v*
[22:51] <amortvigil> !mobiles
[22:51] <amortvigil> !phones
[22:51] <amortvigil> !phone
[22:51] <amortvigil> !pda
[23:40] <lool> amortvigil: Ubuntu Mobile is currently aimed at MID devices typically running Intel LPIA CPUs
[23:40] <lool> amortvigil: More details in the FAQ
[23:56] <amortvigil> lool, so no mobile phones?
[23:58] <lool> amortvigil: Well, it could be ported but that's hard work, or you could search for lpia based mofile phones
[23:59] <amortvigil> could the samsung F700 bee one? samsung wont give away proc specification...
[23:59] <amortvigil> lool,