[02:14] <duflu> RAOF: Thanks for the android-headers. Crisis averted
[02:15] <duflu> It was a race against time as our xenial build machines on Friday were luckily slightly out of date and didn't have the bug yet...
[02:43] <RAOF> duflu: Actually, our xenial build machines would have correctly built it ;)
[02:43] <duflu> RAOF: How's that?
[02:43] <RAOF> duflu: Because the bug only appears when *upgrading* from android-headers $OLD_VERSION to android-headers 23.
[02:43] <RAOF> Since we install fresh on the builders, they never would have seen the problem.
[02:44] <duflu> RAOF: Interesting. How often do we install fresh? Sounds expensive
[02:44] <RAOF> Every build?
[02:44] <duflu> Hmm, maybe copy-disk-image rather than install?
[02:44] <RAOF> Not really; it's certainly < 1m on machines that aren't IO thrashing.
[03:25] <duflu> Hmm.... why do Mir servers use more CPU to bypass/overlay than to GL composite?
[03:25] <duflu> Curious
[03:51] <RAOF> Do they actually use more CPU, or is the CPU in a higher performance state when GL compositing?
[03:56] <duflu> RAOF: I'm not sure. The meaning of CPU usage also varies between tools (some say 100% is one core and others say 100% is all cores)
[03:56] <duflu> Never considered power state too
[03:57] <RAOF> 100% CPU at 800MHz is quite different to 100% at 2.5GHz :)
[04:02] <duflu> RAOF: I suspect the former does not usually exist. If you're  using 100% CPU at 800MHz the system should have clocked up already
[04:02] <duflu> But 5% as I'm seeing is plausibly some unknown clock rate
[04:02] <RAOF> Maybe should, but doesn't.
[04:02] <duflu> I should check
[04:03] <RAOF> Or our whole “scrolling is only smooth if you keep a finger on the touchscreen” bug wouldn't have existed.
[04:11] <duflu> RAOF: Still does (if not the original bug a new one is open still)
[04:12] <duflu> I think... I definitely know it's still a problem because that was the sole remaining blocker of double vs triple buffering (and dynamic scaling)
[04:19] <duflu> Interestingly the second-last blocker just got fixed in Mir 0.19.0
[04:25] <RAOF> I wonder if the blockers will be fixed before the codepath no longer exists :)
[05:15] <duflu> RAOF: I'm kind of hoping NBS stumbles upon a way to keep the CPU awake, somewhat by accident
[05:15] <duflu> Which may happen
[05:16] <duflu> But before then, hoping we actually test it and assess whether that it doesn't regress anywhere
[07:22] <zzarr> hello!
[07:23] <zzarr> hello! duflu, I found this https://wiki.debian.org/InstallingDebianOn/Asus/C201
[07:24] <zzarr> it's about as close I of a tutorial I can com/find
[07:24] <zzarr> come*
[07:25] <duflu> zzarr: Hello. Interesting but it seems they have no news on OpenGLES
[07:25] <duflu> "OpenGL ES"
[07:26] <duflu> I've never had a good look at ChromeOS binaries. I wonder what libc they use...
[07:28] <anpok> hmhm on mali you can get at least three different types opengl es libraries..
[07:29] <anpok> .. oh actually four if you count lima too..
[07:30] <anpok> there are es/egl libraries for android, for rendering on fbdev, and for x11..
[07:31] <duflu> BTW all: Mir 0.19.0 is released now (https://launchpad.net/mir/+milestone/0.19.0)
[07:31] <anpok> each of those need mali specfic kernel patches.. integrated for your soc
[07:31] <duflu> Just no announcement yet because we haven't finished documenting the release
[07:32] <zzarr> duflu, what are the differences between the openGLES libs?
[07:32] <duflu> zzarr: I don't understand the question. What libs?
[07:32] <zzarr> is it a specific one that mir needs?
[07:33] <zzarr> ohh, it was the libc versions?
[07:34] <duflu> zzarr: Mir like most OpenGL code links to libGLESv2.so.2 which has a clearly defined ABI. The only question is what libraries does the libGLESv2.so.2 link to.
[07:34] <zzarr> duflu, I see, I understand the question
[07:35] <zzarr> is there a way to know that?
[07:35] <duflu> zzarr: Just run ldd, or objdump
[07:35] <zzarr> okey
[07:38] <zzarr> duflu, what parts of the tutorial do I need in order to install Ubuntu instead of debian?
[07:39] <zzarr> I tried changing jessie to xenial and the url to ports.ubuntu.com, and it worked...
[07:39] <zzarr> basically what failed was to copy the kernel
[07:39] <duflu> zzarr: I can't say with confidence. I would suggest just setting up crouton. That's an easy way to have full Ubuntu, and a working kernel from ChromeOS, and keep ChromeOS working too.
[07:40] <duflu> For anything more advanced, you will need to become the expert and answer those questions yourself
[07:41] <zzarr> I have crouton, but installing Ubuntu on a SD card will not ruin my chromeos
[07:41] <duflu> Sorry, I haven't played with Ubuntu on ChromeOS in a while. You have just about exhausted what I remember :)
[07:42] <zzarr> duflu, sry, did not mean to ;)
[07:43] <zzarr> it's just.. I got exited about running Ubuntu on my chromebook, since it would be 3D-accelerated (which crouton is not)
[07:53] <duflu> Sadly, Intel Chromebooks are an easier way to do that. Although nowhere near as sexy as the Chromebook Flip
[08:00] <zzarr> duflu, I know
[08:04] <zzarr> still, I will fight to get Ubuntu running on my chromebook ;)
[08:28] <zzarr> duflu, I have copied the kernel and signed it now :-D
[08:29] <duflu> Cool
[08:29] <zzarr> I'll try to start from the SD card now
[08:30] <zzarr> just a black display
[08:37] <zzarr> maybe the kernel-flags are wrong, maybe it should not be console=tty1
[09:23] <zzarr> duflu, I can recommend a ASUS Chromebook Flip
[09:24] <duflu> Yeah looks very nice
[09:24] <duflu> The thing that lets down most Chromebooks is the lack of IPS display. So that's solved too
[09:25] <zzarr> yea :)
[09:26] <zzarr> I would not mind higher resolution, but... higher resolution means shorter battery life
[09:26] <zzarr> it's a 1280x800 display
[09:27] <zzarr> but it can handle a UHD over HDMI
[09:28] <duflu> UHD is great. So long as it can keep up with the frame rate of the video you're playing (or ideally 60Hz)
[09:31] <zzarr> it should be able to handle a video @ 30fps
[09:51] <zzarr> duflu, I don't remember, do you have any idea how to activate a console on a kernel that's without one?
[09:51] <duflu> zzarr: No, sorry. Google! :)
[09:51] <zzarr> duflu, okey, it was worth a try (to ask you) :-)
[13:59] <alf_> Saviq: Hi! I saw that you were looking into upgrading sbuild to a newer version in your jenkins builders. What the status of this?
[13:59] <alf_> Saviq: (I too need a newer sbuild)
[13:59] <Saviq> alf_, my prepare jobs do this already
[14:00] <Saviq> alf_, they take it from ppa:launchpad/buildd-staging or is that not new enough?
[14:01] <alf_> Saviq: I get sbuild 0.64.2, but I need a newer version that supports SBUILD_CONFIG (custom config per build)
[14:01] <alf_> Saviq: oops, that's 0.65.2
[14:01] <Saviq> alf_, 0.65.2 is in there https://launchpad.net/~launchpad/+archive/ubuntu/buildd-staging/+packages
[14:02] <Saviq> alf_, why do you need that, btw?
[14:03] <alf_> Saviq: Yes, looking at the git repo I need at least 0.66 for SBUILD_CONFIG
[14:04] <Saviq> alf_, right, misread, problem is it's not a 1:1 backport, I tried building sbuild from xenial on trusty and it failed
[14:05] <alf_> Saviq: I have been trying to run some custom scripts in the chroot with the facilities that sbuild provides, but either sbuild or jenkins get very confused when passing these as command line args to sbuild.
[14:05] <alf_> Saviq: So I want to try defining them in a config file
[14:06] <Saviq> alf_, so you mean stuff like --foo-commands does not work?
[14:06] <Saviq> I'd imagine you'd have to escape those in a way neither jenkins nor sh -r play with that
[14:07] <Saviq> alf_, tried putting the script in a file (I need to move all those shell/py blocks to bzr myself)
[14:07] <alf_> Saviq: Both methods works well locally... not sure what confuses sbuild/jenkins, probably it doesn't escape properly or escapes too much. I have tried with different escape but I haven't been able to find a way that works
[14:08] <Saviq> alf_, right, I'd put the scripts in bzr and run those instead of coding in jenkins directly
[14:08] <Saviq> was meaning to do that anyway
[14:11] <alf_> Saviq: I also tried writing the script to a file and then copying into the chroot, but I found that %SBUILD_CHROOT_DIR doesn't work in jenkins/sbuild with --pre-build-commands, although I think it should be supported in 0.65.2
[14:12] <Saviq> alf_, an "env" in the script could probably help
[14:14] <alf_> Saviq: %SBUILD_CHROOT_DIR should be substituted by sbuild, not sure how an env would help?
[14:15] <Saviq> alf_, ok not sure about that %foo, but I'd imagine stuff's exported as env, innit?
[14:15] <Saviq> alf_, ah I think that only works in strings
[14:16] <Saviq> alf_, man says "sbuild --post-build-commands 'foo %SBUILD_CHANGES'"
[14:17] <Saviq> alf_, so assuming foo is a script, it will be given the argument
[14:17] <Saviq> alf_, but check env, I'm sure there's quite a bit of data in there already
[14:18] <alf_> Saviq: yeah, so %SBUILD_CHROOT_DIR is not substituted for some reason
[14:18] <Saviq> alf_, you said in a file?
[14:20] <alf_> Saviq: Sorry, I wasn't clear... the script itself is an file that I want to copy into the chroot with --pre-build-commands 'cp script.sh %SBUILD_CHROOT_DIR' but I can't because the sbuild var is not substituted properly
[14:21] <Saviq> alf_, right, now I get it, just bind-mount a folder with scripts ;)
[14:21] <alf_> Saviq: thanks, I'll try that
[14:22] <Saviq> alf_, that's what I planned to do with the existing pbuilder hooks - just bind-mount the folder, although those that run outside the chroot might still need the substitutions to work
[14:23] <Saviq> alf_, but indeed man says %r should be available in --pre-build-commands
[14:43] <alf_> Saviq: Let me know when you have moved your scripts to bzr, I will probably want to extend them or branch
[14:44] <Saviq> alf_, will do, I hope you don't diverge far enough, so we can maintain together all of su
[14:44] <Saviq> us
[14:44] <Saviq> alf_, oh btw there was a talk on fosdem about Jenkins DSL https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
[14:45] <Saviq> https://fosdem.org/2016/schedule/event/jenkins_as_code/
[14:45] <alf_> Saviq: agreed, I will try to extend as much as I can (with hooks etc)
[14:45] <alf_> Saviq: interesting
[14:45] <Saviq> alf_, related to what jibel proposed (jenkins-job-builder), unfortunately as things stand we can't use either, because the "seed" jobs need to run on the master ;)
[16:29] <alf_> Saviq: I am seeing cases where jenkins is losing my changes to jobs (I hit save and next time or after a while the job reverts to an older version). Have you seen that?
[16:31] <Saviq> alf_, nope, don't think so
[16:31] <alf_> Saviq: good for you, it's very annoying...
[16:31] <Saviq> I can imagine
[16:32] <alf_> Saviq: so, let me know if I can help with bzr-ifying the scripts
[16:32] <Saviq> alf_, ack, I'll jump on that tomorrow morning