Please backport bzr 2.0.2 from karmic-updates

Doing this backport will probably require a synchronized update to the bzr plugins shipped in ubuntu, primarily bzrtools, bzr-svn and bzr-gtk. The 1.3.1 versions will probably give warnings or not work well with 1.6 or later.

prevu bzr/intrepid
ll /var/cache/prevu/hardy-debs/bzr_1.6.1-1~8.04prevu1_amd64.deb
sudo apt-get update
sudo apt-get install bzr
bzr
sudo apt-get remove bzr
all ok

for the bzr plugin ( bzrtools, bzr-svn and bzr-gtk ) ... what is a good way ?

Time has passed, we'd now like a more recent version like 1.13.1.

On 03/25/2009 06:57 PM, Martin Pool wrote:
> Time has passed, we'd now like a more recent version like 1.13.1.
>
IIRC when i tried to backport Jaunty;s version to Hardy it was a python
version problem (this was done personally) this was during me trying to
get bzr-builddeb and as i recall it needs updated python packages. it
became too big of an issue for me just to get bzr-builddeb so i will
leave it up to the bzr guys :)

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

Could we get 1.14 into backports for Hardy?
The packages are in bzr's release PPA: https://launchpad.net/~bzr/+archive/ppa

Thanks!

Before doing this we have to make completely sure that the
AbsentContentFactory and related errors (see bug 360791) are fixed in
a 1.14.x release; they apparently are not totally fixed in 1.14.

On Mon, 2009-05-04 at 21:33 +0000, Martin Pool wrote:
> Before doing this we have to make completely sure that the
> AbsentContentFactory and related errors (see bug 360791) are fixed in
> a 1.14.x release; they apparently are not totally fixed in 1.14.

There are three bugs:
 - making branches with insufficient data - fixed
 - pulling into a shared repo when the graph sizes don't match with what
the server has (causes a confusing error) - in progress
 - pulling when we have ghosts - Andrew has a patch ready, not up for
review yet IIRC.

I'm not aware of any other bugs at this point.

-Rob

Somebody needs to analyse the diff between the packages in bzr's PPA and the packages in Karmic. We strongly prefer to backport from the Ubuntu development branch where possible, not from a PPA.

The process is as follows:

 * if the package in Karmic will build and work without changes (other than debian/changelog) in the target release, then we can backport that semi-automatically;
 * otherwise, a patch should be provided, preferably relative to the package in Karmic.

A proponent of this backport needs to provide a concise list in this form of what should be done for each bzr-related package.

Thanks Colin.

Any divergences between the PPA packaging and those in Karmic should
be small or accidental, and resolved generally in favor of what Karmic
does.

--
Martin <http://launchpad.net/~mbp/>

Nothing needs to be on bzr itself for this.

1.14 is now quite old, and if we're going to do any backports it should be of 2.0.x.

2.0.x has been out and quite stable for about four months, and 2.0.2 has now got into karmic-updates, through an SRU for <https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/437626>. It would be appropriate to backport from karmic-updates to hardy, intrepid, etc. I think this bug is effectively a dupe of bug 487429, asking for 2.0.2 to be backported, so I'll combine them.

I've been running 2.0.2 on my hardy server for a while, no problems detected. I've attached a debdiff, default format is set to pack-0.92 which is the default for hardy, please review.

I'd be fine with approving the backport as-is due to the launchpad incompatible usecase, but are we also interested in backporting the most popular bzr plugins (i.e bzrtools?) as well?

On 8 February 2010 16:17, Morten Kjeldgaard <email address hidden> wrote:
> I've been running 2.0.2 on my hardy server for a while, no problems
> detected. I've attached a debdiff, default format is set to pack-0.92
> which is the default for hardy, please review.

I have some real qualms about changing the default format in the
packaging, so I'm glad you mentioned that you're doing it.

Pros:
- makes it a less bumpy change for people going from 1.3 to 2.0.2; in
particular there is less risk that machines running hardy-backports
will create repositories that can't be read by machines on non-updated
hardy

Cons:
- all other things being equal it's icky to have two things called
version x that behave differently
- in particular there is an increased support version through bzr
2.0.2 being different on hardy-backports to hardy installed from the
ppa, or on karmic, or installed from source
- ... and the same burden for organizations using 2.0 on hardy and say win32
- 'bzr selftest' will probably fail because some tests make
assumptions about the default format
- if you haven't run selftest, we don't know if anything is actually
substantively broken (as opposed to an oversensitive test); there
shouldn't be anything but it kind of goes against the idea of
backports being safe

So on the whole I would suggest you don't change this.

--
Martin <http://launchpad.net/~mbp/>

On 9 February 2010 04:18, John Dong <email address hidden> wrote:
> I'd be fine with approving the backport as-is due to the launchpad
> incompatible usecase, but are we also interested in backporting the most
> popular bzr plugins (i.e bzrtools?) as well?

Yes, it would be good to take them all from karmic-updates. The ones
currently in hardy may not work with 2.0.x, in which case perhaps the
2.0.x package should conflict with them?

--
Martin <http://launchpad.net/~mbp/>

Fortunately bzr fails in a reasonable manner (for the most part) when an incompatible plugin exists. But yeah, I'd like to take more of the plugins from karmic-updates. Ideally in future Ubuntu packaging (I didn't check if it's already the case), that the plugin packages have specific enough dependencies on the version of bzr required that we wouldn't have this problem again.

Any volunteers for checking buildability of plugins from karmic-updates for hardy?

@jdong I don't know much about the backports infrastructure, but isn't there something that could automatically try to rebuild them from karmic-updates (or lucid-updates) into hardy?

Intrepid -> EOL
https://wiki.ubuntu.com/Releases

Is this meant to have an unending open bzr (Ubuntu) bugtask? I'm marking it incomplete because it doesn't seem relevant here. If we want to nominate specific releases, that seems good, but a generic one isn't worthwhile.

It looks like this bug requests a backport from Ubuntu 9.10 (Karmic Koala). However, as Karmick is no longer supported, such a backport is no longer possible.

This bug is being set to "Won't Fix". If you would still like to move forward with this backport request, please re-open the bug and adjust it to request a backport from a current release.

(This change is being made by an automated bot run by Evan Broder, who is now subscribed to the bug; if you think the change was made in error, please feel free to re-open the bug)