On 2026-07-21 12:39:11, Colin Watson wrote:
> On Tue, Jul 21, 2026 at 12:51:44PM +0200, Benjamin Drung wrote:
>>On Tue, 2026-07-21 at 10:38 +0100, Colin Watson wrote:
>>> On Sun, Jul 19, 2026 at 01:25:48AM +0200, Hefee wrote:
>>> > python3-invoke 3.0 is not compatible with fabric. As woraround please
>>> > update the dependencies.
>>> >
>>> > With python3-invoke 3.0.3+ds-1:
>>> >
>>> > % fab -H server createCsv
>>> > Traceback (most recent call last):
>>> > File "/usr/bin/fab", line 33, in <module>
>>> > sys.exit(load_entry_point('fabric==3.2.2', 'console_scripts', 'fab')())
>>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
>>> > File "/usr/lib/python3/dist-packages/invoke/program.py", line 398, in run
>>> > self.execute()
>>> > ~~~~~~~~~~~~^^
>>> > File "/usr/lib/python3/dist-packages/invoke/program.py", line 583, in
>>> > execute
>>> > executor.execute(*self.tasks)
>>> > ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
>>> > File "/usr/lib/python3/dist-packages/invoke/executor.py", line 141, in
>>> > execute
>>> > context = call.make_context(config, core_parse_result=self.core)
>>> > TypeError: ConnectionCall.make_context() got an unexpected keyword
>>> > argument 'core_parse_result'
>>> >
>>> > Downgrade to python3-invoke 2.2.0-2 resolves the issue. As workaround
>>> > until upstream fixed that - please update the dependencies against
>>> > python3-invoke << 3.0 to have a working fabric.
>>>
>>> That won't achieve anything useful. It will just make fabric
>>> uninstallable and unable to migrate to testing, which would itself be an
>>> RC bug.
>>>
>>> While this has been fixed upstream
>>> (https://github.com/fabric/fabric/commit/7fa309db9dd5dac69079c1fb83b6f579555f7d53),
>>> apparently it's "(technically) backwards incompatible"
>>> (https://github.com/fabric/fabric/commit/63f3d9bdadb7bd2c0b9eb67434a6237261e658f8).
>>> I'm not sure what's best for Debian to do here. Ideally we wouldn't
>>> have upgraded to the new invoke until fabric had a matching release.
>>> It's unfortunate that python-invoke made it to testing despite this; I
>>> guess that's because fabric currently lacks autopkgtests.
>>>
>>> CCing bdrung, who uploaded the new python-invoke.
>>
>>That's very unfortunately. After looking at the fabric upstream repo I
>>think the best way forward is:
>>
>>* package the upstream git main branch as 4.0.0~git$date
>>* run the upstream tests during build and as autopkgtest to avoid this
>>(invoke migrating and breaking fabric) to happen again
>>
>>What do you think?
>
> Maybe we should consult with upstream (CCed) before doing that. I
> notice that there haven't been any changes to git in a few months; is
> there a plan for a 4.0 release soon?
>
> (Another possibility would be to revert python-invoke to 2.x in Debian
> for now, I guess.)
Another possibility, which I will embark on now, is to ship the fix as a
patch in the Debian package directly. A colleague tested it locally and
it seems to Work Fine, so I'm confident this will fix the issue.
The only problem now as I just uploaded 3.2.3 which tweaks the
dependencies to conflict with invoke 3.x, which would have been a fine
idea a while ago as it would have kept users from upgrading to invoke by
mistake, but now will make things more complicated. I will figure this
out.
This is also filed upstream in:
https://github.com/fabric/fabric/issues/2376
I have removed Jeff from CCs. He's granted me maintainer access on the
GitHub repo and I'm trying to reduce noise in his mailbox. I've opened
up a thread about that with him privately and I'm confident I will get a
response within a couple weeks which I will relay here.
A.
--
When I came back to the United States, I decided that if you could use
propaganda for war, you could certainly use it for peace. And
"propaganda" got to be a bad word because of the Germans using it, so
what I did was to try and find some other words so we found the words
"public relations". - Edward Bernays
