[02:47] <manakfula> Hello everyone, I have a couple quick questions about edubuntu
[02:47] <manakfula> I'm familiar with ubuntu so it's nothing really technical
[02:48] <manakfula> and I apologize if I get disconnected, my wireless sucks...I'll be back if that happens
[02:49] <manakfula> does edubuntu come with a spanish distribution or spanish language option at the time of installation?
[02:49] <manakfula> (im not sure if that whole message went through or not I only see part of it)
[02:50] <manakfula> I'll retype it incase it didn't...does it come with a spanish disto or installation option?
[02:51] <manakfula> or just the spanish learning/tutor program?
[02:55] <Manakfula> sorry about that told you my wireless sucks
[02:55] <Manakfula> so is anyone here or is the room just idle?
[11:20] <davew> Am trying to use the profile editor in 9.04 but there is a bug in it. Actually this is one feature that I need as I am using LTSP with 30 clients. Anyone got any ideas
[11:21] <alkisg> davew: sbalneav is trying to fix the bugs and hopes it'll be ready for 9.10. There's a new version at his PPA that works for some people.
[11:22] <davew> Have tried the sbalneav fix and it didn't work for me - are you saying it doesn't work for everybody ?
[11:23] <alkisg> Yup. I don't know the last ubuntu version that sabayon worked in, maybe it was back in gutsy or something...
[11:23] <alkisg> davew: what exactly do you want to lock with sabayon? Maybe there are ways to do it with gconf...
[11:24] <davew> Oh dear I'm in trouble. Without this I don't know what I can do !!!
[11:25] <davew> Do you know when 9.10 which I presume is the next version is out ?
[11:26] <alkisg> 9 = 2009, 10 = 10th month = october
[11:28] <davew> Understood - I am in trouble ! I understand that Sabayon has not worked for about 12 months, is that true ?
[11:29] <alkisg> Well, I bet it's working right now for people that have older ubuntu versions...
[11:30] <alkisg> But yeah, I don't think it has worked in the recent ubuntu releases
[11:32] <davew> O.K. Thanks for that I will have to strip out 9.04 and put in something older or another distro which has similar features. Thanks for your help I have been trying to get some information for several days. Cheers .
[11:32] <alkisg> davew: but again, it may be possible to lock down your desktop for your clients with gconf-editor
[11:33] <davew> Will this allow me to do it globally  for say a particular group ?
[11:34] <alkisg> Hmmm kind of. Global locking is global, not per group. But you could copy the settings on all members of a group.
[11:35] <davew> O.K.  I'll have a look - thanks again .
[11:35] <alkisg> Bye
[16:54] <mss> hello ... I have been facing the hardy release DHCP issue seen by others such as :
[16:54] <mss> https://lists.ubuntu.com/archives/edubuntu-users/2008-December/004911.html
[16:54] <mss> above
[16:54] <mss> Today I captured some logs from my system, turning on one client at a time ...and logs show how slow things get ..
[16:55] <mss> where can I upload so experts can take a look ?
[16:56] <mss> I have captured daemon and kern logs among others
[18:05] <mss> hi alkisg
[18:06] <alkisg> Hello mss, hi all
[18:06] <mss> we spoke a few days ago about the hardy DHCP problem :
[18:06] <mss> https://lists.ubuntu.com/archives/edubuntu-users/2008-December/004911.html
[18:06] <mss> I have daemon, kern and other logs showing the problem
[18:07] <mss> I booted clients one at a time ....the first two boot fast .. the next few start slowing down ...
[18:08] <alkisg> mss, it seems like your case is a dhcp server problem, but then again, I'm not sure, e.g. "slowing down"? Aquiring a dhcp lease should only take some msec...
[18:09] <mss> yes .. I understand that ....but it has now been seen by several folks that this DHCP "slowing down" problem exists ...
[18:09] <mss> in some cases ....
[18:10] <alkisg> Any links for bug reports?
[18:11] <alkisg> mss: an easy thing to try would be another dhcp server, e.g. dnsmasq
[18:11] <alkisg> This way you would be sure if it is or not a dhcp3-server - related problem
[18:13] <mss> I could try that ..but am not clear on exactly how to set up a different dhcp server ... other folks who have moved to a different dhcp server, fould it works fine .
[18:13] <alkisg> mss: also, try to post in #ltsp-discuss, you may have additional chances for an answer there...
[18:13] <mss> https://lists.ubuntu.com/archives/edubuntu-users/2008-December/004914.html
[18:14] <mss> looks like nobody has filed a bug yet ...
[18:14] <alkisg> "We figured that as the box got busy serving up the tftp kernels the dhcp would start to fail/timeout." I haven't heard of anyone having this problem, though...
[18:15] <alkisg> You may try dnsmasq like this:
[18:15] <alkisg> sudo invoke-rc.d dhcp3-server stop
[18:15] <alkisg> sudo apt-get install dnsmasq
[18:15] <alkisg> create an /etc/dnsmasq.d/ltsp.conf file with:
[18:16] <alkisg> port=0 # this makes dnsmasq *not* function as a dns server
[18:16] <alkisg> dhcp-range=<IP_ADDRESS>,<IP_ADDRESS>,8h  # change with your specific range
[18:16] <alkisg> sudo invoke-rc.d dnsmasq restart
[18:16] <mss> The logs I captured show exactly htis problem .
[18:16] <alkisg> [18:17] <mss> thanks .. I will try dnsmasq like you sugested ..
[18:17] <alkisg> mss: do you have a small log part that shows that the server gets a dhcp_discover, and doesn't answer with a dhcp_offer?
[18:18] <alkisg> If so, you should definately file a bug against dhcp3-server...
[18:18] <mss> yes ...I have the logs ... it answers .. but very slowly .. let me pul it up for you ...
[18:20] <mss> here's the first client .
[18:20] <mss> Aug  9 12:48:54 coco dhcpd: DHCPDISCOVER from 00:1e:0b:39:fa:d1 via eth1
[18:20] <mss> Aug  9 12:48:55 coco dhcpd: DHCPOFFER on <IP_ADDRESS> to 00:1e:0b:39:fa:d1 via eth1
[18:20] <mss> Aug  9 12:48:57 coco dhcpd: DHCPREQUEST for <IP_ADDRESS> (<IP_ADDRESS>) from 00:1e:0b:39:fa:d1 via eth1
[18:20] <mss> Aug  9 12:48:57 coco dhcpd: DHCPACK on <IP_ADDRESS> to 00:1e:0b:39:fa:d1 via eth1
[18:21] <alkisg> The client needed 2 seconds to process the offer and request it? !!!
[18:21] <mss> here's the next client by which time things start to slow down
[18:21] <mss> Aug  9 13:02:44 coco dhcpd: DHCPDISCOVER from 00:1e:0b:39:fa:ef via eth1
[18:21] <mss> Aug  9 13:03:09 coco dhcpd: DHCPOFFER on <IP_ADDRESS> to 00:1e:0b:39:fa:ef via eth1
[18:21] <mss> Aug  9 13:03:34 coco dhcpd: DHCPREQUEST for <IP_ADDRESS> (<IP_ADDRESS>) from 00:1e:0b:39:fa:ef via eth1
[18:21] <mss> Aug  9 13:03:59 coco dhcpd: DHCPACK on <IP_ADDRESS> to 00:1e:0b:39:fa:ef via eth1
[18:22] <alkisg> Yeah that *doesn't* look like a dhcp problem to me, but a network problem
[18:22] <alkisg> If it was a server problem, the client wouldn't need (34-09) seconds to process the offer and send a request
[18:23] <mss> the strange thing is ....even before the DHCPDISCOVER shows up in the log ... I can see the client has already acquired the address and on its way ..
[18:23] <mss> but the DHCPACK shows up much later in the log ..
[18:24] <alkisg> There are 2 dhcp requests for each client, did you know that?
[18:24] <alkisg> One during the pxe boot, and one later *after* the kernel boots
[18:24] <mss> yes .... I showed only the first of each client
[18:25] <alkisg> Ah... well then I still don't see this as a dhcp server problem
[18:25] <alkisg> If a client is booted and you try to operate it when other clients boot, does it function correctly, or is it very very slow?
[18:25] <alkisg> E.g. having both full duplex and half duplex clients on the same switch can bring down the network speed to a crawl...
[18:26] <mss> well....the first three- four clients boot....
[18:26] <mss> then the rest do not get any response  in time before the client times out ..
[18:27] <mss> all clients are identical .. hp5135s
[18:27] <alkisg> ok, but during this "clients do not get any response" phase, if you try to sit down on a client a work on it, does it work fine, or is it slow? If it were slow, this would suggest a network problem...
[18:28] <mss> the clients that are up seem to work fine ....
[18:28] <alkisg> Can you upload a full log file somewhere?
[18:28] <mss> yes ..have all the logs
[18:29] <mss> can I email ... only 400k
[18:29] <alkisg> OK... my nickname at gmail dot com
[18:30] <alkisg> also, what NICs do the clients have?
[18:35] <mss> clients ? no idea, but I know other have been using these clients fine ....
[18:36] <alkisg> With the same distro?
[18:36] <alkisg> (and version)?
[18:36] <mss> sent email - it is a zip file of all logs
[18:36] <mss> yes ...
[18:37] <mss> I believe Asmo Koskinen asmo.koskinen at arkki.info  is using them ..
[18:37] <mss> saw him mention in one of his posts
[18:37] <mss> 8.04.10 .. last updated 12 days ago with all current (at that time ) updates
[18:38] <mss> client has 128 MB ram ... shoud that be an issue ?
[18:39] <alkisg> No
[18:40] <alkisg> ...but even with the first client, there are problems: http://alkisg.pastebin.com/d2b2bbb97
[18:40] <alkisg> Even though the client gets a dhcp_ack, it requests the same IP again
[18:40] <mss> I thought that was the kernel
[18:40] <alkisg> There are 3 acks tehre
[18:41] <alkisg> 1 = pxe, 2 = kernel, 3 = problem
[18:41] <mss> every client does this twice ....
[18:49] <mss> but there are only 2 DISC/OFFER s
[18:49] <mss> you are saying the last pair of lines REQUEST/ACK is a problem ?
[18:50] <alkisg> I'm saying that it seems to ignore the "12:49:16 coco dhcpd: DHCPACK"
[18:50] <alkisg> So, if it doesn't get the first ack, it seems like a network problem exists even with 1 client
[18:52] <mss> or if the dhcp server is slow and it gets two reqs one after the other ... is it possible it is responding to both ?
[18:53] <alkisg> Hmmmm though I had send a patch last year for ipconfig that had to do with DHCPNAKs, maybe it didn't make it for 8.04 and that bug is still there
[18:54] <alkisg> http://www.zytor.com/pipermail/klibc/2008-June/002311.html
[19:02] <mss> it says your patch was applied :-)
[19:02] <alkisg> Yeah I know, but I don't know if it make it for hardy
[19:02] <alkisg> I think it's only fixed in 8.10 and 9.04...
[19:02] <mss> thought it should have at least made it to 8.04.10
[19:03] <alkisg> But anyway mss I don't think that ipconfig is your main problem here
[19:04] <alkisg> I mean, in the second client dhcp takes dozens of seconds!!!
[19:04] <mss> I will try the dnsmasq and see how it goes ... I have the ltsp setup at a remote location ( no internet) .. so I can take the dnsmasq.deb file and install .. correct ?
[19:04] <mss> yes ... and then it gets wors ....
[19:04] <alkisg> I think you'll need 2 debs, dnsmasq.deb and dnsmasq-base.deb
[19:04] <alkisg> But do try this:
[19:05] <alkisg> 1. Boot 4-5 clients (as many as they boot)
[19:05] <alkisg> 2. Try to work on one of them. Does it work ok?
[19:05] <mss> but when I left the system alone for a few hours and came back and booted a client .. the first one again came up fast and fine ... then the second one slowed .. and the process repeated ...
[19:05] <alkisg> Ah
[19:05] <mss> it is in the logs ...
[19:06] <alkisg> 3. After a while, open another client and see if it boots fast <== you just answered that
[19:06] <mss> after 14:xx . I came back at 17:xx
[19:06] <alkisg> You don't even have dhcpd.conf in the logs, though...
[19:06] <mss> in the logs
[19:06] <alkisg> Nor /etc/network/interfaceds
[19:07] <mss> dhcpd conf standard as edubuntu requires .. done during installation .. nothing special
[19:07] <mss> attached ifconfig .. if it helps
[19:07] <alkisg> I wonder if it's a tftp problem, i.e. the whole network slows down when the clients get the kernel via tftp
[19:08] <mss> possible ... could you take a loo at kern logs ... it just keeps going on for a client log after the login screen is presented on the clinet ..is that a problem ?
[19:09] <mss> but each client should take no more than 10 secs to get the image
[19:09] <mss> on a FE LAN
[19:10] <alkisg> Yeah, unless there's a problem :) (which is the only thing certain here :))
[19:10] <alkisg> I've seen tftp needing half an hour to server a kernel in problematic cases...
[19:11] <alkisg> *serve
[19:11] <mss> :-)
[19:11] <mss> if the PHY is messed up and retransmissions happen .. I guess it can happen
[19:11] <alkisg> How difficult would it be to try out 9.04? E.g. in a different partition?
[19:12] <alkisg> The installation takes < 30 mins...
[19:12] <mss> I am trying to set up a different system in a couple of days .. I can try 9.04 on that
[19:12] <mss> is it a LTS release ?
[19:13] <alkisg> No, but it was released a year later than 8.04, so they'll be supported for about the same time (only 6 months difference)
[19:14] <mss> so .. I will try both the dnsmasq and the 9.04 and let you know in a day or two ...
[19:15] <mss> thanks for your help
[19:15] <alkisg> mss, ps:
[19:15] <alkisg>  /usr/share/doc/ltsp-server/examples/dhcpd-dnsmasq <== example file for dnsmasq config
[19:15]  * alkisg gotta go... bye all
[19:16] <mss> thanks


 @ahoneybun, I don't want to do a booth if I'll be the only one there.
 Of course.
[01:48] <valorie> I've done a table by myself and it is not very much fun
[01:49] <valorie> and actually not that effective


[05:33] <hikiko> hi
[05:40] <duflu> Morning hikiko
[05:41] <hikiko> hi duflu
[05:57] <TheMuso> Hey hikiko.
[05:58] <hikiko> hi TheMuso
[06:32] <FJKong> hi all
[06:55] <allison[m]> good morning
[07:08] <allison[m]> pindrop
[07:09] <flocculant> :)
[07:57] <sil2100> seb128: hey! Who's the langpack work going? I see some zesty-specific langpacks in the archive, so I guess it's all good? :)
[08:01] <robert_ancell> allison[m], do you know much about g_main_context_iteration?
[08:14] <allison[m]> a bit, yes :)
[08:17] <robert_ancell> allison[m], I use this in snapd-glib to do the sync calls, but for some reason it never returns when you using it in a thread.
[08:18] <robert_ancell> I can confirm the callback (a socket read) occurs, but g_main_context_iteration never exits so the sync call never completes even through it now has the result.
[08:19] <allison[m]> wait wat?
[08:19] <jbicha> good morning
[08:19] <allison[m]> i'm not sure what the problem is, but i'm pretty sure you're "doing it wrong" :)
[08:19] <allison[m]> first, you should never call that function from a thread, unless it's on a mainloop that you created directly for the purpose of that thread
[08:20] <robert_ancell> allison[m], I expected you'd say that, so I'm hoping you can tell me how to do it rigght
[08:20] <allison[m]> second, mainloops should not interact with sync calls at all, except through thread-emulation of async calls...
[08:20] <allison[m]> robert_ancell: can you back up a bit and tell me what you're trying to do first, then?
[08:22] <robert_ancell> allison[m], in snapd-glib you have a socket you send requests on / get responses. I have a bunch of methods that do sync and async calls on it.  But that stops other callbacks you might have
[08:25] <seb128> hey allison[m] robert_ancell sil2100
[08:25] <robert_ancell> seb128, hi
[08:26] <seb128> robert_ancell, staying late!
[08:26] <robert_ancell> seb128, wanted to check if any info regarding Canonical and I needed some allison[m] help
[08:26] <seb128> k
[08:26] <allison[m]> robert_ancell: API looks fine
[08:27] <robert_ancell> allison[m], yeah, I figured the API should survive a refactor behind the scenes to "do it right" (TM)
[08:27] <allison[m]> robert_ancell: so basically you will end up doing async socket calls inside of those async calls of your own
[08:28] <allison[m]> spin up a GTask in the _async start function, pass it in as the user_data to the subcall and from your own finish handler, use g_task_return()...
[08:28] <allison[m]> just one async call inside of another... no threads, etc.
[08:29] <robert_ancell> allison[m], aha, I was confused by GTask only having the _run_in_thread methods. I didn't consider you don't need them at all
[08:29] <allison[m]> they're useful if you need to emulate the operation in a thread...
[08:29] <robert_ancell> allison[m], yeah
[08:30] <allison[m]> but if you can chain other async ops (which is the correct thing to do in this case) then it's not necessary
[08:30] <robert_ancell> allison[m], so do I have to implement sync equivalents? There's some code I was hoping to de-duplicate
[08:30] <allison[m]> if your operation ends up being really complicated with a lot of talking back and forth then you might consider it
[08:30] <Laney> hello
[08:30] <Laney> !!!
[08:30] <allison[m]> since implementing a 5-step handshake in async all the way is ... not awesome (unless you take the vala approach)
[08:30] <allison[m]> so sometimes people just punt over to sync land in that case
[08:30] <sil2100> Hi!
[08:31] <allison[m]> robert_ancell: so there is a "trick" for implementing sync versions of async calls
[08:31] <robert_ancell> it will be less readable than what I've got, but not out of control
[08:31] <allison[m]> (1) create new mail context
[08:31] <allison[m]> (2) set it as the thread local default
[08:31] <allison[m]> (3) do the async call
[08:31] <allison[m]> (4) iterate your new loop until the result handler comes
[08:31] <allison[m]> (5) tear it all down again
[08:31] <allison[m]> this is how GDBus does its sync calls
[08:31] <robert_ancell> allison[m], right, so that's sort of what I had (I think I copied it from somewhere). But that didn't work in the threads (in gnome-software)
[08:32] <allison[m]> if you set the thread-default maincontext correctly, iterate the new context, and use GTask properly then it should "just work"
[08:32] <allison[m]> unless there is something in your async chain that pings back to the global default mainloop
[08:32] <allison[m]> (ie: something that is implemented incorrectly)
[08:33] <robert_ancell> allison[m], thanks, I'll try some refactoring tomorrow
[08:58] <sil2100> seb128: just remember - if you need any help with the langpacks, give me a sign
[08:58] <sil2100> I guess it's still in progress as I don't see zesty in the crontab for l-o-m
[08:59] <sil2100> btw. did we get the zesty potemplate stats in the end from dpm?
[08:59] <sil2100> (or how those were generated)
[09:03] <andyrock> morning all
[09:08] <seb128> sil2100, hey, sorry I was in an hangout earlier, do you need anything particular with langpacks?
[09:09] <seb128> sil2100, I did an update to zesty a week ago and I'm going to do another one now
[09:09] <seb128> sil2100, I didn't sort out the stats job yet, feel free to look at that if you want, for now I workarounded and use the xenial stats on zesty
[09:09] <sil2100> seb128: excellent, we're just going through the list of things for the release
[09:10] <sil2100> seb128: ok, will do
[09:10] <seb128> thanks
[09:10] <seb128> you are in London?
[09:10] <sil2100> Yes
[09:24] <b4n> Trevinho: hi!  regarding a11y shortcuts in Compiz: I've got roughly 1 week left at my job to work on that, and we'd love to get this to work by then.  What do you think would be the best approach to go ahead on that?  Also, could you give some hand/guidance on it?  Porting InputMonitor to Compiz was what we discussed last time, and although I'm not at all familiar enough with it yet to be sure on how it'd be used to solve the plugin
[09:25] <Trevinho> b4n: mh, I guess it could be done yeah... the thing is that compiz is in final freeze now, so we can't merge things
[09:25] <Trevinho> I can do that once A opens though
[09:25] <b4n> when would that be?
[09:25] <Trevinho> b4n: however, yeah.... Trying to have that input monitor at compiz level would be nice, I can try to have a look on that too
[09:25] <b4n> that would be awesome :)
[09:26] <Trevinho> b4n: release is in 3 days, so.... after that
[09:26] <b4n> OK.  anything I could work on to get ahead of it?
[09:27] <b4n> I guess you'd have more ease to port the module as you probably already know it fairly well, but if there's anything I could do would be nice
[09:28] <b4n> for example, maybe you have an idea how the monitor could be used to get actions triggered, like how i'd integrate
[09:29] <b4n> I could possibly research/test on that (not sure how easy that'd be without actually having the monitor in Compiz, but maybe)
[09:31] <Trevinho> b4n: speaking of the events... Is there a reson why you used raw events instead of normal one?
[09:31] <Trevinho> I think you wrote that, but...
[09:32] <b4n> Trevinho: yeah, the reason was primarily not to block Core events
[09:32] <b4n> and I need to re-check (I did too many tests…), but I think some grabs also blocked XI2 non-raw events
[09:33] <duflu> Trevinho: Nice sunset? ;)
[09:33] <Trevinho> duflu: yeah, it was awesome
[09:34] <Laney> hey seb128 duflu allison[m] & Trevinho
[09:34] <Trevinho> hey Laney
[09:34] <duflu> Moring Laney
[09:34] <duflu> Morning even
[09:34] <Laney> how's it going?
[09:34] <happyaron> hey guys
[09:34] <seb128> Hey Laney, in London now?
[09:34] <Laney> yep
[09:35] <Laney> hey happyaron
[09:35] <seb128> had a good w.e and easy trip?
[09:35] <Laney> seb128: was suuuuuuuuuuuuuuuuper sunny yesterday
[09:35] <seb128> hey happyaron
[09:35] <Laney> yeah
[09:35] <Laney> just 1 train, is easy
[09:35] <seb128> same here
[09:35] <seb128> and it was a tennis day
[09:35] <seb128> that was grrrrrreat
[09:35] <Laney> \o/
[09:35] <Laney> i did some walking around London
[09:36] <Laney> had a juice that cost £6.50
[09:36] <Laney> what a magical place
[09:36] <Trevinho> Laney: I might have a neko++ version, is that too late? :-)
[09:36] <Laney> yes
[09:36] <Laney> sorry
[09:36] <seb128> I hope it was good for this price!
[09:36] <Trevinho> ok... fair enough... Sure, I knew it.
[09:36] <Laney> it was okay
[09:37] <seb128> Trevinho can get food and drinks for a day for the price of that juice
[09:37] <duflu> And a massage
[09:37] <Trevinho> Yeah, thta0s sure
[09:37] <Trevinho> yesterday's massage was awesome though
[09:40] <b4n> Trevinho: anyway, the main reason was I didn't wanted to have *all* actions ignore grabs, so I didn't want to forward *all* XI2 events as Core ones anyway
[09:40] <b4n> for example I didn't want window sicther to work when locked or alike
[09:40] <b4n> switcher*
[09:41] <Trevinho> b4n: sure, we can do tha too with the input manager
[09:41] <Trevinho> like enabling callbacks only if a such kind of customer is there
[09:42] <b4n> hum… yeah but the actions of e.g. the ezoom plugin should always work (e.g. ignore grabs)
[09:42] <b4n> and the plugin will be loaded all day long
[09:42] <b4n> yet it shouldn't affect how the other plugin work
[09:42] <b4n> and I'm not sure how we would do that with the event forwarding technique
[09:43] <b4n> unless tracking Core grabs and conditionally forwarding ourselves?
[09:57] <willcooke> DashView.cpp line 1438: <3
[09:58] <b4n> Trevinho: BTW, I didn't test yet but the conflicts andyrock saw are possibly due to multiple XGetEventData() calls and the awful semantics of the return value of that function (e.g. no way to collaboratively use it from 2 sources)
[09:59] <Laney> ssssssshhhhhhhhhhhhhhhh
[10:01] <Laney> https://www.youtube.com/watch?v=EHNL8iSh4pM
[10:02] <willcooke> :)
[10:04] <ogra_> hmm ... so i looked at ubuntu gnome 17.04 on the weekend ... and noticed that there is a gdm session idling after login that eats about 600MB ram ...
[10:04] <ogra_> do we plan to keep lightdm ?
[10:04] <Laney> #ubuntu-gnome
[10:04] <ogra_> Laney, well, that was more with a view on 18.04
[10:05] <Laney> ok, well it's extremely early for that kind of decision
[10:05] <Laney> unknown :(
[10:05] <Laney> but there will certainly be bugs to fix
[10:05] <ogra_> 600MB for just doing nothing are quite hilarious
[10:07] <jbicha> ogra_: did you install from the latest daily?
[10:07] <ogra_> jbicha, yeah
[10:07] <jbicha> gnome-shell probably has several memory leaks :(
[10:07] <ogra_> in a kvm vm ... 4GB ram, 10GB disk
[10:08] <ogra_> jbicha, well, these 600M come from summing up RSS of all gdm owned processes in the ps output ... there is a gazillion settings-daemon bits each eating around 15-20MB ... it simply sums up
[10:10] <jbicha> https://bugzilla.gnome.org/780555
[10:11] <Laney> gdm's used for screen locking in shell afaik
[10:11] <ogra_> jbicha, well ... that affects everything ... but ... my point is that you essentially duplicating the complete session
[10:11] <jbicha> ogra_: you could file a gdm bug to request that it not run as many g-s-d plugins
[10:11] <Laney> so I think that it's likely to (1) be used, and (2) need to have a session open
[10:12] <Laney> (ICBW though)
[10:12] <flexiondotorg> Morning desktopers
[10:12] <ogra_> right after boot my desktop eats 1.1G ... 600 of that are gdm, the others are the user session
[10:12] <jbicha> ogra_: yes, gdm needs to keep running; that's part of how it's designed
[10:12] <darkxst> hey desktopers
[10:13] <darkxst> ogra_, are you using NVIDIA proprietry drivers?
[10:13] <ogra_> jbicha, right, but it could perhaps unload quite some bits if only handling locking, dunno
[10:13] <ogra_> darkxst, in that VM ? no
[10:13] <ogra_> (outside of it i do :) )
[10:13] <jbicha> it also handles login on vt1
[10:13] <GunnarHj> seb128: Hi Seb, are you about to upload fresh zesty langpacks?
[10:14] <chrisccoulson> ogra_, what we need is a display server that isn't so over-engineered. We're doing a full circle here ;)
[10:14] <ogra_> jbicha, well, perhaps a reduces session and less gsd plugins might make some sense there :)
[10:14] <chrisccoulson> server -> manager
[10:14] <darkxst> ogra_, so one of the problems with the NVIDIA drivers is they end up putting their texture caches in the main process
[10:14] <ogra_> *reduced
[10:15] <darkxst> that makes it look bad, but is not a real issue
[10:15] <darkxst> that obviously shouldnt transfer across to a VM though
[10:15] <ogra_> darkxst, well, my point isnt the amount of ram but rather the fact that the ram use is permanently duplicated for something that mostly idles
[10:16] <jbicha> in 3.24 g-s-d was split up into separate plugins which hopefully will make some things better in the future
[10:16] <ogra_> half of the used ram is used for gdm ... the sessions that run seem to be close to identical and i higly doubt thats required to just provide a login window and screen locking
[10:16] <ogra_> anyway ... just an observation :)
[10:17] <darkxst> jbicha,  that has nothing to do with the NVIDIA stuff
[10:18] <darkxst> ogra_, but on NVIDIA its not a true reading of memory use since it includes caches that are on the GPU RAM
[10:20] <ogra_> darkxst, sure ... but even if gdm would only consume 100MB of a 200MB session i would find it weird ... it is the duplication of two running sessions, while only one is necessary that i dont like ... it makes the overall ram use (and thus the minimal reqs.) massively higher for no valid reason (IMHO)
[10:20] <darkxst> in a VM or say intel drivers it should never get anywhere near 600MB
[10:31] <darkxst> ogra_, there are valid reasons to keep gdm running, security is one
[10:31] <Laney> darkxst: ??????????????????????????????????????????????????????????????????????????????????????????????
[10:32] <ogra_> darkxst, welll, why does it need to run a full gnome-session to show a password box and fullscreen picture :)
[10:32] <ogra_> (yes, i'm aware you want a11y and such but that doesn really not require a full gnome-shell session)
[10:33] <darkxst> hey Laney!
[10:33] <ogra_> especially regarding security that just adds additional attach vecrots
[10:33] <Laney> hey
[10:33] <Laney> how's it going?
[10:33] <ogra_> *vectors
[10:33] <darkxst> Laney, still in the mountains, stuggling with internets, but getting ADSL soon
[10:34] <Laney> do you have a massive zen beard?
[10:35] <darkxst> beard yes, massive zen beard probably not
[10:35] <Laney> :)
[10:36] <TheMuso> c
[10:36] <TheMuso> whoops wrong window
[10:36]  * TheMuso waves hello anyway.
[10:36] <darkxst> hey TheMuso
[10:36] <TheMuso> Hey darkxst.
[10:38] <darkxst> ogra_, all authentication is handled by gdm, including drawing the lock/login screens
[10:38] <ogra_> darkxst, yes ... but why does it noeed to run its own gnome-shell for that ?
[10:38] <ogra_> *need
[10:39] <darkxst> I'm not 100% sure on the reasons for the full session, but it was related to wayland
[10:39] <ogra_> all it does is show a login box on a fullscreen picture
[10:39] <tjaalton> is there a way to avoid the annoying swipe on lock screen?
[10:40] <darkxst> it is not a full gnome-shell session
[10:40] <ogra_> so it could ship with a super minimal shell instead that does exactly that ... pls a few gsd plugins for things like a11y and kdb etc
[10:40] <darkxst> it is a majorly cut back gnome-shell session
[10:40] <jbicha> tjaalton: you don't need to swipe, just start entering your password
[10:41] <ogra_> well, it uses the same amount of ram the user session uses ... (independent of how much that ram is, it isnt lees than the normal session ... thats my point)
[10:41] <tjaalton> jbicha: ah, ok
[10:42] <tjaalton> jbicha: yep, works
[10:44] <jbicha> ogra_: my gdm3/zesty says it's using 1M memory, 292MB virtual mem, 7.4 MB resident mem, 6.4 MB shared mem
[10:44] <ogra_> jbicha, your gdm or all processes the gdm user owns ?
[10:45] <jbicha> I don't know, I opened System Monitor, right-clicked on gdm3 and selected Properties
[10:45] <ogra_> right
[10:45] <ogra_> ps aux| grep ^gdm ...
[10:45] <jbicha> you can also click the hamburger menu in System Monitor to see Dependencies
[10:47] <jbicha> and All Processes
[10:49] <jbicha> I don't know much about memory but isn't resident memory a better measure of what we should be looking at?
[10:54] <ogra_> yes
[10:56] <ogra_> http://paste.ubuntu.com/24353954/
[10:56] <ogra_> that sums up the RES field from ps
[10:58] <jbicha> ok
[11:12] <tjaalton> the system monitor and ps show different results for memory consumption.. SM shows just 3,4MiB for gsd-xsettings for instance, ps shows ~20
[11:14] <tjaalton> ah, most of it is shared
[11:17] <tjaalton> ogra_: so you're result includes shared memory too ;)
[11:17] <tjaalton> your
[11:17] <tjaalton> bah
[11:35] <seb128> Laney, seems fair to me to have GNOME/ubuntu-desktop here no? (/me is not on #ubuntu-gnome and not interested to move things to another channel if they impact us)
[11:36] <Laney> seb128: It doesn't impact Ubuntu atm
[11:37] <Laney> Once it does, that's fine
[11:37] <Laney> I don't really care though so whatever
[11:38] <seb128> right, I guess it makes sense for us to start being aware of things that might need some looking at
[11:38] <seb128> but yeah no big deal either way
[11:39] <Laney> can haz langpacks please?
[11:39] <Laney> to get on topic :-)
[11:39] <seb128> yeah, I was going to reply to GunnarHj about that
[11:39] <Laney> thx!
[11:39] <seb128> yw
[11:39] <Laney> we're trying to get 'everything' (that we know about) in today
[11:40] <seb128> I started the job but it takes a bit of time
[11:40] <seb128> hope to have them in about an hour
[11:40] <Laney> cool
[11:41] <GunnarHj> seb128: Great!
[11:41] <jbicha> Firefox :(
[11:41] <seb128> what's the issue with firefox?
[11:41] <Laney> armhf build failure
[11:41] <seb128> oh
[11:46] <Laney> I guess it'll just be able to go into security after though
[11:46] <Laney> or maybe before
[12:22] <ximion> Laney: D's reference compiler is fully open source now<EMAIL_ADDRESS>[12:22] <ximion> all it took was Red Hat to accelerate the process
[12:24] <ximion> I'll run some tests later to see whether dmd makes asgen slower or whather the speed difference is small (probably the latter, since a lot of performance-sensitive code is in C anyway)
[12:24] <ximion> (using dmd reduces the frequency with which I encounter compiler bugs dramatically at least :P)
[12:30] <Laney> ximion: nice
[12:30] <Laney> does it have a different stdlib implementation?
[12:30] <Laney> i thought ldc was alright
[12:31] <ximion> LDC and GDC both use a stdlib fork from dmd, so yes, we have another stdlib version :P
[12:32] <ximion> LDC is fine, but I am still hitting compiler bugs, including gems like https://github.com/ldc-developers/ldc/issues/2022 , while the reference compiler doesn't have those. Also, Red Hat told me they will use dmd
[12:33] <ximion> and I am currently thinking about what to do for Debian so we don't end up with something as bad as the OCaml or Haskell world :P
[12:33] <ximion> (which isn't bad per-se, but rather maintenance-intensive)
[12:33] <ximion> I asked the D guys for advice on the issues<EMAIL_ADDRESS>[12:34] <ximion> the outcome could be that we will just stick with LDC as the best option and only use dmd occasionally
[12:36] <ximion> Laney: but from the looks of it it appears like Red Hat / GNOME is really giving D a shot as GNOME platform language, which is rather nice
[12:37] <ximion> at least a better choice than the "JavaScript is the language you shall write new GNOME apps in" :P
[12:37] <ximion> *idea from a few years ago
[12:53] <qengho> 'Sup.
[13:09] <Laney> ximion: what are they using it for?
[13:09] <ximion> Laney: at time as something to recommend for newcomers besides C in case Vala doesn't cut it
[13:10] <Laney> does it have good bindings?
[13:10] <ximion> jup - the GTK+ D bindings are superb
[13:10] <ximion> (from a developer's viewpoint at least)
[13:12] <ximion> initially I thought that this was just some random exploration, but it looks like some serious work was invested into getting Fedora & Co. support D nicely - with LDC at time, but soon with DMD, as far as I was told
[13:32] <tsdgeos> was a pleasure working for Canonical! /me waves
[13:33] <Laney> :/
[13:35] <Laney> ximion: sounds like libraries in D is painful though
[13:35] <Laney> from your thread
[13:39] <ximion> Laney: it's far better than Haskell and OCaml, but not as nice as C or C++
[13:40] <ximion> D fascinates me in that it always manages to do something really awesome and then screws it up with some stupid papercut
[13:43] <ximion> (e.g. the JSON interface in the standard library sucks, but the language itself is capable of doing Python-esque neat serialization from raw structs (https://dlang.org/phobos/std_json.html vs. http://vibed.org/api/vibe.data.json/))
[17:16] <willcooke> I'm going to start drinking.  o/
[17:16] <seb128> goo
[17:16] <seb128> doh, he did a didrocks again
[17:16] <ogra_> seems to be in fashion recently
[17:17] <didrocks> but but, it's copyrighted
[17:17] <seb128> Laney, sil2100, GunnarHj, langpacks base refresh uploaded
[17:17] <Laney> you little beauty
[17:17] <sil2100> seb128: wooo hooo!
[17:17]  * sil2100 hugs seb128
[17:17] <seb128> :-)
[17:18] <seb128> they are still making they way to the queue so wait a few minutes
[17:18] <seb128> on that note I'm off to prepare diner, enjoy the evening desktopers
[17:19] <kenvandine> good night seb128
[17:19] <seb128> night


[04:59] <Leviticus> !ops | nooo waaaa
[05:22] <goodwill> eh?
[05:30] <rww> just a troll.
[06:51] <gr33n-ion> hello
[07:03] <Noskcaj> hey gr33n-ion
[07:16] <gr33n-ion> sup :D
[12:05] <bluesabre> quick question... does pushing to an ubuntu branch result in an upload as well?
[12:05] <bluesabre> always been unclear about that
[14:57] <hjd> cjwatson: Hello again. I saw that you synced cl-fad yesterday, would you mind doing the same for cl-interpol? (Would probably resolve the ftbfs issue for pgloader) :)
[17:21] <cjwatson> hjd: I'll sort it out tomorrow.  Requires a fakesync so didn't get caught in my initial pass.
[17:21] <cjwatson> (.orig has changed from the contents that the Ubuntu archive remembers from an earlier incarnation)
[17:31] <teward> is there a list of packages which are automatically synced for vivid?
[17:33] <tumbleweed> teward: all packages, except the ones that are blacklisted
[17:33] <teward> tumbleweed: do you have a list of blacklisted packages, somewhere?
[17:33] <tumbleweed> http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[17:35] <teward> tumbleweed: OK, one last question - we have a modified package here in Ubuntu, nginx, which has one built binary which is in Main.  A sync would really need to be a merge, so how does the auto sync interpret that?
[17:35] <teward> does it just sync and its up to the devs to just reapply the changes that're needed to be kept, or does that need a manual merge
[17:36] <tumbleweed> packages are only synced when they aren't modified in ubuntu
[17:36] <tumbleweed> merges are done by hand
[17:36] <teward> so I'd ahve to request a merge... figures.
[17:37] <tumbleweed> usually the last person to touch it does the merge, because they know what changes they made
[17:38] <cjwatson> If you want to look at the full logic, it's in the auto-sync script in lp:ubuntu-archive-tools
[17:40] <teward> tumbleweed: right, well, in theory, the last person to touch it was me, but if you want to be really anal about it, the last person to touch the package was mdeslaur
[17:40] <teward> because marc just sponsored a last-minute change for the nginx package.
[17:40] <teward> (which was to somewhat-mitigate POODLE)
[17:40] <teward> so should I be poking mdeslaur to do the merge?
[17:41] <tumbleweed> no, you're the one on the hook, not him :)
[17:42] <teward> tumbleweed: insomuchthat marc has upload rights and I don't.
[17:42] <teward> any merge I do has to be sponsored.
[17:43] <teward> guess i should dig up my 'how to effectively merge' guide
[17:44] <tumbleweed> yep
[17:49] <hjd> cjwatson: ok. Thanks.
[18:26] <teward> tumbleweed: any kind of guidance on how to perform a merge?
[19:14] <teward> if i have followed http://packaging.ubuntu.com/html/udd-merging.html for creating a merge for a package, where should I push the resulting modifications to?  What is the pattern I should use for uploading this to launchpad?  (I'm used to the traditional debdiff methods :/)
[19:15] <tumbleweed> teward: you read https://wiki.ubuntu.com/UbuntuDevelopment/Merging ?
[19:15] <tumbleweed> ah, you read the udd docs
[19:15] <teward> tumbleweed: MOM failed
[19:15] <teward> that's why i went the UDD route
[19:15] <tumbleweed> yes, you can push a branch and propose a merge, but those can be hard to review
[19:15] <tumbleweed> still that's the reviewer's problem, not yours
[19:16] <teward> tumbleweed: could I perhaps just do bzr builddeb, then gen a debdiff?
[19:16] <teward> upload said debdiff to launchpad when i create a merge request bug?
[19:16] <tumbleweed> failed?
[19:16] <teward> tumbleweed: E:CouldNotFindDSC
[19:16] <tumbleweed> yes you can
[19:17] <tumbleweed> it all looks like it's there. I don't know where you saw that error. https://merges.ubuntu.com/n/nginx/
[19:17]  * teward shrugs
[19:17] <teward> i should use the automated reports, either way xD
[19:17]  * teward yawns
[19:17] <teward> urgh, i need more coffee
[19:18] <teward> tumbleweed: ultimately the same report was shown from the bzr/UDD method
[19:18] <tumbleweed> :P
[19:18] <teward> namely that the debian/ files had those same conflicts
[19:18] <teward> which i resolved
[19:21] <teward> tumbleweed: who do I bother for a cursory review of the debdiff, as this is the first time I've gone the UDD route for creating a merge
[19:21] <teward> shoudl i go bug mdeslaur who merged it before?
[19:22] <tumbleweed> if you propose a merge, it'll appear in the sponsoring overview
[19:45] <teward> tumbleweed: thanks.  QUestion: how often does the sponsorship queue page get updated
[19:59] <tumbleweed> sorry, I can't remember
[21:45] <ari-tczew> Laney: I'd like to take a merge on shotwell, you're the last uploader. I hope you're not angry :-)
[21:47] <Laney> ari-tczew: go for it, happy to review also
[21:48] <ari-tczew> Laney: ok, I'll subscribe/mark you as reviewer! :-)