[01:38] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-97.120~14.04.1] (kernel)
[04:16] <tjaalton> I have a bit of a problem with tomcat8 vs tomcat8.0 and don't know how to best solve it
[04:16] <tjaalton> libtomcatjss-java needs libtomcat8.0-java
[04:17] <tjaalton> but with the current package it doesn't get upgraded, replacing libtomcat8-java with 8.0-java
[04:18] <tjaalton> I guess putting P/C/R: libtomcat8-java would solve it, but then all upgrades would get libtomcat8.0-java, which is not desirable since it's supposed to be temporary to allow dogtag/tomcatjss to work until they've been ported to new tomcat..
[04:33] <tjaalton> hmm, and now dist-upgrade worked without changes.. I'll poke it some more
[04:54] <slangasek> tjaalton: Conflicts/Replaces, without Provides, should be enough to tell apt to prefer the replacing package
[04:56] <tjaalton> slangasek: okay, I had a package which recommended libtomcat8-java and removing that made dist-upgrade work fine
[04:57] <tjaalton> shouldn't have had that installed in the first place. fresh install seems to work fine now at least
[04:57] <slangasek> ok
[06:28] <slangasek> jbicha: what did you want to do about gnome-core on ppc64el? (firefox)
[06:53] <slangasek> sergiusens: I see snapcraft autopkgtests failing in artful, which looks like actual bugs in snapcraft (bundling a subset of glibc libraries in the snaps, which are then incompatible with the new libc.so.6 on the system); do you concur?
[07:28] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-36.40~16.04.1]
[07:29] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-97.120~14.04.1]
[07:29] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-133.182]
[07:31] -queuebot:#ubuntu-release- New binary: glewlwyd [ppc64el] (artful-proposed/universe) [1.1-2ubuntu1] (no packageset)
[07:31] -queuebot:#ubuntu-release- New binary: glewlwyd [s390x] (artful-proposed/universe) [1.1-2ubuntu1] (no packageset)
[07:32] -queuebot:#ubuntu-release- New: accepted glewlwyd [ppc64el] (artful-proposed) [1.1-2ubuntu1]
[07:32] -queuebot:#ubuntu-release- New: accepted glewlwyd [s390x] (artful-proposed) [1.1-2ubuntu1]
[07:33] -queuebot:#ubuntu-release- New binary: glewlwyd [armhf] (artful-proposed/universe) [1.1-2ubuntu1] (no packageset)
[07:39] -queuebot:#ubuntu-release- New: accepted glewlwyd [armhf] (artful-proposed) [1.1-2ubuntu1]
[07:43] -queuebot:#ubuntu-release- New binary: ubuntukylin-wallpapers [amd64] (artful-proposed/universe) [17.10.2] (ubuntukylin)
[07:53] -queuebot:#ubuntu-release- New: accepted gnome-getting-started-docs [amd64] (artful-proposed) [3.26.0-0ubuntu1]
[07:53] -queuebot:#ubuntu-release- New: accepted ubuntukylin-wallpapers [amd64] (artful-proposed) [17.10.2]
[07:53] -queuebot:#ubuntu-release- New: accepted gnome-user-docs [amd64] (artful-proposed) [3.26.0-0ubuntu1]
[07:57] -queuebot:#ubuntu-release- New sync: aether-ant-tasks (artful-proposed/primary) [1.0.1-1]
[07:58] -queuebot:#ubuntu-release- New: accepted aether-ant-tasks [sync] (artful-proposed) [1.0.1-1]
[08:00] <doko> $ apt-cache show linux-tools-4.13.0-11|grep Depends
[08:00] <doko> Depends: libaudit1 (>= 1:2.2.1), libbinutils (>= 2.29), libbinutils (<< 2.30), libc6 (>= 2.14), libdw1 (>= 0.157), libelf1 (>= 0.144), liblzma5 (>= 5.1.1alpha+20120614), libnuma1 (>= 2.0.11), libpci3 (>= 1:3.5.2-1), libslang2 (>= 2.2.4), libudev1 (>= 183), libunwind8, zlib1g (>= 1:1.1.4), linux-tools-common
[08:01] <doko> apw: ^^^ your binutils upper dependency is wrong. whatever relies in linux-tools on that is now broken in the release pocket
[08:01] -queuebot:#ubuntu-release- New binary: aether-ant-tasks [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
[08:04] -queuebot:#ubuntu-release- New: accepted aether-ant-tasks [amd64] (artful-proposed) [1.0.1-1]
[08:28] -queuebot:#ubuntu-release- New binary: python3.7 [s390x] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
[08:31] -queuebot:#ubuntu-release- New binary: python3.7 [ppc64el] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
[08:31] -queuebot:#ubuntu-release- New binary: python3.7 [i386] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
[08:35] -queuebot:#ubuntu-release- New binary: python3.7 [amd64] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
[08:36] <apw> doko, da'fuk ... how on earth did that happen
[08:36] <apw> doko, will look into it and get it sorted out
[08:36] <doko> apw: because you have 2.30 as an upper dependency
[08:37] <apw> doko, those are auto-dependencies, not ones we type
[08:37] <apw> it would have had to be built against the old version somehow
[08:37] <doko> ohh, it's an issue in binutils ;)
[08:38] <doko> but anywa, you should get tigher deps with a rebuild
[08:41] -queuebot:#ubuntu-release- New binary: python3.7 [arm64] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
[08:41] -queuebot:#ubuntu-release- New binary: python3.7 [armhf] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
[08:51] <apw> doko, why are the ones there wrong? given the current version falls in that gap ?
[08:51] <apw> doko, is that not a major version clamp and intended as is ?
[08:52] <doko> no, it's the change of the soname, and that changes often
[08:52] <doko> you can avoid it by statically linking libbfd
[08:52] <doko> read the package description, it's not a stable ABI
[08:58] -queuebot:#ubuntu-release- New: accepted python3.7 [amd64] (artful-proposed) [3.7.0~a1-1]
[08:58] -queuebot:#ubuntu-release- New: accepted python3.7 [armhf] (artful-proposed) [3.7.0~a1-1]
[08:58] -queuebot:#ubuntu-release- New: accepted python3.7 [ppc64el] (artful-proposed) [3.7.0~a1-1]
[08:58] -queuebot:#ubuntu-release- New: accepted python3.7 [arm64] (artful-proposed) [3.7.0~a1-1]
[08:58] -queuebot:#ubuntu-release- New: accepted python3.7 [s390x] (artful-proposed) [3.7.0~a1-1]
[08:58] -queuebot:#ubuntu-release- New: accepted python3.7 [i386] (artful-proposed) [3.7.0~a1-1]
[09:01] <apw> doko, ok, anyhow, they are supplied by binutils i believe, so a rebuild is sufficient to sort that out, right ?
[09:01] <apw> i may have a minor update i can justify uploading
[09:01] <doko> yes
[09:08] <Ukikie> 3.7?  Huh.
[09:17] <apw> t'is an alpha i assume, and us not be using it
[09:23] <fossfreedom_> quick question - for universe packages with no specific ubuntu changes - is sync'ing with debian unstable still occurring? Reason for the question - tlp is an older version in artful compared to unstable and I'm wondering why that is.
[09:25] <cjwatson> fossfreedom_: No, that stopped at Debian import freeze.  See https://wiki.ubuntu.com/ArtfulAardvark/ReleaseSchedule
[09:25] <fossfreedom_> ok. thanks.
[09:25] <cjwatson> Syncs can still be done manually by syncpackage if they're appropriate for the freeze state or have an exception
[09:34] <fossfreedom_> cjwatson: thanks - looks like it was uploaded around the time of the  freeze date.  no worries. it will be pulled in for 18.04
[09:51] <cjwatson> Indeed.
[10:15] -queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [150-2git1~ubuntu17.04.1 => 151-1~ubuntu17.04.1] (no packageset)
[10:15] -queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [150-2git1~ubuntu16.04.1 => 151-1~ubuntu16.04.1] (no packageset)
[10:20] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [151-1~ubuntu16.04.1]
[10:21] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [151-1~ubuntu17.04.1]
[11:52] <jbicha> slangasek: I'll just have gnome-core use epiphany-browser on ppc64el since chromium-browser isn't available there either
[11:59] <doko> jbicha, slangasek: I asked pat to schedule a session about firefox/rust/cargo maintenance. I think at least on architectures where we don't support firefox we can build with external dependencies like Debian is doing it. but lets see next week for that
[12:07] <jbicha> doko: it's likely that webkit2gtk 2.20 (March 2018) will have a build-dependency on gcc-6, how are you thinking we'll handle that?
[12:07] <sergiusens> slangasek I am sort of off today, can look at it tomorrow or ask elopio to start today if there is rush
[12:08] <doko> jbicha: is that the deprecated webkit?
[12:08] <jbicha> (since we have been backporting new webkit2gtk releases to 16.04 LTS as security releases)
[12:08] <jbicha> no
[12:08] <jbicha> deprecated webkit doesn't get new releases
[12:08] <doko> and it cannot be built with GCC 7?
[12:09] <jbicha> it can build with gcc-7 but gcc-6 & gcc-7 aren't in xenial currently
[12:10] <doko> well, package a new gcc-mozilla then ... but then do it with gcc-7 because that will be the one in the next lts
[12:12] <jbicha> ok, thanks
[12:46] <ahasenack> slangasek: thanks for moving ubuntu-advantage-tools to main
[12:58] <coreycb> hello release team, can we demote python-zunclient from main to universe? At this point it is just listed as a Build-Depend and Suggests.
[13:18] <jbicha> coreycb: it's already in universe https://launchpad.net/ubuntu/+source/python-zunclient/+publishinghistory
[13:18] <jbicha> https://people.canonical.com/~ubuntu-archive/madison.cgi?package=python-zunclient
[13:19] <coreycb> jbicha: ah, great. i got a proposed-migration warning this morning so maybe it was handled today.
[13:22] -queuebot:#ubuntu-release- Unapproved: python-oslo.middleware (zesty-proposed/main) [3.23.1-0ubuntu1 => 3.23.1-0ubuntu1.1] (openstack, ubuntu-server)
[16:02] <elopio> ping doko . Sergio tells me there are snapcraft issues in artful. Do you have a link?
[16:13] <ogra_> elopio, (from #snappy )
[16:13] <ogra_> oko> snapcraft autopkg test failure<EMAIL_ADDRESS> output: {{{b'/snap/godd/x1/bin/godd: relocation error: /snap/godd/x1/lib/x86_64-linux-gnu/libpthread.so.0: symbol __mmap, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference\n'}}}
 but it's built with glibc-2.26 ...
[16:17] <elopio> huh, this is running the snaps, not building them.
[16:22] <nacc> ogra_: interesting that's the error i got with my artful build of classic snap too
[16:23] <nacc> (for a different library)
[16:23] <ogra_> nacc, yeah, see the discussion from #snappy :) i mentioned that ...
[16:24] <nacc> ogra_: ah sorry
[16:24] <ogra_> but unlikely to be actually related i think
[16:24] <ogra_> especially since the above happens during build
[16:25] <nacc> ogra_: isn't the output from running hte pyhooks snap?
[16:26] <nacc> ogra_: or running any snap i this case?
[16:26] <ogra_> might be
[16:26] <nacc> ogra_: i'll read the logs a bit myself and see the backlog in #snappy
[16:26]  * ogra_ actually looks at the log
[16:27] <ogra_> well, there wasnt much beyond the above and me saying "ah. i ahve seen that but only with classic on artful"
[16:28] <nacc> heh
[16:28] <nacc> ogra_: ok :)
[16:28] <ogra_> the snaps failing in the test are non-classic though
[16:28] <nacc> yep, understood -- tbh, my snap (well, the wrapper snapd ends up calling in my snap) is a lot like a non-classic snap. Except for it's write permissions.
[16:29] <nacc> so I *could* see it being similar, in terms of what library is from where and why
[16:29] <nacc> but again, i don't see how it would work with non-classic snaps either, if built on artful
[16:29] <nacc> i guess i don't konw what's built where :/
[16:30] <nacc> i would assume the snapcraft tests actually build the snap?
[16:30] <ogra_> thats a question for elopio i guess
[16:31] <nacc> yeah, it looks like it builds it (aroudn the middle of the log). I think it has to build it on the host, but it's not clear from the logs
[16:32] <nacc> elopio: --^ ?
[16:34] <elopio> nacc: yes, the test builds and runs snaps.
[16:36] <ogra_> elopio, it builds them on artful using artful deps ?
[16:36] <ogra_> that cant work ...
[16:36] <ogra_> (especially after the libc update)
[16:37] <slangasek> sergiusens: well, I think it's perhaps a "rush" in the sense that it might show that snapcraft, or the core snap, is currently broken on top of artful
[16:37] <ogra_> (since it will run them on top of the xenial core afterwards)
[16:37] <nacc> yeah, this is the same issue my classic snap has
[16:37] <nacc> it feels like this is another argument for "don't build on artful" :)
[16:37] <nacc> if it also affects confined snaps :)
[16:38] <ogra_> slangasek, nah ... that has never really worked (if it did, tha was by sheer luck) and should never have been promoted as "supported"
[16:38] <slangasek> nacc: well, it's at least an argument for "don't put half of glibc in your runtime and the other half in your snap"
[16:39] <ogra_> do never ever build snaps with host dependencies unless you are on xenial ... thats the only meme here
[16:39] <slangasek> but what's unusual is that the snapcraft testsuite errors reference only GLIBC_2.25... which is not the xenial, zesty, or artful version
[16:39] <ogra_> and the reason for snapcraft cleanbuild to exist
[16:39] <ogra_> yes, thats a bit weird indeed
[16:39] <nacc> ogra_: good poinnt, so i think if the snapcraft dep8 tests did cleanbuilds, they might pass
[16:40] <nacc> ogra_: although that would potentially required nested lxd on all archs where it runs
[16:40] <ogra_> yes, for sure
[16:40] <ogra_> since the lib versions match the core version the snaps are executed on
[16:40] <nacc> slangasek: the issue is glibc is blacklisted (at least that's what we think) so none of it is in the snap
[16:40] <ogra_> right
[16:40] <ogra_> the libc version in use comes from the core snap
[16:41] <nacc> slangasek: so building on artful leaves link-time dependencies to be satisfied by core, which is xenial, regardless of where your snap built
[16:41] <slangasek> nacc: libpthreads, libdl are part of glibc; they are showing up as symbol mismatches
[16:41] <nacc> slangasek: hrm
[16:41] <nacc> slangasek: maybe it's not a good ennough blacklist :)
[16:41] <slangasek> so it's possible libc is blacklisted but the other bits are not
[16:41] <nacc> slangasek: yeah, in my case (git-ubuntu) it was libdl that threw the error
[16:41] <slangasek> mind you, not /all/ of the test failures were this - but at least some of them are lolwut why are you splitting glibc
[16:41] <ogra_> https://launchpadlibrarian.net/337868387/core_16-2.27.6+git381.783a1f9_amd64.manifest
[16:41] <ogra_> libc-bin	2.23-0ubuntu9
[16:41] <ogra_> libc6:amd64	2.23-0ubuntu9
[16:41] <ogra_> libc6:i386	2.23-0ubuntu9
[16:41] <ogra_> hmmmmm
[16:41] <ogra_> mmm
[16:41] <ogra_> m
[16:42] <ogra_> slangasek, but we are not splitting it
[16:42] <ogra_> the one shipped in core is mandatory
[16:42] <slangasek> ogra_: have you looked at the errors in the log?
[16:43] <ogra_> and snapcraft has code to prevent the libc package to ever end up inside a snap app package
[16:43] <ogra_> yes
[16:43] <slangasek> there are paths referring to libdl.so and libpthreads inside the snap being tested
[16:43] <ogra_> i see the mention of 2.25
[16:43] <slangasek> which means these libraries have not successfully been blacklisted from exclusion from the application snap
[16:43] <ogra_> ah
[16:43] <ogra_> yeah
[16:44] <ogra_> so thats the issue then (still though ... why do they link against 2.25 ?)
[16:45] <ogra_> hmm
[16:47] <nacc> is the bug i snapcraft (not the link, but the libc blacklist) that snapcraft/internal/libraries._get_system_libs looksl ike this: http://paste.ubuntu.com/25593456/
[16:47] <nacc> that's a hardcoded only libc.so.6
[16:47] <ogra_> well, snapcraft explicitly denies installation of libc6
[16:48] <ogra_> $ dpkg -S /lib/x86_64-linux-gnu/libpthread.so.0
[16:48] <ogra_> libc6:amd64: /lib/x86_64-linux-gnu/libpthread.so.0
[16:48] <ogra_> and also:
[16:48] <ogra_> ls -l /snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0
[16:48] <ogra_> lrwxrwxrwx 1 root root 18 Sep 12 08:36 /snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0 -> libpthread-2.23.so
[16:48] <ogra_> so there shouldnt be a libpthread.so.0 inside the godd snap
[16:48] <nacc> ogra_: ah ok
[16:49] <ogra_> because of the blacklist
[16:49] <ogra_> and the one from core should be used
[16:49] <ogra_> the question is how did it sneak into the godd snap
[16:50] <nacc> ogra_: where is the blacklist implementation? repo/_base:_fix_symlink ?
[16:50] <nacc> ogra_: i'm not seeing that many references to libc in the source
[16:50] <ogra_> not sure, sergiusens or kyrofa would know
[16:51] <ogra_> there is a txt file somewhere that snapcraft parses
[16:51] <ogra_> but at the same time it also walks ldd output for the built binaries
[16:51] <ogra_> and i think the txt file (the actual blacklist) applies to deb package names ...
[16:52] <ogra_> not sure if there is any verification against deb contents for the blacklisting
[16:53] <elopio> snapcraft/internal/repo/manifest.txt
[16:54] <ogra_> yeah
[16:54] <ogra_> and that only lists deb names
[16:56] <slangasek> coreycb: strange that you got an email about python-zunclient, that seems to have been in response to me fixing the component on the version in -proposed... taking it /off/ of component-mismatches.  Well, another thing to debug at some point
[16:57] <coreycb> slangasek: interesting, ok
[16:58] <elopio> There's also libraries/16.04
[16:59] <nacc> elopio: libdl.so.2 is listed twice? is that file generated?
[17:00] <ogra_> well
[17:01] <ogra_> that lists 16.04 versions
[17:01] <ogra_> hmm, but the link versions
[17:02] <nacc> i'm very cofused by snapcraft/internal/libraries.py
[17:02] <nacc> if you're building on 17.10
[17:02] <nacc> it wo't find any libs file
[17:02] <elopio> nacc: should be: libraries/generate_lib_list.py
[17:02] <nacc> or does it generate it if it's not there?
[17:03] <nacc> i wonder if that's this bug? no libraries file found, so only libc.so.6 is excluded
[17:03] <elopio> nacc: and yes, that's what I was trying. Making a libraries/17.10, and see what happens on artful.
[17:03] <nacc> elopio: _get_system_libs specifically
[17:03] <nacc> elopio: yep
[17:03] <elopio> but well, I'm very lost on this code too. For this, we need kyrofa or sergiusens.
[17:03] <ogra_> i guess kyrofa actually
[17:03] <ogra_> iirc he wrote that bit and the ldd crawler
[17:06] <ogra_> grep pthread /home/ogra/Devel/branches/snapcraft/libraries/16.04
[17:06] <ogra_> libpthread.so.0
[17:06] <ogra_> libpthread.so.0
[17:06] <ogra_> also interesting that this is listed twice inn a row
[17:06] <nacc> ogra_: yeah lots of dupes in that file
[17:06] <ogra_> seems others actually follow the symlink and list link as well asbinary lib
[17:07] <ogra_> which might be because libpthread-2.23.so actually has a dash in the version ? (wild guess)
[17:08] <ogra_> well, whatever ...  we'll need kyrofa
[17:08] <nacc> so it seems like there might need to be two independent fixes (IMO, not konwing anythign about snapcraft): 1) there should be lib lists for all supported build targets; 2) the fallback for only excluding libc.so.6 itself is too narrow and will almost always (with libc mismatches) lead to issues like this -- it should be all libraries provided by libc
[17:08] <nacc> (the bin pkg)
[17:08] <ogra_> well ... 1) there is only one build target :)
[17:08] <ogra_> thats the whole point
[17:09] <nacc> ogra_: true, so the the artful self-tests need to use cleanbuild as well :)
[17:09] <ogra_> yeah
[17:09] <nacc> *artful snapcraft dep8 tests
[17:10] <ogra_> elopio, do you know if there is a reason behind not using cleanbuild in that test ?
[17:10] <ogra_> (and thus pulling in artful deps that will clash with the core snap anyway)
[17:11] <ogra_> (even beyond this libc issues that will cause probs, but perhaps there is some valid reason to actually build native on artful)
[17:18] <elopio> ogra_: mainly, that we couldn't use lxc until recently. But also, I think one of our goals is to be able to build snaps in any distro and use them in any distro.
[17:19] <elopio> I'm not totally sure about that last one. Now that our container builds story is getting a lot better, I think it could make sense to always build in x.
[17:19] <sergiusens> there are two things at play here, the package blacklist and then there's the thing i have been wanting to get rid of for ages but brings in some breakage, there's library collecting from the host so you don't need to bring in the equivalent stage-packages entry for everything that would be satisfied by a build-packages entry
[17:20] <ogra_> ellwell, the last one will definitely not work until we have base snaps for all possible releases and distro combos
[17:20] <ogra_> elopio, ^^
[17:20] <ogra_> sergiusens, well, even if your blacklist works using artful libs inside of snaps that run on top of a xenial core screams for breakage
[17:21] <ogra_> sergiusens, that can work once there are base snaps and an artful-base exists .. but not before
[17:21] <ogra_> the test should just use cleanbuild if possible
[17:21] <elopio> with libraries/17.10, godd works built and run in artful.
[17:21] <ogra_> matter of luck :)
[17:22] <nacc> yeah, it seems like you're just not hitting some ABI change, right?
[17:22] <ogra_> (though its is go ... that will behave better anyway ... if your snap includes actual libs via stage-packages that can quickly fall apart)
[17:22] <nacc> but it's possible to get an ABI change in any of this that might break an app?
[17:22] <sergiusens> ogra_ the only requirement we were given for anything other than xenial (and in future, not built using a proper base) is that people should be allowed to experiment
[17:22] <elopio> ogra_: I wasn't saying it was a good solution, just reporting on my experiment :)
[17:22] <ogra_> sergiusens, sure ... and keep the pieces
[17:23] <nacc> elopio: if nothing else, that fix allows people to continue to usupported experiment
[17:23] <ogra_> sergiusens, but surely nothing you should use in an official test
[17:24] <ogra_> anyway, myth solved \o/
[17:24] <nacc> the implication is, also, though that there is a missing unit or integration test for this, right?
[17:24] <sergiusens> ogra_ the tests were fine as they allowed us to know where we standed, now I need to sit down and think
[17:24] <sergiusens> nacc what is missing?
[17:24] <ogra_> heh, thats another way to put it indeed :)
[17:24] <nacc> sergiusens: a snap was allowed to build using components of libc from a distribution and nnot the core snap
[17:25] <nacc> sergiusens: and ship said components in their sap
[17:25] <nacc> *snap (my n key is struggling!)
[17:25] <sergiusens> nacc oh, that is what we were told to allow and not worry about
[17:25] <ogra_> lol
[17:25] <nacc> who in the world said that?
[17:25] <nacc> it can't work...
[17:25] <ogra_> well
[17:25] <sergiusens> nacc I'd rather not mention ;-)
[17:25] <nacc> ok, it *might* work in some cases :)
[17:25] <ogra_> it would work if you included *all* of libc
[17:25] <nacc> yeah
[17:25] <nacc> you can't include part of it, that's the point slangasek was making
[17:25] <ogra_> the issue here is that only pieces of the libc package were included
[17:26] <ogra_> i.e. not libc itself
[17:26] <nacc> ogra_: yep
[17:26] <ogra_> but libpthread
[17:26] <ogra_> and libdl
[17:26] <nacc> well everythingn but libc.so.6 :)
[17:26] <ogra_> right
[17:26] <nacc> elopio:
[17:26] <nacc> elopio'
[17:26] <sergiusens> ogra_ ah, ic; that can be fixed
[17:26] <nacc> bah! that filelist fix will fix that, at least
[17:27] <sergiusens> nacc I would rather just not auto include anything :-)
[17:27] <ogra_> sergiusens, nut that wont help with other libs that are linked against a newer libc ... which will fall apart equally
[17:27] <sergiusens> this is a perfect excuse for that
[17:27] <ogra_> s/nut/but/
[17:27] <nacc> sergiusens: what do you mean by auto include?
[17:27] <ogra_> (unless the actual libc they link against gets included fully in the snap indeed)
[17:27] <sergiusens> and just raise en error with missing libraries that people will figure out with stage-packages or not
[17:30] <sergiusens> nacc say you say `build-packages: [licurl-dev]`, this would install -dev and libcurl on the host; if you noticed, you don't need to add a `stage-packages: [libcurl]` entry because we crawl the host for libraries to make things easier; I have disliked this feature since forever and given the no break policy we just left it there and added an entry t
[17:30] <sergiusens> o not do this. It seems it would be beneficial for everyone that this not be done automatically at all and raise an error with the missing libraries you have. Anyhow, this is getting snapcraft specific, not sure if worth discussing on #ubuntu-release anymore
[17:31] <nacc> sergiusens: +1 on being as explicit as possible
[17:35] <nacc> ogra_: but this still does't explain the wrong GLIBC version in the logs, right?
[18:19] <doko> slangasek: the reason that you see GLIBC_2.25 is that this is the symbol version. glibc 2.26 didn't have any new symbols compared to glibc-2.25.
[18:19] <nacc> doko: ah that makes sense
[18:20] <nacc> doko: so it is the 2.26 version of the other libs showing that
[18:20] <nacc> doko: thanks!
[18:20] <slangasek> doko: aha, check
[18:21] <doko> what *might* happen is that you see https://sourceware.org/bugzilla/show_bug.cgi?id=22150
[18:21] <doko> or LP: #1715641
[18:21] <doko> if that was built with a binutils (<< 2.29-12)
[18:22] <doko> but I didn't investigate that
[18:23] <nacc> doko: i think we understand (to some degree) why this is happenning to snaps
[18:28] <doko> I think you'll have some fun with glibc-3.0, when glibc starts dropping deprecated symbols ... and keeping the soname
[18:29] <nacc> doko: ugh
[18:29] <nacc> doko: yeah :)
[18:36] <infinity> Eh?  We won't drop symbols and keep the soname.
[18:36] <infinity> That would be madness.
[18:37] <nacc> infinity: that's what i would have thought, but i was trusting doko :)
[18:38] <doko> infinity: that's the long term plan for glibc-3.0, yes. speak with upstream, carlos and florian
[18:39] <infinity> doko: That's a curious new take on things.  I will indeed talk with Carlos.
[18:39] <infinity> It's always in the past been understood that dropping symbols would be libc7.
[18:41] <doko> but the next versions will be .27 and .28 ...
[21:26] <slangasek> doko: the bogl ftbfs is some sort of toolchain bug; an inline function disappears and generates "undefined reference" when building with -Os


[07:17] <abogani> holstein: No I don't play music. I like listen only :) Lately one of my friends, jazz addicted, let me listen his cds and the last artist who I remember was Wes Montgomery...
[13:20] <ScottL> hi falktx
[13:21] <falktx> hi ScottL
[13:25] <falktx> ScottL: i still plan to make a testing ubuntustudio live dvd
[13:25] <falktx> ScottL: my laptop broke and has been in reparing this all time...
[13:26] <ScottL> falktx, cool :)
[13:27] <ScottL> falktx, sorry :(
[13:27] <falktx> it's ok
[13:27] <falktx> I'm finally going to have network at my house...!
[13:30] <astraljava> falktx: Congrats! /me just got it a week ago, so I still remember how it feels :D
[18:42] <scott-work> still working on a ubuntu studio header for the wiki.u.c. pages   https://wiki.ubuntu.com/UbuntuStudio/Sandbox
[18:42] <scott-work> comments encouraged
[18:42] <holstein> scott-work: you know about the theme change of course right?
[18:43] <holstein> akgraner was just telling our loco about it in our metting yesterday
[18:43] <holstein> meeting*
[18:48] <scott-work> holstein: not sure, do you mean orange with new font?
[18:48]  * scott-work admits there are LOTS of things he doesn't know
[18:49] <scott-work> i tend to insulate myself with ubuntu studio and often am out of step with ubuntu in new transitions
[18:52] <holstein> scott-work: yeah
[18:53] <holstein> the 'light' theme or whatever
[18:53] <holstein> instead of the current
[18:53] <holstein> i forget when thats final
[18:53] <holstein> soon though
[18:53] <scott-work> i also need to udpate the current release notes :( https://wiki.ubuntu.com/UbuntuStudio/WorkingReleaseNotes
[18:53] <scott-work> i don't think the 'light' theme will be included in studio
[18:53] <scott-work> i know it shouldn't be installed as default ;)
[18:54] <holstein> wiki theme
[18:54] <holstein> on all wiki pages AFAIK
[18:54] <holstein> if you go to a wiki page
[18:54] <holstein> and your logged in
[18:54] <scott-work> huh, no i didn't know the wiki was changing themes
[18:54] <holstein> you change to the 'light' theme
[18:54] <holstein> and thats what its going to be
[18:54] <holstein> the orange-ish deal
[18:55] <holstein> we were told to make sure our nc wiki pages worked before the switch
[18:55] <holstein> scott-work: probably not a big deal at all
[18:55] <scott-work> oh, i just checked and my preferences were set to "classic theme"
[18:55] <scott-work> changed it to default, waiting to see how it chagnes the page
[18:55] <holstein> just when your choosing colors
[18:55] <holstein> might help
[18:55] <scott-work> ohhh, much pretty, more aligned with help.u.c
[18:56] <scott-work> less ugly, less wiki-looking :P
[18:56] <JFo> still fixed width :-/
[18:56] <scott-work> the colors for the wiki look the same though
[18:56] <scott-work> lol jfo, very true
[18:57] <JFo> :)
[18:57] <scott-work> holstein: and i'm not good with colors (not color blind mind you, just crappy with colors) but i was trying to use some of the ubuntu studio colors
[18:58] <holstein> hey JFo :)
[18:59] <JFo> heya holstein
[18:59] <JFo> need to get you some servers :)
[19:05] <holstein> JFo: i might be coming this weekend
[19:05] <holstein> i'll let you know
[19:06] <holstein> saturday is the tentative hang with AK
[19:06] <JFo> cool
[19:07] <JFo> think her daughter has a competition in SC on Sat, but I don't know the time.
[19:07] <JFo> I'll def be around
[19:10] <scott-work> holstein: i was trying to use colors from this:  https://wiki.ubuntu.com/UbuntuStudio/Artwork/DIYConcept#Color%20Palette
[19:10] <scott-work> if anyone wants to suggest other colors or even color that match better i'm all good for it :)
[19:11] <scott-work> maybe make the CoF with blue background and then use a different background color for the table cell
[19:50] <scott-work> holstein: oh, dizzam!  I didn't change my wiki preferences to the 'light' theme, i had just chosen 'defualt'
[19:51] <scott-work> i see the change you are describing
[19:53] <holstein> scott-work: :)
[19:53] <holstein> cool
[19:53] <holstein> just so you know
[19:53] <holstein> so you dont waste any effort
[19:54] <holstein> its the right time for it
[19:54] <holstein> later this month they all go to that i was told
[19:55] <scott-work> holstein: now i know also why you were asking about colors ;)
[20:03] <holstein> yeah, we gotta revamp our banner too i think
[20:03] <holstein> i think some of the text goes orange
[20:32] <scott-work> holstein: yes, the links are orange


[00:50] <thumper> babbageclunk: let's chat
[00:51] <babbageclunk> thumper: sure - 1:1
[00:51] <thumper> ok
[02:00] <wallyworld> anastasiamac: not sure if you have time for a review? https://github.com/juju/juju/pull/8514
[02:01] <anastasiamac> wallyworld: i can try :)
[02:01]  * anastasiamac looking while lunching :D
[02:01] <wallyworld> ty, spreading the love around
[02:01] <wallyworld> have lunch first
[02:01] <wallyworld> there's no rush
[12:30] <balloons> jam, have to reboot the PC
[12:31] <jam> balloons: k
[12:32] <jam> manadart, externalreality: btw, I added a card on the ha-space stuff that Tim pointed out. Namely "juju enable-ha --to X" should check that X is in the ha-space and prevent you from doing so if it isn't
[12:33] <manadart> jam: Yes, saw it; thanks.
[16:37] <manadart> jam externalreality: PR for the multi-address/no-ha-space-config is up.
[16:37] <manadart> https://github.com/juju/juju/pull/8517
[16:38] <manadart> Only the second commit is relevant, as per description.
[17:16] <jam> manadart: reviewed
[17:24] <cmars> hi balloons, could i get a review of https://github.com/juju/juju/pull/8513 ? this exposes labels in the `juju metrics` command output
[19:37] <thumper> morning
[19:43] <wpk> evening
[19:57] <hml> review anyone?  https://github.com/go-goose/goose/pull/62
[20:37] <hml> wpk: on pr8407, for createDefaultBridgeInDefaultProfile() why only ipv6 settings and not ipv4?
[20:44] <wpk> hml: because we offically support only ipv4 on LXD, we even have special error messages for that occassion :)
[20:45] <wpk> hml: we should do it for v6 to, but I wouldn't make it in this PR
[20:46] <hml> wpk: something isn’t parsing in my brain… we write ipv6 settings because we only support ipv4?
[20:48] <wpk> hml: we disable v6 explicitly
[20:49] <wpk> hml: that's what we've been doing previously, we could 'fix' that bug, again, not this PR
[20:49] <hml> wpk: duh - ipv6.address: none
[20:49] <hml> does the network already contain ipv4 information?
[20:49] <wpk> hml: by default
[20:49] <hml> or the profile
[20:49] <hml> ah
[20:49] <hml> i missed the word none  :-)
[20:52] <balloons> hml, I left some comments for you
[20:52] <hml> balloons: ty
[21:01] <hml> —keep-broken only applies to bootstrap yes?
[21:03] <balloons> veebers, appears you are correct. We can't use our awesome versioning anymore it seems for snaps
[21:09] <balloons> I take that back, our version is missing something
[21:17] <wpk> balloons: btw
[21:17] <wpk> balloons: I had a weird 'hang' in CI run today
[21:17] <wpk> balloons: let me find the run...


[00:24] <racarr> kgunn: image fails
[00:25] <racarr> are there older images
[00:25] <kgunn> racarr: thanks... rsalveti how far back can we go ? ^
[00:25] <racarr> I have a copy of
[00:25] <racarr> july 26th
[00:25] <racarr> on my desktop it seems
[00:26] <racarr> thats kind of far though XD
[00:26] <kgunn> so 12th would be 1 week...and the bug describes it popping up ~2 weeks ago
[00:27] <kgunn> racarr: question...is the hwcomposer.h etc matching from the 12th to current  ?
[00:27] <racarr> no hwcomposer.h on the image
[00:28] <racarr> lets check hardare.h though
[00:28] <kgunn> racarr: yeah...that's what i meant
[00:28] <kgunn> gralloc and fb as well
[00:29] <racarr> yep
[00:29] <racarr> the same
[00:29] <racarr> ok im going to september 26th because
[00:29] <racarr> err
[00:29] <racarr> uly 26th
[00:29] <racarr> because I dont have anything else to do :p
[00:31] <racarr> kgunn: maybe check your ~/Downloads/phablet-flash
[00:31] <racarr> for images?
[00:31] <racarr> though
[00:31] <racarr> i e dont have the images elsewhere
[00:31] <kgunn> racarr: will do
[00:31] <racarr> then bisecting probably ont help much
[00:32] <kgunn> also...as you're building, check the ubuntu/hybris/hybris/include/android/hardware/ and see how those headers compare
[00:32] <kgunn> 26th vs current
[00:34] <racarr> ubuntu/hybrys/hybris/hat
[00:34] <racarr>  /what?
[00:34] <kgunn> racarr: i have a jul 25th :)
[00:34] <racarr> I have been looking in /usr/include/android
[00:35] <kgunn> oops...nvmd...i was looking in source i downloaded
[00:35] <kgunn> that's where they are before image creation
[00:35] <racarr> XD
[00:35] <kgunn> ./ubuntu/hybris/hybris/include/android/hardware/fb.h
[00:35] <kgunn> etc
[00:35] <racarr> thats a hell of a path
[00:35] <racarr> I realized
[00:35] <racarr> e can rule in our out the headers
[00:35] <racarr> in an easy ay
[00:36] <racarr> well that whole theory
[00:36] <racarr> did surface flinger change?
[00:36] <racarr> I guess that doesnt necessarily rule it out
[00:36] <kgunn> whathcya mean?
[00:37] <racarr> I mean we have this theory that libhardware changed
[00:37] <racarr> and it broke mir because mir has the static in tree headers
[00:37] <racarr> but if surface flinger didn't change
[00:37] <racarr> that seems unlikely
[00:42] <kgunn> racarr: right...but isn't it truly in tree for surface flinger (e.g. he's not gonna get headers outta sync)
[00:42] <kgunn> since its all just part of android
[00:46] <racarr> kgunn: Right I am just saying if e literally haven't updated
[00:46] <racarr> the surfaceflinger binary
[00:52] <racarr> havent tested this image yet but want to go get pizza before the bakery closes
[00:52] <racarr> back soon
[00:53] <kgunn> racarr: actually....i think i just found a jul 29 & aug 9 images
[00:54] <racarr> I am trying to build mir on this image...but
[00:54] <racarr> build deps are pulling in a hybris upgrade
[00:54] <racarr> so it would be not so surprising if it didn't work?
[00:55] <racarr> ghsdflKSDfljLKsdgjldkfjglkdjglkejrg;lakerjgl;kejrgt
[00:55] <racarr> just a little keyboard mashing :p
[00:55] <racarr> brb pizza
[01:09] <RAOF> Ah, yes.
[01:09] <RAOF> It's important not to leak fds.
[01:14] <RAOF> Huh. Something's broken in our resource cache it seems.
[01:32] <racarr> back
[01:35] <kgunn> racarr: dont we  rebuild surfaceflinger from source everytime ? (i thot we built the whole android file system...for what we have source for)
[01:35] <kgunn> stepping out...biab
[01:37] <racarr> kgunn: yeah I guess its probably never the same
[01:37] <kgunn> racarr: just comparing bins of libsurfflinger they are diff between jul 25 & latest
[01:37] <kgunn> but not surprising
[01:37] <kgunn> ok...really stepping out
[01:41] <duflu> racarr: is surface flinger relevant to the Nexus4 bug? We intentionally disable it to run Mir (usually)
[01:45] <racarr> kgunn: july 26th works!
[01:45] <racarr> duflu: No but one of the theories is that there is a libhardware mismatch
[01:45] <racarr> but I didn't relize we rebuilt surface flinger everytime
[01:45] <duflu> I see
[01:46] <racarr> duflu: Want to check your ~/Downloads/phablet-flash and see if you have any images beteen
[01:46] <racarr> july 26th and august 18th
[01:46] <racarr> and can verify mir orks/doesn't work on them
[01:46] <racarr> bisecting ;)
[01:46] <racarr> but I am out of images
[01:46] <racarr> err august 12th sorry
[01:47] <racarr> ricmm: rsalveti: Any way we can get images from before august 12th
[01:48] <duflu> racarr: Only July 26th (works for me I think) and August 8th (broken)
[01:49] <racarr> August 8th broken. Awesome
[01:49] <racarr> kgunn: ^
[01:50] <duflu> racarr: At least that appears to be the latest one I have. And the latest broke my N4
[01:50] <duflu> Though surely we can get image dates/versions from the devices?
[01:51] <racarr> duflu: The problem right now is cdimages.ubuntu.com
[01:51] <racarr> only has back to august 12th :p
[01:51] <racarr> so I am trying to bisect
[01:51] <duflu> racarr: Yeah Albert logged the bug on 13th a few days after he first mentioned it. Because it took me a few days to upgrade and confirm
[01:51] <racarr> but the range is uly 26th to august 8th now
[01:52] <racarr> but there are no images
[01:52] <racarr> inbeteen
[01:52] <racarr> ween
[01:52] <racarr> Spill on keyboard:(
[01:52] <duflu> Pork and beans?
[01:52] <duflu> Argh
[01:52] <duflu> That would be weezer
[01:52] <duflu> I suck
[01:58] <racarr> I guess I will start
[01:58] <racarr> reading changeloads
[01:58] <duflu> racarr: Actually 20130808 may not be accurate. The download date for that was 20130813 and I remember I did an update immediately after
[01:59] <duflu> Will have to reflash it without updates to confirm
[01:59] <racarr> Ah! thanks.
[01:59] <racarr> lxc-android-config (0.67) saucy; urgency=low
[01:59] <racarr>   * allow devices that use EFS as label for the factory partition to mount it
[01:59] <racarr>     under /efs instead of /factory
[01:59] <racarr> that means anything
[02:00] <racarr>  -- Oliver Grawert<EMAIL_ADDRESS>Sun, 04 Aug 2013 12:24:23 +0200
[02:00] <racarr> I wonder if
[02:00] <racarr> I have nothing in /factory on the working image so probably not
[02:00] <racarr> I dont know what a /factory is though
[02:00] <racarr> im going to bisect
[02:00] <racarr> lxc-android-config
[02:01] <racarr> because permissions are suspect
[02:01] <racarr> oh I can't really do that as easily as I want to
[02:03] <racarr> ok I upgraded lxc-android-config
[02:03] <racarr> and it still works
[02:03] <racarr> im going to upgrade packages one at a time lol
[02:05] <racarr> that was kind of silly :p not even sure what to try next
[02:06] <racarr> no hybris updates
[02:06] <duflu> N4 sez: Not enough charge to turn on yet. This seems to happen a lot
[02:07] <racarr> lets upgrade lxc
[02:07] <racarr> duflu: Happens to me a lot too :( and you can
[02:08] <racarr> use more poer than you get off low power USB compiling
[02:08] <racarr> mir
[02:08] <duflu> racarr: Yeah I put it on mains for a while
[02:09]  * duflu wonders if the USB 3 port would have more power than USB 2
[02:09] <racarr> Maybe
[02:11] <racarr> not lxc! let's upgrade apparmor
[02:11] <racarr> im staring at a list of like 200 packages trying to pick ones that could be relevant lol
[02:13] <duflu> racarr: Maybe consider those that Mir depends on
[02:16] <racarr> duflu: Mm. should just start with that
[02:21] <racarr> all the build deps
[02:21] <racarr> are newest version
[02:22] <racarr> as are the dependencies
[02:22] <racarr> except or
[02:22] <racarr> multiarch support
[02:22] <racarr> *tests*
[02:24] <duflu> racarr: phablet-flash has no options to specify an image file(s) any more. Any clue?
[02:24] <racarr> duflu: You have to use clockwork mod
[02:24] <racarr> duflu: You flash the armel+dev first then the armhf
[02:24] <duflu> Great. Later then
[02:24] <racarr> you have to use adb push file /sdcard/
[02:24] <racarr> instead of
[02:24] <racarr>  /sdcard
[02:24] <racarr> or it ust silently fails ater taking
[02:24] <racarr> forever
[02:24] <racarr> lol
[02:25] <racarr> aw not multiarch support either
[02:28] <RAOF> Grr overlapping outputs.
[02:34] <racarr> ok I think I narrowed it don to a set of 20 packages
[02:35] <racarr> is there an easy way to reverse my last
[02:35] <racarr> apt transaction
[02:36] <racarr> http://pastebin.ubuntu.com/6004993/
[02:36] <racarr> something in here killed it'
[02:37] <racarr> http://pastebin.ubuntu.com/6004994/
[02:37] <racarr> this is suspiscious
[02:44] <racarr> reverting back to working image to narrow the list
[02:45] <racarr> Setting up initramfs-tools-ubuntu-touch (0.34) ...
[02:45] <racarr> seems sort of sketchy
[02:45] <racarr> compared to everything else at least
[03:21] <smspillaz> racarr: arrrround?
[03:27] <racarr> smspillaz: Enthusiastically!
[03:33] <kgunn> racarr: you're awsome...so down to 20 packages, somewhere between jul 26 & aug 8
[03:35] <racarr> kgunn: Actually just got a working system again and clicking, so more like 19 packages lol
[03:35] <racarr> really only like 4 or 5 that seem reasonable we should know super soon
[03:36] <kgunn> racarr: cool
[03:37] <smspillaz> duflu: so I don't know if something I'm seeing is a bug in the mir buffer swapper or a bug in my code
[03:37] <kgunn> duflu: ping
[03:38] <smspillaz> duflu: basically if I do draw1 -> swap1 -> draw2 -> swap2 -> draw3 -> swap3
[03:38] <smspillaz> I seem to see something like
[03:38] <smspillaz> after swap1 : nothing after swap2 : draw1 after swap3: draw2
[03:38] <smspillaz> (using mir_surface_swap_buffers directly)
[03:39] <duflu> smspillaz: Do you have a very recent server?  Its a setuid thing that talks to pam to get the invoking env, handles all of the vt switching and drmSetMaster/drmDropMaster stuff and then runs weston as user
[03:44] <duflu> smspillaz: Oh right. I have thought about similar
[03:44] <duflu> Someone just has to do it
[03:44] <smspillaz> lol
[03:45] <smspillaz> it makes life a lot easier :)
[03:45] <racarr> smspillaz: Ill take care of it on Yotday, the imaginary day I just invented inbetween
[03:45] <racarr> now and featufre  freeze
[03:45] <racarr> :p
[03:45] <smspillaz> though admittedly not as useful anymore because logind no longer allows arbitrary processes other than init to spawn new sessions
[03:46] <smspillaz> so it has to start on the same vt you launched it on as opposed to starting on a new one
[03:46] <RAOF> As long as you don't want VT switching you should be able to run mir_demo_server_shell as your user directly.
[03:47] <smspillaz> RAOF: don't you need root for input?
[03:47] <smspillaz> I seem to recall that's what half of what weston-launch was about
[03:47] <RAOF> sudo chown smspillaz /dev/input/**/*
[03:47] <smspillaz> or maybe that was to do with vt-switching and input
[03:48] <smspillaz> RAOF: :/
[03:48] <RAOF> smspillaz: Hey, it's harmless¹
[03:48] <RAOF> ¹: As long as you trust everything on your box
[03:49] <smspillaz> I guess my alternative solution of doing source /home/smspillaz/.bashrc was probably not better
[03:49] <smspillaz> (so that I didn't have to re-type every bloody path again)
[03:50] <racarr> Nooooooooooooooooooooooooooooooooo
[03:50] <racarr> bisection failed
[03:50] <racarr> life
[03:50] <racarr> no
[03:50] <racarr> just bisection
[03:57] <smspillaz> duflu: :/ I'm still getting the one-frame lag
[03:57] <smspillaz> (correct paths and all)
[03:59] <racarr> err
[04:00] <racarr> ...I retract my err
[04:01] <smspillaz> though oddly its not happening on the demo clients which use mir_surface_swap_buffers_sync!?!
[04:02] <RAOF> Hrm
[04:03] <smspillaz> attack of the threads!
[04:06] <duflu> smspillaz: Not sure then. We have automated and easily manual testing of this issue. If you can figure out the scenario exactly that would be helpful
[04:07] <smspillaz> duflu: I'm just doing a dump of the image surface to a png to figure out what's going on for now
[04:07] <smspillaz> reeeeecompiling
[04:12] <kgunn> racarr: bisection failed as in ...you added everything back one by one to a failing image that no longer fails but actually boots with unity-mir ?
[04:12] <racarr> kgunn: I think I made a istake in thinking I hd found a broken set of packges
[04:12] <racarr> in that it just didnt ork once
[04:12] <racarr> maybe I didnt use sudo and forgot because adb history was fucked up or something
[04:12] <racarr> I dunno
[04:12] <racarr> no I am still on a orking images
[04:12] <racarr> and adding more and more packages
[04:12] <racarr> about 20 at a time then rebooting and testing
[04:13] <racarr> lol
[04:13] <racarr> this last one pulls in a bunch of stuff so I have a feeling this will break it but then to bisect this smaller list I need to go all the way back
[04:13] <racarr> and reflash
[04:14] <racarr>   ubuntu-touch-generic-initrd ubuntu-touch-session
[04:14] <racarr> these are the most suspsicious packages that I havent ruled out yet
[04:14] <racarr> all the mir dependencies and build dependencies
[04:14] <racarr> are ruled out
[04:23] <kgunn> racarr: can you pastebin the remaining packages ?
[04:24] <kgunn> just updating the bug
[04:24] <robert_ancell> thomi, is jenkins screwed up again? (https://jenkins.qa.ubuntu.com/job/lightdm-saucy-amd64-ci/85/console)
[04:24] <robert_ancell> and http://s-jenkins:8080/job/lightdm-ci/168/
[04:24] <kgunn> just in case you don't find the offender
[04:24] <thomi> it wouldn't surprise me, let me see
[04:24] <racarr> kgunn: http://pastebin.ubuntu.com/6005189/
[04:24] <racarr> almost through a bunch though
[04:25] <thomi> robert_ancell: the public jenkins has been up and down all day today
[04:25] <thomi> robert_ancell: private jenkins should be working though
[04:25] <robert_ancell> thomi, also, do you happen to know who I can poke to make a PPA have a high priority?
[04:26] <thomi> robert_ancell: #launchpad-ops
[04:26] <olli_> robert_ancell, rcimm & rsalveti
[04:26] <racarr> kgunn: http://pastebin.ubuntu.com/6005191/
[04:26] <racarr> I ust ran mir succesfully
[04:26] <racarr> after a reboot
[04:26] <racarr> and those are the only remaining packages
[04:26] <racarr> in upgrade
[04:26] <racarr> going to eat some ice cream then come back to it
[04:27] <robert_ancell> ricmm, rsalveti, you can bump PPA priorities? Can you set ppa:mir-team/qa-testing to the same priority as ppa:mir-team/staging?
[04:27] <thomi> robert_ancell: you mean build priority in the lp build queue, right?
[04:27] <racarr> going to eat icecream and revisit
[04:28] <racarr> oh
[04:28] <racarr> wow
[04:28] <robert_ancell> thomi, yeah
[04:28] <racarr> im going around in workspace switching loops
[04:28] <thomi> robert_ancell: I thought so, I've always had to ask launchpad people to tweak that for me, but maybe others have more permissons than I do
[04:29] <kgunn> racarr: icecream can only help
[04:40] <smspillaz> kgunn: so I'm working at the australian election and our counting how-to guide give the example of replacing the candidates name with "ice cream"
[04:40] <smspillaz> as an example of an informal vote
[04:41] <smspillaz> I really don't know who or why somebody would want to vote for ice cream
[04:42] <racarr> so close
[04:42] <racarr> ps daily show had coverage of australlian elections it as hilarious
[04:42] <smspillaz> racarr: I saw that!
[04:42] <smspillaz> ahh good ol' cameron diaz
[04:44] <racarr> does anyone have time to revie client-focus-notifications while I am still awake?
[04:47] <racarr> libopenobex1 libpam-systemd libpixman-1-0 libplymouth2 libpolkit-agent-1-0 libpolkit-backend-1-0 libpolkit-gobject-1-0 libsystemd-daemon0 libsystemd-login0 libupower-glib1 libusb-1.0-0 libwaudio1 login multiarch-support packagekit-plugin-click plymouth policykit-1 powerd systemd-services telepathy-gabble telepathy-ofono tzdata
[04:48] <racarr> one is evil
[04:49] <RAOF> racarr: Sure. I want that branch landed :)
[04:49] <racarr> RAOF: It feels like today is the day
[04:50] <RAOF> https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/179801 is the current one, right?
[04:50] <racarr> I'm looking for the words to say...I don't think I can hide...what I'm feeling inside...
[04:50] <racarr> RAOF: https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/180903
[04:50] <racarr> didn't you check the moon charts?
[04:51] <racarr>   libpam-systemd libplymouth2 libpolkit-agent-1-0 libpolkit-backend-1-0
[04:51] <racarr>   libpolkit-gobject-1-0 libsystemd-daemon0 libusb-1.0-0 libwaudio1
[04:51] <racarr>   multiarch-support packagekit-plugin-click plymouth policykit-1 powerd
[04:51] <racarr>   systemd-services
[04:51] <racarr> hmmm
[04:52] <racarr> im trying to eliminate ones which seem really unlikely to break mir
[04:52] <racarr> first so when I finally break it (and have to start the whole thing over again)
[04:52] <racarr> the pool is super small and I can just guess
[04:54] <racarr> libpam-systemd libplymouth2 libsystemd-daemon0 plymouth policykit-1 powerd systemd-services
[04:55] <racarr> any bets? :p
[04:55] <racarr> systemd plymouth policykit or powerd one of them broke mir on the nexus 4
[04:58]  * RAOF lays a bet on "systemd"
[04:58] <racarr> seems likely
[04:58] <racarr> it wasn't powerd
[04:58] <racarr> seeing if plymouth is the surprise offender now
[04:59] <racarr> damnit, ran demo ithout root, 30 second penalty as phone hangs.
[04:59] <racarr> :p
[05:00]  * RAOF should really get around to submitting a branch that fixes the build with clang 3.4
[05:01] <racarr> plymouth, hitelisted
[05:04] <racarr> what
[05:04] <racarr> I am fully upgraded
[05:04] <racarr> and just ran mir
[05:04] <racarr> ufahsufashfasha
[05:04] <RAOF> Huzzah!
[05:04] <RAOF> You've fixed it!
[05:05] <racarr> what if it fixed itself in the archive
[05:05] <racarr> while ive been doing this all day
[05:08] <racarr> ive been using
[05:08] <racarr> the same mir
[05:08] <racarr> binary
[05:08] <racarr> ...maybe a header changed
[05:08] <racarr> ugh
[05:08] <racarr> ok literally no headers changed
[05:10] <racarr> im flashing a latest image and upgrading to see if it really did just
[05:10] <racarr> ...fix itself
[05:15] <tvoss> good morning
[05:15] <tvoss> RAOF, we have exclusive access to the ati machine :)
[05:20] <RAOF> Excellent.
[05:20]  * RAOF is making coffee for a moment.
[05:23] <tvoss> RAOF, I'm back in ~1 hour
[05:26] <racarr> tvoss: So I've been bisecting images, until I got to august 12th broken july 26th orks then I ran out of images so I started
[05:26] <racarr> installing packages to upgrade, about 10 at a time
[05:26] <racarr> and rebooting and testing
[05:26] <racarr> at one point it seemed to break, so I bisected those packages from the working image
[05:27] <racarr> but then it always orked so I started over
[05:27] <racarr> over about 30 reboots I saw maybe 2 failures here I had to reboot, but then it alays worked until I was
[05:27] <racarr> fully ugpraded, and it still worked!
[05:27] <tvoss> racarr, wtf
[05:27] <racarr> and then I verified I asn't crazy, and the fully upgraded binary was working
[05:27] <racarr> and cmake, didn't detect any thing as touched, i.e. mir needing rebuild, in fact none of the mir
[05:27] <tvoss> racarr, could you reboot like 20 times to rule out a race?
[05:28] <racarr> build depdencies were ever upgraded
[05:28] <racarr> tvoss: I have, it seems either it always fails, or
[05:28] <racarr> just occasionally it fails in this one way that a reboot fix
[05:28] <racarr> but always works otherwise
[05:28] <racarr> what I am doing now is a clean image to see i it was
[05:28] <racarr> magically fixed in the archive
[05:28] <tvoss> okay
[05:29] <tvoss> racarr, can you compile that into an email?
[05:30] <racarr> tvoss: Yeah I am about 5 minutes away from the result on the
[05:30] <racarr> clean image then I will write things up
[05:31] <racarr> it doesn't really make any sense as far as I can see, but I was pretty careful
[05:31] <racarr> but I dunno, I haven't really zoomed back out yet
[05:31] <racarr> ive just been...in robot mode
[05:34] <racarr> ugh
[05:34] <racarr> it didn't work
[05:35] <didrocks> hey robert_ancell! Just a quick note on lightdm packaging, you took my cleanup branch, right? (https://code.launchpad.net/~didrocks/lightdm/packaging-cleanup)
[05:35] <didrocks> it was merged in the /unity one, not sure you took it for trunk
[05:36] <robert_ancell> didrocks, yeah, it's a mix of a few different packaging branches :)
[05:36] <robert_ancell> i.e. what was in the archive + the changes you made + the test changes made for CI
[05:36] <robert_ancell> will be nice to be down to one branch :)
[05:37] <didrocks> robert_ancell: indeed ;) thanks!
[05:37]  * didrocks can close a tab then \o/
[05:39] <racarr> tvoss: OK I commented on the bug
[05:44] <racarr> brain basically off now
[05:45] <RAOF> didrocks: Yo!
[05:45] <didrocks>  RAOF hey!
[05:46] <RAOF> Bah. Why aren't all the rdeps of xmir magically rebuilt when I break the ABI? :)
[05:48] <RAOF> didrocks: By the way, this patch http://paste.ubuntu.com/5983202/ worked fine; it was when we turned on logging for the msg-processor and frontend that the race disappeared.
[05:48] <RAOF> And by ‘worked fine’ I obviously mean “hung like a bastard”
[05:49] <didrocks> RAOF: was the rdepends a question for me?
[05:50] <didrocks> RAOF: ah, so you got all the info you needed?
[05:50] <RAOF> No :)
[05:50] <RAOF> didrocks: Well, we got all the information that patch provided. :)
[05:50] <didrocks> heh
[05:50] <RAOF> Which was "yes, XMir really is writing the request to the socket and is not receiving a reply"
[05:52] <didrocks> RAOF: the ATI machine is completely deprovisionned btw
[05:52] <RAOF> So I hear.
[05:52] <didrocks> (just done)
[05:53] <didrocks> if you need help to setup the environment, do not hesitate
[05:53] <RAOF> I think others are taking the lead on this bug for a while, while I get multihead for XMir done.
[05:53] <didrocks> ok
[06:14] <alf__> racarr: dpms ping
[06:22] <RAOF> I seem to be leaking ALL THE FDs
[06:23] <RAOF> But I don't think that's my fault.
[06:24] <smspillaz> the awkward moment when you have been writing C++ for so long that you forgot how to write GObjects
[06:24] <RAOF> I hear the correct way to do that is to write a DSL.
[06:25] <smspillaz> RAOF: DSL?
[06:26] <RAOF> Domain Specific Language; ie: Vala
[06:26] <smspillaz> lol
[06:26] <smspillaz> actually
[06:26] <smspillaz> I think this marks the first time this year
[06:26] <smspillaz> I will have written a GObject
[06:26] <duflu> \o/
[06:26] <smspillaz> not a cause for celebration
[06:27] <duflu> or /o\ depending on how you look at it
[06:27] <smspillaz> /o\ most certainly
[06:43] <duflu> gcc. How I hate you and your insane C++ error messages
[06:46] <RAOF> Yes
[06:53] <dholbach> good morning
[07:41] <RAOF> Hrm.
[07:42] <tvoss> RAOF, ?
[07:42] <RAOF> I think we might leak fds for clients with more than one window
[07:43] <RAOF> Or, at least, we leak ALL THE FDs when XMir has two surfaces, one for each of my displays, and we don't leak fds when XMir is only driving one display.
[07:49] <RAOF> The problem could be in the XMir code, but I thought that mirclient should handle the fds sent over the wire.
[07:51] <duflu> RAOF: Is this related?... 1194534
[07:51] <duflu> bug 1194534
[07:51] <RAOF> duflu: I don't think so; I don't call mir_connection_release
[07:52] <duflu> Ever?
[07:52] <RAOF> Ever
[07:53] <RAOF> At the moment. I guess I should at some point, but it's not hugely important.
[07:53] <duflu> RAOF: So you *should* get leaks of some sort anyway :)
[07:53] <RAOF> What *is* important is that Mir doesn't leave in excess of 1024 file descriptors open, causing X to fail to accept any new clients.
[07:54] <RAOF> duflu: Oh, sure. It just shouldn't be “there are more than 1024 file descriptors leaked by the RPC code”
[07:54] <duflu> That is indeed a lot
[08:25] <tvoss> alf__, ping
[08:26] <alf__> tvoss: pong
[08:38] <alan_g> hikiko: how is it going?
[08:39] <hikiko> hi alan_g
[08:40] <hikiko> I started a new branch here: https://code.launchpad.net/~hikiko/mir/mir.native-platform-functions and I am now replacing the functions in native platform
[08:45] <alan_g> hikiko: by "native platform" you mean *nested* platform?
[08:45] <hikiko> no
[08:45] <hikiko> I started filling the:
[08:46] <hikiko> get_ipc_package, create_internal_client, create_buffer_allocator
[08:48] <alan_g> for android and gbm?
[08:48] <alan_g> Let's first rewrite the nested functions that can be written "return native_platform->xxxxxxx();" and get that onto trunk.
[08:51] <hikiko> without implementing the xxxx() you mean?
[08:52] <alan_g> https://code.launchpad.net/~hikiko/mir/mir.native-platform-functions already has implementations (stubs)
[08:52] <hikiko> yes
[08:52] <hikiko> so I ll just call the stub functions
[08:52] <hikiko> you don't want me to implement the stubs as well
[08:53] <alan_g> If we get the nested code landed (with stubs) then we can separate work on the GBM and Android support
[08:54] <hikiko> cool
[08:54]  * alan_g likes to keep as much code on trunk as possible. (I.e. small incremental merges)
[08:57] <alan_g> hikiko: like: https://code.launchpad.net/~alan-griffiths/mir/display-is-not-output/+merge/180914 (which you could review once you've MP'd the above)
[09:25] <RAOF> Oh, that's right.  My thinkpad has pinned itself to 800MHz even though I'm building on both cores
[09:29] <duflu> Usually that only happens on low battery or high temperature...
[09:40] <RAOF> Is there some philosophical reason why all our async functions *require* valid callbacks to be passed in?
[09:45] <duflu> RAOF: I was wondering that at the start of the year. I think I proposed making them optional and it was rejected. Can't remember
[09:45] <hikiko> alan_g, https://code.launchpad.net/~hikiko/mir/mir.nested-platform-functions/+merge/181001
[09:46] <hikiko> I'll review the display-is-not-output now
[09:46] <RAOF> duflu: I guess we could have a no-op callback in mirclient?
[09:46] <alan_g> hikiko: OK (I'll review yours after I finish on session_lifecycle)
[09:47] <RAOF> Because I really *don't care* when this surface gets released
[09:47] <duflu> RAOF: It's a bit ugly and definitely suboptimal
[09:47] <duflu> RAOF: I'd prefer support for NULL
[09:47] <duflu> NULL is definitely a valid callback in some cases
[09:48] <RAOF> An explicit no-op callback is probably more self-documenting, but NULL is more idiomatic.
[09:48] <duflu> RAOF: Then to solve both: const CallbackType *noop = NULL;
[09:48] <hikiko> sure alan_g take your time
[09:49] <duflu> RAOF: Or just #define NO_CALLBACK NULL
[09:49] <RAOF> But now you need to explicitly handle NULL in mirclient!
[09:49] <duflu> RAOF: So...?
[09:50]  * RAOF is not really arguing against NULL
[10:04] <mpt> tvoss, katie: When we say surfaces aren't aware of their absolute position, what's the one-sentence reason why?
[10:08] <hikiko> alan_g, what does the POC mean here? // TODO as a POC just use the first active display
[10:09] <alan_g> "Proof Of Concept" (note to self: don't abbreviate)
[10:09] <tvoss> mpt, as seen in the past, it leads to assumptions regarding the phyiscal layout of screens for example.
[10:15] <hikiko> so, alan_g this branch just modifies the display to match the new Display interface with the multimonitor support or I am missing something?
[10:16] <hikiko> no, there's the displayoutput as well
[10:16] <alan_g> hikiko: yep
[10:19] <mpt> tvoss, when there are multiple displays, do apps know even what display each surface is on?
[10:20] <tvoss> mpt, the plan is to only communicate dpi changes
[10:21] <mpt> tvoss, thanks. Next question: If an app has three windows open, A, B, and C, and A is focused, does the app have knowledge that B is above C or vice versa?
[10:22] <tvoss> mpt, the app knows which surface is focused
[10:22] <mpt> Yes, but that's A. :-)
[10:23] <tvoss> mpt, sure :) but under the constraint that stacking only changes when focus changes, an app knows if B is over C or vice versa
[10:23] <mpt> ah, right
[10:23] <mpt> So it couldn't interrogate, but it could remember
[10:23] <hikiko> alan_g, output == context?
[10:23] <alan_g> hikiko: ?
[10:24] <tvoss> mpt, exactly. our focus policy makes sure that stacking per app only ever changes if focus changes (at least for regular surfaces)
[10:25] <mpt> tvoss, unless a window manager decides to go Amiga Intuition 1.x style and add a "Send to Back" button to every title bar. :-)
[10:25] <hikiko> I mean, a display's output (eg the nested display's output) is the sum of variables that describe the context we render in the display (the state)?
[10:25] <tvoss> mpt, hmmm, good point ;)
[10:26] <hikiko> and we ll have a different context for every display and a different display for every monitor?
[10:27] <alan_g> hikiko: there's one Display and an output for each active monitor. (At least that's what's in the native GBM code)
[10:28] <alan_g> But that's not what I've implemented for nested (yet)
[10:28] <hikiko> so each monitor is a different "buffer"/window?
[10:28] <alan_g> ack
[10:28] <hikiko> yes, I understand what you did and it looks good to me, I am just trying to get sure I understand the whole concept
[10:30] <hikiko> +can I top approve? it has 4 positive reviews
[10:30] <alan_g> hikiko: I think it should be a customization point - and am still thinking. (E.g. I may want a nested mir with a single window that doesn't match a monitor)
[10:31] <alan_g> hikiko: you can top approve
[10:31] <alan_g> (And you don't need to ask permission)
[10:31] <katie> tvoss, another question for you.. is it Mir or the application that should remember whether a surface is fullscreen/maximised etc?
[10:32] <tvoss> katie, for the surface state, it should be the application
[10:34] <hikiko> alan_g, if this 1 window can be splitted to as many buffers as the monitors and can have the size of the virt. screen size there shouldn't be a problem (I am not 100% sure though)
[10:34] <mpt> tvoss, katie: If Mir can remember its absolute position, why can't Mir remember its state too?
[10:35] <tvoss> mpt, fair question: we could add a function: restore previous state
[10:36] <mpt> tvoss, katie: I think we're missing a description of how an app tells Mir the identity of a surface it's reopening. That would be the place to describe that Mir restores not just the previous position and size but the previous state too.
[10:36] <alan_g> hikiko: it isn't a problem for now - but I was thinking more of a window smaller than a monitor. (So I could run up a server as a "normal" application)
[10:37] <tvoss> mpt, ah, that's a good point. so the app is responsible for "tagging" a surface
[10:53] <mpt> tvoss, when an app opens a surface, does it have to provide a preferred size?
[10:53] <tvoss> mpt, yup, an initial one at least
[10:55] <mpt> tvoss, but what if I develop a word processor, and the preferred size for new document windows depends on the physical size of the current display, up to a reasonable limit? Should all apps contain that kind of logic?
[10:56] <tvoss> mpt, why would it depend on the physical size? you mean in terms of percentage?
[10:57] <mpt> tvoss, katie suggests that in that case, an app could just ask for a preferred size of, say, 8" by 12". On any screen smaller than that (e.g. phone, tablet), it would take up full screen. On any screen larger (e.g. Cinema Display), I'd get that actual size.
[10:58] <tvoss> mpt, yup, that sounds like a good idea. How do you want to handle aspect ratios?
[11:01] <mpt> tvoss, if you reopened a surface on a display that was still wide enough but not tall enough, katie and I think it would only get shorter, not narrower.
[11:03] <tvoss> mpt, so we do not preserve aspect ratio?
[11:03] <mpt> tvoss, right
[11:03] <tvoss> mpt, okay. What if an app needs that functionality?
[11:05] <mpt> tvoss, unless you want to back that into window management (it seems a bit niche), the app would need to notice its new height and narrow itself proportionately.
[11:05] <mpt> *back -> bake
[11:06] <tvoss> mpt, the one thing that concerns me is the feedback cycle required ...
[11:06] <tvoss> mpt, user resizes window, app receives resize notification, resizes its frame
[11:08] <mpt> tvoss, well there are other cases where a window wants to set strict limits on how it can be resized ... The most complicated example I've seen is floating toolbars, where the exact combination of width and height depends on what buttons and other controls are present.
[11:08] <mpt> Palettes is an even better example.
[11:10] <tvoss> mpt, ack, so why don't we say an app can request the following flow: about-to-be-resized(old_size, newly_requested_size) -> new_size_as_calculated_by_app
[11:10] <tvoss> and only then we resize
[11:12] <mpt> Hmm, I thought the Gimp toolbox would be an example, but it isn't, because of that dire "You can drop dockable dialogues [sic] here"
[11:15] <mpt> tvoss, what use is old_size there?
[11:18] <tvoss> mpt, hmmm, to express the user requested change ... although the application should know that anyways
[11:20] <mpt> tvoss, ideally the app would animate internal reshuffling of a window's contents, but that isn't helped by knowing the old size of the entire window.
[11:21] <mpt> For that it needs to know the old position of individual elements inside.
[11:23] <tvoss> mpt, which it does anyway
[11:42] <Saviq> greyback, any idea how do we stand on screen blanking in unity8@Mir?
[11:44] <greyback> Saviq: I've not attempted it. Right now it doesn't blank.
[11:45] <Saviq> greyback, right, another one to the list of regressions
[11:47] <Saviq> greyback, did you write it in the end or shall I?
[11:49] <greyback> Saviq: http://sketchpad.cc/zYRXs1hnWu
[11:52] <Saviq> greyback, added some more and their blueprint-like status, how's it look?
[11:53] <greyback> Saviq: looks ok
[12:08] <tvoss> alan_g, got a nexus 4 handy?
[12:08] <alan_g> yes (but lunch is calling)
[12:09] <tvoss> alan_g, can you ping me after lunch then?
[12:10] <alan_g> tvoss: Sure. Should I leave it installing anything?
[12:10] <tvoss> alan_g, would be cool if you could phablet flash the latest image
[12:11] <alan_g> tvoss: ack
[12:14] <alan_g> Rats!! (It is in "I don't have enough charge to charge mode" again.)
[12:15] <tvoss> olli_, ping
[12:16] <olli_> tvoss, pong
[13:38] <alan_g> tvoss: back (but flashing failed) "ERROR:phablet-flash:Command 'adb shell mount /sdcard/' returned non-zero exit status 255"
[13:41] <tvoss> alan_g, please ask in #ubuntu-touch for help
[13:42] <alan_g> tvoss: I'll ping you when I've got it working again
[13:42] <tvoss> alan_g, ack
[13:54] <alan_g> hikiko: how are you doing?
[13:55] <tvoss> sil2100, didrocks lxc-start on the ati machine fails, I can briefly see the login prompt, then the container shuts down
[13:56] <tvoss> sil2100, didrocks lxc-attach fails with lxc-attach: failed to get the init pid
[13:56] <didrocks> tvoss: do you restart the Mir environment?
[13:56] <didrocks> the right run?
[13:57] <alan_g> tvoss: OK I've got a newly flashed N4
[13:57] <ricmm> thomi: did you guys get the prio sorted?
[13:57] <ricmm> I obv cant push it, I just ask whoever is on vanguard in webops
[13:57] <tvoss> ricmm, thomi is unlikely to be online
[13:59] <ricmm> right
[13:59] <tvoss> didrocks, how do I do that?
[14:00] <didrocks> tvoss: that's what I told, we need to reset the Mir environment
[14:00] <tvoss> didrocks, mind telling me how? :)
[14:00] <didrocks> but I don't have time for that (taking 15 minutes and hoping on meetings)
[14:00] <didrocks> tvoss: I can recreate quickly a blank one rather
[14:00] <tvoss> didrocks, ack
[14:00] <didrocks> where you have a persistency daily image
[14:00] <didrocks> then you add the ppa
[14:00] <didrocks> and the packages
[14:00] <didrocks> sounds ok?
[14:01] <hikiko> alan_g, in this case the window could be resized to be fullscreen when necessary
[14:01] <hikiko> so, why not
[14:01] <didrocks> let's take that as a yes :)
[14:02] <alan_g> hikiko: Don't worry about that use case yet
[14:04] <alan_g> hikiko: what are you doing currently?
[14:05] <hikiko> I am looking at the display
[14:05] <didrocks> tvoss: ok done
[14:05] <didrocks> let me pm the instructions
[14:05] <hikiko> there are at about 8 functions with todo
[14:06] <hikiko> I think that maybe I should start from there
[14:06] <hikiko> if you agree
[14:06] <hikiko> (alan_g)
[14:09] <alan_g> hikiko: Don't try to do too much at once.  I'm looking at the mulit-monitor interactions for NestedDisplay (I think alf__  is busy writing the stuff I need for it)
[14:09] <hikiko> alan_g, what do you suggest I do as a next step then?
[14:09] <alan_g> so maybe the best place to for you to start is in the NativeGBMPlatform
[14:10] <alan_g> BTW Don't worry about duplicating code with GBMPlatform - we can refactor that after we have things working.
[14:10] <alan_g> hikiko: ^^
[14:11] <hikiko> ok then :) I ll start adding the functions there!
[14:12] <alan_g> hikiko: don't go too fast - just get the test to get through one more function call
[14:13] <alan_g> (Before an exception gets thrown)
[14:15] <hikiko> alan_g, what do you mean get the test?
[14:15] <rsalveti> tvoss: racarr: can start mir_demo_server successfully with aug 5th
[14:15] <rsalveti> tvoss: which other test can I run?
[14:16] <rsalveti> hm, seems it crashed now
[14:16] <rsalveti> E/Adreno200-GSL( 1724): <ioctl_kgsl_driver_entry:269>: open(/dev/kgsl-3d0) failed: errno 2. No such file or directory
[14:16] <alan_g> hikiko: there's only one TestNestedMir test currently - I mean that one
[14:17] <hikiko> you mean to run this test each time I add a new function?
[14:18] <alan_g> hikiko: I mean change the system so that the exception caught comes from the next not-implemented function that gets called, update the test for the new exception and MP those changes.
[14:23] <hikiko> alan_g, ok :) I might bother you when I have to modify the test because it will be my first one... but ok, I'll do the change first :)
[14:41] <alan_g> alf__: @place-surface-in-output - how does a client select an output? I don't see any client-side API for it - what have I missed.
[14:43] <alf__> alan_g: it's a new field in surface creation parameters .output_id
[14:44] <alan_g> alf__: thanks
[15:10] <tvoss> racarr, ping
[15:15] <hikiko> bye!
[15:17] <tsdgeos> olli_: is it ok if instead of 19.2 I test image 20?
[15:17] <tsdgeos> phablet-flash cdimage-touch --pending is giving me 20 instead of 19.2
[15:17] <tvoss> tsdgeos, please do 19.2
[15:17] <tsdgeos> tvoss: then i'm going to need help on how to get it
[15:18] <tvoss> ogra_, how to get 19.2 with phablet-flash?
[15:21] <ogra_> tvoss, dunno, i never use phablet-flash ... i think you need to give it a --url parameter
[15:23] <ogra_> tvoss, reading teeh help i would guess: phablet-flash cdimage-touch -d mako --ubuntu-path=http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130819.2/
[15:23] <tvoss> tsdgeos, ^
[15:24] <tsdgeos> ogra_: the help confuses me
[15:24] <ogra_>  phablet-flash cdimage-touch -h
[15:24] <tsdgeos> what's the difference between --device-path and --ubuntu-path
[15:24] <tsdgeos> ogra_: that is what is confusing me, yes i can get there ;-)
[15:24] <ogra_> dunno, ask sergiuiens :)
[15:25] <ogra_> he invents those options all the time :)
[15:32] <rsalveti> device-path is the android zip file
[15:32] <rsalveti> ubuntu-path is the ubuntu zip file
[15:32] <rsalveti> you need both
[15:32] <ogra_> oh ?
[15:33] <tsdgeos> can't i just say "i want 20130819.2" easily?
[15:33] <ogra_> i thought there was a patch that you only need one with the latest phablet-flash
[15:33] <ogra_> tsdgeos, depends how well your voice input works
[15:33] <ogra_> :P
[15:49] <bschaefer> tvoss, ping
[15:49] <tvoss> bschaefer, otp
[15:49] <bschaefer> tvoss, alright
[16:58] <alan_g> Have a good day everybody!
[17:16] <kgunn> racarr: you on?
[17:17] <racarr> kgunn: Yeah just recently
[17:17] <kgunn> np...feel free to coffee up
[17:18] <kgunn> basically....the current request is to retest using 19.2 with -b (to make it completely fresh)
[17:18] <kgunn> rsalveti was able to get it working
[17:18] <kgunn> in case the image moved....use this command line
[17:18] <rsalveti> I didn't get the crash, but just noticed I'm also getting a black screen
[17:18] <rsalveti> the issue when allocating memory is due a race in udev/ueventd, which I'm working on atm
[17:18] <kgunn> phablet-flash cdimage-touch --ubuntu-path http://cdimages.ubuntu.com/ubuntu-touch/daily-preinstalled/20130819.2/saucy-preinstalled-touch-armhf.zip --device-path http://cdimages.ubuntu.com/ubuntu-touch/daily-preinstalled/20130819.2/saucy-preinstalled-touch-armel+[device].zip -b
[17:18] <racarr> 19.2?
[17:19] <rsalveti> racarr: which was the latest issue that you were having? a crash or just a black screen?
[17:19] <racarr> rsalveti: Ah yeah black screen is all I get
[17:19] <racarr> crash is rare
[17:19] <racarr> any time I have ever seen the crash
[17:19] <racarr> a reboot has made it go aay and it
[17:19] <racarr> reverted to black screen
[17:19] <rsalveti> right, then let me flash the older image again, which was working without black screen
[17:20] <racarr> err so wait should I try this
[17:20] <racarr> phblet-flash kgunn gave me?
[17:20] <rsalveti> please try
[17:20] <rsalveti> seems it worked fine for ev
[17:20] <kgunn> rsalveti: "worked fine" means unity8 came up on mir ? & no black screen ?
[17:21] <racarr> Err
[17:21] <rsalveti> unity coming afaik
[17:22] <racarr> flashing
[17:39] <racarr> ok installing mir ppa on image
[17:40] <bschaefer> kgunn, hey, sooo Im suppose to help work on an ATI bug? Would you happen to know something about that?
[17:40] <kgunn> bschaefer: ok....so, it seems to be corrected by the latest kernel (updated to 3.11 y'day ~2pm my time)
[17:40] <bschaefer> through didrocks machine, and I missed tvoss a bit ago...soo I figured you might know something!
[17:40] <bschaefer> kgunn, o really?
[17:40] <bschaefer> kgunn, soo do we need to confirm this, or is it already?
[17:41] <kgunn> tvoss|afk: & didrocks rebuilt and tried reboot ad-nauseum
[17:41] <kgunn> it never failed
[17:41] <kgunn> there were some kernel changes (e.g. mutex related) that certainly could've effected
[17:42] <kgunn> so anyway...result was to place didrocks machine back "on the line"
[17:42] <bschaefer> sweet, well lets hope it stays fixed :)
[17:42] <kgunn> he will start pushing updates tomorrow morning his tmie
[17:42] <kgunn> time
[17:42] <kgunn> yep
[17:42] <bschaefer> cool! Well that was fun to work on :)
[17:42] <kgunn> we are going to pull his machine again in a couple of weeks during bug squash week to root cause
[17:43] <kgunn> seriously the pressure is off....but if you wanted to attempt some root cause effort that would be great
[17:43] <bschaefer> that would be a good idea, don't want this coming up later on
[17:43] <kgunn> altho you'd need to coordinate with him....as its back in service
[17:43] <kgunn> painful part will be trying to stay on 3.10 kernel to test
[17:43] <bschaefer> kgunn, I can try, I think i remember trying to reproduce this last week on my ati machine
[17:44] <kgunn> bschaefer: were you ever successful ?
[17:44] <bschaefer> right, yeah if he comes back and wants some more testing i my time zone Ill go with it!
[17:44] <bschaefer> kgunn, nope :(
[17:44] <bschaefer> kgunn, it was only didrocks machine
[17:44] <kgunn> bschaefer: yeah...that's the thing....his machine was kinda golden
[17:44] <kgunn> even raof's debug add ons changed timing and bug disappeared....
[17:44] <bschaefer> yeeah, didrocks should get a new machine :)
[17:44] <kgunn> like i say mutex changes coming in 3.11 kernel make me wonder
[17:45] <bschaefer> but it is nice it did catch something like that, would have been hard to figure out later on...
[17:45] <bschaefer> kgunn, in a bad way?
[17:45] <bschaefer> or rather the mutex fixes are the fix?
[17:45] <kgunn> b/c xmir would always start ok...it only ever stalled when compiz was trying to init gl for unity
[17:45] <kgunn> in a good way
[17:45] <kgunn> yes...mutex fixes
[17:45] <bschaefer> right, I ran into that on my intel machine
[17:46] <bschaefer> but then i purged all of my libegl* stuff and it never came back...
 mir fixes, ww_mutex changes, dpm support
[17:46] <bschaefer> kgunn, then my laptop died :(...
 maybe uvd fixes
[17:46] <bschaefer> awesome
[17:47] <kgunn> that was the response i got for kernel changes that might've effected this
[17:47] <bschaefer> well IIRC it was thought to be a deadlock right?
[17:47] <bschaefer> or a race for this ATI problem?
[17:49] <racarr> back on DPMS mode :)
[17:49] <racarr> phone almost upgraded
[17:49] <kgunn> racarr: so did 19.2 work for you ?
[17:50] <kgunn> bschaefer: well...deadlock only occured when they tried subsequent start of x after the compiz stall on gl load
[17:50] <kgunn> bschaefer: so the 1st symptom was always failure to load gl from compiz (even tho mir was fine)
[17:51] <bschaefer> kgunn, oo interesting, well when tvoss|afk gets back I can play around on the machine again to try and get the issue or dig some more into it
[17:51] <racarr> kgunn: It's installing mir ppa
[17:51] <racarr> it takes me 5-6 minutes to run apt-get update alone :(
[17:51] <racarr> phablet is so slo on my wireless
[17:51] <rsalveti> racarr: 19.2 always gives black screen here, but aug 5th works fine, will test some other images
[17:51] <rsalveti> doesn't crash, but gets a black screen
[17:51] <kgunn> racarr: rsalveti ....ok, i tried earlier, got black screen....just reflashed and _only_ installed the mir ppa (e.g. didn;t do a dist-upgrade rather install 1by1)
[17:51] <kgunn> and still got a black screen
[17:52] <racarr> Wait then why am I trying
[17:52] <racarr> because isnt this hat I did
[17:52] <racarr> yesterday
[17:52] <rsalveti> right, I first thought the issue was related with the crash that happens sometimes
[17:52] <racarr> no
[17:52] <racarr> the crash just happens XD
[17:52] <rsalveti> hahah, right
[17:52] <racarr> I think it's different
[17:52] <racarr> rsalveti: Ok so yesterday
[17:52] <rsalveti> let me try to isolate the black screen then
[17:52] <racarr> I started from a working image
[17:52] <racarr> july 26th
[17:52] <racarr> and started upgrading packages in groups of 10
[17:52] <kgunn> rsalveti: also...for racarr's sanity....didn't you see unity boot (no black screen) when apparmor=0 ?
[17:52] <racarr> a few times I saw the crash, but reboot always fixed it and it orks multiple times over
[17:52] <racarr> eventually I ully ugpraded
[17:52] <kgunn> or was that just a red herring
[17:53] <racarr> and it worked too!
[17:53] <rsalveti> apparmor=0 doesn't have any effect here
[17:53] <racarr> Never had any effect here either:(
[17:53] <kgunn> rsalveti: thanks...i'll stop saying that then :)
[17:53] <racarr> rsalveti: Anyay what this means (i.e. if someone can confirm that upgrading uly 26th works while installing the latest image fails)
[17:53] <rsalveti> racarr: right, will try with some other images here, if it's android related I should be able to see what changed easily
[17:53] <racarr> then we can narrow it down to things in the image process
[17:53] <racarr> great
[17:53] <racarr> I was wondering if it could have to do
[17:53] <racarr> didn't the images change
[17:53] <rsalveti> racarr: just tested from aug 5th, and worked fine
[17:53] <racarr> to multiuser
[17:53] <rsalveti> but didn't dist-upgrade
[17:53] <rsalveti> let me do that now
[17:53] <rsalveti> will download 100mb =\
[17:54] <racarr> tested what?
[17:54] <racarr> i.e. mir/unity, etc all run fine (from which source)
[17:54] <rsalveti> image from aug5th
[17:54] <racarr> on august 5th image?
[17:54] <rsalveti> yup
[17:54] <racarr> the mir image? or
[17:54] <racarr> image + mir ppa or whatever
[17:54] <racarr> what*
[17:54] <rsalveti> default image, and default mir from ppa (just testing the egltriangle client example)_
[17:54] <rsalveti> for now
[17:54] <rsalveti> which is already enough to reproduce the black screen issue
[17:54] <rsalveti> sorry, default mir from archive
[17:55] <rsalveti> let me dist-upgrade now to check
[17:55] <kgunn> rsalveti: you sure about that?...i thot racarr was getting black screen , but then could subsequently run mir demo client fine
[17:55] <kgunn> racarr: ^ ?
[17:55] <rsalveti> lol, so many issues at the same time it seems :-)
[17:56] <rsalveti> but I'm getting black screen with mir_demo_client_egltriangle
[17:56] <kgunn> :)~
[17:57] <racarr> Yes I can run the client
[17:57] <racarr> fine
[17:57] <racarr> and it reports getting FPS, etc
[17:57] <racarr> (frequently it gets stuck at half FPS though not always)
[17:57] <racarr> but there is never anything on the screen
[17:57] <rsalveti> then why the hell even the client is getting a black screen here
[17:57] <racarr> rsalveti: No, black screen
[17:57] <rsalveti> showing fps and such, but black screen
[17:57] <racarr> it ust reports working
[17:57] <racarr> yes
[17:57] <rsalveti> right
[17:57] <rsalveti> then it's the same behavior here
[17:57] <racarr> On any image where I have ever seen that
[17:58] <racarr> I have never seen
[17:58] <racarr> anything on screen  from mir :)
[17:58] <racarr> but occasionally have seen the crash
[17:58] <racarr> on any image where I have seen things on screen from mir
[17:58] <racarr> I have also occasionally seen the crash
[17:58] <racarr> but never seen
[17:58] <racarr> just black screen
[17:58] <racarr> so I think it's really just two issues
[17:58] <rsalveti> right
[17:58] <rsalveti> the crash is something that should be fixed once I fix the udev/ueventd races
[17:59] <rsalveti> now we need to isolate this black screen one, got quite a few images to test here
[17:59] <rsalveti> after doing dist-upgrade
[17:59] <racarr> ok makes sense that the crash is a race
[18:00] <racarr> im glad you hve the images :)
[18:00] <racarr> 19.2 is still broken for me
[18:00] <racarr> ust for the record
[18:01] <rsalveti> ok, should have enough to keep me busy for the next hour
[18:01] <racarr> Ok. Let me know if I can help
[18:01] <kgunn> rsalveti: let me know if i can be of help as well....
[18:01] <rsalveti> sure
[18:02] <racarr> kgunn: I am considering that maybe I should try and land dpms with the ineffeciency that I was talking about yesterday
[18:02] <racarr> because it will be easy to fix after FF
[18:02] <kgunn> i'm not the fastest....but i follow instructions well
[18:02] <kgunn> racarr: yes
[18:02] <kgunn> agreed...
[18:08] <rsalveti> racarr: worked fine after dist-upgrade
[18:08] <rsalveti> now to try some other images
[18:10] <racarr> So sstrange
[18:10] <racarr> its going to be something awfully small in the end haha
[18:12] <rsalveti> could be on the android side
[18:12] <rsalveti> like the migration to 4.2.2
[18:14] <racarr> oh didnt realize that happened
[18:16] <rsalveti> but the interesting thing is that the binaries we were using were already from 4.2.2
[18:19] <racarr> so strange :/
[18:21] <rsalveti> yeah, image from 07 already gives me a black screen
[18:21] <rsalveti> now let me revert the android side
[18:23] <rsalveti> yeah, just flashing the android zip from 05 made 07 to work again
[18:24] <rsalveti> so the different is on the android side, will investigate that a bit more
[18:25] <racarr> Aha! close
[18:26]  * rsalveti takes a break, late lunch
[18:26] <racarr> :) enoy
[18:52] <racarr> Lunch for me
[19:01] <tvoss_> racarr, ping
[19:19] <kgunn> rsalveti: so 07 vs 05...that's android config as of August 7 and August 5 respectively ?
[19:19] <rsalveti> kgunn: yes
[19:20] <rsalveti> august 5 was still based on 4.2.1, >= august 6 is based on 4.2.2
[19:20] <kgunn> rsalveti: got it...
[19:46] <racarr> hoops back
[19:46] <racarr> whoops*
[19:52] <racarr> tvoss_: pong
[20:12] <thomi> morning
[20:17] <racarr> dpms is almost done :)
[20:18] <racarr> all done except the GBM impl hich looks really simple
[20:18] <racarr> im a little concerned about backlight control
[20:24] <racarr>                 if (drmIoctl(sna->kgem.fd, DRM_IOCTL_MODE_GETPROPERTY, &prop))
[20:24] <racarr> drm API is a pain to mock
[20:25] <racarr> not sure how to mock the
[20:25] <racarr> DPMS property index id integer:p
[20:34] <rsalveti> racarr: ok, so the change is part of the updated display stack for qcom (for 4.2.2)
[20:34] <rsalveti> reverted it and was able to get that to work with the latest image, now to find out the right commit :-)
[20:43] <kgunn> rsalveti: can you share the android git tree & relative history (if easily at hand)
[20:43] <kgunn> rsalveti: just curious...i mean, we're likely going to have to update to "new android stack model"
[20:43] <kgunn> would be my guess
[20:43] <kgunn> rsalveti: p.s. thanks for the bisecting help
[20:46] <racarr> rsalveti: Great to hear :)
[20:48] <rsalveti> kgunn: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_hardware_qcom_display.git;a=summary
[20:48] <rsalveti> this is what I reverted, basically
[20:48] <rsalveti> from the phablet-saucy branch to phablet-10.1
[20:49] <rsalveti> now will try to bisect in more details
[20:53] <racarr> Implemented durning off the display but turning it back on
[20:53] <racarr> is having some issues
[21:32] <racarr> revno: 982 [merge]
[21:32] <racarr> what does this do
[21:32] <racarr> or is it just refactoring
[21:32] <racarr> it breaks unity 8
[21:33] <racarr> and the easy answer is revert it :p
[21:42] <racarr> ...lol at xf86-video-modesetting
[21:43] <racarr>         /* bonghits in the randr 1.2 - uses dpms to disable crtc - bad buzz */
[21:43] <racarr>         if (mode == DPMSModeOff) {
[21:43] <racarr>         }
[21:43] <racarr> ...bad buzz indeed.
[21:44] <bschaefer> anyone else getting this error with only this mir demo: http://paste.ubuntu.com/6008072/
[21:44] <bschaefer> the multiwin, it seems when ever I try to do any kind of "get mir region" it fails :(
[21:45] <racarr> bschaefer: THERE ARE NO MORE B UGS LALALALALALALALA
[21:45] <racarr> No I have not seen that
[21:45] <bschaefer> racarr, :)
[21:45] <bschaefer> haha
[21:45] <racarr> and actually just built and tested trunk like 30 seconds ago
[21:45] <racarr> on radeon
[21:45] <racarr> my distribution
[21:45] <racarr> is not entirely up to date
[21:45] <bschaefer> racarr, yeah im on ati...maybe I should update mir
[21:45]  * bschaefer goes to rebuild trunk
[21:46] <bschaefer> all other demos work though :)
[21:50] <robert_ancell> robotfuel, ack on the bypass testing - that seems to be the same behaviour others are getting. duflu has made some more changes so I'll update the PPA now
[21:58]  * bschaefer notices the nice grey background of the mir server now
[22:00] <bschaefer> racarr, stack trace if you're interested: http://paste.ubuntu.com/6008119/
[22:02] <bschaefer> full trace: http://paste.ubuntu.com/6008126/
[22:02] <bschaefer> racarr, i also just realized was getting that cursor problem as well that I commented out...
[22:03] <bschaefer> as im not even able to load the server without it complaining about the gbm not able to open ...
[22:03]  * bschaefer goes to try that out again
[22:08] <racarr> ill check it out soon
[22:08] <racarr> second lunch :p
[22:08] <bschaefer> yuup getting that gbm cursor error just when trying to start the mir server on normal X... http://paste.ubuntu.com/6008137/
[22:08] <bschaefer> racarr, :), well I really should ping RAOF about it
[22:08] <bschaefer> as IIRC the fix the u-s-c was to disable input but this was only for u-s-c, not the mir server...
[22:09] <racarr> No I get RAOF
[22:09] <racarr> :p ok maybe I can figure out my dpms thing myself
[22:10] <racarr> and you can hve RAOF
[22:10] <bschaefer> racarr, haha, well yours is a bit more important :)
[22:10] <bschaefer> i think my issue is only on a few ATI cards...
[22:11] <bschaefer> racarr, i can also bug him tomorrow about it
[22:11] <racarr> ok ill give you RAOF for
[22:11] <racarr> 1 bitcoin
[22:11] <racarr> insted
[22:11] <bschaefer> haha
[22:11] <racarr> :p haha sorry im just teasing
[22:11] <racarr> dont orry about it
[22:11]  * bschaefer doesn't have any bitcoins
[22:11] <racarr> I probably cant look hard at this right aay though, need to poke at
[22:11] <racarr> DPMS a little
[22:11] <racarr> should be super close
[22:11] <racarr> haha me either
[22:12] <bschaefer> cool, i don't actually know what DPMS is
[22:12] <bschaefer> sounds like a long word though
[22:13] <kgunn> rsalveti: so what's the current thot....should you simply revert that one commit to unblock ? or what's your recommendation ?
[22:13] <bschaefer> Display Power Management Signaling? Eww...
[22:13] <rsalveti> kgunn: there's not single commit to revert yet, still looking
[22:13] <kgunn> rsalveti: got it...i'll try to be patient
[22:13] <rsalveti> haha :-)
[22:15] <kgunn> rsalveti: i get a lot of questions about it....as you can imagine :)
[22:15] <rsalveti> yup, no worries
[22:26] <racarr> bschaefer: Its pretty ew
[22:26] <racarr> so ar I can turn the display off
[22:26] <racarr> but then never back on :p
[22:26] <bschaefer> haha, well who needs a working display anyway!
[22:27] <racarr> then I tried looking in xf86-video-modesetting for examples
[22:27] <racarr> hich is where
[22:27] <racarr> 21:44 < racarr>         /* bonghits in the randr 1.2 - uses dpms to disable crtc - bad buzz */
[22:27] <racarr> comes from
[22:27] <racarr> lol
[22:27] <bschaefer> hahaha
[22:59] <racarr> RAOF: Around?
[23:08] <RAOF> racarr: Yo!
[23:10] <racarr> RAOF: Was hoping you might have some insight on my DPMS difficulties
[23:10] <racarr> essentially, I am setting the DPMS property on the connector
[23:10] <RAOF> Sure. Let's see if I've drunk from that particular fountain of madness.
[23:11] <racarr> with the DPMS mode, and DPMSModeOff works kind of as you ould expect
[23:11] <racarr> the display turns off
[23:11] <racarr> unforunately I can't verify hat happens next because
[23:11] <racarr> I can never turn the display back on
[23:11] <RAOF> Heh.
[23:11] <racarr> and if I write mir_demo_server to
[23:11] <racarr> some output the file ends up empty
[23:11] <racarr> I guess I can use a second machine to
[23:12] <racarr> get that but
[23:12] <racarr> lol I guess I am just wondering if there is anything off the top of your head
[23:12] <racarr> that should obviously have to be done as well, etc
[23:12] <racarr> maybe I can use xset dpms force on
[23:12] <racarr> to recover
[23:13] <RAOF> I think possibly the answer might be "don't bother trying to use the dpms properties; just modeset a null fb"?
[23:14] <RAOF> racarr: That's what the intel driver does, at least.
[23:15] <RAOF> DPMSOff == SET_CRTC to 0; DPMSOn == set_mode_major (ie: full modeset)
[23:18] <RAOF> racarr: This is different to just removing the display from the DisplayConfig because the display is still logically connected (and so you can put windows on it, we probably still have its DisplayBuffers allocated, etc). But as far as KMS is concerned, just remove it from the config.
[23:18] <racarr> he intel driver also sets the property
[23:18] <racarr> the modesetting driver ignores the crt and just messes ith the property
[23:18] <racarr> complaining of "bonghits in the randr"
[23:20] <racarr> Ill try ith the crtc...and make sure I redo things properly on ModeON
[23:22] <RAOF> Ah, right. You might want to set the DPMS property in addition to doing the modeset to turn off/on the backlight.
[23:22] <RAOF> (Which we might have to do manually anyway)
[23:22] <racarr> sounds promising
[23:22] <racarr> yes backlight
[23:22] <racarr> is a mild concern
[23:23] <racarr> intel driver seems to do special things
[23:23] <RAOF> Yeah, backlight is a swamp of madness.
[23:24] <racarr> attempts test again...*crosses fingers*
[23:24] <RAOF> Because it's all ‘as an OEM I can add value by having a different backlight interface!’
[23:24] <RAOF> (Spoiler: no, you can't)
[23:27] <RAOF> Hm. So XMir XRandR appears to work, except for the bit where Mir actually changes any modes.
[23:32] <racarr> Doo doo :(
[23:32] <racarr> also that doesnt sound great
[23:36] <bschaefer> RAOF, hey, guess what happens when I try to start the mir server on my ATI machine? http://paste.ubuntu.com/6008137/
[23:36] <RAOF> bschaefer: What ATI card do you have, again?
[23:37] <bschaefer>  VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood XT [Radeon HD 5670/5690/5730]
[23:37] <bschaefer> 5670
[23:37] <bschaefer> is the one I have
[23:38] <bschaefer> and if i comment out the creation of the cursor it works fine until I try to do software renderering (multiwin example)
[23:38] <bschaefer> everything else works if I comment that out...
[23:38] <bschaefer> (comment out the creation of the cursor)
[23:40] <RAOF> Right. This suggests that we're failing to allocate software-renderable gbm buffers.
[23:40] <bschaefer> right, which this is what I get when I run the mutli win when I turn the cursor off: http://paste.ubuntu.com/6008119/
[23:41] <RAOF> Does the server also die?
[23:41] <RAOF> Or spew any error messages?
[23:41] <bschaefer> well right from my perspective of it not working :)
[23:41] <bschaefer> RAOF, nope, it just fails to run the application and it dies
[23:41] <bschaefer> it spews out:
[23:41] <bschaefer> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
[23:41] <bschaefer>   what():  Failed to import PRIME fd for DRM buffer
[23:43] <bschaefer> also this is me running mir natively on normal X
[23:45] <RAOF> By "on normal X" you mean "With an X server running on another VT", right?
[23:46] <bschaefer> RAOF, hmm normal X meaning i've turned off xmir
[23:46] <kgunn> hey...anyone got phoronix installed running standalone x (not xmir)....updated like today...want to give it a shot
[23:46] <bschaefer> but yes
[23:47] <kgunn> specifically openarena
[23:47] <bschaefer> kgunn, i don't have phronoix installed but I can install it
[23:47] <bschaefer> and im on standalone x
[23:47] <kgunn> its pretty dead easy
[23:48] <bschaefer> yeah, it just take a while to download the games :(
[23:48] <kgunn> i just ran it on a recent update and it was ~10fps
[23:48] <bschaefer> RAOF, i can try to take a better look into it since I can reproduce it well
[23:49] <bschaefer> well at lease figure out what function is failing...
[23:49] <bschaefer> kgunn, im also on ati
[23:50] <RAOF> bschaefer: To debug you'd want to stick a breakpoint in gbm_dri_bo_create, matching width == 64 and height == 64.
[23:51] <bschaefer> RAOF, to match the size of the cursor?
[23:51] <bschaefer> RAOF, and ill give that a try after running this phoronix test
[23:51] <RAOF> bschaefer: Correct. That way you won't catch the other allocations
[23:51] <bschaefer> o cool, but it seems to be the the only one, as commenting out the creation of the cursor and the server works
[23:52] <bschaefer> all egl apps work fine on it
[23:55] <kgunn> bschaefer: that's cool...its a good data point
[23:55] <bschaefer> kgunn, cool, just downloading openarea...then it should run!
[23:56] <RAOF> bschaefer: Yeah; all those other allocations will succeed, so they're uninteresting. That's why you should ‘break gbm_dri_bo_create if ((width == 64) && (height == 64))” ☺
[23:57] <bschaefer> ooo i see, I was thinking all gbm buffer calls were failing, because running the example mulitwin was having problems getting a mir region
[23:57] <bschaefer> which seemed related...
[23:57] <bschaefer> thanks!
[23:58] <RAOF> I'd suspect it's just calls with GBM_BO_USE_WRITE set
[23:59] <RAOF> Which the cursor will have, but also any buffer we allocate for software rendering.
[23:59] <RAOF> And it's easier to catch the cursor :)