[01:25] <johnt123456> hello
[01:25] <johnt123456> can you read me ?
[01:27] <johnt123456> daek
[01:27] <Daekdroom> ?
[01:27] <johnt123456> whoaa i am really connected :D
[01:30] <Kow> we get signal
[01:31] <johnt123456> are you an alien Kow :P
[01:32] <johnjohn1011> hello #ubuntu+1 board.  so far so good, only one reload.
[01:32] <johnt123456> hello johny buoy
[01:33] <johnjohn1011> so by alpha1, is everything compiled in gcc 4.8 or will that come later?
[09:54] <ElectricPrism1> are there any videos showing the current state of mir?
[09:54] <ElectricPrism1> I'm really excited about the new shift
[09:56] <alankila> some videos of some ex-android phone running mir and unity have been shown
[09:56] <alankila> was it by mr. bacon
[09:58] <alankila> yes, it seems. They call that dogfooding, apparently he's able to actually use it as a phone and the applications may be more than mere shims by this point of time too.
[10:14] <ElectricPrism1> alankila: cool thanks :)
[12:50] <BluesKaj> Hiyas all


[13:08] <Umeaboy> Hi!
[13:09] <Umeaboy> https://wiki.ubuntu.com/ARM/RootfsFromScratch is out of date.
[13:09] <Umeaboy> Which page should and can I use?
[13:09] <Umeaboy> For 16.04.
[18:25] <mike00> hi appdevs. can I get the time and/or the week day in a qmake app?
[18:57] <mike00> appdevs: and I want to know how can a qmake app can keep the phone always wake, without switching off the screen, please
[19:03] <c001130> Hi, I am starting developping apps for Ubuntu Touch and have a very simple question.
[19:04] <c001130> I created a new project "QML App with simple UI" and am trying to show just a simple image. But whatever I do, the image is not found when I try to run the app on my phone.
[19:06] <c001130> So, I think my question is: How to add a png file to the app?
[19:40] <Elleo> mike00: as I understand it you just need to add the keep-screen-on policy to your app armor profile, then use the ScreenSaver element to set screenSaverEnabled: false
[19:40] <Elleo> mike00: possibly best to set that as screenSaverEnabled: !Qt.application.active
[19:41] <Elleo> mike00: so that it only disables while your app is active (unlikely to make a difference on the phone, but might make a difference on less confined desktop systems)
[19:42] <Elleo> c001130: is it a qmlproject or a cmake project?
[19:43] <mike00> thanks Elleo
[19:43] <Elleo> mike00: no problem :)
[19:43] <mike00> :)
[19:44] <Elleo> mike00: also I think all the standard javascript time/date classes should be available to you for doing stuff with the time and date
[19:44] <mike00> Elleo: how can I get that values?
[19:45] <Elleo> mike00: http://www.w3schools.com/jsref/jsref_obj_date.asp
[19:46] <mike00> thanks very much Elleo, I'll try as soon as possible ;)
[19:46] <Elleo> you're welcome
[19:47] <c001130> Elleo: I tried both. When I try it with "QML App with Simple UI (qmake)", I can "Add existing files" to my project tree but they are not transfered to the device apparently.
[19:47] <c001130> When I try it with "QML App with Simple UI (cmake)",  I can not even "Add existing files".
[19:48] <c001130> Would I require a resource file?
[19:48] <c001130> I remember that I wrote an App some months ago and didn't have these problems.
[19:49] <Elleo> c001130: I think you just need to add them as part of the project tree, if you're using "Add existing files" I think it'll use a relative to path to wherever they currently exist on the system (which won't be included in the click package)
[19:49] <Elleo> so if you copy them in manually you should be okay
[19:50] <Elleo> (outside of qtcreator)
[19:50] <mike00> c001130: in a qmake project you have to add the file path to the .pro file
[19:50] <Elleo> ah, yeah sorry I was thinking of a qmlproject not a qmake project
[19:51] <mike00> c001130: when the file says "CONF_FILES += " and a list of about 2 files. you have to add there your files
[20:07] <c001130> mike00: I'll try! Give me a sec!"
[20:07] <mike00> ok
[20:14] <c001130> mike00: It worked. You helped me a lot! Just one detail: Should I use the CONF_FILES list or should I take another list for my images?
[20:15] <mike00> I put all my file under CONF_FILES and my app works
[20:15] <mike00> I'm not an expert
[20:18] <c001130> Okay, I do it the same way then. For me you're expert enough. ;-)
[20:23] <mike00> well, I have your same problem until few days ago: I've just discovered this


[00:00] <qwebirc50725> My setup has a ASUS Xonar DG card connected to my NVIDIA GeForce 9400 card for HDMI output.
[00:00] <qwebirc50725> Everything was working in both the myth frontend and in other apps (chromium). I was also able to play sample sound files using aplay. Now, nothing works.
[00:02] <qwebirc50725> Prior to the update, my /etc/asound.conf file had one line: "pcm.!default "plughw:0,1""
[00:03] <qwebirc50725> I tried removing that, rebooting, and testing again. No dice. I've also been through all of the devices listed by aplay -L, trying, for example: aplay /usr/share/sounds/alsa/Noise.wav -vv -D plughw:0,1
[00:05] <Shadow__X> qwebirc50725: did you make sure its not muted in alsa mixer
[00:07] <qwebirc50725> Ahh, yes, Shadow, I did. Of course, I'm not sure what I'm supposed to un-mute (SPDIF?), but all are unmuted.
[00:08] <Shadow__X> you could plug something into the audio ports to see if its just going to the wrong port
[00:09] <qwebirc50725> Yes, I did not do that.
[00:11] <Shadow__X> also if you are using multiple audio things disable then to decrease complexity
[00:11] <qwebirc50725> Multiple audio things?
[00:12] <Shadow__X> audio cards, isnt the asus xonar dg an audio card
[00:13] <qwebirc50725> Oh, yes. I guess there would be a motherboard audio, too...
[00:13] <Shadow__X> you have to keep th at in mind
[00:13] <Shadow__X> when testing
[00:13] <qwebirc50725> Right, well, in alsamixer, I see only one card--the xonar dg.
[00:14] <Shadow__X> you can switch to different ones iirc
[00:15] <qwebirc50725> Right, F6, but it only listed the one.
[00:15] <qwebirc50725> So there is no audio coming out any port (I have speaker-test running).
[00:17] <qwebirc50725> Ahh, but if I use -Dsurround51:CARD=DG,DEV=0, I *can* hear audio on the analog ports of the Xonar card.
[00:17] <qwebirc50725> So the card seems to be working, at least partially.
[00:25] <qwebirc50725> But I still can't get sound to come via the hdmi ports, as it was before 2 this afternoon. Ugh.
[00:25] <qwebirc50725> This is why I hate linux updates and used to almost never apply them.
[15:39] <qwebirc50725> Hey! Does anyone know if there are any X11 conf files that relate to HDMI audio?


[14:45] <smoser> mnaser, mgagne a couple things:
[14:47] <smoser> a.) kernel resize of online disk is orders of magnitude faster with newer kernels . that got magically fast ~ 3.5 i think.
[14:47] <smoser> b.) backgrounding the resize ends up not being all that useful on the older kernels.  It should background, but it is extremely IO intensive and halts most other things.   it should work correclty, but everything will be slow.
[14:48] <mnaser> smoser: i notied that, also it doesnt seem like it background cloud-init .. if nothing else in cloud-init is setup to run, it won't really be backgrounded
[14:50] <smoser> it shoudl bacground
[14:51] <smoser> mnaser, is the call to util.fork_cb just broken ?
[14:52] <smoser> it looks right
[14:52] <mnaser> smoser: so what was happening is that it was saying "Backgrounding resize" but it was still blocking
[14:53] <smoser> hm.. i really doubt its broken.
[14:53] <mnaser> and the proof to that even more is that the "part" that does resizing would say "took 180 seonds" let's say and it was blocked there
[14:53] <smoser> hm..
[14:53] <mnaser> but this is cloud-init of CentOS 6
[14:53] <mnaser> so maybe that's not been tested
[14:53] <mnaser> also i recall
[14:53] <smoser> i dont know what is in centos 6. i'm just looking at trunk
[14:53] <smoser> but it *is* crazy io intensive
[14:53] <mnaser> there was an error
[14:53] <smoser> and so is boot
[14:53] <smoser> so originally when i did this, i found it to be almost useless.
[14:53] <mnaser> with the callback being a NoneType or something
[14:54] <smoser> hm..
[14:54] <smoser> let me look at that again
[14:55] <mnaser> also this is 10x ssd drives in raid-10 so it's pretty fast
[14:56] <smoser> you're right
[14:56] <smoser> its busted
[14:56] <mnaser> smoser: Jul  7 12:34:20 localhost [CLOUDINIT] util.py[DEBUG]: backgrounded Resizing took 41.487 seconds
[14:56] <mnaser> Jul  7 12:34:20 localhost [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'init' took 41.799 seconds (41.80)
[14:56] <mnaser> and then it continues afterwards
[14:56] <smoser> :-(
[14:56] <smoser> and i broke it when i added the util.log_
[14:56] <smoser> open a bug ?
[14:56] <mnaser> perhaps
[14:56] <mnaser> sure
[15:01] <mnaser> smoser: https://bugs.launchpad.net/cloud-init/+bug/1338614
[15:06] <smoser> mnaser, try: http://paste.ubuntu.com/7760542/ ?
[15:06] <smoser> are you able to easily try that ?
[15:06] <mnaser> hm
[15:07] <mnaser> i think i can spin up a new vm with cloud config disabling resize
[15:07] <mnaser> then patch it and run the module manually
[15:07] <mnaser> i assume if i run it manually it should background as well
[15:08] <mnaser> heck, let me try to patch one that is already running because it's failing to fork resizefs anyways
[15:10] <smoser> it should work, yea.
[15:10] <smoser> mnaser, thank you.
[15:11] <mnaser> smoser: fyi in the cc_resizefs.py file
[15:11] <mnaser> 'args': (resize_cmd, log)) should be 'args': (resize_cmd, log)}
[15:12] <smoser> yeah
[15:12] <mnaser> doesnt give that warning anymore... now to test if it's actually properly backgrounding will take a bit longer
[15:12] <mnaser> but let me do it, solving this will be very usefu
[15:14] <smoser> mnaser, it was calling fork_cb completely wrong.
[15:14] <smoser> so i'm trying to just fix how it calls it, by adding a fork_cb_kwargs and calling that one, and making fork_cb backwards compat and call the fork_cb_kwargs.
[15:14] <smoser> my concern is that fork_cb might not be completley backwards compat
[15:16] <mnaser> and maybe other parts thats rely on it might be broken now
[15:16] <mnaser> right so just made a new vm that was not resized automatically
[15:17] <mnaser> now i'll do the patch for it, delete all the cloud init stuff, reboot and *hopefully* it'll background
[15:17] <mnaser> or should i just run it manually in the shell after patching and it'll be okay, smoser ?
[15:18] <smoser> rm -Rf /var/lib/cloud
[15:18] <smoser> and reboot
[15:18] <smoser> and see
[15:18] <smoser> that'll be more complete at least
[15:19] <smoser> there is only one other caller though
[15:19] <smoser> so i could just patch it too
[15:19] <mnaser> alright so its patched up now
[15:19] <mnaser> rebooting
[15:20] <mnaser> its only going to do a resize from 20gb to 40gb but i think it'll still show
[15:21] <mnaser> oh, it didnt do the resize again beacuse it read the user data (configdrive) and that says not too
[15:21] <mnaser> hm
[15:22] <smoser> ah. rihgt.
[15:22] <smoser> and you can't easily override that.
[15:22] <mnaser> Jul  7 15:22:03 resize-test [CLOUDINIT] cc_resizefs.py[DEBUG]: Skipping module named resizefs, resizing disabled
[15:22] <mnaser> even if i force it to run
[15:23] <mnaser> from the shell
[15:23] <smoser> well if you tell it to run it still reads config
[15:23] <mnaser> i guess what ill do is
[15:23] <mnaser> take a snapshot of this server
[15:23] <mnaser> and boot another one
[15:24] <smoser> mnaser, just put 'resize_root = NOBLOCK'
[15:24] <smoser> right before that
[15:24] <smoser> ie, force it on
[15:24] <smoser> actually..
[15:24] <mnaser> before where exactly?
[15:24] <smoser> if you run it manually you *should* be able to pass it in
[15:24] <mnaser> cloud-init --debug single -n resizefs
[15:24] <mnaser> this didnt run it manually
[15:25] <smoser> cloud-init --debug single -n resizefs noblock
[15:25] <smoser> try that
[15:25] <mnaser> i'll take a snapshot and boot from it a much larger machien so we have a feel of what it's like
[15:25] <mnaser> so if anything else is disturbing, we'll see it
[15:26] <smoser> mnaser, it is crazy slow.
[15:26] <smoser> i have done resize on spinning disk from 2G to 2TB
[15:26] <mnaser> oh ill make 20G to 80G resize
[15:26] <smoser> and it took > 1 our i think
[15:26] <mnaser> yeah i know that pain :P
[15:26] <smoser> 1 hour
[15:26] <mnaser> ssd, 20G to 1.2TB was 10 minutes
[15:26] <mnaser> still al ot
[15:26] <smoser> yeah.
[15:26] <smoser> and it is crazy magic fast in 3.5
[15:26] <smoser> its 1000x faster
[15:27] <mnaser> oh well, centos :-(
[15:27] <smoser> yeah
[15:27] <mnaser> alright, got snapshot, booting it now
[15:34] <mnaser> smoser
[15:34] <mnaser> Jul  7 15:31:57 resize-test [CLOUDINIT] util.py[WARNING]: Failed forking and calling callback log_time
[15:34] <mnaser> Jul  7 15:31:57 resize-test [CLOUDINIT] util.py[DEBUG]: Failed forking and calling callback log_time#012Traceback (most recent call last):#012  File "/usr/lib/python2.6/site-packages/cloudinit/util.py", line 224, in fork_cb_kwargs#012    child_cb(*args, **kwargs)#012TypeError: log_time() argument after * must be a sequence, not NoneType
[15:37] <smoser> boo.
[15:38] <smoser> mnaser, http://paste.ubuntu.com/7760686/
[15:38] <smoser> try that
[15:38] <smoser> and i apologize
[15:38] <smoser> i wondered about that
[15:38] <mnaser> no worries
[15:38] <mnaser> now i can easily rename and reboot :p
[15:40] <mnaser> btw smoser
[15:41] <mnaser> backgrounded Resizing = Backgrounded resizing
[15:41] <mnaser> cannot imagine how much that bothered me in logs :-P
[15:41] <smoser> ?
[15:42] <smoser> oh. i see. capitalize :)
[15:42] <mnaser> yes :p
[15:42] <smoser> well, the 'R' makes sense.
[15:42] <smoser> sort of
[15:42] <smoser> in my world
[15:42] <smoser> as the 'Resizing' in the non-backgrounded path.
[15:42] <mnaser> smoser: really silly
[15:42] <mnaser> but
[15:42] <smoser> (so grepping for 'Resizing' would get either)
[15:42] <mnaser> why not just do this
[15:42] <mnaser> def fork_cb_kwargs(child_cb, args=[], kwargs={}):
[15:46] <smoser> mnaser, generally, http://satyajit.ranjeev.in/2012/01/12/python--dangerous-default-value-as-argument.html
[15:47] <mnaser> aah
[15:47] <mnaser> that's good to know
[15:47] <smoser> https://docs.python.org/2/tutorial/controlflow.html#default-argument-values
[15:47] <mnaser> rebooting
[15:47] <smoser> see the 'important warning' there
[15:48] <mnaser> always learning something new
[15:49] <mnaser> Jul  7 15:48:46 resize-test2 [CLOUDINIT] util.py[WARNING]: Failed forking and calling callback log_time
[15:49] <mnaser> Jul  7 15:48:46 resize-test2 [CLOUDINIT] util.py[DEBUG]: Failed forking and calling callback log_time#012Traceback (most recent call last):#012  File "/usr/lib/python2.6/site-packages/cloudinit/util.py", line 229, in fork_cb_kwargs#012    child_cb(*args, **kwargs)#012  File "/usr/lib/python2.6/site-packages/cloudinit/util.py", line 1830, in log_time#012    ret = func(*args, **kwargs)#012TypeError: 'str' object is not callable
[15:49] <mnaser> smoser ^
[15:49] <mnaser> tho
[15:49] <mnaser> i think i should ahv esaid this earlier
[15:50] <mnaser> running cloud-init 0.7.4 not trunk
[15:50] <mnaser> so maybe this has to do with it
[16:01] <smoser> mnaser, i'll stop bothering you and i'll just make sure it works on trunk before asking again.
[16:01] <smoser> k?
[16:34] <mnaser> smoser: no problem, thank you so much :)
[19:04] <harlowja> smoser u might want to respond to http://lists.openstack.org/pipermail/openstack-dev/2014-July/039514.html :)
[19:04] <harlowja> see last line ;)
[19:11] <cloudnoob> harlowja: I emailed you about cloud-init-dev over the weekend?
[19:11] <cloudnoob> I will paste my email into irc :)
[19:11] <harlowja> cloudnoob howdy
[19:12] <cloudnoob> It looks like the default configuration of cloud-init on Ubuntu 12.04 LTS causes a new RSA key & fingerprint to be generated when an existing (root) EBS volume is attached to a new instance[1]. I'd like to avoid this behavior on some of my instances.  After some poking around, I think removing 'ssh' from cloud_init_modules list in /etc/cloud/cloud.cfg will prevent this from happening[2]. Can a cloud-init-dev@'er confirm this is t
[19:12] <cloudnoob> oh hmmm
[19:12] <cloudnoob> looks like I hit a limit
[19:12] <cloudnoob> 1/ It looks like the default configuration of cloud-init on Ubuntu 12.04 LTS causes a new RSA key & fingerprint to be generated when an existing (root) EBS volume is attached to a new instance
[19:12] <harlowja> that would seem fine to do
[19:12] <cloudnoob> 2/  I'd like to avoid this behavior on some of my instances.
[19:12] <harlowja> take ssh module out
[19:12] <cloudnoob> 3/ After some poking around, I think removing 'ssh' from cloud_init_modules list in /etc/cloud/cloud.cfg will prevent this from happening
[19:12] <cloudnoob> 4/ Can a cloud-init-dev@'er confirm this is the case, and that this is a safe/secure thing to do for existing systems which have already been through once-per-instance setup? I'm also open to advice or suggestions on better approaches.
[19:13] <cloudnoob> see http://serverfault.com/questions/294039/rsa-fingerprint-changed-after-moving-ebs-and-eip-to-new-instance for a similar writeup
[19:13] <cloudnoob> also my understanding is based on the assumption that 'ssh' in this list corresponds to executing the handler defined in 'cc_ssh.py'.
[19:13] <harlowja> cloudnoob i think u can also place ssh_genkeytypes: [] in userdata
[19:13] <harlowja> to avoid it doing any extra key creation
[19:14] <cloudnoob> ok
[19:14] <harlowja> or adjust it in /etc/cloud/cloud.cfg
[19:14] <cloudnoob> is that better than removing from cloud_init_modules?
[19:15] <harlowja> disabling ssh makes it impossible for any user keys to come in, if they ever want
[19:15] <harlowja> i think u are hitting http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/config/cc_ssh.py#L91 which the ssh_genkeytypes: [] should just stop
[19:15] <cloudnoob> ah
[19:15] <harlowja> aka, no more generation, but if people provide them that code path will work
[19:15] <cloudnoob> okay cool
[19:15] <cloudnoob> I'll try it
[19:16] <cloudnoob> there are existing keys so yeah, just don't want to overwrite them
[19:16] <cloudnoob> thanks for the suggestions
[19:16] <harlowja> np
[19:16] <cloudnoob> and thanks for the software of course
[19:16] <cloudnoob> teh useful
[19:16] <harlowja> np
[19:17] <harlowja> thx for using it :-P
[19:29] <smoser> harlowja, thanks for the heads up. responded
[19:29] <harlowja> smoser cool
[19:30] <harlowja> i'm not touching that question ;)
[19:30] <harlowja> u can, haha
[19:36] <harlowja> *not the ipv6 question, the lets get rid of metadata service
[19:39] <harmw> can't we just ditch ip6?
[19:39] <harmw> far easier
[19:39] <harmw> everything just works with ip4
[19:39] <harmw> lets keep it that way
[19:44] <ijw> yo
[19:45] <ijw> Since I'm here, I wanted to ask: has anyone thought about a generic format for network information (rather than the /etc/network/interfaces file that Openstack likes to template, badly, and then inject)?
[19:52] <harlowja> ijw yes
[19:52] <ijw> How much thinking so far?
[19:53] <harlowja> ijw http://bazaar.launchpad.net/~harlowja/cloud-init/better-todo/view/head:/TODO.rst (this is updated with this, although its been thought of for a long time, ha)
[19:53] <harlowja> smoser u should merge that branch :)
[19:53] <ijw>   I have an MTU problem that is really not going to fit in with the current mechanisms
[19:53] <harlowja> ijw i don't think its cloud-init that would have the biggest problem with changing, its the other things that write the format :)
[19:53] <ijw> Win7 doesn't advertise for MTU on DHCP, and Linux has Opinions on how big the MTU can be
[19:54] <harlowja> ijw https://fedorahosted.org/netcf/ has been discussed (although its xml, eck, haha)
[19:55] <ijw> Given that the in-page example is a bridge it's more complex than we strictly need anyway
[19:55] <harlowja> sure
[19:55] <ijw> (also, you can't specify data by eth0/1/2 since they're assigned by the OS)
[19:55] <harlowja> ijw the issue is that other surronding projects need to get away from writing this format also, this imho is the harder part :)
[19:55] <harlowja> *neutron/nova in openstack
[19:56] <harlowja> ijw ideally someone really needs to own that format change and push it through the various openstack projects
[19:56] <harlowja> the cloud-init work i don't think would be that much
[19:57] <harlowja> *at least to do the basics
[19:57] <smoser> harlowja, we have a fail safe datasource.
[19:57] <smoser> ijw, yeah, mtu sucks.
[19:57] <harlowja> smoser damn gotta change that in the todo, no longer a todo then, ha
[19:58] <smoser> ijw, from my perspective, it needs to be specified by the "provider" in one way or another.
[19:58] <ijw> It's not even a format change - it's an additional file on the web server or config drive that could happily be ignored by anything that didn't know about it
[19:58] <smoser> dhcp is reasonable for dhcp . but ideally it'd be available if not dhcp.
[19:58] <harlowja> ijw sure, just write "network.xml" (or something)
[19:58] <ijw> And I think if it had interface, optionally with VLAN/v4(s)/v6(es)/mtu that would be sufficient
[19:58] <smoser> this advertising needs to be more part of the network imo
[19:59] <harlowja> and cloud-init will use it if it exists (or if not look for the old way)
[19:59] <smoser> but maybe not.
[19:59] <smoser> it is very problematic
[19:59] <smoser> and we're hitting it here too.
[20:00] <ijw> smoser: DHCP in either the v4 or v6 forms has various issues advertising MTU.  The client needs to know, and v6's spec is written with a pedantic respect to the fact that ethernet doesn't standardise packet sizes >1500 bytes (so making bigger MTUs is hard)
[20:01] <ijw> Assuming YAML wouldn't make people cry, the spec could be very straightforward, in fact
[20:01]  * ijw finds an etherpad
[20:02] <harlowja> :), bb, meeting
[20:02] <smoser> it just seems really odd that this isn't sovled
[20:03] <smoser> harlowja, merged. dont say i never did anything for you :)
[22:08] <harlowja> smoser woot :-P
[23:06] <ijw> By sheer coincidence someone's just talked to be about bonding, too...


[12:45] <shinmen> Why are some of the sources unavailable? (e.g. gnomevfs2, procps) I've been getting them on dapper sparc and on breezy (sparc and i386).
[12:46] <fabbione> shinmen: the sources are only in one place
[12:46] <fabbione> they are not replicated to ports.ubuntu.com
[12:46] <fabbione> only to archive
[12:46] <fabbione> on ports we expose only the binaries
[12:47] <fabbione> and i am pretty sure they are all there
[12:50] <shinmen> Hmm. Found it. I'm getting dumber every day.
[12:55] <shinmen> fabbione, thanks.
[01:12] <fabbione> shinmen: no problem :)
[01:39] <shinmen> I'm already afraid to ask... I might have a faulty installation. But does anyone else get a segfault using pgrep?
[01:40] <shinmen> I recomplied procps and not it works.
[05:10] <shinmen> BTW, I tried to start X by hand, then a terminal, and in the terminal I start metacity, gnome-settings-daemon, gnome-panel and nautilus, and the problem that happened before, that some of the gnome daemons cucked up all of the CPU, doesn't happen any  more.
[05:11] <shinmen> I don't know mutch about gnome... I've only been using it since I moved to ubuntu, so I don't know if I'm missing any daemons, of if there's a proper way to start gnome, but know I know that the problem is not in the daemons in the packages... it's something else. At least know I have a workarroud for it.
[05:55] <fabbione> hmmm
[05:55] <fabbione> you should try to start via gdm
[05:55] <fabbione> and see if it happens again
[06:38] <shinmen> Yeap.. I just can't debug it right know...  But I'll try to ASAP.
[06:40] <fabbione> ehe no problem