#ubuntu-qt 2018-05-03
-queuebot:#ubuntu-qt- Unapproved: qtcreator (cosmic-proposed/universe) [4.5.2-3ubuntu2 => 4.6.0-3] (qt5) (sync)
#ubuntu-qt 2018-05-04
<lubot> <tsimonq2> @mitya57 Should we prepare the 5.10.1 transition for when the archive opens?
<lubot> <tsimonq2> Can't create Cosmic Bileto tickets yet, pinged on IRC.
<lubot> <mitya57> @tsimonq2, I don't see why we should hurryâ¦
<lubot> <tsimonq2> @mitya57, Is there any reason to delay? :)
<lubot> <mitya57> I don't know what other transitions are planned for archive opening. But it's very likely that we will entangle with something like perl and it will take weeks to migrate.
<lubot> <tsimonq2> We can wait to land it until it's done.
<lubot> <mitya57> Ok :)
-queuebot:#ubuntu-qt- New binary: fcitx-qt5 [s390x] (cosmic-proposed/universe) [1.2.2-2] (input-methods, kubuntu, ubuntu-qt-packages)
-queuebot:#ubuntu-qt- New binary: fcitx-qt5 [amd64] (cosmic-proposed/universe) [1.2.2-2] (input-methods, kubuntu, ubuntu-qt-packages)
-queuebot:#ubuntu-qt- New binary: fcitx-qt5 [i386] (cosmic-proposed/universe) [1.2.2-2] (input-methods, kubuntu, ubuntu-qt-packages)
-queuebot:#ubuntu-qt- New binary: fcitx-qt5 [ppc64el] (cosmic-proposed/universe) [1.2.2-2] (input-methods, kubuntu, ubuntu-qt-packages)
#ubuntu-qt 2018-05-05
-queuebot:#ubuntu-qt- New binary: fcitx-qt5 [arm64] (cosmic-proposed/universe) [1.2.2-2] (input-methods, kubuntu, ubuntu-qt-packages)
-queuebot:#ubuntu-qt- New binary: fcitx-qt5 [armhf] (cosmic-proposed/universe) [1.2.2-2] (input-methods, kubuntu, ubuntu-qt-packages)
-queuebot:#ubuntu-qt- New: accepted fcitx-qt5 [ppc64el] (cosmic-proposed) [1.2.2-2]
-queuebot:#ubuntu-qt- New: accepted fcitx-qt5 [i386] (cosmic-proposed) [1.2.2-2]
-queuebot:#ubuntu-qt- New: accepted fcitx-qt5 [s390x] (cosmic-proposed) [1.2.2-2]
-queuebot:#ubuntu-qt- New: accepted fcitx-qt5 [amd64] (cosmic-proposed) [1.2.2-2]
<lubot1> <acheronuk> Fwd from acheronuk: building against -proposed in cosmic for anything Qt is fucked for the time being
<lubot1> <acheronuk> Fwd from acheronuk: the sync of new wayland version before new mesa was merged, leaves qtbase5-dev uninstallable in -proposed
<lubot1> <acheronuk> FYI ^^^
<acheronuk> apologies there!
<lubot1> <acheronuk> building against -proposed in cosmic for anything Qt is 'broken' for the time being
<lubot1> <acheronuk> the sync of new wayland version before new mesa was merged, leaves qtbase5-dev uninstallable in -proposed
<lubot1> <tsimonq2> Eek!
<valorie> just a reminder that this chan is logged
<acheronuk> yep :P
#ubuntu-qt 2018-05-06
-queuebot:#ubuntu-qt- Unapproved: qtcreator (cosmic-proposed/universe) [4.6.0-3 => 4.6.0-3build1] (qt5)
<lubot> <tsimonq2> @valorie, Why's the reminder needed? :P
<lubot> <acheronuk> @tsimonq2, because some people are not careful when lazily forwarding telegram messages from elsewhere to the channel ð³
<lubot> <tsimonq2> @acheronuk, Oh
<valorie> lol
<lubot> <tsimonq2> Oh, didn't see the deleted message. :P
<lubot> <tsimonq2> I'll create the Bileto ticket in a few hours.
<valorie> tsimonq2: back from the Great Outdoors?
<valorie> lol
<lubot> <tsimonq2> @valorie, Ish.
 * valorie heads outside
#ubuntu-qt 2018-05-07
<lubot> <tsimonq2> https://bileto.ubuntu.com/#/ticket/3252
<lubot> <tsimonq2> Time to figure out how to do the topic. :P
* tsimonq2 changed the topic of #ubuntu-qt to: Ubuntu Qt Discussion Channel | https://is.gd/GIZG9E | Staging Qt 5.10 for Cosmic: https://bileto.ubuntu.com/#/ticket/3252 | 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 acolon@example.com. Use of this channel implies acceptance of Ubuntu IRC channel terms..
* tsimonq2 changed the topic of #ubuntu-qt to: Ubuntu Qt Discussion Channel | https://is.gd/GIZG9E | Staging Qt 5.10 for Cosmic: https://bileto.ubuntu.com/#/ticket/3252 | 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 acolon@example.com. Use of this channel implies acceptance of Ubuntu IRC channel terms.
<mamarley> tsimonq2: In your packaging of Qt 5.10, have you switched it over to using OpenSSL 1.1?
<lubot> <tsimonq2> @mamarley, We switched last cycle.
<mamarley> Awesome, thanks!
#ubuntu-qt 2018-05-08
<lubot> <tsimonq2> @mitya57 Hm, wanna just skip to 5.11?
<lubot> <tsimonq2> Perhaps we can get it in experimental and then Ubuntu
<lubot> <tsimonq2> Once it lands in Sid (5.11.1) it'll be properly "in sync"
<lubot> <tsimonq2> How does that sound?
<lubot> <mitya57> I think @acheronuk wanted to have 5.10 before 5.11.
<lubot> <mitya57> Fwd from acheronuk: I ask as plasma 5.13 out 12th June needs 5.10 or greater
<lubot> <tsimonq2> @acheronuk Thoughts?
<lubot> <tsimonq2> I'm fine with whatever, but that just seems to make sense. :)
<lubot> <mitya57> Ok then I am fine too :)
<mamarley> Is qtbase5-dev back to being installable in cosmic-proposed yet?
<lubot> <tsimonq2> Good question.
<lubot> <acheronuk> @mamarley, yes
<mamarley> Awesome, thanks!
<lubot> <acheronuk> @tsimonq2, which makes sense?
<lubot> <acheronuk> 5.13 beta is out in 9 days time. I could builf that with the 5.10.1 I have in the Kubuntu CI repos if realy need be
<lubot> <tsimonq2> @acheronuk, Let's do 5.11 then?
<lubot> <tsimonq2> So we can get the .0 in the archive in time for Plasma.
<lubot> <acheronuk> ok. whichever makes best sense for Qt. If I need it sooner I can always to another test build for just amd64. That so far has been pretty trouble free to throw in a ppa somewhere
<lubot> <mitya57> @tsimonq2, Sounds fine to me. According to the latest news it may be released on May 22nd.
<lisandro> 5.11.0?
<lisandro> interesting
<mamarley> Yeah, what's up with that, Qt releases are supposed to be late!
<mitya57> lisandro: Yes, see http://lists.qt-project.org/pipermail/releasing/2018-May/004643.html
<lisandro> choose between late or buggy! ;-)
<mamarley> Why not both? ;)
<lisandro> ah, missed the second paragraph it seems
<lubot> <acheronuk> @mamarley, Original plan 31.5.2018
<lubot> Updated plan 22.5.2018
<lubot> ð®
<lubot> <acheronuk> amazing!
<lubot> <tsimonq2> I'll be a DM on the next keyring update, so if lisandro or mitya57 wants to give me access, I can Just Do the 5.11 transition in Experimental.
<lubot> <tsimonq2> Ofc we can collaborate, but I want to get used to uploading to Debian. ;)
<lisandro> experimental has no transitions ;-)
<lisandro> but yes, I'll give you access. I might review stuff before you upload, but just that
<mitya57> I will maybe want to review qtbase too, everything else should be simpler.
<lisandro> indeed
<lisandro> qtdeclaratve also needs reviewing
<lisandro> because of private symbols
 * mitya57 agrees
<lubot> <tsimonq2> No problem.
<lubot> <tsimonq2> I'll be happy to get reviews before uploading. :)
#ubuntu-qt 2018-05-10
<jpleau> Hi. I would like to keep qtcreator up to date on my 18.04 install. I've started backporting some of the deps (mainly qbs so far), but I'm wondering if there are things that could eventually break? Am I better off using upstream's binary installer to have the latest qtcreator at all times?
<valorie> jpleau: please file a "please package" bug on QtCreator
<valorie> since it isn't KDE software, the kubuntu team doesn't take care of it particular
<valorie> but I'm sure one of use can get it upgraded and into the archive -- esp. if Debian has done so
<valorie> `ubuntu-bug qtcreator`
<valorie> is the easy way
<jpleau> I'm guessing this is similar to reportbug on debian? :)
<jpleau> I wasn't sure if new versions including new features would have a chance of getting updates in an ubuntu release.. specially an LTS
<valorie> be sure to link to docs about the newest release, and if it is in Debian yet
<valorie> I assume
<valorie> sort of depends on whether or not it has bugfixes or new stuff
<valorie> new stuff would only be in backports for the LTS
<valorie> and in Cosmic
<jpleau> I don't have a reason yet to request an upgrade, I asking more "generally" during the LTS cycle. iirc the clang code model gets a few fixes / new features every then and now
<valorie> like I said, bugfixes should always get in
<valorie> and backports for new features
<valorie> but Cosmic should have the newest if someone notices
<valorie> thus the BR
<valorie> the Kubuntu team owns kdevelop, but not QtCreator
<jpleau> valorie: thanks a lot for the answers, will keep an eye on new releases on my sid install (the debian devs working on qtcreator are usually fast with updates too)
<valorie> cool
<valorie> if it can be synced that makes everything faster
<valorie> jpleau: some of our ubuntu devels are debian devels as well
<valorie> so sometimes the packaging comes from "us"
<valorie> so that we can all have the new toys
<jpleau> valorie: sorry I didn't mean to exclude ubuntu-devs from my sentence, a lot of packages are worked on by devs of both distribution which is nice
<valorie> yup
<valorie> the more that happens, the better it is IMO
<jpleau> I'm myself a DM in debian, the one thing that I think is missing is launchpad/bugs.d.o not always in sync (ie: ubuntu users files bugs on a package I work on, on lauchpad, I may never hear of it). That's another (offtopic) story though :)
<valorie> yeah, linking bugs could be much better
<lubot> <tsimonq2> I'll look into a backport.
<lubot> <tsimonq2> Ya know, officially into bionic-backports. ;)
<lubot> <tsimonq2> Sometime within the next week,
<lisandro> valorie: in the specific case of qtcreator only tsimonq2 has done some work (IIRC). But of course, help is always appreciated.
<valorie> jpleau: ^^^
#ubuntu-qt 2018-05-15
<lubot2> <tsimonq2> From the Qt Release Team meeting today:
<lubot2> Qt 5.9.6 status:
<lubot2> - Branching ongoing, will be finalized 22nd May
<lubot2> - Blocker list here: https://bugreports.qt.io/issues/?filter=19339
<lubot2> * Only one item open in the list atm
<lubot2> - Target is still to get the release out at the beginning of June
<lubot2> <Lazy B> @tsimonq2, Qool, is changelog already available?
<lubot2> <tsimonq2> @Lazy B, I don't think so.
#ubuntu-qt 2018-05-16
<lisandro> https://blog.qt.io/blog/2018/05/16/code-contributions-via-bug-reports-forum-posts/
<lisandro> Very good news for everyone
<valorie> indeed
<valorie> I wasn't aware that they were ignoring patches, but it makes some of the complaints I've heard make sense
<lisandro> and actually thiago is going to keep ignoring them
<lisandro> and I think his reasoning is right
<lubot2> <mitya57> I would call this âhe does not get the legal right to apply these patchesâ. The same applies to us too.
<lubot2> For reference: http://lists.qt-project.org/pipermail/development/2018-May/032715.html
<valorie> imo I would trust Thiago with almost anything code-related
 * lisandro too
<lisandro> so, all in all, we should try to avoid people sending patches to bugs
<lisandro> even if it's still a pain
#ubuntu-qt 2018-05-17
<lubot2> <tsimonq2> https://tracker.debian.org/news/958045/accepted-qtbase-opensource-src-5110rc1dfsg-1-source-amd64-into-experimental-experimental/
<mamarley> tsimonq2: Is there somewhere I can download that +dfsg tarball?
<lubot2> <mitya57> @mamarley, http://incoming.debian.org/debian-buildd/pool/main/q/qtbase-opensource-src/qtbase-opensource-src_5.11.0~rc1+dfsg.orig.tar.xz
<mamarley> mitya57: Awesome, thanks!
#ubuntu-qt 2018-05-18
<lubot2> <tsimonq2> http://lists.qt-project.org/pipermail/releasing/2018-May/004647.html
<acheronuk> [12:25] <fvogt> asturm: FYI, gcc 8 miscompiles qtscript: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822
<ubottu> gcc.gnu.org bug 85822 in tree-optimization "[8/9 Regression] Maybe wrong code in VRP since r249150" [Normal,Assigned]
<acheronuk> [12:57] <fvogt> asturm, arojas: I chose to just skip RC2 as it was broken as well. Apparently that was a good choice...
<acheronuk> plasma and OpenSuse devel ^^^
<mitya57> Interesting, thanks!
<acheronuk> [13:28] <fvogt> The main change of RC2 vs. RC1 was the static clang fix, which did not work
<acheronuk> [13:28] <fvogt> acheronuk: GCC8 is unrelated to Qt 5.11
<acheronuk> mitya57: I may have got context a bit wrong initially then :/
<mitya57> I know that qtscript is dead and not changed between 5.10 and 5.11, but still interesting to know that GCC 8 miscompiles it :)
<acheronuk> ok. more info is always better
<acheronuk> and apparently there have been tarball respins of RC2 for fixes, so beware and check if anyone has already fetched
<lubot2> <tsimonq2> @acheronuk, Not yet.
#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 2018-05-31
<valorie> wooooo: https://lists.debian.org/debian-devel-announce/2018/05/msg00006.html
<valorie> that's good news
<lubot> <tsimonq2> Yep. :D
<valorie> 'I accepted an invitation for Debian to join the KDE Advisory Board' - Chris Lamb
<lubot> * tsimonq2 asks someone who might know who at Canonical represents the company
<valorie> um
<valorie> I met him at Akademy, and he was in our kubuntu-devel chan for awhile, but..... name escapes me
<valorie> Irish guy
<valorie> really helpful
<lubot> <tsimonq2> Ah.
<valorie> Gerry Boland "greyback"
<lubot> <tsimonq2> OH. I've heard the name.
<lubot> <tsimonq2> He's also here. ;)
<valorie> hey Gerry!
#ubuntu-qt 2020-05-01
<lubot> <mitya57> I see qtmultimedia, thanks @tsimonq2!
#ubuntu-qt 2020-05-03
<lubot> <RikMills> Extension error: â¦ Could not import extension ecm (exception: No module named 'sphinxcontrib')
<lubot> <RikMills> @mitya57 any idea on that?
<lubot> <mitya57> Looks like Debian #955117
<ubottu> Debian bug 955117 in src:extra-cmake-modules "extra-cmake-modules: FTBFS with Sphinx 2.4: Could not import extension ecm (exception: No module named 'sphinxcontrib')" [Serious,Open] http://bugs.debian.org/955117
<lubot> <RikMills> thanks!
<lubot> <mitya57> I can't say how to fix it, though, no time to investigate.
<lubot> <RikMills> For now probably just not bother building the docs?
<lubot> <mitya57> Maybe
<lubot> <mitya57> If no other packages are using ecm extension
<lubot> <RikMills> wow @ the number of bugs sphinx 2.4 has caused! ð±
<lubot> <RikMills> Ok. might be simple after all https://salsa.debian.org/qt-kde-team/kde/extra-cmake-modules/-/commit/6d35288e839c0b5e7c87a6915bc1e012d86e3d71
<lubot> <RikMills> I did not find those packages when I searched earlier :/
<lubot> <RikMills> ah, new in proposed
<lubot> <mitya57> @RikMills [wow @ the number of bugs sphinx 2.4 has caused! ð±], Almost every new sphinx release causes this
<lubot> <mitya57> Now 3.0 is released, but I want to wait until this pile of bugs settles down :)
<lubot> <RikMills> @mitya57 [Almost every new sphinx release causes this], I must have been lucky so far then!
#ubuntu-qt 2020-05-07
<mitya57> Qt 5.14.2 status update: 22 packages updated in Debian experimental, 1 waiting in NEW queue, 12 remaining.
<mitya57> Right now there is some issue with satisfying build-dependencies on buildds, which prevents me from moving forward (see e.g. https://buildd.debian.org/status/package.php?p=qtserialport-opensource-src&suite=experimental).
<mitya57> Plasma 5.19 beta is in a week, we still have chances to meet that date (or almost meet it).
<lubot> <RikMills> thanks. would be nice. might have to do plasma in a PPA at 1st though, as it needs 2 new sources anyway :/
#ubuntu-qt 2020-05-09
<lubot> Zurd0s was added by: RikMills
<lubot> <RikMills> @mitya57 Zurdo has a question about Qt 5.14 :)
<lubot> <Zurd0s> so, I thought, hey, history, I'll try searching. Curse telegram search being unable to find partial words :)
<lubot> <Zurd0s> Hi all!
<lubot> <Zurd0s> I'm having difficulties both understanding and fixing issues with a change in Qt 5.14, namely "Qt is now relocatable"
<lubot> <Zurd0s> @Zurd0s [I'm having difficulties both understanding and fixing issues with a change in Qt â¦], It could still be a red herring, but it's the only relevant change in 5.14 I've seen that makes sense to be causing issues like quasselcore not finding lib/qt-qtversion/plugins/sqldrivers, for example
<lubot> <Zurd0s> @Zurd0s [It could still be a red herring, but it's the only relevant change in 5.14 I've â¦], (therefore not being able to start at all)
<lubot> <Zurd0s> what I'm able to grok of the change is that now, by default, a Qt app will find libQt5Core.so.5, and the rest of the Qt libraries will be looked for relative to libQt5Core.so.5.
<lubot> <Zurd0s> AFAICT, most of y'all packaging for a civilised, normal human being distro, shouldn't even notice this? Thing is, nutters like us on NixOS... well
<lubot> <Zurd0s> havoc, I tell you
<lubot> <Zurd0s> so, I'm lost at several steps
<lubot> <Zurd0s> I think I've disabled the relocation thing (`-no-feature-relocation`...?) but behavior doesn't seem to change. I'd love to know both if I'm disabling it right, or if I can "ask" the final libraries to tell me what features they've been built
#ubuntu-qt 2020-05-10
<lubot> <mitya57> Hi @Zurd0s! I haven't heard anything about this issue. I will suggest you to use strace to find which directories Qt searches for plugins in.
<lubot> <mitya57> @Zurd0s [I think I've disabled the relocation thing (-no-feature-relocation...?) but beha â¦], Features are listed in qconfig.h, if I remember correctly.
<lubot> <mitya57> Also maybe you will get more lack if you ask on #qt-labs.
<lubot> <Zurd0s> @mitya57 [Hi @Zurd0s! I haven't heard anything about this issue. I will suggest you to use â¦], I ended up doing so. Using quassel as an example, it was only looking in its own package for plugins (on NixOS packages don't share hierarchy: quassel has its own /lib, isolated from qt's. And, in fact, qt produces at least two different
<lubot> /lib directories, but that's another story...). However, I believe we managed to fix this by forward-porting a patch that we used in 5.12 (probably before too) that didn't apply on 5.14 (situation on which we defaulted to dropping the patch, of course). It appears most of the weirdness left on update is related to QML module paths now, but now we h
<lubot> ave a method :P
<lubot> <Zurd0s> @mitya57 [Features are listed in qconfig.h, if I remember correctly.], There's not a single qconfig.h on my system that has anything resembling "relocatable", so it's either not it, or I didn't disable it correctly. Still, thanks!
<lubot> <Zurd0s> @mitya57 [Also maybe you will get more luck if you ask on #qt-labs.], I'll try. Thank you!
#ubuntu-qt 2020-05-12
<lubot> <RikMills> @mitya57 how is 5.14 doing? Thanks for the work, and to others who are helping.
<lubot> <mitya57> I was offline for the weekend, uploaded 3 packages yesterday, 2 more are in progress. Patrick Franz was creating merge requests and helping me a lot. â¦ I will try to create a PPA today and start bootstrapping docs there.
<lubot> <RikMills> Thank you :)
<lubot> <mitya57> I think I will ask you to do the rebuilds once Qt is ready, if you don't mind. Then I will look at failing ones.
<lubot> <RikMills> I don't mind at all!
<lubot> <mitya57> @mitya57 [I was offline for the weekend, uploaded 3 packages yesterday, 2 more are in prog â¦], And it will be https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4057/+packages.
<mitya57> By the way, can someone please update IRC topic? Focal has 5.12.8, and Disco is dead so we can remove it.
* RikMills changed the topic of #ubuntu-qt to: Ubuntu Qt Discussion Channel | https://is.gd/GIZG9E | 5.12.8 in Focal, 5.12.4 in Eoan, 5.9.5 in Bionic, 5.5.1 in Xenial | This channel is bridged to Telegram, ask us to be added | This channel is acolon@example.com; use implies acceptance of the Ubuntu IRC channel terms.
<RikMills> mitya57: done
<mitya57> Thanks!
<lubot> <RikMills> @mitya57 Qtbase does not build on i386 now?
<lubot> <mitya57> Probably libmd4c-dev needs to be added to the whitelist.
<lubot> <RikMills> shall I ask?
<lubot> <mitya57> Yes, please :)
<lubot> <RikMills> done. hopefully can get that done later
<lubot> <mitya57> Thanks
<lubot> <RikMills> riscv64 OOM ftbfs?
<lubot> <mitya57> Similar thing happened in Debian, but with other .cpp file.
<lubot> <mitya57> I will retry.
<lubot> <RikMills> @mitya57 [Probably libmd4c-dev needs to be added to the whitelist.], done and built apparently
<lubot> <RikMills> not published yet....
<lubot> <mitya57> Ok, let's hope that library is enough
<lubot> <mitya57> @mitya57 [I will retry.], riscv64 failed again :(
<lubot> <mitya57> I will ask wgrant or doko tomorrow, now time to go to bed
<lubot> <RikMills> ok. good night :)
<lubot> <mitya57> Thanks!
<lubot> <UniversalSuperBox> I know this isn't exactly the right place, but IRC never answered me in the past... We're trying to use the Qt auto-scaling, which is activated using QT_AUTO_SCREEN_SCALE_FACTOR. We had to implement the `pixelDensity()` function in our own QPA in order to do this in the past... but now we're using QtWayland
<lubot> <UniversalSuperBox> I had to do this in the past: https://github.com/ubports/qtubuntu/pull/5 â¦ But QtWayland just won't seem to do the scaling correctly. How are the rest of you handling auto scaling under Wayland, if at all?
<lubot> <UniversalSuperBox> It seems to be about the only way to make QtWebEngine do the scaling correctly
<lubot> <RikMills> I gave riscv64 one more try for luck, but failed again
#ubuntu-qt 2020-05-13
<lubot> <mitya57> https://irclogs.ubuntu.com/2020/05/13/%23ubuntu-devel.html#t07:51 â my discussion with wgrant
<RikMills> thanks
<mitya57> Today's status update:
<mitya57> - In Debian Qt 5.14.2 is mostly done, only two insignificant packages are remaining (qtdoc and qtimageformats) which I will do in the morning.
<mitya57> - Bootstrapping is in progress in PPA 4057. qtbase failed on arm64 two times without log, retried again, let's hope it will work.
<mitya57> Also, looks like we are not alone with the riscv64 bug, ruby2.7 is also affected. wgrant said: I'll hopefully investigate it tomorrow, or just downgrade all the VMs again and see if they work
#ubuntu-qt 2020-05-14
<lubot> <RikMills> thanks for the update :)
<lubot> <mitya57> Buildds are slow today :(
<mitya57> Yet another status update:
<mitya57> - All of Qt 5.14.2 is now uploaded to Debian experimental.
<mitya57> - qtbase finally built fine on riscv64.
<mitya57> - Buildds are not only slow but also buggy today, builds are failing without any log so I have to retry them.
<lubot> <RikMills> :) Thanks for the work.
<lubot> <mitya57> Docs are bootstrapped now, I will be copying more packages from Debian when their reverse dependencies get built.
#ubuntu-qt 2020-05-16
<lubot> <RikMills> Looking good apart from the few fails
<lubot> <mitya57> I will look at qtimageformats SIGILL on armhf later today. In the mean time I think you can do the rebuilds.
<lubot> <mitya57> qtremoteobjects is not a regression. qtquickcontrols is a regression, but I will retry it first.
<lubot> <RikMills> @mitya57 [qtremoteobjects is not a regression. qtquickcontrols is a regression, will also â¦], I retried qtquickcontrols about an hour ago.
<lubot> <RikMills> @mitya57 [I will look at qtimageformats SIGILL on armhf later today. In the mean time I th â¦], If you are sure, I'll get those done in a minute
<lubot> <mitya57> @RikMills [If you are sure, I'll get those done in a minute], Why not?
<lubot> <RikMills> @mitya57 [Why not?], I just meant that if you are sure the stack is complete and buildable against. It was more a turn of phrase than anything. I am sure it is all good.
<lubot> <mitya57> In the worst case some packages can dep-wait. As far as I know Launchpad they should not build against 5.12.8.
<lubot> <RikMills> Oops. my rebuild script was still set to focal. just as well I did not upload. Will take a short while to regenerate the sources
<lubot> <RikMills> rebuilds uploaded
<lubot> <mitya57> @mitya57 [I will look at qtimageformats SIGBUS on armhf later today. In the mean time I th â¦], Looks like a real bug: unaligned access in https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/painting/qicc.cpp?h=v5.14.2#n447
<lubot> <mitya57> â¦which doesn't seem to be easily fixable because unaligned access is all over that file :(
<lubot> <mitya57> I filed https://bugreports.qt.io/browse/QTBUG-84267 for now because I want some advice from upstream before spending hours on it.
<lubot> <mitya57> qtcreator needs new qbs, which I will work on.
<lubot> <mitya57> qbs needs more work because there are many changes between 1.14 and 1.16. Will continue tomorrow.
<lubot> <mitya57> In the mean time I fixed deepin-qt5dxcb-plugin and tried to fix gammaray, but not fixed completely.
<lubot> <RikMills> thanks. I have not checked through yet, but anything in sync with debian do you want to fix there and copy, or not that bothered as it will get done eventually with debian transition?
<lubot> <mitya57> I will upload directly packages that are in Qt/KDE team, and file bugs for others. But later, I have little time as usual and want to finish the transition in Ubuntu first.
#ubuntu-qt 2020-05-17
<lubot> <mitya57> Small status update: â¦ - Fixed qttools, this allowed me to retry a dozen of failed riscv64 builds. I will be able to retry more when kxmlgui is built on riscv64. â¦ - Copied qbs 1.14 from Debian. This is not the latest release, but 1.16 will take more time because it will need to pass Debian's NEW queue. But it should be already compat
<lubot> ible with Qt 5.14.
<lubot> <RikMills> module qtqml is not installed :/
<lubot> <mitya57> Where is that?
<lubot> <RikMills> (Photo, 1280x865) https://i.imgur.com/opOlznR.jpg
<lubot> <RikMills> sddm startup
<lubot> <mitya57> Something needs to depend on qml-module-qtqml
<lubot> <RikMills> is that new?
<lubot> <mitya57> Yes, it is new. Looks like qml-module-qtquick-controls needs that dependency (it needs a new upload because of tests anyway).
<lubot> <RikMills> @mitya57 [Yes, it is new. Looks like qml-module-qtquick-controls needs that dependency (it â¦], Makes sense. Thanks :)
<lubot> <RikMills> Installing that fixes sddm and plasma
<lubot> <mitya57> Great!
<lubot> <RikMills> Had to use proposed as webengine picked up a dep on the new re2 lib in there, but things seem ok in a very quick VM test now
<lubot> <mitya57> Fixed dde-qt5integration
<lubot> <mitya57> We need a helper that will automatically add QML dependencies based on plugins.qmltypes
<lubot> <RikMills> I might start test building new plasma against the PPA later
<lubot> <bhushanshah> Do anyone know nature of this patch? https://packaging.neon.kde.org/kde/kwallet.git/tree/debian/patches/blowfish_endianess.diff?h=Neon/unstable
<lubot> <mitya57> `#define Q_BYTE_ORDER Q_BIG_ENDIAN` (which was in original file and not patched out) looks very wrong
<lubot> <RikMills> @bhushanshah [Do anyone know nature of this patch? https://packaging.neon.kde.org/kde/kwallet. â¦], debian/changelog says it was added for this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828160
<ubottu> Debian bug 828160 in src:kwallet-kf5 "kwallet-kf5: FTBFS on hppa - blowfishtest (Failed)" [Normal,Fixed]
<lubot> <mitya57> @mitya57 [Yes, it is new. Looks like qml-module-qtquick-controls needs that dependency (it â¦], Added in https://salsa.debian.org/qt-kde-team/qt/qtquickcontrols/-/commit/cb684fa064063135, will be in the next upload to PPA.
<lubot> <bhushanshah> So just as a note : https://bugs.kde.org/show_bug.cgi?id=362805#c19 new upstream patch in kwallet breaks existing wallets with debian patchset
<ubottu> KDE bug 362805 in general "KF5Wallet can't open previuosly created wallet with error code -9" [Normal,Resolved: fixed]
<lubot> <bhushanshah> So you will have to revert part of upstream patch for next release
<lubot> <RikMills> @bhushanshah [So you will have to revert part of upstream patch for next release], I'm slightly lost, but I guess follow what you do in Neon?
<lubot> <bhushanshah> More or less yes
<lubot> <bhushanshah> https://cgit.kde.org/kwallet.git/commit/?id=850219f83e7d74621efba9cf8a6eebb11f6bc3fc essentially revert of this will be needed
<lubot> <RikMills> right
<lubot> <mitya57> Hopefully fixed gammaray, qgis and qtav. The major remaining package is qtcreator, which is better with new qbs, but now has error installing the documentation.
<lubot> <mitya57> Looks like that error was always there, but now is fatal because of https://code.qt.io/cgit/qt/qtbase.git/commit/?id=20e9422e069a27b7
<lubot> <mitya57> I think I fixed everything now, we should just wait until it builds :)
<lubot> <RikMills> :)
<lubot> <RikMills> new perl just landing in proposed which makes pkg-kde-tools impossible to install in builds :(
<mamarley> RikMills: It looks like libclass-xsaccessor-perl and possible libcommon-sense-perl need rebuilds.
<lubot> <mitya57> For Qt transition, we need to wait for a few builds to finish and then it will be good to land.
<lubot> <mitya57> @RikMills Feel free to do that if I will be sleeping :)
<lubot> <mitya57> (Or you want to wait until perl is fixed?)
<lubot> <RikMills> I'll think about that. I will check in a couple of hrs before I sleep
<valorie> y'all are heroes!
<lubot> <RikMills> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960856
<ubottu> Debian bug 960856 in release.debian.org "binnmus for perl mini-transition" [Normal,Open]
<lubot> <RikMills> I think we may as well land.
 * RikMills clicks buttons
<RikMills> 5.14.2 landing
<mamarley> \o/ Great job!
<mamarley> Also, it looks like https://bugs.launchpad.net/ubuntu/+source/qtwayland-opensource-src/+bug/1862987 is going to get some attention very soon.  That package is also needed for kwayland-server.
<ubottu> Launchpad bug 1862987 in qtwayland-opensource-src (Ubuntu) "qtbase5-private-dev does not install private headers for QtWayland" [Undecided,New]
#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://acolon@example.com;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. :)
#ubuntu-qt 2020-05-25
<lubot> <mitya57> @RikMills qtwebengine finally built fine in 4072. Do you think it's ok to land it now?
<lubot> <RikMills> @mitya57 [@RikMills qtwebengine finally built fine in 4072. Do you think it's ok to land i â¦], Probably, as Qt is not migrating any time soon. Can we run the testis or the PPA though to make sure rdep tests are ok?
<lubot> <mitya57> I forgot how to do this :(
<lubot> <RikMills> @mitya57 [I forgot how to do this :(], diff and set lander signoff to approved
<lubot> <RikMills> after a couple of 20 min bileto bot updates, tests should run
<lubot> <mitya57> Doing.
<lubot> <RikMills> :)
<lubot> <RikMills> Maybe we should also ask vorlon tonight if he is happy with it landing. Our original Qt landing stomped on another transition, which vorlon reverted webengine to get through. Then the other day I bemoaned someone else's webengine rebuild that entangled re2. So to maintain good will, and in case this rebuild has picked up a dep in pro
<lubot> posed we can't tell, then asking would be smart.
<lubot> <mitya57> Asked on #-release.
<lubot> <RikMills> Great. This is safer. Going to need his help to get Qt through ð
<lubot> <mitya57> https://bileto.ubuntu.com/excuses/4072/groovy.html â looks like Bileto does not use packages from -proposed
<lubot> <mitya57> "libqt5webengine5 : Depends: libqt5core5a (>= 5.14.2+dfsg~) but 5.12.8+dfsg-0ubuntu1 is to be installed"
<lubot> <RikMills> odd. I am sure is has before on ones I did
<lubot> <RikMills> vorlon said ok, so am trying to land it
#ubuntu-qt 2020-05-29
<lubot> * mitya57 notices that Qt migrated
<lubot> <x_sun> Yay, new Plasma soon
<lubot> <RikMills> @mitya57 [/me notices that Qt migrated], How the hell did that happen?
<lubot> <RikMills> but \o/
<lubot> <RikMills> @x_sun [Yay, new Plasma soon], Not soon, sorry.
<lubot> <RikMills> It needs 2 new source packages, which on past experience takes ages to get archive admins to review and accept
<lubot> <RikMills> + they are not in debian yet, so I cannot get them that way via sync
<mparillo> Qt migrated? The last of the LTS https://www.qt.io/blog/qt-5.15-released ? To GG Daily Builds?
<RikMills> mparillo: no, 5.14.2
<mparillo> Thanks, and sorry for jumping the gun.
<RikMills> mparillo: no worries. we hjave not discussed 5.15 yet, but the plasma we will have in groovy only needs 5.14 so I guess we shall just see what is possible
<lubot> <x_sun> It's a bit too early for 5.15, I'm already applying tons of patches to 5.15.0 webengine ð
<lubot> <mitya57> @RikMills [How the hell did that happen?], Kudos go to vorlon â¦ https://lists.ubuntu.com/archives/ubuntu-devel/2020-May/041026.html
<lubot> <RikMills> @mitya57 [Kudos go to vorlon â¦ https://lists.ubuntu.com/archives/ubuntu-devel/2020-May/0410 â¦], https://lists.ubuntu.com/archives/ubuntu-devel/2020-May/041027.html
<lubot> <RikMills> I just replied
<lubot> <mitya57> Ah, great
<lubot> <RikMills> I am still not sure how some of the issue were solved, but I'll take it! :P
<lubot> <RikMills> @mitya57 [Ah, great], Oh, and thank you for 5.14!
<lubot> <mitya57> You are welcome :)
<mitya57> I think it's time to update channel topic. RikMills, can you add groovy please?

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