=== krowv_ is now known as krowv
[07:03] <mardy> jamesh: hi! I need some help from a Go expert... any idea why account polld builds are failing in some architectures here? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages
[07:04] <mardy> jamesh: is it because of go vs gcc-go?
[07:08] <jamesh> mardy: I'm not sure of the underlying cause, but it looks like it is having trouble finding the C++ compiler in the failing builds
[07:08] <jamesh> mardy: "go build launchpad.net/account-polld/qtcontact: /usr/bin/g++-5: fork/exec /usr/bin/g++-5: no such file or directory"
[07:09] <jamesh> mardy: that's in the failed vivid builds.  In the failed xenial build it says "go build launchpad.net/account-polld/qtcontact: /usr/bin/g++-5: fork/exec /usr/bin/g++-5: no such file or directory"
[07:09] <jamesh> oops.  wrong paste
[07:09] <jamesh> "go build launchpad.net/account-polld/qtcontact: /usr/bin/g++-6: fork/exec /usr/bin/g++-6: no such file or directory"
[07:10] <jamesh> so for some reason it is looking for GCC 5 on vivid (which ships with 4.9), and GCC 6 on Xenial (which ships with 5)
[07:10] <jamesh> I don't know why it would be doing this
[07:11] <mardy> jamesh: is it possible from the build log to tell whether it's building with go or gcc-go?
[07:11] <mardy> jamesh: I'm asking, because I suspect that it's using gcc-go in those failing logs
[07:13] <jamesh> mardy: the xenial/powerpc build seems to be installing gccgo
[07:13] <jamesh> interestingly, it is installing a "gccgo-6" package
[07:13] <mardy> jamesh: I wonder if the go shipped in those ubuntu releases did not support those archs, so gcc-go is being used instead
[07:13] <mardy> jamesh: ah, so it expects a g++-6
[07:14] <mardy> weird
[07:14] <jamesh> mardy: and the failing vivid builds are installing gccgo-5
[07:14] <mardy> right
[07:14] <mardy> jamesh: do you know where this logic resides? is it in the debhelper plugin for go?
[07:15] <jamesh> mardy: my guess is that they've included gccgo packages from a newer gcc due to the compiler being fairly new
[07:15] <jamesh> but it ends up looking for a matching C/C++ compiler if you use cgo, and fails
[07:16] <jamesh> mardy: I'm not sure what makes the decision
[07:18] <jamesh> mardy: on another topic, did you see this bug I filed? https://bugs.launchpad.net/online-accounts-api/+bug/1617180
[07:18] <ubot5> Ubuntu bug 1617180 in storage-framework (Ubuntu) "memory leaks from OnlineAccounts::Manager" [Undecided,New]
[07:19] <mardy> jamesh: yes, I'll get to that, eventually
[07:19] <jamesh> I dug around a bit, but couldn't work out what was causing the leak
[07:19] <jamesh> I couldn't see anything obvious in the code that could explain the leak
[07:20] <mardy> jamesh: I wonder, could you try that in vivid or xenial, where qt 5.5 is being used?
[07:20] <jamesh> your code looked pretty much like every other piece of QtDBus code I've seen
[07:20] <mardy> jamesh: I wonder if the leak could be in Qt 5.6 itself, sincethe QtDbus part has been heavily modified in there
[07:21] <jamesh> mardy: that valgrind run was on Xenial
[07:21] <jamesh> so Qt 5.5
[07:21] <mardy> jamesh: ok
[07:22] <jamesh> If I've got time, I'll try repeating on vivid and yakkety
[07:22] <jamesh> to cover 5.4 and 5.6
[07:23] <mardy> jamesh: that might help, thanks
[07:25] <mardy> jamesh: back to the gccgo issue, I suspect that the problem is that the gccgo-5 (I'm looking at vivid only, for now) does not depend on g++-5 (or any gcc/g++, for that matter)
[07:25] <mardy> jamesh: while in yakkety I see that it has the proper dependency
[07:27] <jamesh> mardy: there probably isn't a g++-5 package on vivid
[07:29] <mardy> jamesh: and you are right...
[07:33] <mardy> jamesh: do you know how to solve this? maybe we could check modify the gccgo-5 package in vivid to use gcc-4 instead? Or would the generated objects be incompatible?
[07:39] <mardy> dbarth: do you have an arm64 device with ubuntu?
[07:39] <mardy> dbarth: and hi :-)
[07:43] <jamesh> mardy: I don't know.  If the package has never built on those platforms, then it probably isn't worth worrying about
[08:33] <dbarth_> mardy: nope, sorry, only having a cooler here
[08:33] <dbarth_> mardy: on maybe my rpi3 ?
[09:02] <pstolowski> pitti, hey, can you help with silo 21 and retry autopkg tests on xenial and yakkety there?
[09:10] <pitti> pstolowski: I need the full URLs to the excuses
[09:11] <pstolowski> pitti, https://requests.ci-train.ubuntu.com/static/britney/landing-021/xenial/excuses.html
[09:12] <pstolowski> pitti, and https://requests.ci-train.ubuntu.com/static/britney/landing-021/yakkety/excuses.html
[09:12] <pitti> pstolowski: retried the xneial ones; nothing to do on the yakkety one
[09:12] <pitti> (no tests at all)
[09:12] <pitti> this is a packaging bug instead, you need to stop building on s390x
[09:12] <pstolowski> pitti, ah oh, sorry, you're right
[09:13] <pitti> best to explicitly build-dep on the corresponding -dev packages so that it will fail to build
[09:13] <pitti> instead of being built and then uninstallable
[09:14] <pstolowski> pitti, i see, ok, will fix that, thanks
[09:17] <zzarr> OTA-13 today :D
[09:23] <duflu> zzarr: Web page says 19 September: https://launchpad.net/canonical-devices-system-image/+milestone/13
[09:24] <zzarr> ohh, the testing and bugfixing have been prolonged?
[09:29] <zzarr> duflu, do you know if mms:es will be fixed in OTA-13?
[09:29] <duflu> zzarr: I don't know. Check the above list
[09:30] <zzarr> I could not find anything about it
[09:33] <zzarr> receiving MMS have not worked since OTA-10 (I'm not alone experiencing this problem)
[09:34] <zzarr> should I report the problem?
[09:40] <popey> zzarr: if it's not been reported as a bug then it certainly won't get fixed
[09:41] <zzarr> popey, are the list duflu linked to the complete list of reported bugs?
[09:41] <popey> no
[09:41] <duflu> zzarr: No it's more an executive summary. If you think some bug is missing please tell someone here or in the bug
[09:42] <zzarr> is there a complete list?
[09:42] <duflu> zzarr: No it's launchpad. There are separate lists per project. Please check the appropriate project
[09:43] <zzarr> that list is only for OTA-13?
[09:43] <duflu> Yes, and it's not quite complete for OTA-13 even
[09:43] <duflu> If you know of a bug that's missing please point to it
[09:44] <zzarr> if I don't have the complete list I can't know if the problem with MMS is reported
[09:45] <zzarr> but I guess that the worst that could happen is that I report a bug again and my report and the original is merged
[09:45] <zzarr> or I'm pointed to the correct bug report
[09:49] <zzarr> can I somehow force the phone to send information to my service provider that the phone is capable of receiving MMS?
[09:55] <popey> zzarr: step one is file a bug, yes.
[09:55] <zzarr> okey, I'll do it
[09:55] <popey> https://bugs.launchpad.net/ubuntu/+source/messaging-app/+bugs
[09:55] <popey> thats where mms bugs lie
[09:55] <popey> so maybe scan that list
[09:56] <zzarr> okey, thanks
=== oSoMoN_ is now known as oSoMoN
[10:45] <zzarr> I found a bug report regarding this issue and a technician at Tele2 the operator I use tells me after a few tests that the problem is with Ubuntu
[10:45] <zzarr> now some lunch
[10:56] <melvster> hi all i heard a rumor OTA13 was coming out this week, is that right?
[10:59] <Hourd> \q
[11:25] <jgdx> mardy, ping
[11:26] <mardy> jgdx: hi!
[11:26] <jgdx> mardy, hey, so I'm trying to solve a problem in System Settings I'd like your input on
[11:27] <jgdx> mardy, system settings will run on a snappy-based system, this means that every reference to /, will have to be prefixed with $SNAP. There are such refs everywhere.
[11:27] <mardy> right
[11:28] <jgdx> and this is a problem for libSystemSettings as well, as it refers to / multiple places
[11:28] <jgdx> we don't want six-ish calls to qgetenv at startup
[11:29] <mardy> jgdx: what are we using / for? is it for the plugin path, or for something else too?
[11:30] <jgdx> mardy, we refer to PLUGIN_QML_DIR, PLUGIN_PRIVATE_MODULE_DIR, PLUGIN_MANIFEST_DIR and PLUGIN_MODULE_DIR
[11:31] <jgdx> in main, plugin-manager and plugin
[11:31] <jgdx> which all point at /
[11:31] <jgdx> and we do not know $SNAP at build time, iuic
[11:33] <jgdx> one suggestion is to subclass qtapplication, add mountPoint as a property. Then add a header to libsystemsettings-dev that exposes this class, as well as rewrite the qApp macro.
[11:35] <mardy> jgdx: or, instead of hardcoding these paths, hardcode only the components on top of XDG dirs
[11:36] <mardy> jgdx: and use QStandardPaths in our code, then append the fixed components
[11:36] <jgdx> mardy, but why isn't it already relative to xdg dirs?
[11:37] <jgdx> i assumed there was some reason, but if not, why we'll do it that way
[11:38] <mardy> jgdx: no idea, I guess I didn't see a compelling reason to do so
[11:38] <mardy> jgdx: XDG-izing the app is a good idea anyway
[11:39] <jgdx> mardy, do you think it's trivially doable?
[11:39] <mardy> jgdx: ah, well, one reason *not* to do it is that XDG dirs is a list, while we use one directory only
[11:40] <mardy> jgdx: I guess it's fairly trivial if we pick only the first directory, but doing things properly would be a bit more complicated
[11:43] <jgdx> mardy, where in the xdg specification are library files mentioned?
[11:44] <mardy> jgdx: oh, right, this would apply to plugin manifest files, but not libraries
[11:45] <mardy> jgdx: but for QML modules it's not hard either, we just add a path to the QQmlEngine in src/main.cpp
[11:46] <mardy> jgdx: so I guess that you could read $SNAP from there, and add a couple of paths based on $SNAP
[11:47] <mardy> jgdx: or even, don't change the code at all and play with the QML2_IMPORT_PATH variable
[11:53] <jgdx> mardy, okay, so how do a plugin find its .so? Seems that's the last piece of the puzzle here
[11:54] <jgdx> that's not a qml import, nor is it covered by xdg
[11:55] <mardy> jgdx: I think it's relative to the QML module dir, so you shouldn't need to worry
[11:56] <jgdx> mardy, okay, let's do this then. Thanks
[11:57] <mardy> jgdx: yw, let me know how it goes :-)
=== _salem is now known as salem_
[12:53] <jgdx> mardy, any reason why you only want to pick one dir when multiple are returned?
[12:54] <mardy> jgdx: no, no, feel free to iterate them all, that's better
[12:54] <jgdx> yeah
=== boiko_ is now known as boiko
=== chihchun is now known as chihchun_afk
[14:04] <jgdx> mardy, I'm not sure your assumption on the .so's holds: e.g. /usr/lib/arm-linux-gnueabihf/ubuntu-system-settings/libonline-accounts.so
[14:04] <jgdx> that's what loaded
[14:14] <tedg> popey: Is ubuntu-terminal-app in the archive somewhere?
[14:14] <mardy> jgdx: you are right, the libs are in $$LIBDIR/ubuntu-system-settings/, and the QML plugins are in the "private" subdir
[14:15] <popey> tedg: no
[14:16] <tedg> popey: :-(
[14:21] <mardy> jgdx: it's non trivial... we could avoid specifying a path, given that we use QPluginLoader which uses QCoreApplication::libraryPaths(), but it's a bit risky
[14:21] <mardy> jgdx: because we risk loading some other unrelated plugin, if they happen to have the same name
[14:22] <jgdx> mardy, what about putting the mount point in a ctx prop?
[14:22] <mardy> jgdx: it's not clear to me what the solution should be. Plugins can also come from other snaps, so we don't want just to check our $SNAP dir
[14:22] <mardy> jgdx: unless other snaps can install stuff there too?
[14:23] <jgdx> mardy, yeah, I don't know about that scenario. The current approach breaks confinement
[14:23] <dobey> tedg: can't you install the click?
[14:24] <tedg> dobey: Wanting to include it in a snap.
[14:24] <mardy> jgdx: online-accounts for example is a plugin coming from another snap, unless we merge them
[14:24] <tedg> dobey: For debugging
[14:24] <mardy> jgdx: IMHO, we should have a single snap for the whole of unity8, TBH
[14:24] <jgdx> tedg, ^^
[14:24] <tedg> Heh, yes, I agree.
[14:24] <jgdx> ;)
[14:25] <dobey> mv system.img unity8.snap
[14:25] <jgdx> mardy, okay, so breaking confinement to load external plugins is a non-starter i guess.
[14:25] <jgdx> since what you want is highly probably
[14:25] <jgdx> probable
[14:26] <mardy> dobey: even better: for i in *.deb; mv $i ${i/deb/snap}; done ;-)
[14:27] <dobey> for (const auto& rum: rums) { drink(rum); }
[14:28] <jgdx> const ref rum??
[14:28] <jgdx> yeah that works
[15:29] <dobey> jgdx: well if you keep creating duplicates of the rum, things get weird
[15:35] <mancebeitor> When OTA13?
=== dandrader is now known as dandrader|afk
[15:57] <harirama> the glass screen of my bq4.5 broke, friend ordered a new one from china, had it installed:
[15:57] <harirama> thing doesn't work right, only lower part works as a keyboard.
[15:58] <harirama> http://www.ubuntu.com/phone/devices
[15:58] <harirama> all the phones there say:
[15:58] <harirama> "sold out"
[15:58] <harirama> now what do i do? aaargh help
=== gkeen_ is now known as gkeen
[16:02] <popey> harirama: call bq?
[16:06] <harirama> popey, what hardware are u running on?
[16:10] <popey> harirama: I have a few phones :)
[16:18] <harirama> well, at the moment, i have 0 :(
[16:30] <mancebeitor> When OTA 13?
=== blackout is now known as Guest58758
=== dandrader|afk is now known as dandrader
[17:47] <Perzival1312> is there anything about any of the one plus models?
[17:49] <dobey> no more than what ubuports has
=== dandrader is now known as dandrader|afk
[20:11] <jgdx> mardy, hey, when you got a chance, could you take a look at this [1] mp and see if it agrees with the approach we discussed? It's a bit eclectic, but should work. [1] https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/snapd-paths2/+merge/305751
=== dandrader|afk is now known as dandrader
[20:16] <flohack> Good Eve
[20:17] <flohack> Can anyone tell me if it is possible to get screen console during touch boot so that stdout messages can be monitored?
[20:40] <Walex> flohack: probably in developer mode
[20:41] <flohack> How to get there ;)
[20:48] <dobey> flohack: well assuming it gets far enough to start some services, and usb works, you'd need adbd running, and to then adb in and read dmesg
[20:50] <flohack> No thats my problem... automatic reboot after 5 secs, no adb. Take a look:
[20:51] <flohack> [    5.699726] initrd: mounting system.img (user mode)
[20:51] <flohack> [    5.733970] initrd: mounting device image as ro
[20:51] <flohack> [    5.795786] EXT4-fs (loop1): mounted filesystem with ordered data mode. Opts: (null)
[20:51] <flohack> [    5.817083] initrd: device is endeavoru
[20:51] <flohack> [    8.790337] initrd: mounting /root/var/lib/lxc/android/system.img as /root/android/system
[20:51] <flohack> [    9.075972] Kernel panic - not syncing: Attempted to kill init!
[20:51] <flohack> [    9.108567] Rebooting in 5 seconds..
[20:51] <flohack> I took only the relevant things I hope
[20:51] <dobey> use pastebin please in future
[20:51] <flohack> Ok wait a sec
[20:52] <dobey> well i can't really help you, myself
[20:52] <dobey> other than to say a kernel panic seems obviously bad :)
[20:53] <flohack> http://pastebin.com/a2STZv71
[20:53] <flohack> :) thanks, but I need to know the reason somehow
[20:53] <flohack> And there is lots of things logged in scripts/touch to stdout, not to kmsg
[20:53] <flohack> And maybe I can get a clue from that
[21:01] <dobey> well, reboot to recovery, and check the syslog. i'm not 100% sure how to do it, but i presume you can adb into recovery
[21:08] <flohack> yes I can
[21:08] <flohack> its a littel bit tricky with those 100 mounts, remounts and loop mounts to find syslog :P
[21:21] <flohack> I would need framebuffer console I think
[21:21] <flohack> is this configurable at all?
[21:34] <flohack> I try with CONFIG_FRAMEBUFFER_CONSOLE=y
[21:34] <flohack> lets ee...
[22:11] <flohack> Ok fb console works but I got other issues... good night ;)
[22:22] <Acou_Bass> i know this isn't really the right channel, but figured you guys might have experience - has anyone replaced the screen on s nexus 4? i broke mine today like a dumbo
=== Guest56430 is now known as IdleOne
=== salem_ is now known as _salem