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

Bug#1098999: marked as done (transition: bobcat)

Your message dated Fri, 28 Feb 2025 10:12:59 +0100
with message-id <7a080db7-02fa-4191-89e0-3981204305e2@debian.org>
and subject line Re: Bug#1098999: transition: bobcat
has caused the Debian Bug report #1098999,
regarding transition: bobcat
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.)


-- 
1098999: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098999
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: bobcat@packages.debian.org
Control: affects -1 + src:bobcat
User: release.debian.org@packages.debian.org
Usertags: transition

Dear Release Team,

The bobcat source package 6.07.01 introduces an enum change that will
require sourceful uploads of a subset of packages that have build
dependencies on libbobcat-dev to accommodate the new enum value.  Or put
more directly, the following packages will FTBFS once bobcat >= 6.07.01
enters the archive:

filtermail
flexc++
guncat
natlog
ssh-cron
stealth
xd

In case you're curious, the reason the enum change can't be made
backwards compatible is due to the use of a single precompiled header in
bobcat 6.07 and the preprocessor tripping over the (old) enum value of
"None".  Not all 

There is no ABI breakage, hence no SONAME bump, and there is no issue
with libbobcat6 entering the archive.

All of these source packages have a common upstream author who has
already prepared updated upstream versions that will declare versioned
build dependencies on libbobcat-dev >= 6.07.01.  I have verified the
list by building all packages that build-dep on bobcat.

If the transition is approved, I believe the convention is that I will
file FTBFS bugs against all of the affected build r-deps and block them
with the transition bug.  (Or perhaps simply mark these packages as
affected by the transition bug?)

Then upload bobcat to unstable, and follow immediately with the new
versions of the affected packages with the versioned build-dep.  This
could also be done in the opposite order - I am open to guidance.

I wasn't 100% clear on how to specify a version in the ben file but this
is the proposed file:

title = "bobcat";
is_affected = .depends ~ "libbobcat-dev"
is_good = .depends ~ "libbobcat-dev" & >= "6.07.01";
is_bad = .depends ~ "libbobcat-dev" & << "6.07.01";


Thank you in advance for your help,
tony

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- 
Control: tags -1 confirmed

On 27/02/2025 05:10, tony mancill wrote:

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: bobcat@packages.debian.org
Control: affects -1 + src:bobcat
User: release.debian.org@packages.debian.org
Usertags: transition

Dear Release Team,

The bobcat source package 6.07.01 introduces an enum change that will
require sourceful uploads of a subset of packages that have build
dependencies on libbobcat-dev to accommodate the new enum value.  Or put
more directly, the following packages will FTBFS once bobcat >= 6.07.01
enters the archive:

filtermail
flexc++
guncat
natlog
ssh-cron
stealth
xd

In case you're curious, the reason the enum change can't be made
backwards compatible is due to the use of a single precompiled header in
bobcat 6.07 and the preprocessor tripping over the (old) enum value of
"None".  Not all

There is no ABI breakage, hence no SONAME bump, and there is no issue
with libbobcat6 entering the archive.

All of these source packages have a common upstream author who has
already prepared updated upstream versions that will declare versioned
build dependencies on libbobcat-dev >= 6.07.01.  I have verified the
list by building all packages that build-dep on bobcat.

If the transition is approved, I believe the convention is that I will
file FTBFS bugs against all of the affected build r-deps and block them
with the transition bug.  (Or perhaps simply mark these packages as
affected by the transition bug?)

Then upload bobcat to unstable, and follow immediately with the new
versions of the affected packages with the versioned build-dep.  This
could also be done in the opposite order - I am open to guidance.

I wasn't 100% clear on how to specify a version in the ben file but this
is the proposed file:
Go ahead. I don't think we need to track this as a transition, as as you say, there is no SONAME bump. You can just file those bugs, usertag them, and start fixing them or sending patches, and track the progress in the bug list. 

Cheers,
Emilio

--- End Message ---
Reply to: