[00:13] <bjf> ogasawara, i already know about #ubuntu-ops, i dropped out after my first day, they were giving me shit for stupid stuff
[00:14] <bjf> pgraner, ^
[00:42]  * vanhoof looks in
[00:57] <bjf> Arrrgg! CHURCH BELLS!!!
[00:58] <ogasawara> bjf: what time is it there?
[00:59] <bjf> ogasawara, 2 a.m., gotta love jet lag
[00:59] <ogasawara> yuck
[00:59] <bjf> ogasawara, the church bells on the qrtr hr. don't help
[00:59] <ogasawara> bjf: wow, that's annoying
[01:00] <jjohansen> yikes
[01:00] <bjf> ogasawara, it's on the hour now, so i am getting the full deal right now
[01:00] <jjohansen> every quarter hour in the night?
[01:00]  * ogasawara hands bjf some ear plugs
[01:00] <bjf> ogasawara, they play almost an entire song with bells and then the hour is bonged out
[01:02] <bjf> hughhalf, got your email, do you want me to follow up with #admin tomorrow if we don't hear anything?
[01:02] <bjf> ogasawara, the room comes with ear plugs on the bed :-)
[06:12] <bullgard4>  '~$ uname -r; 2.6.32-21-generic'. After startup or thawing there is a process 'flush-8:0' (and often similar ones having other digits). What is its function? I believe it is a kernel process which writes a buffer to disk. Where can I find its associated source code?
[06:13]  * winXPuser googles it
[06:14] <winXPuser> Do you have wine?
[06:14] <winXPuser> I mean Wine, the app
[06:14] <winXPuser> the one which can run windows applications in linux
[06:17] <bullgard4> winXPuser: Who are you talking to?
[06:18] <winXPuser> you! I tried to google your string, it seeems to be related to wine on linux
[06:21] <RAOF> bullgard4: I *think* you'd be looking for the vfs subsystem.  I don't think that's the responsibility of the filesystem (probably ext4).
[06:22] <bullgard4> winXPuser: I do not use Wine.
[06:23] <winXPuser> Hm.
[06:25] <bullgard4> RAOF: I agree with you that my problem is not within the responsibility of the filesystem. Rather, of the kernel.
[06:26] <RAOF> bullgard4: I haven't seen you describe a problem?  Are you looking for this code for some particular reason?
[06:28] <bullgard4> RAOF I am looking for this code because i.) my X occasionally crashes ii.) After booting or thawing I am getting a lot of I/O operations which was not the case with earlier kernel.
[06:30] <RAOF> Oh.  Well, that will be a kernel thread responsible for writing the the buffers out to one of your discs.  It's clearly going to be doing a lot of i/o :)
[06:30] <RAOF> It's not going to generate any i/o on its own, though.
[06:40] <bullgard4> RAOF: You say: "that will be a kernel thread responsible for writing the the buffers out to one of your discs." Where can I find the source code for the 'flush-8:0' process?
[06:41] <RAOF> As I said before: I think you'll be looking at the vfs subsystem.  Of the kernel.
[07:50] <baptistemm> jjohansen, another example is bug 572197 where the adapter was discovered under karmic but not under lucid 
[07:50] <ubot3> Malone bug 572197 in bluez "Bluetooth adapter not detected (dup-of: 416487)" [Undecided,New] https://launchpad.net/bugs/572197
[07:50] <ubot3> Malone bug 416487 in bluez "Bluetooth Doesnt Work - Eee PC 1005HA-P" [Undecided,Incomplete] https://launchpad.net/bugs/416487
[07:51] <baptistemm> perhaps I shouldn't had duped this one
[08:06] <mase_wk> jjohansen: don't suppose your awake ?
[08:46]  * cking waves to smb 
[08:46] <smb> Good morning cking 
[08:48]  * smb waits for the coffee to take effect...
[08:48]  * apw waves to smb ... flights working ok then i assume ... seems .ie is closed again
[08:48] <apw> (for ash)
[08:49] <smb> apw, Yeah, no issues on my flights. But I read about IE
[08:50]  * apw was able to eat something without throwing up this morning
[08:50] <jk-> apw: crap, not feeling well? :/
[08:50] <smb> apw, Sounds like an improvement. Head is feeling better, too?
[08:51] <apw> jk-, yeah been a bit off my game this weekend, most unpleasant
[08:51] <jk-> bugger.
[08:51] <apw> smb, head is pretty much normal i think, waiting on my stomach to confirm breakfast was acceptable
[08:52]  * smb hopes for the best
[08:52]  * apw does too, i've lost 5 pounds since friday
[08:53] <cking> apw, maybe there was something going around the office last week - I spent the weekend in recovery mode too
[08:53] <smb> If that would not be that unpleasant I might be tempted to try that... :-P
[08:53] <apw> smb, i see the lucid -proposed kerenel is still in -proposed i guess we need to talk to pitti today about that
[08:54] <apw> cking, coffy, slight nosey, sicky, headachey ?
[08:54] <smb> apw, Yeah, that should go as quickly as possible to updates.
[08:54] <cking> apw, yep
[08:55]  * cking thought it was just some bad food I ate
[08:55] <apw> i t
[08:55] <apw> cking, i think its a stomach flu, just no strong dripping nose
[08:56] <cking> gah
[08:56] <apw> that you had it in the same timescale as me, means we got it from someone at the office
[08:56] <apw> i don't think you would be so advanced if i'd been the vector
[08:57] <cking> probably from monday then
[08:57]  * smb must have been too stubborn to accept that. Or it comes later
[08:57] <apw> smb, think too healthy, or too hardy :)
[08:58] <cking> he is the hardy maintainer
[08:58] <apw> :)
[09:02] <smb> apw, Saw that commend from piti about still some claims on failing fans after resume?
[09:03] <apw> smb, yep
[09:03] <apw> i am waiting on soooo speedy LP for the bug now
[09:03] <smb> apw, Ok. So lp rocks again? :)
[09:05] <apw> smb, rocks indeed ... 40s to open a bug at the moment
[09:06] <apw> well actually worse, its still opening, that was another tab finishing ... sigh
[09:08] <smb> apw, Maybe part of the health care program. Prevents you from overworking yourself
[09:09] <apw> smb, good point :/ ... i suspect some maverick processing is hammering the DB into the ground
[09:10] <smb> apw, Not to forget the getting read-onlyness mentioned elsewhere
[09:10] <smb> apw, Seems to be today in an hour, so it might be preparing for that
[09:10] <apw> gah
[09:11] <apw> smb, no its just edge in a heap
[09:12] <apw> redirection disabled ... sensible load times restored
[09:12] <smb> heh
[09:16] <apw> smb, ok those new reports in the EC (v3) bug seem all related to suspending, removing battery, and resuming ... who the heck does that :)
[09:17]  * smb is surprised that that works at all
[09:17] <apw> yeah once my machine has finished syncing its brain i am going to try it here
[09:17] <smb> Guess they must have ac connected
[09:17] <apw> one assumes so ...
[09:20] <cking> apw, that's the kind of madness I sometimes have to test... don't knock it ;-)
[09:22] <apw> cking, perhaps you could spin round the machines you have immediatly to hand and see if it works there or not
[09:22] <apw> it could just as easily never have worked
[09:22] <cking> apw, will in in 45 mins or so - I've got a dr appointment in 10 mins - gotta go
[09:22] <apw> cking, luck
[09:33] <apw> tgardner, morning ... 
[09:34] <tgardner> apw, dude, was'up ?
[09:34]  * apw has been in a heap all day yesterday, so am unsure if i am fit to travel to the office as yet
[09:35] <tgardner> apw, spend some time getting well.
[09:38] <apw> tgardner, seems cking has had the same, so i think we must have picked it up in the office
[09:38] <tgardner> apw, bummer
[09:49]  * cking fetches some H/W from the loft
[09:50] <bjf> cking, you must be about to travel, i see that ireland is closing airspace due to ash
[09:51] <cking> bjf, volcanoes are old news, I'm ramping up to the next level - earthquake and/or asteroid strike
[09:52]  * apw considers how much ash there would be if an asteroid struck cking 
[09:53] <tgardner> cking, speak not of the devil lest he appear. I'm going under the channel tomorrow, so I'd just as soon there were no earthquakes.
[09:53]  * cking will not mention any natural or unnatural disasters from now on
[09:54]  * bjf is a natural disaster
[09:55]  * apw moans about this new maverick tree bloating his unison sync
[09:55]  * cking double checks his H/W inventory again
[09:56] <apw> bjf, ahh you are local for a couple of days arn't you
[09:57] <apw> you going back home before uds of continuing on
[09:57] <bjf> apw, straight from here to uds
[09:58] <bjf> i'll be traveling to la hulpe tomorrow actually
[09:58] <apw> bjf very sensible, its not that far i assume relativly speaking
[09:59] <bjf> not bad, no
[09:59] <bjf> i'm not working on my air miles like ogasawara :-)
[10:00] <bullgard4> RAOF:  /usr/src/linux-source-2.6.32/Documentation/filesystems/vfs.txt (June 24, 2007): "Overview of the Linux Virtual File System (VFS): "The File Object: A file object represents a file opened by a process.  The struct file_operations describes how the VFS can manipulate an open file. struct file_operations {...; int (*flush) (struct file *); ... ;};  Where is the definition of this flush...
[10:00] <bullgard4> ...to be found?
[10:01] <apw> bjf, heheh
[10:01] <apw> bullgard4, that would be in each filesystem, specific to it in general
[10:02] <bullgard4> apw: Ah! Thank you for your remark.
[10:02] <apw> bullgard4, look for a definition of stuct file_operations in the filesystem implementation, it should have a line like '.flush = ext4_flush'
[10:02] <apw> the name on the right is a function which implements that
[10:06] <bullgard4> apw: I will do snooping according to the directions which you gave. --  Thank you.
[10:09] <apw> tgardner, let us know how the travel works our tomorrow, as a number of us are following in your exact footsteps, train numbers, station names, and the like appreciated
[10:13] <tgardner> apw, will do
[10:22] <baptistemm> heya
[10:24] <apw> hi
[10:24] <baptistemm> sorry I'll repeat what I asked yesterday night: I'm coming to get some help about bluetooth adapter and kernel, I'm managing the applications and bug report related to bluetooth and I have some bug reports where people reported their bluetooth adapter is no more discovered in lucid while they were seen in karmic kernel.
[10:25] <baptistemm> One example is example is bug 572197 where the adapter was discovered under karmic but not under lucid 
[10:25] <ubot3> Malone bug 572197 in bluez "Bluetooth adapter not detected (dup-of: 416487)" [Undecided,New] https://launchpad.net/bugs/572197
[10:25] <ubot3> Malone bug 416487 in bluez "Bluetooth Doesnt Work - Eee PC 1005HA-P" [Undecided,Incomplete] https://launchpad.net/bugs/416487
[10:25] <apw> baptistemm, i don't know of any bluetooth controllers we would expect to have become unsupported
[10:26] <baptistemm> I'm not impacted by such bug so it's hard for me to know what happens, and my kernel fu is somewhat near zero
[10:26] <apw> baptistemm, therefore i would say we need to find out if they are PCI or USB and find out their IDs in each case to see if there is a pattern
[10:26] <baptistemm> apw, is there a specific driover for each adapter or is btusb a generic module for them?
[10:27] <baptistemm> I did an apport hook for bluez so normally there is the output of lsusb attached to bug report 
[10:28] <apw> baptistemm, i am not much of a bluetooth expert either, but most seem to be USB and use the same driver ... i think its called btusb but i note that i don't have BT on either of these boxes ... hrm
[10:28] <apw> baptistemm, from a triag point of view, we'd be wanting to find out the exact id's of the devices, and getting dmesg output from karmic (or whever it worked) too
[10:28] <apw> to see which driver picked it up there
[10:29] <baptistemm> apw, how tyhe kernel know which module to load for a device (sorry for the dumb question) or point me to a good explanation of you can :)
[10:30] <apw> baptistemm, it also sounds like there is a fair few of these?  if so it would be handy to get the ones you think are related to this issue tagged with something ... lucid-bluetooth or something and let JFo know that you think there is an issue and what tag you are using
[10:30] <apw> as he can help get the initial triage done there
[10:30] <baptistemm> apw, hmm okay, that would be nice, I'm a bit ashamed to not had come earlier to see that with you
[10:31] <apw> baptistemm, the kernel generally loads drivers based on device attributes, PCI ids, USB ids, HID attributes etc
[10:31] <baptistemm> apw, does make a updated-usbid would help the user? ?
[10:31] <apw> baptistemm, don't be, at least we are aware now, and can follow up
[10:32] <apw> baptistemm, not sure ... the best thing is to collect these all together and and lets get a kernel person to go over them looking for a common issue
[10:32] <baptistemm> I'm not that ashame, but not one cared to follow bluetooth bugs for months, and I see such. I just try know to do the job that someone should do :)
[10:33] <apw> and i think the best way there is to leverage the good work you have done, by getting your list to our main triage contact: ircnick JFo, though he is normally not awake for a few hours yet
[10:33] <apw> baptistemm, the first step is knowing who to approach, us here for one, and definatly knowing jfo can help as he has a lot of trige experience and always keen to have help from area experts
[10:35] <apw> BAH is LP read-only again?
[10:35] <soren> Yes.
[10:35] <soren> "Launchpad down/in read-only from 09:00-11:00UTC for a code update" from /TOPIC in #lanchpad.
[10:35] <soren> #launchpad, even.
[10:37] <apw> down about .6% of the time for upgrades ... and they almost always on annoying days
[10:39]  * cking takes the LP downtime opportunity to swap HDD drives on laptop
[10:41] <baptistemm> apw, Okay I'll ping Jfo tonigh, I'm EU based but my free-time is after dinner
[10:41] <apw> baptistemm, well that is probabally about perfect timeing for him, if i see him before you i'll let him know
[10:44] <baptistemm> wonderful, thanks
[11:00] <apw> psurbhi, hey ... made it back home in the end?
[11:07] <psurbhi> apw, yes..
[11:08] <psurbhi> apw, I hope you get better by the weekend
[11:09] <psurbhi> when are you traveling to brussels?
[11:09] <apw> psurbhi, yeah think i am on the mend, at least i can see straight today.
[11:09] <psurbhi> :-)
[11:09] <apw> psurbhi, yeah off on sunday
[11:09] <psurbhi> ok..cool
[11:09] <apw> i suspect the majority appear that evening, so we can have a team get to gether somewhen in the evening
[11:10] <psurbhi> cool
[11:16]  * cking tries suspending, removing battery, and resuming and it works OK in his kit with latest kernel
[11:18]  * apw has a go too
[11:18]  * cking tries one more machine
[11:18] <bjf> apw, there is a mandatory meeting Sun. night no?
[11:19] <apw> bjf erm is there?
[11:19] <cking> apw, check your email
[11:19] <apw> cking, we there in time?
[11:19] <cking> looks like a close call
[11:20] <apw> typical planning balls up, they really should tell people before they tell us to book shit
[11:37] <apw> cking, well after 5 mins i finally managed to get the battery out of my mini10v without waking it up, and its ok
[11:37]  * apw suspends this one
[11:37]  * cking next tries HP mini
[11:40]  * psurbhi digs into btrfs code
[11:42] <cking> psurbhi, did you check out that grub 0.97 btrfs patch that I referred to?
[11:42] <psurbhi> cking, yes i got that one
[11:42] <psurbhi> cking, m looking first at only single device support.
[11:43] <psurbhi> that patch needs huge modifications for grub2, but ofcourse is a very helpful one
[11:43] <cking> yep, it's a pain to migrate between the two versions
[11:45] <cking> psurbhi, what's "single device support"? I'm confused
[11:45] <psurbhi> cking, no raid support.. no subvolume
[11:45] <psurbhi> from grub
[11:46] <psurbhi> so targeting /boot to be on a single partition and no raid involvd
[11:47] <cking> psurbhi, why do you need to be looking at that for btrfs? or is this another side-issue that needs looking at?
[11:47] <psurbhi> cking, as in?
[11:48] <psurbhi> cking, i am not looking at that right now..but sometime later someone else might do it
[11:49] <cking> psurbhi, I just thought you were digging around in brtfs/grub2 support... sorry, I'm not fully up to speed with what you are doing in grub2
[11:49] <psurbhi> cking, yes thats right
[11:50] <psurbhi> cking, http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg02024.html
[11:51] <psurbhi> cking, i am trying to get up to speed with the btrfs features :(
[11:51] <psurbhi> and what needs support from grub
[11:52] <cking> psurbhi, fair enough, it looks like a minefield
[11:52] <apw> cking, HRM, well my dell 1537 shows this suspend/remove battery/resume/no fans issue ... interestingly inserting the battery live after resume makes the sensors come back
[11:55] <cking> apw, whats the LP bug for this again?
[12:00] <apw> cking, just got them to start a new one
[12:00] <apw> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/575030
[12:00] <ubot3> Malone bug 575030 in linux "[Dell Studio 1537] No sensors and fan control if there is no battery present on wakeup from suspend" [Low,Triaged] 
[12:01] <apw> cking, it is reasonable to remove/reinsert a battery with the machine running right?
[12:01] <cking> apw, yep
[12:01] <apw> cking, then i think we can call this one pretty low as you can fix it by inserting and re-removing the battery
[12:01] <cking> it's perfectly reasonable. Depends what the BIOS does when the EC detects these state changes
[12:03] <cking> apw, it's going to be annoying if one has to replug the battery every time
[12:03] <apw> cking, yep for sure, though why you would remove the battery is beyond me
[12:04] <apw> i need to try and karmic kernel i guess to find out if this is a regressions
[12:05] <cking> yep - you've got H/W which can repro this bug - that's v.helpful
[12:06] <apw> cking, going down to try the other combination, removing the battery awake then s/r
[12:08] <akgraner> apw, my cpu temp has been hovering about 78C all morning- but when I killed Chromium and Gwibber it went back to 48C - Do you know if Gwibber is still causing the CPU temp to rise like that?
[12:09] <apw> akgraner, i have a vague memory of someone saying something about a CPU issue with gwibber, so could be
[12:09] <apw> akgraner, is that with the -proposed kernel or the regular one?
[12:09] <akgraner> apw -proposed as far as I know - I didn't change it since I added -proposed
[12:09] <apw> cking, ok its actually r without battery thats the issue as removing the battery before also breaks things
[12:10] <apw> akgraner, cat /proc/version_signature whats that say
[12:11]  * akgraner looks
[12:11] <akgraner> apw, Ubuntu 2.6.32-21.32-generic 2.6.32.11+drm33.2
[12:12] <apw> akgraner, the version in -proposed is -22.33
[12:12] <akgraner> apw, hmm how'd that change :-(
[12:12] <apw> https://edge.launchpad.net/ubuntu/+source/linux
[12:13] <akgraner> on my machine I mean
[12:13] <cking> anyone got any ideas on why S4 is so sloooooow
[12:13] <apw> thats the only version that has ever been in -proposed
[12:13] <apw> cking, so slow to get into and out of ?
[12:13] <akgraner> apw, I meant how did it get changed after I installed the -proposed one b/c I didn't change it 
[12:13] <cking> apw, yep - compared to Windoze and OS X it's really lame
[12:13] <apw> akgraner, i suspect you never got it
[12:14] <apw> cking, S4 == hibernate
[12:14] <akgraner> but anywho - let me go add the -proposed one and add it
[12:14] <akgraner> brb
[12:14] <apw> cking, ?
[12:14] <cking> apw, yep, S4 == hibernate.  I've found that dropping cached pages may help, but I thought hibernate evicted these pages by default
[12:18] <apw> cking, i also find it takes for ever, though i have 4GB of ram and everything like sync etc do
[12:18] <apw> cking, windows does its magic suspend means hibernate and suspend hybrid thing, and i suspect that is the trigger for the 'always writing' behaviour of windows
[12:24] <cking> apw, yeah, given enough time I'd rig up a QEMU image of both and check out I/O block activity to sanity check this assumption
[12:24] <apw> cking, yeah sounds like a plan for your copius [sic] spare time
[12:30] <cking> apw, I have a server spare next door, so I can kick off some tests
[12:30]  * apw pokes his head out the window to hear cking's server spin up
[12:31] <cking> heh
[12:32] <akgraner> apw, it's gwibber - I started it back up and within a couple seconds the temp went from 42C to 63C
[12:32] <apw> akgraner, ouch
[12:33] <apw> akgraner, fans running ok with that kernel i hope
[12:33] <akgraner> oh yeah now they kick on
[12:33] <akgraner> where as before they never did
[12:33] <akgraner> apw so that is a win :-)
[12:34] <apw> akgraner, yeah something at least
[12:34] <akgraner> apw, that just means now I have to be less social until I can get this gwibber thing worked out :-)
[12:35] <apw> akgraner, social from the cooker
[12:36] <akgraner> hehe
[12:36]  * abogani waves
[12:36] <abogani> I'm wondering why in kernel configuration the default governor is "performance" (`grep -i cpu_freq_default /boot/config-2.6.31-21-generic`) but a `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor` return "ondemand".
[12:37] <ogra> abogani, it gets switched during boot
[12:38] <ogra> using performance in the initial boot significantly speeds up the bootprocess
[12:39] <abogani> ogra: Sound reasonable. Is there a way to configure it (I would want stick on "performance")?
[12:39] <ogra> no idea, i guess you culd script it to switch back though
[12:40] <mdz> abogani: /etc/init.d/ondemand
[12:42]  * apw reminds everyone there is a kernel Q&A session at 15:00 UTC Thursday
[12:44]  * apw reboots to test a karmic kernel with batteries/s/r ... sigh
[12:46]  * apw wonders if this thing will even boot with a karmic kernel any moer
[12:46]  * JFo notes the kernel q&a on his calendar
[12:47] <apw> JFo, baptistemm was interested in helping/getting advice on correctly triaging bluetooth failures
[12:47] <JFo> apw cool! :)
[12:48] <JFo> baptistemm, let me know if you need any information on how to triage
[12:48] <JFo> I have tons of links and we can look at specific bugs etc.
[12:50] <apw> JFo, he is likely about later in your day, thats when their spare time is
[12:50] <apw> s/he/their/
[12:50] <JFo> yeah, I suspected
[12:50] <JFo> thanks for the heads-up apw 
[12:56] <JFo> morning ogasawara 
[12:56] <smb> Screwed up in timezones it seems... 
[13:14] <apw> ogasawara, heads up that as of today, if you sync anything from lucid to maverick you may need to sort out the bug, as you likely have a linux task now
[13:40]  * JFo wonders if anyone is interested in looking at bug 569610
[13:40] <ubot3> Malone bug 569610 in linux ""Kernel unaligned access at TPC" causing network/system to become slow and/or unresponsive" [Medium,Triaged] https://launchpad.net/bugs/569610
[13:40] <JFo> :-)
[13:40]  * JFo is a giver
[13:49] <cking-afk> back in 15
[13:51] <pgraner> JFo: hey make sure you bring my little bag of travel adapters, it was in the travel box
[13:52] <JFo> yessir
[13:52] <pgraner> JFo: smart ass
[13:52] <JFo> :-)
[13:52] <JFo> oh hey pgraner, my ticket says i fly at 1:40PM
[13:53] <JFo> so looks like a different flight than the one you are on
[13:53] <JFo> kind of odd, but oh well
[13:53] <pgraner> JFo: that means your on the same flight to beligum, I have a 5 hr layover in Chicago
[13:54] <JFo> ah, yep. i bet that is it
[13:56] <JFo> sconklin, you interested in a Intel graphics bug? bug 555595
[13:56] <ubot3> Malone bug 555595 in linux "Intel graphics performance regression in 2.6.32-19 lucid kernel update (was: Firefox Slows Down Compiz)" [Medium,Triaged] https://launchpad.net/bugs/555595
[14:07] <bigcx2> hey all
[14:07] <bigcx2> i'm having a problem building a custom kernel under ubuntu
[14:08] <bigcx2> i'm using a fresh 2.6.32.11 kernel
[14:08] <bigcx2> and i simply copied the config to my .config
[14:09] <bigcx2> and did CONCURRENCY_LEVEL=2 time fakeroot make-kpkg --initrd --append-to-version -geode-ubuntu --config oldconfig kernel_image
[14:09] <bigcx2> but then on booting
[14:09] <bigcx2> i get a kernel panic
[14:09] <bigcx2> saying, can't find root partition
[14:10] <bigcx2> what gives?
[14:10] <bigcx2> the UUID in grub is exactly the same as the working version
[14:11] <bigcx2> and i also tried specifically setting root (hd0,0) and root=/dev/sda1 with no success
[14:12] <apw> JFo, i'd say that that is a sparc issue isn't it? so its not a high priority for us
[14:12] <JFo> yeah, i suspected that might be the case
[14:12] <JFo> just wanted to get someone smarter than me to have a look :)
[14:13] <apw> bigcx2, does it make you an initramfs?  UUID is mapped by initramfs, if root= does not work then i would wonder if the disk driver is loading correctly, or again if you are missing an initramfs as we do not build most of them in
[14:14] <sconklin> JFo: I'll subscribe myself, thanks. I think it's probably compiz and not kernel, but who knows
[14:14] <JFo> sconklin, I was wondering that, but I am still way away from being anywhere near conversational on graphics :)
[14:15] <JFo> thanks for looking
[14:15] <bigcx2> apw: i don't think it's loading the proper disk driver, when i boot the kernel in debug mode, it says "here are the available partitions"
[14:15] <bigcx2> apw: but then nothing shows up
[14:16] <apw> that would be indicative of no driver.  do you have an initramfs for that kernel 
[14:16] <bigcx2> apw: but i can't figure out why it wouldn't be loading the proper driver? like i said i used the exact same config used in my working kernel
[14:16] <bigcx2> i ran make-kpkg with --initrd if that's what you mean
[14:17] <apw> bigcx2, the most important thing is whether we see it loaded kernel wise
[14:17] <apw> you get to an initramfs prompt on failure to find the root disk?
[14:17] <apw> if not i suspect its not using it
[14:17] <bigcx2> no, i don't get a prompt
[14:18] <bigcx2> how can i get it to use it?
[14:18] <vanhoof> good morning 
[14:18] <apw> if the initramfs was waiting for the dfisk, and it didn't appear you would get a prompt after the timeout
[14:18] <apw> bigcx2, the kernel obviously does not do that, and its there you see the list you mentioned.  so i am suspicious you don't have the initramfs in use
[14:19] <apw> that can occur for several reasons, not specified in the boot loader entry, or incorrect option on the kernel so it doesn't check
[14:19] <bigcx2> hmm
[14:20] <bigcx2> let me take a look at my grub conf one more time
[14:20] <apw> bigcx2, i'd start with the bootloader as you used our config
[14:21] <bigcx2> aha!
[14:21] <sconklin> JFo: yeah, just checked, and there were no major changes in the intel driver in the release range mentioned in the bug - I'll update it with that info
[14:21] <JFo> coolness, thanks sconklin 
[14:21] <bigcx2> there's not initrd line in my custom kernel boot!
[14:21] <bigcx2> no*
[14:22] <bigcx2> i wonder why that didn't get appended to the grub conf
[14:22] <apw> bigcx2, strange indeed
[14:23] <abogani> I suggest to post the "ls -l /boot' output
[14:23] <bigcx2> thanks guys, one sec
[14:24] <sconklin> Wait JFo, I did find a cuoplf of i915 patches that went in when they say the problem started, I'll investigate
[14:24] <JFo> sconklin, k
[14:27] <bigcx2> yea, it looks like there was not initrd generated for my custom kernel
[14:27] <bigcx2> ?!
[14:27] <bigcx2> i see a System.map file
[14:28] <abogani> bigcx2: AFAIK the debian way for generate initial ramdisk (aka make-kpkg --initrd) don't work on Ubuntu.
[14:28] <bigcx2> abogani: please ubuntize me :)
[14:29] <abogani> bigcx2: cd /boot; sudo mkinitramfs -o $DESTDIR/initrd.img-$VERSION $VERSION
[14:30] <bigcx2> abogani: ok, trying that, how can i make my kernel deb include that as part of the build process?
[14:31] <bigcx2> aka what is the proper ubuntu build procedure?
[14:33] <bigcx2> AUTOBUILD?
[14:34] <abogani> bigcx2: Initramfs file generation never should be included in deb build procedures because it is machine depend.
[14:34] <bigcx2> abogani: ok, did not know that
[14:35] <bigcx2> i'm reading the wiki page on kernel compile
[14:35] <bigcx2> and it says
[14:35] <bigcx2> Since Ubuntu Lucid (10.04) the image postinst no longer runs the initramfs creation commands. Instead, there are example scripts provided that will perform the task. These scripts will work for official kernel images as well. For example 
[14:37] <bigcx2> sudo cp /usr/share/doc/kernel-package/examples/etc/kernel/postinst.d/initramfs /etc/kernel/postinst.d/initramfs 
[14:37] <bigcx2> sudo cp /usr/share/doc/kernel-package/examples/etc/kernel/postrm.d/initramfs /etc/kernel/postrm.d/initramfs
[14:40] <bigcx2> abogani: if it's not included in the deb build procedure, should I put it in there by hand in the debian postinst, postrm scripts?
[14:42]  * persia was under the impression that was now handled by triggers from initramfs-tools
[14:45] <bigcx2> ok, so i just tried to add my initrd img to my grub conf, which complained about ot beign able to load modules.dep
[14:45] <bigcx2> and then it failed to mount the root filesystem based on uuid
[14:46] <bigcx2> then i tried specifically putting in a root (hd0,0) line and adding root=/dev/sda1
[14:46] <bigcx2> both methods dropped me into a busybox initramfs shell
[14:56] <bigcx2> abogani: i just got it to work by using update-initramfs
[14:56] <bigcx2> instead of mkinitramfs
[14:57] <bigcx2> update-initramfs -t -c -k ${VERSION}
[14:57] <bigcx2> and then updating my grub conf
[14:58] <bigcx2> but i guess my question is, what's the best way to automate that? will using AUTOBUILD do the trick?
[15:00] <ianloic> argh, so my key input is feeling super laggy and drops keystrokes. plus event/1 takes 30-60% of cpu. where should I ask? how can I debug?
[15:01] <ianloic> this is on 10.10 on a thinkpad x61 (ie: intel chipsets)
[15:01] <abogani> bigcx2: No. I don't know a lot about Lucid but until Karmic initramfs was generated at installation time.
[15:02] <abogani> bigcx2: If you create a flavour probably you don't have to take care of it.
[15:03] <bigcx2> ?
[15:04] <abogani> bigcx2: If you create an Ubuntu kernel flavour (aka you reuse debian.master/ directory as template renaming in debian.myflavour) probably you don't have to care on how initramfs will be generated.
[15:04] <abogani> s/renaming/copying
[15:05] <cking> doh
[15:05] <bigcx2> ah, ok i'll look into that
[15:05] <bigcx2> thx
[15:08] <abogani> bigcx2: I would suggest you to take a look on  http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=summary (in the bottom of the page at 'heads').
[15:10] <bigcx2> abogani: k, thanks
[15:29] <baptistemm> JFo, Hi, as apw said, I try to triage bluetooth software related bugs, and some of them are about bt device not being discovered (after kernel and/or distro upgrade). Now I'm at work but I'll try to get back to you once I'm back home tonight or in the current week
[15:29] <JFo> ok baptistemm sounds good
[15:37]  * psurbhi breaks.. eyes are watering.. 
[15:51] <ogasawara> apw: you mentioned earlier that if I sync'd Lucid with Maverick as of today I need to sort out "the bug", which bug is that?
[15:52] <apw> ogasawara, if those commits have a bug number, its likely now they would have a lucid and linux task
[15:52] <ogasawara> apw: ack
[15:52] <apw> the linux task is yours now, rather than lucid as it were
[15:52]  * ogasawara was too literal with her interpretation of "the bug"
[15:54] <apw> ogasawara, heh yeah probabally
[15:54]  * JFo was thinking bug 1
[15:54] <JFo> :)
[15:54] <ubot3> JFo: Error: Could not parse data returned by Malone: The read operation timed out
[15:54] <JFo> wow
[15:54] <JFo> ubot3, fail
[15:54] <ubot3> Factoid fail not found
[15:54] <JFo> heh
[15:54] <apw> thats normal its too long
[15:54] <tgardner> apw, I think there is a maverick field now as well. at least when you nominate for release, maverick shows up in the list
[15:55] <tgardner> we should be able to assign all maverick bugs to ogasawara 
[15:55] <ogasawara> apw: for the most part, I'm relying on smb et al to follow SRU policy from this point ie the fix needs to be applied to the actively developed kernel before qualifying for SRU
[15:55] <apw> :)
[15:55]  * ogasawara slaps tgardner 
[15:55] <apw> ogasawara, yeah there is a 'gap' for some in there now i suspect
[15:56]  * ogasawara nods
[15:56] <apw> ogasawara, as normal, "here is an egg"
[15:57] <ogasawara> haha
[16:15]  * psurbhi quits for today
[16:24] <JFo> moin bjf 
[16:24] <bjf> jfo, :-) right
[16:24] <JFo> :)
[16:25] <JFo> late afternoon then? :-P
[16:28] <bjf> JFo, 5:30 p.m., it's time for a beer
[16:29] <JFo> indeed it is
[16:34] <cking> bjf, where are you at the moment? I'm geographically challenged 
[16:34] <tgardner> apw, how do I disable join/depart messages on this silly xchat client?
[16:35] <bjf> cking, i'm in utrecht, the netherlands
[16:35] <smb> tgardner, You right click on the channel tab
[16:36] <smb> tgardner, Then tick under settings
[16:36] <tgardner> smb, doh! not an obvious place
[16:36] <apw> tgardner, yeah what smb said
[16:36] <tgardner> I have to do that for each channel?
[16:37] <smb> tgardner, I did that, though maybe there is a shortcut. Luckily xchat remembers
[16:37] <vanhoof> tgardner: does xchat respect /ignore ?
[16:37] <achiang> http://xchat.org/faq/#q211
[16:37] <ogasawara> manjo: do you need us to hold a session at UDS for the kernel-maverick-firewire-stack blueprint, or do you already know what needs doing
[16:37] <achiang> tgardner: ^^
[16:38] <ogasawara> manjo: ie no need for me to schedule a slot for it
[16:38] <vanhoof>  this might get you what you need  -- /ignore * JOINS PARTS QUITS MODES
[16:38] <tgardner> achiang, cool, thanks
[16:38] <achiang> np
[16:39] <bjf> tgardner, don't you want settings->preferences->chatting->general
[16:39] <bjf> ?
[16:39]  * achiang has backlog_msg_only = true; set in his bip.conf too
[16:39] <bjf> tgardner, maybe not
[16:40] <tgardner> bjf, that doesn't cover all of the cases
[16:51]  * JFo goes for lunch
[17:07]  * cking wonders where the day has gone
[17:08]  * awe too
[17:08] <apw> cking, illness afterglow
[17:10] <cking> apw, 7.5 hours answering emails so far. backlogged from last week
[17:11] <kamal> cking: hiya - got a few minutes to look at some DSDT insanity?
[17:12] <kamal> cking: or should I just add my questions to your email pile?  ;-)
[17:13] <cking> kamal, gimme 5 mins to get a coffee - my head is spinning today
[17:14] <kamal> yeah, i saw after I asked that you were already maybe starting to wind down :-)   I'll send you my Q's and be here to chat about it if you're up for it.
[17:19] <cking> kamal, yep, send me an Email and I will read it while slurping some brain stimulants
[17:20] <kamal> cking: done -- thanks for taking a look at it.
[17:20] <cking> no probs
[18:29] <kamal> I have installed a custom DSDT.aml, but I find that CONFIG_ACPI_CUSTOM_DSDT is not enabled so kernel doesn't try to load it.  I think that this config param used to be called CONFIG_ACPI_CUSTOM_DSDT_INITRD and that it was enabled by default.  Is that correct?  Why is it no longer enabled by default?
[18:34] <cking> kamal, because people can seriously damage their H/W if they mess it up ;-)
[18:34] <kamal> cking: people like me, for instance!  ;-)
[18:34] <cking> maybe ;-)
[18:35] <kamal> cking: I'm about to try enabling it in the config here.
[18:36] <cking> no harm in trying I suppose
[18:39] <BenC> kamal: if the dsdt_initrd patch was not applied, you wont have any luck
[18:39] <BenC> kamal: you will need to compile your DSDT.aml into the kernel instead
[18:40] <BenC> kamal: CONFIG_ACPI_CUSTOM_DSDT_INITRD was not part of the upstream kernel, and was applied into the ubuntu kernel as an extra patch
[18:40]  * cking notes that BenC knows the history to this.
[18:41] <BenC> cking: I didn't know it was removed as an option to the ubuntu kernel until now though :)
[18:41] <kamal> BenC: ok -- that's where that config went!   I think I'd prefer to be able to install DSDT.aml into initrd if that's possible -- can I apply that patch to my Lucid kernel?  where can I find it? 
[18:42] <mjg59> kamal: Why do you have a custom DSDT?
[18:42] <kamal> mjg59: I'm working on a problem with Dell Studio laptops brightness control.
[18:42] <mjg59> Which model?
[18:43] <kamal> Dell Studio 1558.
[18:43] <cking> kamal, you need to see why the _BCM is being ignored - the AML looked sane to me at a first glance
[18:43] <kamal> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/568611
[18:43] <ubot3> Malone bug 568611 in linux "Screen brightness control fails on Dell Studio 1558" [Undecided,In progress] 
[18:46] <mjg59> Ha
[18:46] <mjg59> I bet it's because the _BQC is full of misery
[18:46] <kamal> cking: re: your email -- I'm not convinced that _BCM is in the right scope -- there is /not/ a _BCM method in the DD02 device, but there is a _BCL there.  Looking at a different laptop (completely different vendor) I do see _BCM and _BCL in the equivalent of the "DD02".
[18:47] <mjg59> Oh, that is interesting
[18:47] <kamal> mjg59: Yes, the _BQC is quite broken also, but I think that's a completely secondary problem!
[18:49] <cking> kamal, the _BQC does not appear to do much
[18:49] <kamal> So...  I think that 1. the _BCM is in the wrong place (matching acpica's "AE_NOT_FOUND").   I've constructed a DSDT.aml with it moved where I think it needs to be (and fixed, since its visibly bug-ridden).   I want to see if acpica no longer says AE_NOT_FOUND at least.
[18:49] <mjg59> kamal: Yeah, you get to build a new kernel in that cae
[18:49] <kamal> cking: yeah, the _BQC can't possibly be "correct" as it doesn't return any value.
[18:50]  * cking wonders if Dell QA's this code
[18:50] <mjg59> Interesting that it's Intel
[18:50] <kamal> mjg59: ok, no problem -- I'm happy to build a new kernel -- where do I stuff my hacked DSDT.aml?
[18:50] <cking> mjg59, why?
[18:50] <mjg59> Because, in theory, with the IGD opregion support you could avoid needing to call _BCM
[18:51] <mjg59> So I wonder whether the Intel driver for Windows ignores it
[18:51] <cking> mjg59, any info on where I can learn about the IGD opregion support?
[18:52] <kamal> mjg59: Looking at the _BCM code (the misplaced _BCM code mind you ;-) I don't think that it could possibly work anyway -- the code logic is just wrong.
[18:52] <kamal> mjg59: so that matches the idea that Windows doesn't actually use it.
[18:52] <cking> kamal, that sounds like a good theory
[18:52] <mjg59> http://intellinuxgraphics.org/OpRegion.html
[18:52] <cking> ta
[18:53] <mjg59> Would need to extend video.c to allow display drivers to register callbacks
[18:57] <cking> kamal, want to run with that^^
[18:58] <kamal> cking: run with what?...  extending video.c for opregion?   that sounds like a major project!
[18:59] <mjg59> The opregion spec is entirely implemented already
[18:59] <mjg59> Well. I say "entirely" - the bits that make any sense at all are
[19:00] <mjg59> Where i915.c currently does acpi_video_register() (or something like that), you want to be able to pass in some callbacks that will be used when the brightness is set or retrieved
[19:01] <mjg59> That does, of course, end up being predicated on the machine using opregion. What does lspci -s 02.0 -xxx give?
[19:02] <kamal> 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12)
[19:02] <kamal> ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
[19:02] <kamal> (with blocks of hex bytes below each)
[19:04] <mjg59> kamal: Sorry, should have been 00:02.0 - can you pastebin the hex?
[19:05] <kamal> mjg59: http://paste.ubuntu.com/427806/
[19:06] <kamal> mjg59: thanks very much for the help with this BTW
[19:07] <mjg59> kamal: Sorry, can you run that as root?
[19:07] <kamal> mjg59: http://paste.ubuntu.com/427808/
[19:08] <mjg59> Yeah, ok, that implements the opregion spec
[19:09] <cking-afk> mjg59, what specific magic shows that?
[19:10] <mjg59> cking-afk: fc-ff aren't 0
[19:10] <kamal> ok, so if I'm following, you're saying that we might be able to get working brightness controls by adding appropriate "opregion hooks" which can adjust the brightness levels without bothering with the _BCM method at all.   Yes?
[19:10] <mjg59> Right
[19:11] <kamal> Ok, I'll start reading that OpRegion spec then!
[19:11] <kamal> hmmm.  maybe I'll still try installing my hacked DSDT anyway, as a sanity check.
[19:12] <cking-afk> kamal, worth wiki'ng up once you reach OpRegion enlightenment
[19:12] <kamal> if-and-when ;-)  What little I understand about ACPI is just enough to get me in trouble, I fear.  ;-)
[19:12] <mjg59> kamal: Easiest is probably to take a look at the i915_opregion.c code rather than the spec
[19:13] <mjg59> The spec departs from reality in one or two cases
[19:13] <kamal> mjg59: ok, great, thanks for that tip
[19:20]  * JFo looks forward to the wikification of this particular section of kamal's brain :)
[19:21]  * pgraner notes JFo is lazy....
[19:21] <JFo> lazy indeed
[19:21] <JFo> so lazy... it just might work!
[19:22] <JFo> oh wait, that's 'crazy' ;-)
[19:23] <kamal> "The Wikification of Kamal's Brain" sounds to me like it would be a really bad Dr. Who episode or something.
[19:30] <ogasawara> apw: did we lose a commit in Lucid? - "UBUNTU: [Config] Add atl1c to nic-modules udeb"
[19:30] <ogasawara> apw: kernel-team ml thread was "Lucid pull request, SRU lp557130"
[19:49] <kees> we need to revert 5e1941884c700b7b97bcad52c2d8212ac56a7ebc it's causing more problems than it tries to solve.
[19:49] <kees> i.e. if any filesystem is under heavy load, you can't umount any other filesystems until the sync finishes.
[19:50] <ogasawara> kees: can you send us an email (kernel-team@lists.ubuntu.com) and I'll make sure it's on smb's radar to revert
[19:50] <kees> ogasawara: okay
[19:55] <baptistemm_> Heya, I'm back
[20:13] <baptistemm_> JFo, hi, what should I do with the bug related to kernel? should I tag them and reassigning to kernel?
[20:44] <manjo> baptistemm, what is the bug number ? 
[20:48] <baptistemm_> manjo, actually I continue a discussion I had previously with JFo, I have some bug report from bluetooth users about lack of support of their bt adapter (or regression)
[20:48] <baptistemm_> manjo, bug reports are 416487 and 572197
[20:54] <manjo> baptistemm_, this is a regression in Lucid ? 
[20:55] <manjo> baptistemm_, looks like the 2 the dups of each other ?
[20:56] <baptistemm_> manjo, 572197 yes, the other no
[20:57] <manjo> those looks like valid bugs that could be picked up by the kernel team
[20:57] <baptistemm_> manjo, so I should reassign to kernel ?
[20:57] <manjo> baptistemm_, let me see if I those models with me... I have a EEEPC here ... 
[20:57] <baptistemm_> hoo, wonderful
[20:58] <baptistemm_> I'm looking for people with bluetooth :)
[20:58] <manjo> I have a 1201N eeepc 
[20:59] <manjo> I will have a look at 416487
[21:00] <manjo> not sure if they have the same adapter though
[21:02] <manjo> baptistemm_, to me looks like both the bugs are the same problem... but I need to investigate 1st 
[21:05] <baptistemm_> manjo, they look like dups for me to, but as the usual was complaing I un-dupped them to have a 2nd look 
[21:06] <baptistemm_> s/usual/user/
[21:06] <manjo> yep leave them undupd for now 
[21:35] <vanhoof> ogasawara: got a quick sec to chat about the uds schedule?
[21:35] <ogasawara> vanhoof: sure
[21:35] <ogasawara> vanhoof: need anything moved?
[21:36] <vanhoof> ogasawara: nah, not moved, curious about signing up for events, specifically the two you mentioned in email
[21:36] <vanhoof> ogasawara: is it more of a 'just be there' kinda thing? :)
[21:36] <ogasawara> vanhoof: yah, for those two you just show up, no need to specifically sign yourself up
[21:36] <vanhoof> ogasawara: cool, just wanted to check
[21:37] <vanhoof> ogasawara: thanks!
[21:37] <baptistemm_> manjo, bug 507957 seems o be the same issue (eeepc again)
[21:37] <ubot3> Malone bug 507957 in gnome-bluetooth "applet doesn't run" [Low,Incomplete] https://launchpad.net/bugs/507957
[21:39] <manjo> baptistemm_, yes it does ... wonder of they load the omnibook module, will it do the trick ?
[21:39] <manjo> baptistemm_, I am upgrading my eeepc from alpha1 to release version now 
[21:41] <ogasawara> vanhoof: for one's which have actual blueprints, you can subscribe yourself to the blueprint and I believe the summit.ubuntu.com system will magically add you to the list of participants
[21:43] <manjo> baptistemm_, I have a Broadcom BT device and it is recognized by lucid
[21:45] <manjo> baptistemm_, the Bug #507957 does not have enough information.. and the reporter did not respond to previous questions, you could close that as invalid and add a comment saying they should use ubuntu-bug  to add more information to the bug and repeon if it needs to be looked at 
[21:45] <ubot3> Malone bug 507957 in gnome-bluetooth "applet doesn't run" [Low,Incomplete] https://launchpad.net/bugs/507957
[21:48] <baptistemm_> hmm, a new reporter about same problem but on other hardware type, bug ubuntu-bug
[21:48] <baptistemm_> hmm, a new reporter about same problem but on other hardware type, bug ubuntu-bug
[21:48] <baptistemm_> RR, excuse me, bug 575366
[21:48] <ubot3> Malone bug 575366 in bluez "10.04 on iMac 27" i7: "No Bluetooth adapters present"." [Undecided,New] https://launchpad.net/bugs/575366
[21:52] <manjo> baptistemm_, I added comments to all of them saying we need output of "sudo lsusb -v" 
[21:55] <lamont> so... if I'm root outside of a process, and I want to cause the (mostly paged out) process to be ram-resident, is there a trivial way to do that?
[21:55] <baptistemm_> manjo, okay thanks, so you didn't move them to linux-meta package?
[21:56] <manjo> baptistemm_, no I did not ... not sure .. you should check with JFo and see what he  thinks as well... 
[21:56] <baptistemm_> okay
[21:56] <manjo> baptistemm_, since you and him are working on it 
[22:20] <jjohansen> ogasawara: I don't think any of the blueprints I registered deserved a full session
[22:21] <jjohansen> ogasawara: I can't see use a pv-ops kernel taking more than 5 minutes
[22:21] <ogasawara> jjohansen: do you want to combine them into 1 catchall session?
[22:21] <jjohansen> sure
[22:22] <ogasawara> jjohansen: cool, I'll condense them into 1 slot
[22:23] <jjohansen> honestly if there are other things to go into a catch all they could go there
[22:23] <jjohansen> union mounts - is lets look at where they are and evaluate
[22:23] <jjohansen> AA could take maybe 10 min
[22:24] <manjo> jjohansen, you in AA? 
[22:24] <ogasawara> jjohansen: do you want to just use one of the round tables to discuss them? rather than even having an actual slot.
[22:24] <jjohansen> ogasawara: pv-ops and union mounts sure
[22:25] <jjohansen> AA I am not sure, but security also has a full AA session
[22:25] <ogasawara> jjohansen: yah, I noticed there was a security AA session but wasn't sure what would be discussed and if it'd overlap
[22:25] <jjohansen> some overlap
[22:25] <manjo> ogasawara, is there a session on suspend resume ? 
[22:26] <jjohansen> I think the kernel portion can be done mostly as a separate discussion
[22:26] <ogasawara> jjohansen: is the security AA session on monday? /me looks
[22:26] <jjohansen> just not sure how big to make it
[22:27] <jjohansen> ogasawara: yes
[22:27] <jjohansen> actually that one being early is good as it can feed into any kernel discussion later in the week
[22:27] <ogasawara> jjohansen: ok, so the security AA session is monday afternoon.  lets leave the kernel AA session for now in case we need it as an extension to what gets covered in Monday's session.
[22:27] <jjohansen> okay
[22:27] <ogasawara> jjohansen: I can always remove it from the schedule later if we don't need it.
[22:28] <jjohansen> sounds good
[22:28] <ogasawara> jjohansen: the pv-ops and union mounts i'll just remove and we'll use one of the morning round tables to go over them.
[22:28] <jjohansen> okay thanks
[22:29] <ogasawara> manjo: there isn't any specific suspend/resume session
[22:29] <baptistemm_> good night, thanks manjo
[22:30] <manjo> ogasawara, good 
[22:30] <manjo> ogasawara, thanks