[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#923184: marked as done (unblock: qgis/3.4.6+dfsg-1)

Your message dated Sat, 30 Mar 2019 12:39:45 +0100
with message-id <ba14fdd5-a9f0-04b1-007b-7e19bef75343@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 owner@bugs.debian.org
immediately.)


-- 
923184: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923184
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: release.debian.org@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.

Paul

Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---
Reply to: