Bug#953383: marked as done (transition: libgwenhywfar)
Your message dated Mon, 30 Mar 2020 12:27:33 +0200
with message-id <9d73c763-4b6e-c090-0bf4-11172cef53cf@debian.org>
and subject line Re: Bug#953383: transition: libgwenhywfar
has caused the Debian Bug report #953383,
regarding transition: libgwenhywfar
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.)
--
953383: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953383
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: transition
Control: forwarded -1 https://release.debian.org/transitions/html/auto-libgwenhywfar.html
Hi release team,
the Gwenhywfar package got its SONAMEs cleaned up (actually synced with the
main library) for its frontend libraries. For this reason some binary package
names had to be changed:
- libgwengui-gtk3-0 -> libgwengui-gtk3-79,
- libgwengui-qt5-0 -> libgwengui-qt5-79,
- libgwengui-fox16-0 -> libgwengui-fox16-79.
Additionally with the SONAME now being in sync with the main library, the C++
frontend library previously packaged in libgwengui-cpp0 (which doesn't itself
depend on any other GUI framework libraries like GTK) could be merged to the
main library package libgwenhywfar79 and hence disappears.
The affected packages will need a binNMU to pick up the new SONAME from the
corresponding libgwengui-* package:
* https://tracker.debian.org/gnucash
* https://tracker.debian.org/kmymoney
I didn't do a test rebuild of these packages, because reading through the
upstream changes compared to the last uploader there were no other changes in
the gui/ folder of the upstream source. I don't expect any breakage.
Best regards,
Micha
Ben file:
title = "libgwenhywfar";
is_affected = .depends ~ "\b(libgwengui\-cpp0|libgwengui\-fox16\-0|libgwengui\-gtk3\-0|libgwengui\-qt5\-0|libgwenhywfar79\-dev)\b" | .depends ~ "\b(libgwengui\-fox16\-79|libgwengui\-gtk3\-79|libgwengui\-qt5\-79)\b";
is_good = .depends ~ "\b(libgwengui\-fox16\-79|libgwengui\-gtk3\-79|libgwengui\-qt5\-79)\b";
is_bad = .depends ~ "\b(libgwengui\-cpp0|libgwengui\-fox16\-0|libgwengui\-gtk3\-0|libgwengui\-qt5\-0|libgwenhywfar79\-dev)\b";
--- End Message ---
--- Begin Message ---
On 09/03/2020 11:05, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
>
> On 08/03/2020 21:02, Micha Lenk wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian.org@packages.debian.org
>> Usertags: transition
>> Control: forwarded -1 https://release.debian.org/transitions/html/auto-libgwenhywfar.html
>>
>> Hi release team,
>>
>> the Gwenhywfar package got its SONAMEs cleaned up (actually synced with the
>> main library) for its frontend libraries. For this reason some binary package
>> names had to be changed:
>> - libgwengui-gtk3-0 -> libgwengui-gtk3-79,
>> - libgwengui-qt5-0 -> libgwengui-qt5-79,
>> - libgwengui-fox16-0 -> libgwengui-fox16-79.
>>
>> Additionally with the SONAME now being in sync with the main library, the C++
>> frontend library previously packaged in libgwengui-cpp0 (which doesn't itself
>> depend on any other GUI framework libraries like GTK) could be merged to the
>> main library package libgwenhywfar79 and hence disappears.
>>
>> The affected packages will need a binNMU to pick up the new SONAME from the
>> corresponding libgwengui-* package:
>> * https://tracker.debian.org/gnucash
>> * https://tracker.debian.org/kmymoney
>> I didn't do a test rebuild of these packages, because reading through the
>> upstream changes compared to the last uploader there were no other changes in
>> the gui/ folder of the upstream source. I don't expect any breakage.
>
> I would have preferred to have actual confirmation that the rdeps build fine,
> but given the above and that there are only two of them, let's go ahead.
This is finished, closing.
Emilio
--- End Message ---
Reply to: