Your message dated Thu, 17 Feb 2022 21:02:57 +0100
with message-id <yg6p8s8vqznsg...@ramacher.at>
and subject line Re: Bug#1005068: transition (unplanned?): libwacom9
has caused the Debian Bug report #1005068,
regarding transition (unplanned?): libwacom9
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.)
--
1005068: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005068
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: transition
X-Debbugs-Cc: libwa...@packages.debian.org
Control: forwarded -1
https://release.debian.org/transitions/html/auto-libwacom.html
src:libwacom was recently updated from libwacom2 to libwacom9, starting
a transition. I don't see any indication that this was approved by the
release team, so I'm opening this transition tracking bug (my apologies
if there is already a transition-tracker that I missed).
https://release.debian.org/transitions/html/auto-libwacom.html looks like
it is tracking this transition correctly.
Because libwacom2 and libwacom9 both depend on a matching libwacom-common,
this makes affected packages such as mutter uninstallable in unstable.
How big are the API/ABI breaks? Are dependent packages expected to compile
and work successfully without code changes?
In addition to rebuilding reverse-dependencis, src:libwacom will need a
source-only upload to unstable so that it will be allowed to migrate.
It is usually best for transitions to happen by uploading NEW packages
to experimental, then opening a transition-tracking bug like this one
and getting release team approval, and finally re-uploading to unstable
after approval has been received, particularly if the transition is an
all-or-nothing one like this.
smcv
--- End Message ---
--- Begin Message ---
On 2022-02-07 13:52:48 +0200, Timo Aaltonen wrote:
> Sebastian Ramacher kirjoitti 7.2.2022 klo 11.38:
> > On 2022-02-07 10:48:01, Timo Aaltonen wrote:
> > > Simon McVittie kirjoitti 7.2.2022 klo 3.17:
> > > > On Mon, 07 Feb 2022 at 00:51:08 +0000, Marius Gripsgard wrote:
> > > > > The ABI/API breakage is not *too* bad, see [0]. just hope none use
> > > > > those
> > > > > deprecated APIs
> > > > >
> > > > > [0]
> > > > > https://github.com/linuxwacom/libwacom/commit/b4f3c3f855a68e35b5ebfc305bc67c565f9146c7
> > > >
> > > > Thanks. Looks like nobody should have been using those symbols anyway
> > > > (the commit message says they were private and not mentioned in any
> > > > public
> > > > header files), and codesearch.debian.net does not find any references
> > > > outside src:libwacom, so it should be safe to binNMU dependent packages.
> > > >
> > > > smcv
> > > >
> > >
> > > Right, should've asked for a transition.
> > >
> > > Filed nmu's for wacomtablet and cinnamon-settings-daemon, libinput rebuild
> > > upload I did myself.
> >
> > If there's a transition bug, there is no need to file individual
> > requests for nmus.
> >
> > Cheers
>
> Oh, sorry about those then. I thought there was something I had to do to fix
> this mess..
>
> I'll upload a source-only libwacom later, thanks.
libwacom migrated and the old binary packages got removed.
Cheers
--
Sebastian Ramacher
signature.asc
Description: PGP signature
--- End Message ---
