=== zz_nhayashi is now known as nhayashi
=== TheDrums is now known as TheMaster
=== TheMaster is now known as DalekSec
=== fmasi is now known as Guest98598
=== Guest98598 is now known as fmasi
=== shuduo_ is now known as shuduo
[13:10] <tjaalton> if it proves working, would something like https://git.kernel.org/cgit/linux/kernel/git/johan/usb-serial.git/patch/?id=cec285642a121069e9c05cfb4189871043d8c39c qualify as SAUCE?
[13:11] <tjaalton> my youngest daughter has type1 diabetes, and sending data off the insulin pump for the doctor needs this damn device
=== nhayashi is now known as zz_nhayashi
[14:03] <ogasawara> tjaalton: I'd consider that patch saucy worthy.  looks like it was undergoing some review/testing upstream on the linux-usb list
[14:03] <tjaalton> yeah
[14:11] <rtg> ogasawara, it is deeply disturbing to me that you and tjaalton are considering patches for a released kernel that have not been exposed to the Ubuntu community. poke, poke.
[14:12] <ogasawara> rtg: heh, well I'm assuming tjaalton will send a patch to the mailing list when he's ready :)
=== maxb_ is now known as maxb
[14:19] <tjaalton> sure :)
[14:19] <tjaalton> not assuming you to pull it from there
[14:19] <tjaalton> actually, I'm hitting that enumeration issue with superspeed ports
[14:20] <tjaalton> but it happens regardless of the patch
[14:23] <tjaalton> yeah seems to work on usb2, now I need to figure out how to get the data from it..
[14:44] <tjaalton> looks like there are no tools for it yet, so I'll check out the situation and get back to you when there's something to use with it
[14:44] <tjaalton> some background in http://www.diabetesmine.com/2013/01/the-ethical-imperative-of-diabetes-interoperability.html
[14:45] <tjaalton> bewest is the guy who emailed linux-usb about the enumeration issue
[15:05] <bjf> tjaalton, saucy doesn't have a lot longer on support
[15:13] <tjaalton> bjf: yeah I meant as sauce patch
[15:13] <tjaalton> it's not upstream yet, maybe for 3.16
[15:13] <bjf> tjaalton, still... best be upgrading to trusty :-)
[15:14] <tjaalton> that's what I use
[15:14] <tjaalton> ogasawara probably just typoed it :)
[15:14] <tjaalton> sauce/saucy
[15:15] <ogasawara> tjaalton: oops, yes, that was a typo.  I did mean sauce
[15:15] <tjaalton> :)
[16:15] <smoser> rtg, you have trusty on your x120e ?
[16:16] <rtg> smoser, yup
[16:33] <smoser> rtg, does it resume from suspend ?
[16:33] <smoser> because i dont. 
[16:34] <smoser> it dies, to the point where i have to pull the battery out on next reboot
[16:34] <rtg> smoser, actually, it has _never_ failed. I'll go update it andmake sure.
[16:38] <smoser> rtg, well, its only ever worked really well for me (suspend/resume). but just did fresh install last night (which is a pita because of the UEFI issue bug 1040320).
[16:38] <ubot2> Launchpad bug 1040320 in ubiquity (Ubuntu) "Lenovo x120e install fails when in UEFI mode" [Undecided,New] https://launchpad.net/bugs/1040320
[16:57] <smoser> rtg, well, ijust filed bug 1309112
[16:57] <ubot2> Launchpad bug 1309112 in linux (Ubuntu) "x120e does not resume from suspend" [Undecided,New] https://launchpad.net/bugs/1309112
[16:57] <rtg> smoser, mine is still updating
=== sz0 is now known as sz0`
[17:08] <rtg> ppisati, looks like some of the arm configs just turn off stack size warnings. 'git grep CONFIG_FRAME_WARN'
[17:09] <ppisati> rtg: i can see it's in our config _at least_
[17:09] <ppisati> (trusty-amd64)ppisati@tangerine:~/ubuntu-trusty$ grep -Ri FRAME_WARN debian.master/config/
[17:09] <ppisati> debian.master/config/powerpc/config.common.powerpc:CONFIG_FRAME_WARN=1024
[17:09] <ppisati> debian.master/config/armhf/config.common.armhf:CONFIG_FRAME_WARN=1024
[17:09] <ppisati> debian.master/config/amd64/config.common.amd64:CONFIG_FRAME_WARN=1024
[17:09] <ppisati> debian.master/config/arm64/config.common.arm64:CONFIG_FRAME_WARN=1024
[17:09] <ppisati> debian.master/config/i386/config.common.i386:CONFIG_FRAME_WARN=1024
[17:09] <ppisati> debian.master/config/ppc64el/config.common.ppc64el:CONFIG_FRAME_WARN=2048
[17:09] <rtg> ppisati, yup, which I why I noticed it. OK, looks like an upstream patch.
[17:10] <rtg> which is*
[17:22] <rtg> ppisati, hmm, must be an artifact of building that module for powerpc. on armhf the frame size is only 472 bytes.
[17:22] <rtg> I am assuming wireless/ti/wlcore can only be loaded on arm
[17:23] <ppisati> yep
[17:23] <rtg> ok, guess I'll leave it alone
[17:24] <ppisati> rtg: you got 8k usage for wlcore on ppc?
[17:24] <rtg> ppisati, 9172
[17:25] <cking> stack scribbler then
[17:25] <rtg> cking, except that wlcore will never get loaded on powerpc
[17:25] <cking> ah
[17:26] <ppisati> rtg: well, i don't know if TI relicensed it's wifi IP for a discerete chip/company
[17:26] <ppisati> rtg: but i doubt
[17:26] <ppisati> rtg: and in any case it would be another driver
=== sz0` is now known as sz0
[18:06] <smoser> rtg, upgraded  yet?
[18:06] <rtg> smoser, uh, yeah. works fine.
[18:06] <smoser> really?
[18:06] <rtg> would I kid you ?
[18:06] <smoser> i think you have that rtl wireless.
[18:06] <smoser> i dont knw what could be different.
[18:07] <smoser> other than i put a ssd in yesterday
[18:07] <rtg> smoser, what is your wifi ? I haven't looked at the bug yet
[18:07] <rtg> I have an SSD
[18:07] <rtg> rtl8188ce
[18:08] <smoser> https://launchpadlibrarian.net/173032656/susres.2014-04-17_12%3A45%3A58.004375.crash
[18:09] <smoser> rtg, you dont boot with UEFI do you?
[18:09] <rtg> smoser, not that I recall. I'm pretty sure I don't have grub-efi installed.
[18:10] <rtg> smoser, actually, I _do_ have grub-efi-amd64 installed.
[18:11] <smoser> i could not get bios to recognize anything the installer laid down.
[18:11] <smoser> i let it do auto once
[18:11] <smoser> and did it myself another.
[18:19] <smoser> i wonder why i'm unlucky.
[18:28] <smoser> apw, your name is on /usr/share/apport/apportcheckresume
[18:29] <smoser> that runs after my system fails to resume. and i think it crashes.  *it* causes a dialog (i think). but maybe i'm misunderstanding something.
[18:29] <apw> smoser, it is meant to cause an apport report when resume fails indeed
[18:30] <apw> smoser, its job is to work out that we have booted but that the last thing we did was suspend not shutdown; in that case it files a bug report
[18:30] <smoser> well... hm.. its confusing.
[18:31] <smoser> what you're saying makes perfecdt sense. and thats what i thought
[18:31] <smoser> but then
[18:31] <smoser> the dialog that comes up says
[18:31] <smoser> "Sorry, the application apportcheckresume has stopped unexpectedly"
[18:31] <smoser> ExecutablePath /usr/share/apport/apportcheckresume
[18:32] <smoser> whiich made me think *it* crashed when something else ran it.
[18:32] <smoser> am i just not reading the dialog right?
[18:32] <apw> it may well have does it wrong, can you let it file a bug, and send me the name
[18:33] <apw> number even
[18:33] <smoser> well, on that system it never gets there.
[18:33] <smoser> the dialogs just go away
[18:33] <smoser> i say "continue", then nothing.
[18:33] <apw> well that is quality, ok, i'll try and reproduce it, could you email me direct and remind me, as i will forget by tuesday
[18:34] <smoser> happy easter.
[18:34] <smoser> i'll try to remember too.
[18:34] <apw> smoser, you too :)  /me blames it on p itt i or someone :)
=== sz0 is now known as sz0`