#ubuntu-qt 2018-05-22
<lubot> <acheronuk> http://blog.qt.io/blog/2018/05/22/qt-5-11-released/
<lubot> * acheronuk pokes @tsimonq2
<lubot> go go go go go go.........
<lubot> <tsimonq2> lol
<lubot> <tsimonq2> Thanks for the heads up @acheronuk
<lubot> <tsimonq2> First, I'll make sure the "transition" in Experimental is finished.
<lubot> <tsimonq2> "Branching from '5.9' -> '5.9.6' now done and '5.9' is for Qt 5.9.7. So all changes targeted to Qt 5.9.6 must be done in '5.9.6' from now on.
<lubot> Target is to create Qt 5.9.6 "rc" soon, test it and if all OK release Qt 5.9.6 at the beginning of June. So please make sure all release blockers are visible in 5.9.6 blocker list ([https://bugreports.qt.io/issues/?filter=19339 )](https://bugreports.qt.io/issues/?filter=19339))"
<lubot> <tsimonq2> Qool
<lubot> <Lazy B> Means 5.9.6 will land bionic?
<lubot> <tsimonq2> @Lazy B, Yes.
<blaze> noice
<lubot> <tsimonq2> From #kubuntu-devel
<lubot> <tsimonq2> Fwd from IrcsomeBot: <sitter> Mirv: FYI in case you end up putting qt 5.10+ into a snap: beware temporary file problems https://packaging.neon.kde.org/qt/qtbase.git/commit/?h=Neon/release&id=13e45db62e9f7bcf9703858eb7d55953cdfb4c36
#ubuntu-qt 2018-05-23
<valorie> from #kde-neon earlier:
<valorie> 02:41] <bcooksley> someone who works in the Debian Qt repos using the ubuntu branches also patently decided at some point to change from have a branch 'ubuntu' to a branch 'ubuntu/...'
<valorie> [02:41] <bcooksley> as Python-Git is going bang
<valorie> [02:41] <bcooksley> FileExistsError: [Errno 17] File exists: '/home/neon/repositories/qt/qt5webkit.git/refs/heads/ubuntu'
<mitya57> They need to do âgit remote prune originâ.
<mitya57> Also, blame tsimonq2 :)
<valorie> mitya57: perhaps speak to bcooksley about it?
 * valorie is just the messenger
<mitya57> /me joins #kde-neon
<valorie> well, #kde-sysadmin is where you'll always find him, but yeah
<valorie> :-)
#ubuntu-qt 2018-05-24
<lubot> <tsimonq2> lol
<lubot> <tsimonq2> Yes, blame me.
#ubuntu-qt 2020-05-18
<lubot> <mitya57> @RikMills [<RikMills> 5.14.2 landing], \o/
<lubot> <RikMills> now the trick is getting it to release :P
<mitya57> lisandro: I think we should ship private headers if kwayland-server needs them. See what mamarley said above. What do you think?
<mitya57> Asking because you marked Debian #894472 as wontfix.
<ubottu> Debian bug 894472 in libqt5waylandclient5-dev "libqt5waylandclient5-dev: Missing QtWayland private headers" [Wishlist,Open] http://bugs.debian.org/894472
<lubot> <RikMills> https://launchpad.net/~kubuntu-ninjas/+archive/ubuntu/plasma/+build/19316031
<lubot> <RikMills> @mitya57 so there will be no newer Plasma in 20.10 if you don't
<lubot> <mitya57> Ack
<lubot> <mitya57> But we can wait until the current transition lands, right?
<lubot> <RikMills> Yes, I think so. I can shove a qtwayland build with the headers in my plasma staging ppa in the meantime
<lubot> <RikMills> Sorry. I did not know about this, as I have not been able to try to build the new plasma without 5.14
<lubot> <mitya57> No problem
<lubot> <RikMills> I will also double check the requirement if I can. I have asked in Neon channel
<lubot> <RikMills> They added the package there, but the git log is not very informative
<lubot> <RikMills> maybe it is needed for some plasma-mobile stuff which we do not build at the moment
<lubot> <RikMills> so far just building kwayland-server seems not to need private headers, but building the tests seems to need qtbase private. opensuse do not build with them or the tests
<lubot> <mitya57> qtbase private headers are all there :)
<lubot> <RikMills> indeed. when the right people from Neon show up today, I will try to clarify why they wanted the qtwayland private things and put a build depend on them
<lubot> <RikMills> https://launchpad.net/~kubuntu-ninjas/+archive/ubuntu/plasma/+build/19318324
<lubot> <RikMills> that builds ok with no private anything and tests disabled
<lubot> <x_sun> (Photo, 977x171) https://i.imgur.com/zvWpQui.jpg
<lubot> <x_sun> (Photo, 1061x175) https://i.imgur.com/j5HAGWR.jpg Launchpad build fails where my local build works just fine. I hate this stuff ð
<lubot> <tsimonq2> @x_sun [<reply to image>], How are you building it locally?
<lubot> <x_sun> Clean vm
<lubot> <tsimonq2> Cross ref build deps and versions pulled in by infra vs local copy
<lubot> <tsimonq2> There's a file that tells you this, hmm..
<lubot> <tsimonq2> Alright wtf LP
<lubot> <tsimonq2> LP builders build the buildinfo file
<lubot> <tsimonq2> But don't actually publish it
<lubot> <tsimonq2> That can't be right...
<lubot> <tsimonq2> @x_sun [Clean vm], In any case, since I'm done going down that rabbit hole, try sbuild
<lubot> <tsimonq2> So a very very very minimal install
<lubot> <x_sun> It was on my radar, yeah
<lubot> <tsimonq2> Cool
<lubot> <RikMills> @mitya57 I am now told by kde devs that the qtwayland private headers are not needed for kwayland-server, which just conforms what experimentation already showed
<lubot> <RikMills> No idea why Neon added that build dep
<lubot> <x_sun> But I think that the reason Ninja fails here can be that `<<BUILDDIR>>` path
<lubot> <mitya57> @RikMills [@mitya57 I am now told by kde devs that the qtwayland private headers are not ne â¦], Ok, private headers can wait then. (Lisandro prefers we wait until 5.15)
<lubot> <mitya57> @x_sun [But I think that the reason Ninja fails here can be that <<BUILDDIR>> path], <<BUILDDIR>> is not an actual build directory, it's what it is replaced with in the log.
<lubot> <x_sun> @mitya57 [<<BUILDDIR>> is not an actual build directory, it's what it is replaced with in â¦], Yeah, but I'm 99% sure there's something wrong with the path just looking at the problematic line of `toolchain.ninja`
<lubot> <x_sun> My guess is that tilde `~` is not allowed there ð¤·
<lubot> <x_sun> Is there a way to hack a LP builddir location without changing the package version?
<lubot> <x_sun> Guess what, I've managed to reproduce the issue on a local vm
<lubot> <x_sun> (Photo, 1089x117) https://i.imgur.com/TvXe9u6.jpg
<lisandro> mitya57: wrt private headers: (1) considering the null amount of time I have been able to put into Qt it's really up to you (2) whatever KDE is part of the Debian Qt/KDE team's responsability, so yes, if I where to make the decistion I would go forward
<lisandro> I guess that if I could really put all the necessary effort into Qt packaging I would certainly try to ship all private headers. But IMPOV that's nealy a paid job thing
<lisandro> *nearly
<mitya57> lisandro: looks like KDE actually doesn't need it right now, and it can wait until 5.15.
<lubot> <RikMills> The KDE person who wanted it could not remember why they wanted the headers in Neon Qt.
<lubot> <mitya57> @RikMills [thanks. I have not checked through yet, but anything in sync with debian do you â¦], Bugs filed at https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-qt-kde@lists.debian.org;tag=qt5.14
<lubot> <mitya57> vorlon deleted qtwebengine from proposed. âdisentangle Qt from protobufâ ð¤
<mamarley> Yeah, and completely wreck the dependencies for KDEâ¦
#ubuntu-qt 2020-05-19
<lubot> <RikMills> (Photo, 806x335) https://i.imgur.com/HluyrWt.jpg
<lubot> <RikMills> @mitya57 you aware of anything such? ^
<lubot> <RikMills> I have a feeling some autotests failed with similar?
<lubot> <mitya57> In 5.14.2 I removed a patch that may be related.
<lubot> <RikMills> http://autopkgtest.ubuntu.com/packages/n/notepadqq/groovy/amd64
<lubot> <RikMills> tests failing with similar error
<lubot> <mitya57> https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/commit/e0bb0919ad7c7920dfdf59be36a2de6833cd72bf
<lubot> <mitya57> Also we are building with bundled ICU because Debian has an old version, in Ubuntu there is no such problem so maybe building with system ICU again will help.
<lubot> <RikMills> I have a groovy VM on another machine I can test any trial PPA build you might do
<lubot> <tsimonq2> @mitya57 [Interesting, vorlon reinstantiated the previous qtwebengine upload, I thought su â¦], copy-package takes any version as an argument
<lubot> <tsimonq2> And he's an AA so he has the powers
<lubot> <mitya57> @RikMills [I have a groovy VM on another machine I can test any trial PPA build you might d â¦], Will it be OK if I upload to the same PPA (4057)?
<lubot> <RikMills> Do you want to copy it to the archive from the PPA if it tests OK? if so, I think you will need a fresh ticket. If not, then should do no harm
<lubot> <mitya57> If it is one package then I can copy it manually.
<lubot> <RikMills> right. I have never tried that
<lubot> <RikMills> anyway, using that ppa should not steop us finalizing the ticket
<lubot> <mitya57> Uploaded.
<lubot> <mitya57> I wonder if I should have created a separate qml-module-qtqml package. Neon guys did not add it. And it breaks a few packages, e.g. kitemmodels.
<lubot> <mitya57> @RikMills what do you think?
<lubot> <mitya57> Looks like a separate .so file for that module was added as part of https://code.qt.io/cgit/qt/qtdeclarative.git/commit/?id=43573c8df170c566
<lubot> <RikMills> I guess it makes sense as you did it
<lubot> <RikMills> I think...
<lubot> <mitya57> The documentation lists it as a separate module (https://doc.qt.io/qt-5/qtqml-qmlmodule.html) and I think it is possible to use QtQml without importing it, so maybe that was correct, yes.
<lubot> <mitya57> In that case kitemmodels tests need to depend on it (outside of autotests directory, it is not used).
<lubot> <RikMills> shall I upload that then?
<lubot> <mitya57> Yes, please
<lubot> <RikMills> done
<lubot> <mitya57> Thanks
<lubot> <RikMills> missing symbols for qtwebengine :(
<lubot> <mitya57> Oops
<lubot> <mitya57> Will fix in 15 minutes
<lubot> <mitya57> Done.
<lubot> <RikMills> @mitya57 https://bugreports.qt.io/browse/QTBUG-82589
<lubot> <RikMills> https://bugs.mageia.org/show_bug.cgi?id=26200
<ubottu> bugs.mageia.org bug 26200 in RPM Packages "Kontact does not start because it is looking for qtwebengine in the wrong place" [Critical,Resolved: fixed]
<lubot> <mitya57> Interesting that qtdiag prints the right path.
<lubot> <mitya57> But this is without usrmerge. Do you have it enabled?
<lubot> <RikMills> I guess so. This is a default install
<lubot> <mitya57> Let me try to build qtbase with `-no-feature-relocatable` in that PPA.
<lubot> <RikMills> Ok. Thanks!
<lubot> <mitya57> Uploaded.
<lubot> <RikMills> aha https://packaging.neon.kde.org/qt/qtbase.git/commit/debian/rules?h=Neon/release&id=2cbf7f4d5d1ea1496d76f0a159187af96b3401c3
<lubot> <mitya57> So this was the right change :)
<lubot> <mitya57> FWIW, I uploaded qcustomplot which should fix the autopkgtest failure.
<fvogt> FYI, that's what upstream Qt recommends for system-wide installations anyway
<lubot> <RikMills> this change should fix notepadqq tests I hope
<mitya57> fvogt: Thanks for confirming!
<lubot> <mitya57> @RikMills [this change should fix notepadqq tests I hope], Maybe you can already test how kontact behaves? Qtbase built on amd64
<lubot> <RikMills> @mitya57 [Maybe you can already test how kontact behaves? Qtbase built on amd64], I tried a few mins ago. Had not published the amd64 in the PPA yet
<lubot> <mitya57> "Finished 50 minutes ago" â hopefully should be published soon
<lubot> <RikMills> Looks like it just has!
<lubot> <RikMills> @mitya57 fixed!
<lubot> <mitya57> Great! I am copying it to archive then.
<lubot> <mitya57> Or better to wait until it builds on all architectures and copy with binaries? What do you think?
<lubot> <RikMills> I think either way, some arches will not be done until after midnight my time. and riscv64 took 8 hrs last time, so waiting to binary copy that means tomorrow
<lubot> <RikMills> so I think I would source copy or upload
<lubot> <RikMills> that way autotests will get queued overnight
<lubot> <RikMills> as they do not wait for riscv64 to be done
<lubot> <mitya57> Copied with existing binaries. Apparently it was possible :)
<lubot> <RikMills> really? nice
<lubot> <RikMills> I assumed that would fail. handy to know
<lubot> <mitya57> For arm and riscv64 new builds are started.
<lubot> <RikMills> ah. I think it errors when there are binaries, but they are not published in the source archive. that must be what failed for me once before
<lubot> <mitya57> Maybe.
<lubot> <RikMills> I have triggered kitemmodels retests
<lubot> <RikMills> and I will probably do some more looking in the morning
<lubot> <mitya57> Thanks!
<lubot> <RikMills> sadly we are are queued behind about 1.5 billion perl tests ð
<lubot> <mitya57> ð±
#ubuntu-qt 2020-05-20
<lubot> * mitya57 retried some tests and uploaded pyqt5chart rebuild which was needed because https://bugreports.qt.io/browse/QTBUG-74752 was fixed and some symbols changed namespace
<lubot> <RikMills> Thanks. I got sidetracked fixing some plasma beta issues so far today
<lubot> <RikMills> qtsystems-opensource-src seems to be failing build time tests on riscv64. Ignore them?
<lubot> <mitya57> No full log yet, but I think making them non-fatal would work.
<lubot> <mitya57> E.g. by prepending `-` to the command
<lubot> <RikMills> Yeah, that is what I intended
<lubot> <RikMills> @mitya57 [E.g. by prepending - to the command], does not work. just fails the build with env: â-dbus-test-runnerâ: No such file or directory
<lubot> <mitya57> Prepend before `env`, that's where the command begins
<lubot> <RikMills> thanks. I should have seen that
<lubot> <mitya57> @x_sun [@mitya57 FYI Polymer exclusion from qtwebengine 5.14.2 breaks embedded pdf viewe â¦], Can you please test qtwebengine from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4072/+packages and check if it fixes that issue?
<lubot> <x_sun> (Photo, 1169x823) https://i.imgur.com/mcM7PH5.jpg Everything looks fine
<lubot> <mitya57> Thanks a lot for testing! I will publish it then when it builds on all architectures.
<lubot> <x_sun> No prob
#ubuntu-qt 2020-05-21
<lubot> <mitya57> Sigh, qtwebengine armhf/arm64 builds keep failing without any log
#ubuntu-qt 2020-05-22
<lubot> <RikMills> https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.14.2+dfsg-1build1
<lubot> <mitya57> Argh
<lubot> <mitya57> So I will need to rebuild my PDF viewer fix again
<lubot> <RikMills> did you sort out the FTBFS?
<lubot> <mitya57> No :(
<lubot> <mitya57> I asked on #launchpad, the answer was that Qt WebEngine probably DoSes the builders.
<lubot> <mitya57> That landing can probably wait until the current set of packages migrates. If the current upload in archive builds, of courseâ¦
<lubot> * mitya57 just filed bug 1880141 which is needed for https://autopkgtest.ubuntu.com/packages/f/forensics-all/groovy/s390x
<ubottu> bug 1880141 in nmapsi4 (Ubuntu) "Please remove nmapsi4 and forensics-all on ppc64el, riscv64, s390x" [Undecided,New] https://launchpad.net/bugs/1880141
<lubot> <RikMills> @mitya57 [/me just filed bug 1880141 which is needed for https://autopkgtest.ubuntu.com/pa â¦], I asked vorlon to remove the binaries a few days ago. he did it
<ubottu> bug 1880141 in nmapsi4 (Ubuntu) "Please remove nmapsi4 and forensics-all on ppc64el, riscv64, s390x" [Undecided,New] https://launchpad.net/bugs/1880141
<lubot> <RikMills> @mitya57 [That landing can probably wait until the current set of packages migrates. If th â¦], If it fails to build, we can probably ask for the original one with the Qt transition to be re-instated
<lubot> <RikMills> https://irclogs.ubuntu.com/2020/05/20/%23ubuntu-release.html#t20:54
<lubot> <RikMills> actually, I think we should for QtWebEngine to be rolled back anyway, because even if it builds it will entangle the re2 transition, which in turn entangles the perl transition, with Qt
<lubot> <RikMills> I have asked
<lubot> <mitya57> Thanks!
<lubot> <mitya57> @RikMills [I asked vorlon to remove the binaries a few days ago. he did it], I wonder what needs to be done to make the autopkgtest failure not block Qt then.
<lubot> <RikMills> @mitya57 [I wonder what needs to be done to make the autopkgtest failure not block Qt then â¦], Restrict the arches for which forensics-all-gui depends on nmapsi4?
<lubot> <mitya57> Ah, right. Will do.
<lubot> <RikMills> That's if I am reading the output right....
<lubot> <mitya57> https://launchpadlibrarian.net/480910901/buildlog_ubuntu-groovy-amd64.forensics-all_3.18ubuntu1_BUILDING.txt.gz â¦ ð
<lubot> <mitya57> I guess I will move that to Recommends.
<lubot> <RikMills> urgh. yeah
<lubot> <mitya57> Fixed and also created a merge request for Debian: https://salsa.debian.org/pkg-security-team/forensics-all/-/merge_requests/2
-queuebot:#ubuntu-qt- Packageset: Added qt5-ukui-platformtheme to ubuntukylin in bionic
-queuebot:#ubuntu-qt- Packageset: Added qt5-ukui-platformtheme to ubuntukylin in focal
-queuebot:#ubuntu-qt- Packageset: Added qt5-ukui-platformtheme to ubuntukylin in groovy
-queuebot:#ubuntu-qt- Packageset: Added qt5-ukui-platformtheme to ubuntukylin in eoan
#ubuntu-qt 2020-05-23
<lubot> <RikMills> qtbase and most of the rest on the transition is a valid candidate. a few things entangled via proj and re2
<lubot> <mitya57> @RikMills [qtbase and most of the rest on the transition is a valid candidate. a few things â¦], I see you retried http://autopkgtest.ubuntu.com/packages/r/r-cran-lwgeom/groovy/s390x but it failed again :(
<lubot> <RikMills> @mitya57 [I see you retried http://autopkgtest.ubuntu.com/packages/r/r-cran-lwgeom/groovy/ â¦], I just tried it for the hell of it.
<lubot> <RikMills> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961211
<ubottu> Debian bug 961211 in src:r-cran-lwgeom "r-cran-lwgeom: autopkgtest failures on s390x" [Serious,Open]
#ubuntu-qt 2020-05-24
<lubot> <mitya57> After 5 days of failures for unknown reasons, now qtwebengine failed with symbols errors on armhf :)
<lubot> <mitya57> (In https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4072/+packages, not in archive)
<lubot> <RikMills> Progress. Good. :)
