#ubuntu-qt 2018-07-01
<lubot> <tsimonq2> @mitya57 Could you please do the new upstream release of pyqt5?
<lubot> <mitya57> @tsimonq2, If you mean 5.11.1 then no, it is broken.
<lubot> https://www.riverbankcomputing.com/pipermail/pyqt/2018-June/040459.html
<lubot> <tsimonq2> @mitya57, Ah, thanks.
#ubuntu-qt 2018-07-02
<lubot> <mitya57> There should be PyQt 5.11.2 today, I will amy08@example.org.
<lubot> <Lazy B> What about PySide2 and Shiboken?
<lubot> <mitya57> RaphaÃ«l Hertzog was going to take care of it in Debian #877871, but there has not been any update for a while.
<ubottu> Debian bug 877871 in wnpp "ITP: pyside2 -- Qt for Python" [Wishlist,Open] http://bugs.debian.org/877871
<lisandro> maybe we scared him?
<lisandro> I don't think he likes not using gbp
<mitya57> He can always maintain it in qt-kde-team/extras or in python-team/modules, we did not insist on our packaging scheme!
<lisandro> right
#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 2018-07-16
<lubot> <mitya57> @tsimonq2, Done. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3291/+sourcepub/9257332/+listing-archive-extra
<lubot> * acheronuk lays bets on how long arm64 will take
<lubot> <tsimonq2> @mitya57, Thank you!
#ubuntu-qt 2018-07-17
<lubot> <acheronuk> @tsimonq2 @mitya57 It built!  ð
<lubot> <tsimonq2> YAY!
<lubot> <tsimonq2> Can we ship it? ð
<lubot> <acheronuk> @tsimonq2, fix the rest of the redeps :P
<lubot> <tsimonq2> On it
<lubot> <tsimonq2> #1 priority right now
<lubot> * acheronuk #1 priority is a cold ðº
<lubot> <mitya57> @acheronuk, Hooray
<lubot> <tsimonq2> It's in cosmic-proposed now
<valorie> I thought acheronuk was saying he has a cold
<valorie> but a cold ðº is better
<valorie> lol
#ubuntu-qt 2018-07-18
<lubot> <tsimonq2> https://launchpad.net/ubuntu/+source/qtpim-opensource-src/5.0~git20140515~29475884-0ubuntu24~8
<lubot> <tsimonq2> @mitya57 Doesn't seem like too bad of a test regression.
<lubot> <mitya57> I am travelling today. Will look later, maybe tomorrow.
<lubot> <tsimonq2> @mitya57 Any reason not to just ask for a removal?
<lubot> <tsimonq2> It hasn't had a release, it's Ubuntu-only, and has no rdeps
<lubot> <mitya57> It has reverse dependencies I think?
<lubot> <tsimonq2> Nope, I just checked :)
<lubot> <mitya57> Oh, then ask for removal definitely :)
<lubot> <tsimonq2> Doing :)
<lubot> <tsimonq2> .
<lubot> https://bugs.launchpad.net/ubuntu/+source/qtpim-opensource-src/+bug/1782326
<ubottu> Launchpad bug 1782326 in qtpim-opensource-src (Ubuntu) "Please remove qtpim from Ubuntu" [Undecided,New]
<lubot> <acheronuk> working with simon to fix issues for 5.11 rdeps etc
<lubot> <tsimonq2> Right
<lubot> <tsimonq2> We're making good headway I think
<lubot> <tsimonq2> Let's continue coordination in here instead of via PM
<lubot> <tsimonq2> https://launchpad.net/ubuntu/+source/akonadi/4:17.12.3-0ubuntu5 seems to be fixed
<lubot> <acheronuk> @tsimonq2, Yep. That is what I was thinking
<lubot> <tsimonq2> Looking at u1db-qt now
<lubot> <acheronuk> depends qtdeclarative5-qtquick2-plugin, which in 5.9.5 is a transitional package, and which seems dropped in 5.11
<lubot> <tsimonq2> Right
<lubot> <tsimonq2> In other news, the Qt transition in Debian is halted in waiting for the ffmpeg transition
<lubot> <tsimonq2> Which means that qtwebengine will be FTBFS yet again when it's no-change rebuilt
<lubot> <acheronuk> always something!
<lubot> <acheronuk> notest update output:
<lubot> easy: 214+0: a-41:a-39:a-39:i-39:p-28:s-28
<lubot>     * amd64: akonadi-backend-sqlite, gammaray, gammaray-dev, gammaray-plugin-bluetooth, gammaray-plugin-kjobtracker, gammaray-plugin-positioning, gammaray-plugin-quickinspector, gammaray-plugin-waylandinspector, gchempaint, gcrystal, gcu-bin, gcu-plugin, kalzium, kamoso, kde-full, kde-spectacle, kde-standard, kdeedu, kdegraphics, kdevelop, libgcu0v5, libkf5purpose-bin, libkf5purpose-dev, libqt5webview5, libqt5webview5-dev, libu1db-qt5-3, libu1db-qt5-dev,
<lubot> libu1db-qt5-doc, libu1db-qt5-examples, okular, plasma-kdevelop, plasma-widgets-addons, qml-module-gsettings1.0, qml-module-org-kde-purpose, qml-module-qtwebview, qml-module-ubuntu-onlineaccounts, qtcreator, qtdeclarative5-accounts-plugin, qtdeclarative5-u1db1.0, qtwebview5-examples
<lubot> <acheronuk> not too big a list
<lubot> <tsimonq2> $ reverse-depends qtdeclarative5-qtquick2-plugin
<lubot> Reverse-Depends
<lubot> ===============
<lubot> * libu1db-qt5-3
<lubot> * qml-module-ubuntu-onlineaccounts
<lubot> * qtdeclarative5-u1db1.0
<lubot> * twinkle
<lubot> <tsimonq2> twinkle oddly has it as an alternative dependency; it's non-blocking but I'll file a bug anyway
<lubot> <tsimonq2> All others are fixed
<lubot> <acheronuk> :)
<lubot> <acheronuk> breaking  qml-module-ubuntu-onlineaccounts breaks purpose, and that breaks kdevelop and some other things. so fixing qml-module-ubuntu-onlineaccounts should know the list down a lot
<lubot> <tsimonq2> https://launchpad.net/ubuntu/+source/accounts-qml-module/0.6+17.04.20170405-0ubuntu2
<lubot> <tsimonq2> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904029
<ubottu> Debian bug 904029 in twinkle "twinkle: Please remove alternative dependency on qtdeclarative5-qtquick2-plugin" [Normal,Open]
<lubot> * acheronuk test builds Plasma 5.13 against  Qt 5.11 :)
<lubot> <tsimonq2> Kool :)
<lubot> <JBBgameich> There's also a new upstream release available for accounts-qml-module FYI
<lubot> <tsimonq2> We should really really get that in Debian if it isn't there already.
<lubot> <JBBgameich> No it isn't. I maintain the package for debian in an inofficial repository since it's a dependency of the Plasma Mobile settings app.
<lubot> <tsimonq2> OK
<lubot> <JBBgameich> But of course it would be much better to upstream it into debian. I just have never done that yet.
<lubot> <tsimonq2> @JBBgameich, I can do that.
<lubot> <JBBgameich> ð
<lubot> <JBBgameich> Just in case it's helpful, this is the packaging I currently use: https://gitlab.com/debian-pm/accounts-qml-module
<lubot> <tsimonq2> Thanks
<lubot> <tsimonq2> @JBBgameich You might be interested in becoming a Debian Maintainer and comaintaining :)
<lubot> <JBBgameich> Why not :)
<lubot> <tsimonq2> You just need to hunt down^M^Mfind a Debian Developer or two in real life and sign their GPG key
<lubot> <ilyaishere> ð
<lubot> <acheronuk> https://build.opensuse.org/package/view_file/multimedia:libs/vlc/vlc-qt-5.11.patch
<lubot> <acheronuk> I guess the last debian uploader will likely add such though
<lubot> <acheronuk> oh. 5.11 is in experimental? maybe they won't then
#ubuntu-qt 2018-07-19
<lubot> <acheronuk> webengine i386 "int64_t has weird alignment"
<lubot> <acheronuk> so maybe? https://build.opensuse.org/package/view_file/openSUSE:Factory/libqt5-qtwebengine/chromium-+1-905-866-7687-gcc8-alignof.patch?expand=1
<bshah> re: hunting down^W^W finding a debian developers, it can be fixed at Akademy I think ;0
<tsimonq2> If only I had a way to get there.......
<tsimonq2> ENOMONEY
<bshah> @JBBgameich btw, https://community.kde.org/Akademy/2018/GPGKeys would recommend this :)
<tsimonq2> Unless you know someone who would happily pay the $2000 for me to be there... :P
<tsimonq2> Actually, more like $2200 if I want to avoid United Airlines (which I absolutely do)
<tsimonq2> I do plan on saving up though. If I end up footing my own bill, probably 2020...
<lubot> <acheronuk> @https://launchpad.net/ubuntu/+source/u1db-qt/0.1.5+15.10.20150826.1-0ubuntu3/+build/15143538
<lubot> <acheronuk> @tsimonq2 ^^
<lubot> <acheronuk> https://launchpad.net/ubuntu/+source/u1db-qt/0.1.5+15.10.20150826.1-0ubuntu3/+build/15143538
<lubot> <tsimonq2> hmmm
<lubot> <acheronuk> @tsimonq2 https://launchpad.net/ubuntu/+source/ubuntu-ui-toolkit
<lubot> <acheronuk> not existsed since xenial
<lubot> <tsimonq2> Not *built* since Xenial :P
<lubot> <tsimonq2> @acheronuk, Pinged an AA
<lubot> <acheronuk> whatever.not going to get its depwait satisfied in an hurry
<lubot> <acheronuk> @tsimonq2, ð
<lubot> <tsimonq2> @acheronuk bug 1782569, sil2100 has it
<ubottu> bug 1782569 in u1db-qt (Ubuntu) "Please remove u1db-qt from Ubuntu" [Undecided,In progress] https://launchpad.net/bugs/1782569
<lubot> <tsimonq2> ð´
<lubot> <tsimonq2> (I should have EOD'd 7 hours ago...)
<lubot> <acheronuk> ok. thanks
<lubot> <tsimonq2> np
#ubuntu-qt 2018-07-26
<lubot5> <ilyaishere> Hello! When I build Qt5Core from Testing for i386, I get this `file` info:
<lubot5> ```libQt5Core.so.5.10.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=..., for GNU/Linux 3.17.0, stripped```
<lubot5> <ilyaishere> (Photo, 1183x688) https://i.imgur.com/I9tTGVE.jpg Compare to other libraries
<lubot5> <ilyaishere> I have an older kernel, so the linker does not use this library, and all the Qt software fails
<lubot5> <ilyaishere> This didn't happen before, any change that could trigger this?
<lubot5> <mitya57> @ilyaishere, See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895718
<ubottu> Debian bug 895718 in libqt5core5a "libqt5core5a: Requires Linux kernel 3.17.0 or newer" [Normal,Open]
<lubot5> <mitya57> The previous LTS release has kernel 4.4 (without HWE updates) and I think this is the minimum kernel version we should support in Cosmic.
<lubot5> <ilyaishere> So, upstream Qt now limits to 3.17...
<lubot5> <ilyaishere> That's sad, it cuts a huge percentage of phones
<bshah> o_O
<lubot5> <mitya57> @ilyaishere, Unless you build it without getentropy support.
<lubot5> <ilyaishere> > We can build Qt without the âgetentropyâ feature and that would lower the
<lubot5> > required kernel version to 3.16:
<lubot5> > https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/minimum-linux_p.h#n64
<lubot5> <ilyaishere> I seem to have missed a number of version bumps
<lubot5> <ilyaishere> 2 month ago I had no issues using 3.10
<lubot5> <ilyaishere> I guess, some "renameat" config also has to be disabled...
<lubot5> <ilyaishere> If I disable those two, will it break applications?
<lubot5> * ilyaishere searches for a Halium device with kernel >= 3.17
<lubot5> <JBBgameich> My device has kernel 3.18, but it's an armhf device.
<lubot5> <ilyaishere> You're on the edge ;)
<lubot5> <ilyaishere> They actually disabled it on Android: http://code.qt.io/cgit/qt/qtbase.git/commit/src/corelib/io/qfilesystemengine_unix.cpp?id=8eb3944dac81b8c51d7bac7784204d457551b50c
<lubot5> <ilyaishere> Can't yet find the fallback they use
<lubot5> <ilyaishere> It looks like they redefine libc functions; if they can't do so, libc functions are used instead
<lubot5> <ilyaishere> I think we'll have to fork the packaging for Halium
<lubot5> <ilyaishere> But it seems like they enable it anyway if host kernel supports it: http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfilesystemengine_unix.cpp#n109
<bshah> Probably question(s) for #qt
<lubot5> <ilyaishere> (so also a patch)
<lubot5> <ilyaishere> Yeah...
<bshah> also it seems, only Debian is affected? I didn't hit this with 3.10 kernel and Ubuntu + arm?
<bshah> [I didn't read bug report fully]
<lubot5> <ilyaishere> Well, Ubuntu should be affected as well as long as they haven
<lubot5> <ilyaishere> 't disabled these syscalls
<lubot5> <ilyaishere> Arch is affected FWIW
<lubot5> <JBBgameich> @bshah, It doesn't seem to be disabled in the KDE Neon packaging as far as I can see.
<lubot5> <ilyaishere> bshah: is build machine kernel newer than 3.16?
<lubot5> <JBBgameich> Also, does docker maybe prevent detecting the kernel features? (in case the neon ci uses docker)
<bshah> @ilyaishere: to answer your question, that machine would be using 4.4 or 4.8(?) kernel depending on which slave it uses
<lubot5> <ilyaishere> Ok. To clarify, the idea right now is that neon rootfs works because the kernel renameat feture is not detected: http://code.qt.io/cgit/qt/qtbase.git/commit/src/corelib/io/qfilesystemengine_unix.cpp?id=6eef81ee1c82f934e14d47047d8b6103b8755321
* tsimonq2 changed the topic of #ubuntu-qt to: Ubuntu Qt Discussion Channel | https://is.gd/GIZG9E | 5.11.1 in cosmic-proposed | Help remove Qt 4! https://is.gd/QXLEFW | 5.9.5 in Bionic, 5.5.1 in Xenial, 5.2.1 in Trusty | This channel is bridged to Telegram, ask us to be added | This channel is amy08@example.org; use implies acceptance of Ubuntu IRC channel terms.
* tsimonq2 changed the topic of #ubuntu-qt to: Ubuntu Qt Discussion Channel | https://is.gd/GIZG9E | Prepping 5.9.6 for Bionic: https://bileto.ubuntu.com/#/ticket/3329 | 5.11.1 in cosmic-proposed | Help remove Qt 4! https://is.gd/QXLEFW | 5.9.5 in Bionic, 5.5.1 in Xenial, 5.2.1 in Trusty | This channel is bridged to Telegram, ask us to be added | This channel is amy08@example.org; use implies acceptance of Ubuntu IRC chann
* tsimonq2 changed the topic of #ubuntu-qt to: Ubuntu Qt Discussion Channel | https://is.gd/GIZG9E | 5.9.6 for Bionic: https://bileto.ubuntu.com/#/ticket/3329 | 5.11.1 in cosmic-proposed | Help remove Qt 4! https://is.gd/QXLEFW | 5.9.5 in Bionic, 5.5.1 in Xenial | This channel is bridged to Telegram, ask us to be added | This channel is amy08@example.org; use implies acceptance of Ubuntu IRC channel terms.
<tsimonq2> So, with 5.11.1 being in cosmic-proposed, I'm going to hunt it down a little bit more.
<tsimonq2> Otherwise I'm starting the preparation of 5.9.6 for Bionic: https://bileto.ubuntu.com/#/ticket/3329
<tsimonq2> I plan on doing everything but qtwebengine in that PPA, and once all the packages are updated and we're ready, I'll manually upload to the queue to make it easier to review.
<tsimonq2> As I discussed with @mitya57, I'm going to revert the commit changing the internal version to 5.9.6, so we don't have to no-change rebuild rdeps of the private headers.
#ubuntu-qt 2018-07-30
<lubot5> <acheronuk> ovito in -release failing tests against qtbase 5.11
<lubot5> <acheronuk> ovito in -proposed FTBFS
<lubot5> <acheronuk> FTBFS looks similar to: https://gitlab.com/stuko/ovito/issues/40
<lubot5> <acheronuk> the one in -proposed was a no change rebuild, so the FTBFS is a regression with gcc like that one possibly
<lubot5> <acheronuk> whereas kxstitch has an obvious fix build with 5.11 patch :) https://cgit.kde.org/kxstitch.git/log/?h=release-2.1.0
<lubot5> <tsimonq2> @acheronuk, kxstitch is already fixed
<lubot5> <acheronuk> @tsimonq2, if so, it's tests need a prod
<lubot5> <tsimonq2> .
<lubot5> <acheronuk> @tsimonq2, I assumed since the tests hadn't been passed, no fix had been uploaded. sorry
<lubot5> <acheronuk> anyway. ovito is going to be the fun one :P
<lubot5> <tsimonq2> Bah.
<lubot5> <acheronuk> FWIW, I fixed the worst of what I have permissions for today. so tag, you're it..
<lubot5> <tsimonq2> OK
<lubot5> <tsimonq2> Qool.
<lubot5> <acheronuk> demote to -proposed
<lubot5> * acheronuk nods
<lubot5> <acheronuk> needs a new upstream release if it has a hope of fixing, so was thinking of much the same
<lubot5> <acheronuk> looks like I can poke kxstitch retries. forgot qtbase itself would give me the right. so done
<lubot5> <tsimonq2> Kool.
<lubot5> <acheronuk> maybe most of Qt can at least be a candidate tonight!
<lubot5> <tsimonq2> Maaaaaaybe.
<lubot5> <acheronuk> @tsimonq2, well, not webengine :/
<lubot5> <tsimonq2> Oh?
<lubot5> <acheronuk> ffmpeg
<lubot5> <tsimonq2> ahh
<lubot5> <acheronuk> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ffmpeg
<lubot5> <acheronuk> hmmm
<lubot5> <acheronuk> valid canditates for much of it :)
<lubot5> <tsimonq2> Ooh.
#ubuntu-qt 2018-07-31
<lubot5> <acheronuk> for some reason the transition wants to remove all KDE4
<lubot5> <acheronuk> i.e. would break all kde4 if migrated
<lubot5> <acheronuk> @tsimonq2 would probably cheer :P but in practical terms for this, not good
<lubot5> <acheronuk> looks likely to be because strigi FTBFS against ffmpeg4
<lubot5> <acheronuk> strigi is removed in debian, so if I stop kde4libs building against it (hence a dep) then it should become removable from Ubuntu ð¤
<lubot5> <acheronuk> @tsimonq2 https://bugs.launchpad.net/ubuntu/+source/transcode/+bug/1784612
<ubottu> Launchpad bug 1784612 in transcode (Ubuntu) "FTBFS against ffmpeg 4" [Undecided,New]
<lubot5> <acheronuk> that will block ffmpeg, and hence Qt as well
<lisandro> tangled transitions are not fun
<acheronuk> lisandro: with Qt and KDE, there are rarely any other kind :P
<acheronuk> of the larger ones, anyway
<lisandro> :-)
<lubot5> * acheronuk wonders what happened to the idea of checking that rdeps build ok BEFORE you start a transition
<lubot5> <acheronuk> https://people.canonical.com/~ubuntu-archive/transitions/html/html/ffmpeg.html
<lubot5> * acheronuk wonders if webengine can be decoupled from ffmpeg in the short term
<lubot5> <acheronuk> too many other things also build with it :(
<lubot5> <tsimonq2> @acheronuk kmail apparently needs a fix for Qt 5.11.1
<lubot5> <tsimonq2> See amy08@example.org but lisandro has a patch, apparently :)
<lubot5> <acheronuk> with all the patching already, I would be amazed if PIM works at all!
<lubot5> <tsimonq2> heh
<lubot5> <acheronuk> I'll have a look where we are. with Qt firmly wedged in proposed, doubt this will affect many people. + I wonder if fixed in 18.04 apps, which if so, might be done anyway before Qt migrates, or immediately after
<lubot5> <acheronuk> @tsimonq2 so this? https://cgit.kde.org/messagelib.git/commit/?h=Applications/18.04&id=38d8323062731ae0cf8a037451b5b55d41f0e3f6
<lubot5> <acheronuk> that is in 18.04 it seems
<lubot5> <tsimonq2> I think so
<lubot5> <tsimonq2> I don't use kmail :P
<lubot5> <acheronuk> So I'll ponder whether to do that earlier now, or patch
<lubot5> <tsimonq2> Up to you.
<lubot5> <acheronuk> @tsimonq2, seems multiple fixes https://cgit.kde.org/messagelib.git/log/?h=Applications%2F18.04&qt=grep&q=5.11
<lubot5> <tsimonq2> Ah.
<lubot5> <acheronuk> @tsimonq2 kde4libs is migrating. strigi in release and FTBFS in proposed against ffmpeg should be removable when done
<lubot5> <tsimonq2> ack
<lubot5> <acheronuk> ð´ð¤
<lisandro> @acheronuk working on it
<lisandro> I'm also adding a patch for missing headers
<lisandro> ideally we would need heffee around :-/
#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 amy08@example.org; 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!
#ubuntu-qt 2019-07-16
<lubot> <RikMills> @mitya57 qca2 from ubnstable fails its build time tests with GCC 9. do you think there would any problem forcing GCC 8 for time being?
<lubot> <mitya57> @RikMills [@mitya57 qca2 from unstable fails its build time tests with GCC 9. do you think â¦], https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925809#12
<ubottu> Debian bug 925809 in src:qca2 "qca2: ftbfs with GCC-9" [Important,Open]
<lubot> <mitya57> Maybe you can merge qt4-x11 instead (or cherry-pick the fix)?
<lubot> <RikMills> Ah. I missed that
<lubot> <RikMills> @mitya57 [Maybe you can merge qt4-x11 instead (or cherry-pick the fix)?], Sure
<lubot> <mitya57> Or disable Qt 4 support, there is time to do that anyway
<lubot> <RikMills> I did think of only running the qt5 set of tests
<lubot> <mitya57> Actually maybe Qt 4 can just be synced. There is a lot of delta but I am not sure it's needed now that most of KDE is moved to Qt 5.
<lubot> <RikMills> @mitya57 [Actually maybe Qt 4 can just be synced. There is a lot of delta but I am not sur â¦], Might be worth a try. Can always add delta back. At the moment, I am having to cherry-pick quite a lot to get close to making it build!
<lubot> <x_sun> Any volunterrs to package https://github.com/Samsung/rlottie ?
<lubot> <x_sun> There's no stable version, so should be a snapshot I guess
#ubuntu-qt 2019-07-18
<lubot> <RikMills> @mitya57 https://mail.kde.org/pipermail/kde-distro-packagers/2019-July/000379.html
<lubot> <mitya57> Ok, will do
<lubot> <RikMills> @mitya57 [Ok, will do], Thanks :)
#ubuntu-qt 2019-07-19
-queuebot:#ubuntu-qt- New binary: qtstyleplugins-src [s390x] (eoan-proposed/universe) [5.0.0+git23.g335dbec-3ubuntu1] (kubuntu, qt5)
-queuebot:#ubuntu-qt- New binary: qtstyleplugins-src [arm64] (eoan-proposed/universe) [5.0.0+git23.g335dbec-3ubuntu1] (kubuntu, qt5)
-queuebot:#ubuntu-qt- New binary: qtstyleplugins-src [armhf] (eoan-proposed/universe) [5.0.0+git23.g335dbec-3ubuntu1] (kubuntu, qt5)
-queuebot:#ubuntu-qt- New binary: qtstyleplugins-src [amd64] (eoan-proposed/universe) [5.0.0+git23.g335dbec-3ubuntu1] (kubuntu, qt5)
-queuebot:#ubuntu-qt- New binary: qtstyleplugins-src [i386] (eoan-proposed/universe) [5.0.0+git23.g335dbec-3ubuntu1] (kubuntu, qt5)
-queuebot:#ubuntu-qt- New binary: qtstyleplugins-src [ppc64el] (eoan-proposed/universe) [5.0.0+git23.g335dbec-3ubuntu1] (kubuntu, qt5)
<lubot> <mitya57> @RikMills [@mitya57 https://mail.kde.org/pipermail/kde-distro-packagers/2019-July/000379.ht â¦], Hmm, of three merge proposals one merged, one is work in progress and one has merge conflict. Maybe I will wait a bit.
<lubot> <RikMills> Ok. They are wayland fixes. Which is just trying to make a broken thing slightly less broken. ð
<lubot> <mitya57> We have quite a lot of time before release, I hope David will finalize these fixes and then I will cherry-pick them. (Or maybe we will get them through 5.12.5 release)
<lubot> <JBBgameich> Probably a question you hear quite often: Is there an estimated date when Qt 5.12.4 will leave debian experimental? â¦ (Qt 5.12 is required to get Plasma Mobile running properly on the Librem5)
<lubot> <mitya57> I am afraid not soon. I am going for vacation in a week and will be able to do it only when I return, unless someone else volunteers to handle it. Maybe it will be 5.12.5 directly (expected in end of August).
<valorie> meanwhile tsimonq2 is probably melting
#ubuntu-qt 2019-07-20
-queuebot:#ubuntu-qt- New binary: qtstyleplugins-src [amd64] (eoan-proposed/universe) [5.0.0+git23.g335dbec-3ubuntu1] (kubuntu, qt5)
-queuebot:#ubuntu-qt- New binary: qtstyleplugins-src [arm64] (eoan-proposed/universe) [5.0.0+git23.g335dbec-3ubuntu1] (kubuntu, qt5)
#ubuntu-qt 2019-07-21
<lubot> <mitya57> Are there any users of quiterss or qbittorrent here? I need someone to verify the fix in bug 1833536. If you just use these apps on Bionic or Disco, and they do not crash, please add a comment on that bug.
<ubottu> bug 1833536 in qtbase-opensource-src (Ubuntu Disco) "QuiteRSS crashes intermittently" [Undecided,Fix committed] https://launchpad.net/bugs/1833536
#ubuntu-qt 2019-07-22
<pandaR> hello. could i ask help with a bug?
<lubot> <bhushanshah> @mitya57 [I am afraid not soon. I am going for vacation in a week and will be able to do i â¦], Question: are there any plan to have qt 5.12.x in buster? Or it will be specific to bullseye only?
<lubot> <mitya57> It can be available in backports but only if someone volunteers (not me).
<lubot> <bhushanshah> Okay.
<lubot> <mitya57> Though thinking more about it, Plasma won't work with it as it is compiled against 5.11 private ABI.
#ubuntu-qt 2020-07-13
<lubot> <RikMills> @mitya57 will we be still be able to have 5.15 for groovy?
<lubot> <mitya57> @RikMills [@mitya57 will we be still be able to have 5.15 for groovy?], https://wiki.qt.io/Qt_5.15_Release says that 5.15.1 will be released in August 2019, and feature freeze is on August 27th.
<lubot> <mitya57> So I think yes. My time is very limited as usual so I can't afford time to make two transitions (first .0 then .1), but .1 looks possible.
<lubot> <RikMills> On debian IRC you said in 4 months for landing in debian, so I was not sure if that meant you were somehow too busy with work before then
<lubot> <RikMills> @mitya57 [So I think yes. My time is very limited as usual so I can't afford time to make â¦], ok :)
<lubot> <mitya57> â4 monthsâ was a quote from https://mail.kde.org/pipermail/kde-distro-packagers/2020-June/000421.html.
<lubot> <mitya57> By that time even Debian should have 5.15.1 (it will be slower than in Ubuntu).
<lubot> <RikMills> @mitya57 [â4 monthsâ was a quote from https://mail.kde.org/pipermail/kde-distro-packagers/ â¦], Ah, right. That would be the plasma release date then, and that email is 1 month old.
<lubot> <RikMills> with that context, I am clear now on what is likely. thanks
<lubot> <mitya57> 3 months should be enough too. Also Debian's Plasma maintainers are even slower than me :)
<lubot> <RikMills> @mitya57 [3 months should be enough too. Also Debian's Plasma maintainers are even slower â¦], Yeah, I have been watching the emails about Plasma in debian. ð
#ubuntu-qt 2020-07-31
<lubot> ilyaishere was removed by: ilyaishere

{'channel': 'ubuntu-qt', 'month': 7}