[07:22] Mirv: hi, just to be sure, what's the best "Qt 5.3 ppa" to use? daily? [07:29] tsdgeos: the best PPA is to read the _description_ of qt5-beta2 PPA page, which I update if the recommendation changes. so, qt5-beta2 again now, and it has now thanks to late night hacking final versions of qtbase, qtxmlpatterns and qtdeclarative (no difference on the various bugs, though) [07:30] Mirv: well you told me to use daily before so i was using that one :D [07:30] i'll update to beta2 then [07:31] tsdgeos: but many of the issues seem to come down to a read only property of a thing already revealed by (now disabled) UITK unit test, and UITK team (timp/zsombi) already had some idea that it doesn't seem like too hard. music-app has a type error, and webbrowser is using a private symbol that has disappeared [07:31] oki :) [07:31] tsdgeos: yeah well it's complicated, sorry :) sometimes I know qt5-daily has newer stuff (now it's pretty much equal to qt5-beta2) so I mentioned it so that you'd get stuff earlier. but the general idea is to get everything that works to qt5-beta2 [07:32] ok, i'll switch to beta2 [07:32] no worrie [07:32] s [07:32] yeah there's no problem switching [07:33] the media playback is more of a mystery, there's no clear error although jhodapp will hopefully continue looking at it today. and then there's the black launcher and black (background) rectangle in clock app [07:33] but it's still possible a majority of the problems comes down to 2-3 fixable ~small problems, rebuilds of stuff using private headers etc [07:38] Mirv: nice :) [07:38] Cimi:can you have a quick look at https://code.launchpad.net/~aacid/unity8/noiconpreviewheader/+merge/219502 ? [07:46] Mirv: don't we need a sudo in front of apt-add-repository ppa:canonical-qt5-edgers/qt5-beta2 in https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/ [07:48] tsdgeos, ok [07:50] tx [07:51] tsdgeos: true, for desktop, fixing [07:51] greyback: howdy. having some trouble with a unity-mir test. The application manager is starting a non-existing desktop file, and the test isn't ending. [07:52] dednick: the test is hanging, or fails? [07:52] dednick: this with trunk, or your own branch? [07:52] greyback: hanging. due to a forked process from the mock task manager i think. [07:53] greyback: it's the mir 0.2 change branch [07:53] dednick: lemme see [07:54] greyback: not sure which mir branch unity-mir/devel builds against [07:55] dednick: mir0.2 built anywhere? And which test is the failing one? [07:55] .. [07:56] greyback: hm. give me a minute. i'm going to try build unity-mir/devel [07:56] and see if the problem exists there as well. [07:56] dednick: there's no difference between unity-mir and devel right now [07:56] greyback: yeah, but there is with the mir0.2 change [07:57] dednick: unity-mir is the one the mir0.2 change will be merging in to anyway [07:57] ah I see what you mean. [07:58] greyback: so the problem doesn't seem to always manifest in the lp:~mir-team/unity-mir/mir-0.2.0-compatibility-changes. [07:58] but if i only run ApplicationManagerTests.SuspendingAndResumingARunningApplicationResultsInOomScoreAdjustment it does. [07:59] maybe need to kill children on ~MockApplicationController [08:00] not sure how core::posix::fork works [08:00] nor am I, but all it's doing is writing a value to a file in proc [08:01] greyback: just wondering if the process is cleaned up on destruction. [08:01] dednick: I hope so, but I've only basic grasp of gmock, so can't be sure [08:02] greyback: i meant the destruction of core::posix::ChildProcess [08:03] dednick: in that case: no idea [08:03] greyback: checking now [08:04] greyback: nope. doesnt look like it. And i guess that explains all the application_manager_test processes i have in ps list. [08:06] not sure why it's working in trunk/CI though [08:06] dednick: what isn't clear to me is that we mock the ProcessController::OomController completely, it should not be using processcpp at all [08:07] MockApplicationController::doStartApplicationWithAppIdAndArgs forks a process [08:08] oh so it does [08:10] process-cpp has child observers [08:11] which screw with signals, so it's likely to break qt's process handling [08:11] mhr3: yeah, i see that. we're not actually doing much with the children though [08:12] well you still need to waitpid them [08:12] although... if it's a test... meh [08:12] mhr3: you mean to ensure they've shut down? [08:13] mhr3: auto child = core::posix::fork([]() { while(true); return ... } [08:13] :) [08:13] i guess you do kill them at some point [08:13] and then they'll be zombies [08:13] mhr3: um. yeah, well... no [08:13] ah... interesting test :P [08:14] I would guess once 'child' is deleted, the process is destroyed [08:14] i don't think so [08:16] need to use Signalable::send_signal(sig_kill) ? [08:17] marcustomlinson, do you know if process-cpp auto-kills a process when the instance goes out of scope? [08:17] greyback: nope. http://bazaar.launchpad.net/~phablet-team/process-cpp/trunk/view/head:/src/core/posix/child_process.cpp#L341 [08:17] mhr3: looking [08:17] http://bazaar.launchpad.net/~phablet-team/process-cpp/trunk/view/head:/src/core/posix/process.cpp#L55 [08:17] * greyback surprised [08:17] yea, that's a definite no [08:18] think it's cause send_signal can throw [08:18] and destructors can't [08:18] http://bazaar.launchpad.net/~phablet-team/process-cpp/trunk/view/head:/src/core/posix/child_process.cpp#L301 [08:18] ~Private() ::kill(original_child_pid, SIGKILL); [08:19] mhr3, greyback: yup, I saw that too^ [08:19] mhr3: so ja, looks like it should [08:22] ah, didnt see that [08:22] alright [08:23] still not waitpid()ing in that case though [08:24] but back to my original point, try not mixing qt and process-cpp, it will cause trouble [08:24] greyback: looks like the test is thowing an assert. destructor not called? [08:25] http://pastebin.ubuntu.com/7496455/ [08:26] dednick: ah, you compiled in debug mode? [08:26] greyback: ah. yeah.. that's it [08:26] heh. [08:26] Cimi: Saviq: can you reproduce in https://bugs.launchpad.net/unity8/+bug/1319907 that when the header is not there if you start changing to another scope it will come back? [08:26] Ubuntu bug 1319907 in Unity 8 "Carousel overlay not always shown" [High,Triaged] [08:27] dednick: assert on file not found bit overkill really... old code, needs refreshing [08:27] tsdgeos, "it" will come back? the header or overlay? [08:27] Saviq: well header and overlay are the same thing in this case :D [08:27] so both :D [08:28] tsdgeos, ah, thought page header [08:28] tsdgeos, yes, it comes back [08:30] tsdgeos, Saviq yes I have that [08:30] tsdgeos, it started with your branch [08:31] Cimi: i'm not asking if you have that [08:31] hold on [08:31] Saviq: that's pretty confusing :/ [08:32] tsdgeos, indeed, it feels like a frame isn't pushed to the screen? [08:32] i'd say that [08:32] tsdgeos, not pretty helpfuyl, but this revision started to have the issue for me http://bazaar.launchpad.net/~cimi/unity8/carousel-shadow/revision/884 [08:32] but it's one of those "almost impossible to prove" things [08:33] Cimi: dude, do you realize i made you an specific question and you're answering lots of things which are not what i asked? === _salem is now known as salem_ [09:09] uuuh [09:09] scary [09:09] QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. [09:09] kill the lib that causes that! [09:09] with fire! [09:09] or you know... fix it [09:10] * didrocks would love to see that mhr3 discovers it's on of his libs :p [09:10] didrocks, i'm sure it isn't :P [09:10] we don't do evil stuff [09:10] not this kind of evil anyway :) [09:13] :) [09:14] mhr3: it's kind of unfixable [09:14] mhr3: all kde stuff does this and the Qt dbus guy said "oh yeah, that, will fix it for Qt5" [09:14] but maybe happens in Qt5 too? [09:16] greyback: hi! I just updated https://code.launchpad.net/~mardy/unity-mir/signonui-with-oxide/+merge/216845 to remove the test [09:16] mardy: thanks! Will give it a look now [09:17] mardy: yep, that's exactly what was needed, thank you [09:19] tsdgeos, ehm, it means a lib is statically initializing something that uses DBus, doesn't sound that hard to fix to me [09:20] mhr3: i'm just relaying second hand info, i may be wrong :) [09:20] last time i checked, signon-qt was doing it [09:20] but i suppose it's not the only one [09:38] Mirv, did we not get a fix for the transitional packages re: multi-arch? [09:38] Mirv, http://paste.ubuntu.com/7496672/ [09:42] mikenagle: is the departments supposed to be visible all the time or just when at the top of the view? i.e. if i scroll up do they hide or stay there? [09:42] Saviq: we did, we did [09:43] tsdgeos, it's meant to be part of the page header [09:44] Saviq: that's armhf now for example https://launchpad.net/ubuntu/utopic/armhf/qtdeclarative5-qtquick2-plugin [09:44] Mirv, is it M-A: foreign, too? === salem_ is now known as _salem [09:48] Saviq: both the new package name and the transitional package are M-A: same === _salem is now known as salem_ === salem_ is now known as _salem [09:49] Mirv, xnox said they should be foreign I think? [09:49] Mirv, in any case... x-resolution of unity8 build deps still doesn't work because of something there :/ [09:50] Saviq: hmm, no, an amd64 compiled QML plugin cannot work on armhf [09:50] Saviq: transitional package, must match the target. in terms of Architecture & Multi-arch fields. [09:50] right, that was done for the modules in qtdeclarative-opensource-src [09:50] Mirv, sure, it's only a B-D for testing, and we're not running tests when x-compiling [09:50] Saviq: thus "empty" transitional packages for libraries are typically Architecture:any & Multi-Arch: same. [09:51] Mirv, but we can't B-D on packages "only for testing" can we :| [09:51] and well, it was working before the rename... [09:51] Saviq: sure, but that's a property of your use-case, package themself needs to declared things. And a compiled qt modules are Multi-arch:same. [09:52] xnox, Mirv, false alarm [09:52] mzanetti, it builds fine for me... [09:52] mzanetti, ah that's scopes [09:52] Saviq: unity8 had the same for me [09:52] mzanetti, builds fine here [09:53] mzanetti, you sure your source chroots are apt-updated correctly (and/or you don't have apt-update disabled in the chroot?) [09:53] Saviq: ah no. its slightly another issue [09:53] qtdeclarative5-ubuntu-ui-toolkit-plugin:armhf : Depends: libqt5qml-graphicaleffects:armhf but it is not installable or [09:53] libqt5graphicaleffects5:armhf but it is not installable [09:53] mzanetti, that's an issue that should be resolved by now [09:53] mzanetti, make sure to update your chroots [09:54] ack [09:54] u8 builds fine here now, just trying scopes [09:56] xnox, that's what I got for unity-scopes-shell, could you have a look please http://paste.ubuntu.com/7496738/ ? [09:57] xnox, here's the relevant control for unity-scopes-api which fails to install http://bazaar.launchpad.net/~unity-team/unity-scopes-api/trunk/view/head:/debian/control [09:58] Saviq: I upgraded the chroot. still the same here [09:59] mzanetti, can you paste the whole log from sbuild? there should be a file in wherever you pointed sbuild to put the logs in? [09:59] mzanetti, $log_dir in ~/.sbuilrc [09:59] ack [10:00] Saviq: well figure out why. [10:01] xnox, ah, the scopes problem is apparmor [10:01] Saviq: libunity-scopes1 conflicts with libunity-scopes0, do you have old one installed? [10:01] xnox, libunity-scopes1:armhf : Depends: apparmor:armhf but it is not going to be installed [10:01] xnox, no, clean chroot [10:01] tsdgeos, what do I need to have scopes in unity8 desktop? [10:01] anyone knows why the PageHeader has a Flickable ? [10:01] tsdgeos, I reviewed your code, I am trying to test it [10:01] Saviq: right, i do wonder if we should make apparmor foreign.... [10:01] Saviq: also why is it dependencing on apparmor? [10:01] Cimi: should work? [10:01] tsdgeos, but I have no scopes in scopes scope [10:02] in scope scopes I meant xD [10:02] Saviq: libraries should not depend on runtime packages. [10:02] xnox, indeed, that looks weird [10:02] Saviq: and apparmor does not provide any shared libraries as far as i can tell. [10:02] Saviq: can you find out who is adding these apparmor dependencies and why? [10:02] tsdgeos, to swipe left/right [10:02] Cimi: the bug is not about scopes, it's about the music scope previews [10:02] xnox, yup, will do [10:02] tsdgeos, I am talking about your mascot MR [10:03] Cimi: yes, bug is just in the music previews [10:03] previews [10:03] not scope [10:03] but still [10:03] Saviq: dont suppose you know if we can get osk to appear on unity8 desktop launch? [10:03] ah sorry [10:03] Cimi: you should have scopes [10:03] Cimi: so you only have the apps one? [10:03] Saviq: http://paste.ubuntu.com/7496753 [10:03] tsdgeos, I thought it was the padding in scopes [10:03] tsdgeos, I have nothing [10:03] xnox, possible we need to split libunity-scopes1 [10:04] I upgraded to utopic last night [10:04] and now BAM [10:04] xnox, since they rely on aa-exec to contain scope processes [10:04] :D [10:04] I guess I can blame Saviq [10:04] I need to blame someone :D [10:04] Cimi: so read the bug in https://code.launchpad.net/~aacid/unity8/noiconpreviewheader/+merge/219502 again, see how it says Preview Header ;) [10:05] Cimi: now [10:05] $ initctl list | grep scope [10:05] smart-scopes-proxy start/running, process 22503 [10:05] scope-registry start/running, process 22545 [10:06] xnox, here's where the dep was introduced http://bazaar.launchpad.net/~unity-team/unity-scopes-api/devel/revision/303 [10:06] Cimi: can you define "nothing"? you have no tabs or you have tabs but scopes show no contents? [10:07] no content [10:07] Saviq: reading. [10:07] but I have packages to upgrade [10:07] hold on [10:07] Cimi: then don't say you have nothing ;) [10:07] xnox, but libunity-scopes1 ships executables as well as libs, so that's probably what would need fixing - it should be split [10:07] tsdgeos, still no content aFTER UPGRADE [10:07] ops caps lock [10:07] Cimi: merge the branch with unity8 [10:08] * Cimi rebuilds [10:08] ok :D [10:09] I read you merged from the branch log and I thought was up to date [10:09] my bad [10:09] mzanetti, get into the chroot (schroot -r -c session:utopic-amd64-armhf-2317cbf4-ba50-43d1-900f-c7555f9a41c6 -u root) [10:09] Saviq: well the code does exec ("/usr/sbin/aa-exec") [10:09] Saviq: so the dep is legit. [10:10] Saviq: i'll check if we can fix it in apparmor. [10:10] xnox, thanks [10:11] tsdgeos, one, next, overlay bug [10:11] Cimi: do, no, understand [10:11] :D [10:11] Cimi: can you add some verbs and stuff to that sentence? [10:12] hah [10:12] mzanetti, then apt-cache policy libqt5qml-graphicaleffects [10:12] tsdgeos, I approved your branch [10:12] tsdgeos, moving over the next one, the overlay bug [10:12] Cimi: cool tx [10:12] tsdgeos, I confirm it does not happen on the desktop [10:13] Mirv, ah, how about qtgraphicaleffects? did that get fixed for multi-arch? [10:13] Cimi: oki, tx [10:13] Cimi: https://code.launchpad.net/~aacid/unity8/noiconsfakeunity/+merge/219478 should be a pretty easy one too [10:13] dednick, just start maliit-server should be enough [10:13] dednick, I don't think it checks for hw keyboard yet [10:15] Mirv, looks like not [10:15] mzanetti, yeah, I used a non-clean chroot [10:15] mzanetti, that's why it worked for me [10:15] Saviq: that one did not, it's a direct sync from Debian so no Ubuntu changes at the moment [10:15] mzanetti, and qtgraphicaleffects isn't fixed for M-A [10:16] Mirv, so yeah, that breaks X-building of unity8 [10:16] but we probably discussed this [10:16] Saviq: Debian's going to drop the transitional packages, though, so I guess we need to diverge a bit anyhow. Debian didn't have a release with Qt 5 unlike we did. [10:16] Saviq: I can fix that, hopefully that'd be enough [10:16] Mirv, yeah, so we should fix the dep in UITK? [10:16] Mirv, or that [10:16] if you want to touch the package [10:17] Saviq: oh, we could fix UITK instead? yes please let's fix UITK. I actually thought there was a branch for that already earlier [10:18] Mirv: where you at? [10:18] Mirv, I believe so, if we make qml-module-graphicaleffects the default dep in UITK [10:18] Saviq: https://code.launchpad.net/~timo-jyrinki/ubuntu-ui-toolkit/allow_new_qml_package_names/+merge/218605 [10:18] Mirv, indeed ;) [10:18] Saviq: can you approve it at least and let's maybe ping SDK Team about it? [10:18] davmor2: 2 C [10:19] Mirv, yeah, let me test it out [10:19] mzanetti, ↑↑ grab packages from there [10:20] mzanetti, https://wiki.ubuntu.com/SimpleSbuild#Local_packages [10:20] mzanetti, and it should work [10:20] interesting. [10:20] this seems quite useful for other situations too [10:22] mhr3, dednick office this afternoon or not? [10:23] I am going [10:23] Cimi: nope. [10:23] Cimi, not 100% sure yet :) [10:23] mzanetti, it's very useful - build-your-own-silo-style ;) [10:24] too nice outside. going to sit in garden! [10:24] i'm kinda knackered [10:24] dednick's fault [10:27] my eyes! [10:27] mzanetti, I kicked a rebuild on jenkins, since distro packages are newer than those [10:27] mzanetti, you'll have to wait for that [10:27] ack. just failed here [10:27] mzanetti, in any case [10:27] Saviq: the wiki says "Drop packages (with .dsc)..." [10:27] mzanetti, .dsc not necessary [10:27] Saviq: there is no .dsc in those jenkins created pacakges [10:27] ok [10:27] * Saviq fixes [10:28] mzanetti, in any case [10:28] mzanetti, all that you can solve by installing deps by hand [10:28] mzanetti, and then making dpkg-buildpackage just ignore with -d [10:29] ok... will try [10:31] tsdgeos, confirmed your comment [10:32] tsdgeos, all we need to do now is to put a console.log when the overlay should appear [10:32] tsdgeos, and see if it actually is a rendering issue [10:32] Cimi: you mean an onVisibleChanged in the overlay? [10:32] i did that [10:32] it changes to true [10:35] tsdgeos, yep [10:35] tsdgeos, tried async false? [10:36] Cimi: i did [10:36] Cimi: but give it another try [10:51] /food [10:58] tsdgeos, so [10:59] yes? [10:59] tsdgeos, I tried having the loader always visible: true [10:59] tsdgeos, the shader is shown, but not the overlay text [10:59] Cimi: which loader? [10:59] the overlay one? [10:59] tsdgeos, yes [10:59] the text is somewhere else [10:59] tsdgeos, so is not a loader issue [11:00] tsdgeos, shader or so [11:00] Cimi: you can just set showHeader to true all the time (commenting the code in CardCarousel) and you'll see all get the header [11:04] greyback: should i do that thing you did for the red rectangle on 5.3? [11:05] tsdgeos: yes please, would help identify if the GL calls are different, which might be the cause [11:06] greyback: ok, doing [11:07] tsdgeos, yeah, I removed the connection of the titlelabel with the loader [11:07] tsdgeos, I think is a rendering issue [11:19] pete-woods: i can still reproduce the hud going crazy :/ [11:19] pete-woods: i was thinking if it can be firefox+grooveshark maybe? [11:20] tsdgeos: I have a branch that [11:20] that's under SRU that should stop it [11:20] a [11:20] cool [11:20] crossing all fingers + toes === MacSlow is now known as MacSlow|lunch === jono is now known as Guest41797 [11:38] tsdgeos: hey, have been testing the use-unity-api branches [11:38] tsdgeos: seems to work but I think I get more of those: file:///home/phablet/shell/builddir/plugins/Dash/createCardComponent:40:51: Unable to assign [undefined] to QString [11:38] mzanetti: hi [11:38] mzanetti: that's already there on trunk [11:38] there's a fix by Cimi [11:38] tsdgeos: ack [11:38] mzanetti: https://code.launchpad.net/~cimi/unity8/carousel-shadow-fixes/+merge/220213 === vrruiz_ is now known as rvr [11:40] greyback: Saviq: so the traces are defenitely different, not enough gl knowledge in my side to understand if that can be the problem [11:41] tsdgeos: can you share? I'm not much of an expert either, but I'd like a look [11:41] greyback: Saviq attached it to the bug :D [11:41] greyback: http://paste.ubuntu.com/7496983/ [11:44] xnox, can i use the click chroot with sbuild? [11:44] xnox, i just tried sbuild -A -d click-ubuntu-sdk-14.10-armhf --host armhf unity-scopes-api_0.4.7-0ubuntu1.dsc [11:44] and it failed :) === _salem is now known as salem_ [11:45] Saviq: should I commit a workaround for this? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1302761 [11:45] Ubuntu bug 1302761 in unity8 (Ubuntu) "Wrong icon when dragging items in the launcher" [Undecided,Confirmed] [11:46] Saviq: or should we increase priority and still hope for th SDK to fix it eventually? [11:46] mhr3: for some value of can =) [11:47] xnox, got http://paste.ubuntu.com/7497060/ [11:47] mhr3: well, Saviq above was working really hard to enable cross-compilation of that package. [11:48] mhr3: not sure if it was yet. [11:48] mhr3: try cross building $ pull-lp-source hello ? [11:48] to see if it works with the click chroot (it should) [11:49] xnox, inside the chroot? [11:49] i guess not [11:50] tsdgeos: might be handy to set QSG_INFO=1 and run the qml file again. It'll output some handy GL info [11:50] tsdgeos: no need for the apitrace bit [11:50] Saviq: do you do it ↑↑↑ ? [11:50] xnox, same error [11:51] mhr3: pull-lp-source on the host, to get dsc, and then use above you used to cross-build unity-scopes-api but instead cross-building hello*.dsc [11:51] xnox, yea, that's what i did, same error [11:52] Saviq: indicators "not to reach bottom". wtf... haven't noticed that this happens for a year? [11:52] mhr3: hello does not build-depend on systemtap.... so it shouldn't be the same error, unless the chroot is broken. [11:52] xnox, oh you meant hello literally, i just grabbed scopes-api :) [11:54] mhr3: yes, we have "GNU Hello world" package. Which is excellent test-case for cross-building =) we know it cross-builds et.al. thus it should validate if "cross-building random .dsc should work with click chroot". [11:54] mhr3: not everything cross-builds. and i don't think unity-scopes-api is cross-buildable yet, but i might be wrong. [11:54] mhr3: hence the hello test. [11:55] xnox, hello_2.9-1_armhf.deb [11:55] so it works it seems [11:56] yeah. [11:56] mhr3: talk to Saviq about enabling cross-building things. i think he was working on unity-scopes* [11:57] since it's complaining about lttng, i think it's about that right now [11:58] or well.. systemtap === alan_g is now known as alan_g|lunch [12:11] dednick, don't even start... [12:13] Cimi, nope, not coming [12:13] mzanetti, it's actually fixed in SDK, but not in 5.2 [12:13] mhr3, lazy! [12:13] mhr3, see you sunday [12:13] mzanetti, we'd need to backport the patch as linked in one of the comments, or say that this is going to be fixed with 5.3 [12:14] Cimi, lazy indeed :) will come there on friday [12:14] Saviq: mhm... well, for now I've built on the phone [12:14] Cimi, ...maybe :) [12:14] mhr3, I won't be here friday [12:14] greyback, tsdgeos, yeah, let me [12:15] Cimi, here == office, or london? [12:15] mhr3, office [12:16] I'm going this afternoon [12:16] greyback, https://bugs.launchpad.net/unity8/+bug/1321189/comments/7 [12:16] Ubuntu bug 1321189 in Unity 8 "Launcher is black on Qt 5.3" [High,Triaged] [12:17] mhr3, so what's your x-build issue? [12:18] Saviq, pete-woods is getting the uninstallable apparmor [12:18] Saviq, i'm getting uninstallable lltng-dev because systemtap-...-dev is not installable [12:18] Saviq: ok nothing obviously broken afaics. Best ask a Mir person for more help [12:19] mhr3, pete-woods, yeah, xnox was to try fixing that in apparmor, by marking it M-A appropriately [12:19] python3:armhf : Depends: dh-python:armhf but it is not installable seems to be the underlying package [12:19] pete-woods, that's because apparmor pulls in python armhf, while your own build deps pull in the amd64 version [12:20] I haven't asked for any amd64 debs from apt-get [12:20] pete-woods, well, you're talking about cross-building are you not? [12:20] this is with just libunity-scopes-dev:armhf added to the "extra packages" list of click [12:20] this happens at the stage of creating the actual chroot [12:21] I am talking about cross-building, yes [12:21] pete-woods, it's a cross-build chroot, most of the packages there will be amd64, other than libs [12:21] ahh [12:21] that's a very good point [12:21] * pete-woods didn't really employ his brain fully [12:22] pete-woods, solution would be to install apparmor:amd64 instead, and that's what xnox is looking to make possible in apparmor's packaging [12:22] pete-woods, another solution would be to not depend on apparmor from libunity-scopes1 if possible [12:23] pete-woods, probably by splitting out the executables [12:23] and, indeed, any other python tool [12:23] we actually should split the registry into a separate pkg [12:23] that isn't multi-arch aware [12:23] pete-woods: python is fine. it's multi-arched properly. [12:23] although the scoperunner needs to be bound to the soversion [12:25] then again registry is the one that needs apparmor binaries [12:25]