Packages and services available under new locations
-
@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
-
-
@mcostan The link looks good! Does the suggestion of @liverpoolfcfan work?
-
@liverpoolfcfan Not yet, we’re working on that!
-
@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 Thanks Christian
-
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 -
Hi @nib,
that “InRelease” message can safely be ignored.
-
@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?
-
@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.
-
@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 inrelease/2.6
and pre-final/testing is inmaster
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.
-
@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.