Packages and services available under new locations

bhuisman

As you may have already noticed, the systems on which the Z-Hub project was previously running are no longer online. Since the domain does not belong to us, we had no influence on the availability until now. In order to allow you to continue to access Z-Push (and the other projects on Z-Hub) without any problems, the data has been completely restored to a new location and is now available at the following addresses:

Z-Hub wiki: https://kb.kopano.io/display/ZP/Z-Push+Home
Package repositories: https://download.kopano.io/zhub/
Git repositories: https://stash.kopano.io/projects/ZHUB/repos/z-push/browse
Mirror of git repositories: https://github.com/Z-Hub/Z-Push

If you have any questions, please ask!

mcostan

This post is deleted!

mcostan

@bhuisman

Good morning,

I think I am doing something stupid here.

I am trying to updgrade to Debian 10 and I did the following:

add-apt-repository ‘deb https://download.kopano.io/zhub/z-push%3A/final/Debian_10/’

But, when I tried to update I then get this:

Err:8 https://download.kopano.io/zhub/z-push:/final/Debian_10 buster Release
404 Not Found [IP: 37.97.167.49 443]

The repository ‘https://download.kopano.io/zhub/z-push:/final/Debian_10 buster Release’ does not have a Release file.

liverpoolfcfan

@mcostan Looks like the baseurl in your repo is missing the trailing “/”

I don’t use Debian so I don’t know where it stores its .repo files. Suggest you search from root unless you already know where to find it.

find / -name z-push*repo

Then edit the file and make sure the baseurl=https://download.kopano.io/… ends with a “/” character

liverpoolfcfan

@bhuisman
Hi Bob,

Does Jirs external access have a new home?

Thanks
Vincent

bhuisman

@mcostan The link looks good! Does the suggestion of @liverpoolfcfan work?

bhuisman

@liverpoolfcfan Not yet, we’re working on that!

BusinessTux

@bhuisman What is the migration path in UCS? The z-push.list is generated by the Univention Kopano package. How can I adjust the repo URL so that it is not overwritten with the next update?

Thanks
Ulf

externa1

@businesstux

see here : https://help.univention.com/t/z-push-repos-new-location/17853

rg
christian

BusinessTux

@externa1 Thanks Christian

nib

Hi,

I tried to update the file /etc/apt/sources.d/z-push.list to contain:

 deb https://download.kopano.io/zhub/z-push:/final/Univention_4.3 /

instead of the (host down site) http://repo.z-push.io/ …
but now, on “apt update”, I get the message:

E: The repository 'https://download.kopano.io/zhub/z-push:/final/Univention_4.3  InRelease' is not signed.

Am I missing a particular key? How would I get it?

Thanks,
Matthias

fbartels

Hi @nib,

that “InRelease” message can safely be ignored.

laurensb

@fbartels
On https://kb.kopano.io/display/ZP/Installation is specified in the topmost table that

the final stable version “(…) corresponds to the master branch of GIT.” and that
the pre-final testing version “(…) corresponds to the release/2.6 branch in GIT.”

Shouldn’t this be reversed?

fbartels

@laurensb said in Packages and services available under new locations:

Shouldn’t this be reversed?

What makes you think that? Z-Push followed “git flow” and based on this the latest final release should be back in the main branch of the repo (which for z-push is the “master” branch.

laurensb

@fbartels said in Packages and services available under new locations:

What makes you think that? Z-Push followed “git flow” and based on this the latest final release should be back in the main branch of the repo (which for z-push is the “master” branch.

Ah, OK. Well… old-final (old-stable) is in release/2.5 branch, so it seemed logical to me that current stable would be in release/2.6 and pre-final/testing is in master branch. When current pre-final (master branch) is deemed stable enough to be released, it is branched to release/2.7 and labeled “stable”, etc. etc., so I thought to be logical.

It confuses me to see a testing version released under a release-branch.

laurensb

@fbartels
After reading the git flow article you linked it makes sense to me. I see you indeed follow the flow as outlined by Vincent Driessen and the table is thus correct.

Without detailed knowledge of said workflow the Stages table could be a bit confusing though, imho. Looking back it was the coupling of the old-stable to the release/2.5 branch of GIT that pushed me in the wrong direction. Wouldn’t it be more accurate to couple the old-stable with the master/2.5.x tags? The release branches have limited life time after all and are destined to be removed after merging to master, according to the flow model.