#ubuntu-qt 2018-07-10
<lubot> <Santa> @mitya57 there is this: "Build-Depends-Indep: qtbase5-doc-html (>= 5.11.1+dfsg~)" in qttools. I think that B-D-I must be marked as "<!nodoc>". Otherwise the package won't build in "nodoc" mode.
<lubot> <mitya57> @Santa, Do you actually use nodoc?
<lubot> <mitya57> That was just out of curiosity, I will fix it.
<lubot> <acheronuk> I thought nodoc didn't work with launchpad buildds?
<lubot> <mitya57> Right, it is only useful for local builds.
<lubot> <acheronuk> what about debian buildds? I think Santa is doing builds on his own wannabuild setup
<lubot> <mitya57> Both pbuilder and sbuild support build profiles if you set them manually.
<lubot> <mitya57> Anyway, https://salsa.debian.org/qt-kde-team/qt/qttools/commit/dc52d3ffb4948e3b8a0bbcc6ba812c4aecd82981
<lubot> <acheronuk> @Santa I assume your new tooling isn't depending on nodoc profile to build on LP? excuse me, as I've not really looked at the new scripts
<lubot> <Santa> what it does is building as nodoc for the bootstrapping
<lubot> <acheronuk> @Santa, that works on a launchpad ppa?
<lubot> <Santa> to do this it sets the nodoc profile altering the debian/rules and it also removes the <!nodoc> build depends
<lubot> <Santa> and yes, it should work on a launchpad ppa, but I haven't tested yet
<lubot> <Santa> thanks for the fix @mitya57
<lubot> <acheronuk> @Santa, right. it was a long while ago I tried it, and probably not like that
<lubot> <acheronuk> sorry for that. I just had a horrible idea of it all working great on tritemo, then crashing and burning on launchpad!
<lubot> <acheronuk> but you have it covered :)
<lubot> <Santa> we will see, we have to test. I did that on tritemio first just to test the waters
<lubot> * acheronuk nods
<lubot> <tsimonq2> @acheronuk I asked if they'd ever implement nodoc support in Launchpad and was told "no, it's a niche thing"
#ubuntu-qt 2018-07-11
<valorie> why would we want nodoc ?
<lubot> <tsimonq2> The problem with Qt packages is that in order to do a stack which bumps ABI, the documentation needs a bootstrapping process.
<lubot> <tsimonq2> Which means you need to do ~ 10 uploads, wait for all of them to correctly build against each other, then reupload with some stuff re-enabled.
<lubot> <tsimonq2> It's a bit time consuming.
<valorie> and?
<lubot> <tsimonq2> nodoc allows you to skip that process.
<valorie> got it
#ubuntu-qt 2018-07-12
<lubot> <tsimonq2> @mitya57 What do you make of this QtWebEngine FTBFS? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3291/+packages
<lubot> <acheronuk> Missing  (arch=i386)CavlcParamCal_sse2@Qt_5 5.10.1 and (arch=i386)vp8_six_tap_x86@Qt_5 5.9.0
<lubot> <acheronuk> other non ooptional missing are ones you added in 9e2a6814 with an amd64 build?
<lubot> <tsimonq2> Ah maybe
<lubot> <mitya57> @tsimonq2, I will do a new experimental upload with updated symbols today.
<lubot> <tsimonq2> @mitya57, Thanks!
<lubot> <mitya57> It would be nice to wait until the mipsel buildlog is ready, but if it does not start until the evening (in my TZ) then I will update symbols without mipsel.
<lubot> <tsimonq2> OK thanks
#ubuntu-qt 2018-07-14
<tsimonq2> mitya57: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3291/+build/15121400 qtwebengine is FTBFS on arm64 in the PPA.
<mitya57> Oh, internal compiler error :(
<lubot> <tsimonq2> I retried, I'm hoping it's just a one time thing
<lubot> <acheronuk> (Document) http://vps.tsimonq2.net//file_4032.gz
<lubot> <tsimonq2> Rik has the log
<lubot> <tsimonq2> You can see it in Telegram; I dunno if my bridge works with files anymore properly
<lubot> <mitya57> I had the log too :)
<lubot> <tsimonq2> Ah cool
<lubot> <mitya57> But the bridge does not seem to work, http://vps.tsimonq2.net//file_4032.gz â 404
<lubot> <acheronuk> I also set it rebuilding in a seperate PPA
<lubot> <tsimonq2> @mitya57, Right
<lubot> <acheronuk> A quick google seemed to suggest maybe out of memory/swap for similar errors, but google could be wrong
<lubot> <acheronuk> and I don't know enough about building this to judge
<lubot> <mitya57> Out of memory usually happens during linking phase, but here it died compiling a single C++ file (`render_frame_devtools_agent_host.cc`)
<lubot> <acheronuk> https://medium.com/hi-z-labs/yocto-qt5-b2qt-build-fails-on-qtlocation-or-qtwebengine-with-cryptic-gcc-error-1051a7effe3a
<lubot> <mitya57> OK :)
<lubot> <acheronuk> that failed on compiling render_frame_host_manager.cc
<lubot> <mitya57> If it is a memory issue then using --no-parallel may help.
<lubot> <acheronuk> that would take how many days to build? :P
<lubot> <tsimonq2> @mitya57, Let's see if it's erraneous and builds on this next go. If it doesn't build, then let's do that.
<lubot> <acheronuk> you have it building in ci-train. I have a build going in a private ppa. so by this evening we should see the result of those
<lubot> <tsimonq2> True.
<lubot> <mitya57> [Normal build](https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3237-deletedppa/+build/14765245) (with -j4) took 12 hours, so -j1 would take just two days :)
<lubot> <acheronuk> urgh
<lubot> <acheronuk> @mitya57 FTBFS on same render_frame_devtools_agent_host again
<lubot> <acheronuk> same on my other ppa build
<lubot> <mitya57> Ok, so our options are:
<lubot> - try --no-parallel / -j1
<lubot> - force another compiler (older gcc?)
<lubot> - try with different compiler options
<lubot> - ask doko or on ubuntu-devel@
<lubot> <acheronuk> either that is a real kill point on mem usage, or there as you suggested is more to it than just that
<lubot> * acheronuk tries Neon's packaging for the hell of it
<lubot> <acheronuk> more for curiosity than anything else, and on an out the way ppa
<lubot> <Lazy B> (Photo, 477x71) https://i.imgur.com/DwbJcBl.jpg
<lubot> <Lazy B> (Photo, 732x173) https://i.imgur.com/l0hgJZM.jpg
<lubot> <Lazy B> RPL_CONSUMER_TYPE_ERASED_ALWAYS macro instructs gcc to use less memory
<lubot> <Lazy B> Compilation time will be (almost) not affected
<lubot> <Lazy B> It's also possible to use -g1 glag to generate less debuging information
<lubot> <Lazy B> But rather to disable it if it's enabled
<lubot> <mitya57> @Lazy B, I think our qtwebengine has all debugging disabled already.
#ubuntu-qt 2018-07-15
<lubot> <tsimonq2> @mitya57 Did you want to do something about QtWebEngine or should I?
<lubot> <mitya57> @tsimonq2, I donât know a solution. But you can try of course, maybe what Lazy suggested.
<lubot> <tsimonq2> Fwd from mitya57: Ok, so our options are:
<lubot> - try --no-parallel / -j1
<lubot> - force another compiler (older gcc?)
<lubot> - try with different compiler options
<lubot> - ask doko or on ubuntu-devel@
<lubot> <tsimonq2> Is this still valid?
<lubot> <mitya57> Still valid, but no promise it will work :)
<lubot> <acheronuk> @mitya57, RPL_CONSUMER_TYPE_ERASED_ALWAYS ?
<lubot> <mitya57> This is what he suggested, but I never used that.
<lubot> <tsimonq2> I'll upload with `--no-parallel`
<lubot> <acheronuk> @tsimonq2, that will finish building on ummmmm..... Friday?
<lubot> <acheronuk> :P
<lubot> <tsimonq2> @acheronuk, Tuesday LO
<lubot> <tsimonq2> *:P
<lubot> <acheronuk> I vaguely recall launchpad killing webengine builds that used âno-parallel as it thought builds had stalled?
<lubot> <acheronuk> maybe I misremember, or that was fixed
<lubot> <tsimonq2> Just poked in #launchpad
<lubot> <acheronuk> I wasn't total time if I recall, but that with only one process, certain parts of the build went so long between output, that LP thought the build had died
<lubot> <mitya57> @acheronuk, Yes, it was fixed in https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.9.5+dfsg-0ubuntu2
<lubot> <acheronuk> @mitya57, ð
<lubot> <acheronuk> @tsimonq2, failed with same error
<lubot> @mitya57
<lubot> <mitya57> ð
<lubot> <acheronuk> @mitya57, odd. build times for amd64 and i386 were quicker, and the arm64 failure came around the same build time (in relative terms), so I wonder if the change Simon did actually had the intened effect?
<lubot> <acheronuk> I have no experiance with builds that use ninja, so I shrug
<lubot> <mitya57> There are 5 commands printed after the failed one, so it is still parallel
<lubot> <mitya57> Looks like ninja defaults to parallel, so you need to pass -j1 explicitly to it.
<lubot> <acheronuk> @mitya57, in export NINJAFLAGS ?
<lubot> <mitya57> Is there such a variable?
<lubot> <acheronuk> @mitya57, that seems to think so? https://salsa.debian.org/qt-kde-team/qt/qtwebengine/blob/experimental/debian/rules#L6
<lubot> <mitya57> Oh, right, it is understood not by ninja itself but by `src/core/gn_run.pro` which adds them to ninja commandline
<lubot> <mitya57> So `export NINJAFLAGS=-v -j1` will make the build non-parallel, but there is still no promise that it helps.
<lubot> <tsimonq2> @mitya57, Can one of you do it? :)
<lubot> <tsimonq2> (I ask because the earliest I can is in six hours...)
#ubuntu-qt 2019-07-12
<lubot> <RikMills> @mitya57 FINALLY plasma is through its tests!. Sorry about that. ppc64el decided to to be broken/slow just at the wrong time :/
<lubot> <mitya57> Has it already migrated?
<lubot> <RikMills> @mitya57 [Has it already migrated?], Yes, it did overnight.
<lubot> <mitya57> So I will now update some packages in the PPA and it will be ready to land in a couple of hours :)
<lubot> <RikMills> Great :)
<lubot> <RikMills> Might need to apply this: https://commits.kde.org/kpackage/886f7f4004e55f4eb3d61c15ec10d64878fc1dbd
<lubot> <mitya57> kpackage is not on the rebuild list, so it won't block the transition. But I can still do it if you want.
<lubot> <RikMills> Lets wait and see then
<lubot> <Santa> @RikMills [Might need to apply this: https://commits.kde.org/kpackage/886f7f4004e55f4eb3d61 â¦], kpackage was built sucessfully on the test rebuilds; both 5.59 and 5.60
<lubot> <mitya57> @Santa [kpackage was built sucessfully on the test rebuilds; both 5.59 and 5.60], This may be a compiler warning, not fatal error
<lubot> <Santa> aha
<lubot> <mitya57> By the way Qt 5.12.4 is now in Eoan-proposed
<lubot> <Santa> btw I found a bug in the status pages I'm using on my servers so I'm retrying some failed, undetected autopkgtest failures
<lubot> <Santa> @mitya57 [By the way Qt 5.12.4 is now in Eoan-proposed], ok
<lubot> <RikMills> @mitya57 [By the way Qt 5.12.4 is now in Eoan-proposed], Great. ð â¦ Test infra will have a busy weekend!
* RikMills changed the topic of #ubuntu-qt to: Ubuntu Qt Discussion Channel | https://is.gd/GIZG9E | 5.12.4 in Eoan-proposed | 5.12.2 in Disco, 5.11.1 in Cosmic, 5.9.5 in Bionic, 5.5.1 in Xenial | Help remove Qt 4! https://is.gd/QXLEFW | This channel is bridged to Telegram, ask us to be added | This channel is LOGGED at irclogs.ubuntu.com; use implies acceptance of the Ubuntu IRC channel terms.
<lubot> <RikMills> ginga test fail against pyqt5 is the fault of new astropy in proposed, not pyqt5 â¦ Probably obvious, but thought I would say.....
<mitya57> pyotherside needs a rebuild, but I have just sponsored a new version in Debian, will sync it tomorrow
<mitya57> Looks like removal of pytest_plugins in astropy was an intended change: https://github.com/astropy/astropy/blob/master/CHANGES.rst#astropytests-4
<mitya57> So we should probably cherry-pick https://github.com/ejeschke/ginga/commit/0305b79e85bbb0c01e95c6e99dbfab2ff21f688c
#ubuntu-qt 2019-07-13
<lubot> <RikMills> webcamopid goes OOM on ppc64el? It does that now in a test against itself in release pocket, so not Qt's fault
<lubot> <RikMills> https://twitter.com/launchpadstatus/status/1149924386461253632
<lubot> <mitya57> @RikMills Thanks for making the virtualbox tests pass (whatever magic you applied), and also thanks for committing my libfm-qt change to git.
<lubot> <mitya57> I have now uploaded fixed ginga and retried pyotherside tests, so webcamoid should be our main blocker.
<lubot> <RikMills> np. Thanks
<lubot> <RikMills> We can probably get Qt hinted past webcamoid for now, but obviously would be nice to fix. â¦ Its also suspicious that we had all the ppc64el issues end of the week, and now this fail. Perhaps something they did to get the ppc64el test runners unstuck has had that impact
<lubot> <mitya57> It started failing on 2019-07-09 03:13:16 UTC, I guess that was one earlier than the queue problem
<lubot> <RikMills> could have been. whatever, not Qt's fault :)
<lubot> <mitya57> I will ask on #ubuntu-release now
<lubot> <RikMills> or could that be default gcc change? dunno
<lubot> <mitya57> That may be related. The last successful build was with GCC 8, the first failing one is with GCC 9.
<lubot> <RikMills> I note that there is a new webcamoid in experimental. I have no clue if that might help
<lubot> <UniversalSuperBox> So, QtWebEngine 5.13 has tons of improvements for touch devices and that makes me quite interested in it. Is it being blocked by time, technicality, a decision to stick on 5.12?
<lubot> <mitya57> I think nothing changed so far: we stick to 5.12 (for Eoan) at least, but if WebEngine 5.13 builds against Qt 5.12 then we may ship it.
<lubot> <mitya57> If you want to test whether it builds/works in such configuration, that would be welcome.
<lubot> <x_sun> Yeah, it builds against 5.12, experienced a few crashes though
<lubot> <x_sun> I was bulding with no debug symbols because the amount of space on lp is limited
<lubot> <UniversalSuperBox> Did you have to update any patches from what's in https://salsa.debian.org/qt-kde-team/qt/qtwebengine/tree/experimental/debian/patches now?
<lubot> <mitya57> We build with -g1 and that works on LP
<lubot> <x_sun> Patches are still missing, gonna look at them later
<lubot> <x_sun> (Photo, 347x183) https://i.imgur.com/RGIfISW.jpg That's what I have so far
<lubot> <RikMills> Qt migrating
<lubot> <RikMills> @mitya57 thank you.
<lubot> <mitya57> \o/ This time it was fast!
