| === gerald is now known as Guest70860 | ||
| rsalveti | apw: hey, as we're going to set the brightness level using the android hal, we don't need the following patch anymore (for flo): http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=commit;h=c8bbd5315bc7d0ad69c2911cd59c807814e7def2 | 04:32 |
|---|---|---|
| rsalveti | apw: reverting that also fixes a stack trace during boot, and sets up the default framebuffer device as used by the stock android image | 04:33 |
| rsalveti | apw: would you mind reverting that patch and pushing a new package to the ppa? | 04:33 |
| rsalveti | that was only needed because we could only set the brightness level via sysfs (using a specific device class), and the stock config provides a lcd-backlight device under the leds class | 04:35 |
| rsalveti | so with the patch we can set brightness using the current indicator-power logic, but can't using the android hal as the device is different | 04:36 |
| rsalveti | so that's why we need the revert, as once we merge https://code.launchpad.net/~ycheng-twn/indicator-power/indicator-power_set-brightness-via-powerd/+merge/209200 we'll be setting it via hal (which is how powerd is currently using it as well), making it more compatible with the android stack | 04:37 |
| rsalveti | and compatible with more devices | 04:37 |
| ppisati | yep | 07:05 |
| dholbach | hey | 11:33 |
| dholbach | can somebody check what's still missing on this bug: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1256949?? | 11:33 |
| ubot2 | Launchpad bug 1256949 in linux (Ubuntu) "Dell Latitude E5420 doesn't boot if killswitch is turned to "radio off"" [Undecided,Expired] | 11:33 |
| ogra_ | apw, since you had so brilliant ideas about the systremsettle test on the phones when we discovered that the CPU core are hotplugged, i was wondering if you have an idea about upstart in that regard .... it is supposed to crop a chart if the system goes idle after a certain app started, but i cant seem to get it to sense that on the phone | 12:08 |
| ogra_ | http://people.canonical.com/~ogra/touch-bootcharts/ has daily bootcharts .... http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-255.png is the only one where the cropping happened, the CPU usage looks like it is close to zero, so i suspect thats a similar issue as the systemsettle idle issue | 12:09 |
| === gerald is now known as Guest41288 | ||
| === dayangkun is now known as dayangkun_afk | ||
| === hatch__ is now known as hatch | ||
| rsalveti | guess apw is not around today | 15:30 |
| ogra_ | rsalveti, nope, on friday again | 15:31 |
| rsalveti | rtg: mind handling http://paste.ubuntu.com/7157292/? | 15:32 |
| ogra_ | (probably bootchart simply doesnt consider the system idle because the kernel writes 100 battery state messages to syslog all the time :P ) | 15:32 |
| rtg | rsalveti, ack | 15:33 |
| rsalveti | rtg: thanks | 15:33 |
| rtg | rsalveti, Uploading linux-flo_3.4.0-3.9.dsc: done. | 16:07 |
| rsalveti | rtg: thanks! | 16:27 |
| rtg | rsalveti, c-k-t PPA as usual. Note the ABI bump (if that is relevant) | 16:28 |
| rsalveti | rtg: thanks, did you also update the meta package? | 16:28 |
| rsalveti | rtg: I can migrate to the archive | 16:28 |
| rsalveti | after testing it | 16:28 |
| rtg | rsalveti, yup, hence the ABI update | 16:28 |
| rsalveti | awesome, thanks so much | 16:28 |
| rtg | np | 16:28 |
| infinity | rsalveti: I can just copy it to the archive, if you think it's sane. | 16:36 |
| rsalveti | infinity: np, will land it together with another silo | 16:36 |
| rsalveti | but thanks | 16:36 |
| infinity | rsalveti: Whee, silos. Please copy it instead of reuploading. :P | 16:37 |
| infinity | (with binaries) | 16:37 |
| rsalveti | sure, will just copy them :-) | 16:37 |
| infinity | BenC: Daily ping re: http://launchpad.net/bugs/1291125 | 18:15 |
| ubot2 | Launchpad bug 1291125 in Kernel SRU Workflow "linux-ppc: <version to be filled> -proposed tracker" [Medium,In progress] | 18:15 |
| BenC | infinity: Build in progress | 18:15 |
| infinity | BenC: \o/ | 18:15 |
| infinity | BenC: Can I trust that you're doing a full build so I don't have to do it again before I upload? :) | 18:16 |
| BenC | infinity: Yes :) | 18:16 |
| infinity | Shiny. | 18:16 |
| infinity | BenC: Was there a defensible reason why CONFIG_KVM was =y in powerpc rather than =m? | 18:56 |
| infinity | BenC: Or "just cause"? | 18:56 |
| BenC | infinity: I don't think it can be =m | 18:56 |
| infinity | BenC: It can (and is) on other platforms, and qemu --enable-kvm forced a load. | 18:56 |
| infinity | BenC: Hence the curiosity. | 18:57 |
| infinity | s/forced/forces/ | 18:57 |
| BenC | Then my argument is that qemu --enable-kvm doesn't require root (if /dev/kvm is set to a specific group) :) | 18:57 |
| BenC | But to be honest, I have no good reason, and I haven't tried it as =m | 18:57 |
| infinity | BenC: That should still work, through the magic of udev and things. | 18:57 |
| infinity | BenC: Alright, we'll give it a whirl as =m and see if the world explodes. | 18:58 |
| infinity | BenC: But there's no reason why your platform(s) would be special in this regard, right? Like, if it works for me on IBM kit, it should work for you too? | 18:58 |
| BenC | Right | 18:58 |
| infinity | Cool. | 18:58 |
| infinity | rtg: ^ | 18:58 |
| rtg | infinity, ack | 18:59 |
| BenC | As long as there aren't really weird module naming that program have to be aware of (e.g. vx and such) | 18:59 |
| strikov | Hi guys. Kernels for armhf have flash-kernel in recommends. Due to this fact when you try to use curtin (fast-path installer) inside the virtual instance it crashes. Curtin installs kernel, kernel recommends flash-kernel and flash-kernel crashes because it can't get arch name (dtb is not available and /proc/cpuinfo shows 'Dummy Virtual Machine' which is not in flash-kernel's db). What is the best way to solve this? Thanks | 20:21 |
| infinity | strikov: How are kernels meant to be booted in these VMs? | 20:22 |
| infinity | strikov: Is it currently "feed it to qemu externally"? | 20:22 |
| infinity | It's entirely possible that kernels recommending bootloaders is a silly idea we should stop doing. | 20:23 |
| infinity | But since it might be a bit late to easily validate that, adding a no-op flash-kernel DB entry for VMs might do. | 20:24 |
| strikov | infinity: there is no way to boot them right now (when we have grub working inside vm instance that can be the way) | 20:24 |
| strikov | infinity: db entry looks good to me, just wanted to make sure that we can't drop this recommendation | 20:25 |
| strikov | infinity: thanks | 20:25 |
| infinity | strikov: File a bug on flash-kernel with the details and a dump of /proc/cpuinfo on such a setup. | 20:26 |
| strikov | infinity: will do | 20:26 |
| infinity | strikov: I'm pretty sure the right answer here is to make kernels on all arches stop recommending bootloaders, it should be up to your installer to pick one for you, not the kernel package to make sure you have one, but final beta time is probably not the right time to make changes like that. | 20:26 |
| strikov | infinity: agreed | 20:27 |
| strikov | infinity: and do you have example of this no-op entry? | 20:27 |
| strikov | infinity: how it should look like to avoid any work done | 20:27 |
| dannf | infinity: if we do this for just arm64 (remove recommends), and we verify that d-i still works on supported platforms, is that good? | 20:28 |
| infinity | dannf: Possibly, but the above was about armhf. :P | 20:29 |
| dannf | oh - nm, strikov says it related to armhf, and yeah - too late to validate that | 20:29 |
| dannf | we have the same problem on both, but no-op entry would fix it for both | 20:29 |
| infinity | I'd imagine that "Machine: Foo\nKernel-Flavors: generic generic-lpae" and nothing else in the stanza would do pretty much nothing on Foo. | 20:30 |
| infinity | Though please do test. ;) | 20:31 |
| infinity | Though, this conversation did highlight a bug on ppc64el, where loader is wrong. | 20:35 |
| strikov | infinity: http://paste.ubuntu.com/7158987/ at the end of db list did the trick | 20:50 |
| infinity | strikov: Erm, what's that second line for? | 20:53 |
| strikov | infinity: well, we have different /proc/cpuinfo lines on armhf and arm64 :( | 20:55 |
| strikov | infinity: inside the vm instance i mean | 20:55 |
| infinity | Oh, that's for the two arches. Kay. | 20:55 |
| infinity | Awkward that the second one is so ugly. | 20:55 |
| infinity | Is this with hallyn's qemu 2.0 packages? | 20:55 |
| strikov | infinity: it is | 20:56 |
| strikov | infinity: oh, sorry, i'm using 1.7 | 20:57 |
| strikov | infinity: https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1298070 Thanks for helping | 21:56 |
| ubot2 | Launchpad bug 1298070 in flash-kernel (Ubuntu) "Flash-kernel shouldn't raise any errors while running inside vm instance" [Undecided,New] | 21:56 |
| infinity | Not sure I entirely agree with the Foundation Model being in there, but I guess it doesn't hurt terribly. | 21:58 |
| infinity | Since, in theory, if we ever have a bootloader there, it's going to be grub. | 21:58 |
| infinity | Which I assume it also true for our VM story. | 21:58 |
| infinity | s/it/is/ | 21:59 |
| strikov | infinity: yeah, i don't think that we have any chance to see u-boot inside any virt environment | 22:04 |
| strikov | infinity: and flash-kernel is about u-boot | 22:04 |
| hallyn | ok, i apparently misread the memo - 12.04 has a very long chain of hwe kernels; do i understand right that 14.04 will only have 2 years of kernel support? | 23:13 |
| infinity | hallyn: No. | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
