Zimbra Forums

FIY, my Zimbra installation using Ian's build from techfines.online (10.0.6-ish, Ubuntu 18.04) is presenting me with apt updates of several support packages. For instance zimbra-php is being upgraded from 7.4 to 8.3, which is a major release change. Running 'apt-cache policy' shows the packages come...

Only the Zimbra license manager comes from that repo.

But, building against release tags is almost impossible, because apparently one needs to manually collect which 80 tags of sub packages are part of a particular release. There is no automated way.

The key I downloaded is valid between 2015-03-19 till 2025-03-16. I found references to that ID and similar errors years ago, so I'm guessing it's not the issue.

I agree, we can let it go. My point is more that I got that error during installation, and I wanted to show what I did to work around it.

From this: https://askubuntu.com/questions/1286545/what-commands-exactly-should-replace-the-deprecated-apt-key All of the answers so far work around the symptom ("Don't use apt-key add") but fail to address the actual problem that led to apt-key add being deprecated. The problem is not a q...

It's about the 'signed-by' directive. Key's shouldn't be loaded globally anymore.

apt-key is deprecated because of the reason I mentioned, and will be removed eventually. If private keys of any 3rd party apt source that people use are leaked, that can be used so make systems trust any package. It's far too broad. That's why signing keys are now scoped per repo.

Before, when test-upgrading, I didn't have this issue. Now, on upgrading to 10.0.6, I ran into this gpg key error: Use Zimbra's package repository [Y] y Warning: apt-key output should not be parsed (stdout is not a terminal) Importing Zimbra GPG key ERROR: Unable to retrive Zimbra GPG key for packag...

Hi Damini,

That's not my issue. My issue is the usage of numeric offset to describe a geological location. This is fundamentally incorrect.

But the time '2024-04-04 09:00 +0100' is a constant expression. The time zone +0100 still exists in April, it's just that I'm not in it. So, 09:00 +0100 is 10:00 local time in April. Let me illustrate using the command line: date --date '2024-04-04 9:00+0100' do 4 apr 2024 10:00:00 CEST And CEST as ...