@rob-hills : ugh i’m quite puzzled by this issue … assuming the migration is still there and you didnt skip it yet, can you share the output of :
yunohost tools migrations list --pending
(and in particular the block regarding migration 24, we should see its mode is “auto”)
@Aleks thanks for your reply.
I’ve not skipped or run the migration yet. Here is the output:
sudo yunohost tools migrations list --pending
migrations:
description: Repair python app after bullseye migration
disclaimer: Following the upgrade to Debian Bullseye, some Python applications needs to be partially rebuilt to get converted to the new Python version shipped in Debian (in technical terms: what's called the 'virtualenv' needs to be recreated). In the meantime, those Python applications may not work. YunoHost can attempt to rebuild the virtualenv for some of those, as detailed below. For other apps, or if the rebuild attempt fails, you will need to manually force an upgrade for those apps.
id: 0024_rebuild_python_venv
mode: auto
name: rebuild_python_venv
number: 24
state: pending
So, it appears that the terminal command produces the expected output (a full text disclaimer). Also, its mode is indeed “Auto” though I’m not sure what that means.
It means it should have run automatically (and actually do nothing … because venv freezes are generated during the bullseye migration since recently, but because you made the migration before this was introduce, there’s nothing to do in your case)
Maybe there was a failure trying to run the migration right after the last upgrade ? What if you look in Tools > Logs in the webadmin, do you see a migration attempt that would have failed ?
Thanks for your prompt reply. I’ve just checked the Tools > Logs in Webadmin and the only failures there are “Let’s Encrypt” certificate install attempts for some of my non-standard domains and which I’ve since resolved. Nothing about a failed migration.
I am part way through making copies of my two virtualenvs before trying to run the migration. But from your comment about the migration doing nothing in my case, it seems I don’t need to do that.
Well what I didnt say is that you may need to manually recreate virtualenvs 
Though if we’re talking about virtualenvs for yunohost apps, the recommended course of action is to force-upgrade those apps with yunohost app upgrade foobar --force (with foobar to be replaced by the name of the app)
Anyway, back to the original question of “why didnt it run automatically”, let’s maybe try to run it and see if that works … (and by working, again, it should be equal to “doing nothing” but just flagging the migration as done 
)
Neither of my virtualenvs are for apps installed via YunoHost.
Do you recommend I run the Migration from the Webadmin or the command line or does it not matter which?
Running from the command line is simpler to debug just in case it miserably fails for some unexpected reason
All seems good!
admin@server:~$ sudo yunohost tools migrations run --accept-disclaimer
Info: Running migration 0024_rebuild_python_venv...
Success! Migration 0024_rebuild_python_venv completed
Congratulations and I’m in chaos. The packages cannot be installed at all 
'Trotzdem Ihnen viel Spaß und Erfolg weiterhin.
Nevertheless, have fun and continued success.
@rob-hills : ah, now that I see the command written I understand … the migration did not run automatically after the upgrade despite that it’s in “auto” mode because there’s a non-empty disclaimer … That’s where the bug comes from, the disclaimer should be empty … !
Cheers !
Interestingly, the disclaimer was empty in the WebAdmin interface (see my original screenshot above), but I was still prompted to agree to it!
The disclaimer was actually not empty in the webadmin, it was just a string ID (migration_0024...disclaimer_base) which is kinda puzzling. Not sure why, but maybe the webadmin code doesn’t expect disclaimers for migrations flagged as auto and hence doesnt render the string properly for some reason, that would make sense