[06:27] <adam_> hey I accidently deleted a folder under /usr/src
[06:27] <adam_> and I want to put it back
[06:27] <adam_> necessary for kernel development
[06:27] <adam_> ...
[06:28] <ohsix> dpkg -S /usr/src
[06:29] <adam_> thanks... I think that's almost there, but it didn't put the folders back
[06:29] <ohsix> that just gives you package names, you can reinstall the one you think was it
[06:30] <adam_> oh! man
[06:30] <adam_> I'm so dumb
[06:30] <adam_> I should have known that. thanks man
[07:18]  * apw yawns
[07:22]  * cking offers coffee to apw
[07:22]  * apw bites your hand off
[07:24] <cking> remind me never to offer apw coffee first thing when he's grouchy
[07:25] <cking> ;-)
[07:30] <apw> heh
[07:39] <apw> cking, i want to dump the comment section out of an elf binary, i'd like it just raw, suggestions as to what to use
[07:40] <cking> hrm, must be doable from objdump somehow, surely?
[07:41] <apw> cking, somewhat but it gives me <addy> <hex> <text wrapped every 8 characters>
[07:41] <apw> and i'd rather not reconstruct it by hand
[07:42] <cking>  readelf -p .comment a.out perhaps?
[07:46] <apw> cking, readelf is easier to decode i guess ... sigh
[07:49] <cking> sure, what are you doing to require this?
[07:49] <apw> cking, i want to know what compiler was used to build the .ko in my hand
[07:50] <apw> cking, as i want to check that all builds of a kernel were with the same compiler
[07:50] <apw> cking, without booting them
[07:50] <cking> ah, sanity checking. nice
[07:50] <apw> apw@dm$ readelf -p .comment /lib/modules/3.0.0-5-generic/kernel/fs/squashfs/squashfs.ko 
[07:50] <apw> String dump of section '.comment':
[07:50] <apw>   [     1]  GCC: (Ubuntu/Linaro 4.6.1-2ubuntu2) 4.6.1
[07:50] <apw>   [    2c]  GCC: (Ubuntu/Linaro 4.6.1-2ubuntu2) 4.6.1
[07:50] <apw>   [    57]  GCC: (Ubuntu/Linaro 4.6.1-2ubuntu2) 4.6.1
[07:50] <apw> so i think thats the nearest to a usable version string I have
[07:53] <ppisati> just upgraded: now skype is broken, oh crap...
[07:53] <apw> ppisati, nice
[07:55] <RAOF> ppisati: Probably missing some i386 libs if you're on amd64?
[07:55] <ppisati> RAOF: yep
[07:55] <ppisati> [flag@newluxor ~]$ skype
[07:55] <ppisati> skype: error while loading shared libraries: libXss.so.1: cannot open shared object file: No such file or directory
[07:56] <RAOF> ppisati: sudo apt-get install libxss1:i386; rinse and repeat until all the dependencies are satisfied.
[07:57] <ppisati> RAOF: thanks, i'll try
[07:58] <apw> RAOF, ahh is that multiarch finally coming into play 
[07:58] <RAOF> apw: Yup.  ia32-libs lost a lot of weight in the last upload.
[08:06] <apw> Fetching omap...extracting...GCC: (Ubuntu/Linaro 4.6.1-6ubuntu2) 4.6.1...done.
[08:06] <apw> Fetching generic...extracting...GCC: (Ubuntu/Linaro 4.6.1-6ubuntu3) 4.6.1...done.
[08:06] <apw> cking, omg, its caught one already
[08:07] <_ruben> ohh .. that multi-arch stuff looks fancy :)
[08:08] <cking> apw, how the heck does that happen?
[08:08] <apw> compiler building in parallel with the kernel, and slightly ahead
[08:09] <cking> gah
[08:09] <apw> clearly the armel compiler built later (which given the speed of the builders makes sense)
[08:10]  * cking --> dr appointment
[08:11] <smb> Some morning make you want go straight back to bed... Just had to sweettalk the raid to ignore one lying device...
[08:11] <apw> smb, ouch, how long before you have redundancy agian
[08:12] <smb> apw, approx 139min
[08:14] <apw> smb, and presumably its as slow as snot for the duration?
[08:14] <apw> WARNING: inconsistant compiler versions detected
[08:14] <apw> yay ... it works
[08:14] <smb> apw, its okayish as it only tries to do that in the background
[08:20] <smb> apw, Of course, when that is failing, the auto-rename of networking devices decides to fail as well. leaving you with a partially renamed one nobody likes... Ok, that was simpler to recover...
[08:21] <apw> what the heck did you do to this machine ?
[08:21] <apw> you did something odd like turning it on didn't you
[08:22]  * smb thinks it may be that odd turning off before...
[08:22] <apw> smb, does maint-get-abi use getabis at all
[08:23] <smb> apw, Some mornings that machine is like me, but unlike me it cannot be cured by coffee
[08:23] <smb> apw, no thinks its all re-implemented
[08:23] <apw> have you tried coffee on the machine?
[08:23] <apw> BAH now why would you do that
[08:24] <apw> now someone will have to add the same compiler checks to that ...
[08:24] <smb> apw, Because the previous implementation sucks. Isn't that the way it has to happen?
[08:24] <smb> apw, Besides getabis would not be easily converted to not do it locally
[08:24] <apw> well the sucking parts is that you have to run it locally, it runs remotly just fine, ie out of the tree
[08:25] <smb> apw, Wait, compiler checks...?
[08:25] <apw> smb, yes compiler checks, we have a WI to check the compiler, and doing that now, so i am fixing getabis
[08:25] <apw> as that is the only time you have all the information you need
[08:25] <apw> anyhow, maybe i'll fix maint-getabis to use getabis :)
[08:27] <smb> apw, argh, hopefully not fixing python by perl code... :-P
[08:27] <apw> sounds like a great idea to me
[08:27]  * smb slaps apw
[08:28] <smb> apw, But frankly where did that WI come from and what sense does it make to check any compiler for just getting abi information from built packages?
[08:28] <apw> smb, well the work item is to know if we have compiler skew in our builds
[08:29] <apw> and it just detected compiler skew in the latest oneiric stuff
[08:30] <apw> smb, how does maint-getabis know which flavuors exist
[08:31] <smb> apw, It checks the d-i information and has some internal blacklist to ignore stuff
[08:31] <apw> smb, GAH, you complain about the current implementation and me putting perl in it ... and then you have a shell script embedded in it!
[08:32]  * smb does not remember that...
[08:32] <smb> It has been a wile
[08:33] <smb> apw, So its probably not d-i but control.d
[08:33] <smb> the vars stuff I believe
[08:33] <apw> smb, and then another to extract it
[08:34] <apw> this is basically the bits of getabis from the scirpt all cut up... i am wondering why we don't just send the getabis script from the current tree and use that
[08:34] <smb> apw, Must have been that I just was learning python and had to do the job because I needed the money
[08:34] <apw> heh maybe
[08:35] <smb> apw, Maybe, though I am sure I just did not want to rely on variously broken or different implementations of getabi
[08:35] <smb> You know how things evolve and how happy the sru team can be about fixing that kind of things
[08:35] <apw> though with hindsight we should have fixed getabis
[08:37] <smb> apw, Probably. Cannot say for sure now but I may have written this when we tried convincing people that debian.master backports are a good thing. You may remember how well that went. And I wanted it to be working for all releases.
[08:47] <smb> apw, Would it be possible to have the check coded as its own script? Then we could at least call that from maint/build/*-getabis
[08:47] <smb> if present
[08:48]  * smb goes making coffee
[09:11] <ppisati> yeah, my usb mic is broken... :(
[09:12] <smb> ahh
[09:12] <ppisati> i mean, it works
[09:12] <ppisati> it's just that m installation is broken
[09:12] <ppisati> :(
[09:12] <ppisati> doh
[09:13] <smb> all I can hear is something that sounds like a water fountain
[09:13] <ppisati> that doesn't sound so good :)
[09:13] <smb> apw, and if you don't know what we are talking about your mumble is broken too. :)
[09:14] <smb> ppisati, I guess you heard me talking, though it would not surprise me today if my mumble was broken too
[09:14] <ppisati> smb: i head something (i had music in background)
[09:15] <smb> ppisati, So at least I make some noise...
[09:15] <smb> :)
[09:21] <illusec> Dear guys, what is deferences between ioctl and unlocked_ioctl in device driver programming, why ubuntu kernel doesn't support ioctl?
[09:21] <illusec> differences"
[09:24] <apw> illusec, as far as i know they are simply different APIs for ioctl, that they wanted to change the locking rules for ioctl handlers, so they added a new one and deprecated the old one
[09:24] <apw> it is still the place that ioctl calls from userspace go
[09:25] <illusec> aha, tnx
[09:26] <bjf> apw, my unity is fixed, seems my solid background color was breaking it
[09:26] <apw> bjf ... !
[09:26] <bjf> apw, this was helpful: https://wiki.ubuntu.com/Unity/FilingBugs#Getting_a_stack_trace
[09:26] <illusec> but i have a driver with ioctl, but when i change it to unlocked_ioctl for compile reasons the whole ioctls in source get me -1 ! 
[09:26] <apw> bjf, are you saying having your own background broke it
[09:27] <bjf> apw, now i have to make all my changes that were lost when i --reset
[09:27] <bjf> apw, yes
[09:27] <apw> do these guys test even the simplest things?
[09:27] <smb> bjf, Oh your unity --reset actually works?
[09:27] <bjf> smb, depends on your definition of "works"
[09:27] <smb> Mine bails with an error message and does nothing
[09:28] <bjf> now i'm trying to figure out where I set "focus follows mouse"
[09:28] <smb> That was at least yesterday
[09:28] <apw> bjf, is that in 'windows' control panel app
[09:29]  * smb thinks that was set in generic config of compiz
[09:30] <bjf> apw, can't find a 'windows' control panel app
[09:30] <apw> illusec, well the syscall ioctl calls do_vfs_ioctl which calls vfs_ioctl which calls unlocked_ioctl
[09:30] <bjf> apw, i'm looking at the "system settings" control panel
[09:30] <bjf> but i thought it was in CCSM somewhere
[09:30] <smb> bjf, I don't think it was in there
[09:30] <smb> bjf, Yeah either that one or the full blown
[09:31] <bjf> smb, "full blown" ?
[09:31] <smb> bjf, I thought there was some simple config bla and the otehr one
[09:31] <smb> I usually install the other one
[09:32] <smb> And last time I looked there was a generic config option in that one, in the first block of things
[09:34] <apw> bjf, its 'windows' application
[09:35] <bjf> apw, there is an application whose name is just "windows" ?
[09:37] <apw> hit the windows key and search for windows
[09:37] <apw> see if that is the one
[09:38] <bjf> apw, window == "super" ?
[09:41] <smb> bjf, just out of interest, you have the "normal" intel gfx card, right?
[09:41] <bjf> smb, yes, the i915
[09:42] <cjwatson> I'm horribly confused.  Why does ecryptfs seem to be a module in 3.0.0-8.11
[09:42] <cjwatson> ?
[09:42] <cjwatson> despite debian.master/config/config.common.ubuntu:1402:CONFIG_ECRYPT_FS=y
[09:43] <smb> bjf, Ok, so at least you won't be suffering the problem cking and I see where the whole gui seems to resist any of your actions
[09:43] <bjf> smb, i don't think i have that problem
[09:43] <apw> cjwatson, well what you ask for and what you get arn't always the same
[09:44] <apw> cjwatson, if they added a dependancy on something wich isn't a module it can ripple up
[09:44] <cjwatson> I have a d-i bug due to this - can I lob it over to the kernel and let you guys figure it out?
[09:44] <apw> cjwatson, yes
[09:45] <apw> cjwatson, whats the number
[09:45] <cjwatson> cool, thanks, it's bug 827197
[09:45] <ubot2> Launchpad bug 827197 in user-setup "/usr/bin/ecryptfs-setup-private fails with exit status 1 during install - User's home directory not encrypted" [High,Triaged] https://launchpad.net/bugs/827197
[09:45] <cjwatson> thrown your way now
[09:56] <bjf> apw, finally found it, it's in CCSM "general options"
[09:57] <apw> bjf, sadly it is not sloppy focus
[10:08]  * smb -> reboot after resync
[10:09] <apw> bjf have you found a way to get sloppy focus rather than just follows mouse ?
[10:11] <bjf> apw, not sure while i'm typing this my mouse pointer is not in the xchat window but over the desktop
[10:11] <bjf> and now over the launcher
[10:14] <apw> ok my test is " open two overlapping windows, cursor in the one behind, alt-tab to the other window (cursor is now not in the new window but still in the old), where is focus
[10:14] <apw> under sloppy it would be in the new alt-tabbed to window
[10:15] <bjf> hmm, seems to be working that way for me, alt-tab to xchat, mouse still over terminal window behind while i type this
[10:16] <apw> so what are you doing different
[10:16] <apw> you just flipped that one ticky in ccsm ?
[10:16] <apw> oh you are on oneiric, they may have fixed it there
[10:16] <apw> DOH test on the same platform wally
[10:17] <bjf> heh, yes
[10:18] <apw> yeah they have fixed it on oneiric, so i can switch back if i upgrade ... oh the joy of that choice
[11:16] <apw> ogasawara, i've just pushed a fix to bug #827197 to the oneiric tree, this is affecting the installer so needs to be in for beta-1
[11:16] <ubot2> Launchpad bug 827197 in linux "/usr/bin/ecryptfs-setup-private fails with exit status 1 during install - User's home directory not encrypted" [High,Fix committed] https://launchpad.net/bugs/827197
[11:16] <apw> cjwatson, ^^
[11:57]  * ppisati -> lunch
[12:48] <ogasawara> apw: ack
[13:03] <herton> smb: prepare-package should be fix released (bug 829162), fixed that, just minor thing
[13:03] <ubot2> Launchpad bug 829162 in linux-ec2 "linux-ec2: 2.6.32-318.37 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/829162
[13:03] <smb> herton, Ah, darn. Ok, next time then
[13:04] <smb> herton, note that you might need to fetch --tags because I reused the previous (unreleased/unused) version
[13:04] <herton> ok
[13:35] <cjwatson> apw: ta
[13:47]  * ogasawara back in 20
[14:27] <ogasawara> kees: if you get me that updated seccomp pull request by noon-ish, I'll throw it into our Beta-1 upload that I plan to do by EOD
[14:32] <illusec> where is ubuntu's kernel changelog?
[14:33] <illusec> and list of all patches and etc
[14:36] <ppisati> herton: while trying to close a tracking bug
[14:36] <ppisati> herton: 
[14:36] <ppisati> herton: http://pastebin.ubuntu.com/670124/
[14:37] <tgardner> ogasawara, you need to add an ignore.modules
[14:38] <smb> illusec, The changelog you will find either in the git repo under debian.master/changelog or on launchpad (https://launchpad.net/ubuntu/+source/linux/+publishinghistory)
[14:38] <illusec> smb, thanks in advance
[14:39] <herton> ppisati: I think you need to add this ppa: sudo apt-add-repository ppa:arsenal-devel/ppa
[14:39] <herton> ppisati: then update to latest lpltk
[14:41] <herton> (python-launchpadlib-toolkit)
[14:42] <kees> ogasawara: okay, cool
[14:42] <ogasawara> tgardner: ack, will do
[14:48] <ppisati> herton: uhmm... what's the exact name of the pkg i need?
[14:48] <herton> ppisati: python-launchpadlib-toolkit
[14:49] <sconklin> smb, Sarvatt: Looks like we have an i915 regression in Lucid -proposed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/828550
[14:49] <ubot2> Ubuntu bug 828550 in linux "kernel BUG at /build/buildd/linux-2.6.32/drivers/gpu/drm/i915/i915_gem_evict.c:183!" [Undecided,Confirmed]
[14:51] <ppisati> herton: it worked, thanks :)
[14:51] <herton> cool
[14:52] <ppisati> apw: what did it happen to the CVE matrix on people/~apw/cve/...?
[14:52] <apw> ppisati, s/apw/kernel
[14:52] <ppisati> herton: is it normal that it changed the bug title to "Ignore this bug"?
[14:52] <bjf> ppisati, http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
[14:53] <ppisati> ok, no need fo any rebase then
[14:54] <herton> ppisati: yes. I think fsl-imx51 needs to have the released closed no and uploaded no?
[14:55] <ppisati> herton: both mvl-dove and fsl-imx51, i'm --invalidate-ing the tracking bugs
[14:55] <ppisati> ok, did for both
[14:55] <herton> ppisati: ok, so please don't invalidate
[14:55] <smb> sconklin, Hm ok. Ithink there was a large patchset to fix another nasty lockup...
[14:55] <ppisati> doh
[14:55] <ppisati> herton: just did...
[14:55] <herton> ppisati: ok, I'll fix here, wait a sec
[14:55] <ppisati> herton: ok, so what do i have to do in case there's no need for ny uploaD?
[14:55] <herton> ppisati: you just invalidate when there is nothing to upload release
[14:55] <sconklin> smb: yes, there were a number of patches. I just wanted you to be aware. As soon as we get a known good version from the reporter we can start bisecting
[14:55] <ppisati> herton: wait
[14:56] <ppisati> herton: that's the situation, nothing to do
[14:56] <ppisati> herton: aka i've notjing new to push
[14:56] <herton> ppisati: hmm ok. but isn't there anything new in the branches that should be uploaded?
[14:57] <ppisati> herton: nope
[14:57] <smb> sconklin, Yeah. Actually it seems the file where the bug occurs was created for fixes for http://bugs.launchpad.net/bugs/599017 http://bugs.launchpad.net/bugs/807508
[14:57] <ubot2> Ubuntu bug 599017 in linux "[gm45] Xorg freeze on Firefox on one particular page" [High,Fix committed]
[14:57] <herton> ppisati: ah ok, that's fine then
[14:57] <ppisati> herton: ok, done then
[14:57] <ppisati> herton: anything else i've to do?
[14:57] <herton> ppisati: nope
[14:57] <ppisati> ok
[14:59] <apw> herton, i think this bug here is actually fixed by the fix for the CVE crasher: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/828465
[14:59] <ubot2> Ubuntu bug 828465 in linux "Kernel OOPS while running Chrome: BUG: unable to handle kernel paging request at fffffff3" [Undecided,Confirmed]
[14:59] <apw> so if you had a bug for that this should be a dup of it
[15:00] <herton> apw: correct, let me see here, I think there was another bug opened
[15:00] <apw> http://bugs.launchpad.net/bugs/813026 perhaps
[15:00] <ubot2> Ubuntu bug 813026 in linux-ti-omap4 "CVE-2011-1020" [Low,Fix committed]
[15:01] <apw> oh hrm no thats the cve bug itself
[15:01] <smb> sforshee, So maybe you are interested in that bug above in some way... ;)
[15:03] <herton> apw: we can duplicate it against bug 827198, though this one is nominated for maverick only, not lucid (which 828465 is for)
[15:03] <ubot2> Launchpad bug 827198 in linux "Kernel update google Chrome and Chromium freeze" [Undecided,In progress] https://launchpad.net/bugs/827198
[15:03] <sforshee> smb, yes
[15:03] <apw> herton, so if i nominate 827198 for lucid too does that make more sense
[15:04] <herton> apw: yep
[15:04] <apw> herton, nom done
[15:05] <herton> apw: thanks, marked 828465 as a duplicate
[15:05] <smb> sforshee, Hm, interestingly the BUG_ON that is hit was removed by e39a01501b228e1be2037d5bddccae2a820af902
[15:06] <apw> http://status.ubuntu.com/ubuntu-oneiric/group/topic-oneiric-kernel-tasks.html
[15:07] <sforshee> smb, I'm still trying to catch up on the issue -- which commit is causing the regression?
[15:08] <smb> sforshee, Well I guess it is multiple which were part of the fix for that hang which could be triggered through firefox
[15:08] <ogasawara> sconklin: http://people.canonical.com/~platform/workitems/oneiric/u/sconklin-ubuntu-11.10-beta-1.html
[15:08] <smb> sforshee, You should be able to search for one of the bugnumbers I posted
[15:18]  * tgardner relocates. back on in a bit.
[15:20]  * smb decides to retire for this week. back next one :)
[15:25] <apw> smb, have fun
[15:36] <herton> ppisati: shouldn't fsl-imx51 have an update? there were changes (cve fixes) since Ubuntu-2.6.31-609.26 in -updates. also mvl-dove should be rebased
[15:36] <herton> I was checking it here now
[15:41] <ppisati> herton: not by me, at least
[15:41] <ppisati> herton: come back tuesday and i didn't commit anything, so...
[15:41] <ppisati> herton: perhas someone else have fixes and their tree, but i'm unaware
[15:42] <ppisati> s/and/in/
[15:42] <ppisati> (bloody usb keyboard)
[15:42] <herton> ppisati: ok, then you have something to do. if there are changes on the branch since latest fsl-imx51 that got uploaded, then I expected that you closed a new released and pushed, so I can prepare a new source package and upload
[15:42] <apw> fsl-imx51 is a raw tree so its not rebased, it has stuff on it ready i suspect so needs closing out; but herton you guys close them yes
[15:43] <herton> apw: hmm, so should I close? I thought ppisati did the same as stefan
[15:45] <apw> herton, i don't really care who closes it, when we talked about the process i am pretty sure sconklin said he wanted to close things as you had process and scripting in place to get it right
[15:45] <apw> sconklin, ??
[15:46] <sconklin> reading back
[15:47] <herton> the way I thought would be, is that we open a tracking bug for ppisati, without the package version. ppisati checks and closes the release in the branch if there were changes from the last package pushed in updates, or if a rebase is needed. then he updates the tracking bug with the package version, sets prepare-package to fix released. Then I or sconkling prepare the src pkg and upload
[15:47] <sforshee> sconklin, herton, smb: I chatted with Chris Wilson about the BUG_ON from bug 828550. He said it was just paranoia, never actually necessary, and in any case not something the kernel should explode on. So we could try removing it and see if any issues remain with the BUG_ON removed.
[15:47] <ubot2> Launchpad bug 828550 in linux "kernel BUG at /build/buildd/linux-2.6.32/drivers/gpu/drm/i915/i915_gem_evict.c:183!" [Undecided,Incomplete] https://launchpad.net/bugs/828550
[15:48] <apw> sforshee, what fun
[15:48] <sforshee> I hope we can avoid reverting the fair lru eviction patches, as they fix a pretty severe problem (full-on X hang)
[15:49] <sconklin> apw, herton: my memory matches what herton just described
[15:49] <sforshee> If that's agreeable to you guys I can make a test build
[15:49] <apw> sconklin, ok then cool
[15:49] <apw> ppisati, either way the mvl-dove branch needs a rebase i suspect
[15:49] <sconklin> sforshee: I'd be tickled if you just run with this and ask the reporter to test
[15:49] <sforshee> sconklin, all right, I'm on it :)
[15:50] <apw> sconklin, now the copy branches do you do those or do we
[15:50] <apw> i presume we do those too
[15:50] <apw> but you do the lts-backport-xxx yes ?
[15:51] <ppisati> apw: really? actually there are no open cve in mvl-dove that were closed in master
[15:51] <ppisati> anyway, i rebase
[15:51] <mjg59> kirkland: http://fedoraproject.org/wiki/Features/Matahari is what I mentioned yesterday
[15:51] <sconklin> apw: yes, I think that is what was intended to be accomplished by creating the tracking bugs for derived packages, and assiging them to various teams or people. Maybe we don't have that right yet
[15:52] <apw> ppisati, right but there are general updates which it will get if rebased, stable updates etc yes ?
[15:52] <ppisati> ok
[15:52] <apw> a
[15:52] <ppisati> so, a rebase is coming
[15:52] <sconklin> typically, someone else prepares the lts-backport-xxx kernal and tags it (coughTim) and we package it, I think
[15:53] <apw> sconklin, ok if you arn't doing them then we need shankbot to make derivative branch bugs for them too no ?
[15:53] <apw> sconklin, t
[15:53] <herton> sconklin: hmm, I thought were doing now the lts-backport-*, I did the last maverick backport
[15:53] <apw> they are just a script and upload
[15:53] <sconklin> ok, if herton did it, then they are ours
[15:53] <sconklin> yeah they are easy
[15:53] <ppisati> git branc
[15:53] <ppisati> ops
[15:54] <apw> git: did you mean
[15:54] <apw>  git branch
[15:54] <ppisati> :)
[15:54] <apw>  git remove-all-my-files
[15:54] <apw>  git fall-over-in-a-heap
[15:54] <apw> git: chosing git-remove-all-my-files -- hope i got it right
[15:54] <herton> ppisati: so I'm reopening/fixing your tracking bugs, so you can update them when finished
[15:54] <ppisati> herton: k
[15:55] <ppisati> herton: so, i rebase mvl-dove and where do i put it? zinc?
[15:56] <apw> ppisati, i'd say push it to zinc and put the pull request in the bug
[15:56] <herton> yep, works for us
[15:56] <ppisati> in the tracking bug?
[15:56] <ppisati> ok
[16:05] <ppisati> ok, rebase done, is compiling now
[16:05] <ppisati> ill be back in a bit
[16:07] <herton> ppisati: fixed tracking bugs. when you're ready, you can comment on them, and set prepare-package to fix released (also update the bug title with the version of the closed release)
[16:07] <herton> bbl, lunch here
[16:10] <herton_> ppisati: fixed tracking bugs. when you're ready, you can comment on them, and set prepare-package to fix released (also update the bug title with the version of the closed release)
[16:11]  * herton_ -> lunch
[16:12] <diwic> hey you git experts
[16:12] <apw> diwic, s'up
[16:12] <diwic> I'm trying to run "git blame" on something, and what I get is a whitespace change 
[16:12] <diwic> for the line I'm interested in.
[16:13] <apw> ok
[16:13] <apw> so perhaps git blame <whitspace committish>^ -- <filename>
[16:13] <diwic> how do I continue, i e "git blame" for the version of the file that was before the whitespace change?
[16:13] <apw> and get a history at that point instead
[16:13] <apw> note the ^
[16:14] <diwic> apw, hey, we could do jeopardy, you come up with the answer before I even ask the question!
[16:14] <apw> heheh
[16:14] <apw> let me know if it doens't wor
[16:14] <apw> work
[16:15] <diwic> it did, many thanks
[17:07] <kirkland> mjg59: aha, thanks, reading now
[18:00] <ppisati> herton: ok, should be done
[18:00] <ppisati> herton: tell me if it's ok, i'll prepare dinner in the mean time
[18:00] <herton> ppisati: ack
[18:11] <herton> ppisati: at mvl-dove, it's missing a * Release Tracking Bug:... entry in the changelog, with the tracking bug number opened
[18:12] <ppisati> herton: hold on
[18:17] <ppisati> herton: does it go in debian/changelog or debian.mvl-dove/changelog? or both?
[18:17] <herton> ppisati: only in debian.mvl-dove/changelog
[18:18] <ppisati> herton: ok, see if it's ok
[18:20] <herton> ppisati: looks good now
[18:21] <ppisati> cool
[18:21] <herton> ppisati: oops, noted a problem
[18:21]  * ppisati finally bails out for the weekend :)
[18:21] <herton> ppisati: you used the maverick mvl-dove bug, that was recently opened. It's confusing right now, since we have mvl-dove on lucid and maverick
[18:21] <ppisati> doh!
[18:22] <ppisati> crap
[18:22] <ppisati> ok, let me fix it
[18:23] <herton> we have two bugs, for now check the tag or nomination to see which is which. I think may be shank bot could add a comment there, when opening the tracking bug, to make things more clear (eg. saying from which maverick or lucid release it opened the tracking bug)
[18:26] <ppisati> herton: ok, repushed to zinc pointing to the lucid mvl-dove tracking bug
[18:27] <ppisati> herton: in the maverick bug, i deleted the name/version and reverted "prepare package" to New
[18:27] <ppisati> unfortunaely i can't delete my comment "please reset HEAD ..."
[18:27] <ppisati> i'll add anither comment down there
[18:27] <ppisati> saying to ignore my pull request
[18:27] <herton> ppisati: hehe np, it's ok now both, thanks. about fsl-imx51, will you close the release later, or do you wish that I do it?
[18:28] <ppisati> i can close it now if you want, i mean, --invalidate it
[18:28] <ppisati> the same could be done for omap4
[18:48] <herton> ppisati: seems a netsplit here. about fsl-imx51 we shouldn't invalidate it, we must release, there are unreleased cve fixes in the branch, but that can wait, no need for you to verify now
[19:47]  * jjohansen -> lunch
[19:50] <pedahzur> Don't know if this is directly kernel related (feel free to direct to the appropriate place), but: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/829696
[19:50] <ubot2> Ubuntu bug 829696 in linux-firmware "Upgrading to version 1.52.1 breaks broadcom b43 driver" [Undecided,New]
[21:35] <kees> hm, bug 825207
[21:35] <ubot2> Launchpad bug 825207 in linux "gnome-system-monitor fails to launch with latest kernel upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/825207
[22:22] <jjohansen> rebooting