#ubuntu-qt 2019-10-28
-queuebot:#ubuntu-qt- New binary: pyqt5webengine [amd64] (focal-proposed/universe) [5.12.1-4] (no packageset)
-queuebot:#ubuntu-qt- New binary: pyqt5webengine [i386] (focal-proposed/universe) [5.12.1-4] (no packageset)
-queuebot:#ubuntu-qt- New binary: pyqt5webengine [armhf] (focal-proposed/universe) [5.12.1-4] (no packageset)
-queuebot:#ubuntu-qt- New binary: pyqt5webengine [arm64] (focal-proposed/universe) [5.12.1-4] (no packageset)
-queuebot:#ubuntu-qt- New: accepted pyqt5webengine [amd64] (focal-proposed) [5.12.1-4]
-queuebot:#ubuntu-qt- New: accepted pyqt5webengine [armhf] (focal-proposed) [5.12.1-4]
-queuebot:#ubuntu-qt- New: accepted pyqt5webengine [arm64] (focal-proposed) [5.12.1-4]
-queuebot:#ubuntu-qt- New: accepted pyqt5webengine [i386] (focal-proposed) [5.12.1-4]
<lubot> <RikMills> both transition trackers now at 100%. I guess just got a bazillion more tests to go
<lubot> <mitya57> Thank you for handling that!
<lubot> <RikMills> no problem. I have the largest vested interest :P
<lubot> <RikMills> I really want to get on to uploading new plasma/frameworks/apps etc
<lubot> <RikMills> looks like we are entangled with a few things. not overly suprising given the massive amount autosynced
<lubot> <mitya57> Same thing in Debian
#ubuntu-qt 2019-10-29
<lubot> <mitya57> Qt 5.12.6 is planned for November 15th
<lubot> <mitya57> It should be easy but I want to make a series of uploads to (Debian) NEW queue to fix some bugs, and prepare new release only after that.
#ubuntu-qt 2019-10-30
<lubot> <RikMills> @mitya57 what happened to python-pyqt5.qtwebengine?
<lubot> <mitya57> It was removed but then re-added.
<lubot> <RikMills> calibre/amd64 unsatisfiable Depends: python-pyqt5.qtwebengine (>= 5.12.1-4+b1)
<lubot> <mitya57> That's because we don't have +b1
<lubot> <mitya57> So we need to either no-change upload pyqt5webengine with higher version, or lower the dependency in calibre.
<lubot> <RikMills> calibre should be easier for now?
<lubot> <mitya57> +b1 is Debian's suffix for rebuilds.
<lubot> <mitya57> Maybe
<lubot> <RikMills> @mitya57 [Maybe], Oh, that is seperate now isn't it. Bumping that may be better then. As build1 > b1 I think?
<lubot> <mitya57> There is a + so I'm not sure
<lubot> <RikMills> I can ask dpkg
<lubot> <RikMills> $ if $(dpkg --compare-versions "5.12.1-4build1" "lt" "5.12.1-4+b1"); then echo true; fi â¦ true
<lubot> <RikMills> damn
<lubot> <RikMills> not sure if we can add to the +b1 and still have it autosync?
<lubot> <mitya57> Don't worry about autosyncs, I can sync it manually when needed.
<lubot> <RikMills> 5.12.1-4+b1build1 seem ok?
<lubot> <mitya57> Why not just +b1?
<lubot> <RikMills> @mitya57 [Why not just +b1?], good point!
<lubot> <RikMills> doing that then
<lubot> <mitya57> Thank you!
<lubot> <RikMills> Not going to work. When building the source the +b1 gets removed from the .dsc file, so gets rejected on upload.
<lubot> <mitya57> Will +b1build1 work then?
<lubot> <mitya57> If not, then better fix on calibre side.
<lubot> <RikMills> @mitya57 [Will +b1build1 work then?], It did :)
<lubot> <mitya57> Ok
<lubot> <mitya57> Thanks again
<lubot> <RikMills> NP. More things to fix, but at least that should be ok
-queuebot:#ubuntu-qt- Unapproved: qtbase-opensource-src (bionic-proposed/main) [5.9.5+dfsg-0ubuntu2.3 => 5.9.5+dfsg-0ubuntu2.4] (kubuntu, qt5, ubuntu-desktop)
<lubot> <RikMills> Just as we get close to migration, autosync dumps more things to stop it. ð
<valorie> of course
<lubot> <RikMills> Yep. Time for ð´ I think. See where we are in the morning!
<valorie> sweet dreams, RikMills
#ubuntu-qt 2019-10-31
<lubot> <RikMills> @RikMills [Just as we get close to migration, autosync dumps more things to stop it. ð], And the same just happened again. I ****ing give up
<lubot> <RikMills> Sorry. Just very annoying. ð¤£
#ubuntu-qt 2019-11-01
<lubot> <RikMills> @mitya57 do you think a python-qt4 upload to ubuntu reverting the python3-dbus.mainloop.qt drop would be ok? that still has rdeps in ubuntu that trace as far as unity
<lubot> <RikMills> the dropping of phon packages might get phonon in proposed to migrate, so would lile to see python-qt4 migrate also
<lubot> <mitya57> I don't mind, can you do it?
<lubot> <RikMills> Not right now, but maybe later on today. I am fine with taking responsibility
<lubot> <mitya57> I removed Python3 version of dbus.mainloop.qt in a separate commit, so you can just git revert it.
<lubot> <mitya57> Thanks!
<lubot> * mitya57 doesn't have time today, unfortunately
<lubot> <RikMills> No probs. I want to double check the migration outputs to make sure it will do what I think, anyway
<lubot> <RikMills> That worked. Phonon and python-q4 migrating from proposed
<lubot> <mitya57> Thank you!
<lubot> <mitya57> I wonder how phonon managed to migrate in Debian, when python-qt4 still build-depended on it O_o
<lubot> <RikMills> I looked at that and couldn't quite work it out either!
<lubot> <x_sun> o.O
#ubuntu-qt 2019-11-02
 * mitya57 retries pivy autopkgtests which are blocking pyside2 migration
<mitya57> update_output.txt mostly complains about pyside2 now, so maybe we'll get one more step closer to Qt migration if they pass
<lubot> <RikMills> seemed to work
<lubot> <mitya57> Now it complains about:
<lubot> <mitya57> kalgebra, kalgebra-common, kalgebramobile, kde-full, kdeedu, libanalitza-dev, libqgis-3d3.4.13, libqgis-analysis3.4.13, libqgis-app3.4.13, libqgis-core3.4.13, libqgis-customwidgets, libqgis-dev, libqgis-gui3.4.13, libqgis-server3.4.13, libqgisgrass7-3.4.13, libqgispython3.4.13, openorienteering-mapper, pyotherside, pyotherside-tests,
<lubot> python3-qgis, python3-qgis-common, qgis, qgis-plugin-grass, qgis-provider-grass, qgis-providers, qgis-server, qml-module-io-thp-pyotherside, qml-module-org-kde-analitza, qml-module-qtav, qtav-players
<lubot> <mitya57> Still a lot of stuff :(
<lubot> <mitya57> Ok, most of this is qgis but I don't understand what's wrong with it yet.
<lubot> <RikMills> qgis depends on proj, so can olnly migrate if that does. sadly multiple things with failing tests in proposed depend on the libproj13 -> libproj15 transition, so that blocks proj even if it says it is a valid candidate. rbase + r-cran packages are linked in to that
<lubot> <RikMills> It is a bit of a mess
<blaze> yikes
<lubot> <RikMills> Hnece I asked this last night: â¦ [04:45] <RikMills> vorlon: might you consider removing the release versions of qgis and openorienteering-mapper for now to move the Qt transition along? 1st only has reverse recommends while the 2nd nothing â¦ [04:46] <RikMills> I think the proj/rbase brokenness might take some time
<lubot> <mitya57> Ah, thanks for digging this :)
<lubot> <RikMills> I am not sure why britney does not want to group analitza and pyotherside with the 'trying' group yet. I think that is just britney oddness and perhaps hintable if the other things are cleared out of the way. It does not make sense dep-wise to me.
#ubuntu-qt 2019-11-03
<lubot> <RikMills> Those 2 removals, plus a manual hint from vorlon, just made Qt migrate :)
<lubot> <mitya57> \o/
<valorie> nice!
