FS#62658 - [bzr] Consider replacing/superseding with Breeze 3.0
Attached to Project:
Arch Linux
Opened by Emil (xexaxo) - Friday, 17 May 2019, 13:43 GMT
Last edited by freswa (frederik) - Thursday, 13 February 2020, 12:39 GMT
Opened by Emil (xexaxo) - Friday, 17 May 2019, 13:43 GMT
Last edited by freswa (frederik) - Thursday, 13 February 2020, 12:39 GMT
|
Details
Description:
Bazaar written in python2, with the latter EOL in 2020. Breezy is a re-brand/re-write that supports python3. Breezy 3.0 was released earlier this month [1], which is python2+3 compatible. As a starting point we could use the AUR package [2], plus we should consider adding an alias/symlink for backwards compatibility. From the announcement: - bzr <> brz can be aliased as they are command-line compatible - some plugins are now built-in - notably fastimport Analysis of the bzr Required-by list, please double-check: bzr-fastimport - Kill/replace with the built-in devtools flatpak-builder qtcreator (optional) - Safe: Uses the brz command directly etckeeper (optional) - Safe: ToConfirm: Uses python2 solely for bzr. Temporary disable bzr if the python plugin interface is incompatible? zim (optional) - Safe: ToConfirm: Uses the brz command directly cairo-dock (make) chinese-calendar (make) deepin-api (make) etckeeper (make) gloobus-preview (make) gsettings-qt (make) livewallpaper (make) midori (make) prometheus (make) dep (check) - Safe: ToConfirm: Uses the brz command directly [1] https://www.breezy-vcs.org/3.0.0.html [2] https://aur.archlinux.org/packages/breezy/ |
This task depends upon
Closed by freswa (frederik)
Thursday, 13 February 2020, 12:39 GMT
Reason for closing: Fixed
Additional comments about closing: breezy 3.0.2.3
Thursday, 13 February 2020, 12:39 GMT
Reason for closing: Fixed
Additional comments about closing: breezy 3.0.2.3
With a symlink from brz to bzr chinese-calendar, gsettings-qt and livewallpaper build succesfully from bzr repositories in a clean chroot.
cairo-dock, deepin-api, gloobus-preview, midori, prometheus all built with the bzr dependency removed in a clean chroot.
FS#65002- things seems to be stuck in a limbo/loop.The bzr/breeze change depends on etckeeper while the etckeeper change depends on bzr/breeze.
Perhaps something like the following could work:
- disable bzr for etckeeper, roll new package
- introduce breeze package, which provides bzr
- apply python(3) patch for etckeeper, (opt) depend on breeze, enable bzr/breeze integration
https://code.breezy-vcs.org/breezy/trunk/view/head:/doc/en/release-notes/brz-3.0.txt
```
pkgname=breezy-compat
pkgver=1
pkgrel=1
pkgdesc='symlink for replacing bzr with breezy'
arch=(any)
license=(GPL)
depends=(breezy)
conflicts=(bzr)
provides=(bzr)
package() {
cd ${pkgdir}
mkdir -p usr/bin
ln -sr usr/bin/brz usr/bin/bzr
}
```
With conflicts and replaces to ensure a) the symlink does not clash with the original bzr and b) we get stable update path, respectively.
Thanks for the work everyone.
I updated my system and said yes to the question `Replace bzr with extra/breezy? [Y/n]`.
I'm using oh-my-zsh that show me the current git branch when I'm in a git repository and this appeared in all of my local repos: `master ● bzr@59 ✚` in an orange color that usually means that I have made changes. This should only prompt `master` in green since I didn't make any changes. The most annoying thing is that now there is a delay for whatever command I type in (like `ls`) for example before giving me back the control. I even got stuck by going in one of the repositories. When I `cd repo`, press enter, I just wait forever without a new line coming to type a new command, even ctrl+c doesn't make it.
I finally downgraded it by installing the old bzr in pacman cache.
Thanks for reading, I hope my testimony can help
I use to say `yes` when oh-my-zsh prompt to ask me if I want to update it, then I guess it is up-to-date, how is it possible to know the version that I'm running? I can't find on google
I believe ohmyzsh shouldn't run bzr status inside git repositories, prezto doesn't for one. Also bzr status in a git project is really long the first time here, but a lot snappier afterwards.
High-lighting the bug in the upstream issue, is the way forward.
This way they can prioritise and address it... or better yet one could send them a fix ;-)
Working around the bug in each distribution is a non-brainer IMHO.