| slangasek | so apparently the mako kernel doesn't have PERF enabled, which means powertop doesn't run. I'm surprised given how much focus there's been on power management on the phones - is there something other than powertop I should be using? | 00:16 |
|---|---|---|
| === smb` is now known as smb | ||
| === fmasi_afk is now known as fmasi | ||
| === fmasi is now known as fmasi_afk | ||
| === fmasi_afk is now known as fmasi | ||
| ppisati | brb | 09:54 |
| * apw reboots to see if any of his desktop will come back | 09:59 | |
| === fmasi is now known as fmasi_afk | ||
| === fmasi_afk is now known as fmasi | ||
| === amitk is now known as amitk-afk | ||
| * henrix -> late lunch | 13:34 | |
| ppisati | any brave soul who is willing to review my packaging of an armhf/generic-lpae flavour for S? | 13:41 |
| ppisati | watch out: at the end of the packaging, it craps out with an error | 13:41 |
| ppisati | "dpkg-gencontrol: error: package linux-udebs-lpae not in control info" | 13:42 |
| rtg | ppisati, where is your repo ? | 13:42 |
| ppisati | "dh_gencontrol: dpkg-gencontrol -plinux-udebs-lpae -ldebian/changelog -Tdebian/linux-udebs-lpae.substvars -Pdebian/linux-udebs-lpae returned exit code 255' | 13:42 |
| ppisati | rtg: let me push it | 13:42 |
| ppisati | the problem is that $someone is passing 'linux-udebs-lpae' to dpkg-gencontrol instead of 'linux-udebs-generic-lpae' | 13:42 |
| ppisati | but i can't find where it comes from | 13:42 |
| apw | ppisati, that would be my fault | 13:44 |
| apw | rtg, the udebs thing is my fault | 13:44 |
| * rtg is still waiting on the repo location | 13:47 | |
| apw | rtg, i'll fix the udebs bit ... | 13:47 |
| apw | ppisati, can you post your repo ... then i can test my fix | 13:48 |
| ppisati | http://kernel.ubuntu.com/git?p=ppisati/ubuntu-saucy.git;a=shortlog;h=refs/heads/master_generic-lpae | 13:50 |
| ppisati | apw: ^ | 13:50 |
| ppisati | rtg: ^ | 13:50 |
| apw | rtg, this packaging error is mine ... sigh | 13:50 |
| ppisati | it's a S/master-next of yesterday (my time) | 13:51 |
| rtg | ppisati, do you really need an inclusion list ? I think it would be simpler to just have a single linux-image package. | 13:53 |
| ppisati | rtg: ah, could be that we can away without it | 13:54 |
| ppisati | *we can go | 13:55 |
| rtg | ppisati, its simpler, and I assume calxeda isn't all that worried about package size | 13:55 |
| ppisati | rtg: ok | 13:56 |
| rtg | ppisati, is there currently HW available that will run arm LPAE ? | 13:58 |
| ppisati | rtg: not in my hands, but cortex a15 are lpae capable | 13:59 |
| ppisati | rtg: and qemu can emulate the a15 | 13:59 |
| ppisati | rtg: if we want something really cheap, there's the samsung chromebook | 13:59 |
| ppisati | ~250$ | 13:59 |
| rtg | ppisati, ok, just making sure that this isn't a new flavour for vaporware. I don't follow arm developments as closely as you | 14:00 |
| ppisati | http://en.wikipedia.org/wiki/ARM_Cortex-A15_MPCore | 14:00 |
| ppisati | rtg: ah, and of course, the new calxeda silicon :) | 14:01 |
| ogra_ | ppisati, pfft, chromebook ... crap ... you want ubuntu edge ! | 14:01 |
| ppisati | ogra_: auahauh :) | 14:01 |
| ogra_ | 128G at SSD speed and 4G ram :) | 14:02 |
| rtg | ppisati, I'd be tempted to squash all of the config patches into 'UBUNTU: [Config] add an armhf/generic-lpae flavour' in order to make building somewhat bisectable, thought this has been good granularity for review. | 14:03 |
| rtg | though* | 14:04 |
| rtg | ppisati, I assume this flavour will be important for the LTS kernel as well ? | 14:05 |
| rtg | ppisati, cut and paste error in kernel-versions.in: 'armhf PKGVER-ABINUM generic-lpae PKGVER-ABINUM-generic' | 14:07 |
| nessita | diwic, hola! I just saw your msg in the bug report. I'm not currently in the computer that has the issue, I will report back this afternoon, but I can tell audio does not work even on almost "0" load | 14:18 |
| diwic | nessita, okay... | 14:19 |
| diwic | nessita, these delays are really strange | 14:19 |
| nessita | diwic, also, this happens since my update to raring, in precise I had no audio issues at all | 14:19 |
| nessita | diwic, besides checking the load, which I will do, is there anything else I can check/try? | 14:19 |
| nessita | I'm happy to upgrade or fresh install saucy | 14:20 |
| diwic | nessita, you can surely test random things | 14:21 |
| rtg | diwic, perhaps she should go back to Precise, but run the Raring LTS kernel in order to isolate any upgrade differences. | 14:21 |
| diwic | rtg, yeah, that is not a bad idea | 14:21 |
| rtg | or, are you pretty sure it is kernel related ? | 14:21 |
| diwic | rtg, no I'm not sure where in the system it is, at all | 14:22 |
| diwic | rtg, all I see is sudden delays, up to 200 ms, that causes the PulseAudio process to freeze | 14:22 |
| diwic | rtg, and underruns as a result | 14:23 |
| diwic | rtg, I don't know where those delays come from | 14:23 |
| rtg | nessita, after re-installing Precise (and verifying that all works as it should), then install linux-generic-lts-raring-eol-upgrade | 14:23 |
| nessita | diwic, other apps such as mplayer and youtube on fierfox does not have this issue -- I guess those do not use PA? | 14:24 |
| diwic | I haven't ruled pulseaudio out completely either | 14:24 |
| diwic | nessita, it has to do with low latency I believe - when streaming media you can have higher latencies than when having phone conversations | 14:24 |
| rtg | I guess if things work well with the LTS kernel, then the issue likely is with PA | 14:24 |
| nessita | rtg, can do that, no problem (over the weekend) | 14:25 |
| diwic | nessita, so those delays of 200 ms are not a problem when the audio buffers are bigger than 200 ms, but in case of VoIP, buffers are more like 10 ms or so | 14:25 |
| nessita | diwic, ah, so that explains why mumble/skype/hangouts are the one that trigger the issue | 14:26 |
| apw | ppisati, yo ... i have just pushed a quicky fixy to saucy master-next which ought to fix your udebs issue | 14:28 |
| apw | ppisati, could you give that test for me | 14:28 |
| ppisati | apw: let me check | 14:28 |
| apw | you ought to be able to cherry-pick it | 14:30 |
| nessita | diwic, so, summarizing I should: report about system load on current installation when bug appears, and, wipe raring and install precise fresh, with raring kernel | 14:30 |
| rtg | nessita, install precise fresh, verify that all works well, _then_ install the Raring kernel | 14:31 |
| diwic | nessita, if raring kernel only does not show the problem, try with the raring X stack as well | 14:31 |
| nessita | diwic, any how to on how to pull the raring X stack in? is there a ppa? | 14:32 |
| nessita | rtg, right, yes | 14:32 |
| ppisati | apw: ok, it's building | 14:32 |
| rtg | though its easy enough to reboot with the desired kernel | 14:32 |
| diwic | nessita, hmm, rtg should probably know the name of that package | 14:32 |
| rtg | linux-generic-lts-raring-eol-upgrade ? | 14:33 |
| diwic | rtg, right, that's both kernel and X stack? | 14:33 |
| apw | rtg, this last commit on unstable, it seems to be a rebase commit, a start new release, and a removal of alx at the saem time, is this intencional | 14:33 |
| rtg | diwic, no, just kernel | 14:33 |
| apw | ppisati, let me know ... thanks | 14:34 |
| rtg | maybe xserver-xorg-lts-raring. But there is no going back after installing that. | 14:34 |
| diwic | oh | 14:34 |
| diwic | and libgl1-mesa-glx-lts-raring | 14:34 |
| diwic | according to the wiki | 14:35 |
| diwic | wiki.ubuntu.com/Kernel/LTSEnablementStack | 14:35 |
| apw | rtg, i thought you could downgrade again by installing the xserver-xorg (in theory) | 14:35 |
| apw | not that i have ever tried of course | 14:35 |
| rtg | apw, perhaps, never tried it | 14:35 |
| apw | mlanghost is the one who should know i think | 14:35 |
| rtg | as would jmleddy or Sarvatt | 14:36 |
| nessita | ok, I guess that going back would be re-installing fresh after all those tests | 14:38 |
| nessita | (which is ok) | 14:39 |
| diwic | nessita, btw, there are no error messages or similar in dmesg that could give us a hint of the kernel is timing out waiting for something? | 14:40 |
| apw | rtg, this last commit on unstable, it seems to be a rebase commit, a start new release, and a removal of alx at the saem time, is this intencional | 14:42 |
| rtg | apw, oh yeah, I collapsed a bunch of noise | 14:42 |
| rtg | mostly useless history | 14:42 |
| nessita | diwic, will also check when I get to that computer. Would you please add this questions to the bug report, so I don't forget to check anything before wiping that raring? | 14:44 |
| rtg | apw, all that noise is well preserved with the 3.10 tags | 14:44 |
| diwic | nessita, hopefully the latest comment is sufficient? | 14:48 |
| nessita | diwic, right, I need to rememebr to check dmesg, but think I will remember :-) | 14:52 |
| ppisati | apw: ok, the udeb fix did it | 14:55 |
| ppisati | but now i've another error: | 14:55 |
| apw | whats the new one | 14:55 |
| ppisati | http://paste.ubuntu.com/5911420/ | 14:56 |
| apw | ppisati, that implies the d-i config for is not being used i suspect | 14:57 |
| rtg | you need a firmware exclusion file in d-i | 14:57 |
| rtg | ppisati, did you fix the typo in kernel.versions.in ? | 14:58 |
| ppisati | rtg: yep | 14:58 |
| apw | ppisati, did you copy the armhf-generic files over in debian.master-/d-i | 14:58 |
| apw | ppisati, did you copy the armhf-generic files over in debian.master/d-i | 14:58 |
| apw | over to the new name | 14:58 |
| ppisati | uhm | 14:59 |
| ppisati | i'm actually missing debian.master/d-i/exclude-firmware.armhf-generic -> debian.master/d-i/exclude-firmware.armhf-generic-lpae | 14:59 |
| ppisati | rtg: if i delete my generic-lpae.inclusion-list, will it automagically pick generic.inclusion-list or do i need to do something particular? | 15:12 |
| rtg | jjohansen, apw, would you review http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=commit;h=7e78ed6018577530d4ec1fe9f60486aa6d9de529 to make sure I've not done something stupid security wise. | 15:13 |
| rtg | ppisati, no, it simply doesn't use an inclusion list, and therefore only creates a single linux-image package. | 15:16 |
| rtg | at least, thats the theory. | 15:17 |
| ppisati | rtg: let's see | 15:18 |
| rtg | ppisati, you shuld also be OK if do_extras_package != true | 15:22 |
| === fmasi is now known as fmasi_afk | ||
| BenC | apw: Can you look at this build failure and explain what I need to do for ppc? https://launchpadlibrarian.net/145776419/buildlog_ubuntu-saucy-powerpc.linux-ppc_3.10.0-0.6_FAILEDTOBUILD.txt.gz | 15:32 |
| rtg | BenC, apw just applied a patch to master-next that ought to fix it. | 15:33 |
| rtg | UBUNTU: [Packaging] fix SRCPKGNAME-udebs-FLAVOUR handling for complex flavours | 15:33 |
| BenC | rtg: Thanks…when's the next upload? | 15:33 |
| rtg | BenC, unless something critical comes along, likely not until next week. we're considering switching over to 3.11-rc* | 15:34 |
| rtg | we might sneak in a 3.10.y stable.... | 15:34 |
| BenC | rtg: ack | 15:37 |
| === amitk-afk is now known as amitk | ||
| ppisati | rtg: ok, i based my stuff on top of master-next and i'm doing the last build, can you refrain from committing to master-next? | 15:54 |
| infinity | BenC: You may also be missing the debian/control tweaks you need, unless Andy pushed those to you. | 15:54 |
| rtg | ppisati, I dunno, I'm kind of commit happy these days. | 15:55 |
| infinity | BenC: (We both noticed, FWIW, that we don't have write access to your saucy treee on github) | 15:55 |
| bjf | roadmr, just fyi, the newly respun precise kernel is in -proposed and ready for testing | 15:58 |
| rtg | bjf, I don't think he's on IRC | 15:58 |
| bjf | rtg, i just noticed :-( | 15:58 |
| ppisati | brb | 15:59 |
| BenC | infinity: Ah, I'll fix that up | 16:01 |
| infinity | zequence: We had to respin precise, FWIW. Should be ready for a lowlatency rebase. | 16:02 |
| BenC | infinity: added both of you | 16:03 |
| apw | right BenC soz was in a meeting | 16:04 |
| apw | BenC, so that error is due to you needing the new control stanza for that package in the flavour-control.stub | 16:05 |
| apw | BenC, did rtg already point you at it ... i was oging to commit it last night but couldn't | 16:06 |
| BenC | apw: I added you to the repo, so if it's quick for you, please commit it | 16:07 |
| apw | BenC, ack | 16:07 |
| apw | BenC, i've pushed up what ought to be the right changes, could you do a build test, your kit is sooo much faster than mine | 16:17 |
| BenC | apw: starting a full build now | 16:18 |
| rtg | ppisati, is there any reason to call the new flavour generic-lpae as opposed to just lpae ? or maybe arm-lpae 'cause it _is_ specific to arm. | 16:32 |
| apw | rtg, well generic-<variant> the first part imples it is meant to be a common image for all systems ... right ? | 16:33 |
| ppisati | rtg: no reason, but that's what we had in x86 before (e.g. generic-lpae), wasn't it? | 16:33 |
| apw | in the smae vein as generic/generic-pae in x86 | 16:33 |
| ppisati | and i think i heard someone sayign that the lpae version of arm should have been called generic-lpae | 16:33 |
| bjf | ppisati, are you going to respin precise ti-omap4 ? | 16:34 |
| ppisati | bjf: isn't it just a bluetooth fix? | 16:35 |
| bjf | yup | 16:35 |
| rtg | apw, ppisati: well, I think the 'generic' part of the flavour name is useless information. it doesn't really convey any meaning. (nor did it for x86 really) | 16:35 |
| apw | rtg generic is what we call kernels for things which arn't machine specific | 16:37 |
| apw | it has to have some name, well where we have a default variant | 16:38 |
| infinity | rtg: I can agree with the "it doesn't convey anything", but be consistent. If you want to take it off the ARM kernels, ditch it from x86 too. And that's way more effort than matters. | 16:38 |
| infinity | (In other words, don't bother) | 16:38 |
| * rtg is just stirring the mud, and doesn't _really_ care all that much. | 16:39 | |
| ppisati | pull sent | 16:44 |
| rtg | on the other hand, I really don't want to give the x86 32 bit folks any hope that we might someday reinstate support for x86 LPAE. | 16:44 |
| apw | they will have to get that past you | 16:47 |
| rtg | I still get hate mail once in awhile | 16:47 |
| === amitk is now known as amitk-afk | ||
| rtg | cyphermox, sforshee: if I've 2 APs with similar characteristics, but one has clearly inferior signal strength, why would NM _ever_ choose the weaker one on resume ? | 16:49 |
| apw | rtg, we should hold off merging this new flavour until we get the new buildds | 16:49 |
| apw | rtg, as we will be moving to 24 hours to build | 16:49 |
| rtg | apw, I can merge but just not enable the flavour in armhf.mk | 16:50 |
| apw | rtg, sure makes sense | 16:50 |
| * ppisati -> EOD | 17:03 | |
| rtg | ppisati, CONFIG_KVM_ARM_MAX_VCPUS=0 ? the default is 4. | 17:04 |
| cyphermox | rtg: could it be a 2.4Ghz and the other a 5? | 17:05 |
| rtg | cyphermox, both are BG only | 17:06 |
| === fmasi_afk is now known as fmasi | ||
| * rtg -> lunch | 17:34 | |
| === fmasi is now known as fmasi_afk | ||
| * rtg -> EOD | 19:52 | |
| === larsdues1ng is now known as larsduesing | ||
| === fmasi_afk is now known as fmasi | ||
| === fmasi is now known as fmasi_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!