[00:45] <lamont> who knows swraid enough to tell me if a RAID built on i386 can be used on amd64?
[06:44] <ppisati> moin
=== smb` is now known as smb
[07:36] <smb> moin
[07:43] <smb> lamont, In theory I would be disappointed to the point of grabbing pitch fork and torch to visit some developers if not. Practically one never knows. But should be easy to verify with some test-vms. 
[07:43] <ppisati> bah
[07:43] <ppisati> mail.google.com doesn't work for me this morning
[07:43] <ppisati> 'You cannot perform this step unless you first disable OpenID on your account.'
[07:43] <ppisati> then you click on 'disaple OpenID', but nothing changes
[07:44] <ppisati> TGIF
[07:44] <smb> ppisati, That was one of the reasons I took the delay of migration as a chance to put myself on opt-no
[07:44] <ppisati> :(
[07:44] <ppisati> can't check my personal email now
[07:44] <ppisati> ufff
[07:45] <smb> Hm, seems to arrive on the phone for me still
[07:45] <smb> at least the spam
[07:45] <ppisati> maybe if i delete some cookies, cache, bookmarks, the entire internet, etcetc
[07:45] <ppisati> no no
[07:45] <ppisati> it works
[07:45] <ppisati> it's just the web mail that is borked
[07:45] <smb> ppisati, You are sure you have logged out of the Canonical google account
[07:45] <ppisati> smb: i can't
[07:46] <ppisati> smb: there's no logout thing
[07:46] <ppisati> wait
[07:46] <smb> ?
[07:46] <ppisati> the 'logout' click to link
[07:46] <ppisati> wasn't there
[07:46] <ppisati> and if access any google service (e.g. finance)
[07:46] <ppisati> it say 'Sign in'
[07:46] <ppisati> so i'm logged in ATM
[07:47] <ppisati> *i'm not
[07:47] <ppisati> ok
[07:47] <ppisati> ah
[07:48] <ppisati> ok, going trhough ww..google.com
[07:48] <ppisati> www
[07:48] <ppisati> i saw i was still logged in as *canonical
[07:48] <ppisati> and switching account didn't work
[07:48] <ppisati> i first had to logout
[07:49] <ppisati> and then relogin with my private account
[07:50] <smb> yeah, that sounds like my experience. I usually go to either main google page or g+ and log-out-in to switch
[07:50] <ppisati> account switching usually worked
[07:52] <smb> maybe a "feature" of migration
[09:12] <brendand> henrix, hi - i see the certification-testing task was marked Invalid for Lucid
[09:13] <henrix> brendand: hmm, ok. so the bot hasn't been fixed yet. can you please fix it manually?
[09:13] <henrix> brendand: i'll go fix the bot for next cycle
[09:13] <brendand> henrix, it seems we might be too late?
[09:14] <henrix> brendand: to be honest, i don't actually know in which fase of the sru we are currently... sconklin is driving this cycle
[09:14] <brendand> henrix, already in -updates
[09:14] <henrix> brendand: oh
[09:14] <henrix> brendand: ouch
[09:15] <henrix> bjf: ^
[09:37] <henrix> brendand: the cert task creation for lucid kernels has been explicitly removed from our scripts due to comment #9 in bug #1095350
[09:37] <ubot2> Launchpad bug 1095350 in linux (Ubuntu Lucid) "linux: 2.6.32-45.102 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/1095350
[09:38] <brendand> henrix, yeah - that changed later on though
[09:38] <henrix> brendand: ok, i'll revert that then
[09:39] <brendand> henrix, anyone it's not a huge problem, let's just get it reverted and we'll resume testing from next cycle
[09:39] <henrix> brendand: ack, will do. thanks
[12:56] <rtg> ogasawara, we need to develop a firmware delivery mechanism for Precise LBM. cw-3.6+ and up have support for wifi drivers that also need new firmware.
[13:05] <arges> tjaalton: hi
[13:06] <rtg> ogasawara, FYI - I'm updating your patch in bug #1068751 that never got applied for some reason.
[13:06] <ubot2> Launchpad bug 1068751 in linux-backports-modules-3.2.0 (Ubuntu Precise) "Add Conflicts: for compat-wireless stacks" [Medium,In progress] https://launchpad.net/bugs/1068751
[13:07] <ogasawara> rtg: ack and ack
[13:07] <tjaalton> arges: hey
[13:08] <arges> tjaalton: re: bug 1157678. I have the patch already there, and I thought bryce had put it into the xserver-xorg-video-intel.git tree
[13:08] <ubot2> Launchpad bug 1157678 in xserver-xorg-video-intel (Ubuntu) "[ffe] unplugging an external monitor from laptop results in corrupted screen. Logging out fixes it." [Medium,Fix committed] https://launchpad.net/bugs/1157678
[13:08] <tjaalton> arges: he didn't push anything
[13:08] <tjaalton> -0ubuntu2 is the latest on git
[13:08] <arges> tjaalton: so you are pushing it into the ubuntu package as an FFE for raring?
[13:09] <tjaalton> arges: if bryce doesn't beat me to it, yes
[13:09] <tjaalton> doesn't matter who pushes the button
[13:09] <arges> tjaalton: ok. I'm not entirely sure about the procedures for X stuff, so as long as it gets fixed
[13:09] <tjaalton> right
[13:10] <arges> cool thanks
[13:30]  * henrix -> back in 20
[14:08] <bjf> henrix, ack
[14:08] <bjf> brendand, you an still test kernels that are in -updates, no?
[14:10] <brendand> bjf, we can if you'd like. testing can't start until monday though because our lab engineer is in Portland for the OpenStack summit
[14:11] <bjf> brendand, more testing es never a bad thing
[14:15] <bjf> breandan, that statement is kind of confusing. you only have 1 person that can do the testing and he can't kick the jobs off remotely?
[14:22] <bjf> brendand, next week is testing week anyway
[14:27] <brendand> bjf, well we can do 80% of it remotely. there are a couple of systems that won't obey a wakealarm so need a push to resume from suspend
[14:27] <bjf> brendand, like i was saying, next week will be fine. if you find anything just let us know.
[15:24] <ogasawara> ppisati: I've probably missed hearing of any updates, but have we gotten any feedback for the nexus7 kernel from the X guys about the touchscreen issue?
[15:26] <ppisati> ogasawara: no updates so far
[15:28] <ogasawara> ppisati: do we have an eta?  maybe we should just upload, it'll really force the issue then (or confirm nothing else needs to be done).
[15:29] <ppisati> ogasawara: i agree
[15:29] <ppisati> tjaalton: ^
[15:29] <tjaalton> it's not a kernel issue
[15:30] <tjaalton> um, what issue? :)
[15:30] <ppisati> tjaalton: we are carrying a patch in our nexus7 tree
[15:30] <tjaalton> ok
[15:30] <ppisati> tjaalton: to make X (and the desktop img) work with  the touch screen
[15:30] <tjaalton> oh just that, ok
[15:31] <ppisati> tjaalton: the problem is that the same exact kernel has a broken touchscreen when used on the touch img
[15:31] <ppisati> tjaalton: and that touchscreen patch is the culprit
[15:31] <tjaalton> ah
[15:31] <ppisati> tjaalton: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-nexus7.git;a=commit;h=58245f54a897f928a6c86f30a599b461e96cd23a
[15:31] <ppisati> tjaalton: it's the bad patch (but we need it for the desktop img)
[15:32] <tjaalton> I guess you want jani then
[15:32] <tjaalton> hmm
[15:34] <ppisati> tjaalton: ogra told me you were working on a fix
[15:34] <ppisati> ogra_: ^
[15:34] <tjaalton> not the same thing
[15:35] <tjaalton> that's the touch grab hang bug
[15:35] <ogra_> ppisati, only jani can tell 
[15:35] <tjaalton> on X
[15:35] <ogra_> and yeah, different issues
[15:35] <ogra_> i think the patch from jani simply makes X aware of the device 
[15:35] <ogra_> turning it into an ev dev
[15:36] <tjaalton> right
[15:36] <ev> o/ ;)
[15:36] <ppisati> ok so,. 2 questions:
[15:36] <ppisati> 1) if we upload, do touch img get atutomatically it?
[15:36] <ppisati> 2) is there a way to distinguish i'm running in an android env?
[15:37] <ogra_> not easily since the android definition is just in the process of completely being changed 
[15:37] <ogra_> and in the end the andripd bits will likely run *in* ubuntu
[15:38] <ogra_> ppisati, waht touch image do you refer to with 1)
[15:38] <ppisati> ogra_: really? yesterday i heard a completely opposite story
[15:38] <ppisati> ogra_: the phablet nexus7
[15:38] <ogra_> i think rsalveti was working on something that pulls the binaries into the image build, yeah
[15:39] <ogra_> ppisati, for now we will start with an android container ... but i belive the whole set of android bits will eventually just end up in packages in the normal system
[15:39] <ogra_> i think the final implementation will only be decided at the sprint though
[15:40] <ogra_> its all in flux
[15:41] <ogra_> ppisati, what did you hear yesterday ?
[15:41] <ogra_> :)
[15:41] <ppisati> ogra_: that we weren't switching containers
[15:41] <ogra_> right, thats the first step
[15:42] <ppisati> ogasawara: anyhow, it seems we cannot upload because it would break the touch img
[15:42] <ogra_> but the android linker uses  its completely own path ... so in the end having the bits just packaged and installed as normal debs will be easier
[15:42] <ppisati> ogasawara: i'll try to come up with a patch to make it work in both worlds
[15:42] <ogasawara> ppisati: ack
[15:43] <ogra_> ppisati, if you could make it check for the android gadget being enabled and make it use the patch only if that isnt, i guess that could be a good distinction
[15:44] <ppisati> ogra_: that's what i wanted to do: if (!$android) touch_patch(); 
[15:44] <ogra_> the phablet image needs adb, adb needs the android gadget ... while the desktop image is completely built around the compositre gadget 
[15:44] <ogra_> err, wait ... 
[15:45] <ogra_> do you actually apply two differnt configs  and build two different binaries ?
[15:45] <ogra_> dekstop *needs* g_composite builtin ... while phablet *needs* g_android
[15:45] <ppisati> ogra_: builtin? no modules?
[15:45] <ogra_> i guess there are a good bunch of other options the different systems need set/unset
[15:45] <ogra_> builtin, yeah
[15:46] <ppisati> ogra_: to get a system running with wifi/usb/screen/etcetc not that much
[15:46] <ogra_> well, g_android could be a module but it wouldnt load if g_composite is builtin
[15:46] <ogra_> and g_composite or g_serial builtin is essential atm 
[15:47] <ogra_> we need some access to the initrd to make the container flip work ... currently i'm actually abusing the desktop kernel for this
[15:47] <rsalveti> ogra_: ppisati: the mako related patch should land today
[15:47] <rsalveti> and with that it'll grab the kernel automatically from the archive
[15:47] <ogra_> yeah, mak is fine
[15:47] <ogra_> grouper isnt 
[15:47] <rsalveti> same will happen with nexus 7 once we get a blessed kernel
[15:47] <ogra_> rsalveti, thats the problem 
[15:47] <rsalveti> and so on
[15:47] <rsalveti> ogra_: why?
[15:48] <ogra_> we need quite different config options for both images
[15:48] <rsalveti> not necessarily
[15:48] <ppisati> ogra_: i unserstand we need g_android in phablet, but i don't understand we need g_composite in desktop
[15:48] <ppisati> *understand
[15:48] <ppisati> *why we
[15:48] <ppisati> etcetc
[15:49] <ogra_> we have quite some users depending on it, using it to access the initrd etc 
[15:49] <ppisati> ogra_: ?
[15:50] <ppisati> ogra_: what you mean? i probably never used this feature
[15:50] <ogra_> it provides net access and serial access 
[15:50] <rsalveti> but they are modules, not sure if they exclude each other
[15:50] <rsalveti> do we need them built-in?
[15:50] <ogra_> in fact i'm just working with ChickenCutlass on the container flip completely depending on exactly that feature
[15:51] <ogra_> rsalveti, for initrd access we do
[15:51] <rsalveti> why?
[15:51] <rsalveti> we could get the module inside initrd 
[15:51] <ogra_> the initrd cant carry a single module ... 
[15:51] <ogra_> it gets to bg for the boot partition
[15:51] <ogra_> we have only a few bytes free 
[15:51] <rsalveti> why? how large is the boot partition?
[15:52] <ogra_> 8M ...
[15:52] <rsalveti> right, wonder why the kernel is so big for nexus 7
[15:52] <ogra_> the kernel is  around 5
[15:52] <ogra_> no idea
[15:52] <ogra_> i didnt make the config 
[15:52] <rsalveti> that can probably be fixed 
[15:52] <rsalveti> but I'd like to have them in modules and fix whatever uses it to load that at runtime
[15:53] <ogra_> iirc rtg looked into that a while ago
[15:53] <ogra_> or apw ... i dont remeber whom i talked to 
[15:53] <ogra_> its really a while agio
[15:53] <rtg> ogra_, apw was doing the config review
[15:53] <ogra_> cant we just wait a week and start using the grouper kernel with S ?
[15:54] <ogra_> ripping out features a week before release doesnt seem sane 
[15:55] <ppisati> ogra_: are these workitems still valid for S?
[15:55] <ogra_> especially in the light that we have a hard frozen archive since yesterday
[15:56] <ogra_> ppisati, workitems are nowadays on a monthly base :)
[15:56] <ogra_> so yes, sure
[15:56] <ogra_> i'll happily even drop the desktop n7 image in S 
[15:56] <rsalveti> ogra_: we can wait S, for sure
[15:56] <ogra_> so we dont have that issue at all anymore
[15:56] <ppisati> ogra_: do you mind collecting all of them (touchscree patch, usb config $g_things, kernel size, etcetc) in a blueprint?
[15:57] <ppisati> ah, if we want to drop the desktop img then...
[15:57] <ogra_> ppisati, well, how about we hold back for a week and just let the desktop image die (or leave it up to the users to live with the changes/breakages)
[15:58] <apw> ogra_, cirtianly it was me doing configuration reviews.  there i was basically not moving anything y->m
[15:58] <apw> and therefore the kernel was still fat for android, which doesn't load modules
[15:59] <ppisati> Ubuntu's archive are more hostile than the Death Valley, you can get easily killed if no one cares for you
[15:59] <ppisati> and that being said...
[15:59]  * ppisati -> workout -> beer -> chinese food -> evening -> EOW
[16:09]  * smb skips the workout and chinese food
[16:12] <jsalisbury> smb, no hurry, but when you have a chance, can you review bug 1168350  There is a fix available, but it seems fairly large to be considered for SRU
[16:12] <ubot2> Launchpad bug 1168350 in linux (Ubuntu Precise) " arch_trigger_all_cpu_backtrace() results in Oops on virtualized guest" [Medium,Confirmed] https://launchpad.net/bugs/1168350
[16:14] <smb> jsalisbury, I think I heard about that in the past, but back then the proposed changes were not even upstream
[16:15] <jsalisbury> smb, they are upstream now in commit f447d56
[16:16] <smb> jsalisbury, Hm that seems to be one. Somehow I thought to remember two or even three
[16:17] <smb> anyway, will maybe put that off to next week
[16:17] <jsalisbury> smb, sounds good.  thanks for looking.
[16:17] <jsalisbury> smb, oh and pass some of that Chinese food over here ;-)
[16:17] <smb> jsalisbury, Thats ppisati, not me
[16:17] <smb> :)
[16:18] <jsalisbury> :)
[16:26] <jsalisbury> rtg, apw if you have a chance, can you take a look at bug 1170150
[16:26] <ubot2> Launchpad bug 1170150 in linux (Ubuntu) "vmlinuz/initrd.img symlinks do not point to signed versions on kernel updates of secure boot UEFI machines" [Medium,Confirmed] https://launchpad.net/bugs/1170150
[16:29] <rtg> jsalisbury, hmm, I'm having a hard time caring about that one. I guess I'm not groking the real problem.
[16:33] <jsalisbury> rtg, cool, thanks for looking
[16:34] <rtg> jsalisbury, lets get apw's opinion
[16:34] <jsalisbury> rtg, sounds good
[16:34] <rtg> jsalisbury, though we may have missed him for the day. make a note to annoy him on Monday.
[16:36] <jsalisbury> rtg, will do, thanks
[16:54] <apw> rtg, though i am drinking a beer ... i am still about
[16:54] <apw> rtg, i am not sure we can trivially fix that for R, we have talked about wacking the non-signed version in general but ... hmmm
[16:55] <rtg> apw, if you're drinking beer then you should just get lost. come back to work on Monday :)
[17:00] <rtg> kamal, how about 'UBUNTU: SAUCE: (no-up) drm/i915: partially revert PCH_PWM_ENABLE quirk on Dell XPS13 SandyBridge' ?
[17:00] <kamal> rtg: no, that's not really right
[17:00] <rtg> kamal, right, I just read it myself
[17:01] <kamal> rtg: revert PCH_PWM_ENABLE quirk for Dell XPS13-FHD
[17:01] <cjwatson> Hi.  There are a load of kernel source packages still in the archive which only build for armel.  Can I remove them from raring?  linux-linaro-mx51 linux-linaro-omap linux-linaro-shared linux-linaro-vexpress linux-meta-linaro linux-meta-qcm-msm linux-n900 linux-qcm-msm
[17:01] <rtg> bjf, ^^
[17:02] <cjwatson> I finally have a script to detect this kind of thing ...
[17:04] <bjf> cjwatson, i don't see anything there we want/need
[17:04] <ogra_> do we have a vexpress kernel from our generic build ?
[17:05]  * ogra_ would appreciate having a kernel for qemu system usage in the archive ... even if its old 
[17:06] <cjwatson> Well, you don't right now if you're relying on linux-linaro-vexpress :)
[17:06] <cjwatson> (Except in <= quantal)
[17:07] <rtg> ogra_, raring has CONFIG_ARCH_VEXPRESS=y but I've never tested it using QEMU
[17:07] <ogra_> isnt it just a rotten binary ?
[17:07] <ogra_> rtg, well, thats enough 
[17:07] <cjwatson> ogra_: It won't be referenced in any raring Packages files
[17:07] <ogra_> ah
[17:07] <cjwatson> It'll still be in the pool until all series containing armel are obsoleted
[17:07] <ogra_> well, if we have a generic flavouor that potentially works with qemu thats enough 
[17:09] <ogra_> the advantage of vexpress was that we had a netboot image for it so you could just grab vmlinuz from the archive without having to fiddle with packages
[17:09] <ogra_> but yeah, armel isnt an option anyway 
[17:13] <rtg> ogra_, I guess we should add the vexpress DTB to the build. otherwise I don't think that kernel will work. There are several dts files in the kernel tree. Any idea which is the right one ?
[17:15] <ogra_> heh, nope ... i'm a dtb virgin :)
[17:15]  * ogra_ was at all the planning discussion from day one in brussels ... never used a dtb though ...
[17:16] <rtg> ogra_, as am I mostly
[17:21] <bryce> tjaalton, I'll handle arges' patch, I had thought he was going to prepare a more minimalist patch so was waiting on that.
[17:22] <tjaalton> bryce: ok, thanks
[17:23] <tjaalton> from what I heard it should actually be fixed in the kernel, but that'll wait :)
[17:32] <arges> bryce: I posted a patch
[17:32] <arges> bryce: which was a backport of that earlier patch
[17:36] <arges> bryce: not sure how much more minimalist you'd like it, I tried to keep it as close to upstream as possible
[17:36] <arges> tjaalton: re-assigning myself to this, as I think the patch is good to go.  bryce let me know if there are any other actions you need from me
[17:41]  * rtg -> lunch
[17:43]  * apw beer, have a good one
=== yofel_ is now known as yofel
[18:11] <tjaalton> bryce, arges: right, it's from upstream so what choice do we have :)
[18:13]  * henrix -> SIGBEER
[18:16] <bryce> pshaw
[18:17] <tjaalton> indeed, barely made it to the store in time to get a refill ;)
[18:19] <bryce> I'll post the unrefactored in a sec; just checking it still builds.
[18:23] <tjaalton> the commit from upstream doesn't even apply, the last hunk fails
[18:23] <tjaalton> so you need to adjust it
[18:31] <arges> tjaalton: that patch I posted in the bug adjusts the one line
[18:31] <tjaalton> arges: yep
[18:31] <arges> it should apply with 'git am'
[18:31] <arges> ok
[18:31] <tjaalton> we use quilt
[18:31] <arges> i think its worth fixing cause once everybody installs raring and plugs into a projector they may get bit
[18:31] <tjaalton> of course
[18:32] <tjaalton> I'd have uploaded it immediately :)
[18:32] <tjaalton> cause I happened to hit it myself
[18:32] <arges> Ok so there is a git tree git://git.debian.org/git/pkg-xorg/driver/xserver-xorg-video-intel
[18:32] <arges> but since its so close, you need a debdiff
[18:32] <tjaalton> yes
[18:32] <arges> with the path
[18:32] <arges> patch
[18:32] <tjaalton> bryce is on it
[18:32] <arges> ok
[18:33] <arges> coool. let me know if you all need help
[18:33] <tjaalton> it's trivial, drop the patch in debian/patches, update series and changelog and go
[18:41] <bryce> the reason I want the minimal patch is mainly to get through sru.  If we'd gotten this in a week ago we could have just slammed it in.  But now we need to get it signed off by non-X.org people, so for their sake I want to provide as easy-to-review patch as possible
[19:11] <tom231t6> hi, anyone online?
[19:12] <tom231t6> in http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc7-raring/ you forgot to upload the extra debs!
[19:12] <tom231t6> or do I miss something?
[19:15] <tom3356> lost connection
[19:16] <tom3356> I'm testing nvidia 319.12 on raring for optimus support and I need kernel 3.9
[19:21] <arges> tom3356: i e-mailed the maintainer of that build script.
[19:31] <^Mike> I've been asked to test this kernel (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc7-raring/) but when I try to boot it, the kernel panics with "cant find init, try passing init=". My system has encrypted LVM set up. So, /boot is on an unencrypted partition, and then it needs to decrypt and mount / in order to continue. I figure it is trying to use the boot partition as the root partition, which would explain why it can't find init.
[19:39] <Sarvatt> looks like -extra was removed a few days ago in the mainline builds so its not needed
[19:39] <^Mike> As far as I can tell, the entries that got added in /boot/grub/grub.cfg are correct. At least, they look like the entries that work... same "set root=" line, same "--set-root" option on the search line, same "root=" on the linux line
[19:39] <Sarvatt> tom3356, arges: ^
[19:40] <arges> Sarvatt: ack
[20:10]  * rtg -> EOW
[22:59] <bryce> arges, it got accepted