I am not sure if I did something wrong.
But I just did an upgrade from 63 → 65 using the same method as normal and now the console says:
A new version of Mail-in-a-Box is available. You are running version 03145542076c80ab2af3a3b12b94c0da50a631fa. The latest version is v65. For upgrade instructions, see https://mailinabox.email.
Any idea what I have done or if I have broken something.
Everything seems OK.
I can see that this is the git hash of v65. So hopefully this is all fine. but not sure why this happened.
Just came here to report the same. It’s also still working after a reboot, so probably nothing (major) got broken.
You also have a truncated reference to the git hash in the install screen when updating. A small glitch somewhere in the references. Everything is working fine here also
Same problem encountered as well.
A new version of Mail-in-a-Box is available. You are running version 03145542076c80ab2af3a3b12b94c0da50a631fa
same here
You are running version 03145542076c80ab2af3a3b12b94c0da50a631fa
I also can confirm the bug.
The system-check says:
A new version of Mail-in-a-Box is available. You are running version 03145542076c80ab2af3a3b12b94c0da50a631fa. The latest version is v65. For upgrade instructions, see https://mailinabox.email.
Ok what’s the fix? Simple or Wait till updated release?
I’m showing the same issue on my end, admin panel tells me to update to v65, but v64 showing as latest release on Github. I see the notes in the Changelog from yesterday for v65 https://github.com/mail-in-a-box/mailinabox/blob/main/CHANGELOG.md
I’ve added a comment to the github mailinbox issue regarding this, but my guess is that the version is not appearing as expected, because the ‘v65’ tag is a lightweight tag and not an annotated tag, and the use of git describe ... is giving us the results we’re seeing.
Think you are right @dms
git describe
fatal: No annotated tags can describe ‘03145542076c80ab2af3a3b12b94c0da50a631fa’.
However, there were unannotated tags: try --tags.
git describe --tags
v65
Here’s a workaround to remove the alert from your webpage:
edit ~/mailinabox/management/status_checks.py
change line 919 from
tag = shell(“check_output”, [“/usr/bin/git”, “describe”, “–always”, “–abbrev=0”], env={“GIT_DIR”: os.path.join(miab_dir, ‘.git’)}).strip()
to
tag = shell(“check_output”, [“/usr/bin/git”, “describe”, “–tags”, “–always”, “–abbrev=0”], env={“GIT_DIR”: os.path.join(miab_dir, ‘.git’)}).strip()
I restarted my box after that and all was good but you should also be able to fix it with:
systemctl restart mailinabox.service
So, what I did instead of changing the code was to change the tag in /root/mailinabox to be annotated. You can do this with the following command (to be run as root from the /root/mailinabox directory):
date="$(git show $tag --format=%aD | head -1)"
GIT_COMMITTER_DATE="$date" git tag -a -f v65 v65
which will put you into an editor to write the annotation.
After that, "git describe --always" returns “v65”
As I see it, the problem is not the admin notification, but the fact that it is not upgrading from v64 to v65.
It is upgraded. This is simply a matter of incorrect output.
Didn’t work for me I just got Something’s gone wrong message, reverted back to original setting.
Thanks anyway
Worked thanks very much ;O)
I did this, and a “git status” shows:
HEAD detached at v65
Is that going go to cause problems during the next upgrade? (Did I just break things for the next upgrade?)
To be honest, I’m not 100% sure what will happen during the next upgrade, but I’m 90% sure it will make no difference and the upgrade won’t notice we changed a tag from lightweight to annotated, and will happily go about its business.
My reason for thinking that is because running "git status" in /root/mailinabox still shows the the working tree as being clean. If I had changed a file in the repo, on the other hand, the upgrade would complain because the working tree is not clean and refuse to continue until I reverted the change (at least that was my experience when I temporarily changed the backup.py file to deal with the duplicity issue we recently encountered).
If the next upgrade does complain about the tag being annotated, I’ll revert the tag to match upstream. I believe this can be done by deleting the tag and pulling from upstream (that works on my test setup).