[07:05]  * guest42315 sudo snappy install coffee
[08:23] <Saviq> tsdgeos, hey, got a sec? need a sounding board
[08:24] <tsdgeos> Saviq: sure
[08:24] <Saviq> tsdgeos, last issue with autopkgtests
[08:25] <Saviq> tsdgeos, paths.h is generated on build, but when testing archive/ppa-built packages, the non-installed paths there are not the same as what you get in the testing environment
[08:25] <Saviq> e.g. when the packages were built
[08:26] <Saviq> it was file:///build/unity8-aDQvXH/
[08:26] <Saviq> but when the tests are ran
[08:26] <Saviq> it's file:///tmp/adt-run.jl4VOK/build.64t/ for example
[08:26] <Saviq> basically, our binaries get some random paths baked in
[08:27] <tsdgeos> right
[08:28] <tsdgeos> hmmm
[08:28] <tsdgeos> no, not right
[08:28] <tsdgeos> why does this happen?
[08:28] <tsdgeos> does adt copy the things around?
[08:29] <Saviq> this actually makes ApplicationWindow test fail under adt-run *if* you don't build the packages at the same time (e.g. what you should do - take the packages as built in the PPA, not build them locally)
[08:29] <Saviq> tsdgeos, PPA builds the packages, the build path on the builders is /build/foo
[08:30] <Saviq> tsdgeos, then, adt takes those packages as they are, builds just the missing mocks and runs the tests, but the build path is different - /tmp/adt-foo
[08:30] <tsdgeos> ah so there's two builds
[08:30] <Saviq> in effect, yes
[08:31] <Saviq> but even if there were not
[08:31] <Saviq> the path baked into paths.h on the builders
[08:31] <Saviq> are invalid as soon as the build is done
[08:32] <Saviq> at that point paths.h is only useful when running installed
[08:32] <Saviq> == running unity8 itself
[08:34] <Saviq> so, short term I could put the graphics from qml/graphics/applicationIcons and qml/Dash/graphics/{phone,tablet} in qrc
[08:34] <Saviq> they don't belong where they are any more anyway
[08:35] <Saviq> but that still means paths.h is useless non-installed
[08:35] <Saviq> (btw this worked for adt-run when you did build packages within adt-run because the build dir was reused)
[08:36] <Saviq> the real fix would be to runtime-detect our build root
[08:38] <tsdgeos> yep
[08:38] <tsdgeos> make it be XDG_SOMETHING
[08:41] <Saviq> wdym
[08:41] <Saviq> ?
[08:41] <tsdgeos> so there's all these XDG_ variables
[08:42] <tsdgeos> we can just assume our stuff is asumed in XDG_something/path
[08:42] <tsdgeos> and then set XDG_ accordingly for the tests?
[08:42] <tsdgeos> not sure how viable that would be
[08:42] <tsdgeos> how did you plan to detect the root?
[08:43] <tsdgeos> pwd or something?
[08:43] <Saviq> we'd need to up from pwd until reached build root
[08:43] <Saviq> +go
[08:44] <Saviq> but that sounds nasty
[08:44] <tsdgeos> would it even work?
[08:44] <tsdgeos> i mean in paths.h we have
[08:44] <tsdgeos>         return QString("@CMAKE_BINARY_DIR@/po/locale");
[08:44] <tsdgeos> and
[08:44] <tsdgeos>         return QString("@CMAKE_SOURCE_DIR@/qml/");
[08:45] <Saviq> right
[08:45] <tsdgeos> how do we find those if we have two build roots?
[08:45] <tsdgeos> is the source even around?
[08:45] <Saviq> yeah, source is always around
[08:46] <Saviq> but if we start requiring some env vars to be set, even more meh
[08:47] <Saviq> we're not really interested about "previous" CMAKE_BINARY_DIR
[08:47] <Saviq> because it's invalid
[08:47] <Saviq> we only care about current paths
[08:48] <Saviq> I can't shake the feeling that we're either doing something wrong or that someone must've solved this already...
[08:48] <Saviq> obviously the fact that QML makes relative paths nice and easy doesn't help
[08:49] <Saviq> because that only works until you start passing paths to C++
[08:49]  * Saviq tempted to start moving all that stuff to qrc, only reliable way
[08:49] <Saviq> not that it really solves the issue
[08:50] <Saviq> on that note, can you use qrc in qml-only files? how do you tell Qt where the resources are?
[08:56] <Saviq> mzanetti, ideas? (read up to ~10:23 ↑)
[08:57]  * mzanetti reading
[09:01] <mzanetti> +1 for runtime detection... /me never liked the paths.h
[09:01] <mzanetti> now... I don't have the solution obviously
[09:01]  * mzanetti thinks
[09:03] <Saviq> the only thing I could think of is putting a special file in project root and go up from $CWD to find it
[09:03] <Saviq> but that seems meh
[09:06] <Saviq> we could have paths.h as a library and LD_PRELOAD it... that one seems overkill
[09:06] <mzanetti> Saviq, well, putting a special file is meh indeed, but why not trying to find the actual files?
[09:07] <Saviq> mzanetti, as meh as a special file I'd say
[09:07] <mzanetti> slightly less meh
[09:07] <mzanetti> not super pretty still, yes
[09:07] <Saviq> with the added problem that you might want to move or rename the non-special file
[09:07] <mzanetti> yeah well... the test would catch that pretty fast ;)
[09:08] <Saviq> sure, but I'd rather be explicit about it
[09:09] <Saviq> I just feel like this must be a solved problem
[09:09] <Saviq> can't believe we're the first ones to ancounter it
[09:09] <Saviq> *encounter
[09:11] <mzanetti> Saviq, doesn't dpkg export some build_root var or something?
[09:12] <Saviq> mzanetti, even if, only useful if building a package
[09:12] <mzanetti> isn't that what we're talking about?
[09:12] <Saviq> mzanetti, the problem we're facing is running tests
[09:13] <mzanetti> yes, afaiu it's still dpkg who is building the last mocks and runs the tests, no?
[09:13] <Saviq> no
[09:13] <mzanetti> hmm, ok
[09:13] <Saviq> adt-run
[09:13] <Saviq> but even so
[09:13] <mzanetti> I thought that's dpkg-magic
[09:13] <mzanetti> so, doesn't adt-run export some information about the env?
[09:14] <Saviq> don't think we should rely on that
[09:14] <Saviq> because you don't want to have to export this manually when running outside of adt-run
[09:16] <tsdgeos> Saviq: well, default to what we have unless the env var is exported and then use that?
[09:16] <Saviq> tsdgeos, yeah, I was thinking that, but still feels like a band-aid
[09:16] <tsdgeos> seems good to me tbh
[09:17] <tsdgeos> all these "let's detect where i am" are like this
[09:17] <Saviq> trueth
[09:17] <tsdgeos> use some env vars, if not use some paths i got while compiling, if not just try /usr and if not just bail out and go crazy
[09:25] <Saviq> aargh why does QtC not open CMakeLists.txt files any more but tries to build the project ;(
[09:25] <Saviq> oh ok, need to open from project pane not filesystem
[09:43] <Saviq> mzanetti, tsdgeos, opinion: should we rely on paths coming from paths.h to be /-terminated, or assume they're not?
[09:43] <tsdgeos> Saviq: if we're going to accept envvar, assume not
[09:43] <tsdgeos> there's nothing more annoying that stuff failing because you have to add / to an envvar
[09:44] <Saviq> +1
[09:44] <mzanetti> wfm
[09:44] <mzanetti> I usually add trailing slashes, but mostly not rely on them being there
[09:44] <mzanetti> which causes my code to often have // in it... but at least it works
[09:45] <Saviq> yeah, so assume not it is
[09:48] <Saviq> oh wow, QtC remembered changes after crashing, kudos ;D
[13:45] <mzanetti> mterry, can't repro this: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1498486
[13:45] <mzanetti> mterry, for me the clicked icon ends up being completely unfolded
[13:45] <mzanetti> on krillin that is
[13:46] <mterry> mzanetti, huh.  I only tested on mako, assumed they had same size in landscape
[13:46] <mterry> mzanetti, do you have 3 icons not shown in the direction you are testing?
[13:46] <mzanetti> however, I have seen issues that ListView.flick() doesn't always flick with the same strength
[13:46] <mzanetti> mterry, yes, I have like 20 icons in the launcher
[13:46] <mterry> humph
[13:46] <mzanetti> and trying somewhere in the middle
[13:47] <mterry> mzanetti, maybe it's mako-specific (like it matters on a pixel level, instead of a grid unit level)
[13:47] <mzanetti> probably
[13:47]  * mzanetti searches for a mako device
[13:47] <mterry> will edit bug to not mention krillin
[13:48] <mzanetti> mterry, hah... indeed. it flicks like twice as much on mako
[13:49] <mzanetti> cycles through the whole list :D
[13:49] <mterry> oh interesting it's so different
[13:49] <mterry> not the whole list. just like 3 icons...?
[13:50] <mterry> For me, the nearest-folded icon will bounce between top and bottom when I click on it
[13:50] <mterry> But always be folded
[17:02] <dandrader> Saviq, do you know where things like Qt5Gui_PRIVATE_INCLUDE_DIRS come from?
[17:03] <dandrader> Saviq, ie, what file defines it
[17:03] <Saviq> dandrader, dpkg -L qtbase5-dev | grep cmake
[17:04] <dandrader> Saviq, thanks
[17:04] <Saviq> grep PRIVATE -r /usr/lib/x86_64-linux-gnu/cmake/Qt5Gui