=== gerald is now known as Guest46504
[08:20] <ppisati_> the sun is shining, wake up!
[08:24] <smb> ppisati_, Its struggling, so do we :-P
[08:51] <apw> ppisati_, it is shining here too, what gives?
[08:51] <apw> moin
=== soren_ is now known as soren
=== ogra_` is now known as ogra
[10:30] <brendand> cking, do you know which document specifies the length of different fields in DMI?
[10:30] <brendand> sorry if i repeated myself, i think i dropped offline
[10:33] <cking> brendand, somewhere on http://www.dmtf.org/standards/dmi, let me see..
[10:35] <cking> http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf
[10:36] <cking> it's a relatively easy spec, only 137 odd pages
[10:37] <cking> brendand, some fields such as strings are NULL terminated
[10:40] <brendand> cking, so for SKU number the length is BYTE and the type is STRING
[10:41] <brendand> cking, does that mean the maximum length is 256?
[10:41] <cking> lemme look it up in the spec first
[10:42] <cking> brendand, nope, the byte size is an index into a table that contains null terminated strings
[10:43] <brendand> cking, so there is no real limit on the length
[10:43] <cking> brendand, let me read that bit up in the spec..
[10:45] <cking> brendand, section 6.1.3 tells you about strings, the real limit is the Structure Table Length field of the SMBIOS Structure Table Entry Point
[10:45] <cking> so the actual limit is 64K
[10:45] <cking> -1 byte
[10:46] <cking> ish
[10:53] <brendand> cking, just a quick question - in that document SKU Number is said to be there since version 2.4 of the spec
[10:54] <brendand> cking, but the latest version i see on the site is 2.0.1
[10:54] <cking> http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf
[10:55] <cking> that's version 2.8.0
=== Trevinho__ is now known as Trevinho
=== smoser` is now known as smoser
=== josepht_ is now known as josepht
[13:54] <rtg> apw, you mentioned an overlayfs patch for the lxc dudes yesterday. how is that coming ?
[13:57] <apw> rtg, i have a good working one, i am just about to boot and test a possibly simpler one
[13:57] <rtg> apw, ack
[15:10] <apw> hallyn, i have spun a much simpler patch for the overlayfs things, which i would love you to test as well, if that is good i will submit both upstream as options: http://people.canonical.com/~apw/overlayfs-perms3-trusty/
[15:11] <apw> someone else can decide if going all nuclear is ok
[15:18] <hallyn> apw: ok, building a vm to test
[15:34] <apw> hallyn, great
[15:34] <hallyn> apw: workign well.  now i'm going to do a release-upgrade inside an unprivileged clone;
[15:40] <apw> great
[15:46] <hallyn> that worked too, excellent
[15:49] <rtg> sforshee, upload new firmware bits to trusty. https://bugs.launchpad.net/intel/+bug/1265436/comments/13
[15:49] <ubot2`> Launchpad bug 1265436 in intel "Update firmware for 7260 / 3160 devices (Wilkins Peak)" [Undecided,New]
[15:49] <rtg> uploaded*
[15:51] <sforshee> rtg: ack, I just tried out the new 3160 firmware yesterday
[15:51] <Fokkeeerrr> hi
[16:09] <xnox> what is the minimum i386 cpu/machine specs our generic kernel support?
[16:09] <xnox> is sse/pentium4 required?
[16:51] <apw> i have mentally stored pentium4 + sse as the minimum, it was really a minimum at the libc level i think
[16:55] <apw> slangasek, ^^ i think you were there when we made that decision in oh precise or something
[16:57] <slangasek> apw: the libc6 minimum is still i686
[16:57] <slangasek> SSE is definitely not required on i386 userspace
[17:12] <apw> see people with memories ftw
[17:25] <apw> hallyn, i take it you are happy :)
[17:27] <hallyn> apw: yup :)
=== tyhicks` is now known as tyhicks
[17:47] <apw> hallyn, ok i have shoved the decision upstream, but for now i assume you need something, so i would propose applying the second one.  but i'll let you read
[17:47] <hallyn> read on lkml you mean?  i looked at the patch, looked good
[17:48] <apw> hallyn, well i was more asking if you has a preference between yesterdays and todays
[17:48] <apw> ie the one that looked like yours, and this shorter one
[17:51] <apw> hallyn, and remind me do we ahve bug associated with this i shoudl be quoting?
[17:59] <hallyn> apw: i think the one from today is better.
[18:00] <hallyn> apw: no i guess there is no open bug
[18:01] <apw> hallyn, ack and ack; i'll push todays and change it if things change upstream; i expect it'll be quiet
[19:40] <cristian_c> Hi
[19:40] <Prf_Jakob> rtg: Thanks for including the patches.
[19:41] <rtg> vmware ? no problem.
[19:41] <cristian_c> a long time ago, I reported a bug in launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
[19:41] <ubot2`> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged]
[19:41] <Prf_Jakob> rtg: yeah :)
[19:42] <cristian_c> in recent times there have been regressions too
[19:42] <cristian_c> it needs bisect
[19:43] <rtg> cristian_c, jsalisbury can likely help with that
[19:54] <cristian_c> rtg, ok
[19:55] <cristian_c> the doubt is about the request
[19:55] <cristian_c> does it refer to regressions or original bug?
[19:59] <apw> cristian_c, to know if the led color issue is fixed one would need the functioanlity to work
[20:04] <cristian_c> apw, some releases have been suggested
[20:04] <cristian_c> but they are very old kernel
[20:05] <apw> cristian_c, well he is tyring to bracket when the issue appeared
[20:05] <cristian_c> regressions are appeared only from December onwards
[20:05] <cristian_c> *kernels
[20:06] <cristian_c> 'wrote on 2013-12-31:	 #21 I've tested the 3.13.0-031300rc5 kernel and I noticed this bug getting worse compared to the previous kernels. Exactly, the switch between wifi on and off is very slow and the LED does not change color by pressing the button before or after performing the workaround.'
[20:06] <jsalisbury> cristian_c, I requested the older kernels due to the Bug description.  It suggested the regression started in 11.10, is that not correct?
[20:07] <cristian_c> apw, before then, the regressions did not exist
[20:07] <cristian_c> jsalisbury, ok
[20:07] <cristian_c> then original bug, not regressions
[20:07] <cristian_c> :)
[20:07] <cristian_c> thanks
[20:08] <cristian_c> I've always found that bug since I have got that pc
[20:08] <jsalisbury> cristian_c, Yeah, the kernel tested in comment #21 was a release candidate for the 3.13 kernel.  If the new issue that happenes with that kernel still happens with the latest 3.13 kernel in Trusty, then we should open a new, seperate bug for that.
[20:09] <cristian_c> jsalisbury, ok
[20:09] <cristian_c> then, it needs so
[20:10] <jsalisbury> cristian_c, Ok.  I'll look for the new bug.  
[20:10] <jsalisbury> cristian_c, For the original bug, you never had a prior kernel that worked?
[20:10] <cristian_c> jsalisbury, I tried that pc with ubuntu at least since 2009
[20:11] <cristian_c> I think with 2.6.x too
[20:11] <jsalisbury> cristian_c, And the bug happened with the 2.6 kernel?  If that is the case, maybe it is not a regression.
[20:12] <cristian_c> jsalisbury, I think that the original bug is not a regression
[20:12] <cristian_c> jsalisbury, but I tried the workaround only later
[20:13] <cristian_c> jsalisbury, I'll try the kernels you suggested
[20:13] <cristian_c> :)
[20:13] <jsalisbury> cristian_c, Hmm, if the bug is not a regression and still exists in the latest mainline kernel(3.14-rc5), then we should probably open an upstream bug report as well.
[20:14] <jsalisbury> cristian_c, Ok.  Yeah, it would be best to test those kernels before reporting upstream.  That way we can confirm if it is a regression or not.
[20:15] <cristian_c> at the beginning switch was not working and there was no blinking
[20:16] <cristian_c> subsequently blinking appeared 
[20:16] <cristian_c> then, I tried the workaround, and colors were inverted
[20:17] <cristian_c> with 3.8.x series (ubuntu 13.04) too
[20:18] <cristian_c> when I tried 3.13.x regressions appeared
[20:18] <cristian_c> until now (3.14.x)
[20:19] <cristian_c> with regressions workaround didn't work anymore
[20:20] <cristian_c> (no color switch, neither reversed)
[20:40] <cristian_c> jsalisbury, ok, I'll make the test with old kernels and I'll report results in launchpad bug page
[20:40] <cristian_c> :)
[20:41] <jsalisbury> cristian_c, thanks
[20:41] <cristian_c> :D
=== hggdh_ is now known as hggdh