#ubuntu-qt 2018-01-29
<lubot1> <tsimonq2> Alright, so qtbase seems fine, doing a reupload without the ~1 and tagging/pushing
<lubot1> <tsimonq2> I'll work on the Qt transition more tomorrow afternoon, but I expected that arch:all failure (ABI bump...)
<lubot1> <tsimonq2> Shouldn't be a big deal as we already have arch:all binaries published from ~1
<lubot1> <tsimonq2> Just uploaded a fix for this: https://bugs.launchpad.net/ubuntu/+source/qttools-opensource-src/+bug/1739955
<ubottu> Launchpad bug 1739955 in qttools-opensource-src (Ubuntu Xenial) "Qt5UiTools.pc Requires: non-existent Qt5UiPlugin" [Medium,In progress]
<lubot1> <tsimonq2> Night :()
<lubot1> <tsimonq2> *:)
<valorie> sweet dreams, tsimonq2
<lubot1> <mitya57> @tsimonq2, I agree with the ABI bump
<lubot1> <mitya57> @tsimonq2, Thanks for the SRU!
<lubot1> <tsimonq2> @mitya57, OK cool
<lubot1> <tsimonq2> @mitya57, Yw :)
<lubot1> <mitya57> https://lists.ubuntu.com/archives/ubuntu-devel/2018-January/040118.html
<lubot1> <mitya57> Looks like we'll have to include the OpenSSL 1.1 patch in our packaging
<lubot1> <mitya57> The Fedora patch in question is probably this one: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qt5-qtbase-5.9.1-openssl11.patch?id=8cedb395cff98495c47819d048d3d1619c887918
<lubot1> <mitya57> 4k lines, not the best thing to have
<lubot1> <tsimonq2> Ack
<lubot1> <mitya57> @tsimonq2 When working on qttools, please merge the latest version from Debian. Ubuntu is currently two uploads behind.
#ubuntu-qt 2018-01-30
<tsimonq2> Please don't crosspost.
<tsimonq2> whoops
<lubot1> <acheronuk> @tsimonq2  your force sync of libdbusmenu-qt breaks things.
<lubot1> <acheronuk> libdbusmenu-qt5 changes to libdbusmenu-qt5-2, with no breaks/replaces, so gets a dpkg can't overwrite error on the previous version
<lubot1> <acheronuk> and things will need rebuilds against the chaged lib name
<lubot1> <acheronuk> the overwrite error causes tests for FW 5.42 to fail
<acheronuk> $ reverse-depends libdbusmenu-qt5
<acheronuk> Reverse-Depends
<acheronuk> ===============
<acheronuk> * hud
<acheronuk> * libdbusmenu-qt5-dev
<acheronuk> * libkf5notifications5
<acheronuk> * lxqt-panel
<acheronuk> * lxqt-qtplugin
<acheronuk> * quassel
<acheronuk> * quassel-client
<lubot1> <tsimonq2> ack, thanks for the ping.
<lubot1> <mitya57> I would vote for rebuild rather than revert
<lubot1> <mitya57> And maybe add Breaks/Replaces for 18.04 only
<lubot1> <tsimonq2> I agree, right.
<lubot1> <acheronuk> Was just testing both of those in a PPA while waiting for you to wake up
<lubot1> <acheronuk> Just to see if it fixes my test failures as I supposed it would
<lubot1> <acheronuk> breaks/replaces, then a rebuild of knotifications makes the failing plasma-workspace test deps satisfiable again it seems
<lubot1> * acheronuk waits for the whole test to run
<lubot1> <acheronuk> autopkgtest [12:53:21]: @@@@@@@@@@@@@@@@@@@@ summary
<lubot1> testsuite            PASS
<lubot1> acc                  PASS
<lubot1> <tsimonq2> Hm ok
<lubot1> <tsimonq2> @acheronuk Can you upload a fix or is someone going to have to sponsor? ð
<lubot1> <acheronuk> I was upload perms for libdbusmenu-qt5 and knotifications. Other rebuilds, against that, I do not. or not all.
<lubot1> <acheronuk> *I have
<lubot1> <mitya57> I can rebuild the rest in ~2 hours
<lubot1> <acheronuk> @mitya57, Cool. That would be time to publish properly
<lubot1> <mitya57> Or if you want you can prepare everything in a silo and then I will publish it
<lubot1> <tsimonq2> He doesn't have silo access I don't think ð
<lubot1> <acheronuk> I don't have silo access.
<lubot1> <mitya57> Ok, no problem
<lubot1> <acheronuk> done
<lubot1> <mitya57> Sorry, was too busy with other things and forgot about the rebuilds. Will do a bit more later.
<LocutusOfBorg> mitya57, how bad is this upload? https://launchpad.net/ubuntu/+source/openmw/0.43.0-3ubuntu1
<LocutusOfBorg> specially because:   * Build-depend on libqt5opengl5-desktop-dev instead of
<LocutusOfBorg>     libqt5opengl5-dev, enforcing the fact that OpenMW only
<LocutusOfBorg>     works with -lgl and not -lgles/-gles2.
<LocutusOfBorg>     (Closes: #886362)
<LocutusOfBorg> is using "libqt5opengl5-desktop-dev" correct, right?
<lubot1> <mitya57> @LocutusOfBorg, If it works with desktop -lgl only, then it won't work on arm64â¦
<lubot1> <mitya57> So either your upload is wrong or the change in Debian is wrong.
<LocutusOfBorg> so, better sync next time and ask to drop on arm64? why Debian has it then?
<lubot1> <mitya57> There exist arm64 devices with both desktop OpenGL and GL ES
<lubot1> <mitya57> Historically Ubuntu built for the latter. In Debian arm64 was added later and the change was not applied.
<lubot1> <mitya57> As I said earlier, ideally it would be nice to drop this delta, but then we will have worse experience on devices like Raspberry Pi 3
<lubot1> <mitya57> Maybe we can build Qt Widgets with desktop OpenGL and Qt Quick with mobile? Need to investigate that.
<lubot1> <mitya57> The Qt OpenGL module (for which the -desktop-dev provides was added) is deprecated anyway.
<lubot1> <mitya57> I just pushed rebuilds of hud, lxqt-panel, lxqt-qtplugin and quassel
<lubot1> <tsimonq2> Kool
<lubot1> <acheronuk> Thanks
#ubuntu-qt 2018-02-01
<lubot1> <tsimonq2> Continuing the transition...
<lubot1> <tsimonq2> I've added the OpenSSL 1.1 support patch to qtbase in Git, and it's going through sbuild right now.
<lubot1> <tsimonq2> Gah, yeah, nopenopenope :)
<lubot1> <tsimonq2> @mitya57 Please try and apply that patch, no matter what I do, it seems to fail in spectacular fashion.
<lubot1> <tsimonq2> I realized I was wrong in not waiting to bump ABI until after bootstrapping was done so I'll revert that for now to make things work again :)
<lubot1> <tsimonq2> Going to bed, qtbase should be good when I wake up.
<lubot1> <tsimonq2> o/
<lubot1> <mitya57> @tsimonq2, What's the point of bumping ABI after bootstrapping? You'll have to rebuild everything anyway.
<lubot1> <acheronuk> https://mail.kde.org/pipermail/kde-distro-packagers/2018-February/000303.html
<LocutusOfBorg> mitya57, libqt5core5a/amd64 unsatisfiable Depends: libpcre2-16-0
<LocutusOfBorg> I think the pcre3 is still what we want in Ubuntu
<mitya57> LocutusOfBorg: https://bugs.launchpad.net/ubuntu/+source/pcre2/+bug/1636666/comments/22
<ubottu> Launchpad bug 1636666 in pcre2 (Ubuntu) "[MIR] pcre2" [Undecided,Incomplete]
<mitya57> Qt now only supports pcre2, not pcre3
<LocutusOfBorg> I know that page, and your bug seems nice
<LocutusOfBorg> LOL
<mitya57> I would like to get *any* reply on that bug, even if that response would be ârevert to using the bundled versionâ
<LocutusOfBorg> set status to new?
<mitya57> good idea, thanks for setting
<lubot> <tsimonq2> @mitya57, Unsatisfiable deps it seems... Dunno, only qtbase is in the PPA atm, I'll play with it :)
#ubuntu-qt 2018-02-03
<lubot> <acheronuk> @tsimonq2 was this acted on? https://bugs.launchpad.net/ubuntu/+bug/1727617
<ubottu> Launchpad bug 1727617 in Ubuntu "[needs-packaging] libqt5datavisualization5" [Undecided,Confirmed]
<lubot> <tsimonq2> @acheronuk, not yet, assigned to myself
<lubot> <acheronuk> Kool. was just poking at some stuff on KCI, and reminded me that Kstars devs had asked for it
#ubuntu-qt 2020-01-27
<lubot> <RikMills> https://www.qt.io/blog/qt-5.14.1-released
<lubot> <mitya57> \o/
<lubot> <mitya57> As said earlier, I don't have time to look at it, but that may change in a few days.
<lubot> <RikMills> Yeah, just put that there for info. Especially (as pointed out) no release email yet
<lubot> <RikMills> As I say that, the email arrived!
<lubot> <RikMills> https://www.qt.io/blog/qt-offering-changes-2020
<lubot> <mitya57> Oh! But there is one thing I don't understand:
<lubot> <mitya57> > This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. â¦ But there will be no minor release after 5.15. The next series will be 6.0.
<lubot> <mitya57> If they drop support for 5.15 immediately after 6.0 is released, that will be sad. Maybe the new policy will apply only for later 6.x LTS releases?
<lubot> <RikMills> I guess they want to kill off 5 ASAP for people who are not prepared to pay.
<lubot> <mitya57> So the announcement needs removal of âminorâ word. â¦ There is a related discussion on the ML, which I will follow.
<lubot> <RikMills> I can see the logic. It is just a bit cynical
<lubot> <mitya57> Yeah, I see that logic too. Nothing critical for us â we can always cherry-pick important fixes manually. And I guess someone will create a fork of 5.15 branch on GitHub when it gets closed.
<lubot> <RikMills> Urgh. mailing list archives are so hard to follow!
<lubot> <RikMills> @mitya57 [Yeah, I see that logic too. Nothing critical for us â we can always cherry-pick â¦], It will also make our current stays with LTS or go with newer, a less big choice
<lubot> <mitya57> Right
<fvogt> Yeah, the commericial-only LTS change needs some clarification. If it happens for 5.15 already, I'd propose that KDE forks it once Qt 6 is out
<lubot> <JBBgameich> KDE has already set up mirrors, I don't know whether they will be kept as mirrors or repositories with commit access after Qt 6 is released though.
<valorie> There is ongoing discussion between the Qt Company and the KDE Free Qt Foundation about this ^^^
<valorie> and that's all I can say
<valorie> discussion/negotiation
#ubuntu-qt 2020-01-28
<lubot> <X> https://tsdgeos.blogspot.com/2020/01/the-qt-company-is-stopping-qt-lts.html
<lubot> * mitya57 agrees with tsdgeos
<lubot> <RikMills> Fwd from marcinsagol: @bhushanshah https://www.qt.io/blog/qt-5.14.1-released
<lubot> <RikMills> Fwd from bhushanshah: yes, and I am also reading reports of terrible memory corruption
<lubot> <RikMills> Fwd from bhushanshah: so I am holding onto that for bit
<lubot> <RikMills> ^^ from Neon chat
<lubot> <mitya57> Ack
<lisandro> fvogt_vps, valorie : thanks for the data
<lisandro> I'll take a look at tsdgeos' blog
<lisandro> Yes, exactly that
#ubuntu-qt 2020-01-30
<lisandro> Just for the record: there are two new CVEs for Qt. I'll try to tackle them in Debian tomorrow, so hopefully mitya57 or any of you can get the changes soon
