Dear Maintainer,

I am planing to upload jimtcl 0.84-2 to unstable soon and request one
transition from 0.83 to 0.84. Rebuild openocd with the jimtcl 0.84-1 but
will get:

```
src/helper/log.c: In function 'log_puts':
src/helper/log.c:99:11: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
   99 |         f = strrchr(file, '/');
      |           ^
src/helper/command.c: In function 'jimcmd_is_proc':
src/helper/command.c:51:19: error: 'Jim_Cmd' has no member named 'isproc'
   51 |         return cmd->isproc;
      |                   ^~
src/helper/command.c: In function 'jimcmd_is_oocd_command':
src/helper/command.c:56:20: error: 'Jim_Cmd' has no member named 'isproc'
   56 |         return !cmd->isproc && cmd->u.native.cmdProc == jim_command_dispatch;
      |                    ^~
src/helper/command.c: In function 'jimcmd_privdata':
src/helper/command.c:61:19: error: 'Jim_Cmd' has no member named 'isproc'
   61 |         return cmd->isproc ? NULL : cmd->u.native.privData;
      |                   ^~
libtool: link: ar cr src/xsvf/.libs/libxsvf.a src/xsvf/xsvf.o
libtool: link: ranlib src/xsvf/.libs/libxsvf.a
```

Upstream has one commit[0] to fix the build issue and I can confirm that
it works on Debian here also.

So once I upload jimtcl 0.84-2 to unstable, could you have a look at
this?

[0]: https://review.openocd.org/c/openocd/+/8956

Dear maintainer,

I've prepared an NMU for openocd (versioned as 0.12.0-3.1) and uploaded
it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian

I'm not particularly impressed at the speed this went from "I'm going to
upload something that breaks your package" to "This is now an RC bug" to
"Here's an NMU that ignores the fact your package is team maintained and
in git". It doesn't seem to warrant that sense of urgency, and while I'm
sure your upload is good intentioned it doesn't seem to meaningfully
reduce the work required on the part of the maintainer.

J.

jimtcl is a transition (#1146078), and the release team will want to
finish the transition by seeing libjim0.83 removed from testing in the
not too distant future.

I'm just trying to get stuff fixed before the release team
starts considering finishing the transition by removing
openocd from testing.

I agree that the speed of everything was a bit fast in this case,
usually transitions happen at a more glacial speed and the bugs
are already older when the transition starts.

I've cancelled my NMU.

cu
Adrian

Am 01.09.26 um 13:45 schrieb Jonathan McDowell:

This isn't the first time Adrian is working this way.
I've seen this multiple times the past month.

And always the excuse was "package x is in a transition". We are still
just after the release of a new stable release, so I've really some
difficulties to see some collaborative work and good intentions behind
these nearly 0-day NMUs. There is no specific pressure at the moment to
whatever transition done in the next 4 weeks.

I loose quickly the interested now to even look at such NMUs as the
speed these are done sets me under pressure (and isn't really helping me
as Jonathon also stated) as I'm working still on a voluntarily base for
Debian.
So I decided to given up packages Adrian is "contributing" something too
or will cancel such NMUs without further information.

We still have well established processes for bug and FTBFS fixing and
NMUs as well and I can't see why such NMUs are an exception from these
workflows.