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