Packages and services available under new locations

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.