[00:05] <WoC> Anyone managed to install on SGH-I957 ? (Replacing Android)
[00:15] <OerHeks> WoC, there is no port (yet) for that galaxy tab 8.9 https://wiki.ubuntu.com/Touch/Devices
[00:25] <WoC> Just checking, ty. I'm aware though... Not too sure about the boot loader and boot up standard, otherwise i would try to make one myself
[00:25] <WoC> Appreciated deshack
[00:26] <WoC> err DerHeks
[00:26] <OerHeks> please feel free to start a port?
[00:28] <WoC> I would be happy to, but the boot up on arm is a puzzle to me
[00:28] <WoC> not to mention the 30+ partitions from Android
[00:30] <WoC> I'm thinking i would have the tab as a x-display and run the apps on one of the 3 servers i have on my lan
[00:32] <WoC> which would also enable using nfs and softlinks for additional storage...
[00:32] <OerHeks> i wish i could help you with that :-(
[00:32] <WoC> (soft mounts)
[00:36] <WoC> Well, i might figure something out... would be great having grub and ubuntu-touch on it, given that native programs gets about 200+% performance compared to Android (not incluing floatpoint math)
[00:40] <bumblehead> the app store on ubuntu touch is slow and does not show the page for any app that I click on...
[00:40] <bumblehead> does anyone know how to get around this problem?
[00:41] <bumblehead> I'm using a nexus 4
[00:45] <WoC> if you you which app, you might want to use apt directly in a terminal
[00:45] <WoC> err, if you know*
[00:46] <WoC> apt-cache search is handy too
[00:46] <bumblehead> this app https://uappexplorer.com/app/uradio.rubenxparra
[00:51] <WoC> Still trying to open that one, iḿ on a super slow connection at the moment... like 57 kbit/s
[00:52] <WoC> So... don't hold your breath...
[00:52] <bumblehead> it seems that the app store is generally very slow
[00:53] <bumblehead> and my intuition is that... after a certain amount of time passes the app store app simply stops
[00:55] <WoC> something similar to; gnuradio - GNU Radio Software Radio Toolkit
[00:55] <WoC> ?
[08:01] <tsdgeos> Mirv: ping?
[08:02] <tsdgeos> Mirv: i was wondering, did you also rebuild unity8 on that silo for arm64 or only qt?
[08:03] <tsdgeos> doctors appointment! bbl!
[08:48] <Mirv> only qt
[10:04] <Mirv> tsdgeos: so only Qt, now there is unity8 too. so you think https://codereview.qt-project.org/#/c/169892 would require a rebuild of unity8, why? or in other words, how can we know what needs a rebuild if that change would be landed..
[10:05] <tsdgeos> Mirv: so with that silo, unity8 arm64 actually passed without an unity8 rebuild?
[10:05] <tsdgeos> that would mean a rebuild is not needed
[10:06] <tsdgeos> Mirv: thing is that change touches some private headers of qtdeclarative and unity8 uses some qtdeclarative private headers
[10:06] <tsdgeos> so it would not be so far fetched that it needs an unity8 rebuild
[10:06] <Mirv> tsdgeos: I thought you were asking because of my https://bugreports.qt.io/browse/QTBUG-54822 comment where I stated i386 and armhf started segfaulting
[10:06] <tsdgeos> Mirv: yes, i am
[10:07] <tsdgeos> Mirv: the question is, i386 and armhf started segfaulting untiy8, but what about arm64, all was fine?
[10:07] <Mirv> tsdgeos: the autopkgtests are not run on arm64
[10:07] <tsdgeos> i see
[10:07] <Mirv> so I don't know. but amd64 was fine.
[10:08] <tsdgeos> so what was failing before?
[10:08] <Mirv> tsdgeos: and, qtdeclarative built and ran its own tests on arm64, which wasn't the case without he patch.
[10:08] <tsdgeos> ok the tests
[10:08] <Mirv> tsdgeos: everything on arm64 that executes any qml, like qmlplugindump
[10:08] <tsdgeos> i'm getting a chroot with that qt on
[10:08] <tsdgeos> see if i can pin point what would be the problem
[10:08] <Mirv> tsdgeos: ok. on armhf?
[10:09] <tsdgeos> on i386
[10:09] <Mirv> oh, right
[10:09] <tsdgeos> well amd64 hardware but a i386 chroot
[10:09] <Mirv> tsdgeos: yeah, great, I was hoping to ask you to do something like that :)
[10:09] <tsdgeos> let's see if that still has it crashing
[10:09] <Mirv> tsdgeos: autopkgtests are now rerunning with unity8 rebuilt, but there is some worry as even ubuntu-system-settings-online-accounts on i386 (not armhf) shows segfaults: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2055-excuses/2016-10-10_08:15:02/2055_yakkety_excuses.html
[10:10] <Mirv> so that's why I was asked about the needs to rebuild, since u-s-s-o-a does not use private headers
[10:10] <tsdgeos> yeah then no
[10:39] <dr_gogeta86> hi guys
[10:55] <faenil> ondra: dr_gogeta86 is looking for help on HW adaptation, can you assist him or find someone who can? ^
[10:56] <dr_gogeta86> tnx faenil
[11:06] <tsdgeos> Mirv: can you add the uitk to the silo and rebuild too?
[11:06] <tsdgeos> Mirv: at least unity8 gdb trace says http://paste.ubuntu.com/23302609/
[11:06] <tsdgeos> so worth rebuilding the uitk
[11:12] <Mirv> tsdgeos: ok
[11:12] <Mirv> tsdgeos: I'm fine if it'd be limited to our private header users..
[11:12] <Mirv> let's see
[11:12] <tsdgeos> i'm also rebuilding it here, may be faster than the silo
[11:12] <tsdgeos> or not D:
[11:22] <tsdgeos> Mirv: yeah rebuild of the uitk helped locally
[11:23] <tsdgeos> Mirv: basically i'd say we need to rebuild everything that uses qtdeclarative-private
[11:58] <Mirv> tsdgeos: hmm..
[11:59] <Mirv> tsdgeos: then there's also the problem of vivid, I tried to apply the patch on top of 5.4 qtdeclarative and it did not only fail here or there, but pretty spectacularly
[12:00] <Mirv> tsdgeos: anyway, rebuilding qtdeclarative-abi using packages is doable, although for yakkety a bit of problem because it's being released
[12:20] <tsdgeos> Mirv: do we really care for arm64+vivid+overlay?
[12:23] <Mirv> tsdgeos: well, no, true, just bileto will shout but otherwise meaningless
[12:26] <Mirv> tsdgeos: doh, ui-toolkit fails two tests on arm64 in that silo
[12:26] <tsdgeos> well at least it doesn't crash? :D
[12:26] <Mirv> well, I'm suspicious that it fails the tests in test file tst_textinput_touch.SEGFAULT.11.qml :D
[12:26] <tsdgeos> hmmm
[12:26] <tsdgeos> yeah :D
[12:28] <tsdgeos> Mirv: and without the patch it was good? or?
[12:43] <Mirv> tsdgeos: well it's the same source that landed last Friday and was built a week ago, but I can see in another silo if something else changed meanwhile to cause that
[12:43] <Mirv> it's useful that silos are "free" now
[12:43] <tsdgeos> Mirv: sure but was that with the "bad" kernel?
[12:45] <Mirv> tsdgeos: oh right I can't test it in a clean silo since because of the new kernel it will fail even more if the qtdeclarative is not there
[12:45] <Mirv> tsdgeos: yes the successful build was with the earlier kernel
[12:46] <tsdgeos> it's sad Qt upstream doesn't have arm64 CI
[12:46] <tsdgeos> so we're the ones suffering from this
[12:46] <tsdgeos> Mirv: so it aws arm64 the only one failing on the new silo with qtdeclarative, toolkit and unity8, right? no other arch
[12:47] <Mirv> tsdgeos: yes: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2055/+packages
[12:47] <tsdgeos> which means there's no way for me to help
[12:48] <Mirv> tsdgeos: buy a frieza :)
[12:48] <tsdgeos> do we actually run the M10 on arm64? i thought we didn't
[12:50] <Mirv> tsdgeos: well not "really really" but there's something experimental that boots ubuntu-device-flash touch --channel=ubuntu-touch/staging/ubuntu --device=frieza_arm64
[12:50] <tsdgeos> and with that i'd get "the bad kernel" ?
[12:51] <Mirv> tsdgeos: oh, right, no. stupid me. but if it's something else (the UITK test failure), it could be seen there. but frieza always uses 3.10 kernel so we have no way to access hardware with that.
[12:52] <Mirv> ..that 4.4 kernel that causes these problems
[12:53] <tsdgeos> meh
[12:55] <tsdgeos> so what is actually running the bad kernel?
[12:55] <Mirv> we could land this silo to z + xenial-overlay anyway by disabling those two subtests in UITK, if no other problems
[12:55] <tsdgeos> some magic hardware?
[12:55] <Mirv> tsdgeos: the Launchpad builders
[12:56] <tsdgeos> is it qemu'ed? or there's actual hardware in there?
[13:00] <Mirv> actual arm64 hardware that was upgraded from 4.2 kernel to 4.4
[13:00] <Mirv> and 4.4 kernel has CONFIG_ARM64_VA_BITS=48 enabled
[13:03] <tsdgeos> ok
[13:06] <Mirv> on #ubuntu-kernel I'm trying to ask if there is any chance of tweaking that option... I'd guess they have their reasons
[13:06] <Mirv> meanwhile I pushed qtmir* qtubuntu* to the same silo
[13:13] <yang_> is BQ Aquaris M10 the only tablet with Ubuntu touch OS ? Is there any new device to be made soon ?
[14:22] <kaisoz> hi!
[15:30] <abeato> jdstrand, hi, the ofono PR is ready again for review
[17:12] <oSoMoN> ogra_, hey, do you happen to remember why that was needed? https://bazaar.launchpad.net/~phablet-team/ubuntu-touch-session/trunk/revision/106
[17:15] <ogra_> oSoMoN, autopilot tests
[17:15] <ogra_> and to run apps from adb shell
[17:15] <ogra_> (or ssh login)
[17:16] <oSoMoN> ogra_, ok, thanks
[20:14] <ledufakademy> hello