Your message dated Sat, 30 Mar 2019 12:39:45 +0100 with message-id <ba14fdd5-a9f0-04b1-007b-7e19bef75...@debian.org> and subject line Re: Bug#923184: unblock: qgis/3.4.6+dfsg-1 has caused the Debian Bug report #923184, regarding unblock: qgis/3.4.6+dfsg-1 to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 923184: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923184 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: release.debian.org Severity: normal User: release.debian....@packages.debian.org Usertags: unblock Because the 2.18 LTR is EOL with the release of QGIS 3.4.5 having the latter in buster is probably better than leaving the qgis package at the last 2.18.x release (2.18.28). QGIS 3.4 is the new LTR and switches to Qt5 and Python 3, as such the changes since the version in testing are quite large and cannot be considered "small, targeted fixes". While users of the qgis package are unlikely to use the version of the package available in stable, and more likely using the latest LTR from backports, I think having 3.4.5 in buster is better for users upgrading from stretch than leaving them with the EOL 2.18.28 release until the package is updated in buster-backports. Would you approve of moving QGIS 3.4.5 from experimental to unstable and allowing it to migrate to tesing for inclusion in buster? Or should we keep it experimental until after the release, and make the newer LTRs available in buster-backports when it hits testing? Kind Regards, Bas
--- End Message ---
--- Begin Message ---tags 923184 wontfix thanks Hi Sebastiaan, First of all, sorry it took a while to come back to your request. On 30-03-2019 11:18, Sebastiaan Couwenberg wrote: > On 3/17/19 11:43 PM, Sebastiaan Couwenberg wrote: >> On 3/17/19 8:17 PM, Sebastiaan Couwenberg wrote: >>> On 2/24/19 9:23 PM, Bas Couwenberg wrote: >>>> Because the 2.18 LTR is EOL with the release of QGIS 3.4.5 having the >>>> latter in buster is probably better than leaving the qgis package at the >>>> last 2.18.x release (2.18.28). >>>> >>>> QGIS 3.4 is the new LTR and switches to Qt5 and Python 3, as such >>>> the changes since the version in testing are quite large and cannot be >>>> considered "small, targeted fixes". Ack. >>>> While users of the qgis package are unlikely to use the version of the >>>> package available in stable, and more likely using the latest LTR from >>>> backports, I think having 3.4.5 in buster is better for users upgrading >>>> from stretch than leaving them with the EOL 2.18.28 release until the >>>> package is updated in buster-backports. >>>> >>>> Would you approve of moving QGIS 3.4.5 from experimental to unstable and >>>> allowing it to migrate to tesing for inclusion in buster? >>>> >>>> Or should we keep it experimental until after the release, and make the >>>> newer LTRs available in buster-backports when it hits testing? >>> >>> As reported by Lucas Nussbaum in #924833, qgis (2.18.28-2) FTBFS in >>> unstable due to sip4 (4.19.14+dfsg-1) which was uploaded a couple of >>> weeks after qgis. >>> >>> With 2.18.x being EOL upstream, we cannot rely on upstream to provide a >>> fix, and I lack the skills for it. >>> >>> I'm going to move QGIS 3.4 to unstable so that we at least have a >>> version of QGIS in unstable that supports SIP 4.19.14. >>> >>> If the changes in QGIS 3.4 are deemed to invasive for an unblock, we'll >>> have to release buster without qgis and deal with lots of unhappy users. Although we understand that the FTBFS issue in you package was caused by an new version of your build dependency, which had an upload very much not in line with the transition freeze at the time, we will not unblock your package. The changes are just too large in this stage of releasing buster. It would have helped your case if the work on packaging a newer version of qgis would have started earlier, such that the updates in buster would have been smaller. I am aware that you know the concept of autopkgtest, so we suggest you add a test where you try to prevent this kind of change going unnoticed, as you suggest that this is not the first time that sip4 breaks bindings that you use. If those tests are in place, this type of breakage will be spotted automatically and the migration software will block such an version from migrating, until the issue is fixed. Paulsignature.asc
Description: OpenPGP digital signature
--- End Message ---