Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Otto Kekäläinen]

Hello!

2018-03-17 12:04 GMT+02:00 Adam Conrad :
> On Fri, Mar 16, 2018 at 12:35:42AM +, Robie Basak wrote:
>> On Fri, Mar 16, 2018 at 12:01:11AM +0200, Otto Kekäläinen wrote:
>>
>> > And keep the epoch forever. No thanks.
>
> Epochs happen.  A lot.  Here's a quick check of my installed packages:
>
> $ dpkg -l | awk '/^i/ {print $3}' | grep '.:' | wc -l
> 415
>
> I understand that there's a certain "elegance" in always making sure
> versions go forward and epochs never happen as a result, but when that
> doesn't happen, life goes on.

Epochs are quite common, yes, but most examples I've looked at have
had so for a valid reason and in a planned way.

Examples:
- xorg-server, ntfs-3g: was 1:.. already since the first upload to Debian
- git-core: use epoch 1 to supersede gitweb-264 package version
- ruby-defaults: introduced epoch to move from version 4.9 to 1.9
- virt-manager: introduced epoch to move from 0.9 to 0.10
- vim: change package version numbering so that new upstream patches
don't generate new source packages

The only case of "oops, nevermind" I saw was in nautilus
(1:3.24.1-0ubuntu1) with changelog entry "set epoch number (which was
added by error)". This package is supposed to be different from
Debian, so the epoch does a sensible function there despite the
changelog entry.

There are however also other cases where the epoch was introduced for
a stupid reason and should have not been done, like the case "add
epoch since upload is rejected with different orig.tar.gz..." in plum
1:2.33.1-0.1

On debian-devel@ there was recently more discussions on stupid epoch
bumps, but it ended up in not trying to stop it. There was a bug
report about forcing epoch bumps through NEW but it got dismissed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860797

> As a side note, this whole "10.1.29+really10.1.28" business could be
> avoided by moving to 10.1.30, which we seem to be shipping in arful's
> security pocket.  I suspect I'm missing context here, but is there a
> reason that .30 isn't suitable (and, if so, should we be informing the
> security team)?

The way forward here I guess is that
1) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860797 or
something similar should be implemented to stop developers form
uploading epochs too easily, as they should happen very rarely and it
cannot be revoked
2) mariadb-10.3 1:10.3.6-1 should be uploaded to Debian to at least
stop all current 10.3 and 10.2 and 10.1.29+ installs from downgrading.
This is the most effective remedy that can be done in this situation
to minimize the fallout.

I might look into uploading mariadb-10.3 if I have energy to debug all
epoch fallout issues in the control file, but it seems unlikely it
would make into Ubuntu 18.04 since freeze and release is upon us.

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Robie Basak]

[adding pkg-mysql-maint; see
https://lists.ubuntu.com/archives/ubuntu-quality/2018-March/007069.html
for previous thread posts]

Hi Otto,

On Fri, Mar 23, 2018 at 12:29:49PM +, Robie Basak wrote:
> I guess that the discussion is complete now? How do you want to proceed?
> 
> Will you upload a src:mariadb-10.1 update to Debian? If not, I suppose I
> need to upload a src:mariadb-10.1 upload to Ubuntu to fix it for Bionic
> at least?

I've just looked at src:mariadb-10.1 1:10.1.29-6 in Bionic with a view
to uploading a revert to (effectively) 10.1.28-2 as you requested.

I only found two changes between those two versions that I think are
relevant:

 1) The epoch bump.

 2) The dropping of the mariadb-test binary package (commit 27202e3,
Debian bug #881898).

All other changes seem to be related to general bugfixes and
adjustments for upstream microreleases of 10.1, and I don't see any
problem with keeping these.

Since I can't revert the epoch, the only relevant change I can consider
is the dropping of the mariadb-test binary package, for which I think a
straightforward upload of a git revert of 27202e3 using a version of
1:10.1.29-7 (or 1:10.1.29-6ubuntu1 if Ubuntu-only) should be fine.

Without restoring mariadb-test, we have a dep8 failure that Steve had to
force-badtest to in Ubuntu get 1:10.1.29-6 into the Bionic release
pocket. I believe the same problem equally affects Debian.

Since both Debian and Ubuntu have removed src:mariadb-10.2, I think it
makes sense to restore mariadb-test in src:mariadb-10.1 in Debian and
sync this over to Ubuntu, assuming that this will actually fix the dep8
tests in both distributions.

In Ubuntu's upcoming Bionic release this should also help with future
microrelease updates.

I propose to:

  1) Verify as best as I can that dep8 will actually pass again with
 this change.

  2) Push a revert of 27202e3 to the master branch on salsa.

  3) Either upload to Debian and sync to Ubuntu, or upload a delta in Ubuntu
 carrying the same change, depending on whether I can get
 sponsorship for the Debian upload in time.

I believe this will clean up what we need for MariaDB packaging for both
Debian and Ubuntu. The only thing remaining will be the epoch bump,
which as discussed previously we cannot revert.

Does anyone have any alternative proposal to proceed? Otto, I know you
would prefer to revert the epoch, but I think it's safe to say that this
has or will be declined by Debian ftpmasters and Ubuntu archive admins,
so IMHO we need to consider that option closed now and proceed without.

Robie


signature.asc
Description: PGP signature
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Robie Basak]

Hi Otto,

I guess that the discussion is complete now? How do you want to proceed?

Will you upload a src:mariadb-10.1 update to Debian? If not, I suppose I
need to upload a src:mariadb-10.1 upload to Ubuntu to fix it for Bionic
at least?

Robie


signature.asc
Description: PGP signature
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Otto Kekäläinen]

Thanks Robie for your comment. Comments to them below:

2018-03-15 15:47 GMT+02:00 Robie Basak :
..
> Unfortunately, to the best of my knowledge we don't ever try to make
> this kind of revert in the archive because of the knock-on effects it'll
> have everywhere else. I believe both Debian and Ubuntu will hold the
> same opinion on this: now that the epoch bump has been published, we
> will have to live with it.

I don't think it has unacceptable knock-on effects if reverted. On the
contrary, if not reverted, the knock-on effects will be massive.

> I suggest that we:
>
> 1. Ask the Ubuntu archive admins to remove src:mariadb-10.2 (10.2.7-1)
> from the archive. I see that Debian has already done this, so Debian and
> Ubuntu will be the same.

Yes, Ubuntu should follow Debian there.

> 2. Re-publish exactly your known good version mariadb-10.1 10.1.28-2 but
> bump the version string to 1:10.1.29-7really10.1.28. The binaries that
> will build from this will all have version 1:10.1.29-7really10.1.28
> which is higher than all binaries previously published, so should
> publish fine. I believe this would be appropriate to fix the mess in
> Debian too. Therefore you can do this in Debian and we can sync it over
> in Ubuntu. This doesn't need to wait for step 1, but it might be wise to
> have the archive admins review this entire plan first.

For the record, I will not have my name associated with any
1:10.1.29-x versions, and I will not respond to bug reports from
people running that version, or any later version that inherits its
problems.

There is quite a lot of challenges with packaging such a big package
already, but I remain keen in working on it because it results in a
technically beautiful result and as open source if benefits a very
large crowd of users. If the technology has permanently ugly elements
and the crowd is an angry one, I don't see the point in continuing the
effort.

> 3. Once the dust has settled, you can prepare a 1:10.1.28-8 or a
> 1:10.1.29-1 (if that exists) or a 1:10.2.7-1 at your leisure, and they
> can go into Bionic according to the normal freeze requirements. Again,
> you can continue uploading to Debian and we can sync over to Ubuntu as
> appropriate.

And keep the epoch forever. No thanks.

> Consequences:
>
> 4. Users already on the broken mariadb-10.2 will end up "upgrading" to
> mariadb-10.1, which isn't a supported data migration path as you point
> out. They will need to fix their systems manually - but as they were
> using pre-release software, I think this is acceptable even if
> unfortunate.

Yes, correct. And this is already happening and reverting to 10.1.28-1
would make no difference for them in short term, but in long term they
would get 10.3 etc nicely installed and running.

> 5. Everyone shipping MariaDB packages, including upstream, PPAs, etc,
> will need to follow the epoch bump in order for everything to work
> smoothly. This is, AIUI, unavoidable now. If a PPA does not do this,
> then users will end up downgraded, with a failed data migration and
> therefore broken. This is again unfortunate but I think acceptable: this
> is the risk of following a PPA.

I don't think PPA = unstable crap. Nor that we can or should assume
that all 3rd party repositories are temporary or unstable or something
like that. There are perfectly valid 3rd party repositories our there
that are used in production systems. Requiring the world to adapt to
this situation I think is a very self-centric approach and maybe even
against the Ubuntu spirit.

I think Debian unstable, Debian testing and all Ubuntu alpha and beta
releases imply to users that they might have bugs and might change.
Currently this bug has only lived in such pockets and thus it would
make sense to fix it before it gets out in a release labeled stable.

> Options I'm deliberately opining against:
>
> 6. Going backwards in version numbers. AIUI, Launchpad will not permit
> this anyway and nor will Debian ftpmasters.

Underlying is a database that can have records manually fixed to close
this "bug". I do understand that mu request here is exceptional,
though.

I could go around the systems by changing the name of the package, but
that would be a hack as stupid as introducing the epoch in the first
place. My hope is for reverting the package to the state before bad
uploads.

> 7. Directly fixing mariadb-10.2 without reverting mariadb-10.1 first by
> bumping it. Since Bionic is past feature freeze and mariadb-10.2 has
> always been broken, I think it's prudent to get the archive into a
> releaseable state first, and only then looking at bumping major
> versions. IMHO (but this is the release team's decision and not mine),
> we should consider 10.2 to have missed feature freeze since it has
> always been broken. Making 10.2 or 10.3 work in the archive for Bionic
> now should be breaking feature freeze so should follow the usual
> exception process. In any case, re-publishing mariadb-10.1 as I 

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Otto Kekäläinen]

2018-03-16 2:58 GMT+02:00 Robie Basak :
>> Yes, once an epoch is in the wild in Debian or Ubuntu, it's irreversible.
>> Others will simply need to follow suit.
>>
>> > If a PPA does not do this, then users will end up downgraded, with a
>> > failed data migration and therefore broken.  This is again unfortunate but
>> > I think acceptable: this is the risk of following a PPA.
>>
>> It's not clear to me that there is any risk of failed data migration, since
>> the versions involved are 10.1.29 and 10.1.28 - 10.2.7 is not in play.
>
> 10.2.x is in play in upstream's 10.2 apt repository for Artful, for
> example. A user who upgrades from there to Bionic will end up going
> backwards to 1:10.1.x[1]. To avoid this, I think external repositories
> will need to republish 10.2 and 10.3 with an epoch bump to all series,
> including for Artful, as well as for Bionic. Then the user will upgrade
> to 1:10.2.x while still on Artful, and so apt will then not attempt to
> "upgrade" to 1:10.1.x on upgrade to Bionic.

I think it is unfair that one single bad upload in Debian results in a
situation where all repositories in the world need to start using
epoch in all versions of MariaDB 10.1, 10.2, 10.3 (and any future
version) right now, then we assume everybody will upgrade their
packages to get a 1:10.x on their system just to prevent that a later
upgrade to Bionic will not suddenly downgrade their current 10.3 or
10.2 or 10.1 version to 1:10.1.x. In addition the all packaging
adopting this epoch, all control file stanzas referencing later than
or earlier than X will need to be refactored to say "requirement is
MariaDB 10.2 or newer, but not 1:10.1, and then 1:10.2 then again"
etc. I have not invested time in doing in figuring out the exact
details, so this example was just to illustrate the point, and might
not be fully correct.

I have owned several pre-installed Ubuntu laptops and all of them come
with their custom repositories pre-installed in
/etc/apt/sources.list.d/, which install custom versions of Linux
modules or whatever that are absolute requirements for those laptops
to fully work. There is no notion of "beta quality" or "risk" there.
When you for example browse Docker or LXC images they categorically
use 3rd party repositories to provide users with selected newer
software. I know there are _at least_ thousands of users who are
running in production Ubuntu version X plus newer releases of the LAMP
stack components. All of those 3rd party repos are production quality
and users most probably don't view them as a "risk" and a bad thing
they should not be using. Telling them that if they get hurt it is
their own fault is something I don't feel is the right thing to do. I
am now being told that the error has happened, and I and the rest of
the world just needs to "deal with it", but I find that mentally very
hard.

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Adam Conrad]

On Fri, Mar 16, 2018 at 12:35:42AM +, Robie Basak wrote:
> On Fri, Mar 16, 2018 at 12:01:11AM +0200, Otto Kekäläinen wrote:
> 
> > And keep the epoch forever. No thanks.

Epochs happen.  A lot.  Here's a quick check of my installed packages:

$ dpkg -l | awk '/^i/ {print $3}' | grep '.:' | wc -l
415

I understand that there's a certain "elegance" in always making sure
versions go forward and epochs never happen as a result, but when that
doesn't happen, life goes on.

As a side note, this whole "10.1.29+really10.1.28" business could be
avoided by moving to 10.1.30, which we seem to be shipping in arful's
security pocket.  I suspect I'm missing context here, but is there a
reason that .30 isn't suitable (and, if so, should we be informing the
security team)?

... Adam

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Robie Basak]

On Fri, Mar 16, 2018 at 09:43:35AM +0200, Otto Kekäläinen wrote:
> I have owned several pre-installed Ubuntu laptops and all of them come
> with their custom repositories pre-installed in
> /etc/apt/sources.list.d/, which install custom versions of Linux
> modules or whatever that are absolute requirements for those laptops
> to fully work. There is no notion of "beta quality" or "risk" there.
> When you for example browse Docker or LXC images they categorically
> use 3rd party repositories to provide users with selected newer
> software. I know there are _at least_ thousands of users who are
> running in production Ubuntu version X plus newer releases of the LAMP
> stack components. All of those 3rd party repos are production quality
> and users most probably don't view them as a "risk" and a bad thing
> they should not be using. Telling them that if they get hurt it is
> their own fault is something I don't feel is the right thing to do. I

It's not their own fault certainly, because as you point out many guides
out there in the community advise this. It is the fault of the community
perhaps for allowing this to have become the status quo.

Nevertheless, this is how it is. Third party repositories are
effectively a hack upon apt's design. This is why it is preferable to
use a distribution's archive over a third party apt repository.

The risk is substantially mitigated just by third party repositories
"keeping up" with changes in the distribution though. The particular
problem we are facing today can be completely eliminated by a well
maintained third party repository.

> their own fault is something I don't feel is the right thing to do. I
> am now being told that the error has happened, and I and the rest of
> the world just needs to "deal with it", but I find that mentally very
> hard.

Unfortunately this decision was made for you at the time the epoch bump
was signed and uploaded.

Robie


signature.asc
Description: PGP signature
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Robie Basak]

On Fri, Mar 16, 2018 at 12:01:11AM +0200, Otto Kekäläinen wrote:

[I've rearranged the quote ordering to bring common topics together]

> I don't think it has unacceptable knock-on effects if reverted. On the
> contrary, if not reverted, the knock-on effects will be massive.

[...]

> And keep the epoch forever. No thanks.

[...]

> Underlying is a database that can have records manually fixed to close
> this "bug". I do understand that mu request here is exceptional,
> though.

I appreciate that we all wish the epoch bump didn't happen. Reverting,
even if it were advisable, is not my decision. I think the implications
are worse than you think - for example for derivatives using automation
to follow along. In any case, I believe that this type of request has
been refused in the past for worse situations than this. I don't think
it'll happen, so to make progress I think we need to accept this and
deal with it.

> For the record, I will not have my name associated with any
> 1:10.1.29-x versions, and I will not respond to bug reports from
> people running that version, or any later version that inherits its
> problems.
> 
> There is quite a lot of challenges with packaging such a big package
> already, but I remain keen in working on it because it results in a
> technically beautiful result and as open source if benefits a very
> large crowd of users. If the technology has permanently ugly elements
> and the crowd is an angry one, I don't see the point in continuing the
> effort.

What are the problems that will be inherited by keeping the epoch? How
do you think these will be prevented by reverting the epoch bump?

I think that we all understand that you weren't involved in the creating
this situation and we don't associate you with causing the problem. I
think it can be made clear via the changelog in future uploads what you
are and are not responsible for. Nobody can force you to prepare any
upload of course, and we will remain grateful for all the work you've
done already if you feel compelled to stop participating.

> > 5. Everyone shipping MariaDB packages, including upstream, PPAs, etc,
> > will need to follow the epoch bump in order for everything to work
> > smoothly. This is, AIUI, unavoidable now. If a PPA does not do this,
> > then users will end up downgraded, with a failed data migration and
> > therefore broken. This is again unfortunate but I think acceptable: this
> > is the risk of following a PPA.
> 
> I don't think PPA = unstable crap. Nor that we can or should assume
> that all 3rd party repositories are temporary or unstable or something
> like that. There are perfectly valid 3rd party repositories our there
> that are used in production systems.

The situation we're in now is exactly why using PPAs and other third
party apt repositories can be risky for users.

>  Requiring the world to adapt to
> this situation I think is a very self-centric approach and maybe even
> against the Ubuntu spirit.

Requiring the world to adapt to this situation *is a consequence of
apt's design*, and not of any decision we're making today. The problem
is that external package repositories overload the distribution
archive's package and version namespace. The only sane way of dealing
with this is to ask (and/or expect) them to keep up. This is
unfortunate, but it's the consequence of the way that apt works, which
is why it is dangerous to use any external apt repository or PPA that
does not keep up or refuses to keep up. There is no other reasonable
solution. Going backwards in package versions causes other problems.

Regardless, it's easy for all external repositories to deal with this.
They just need to match the epoch bump. I don't think this is too
onerous.

> I think Debian unstable, Debian testing and all Ubuntu alpha and beta
> releases imply to users that they might have bugs and might change.
> Currently this bug has only lived in such pockets and thus it would
> make sense to fix it before it gets out in a release labeled stable.

Testers still have a reasonable expectation that upgrading will, after
release, bring them up to the stable release package versions. Going
backwards in versions will break this. What if, for example, a tester
has a broken mysqld from src:mariadb-10.1 1:10.1.29-6, has disabled the
service manually, but still relies on libmariadbclient18 1:10.1.29-6? A
future security update after Bionic's release given version
10.1.something will never be received.

There are also other consumers of package publications. Raspbian's
Autoforwardportergit comes to mind. I don't know if it will be affected.
It doesn't matter to my point, since you'd have to find every instance
of this type of consumption and verify that it won't break by package
versions going backwards before you can claim that reverting would be a
less worse option. On the other hand, accepting the epoch bump and only
publishing versions higher than already published, including in 

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Steve Langasek]

Hello,

On Thu, Mar 15, 2018 at 01:47:39PM +, Robie Basak wrote:

> On Sat, Mar 10, 2018 at 04:23:10PM +0200, Otto Kekäläinen wrote:
> > ## Request

> > In the name of avoiding a quality catastrophe, please
> > - remove from the Ubuntu Bionic repos the source package and all
> > binary packages of mariadb-10.1 version 1:10.1.29-6 and all remnants
> > of mariadb-10.2
> > - re-introduce last known good version mariadb-10.1 10.1.28-2
> > - add an Ubuntu revision so the package stops syncing from Debian
> > - reset the Ubuntu archive database records related to this package so
> > the systems accept 10.1.28-2 and forgets about the newer versions

> Unfortunately, to the best of my knowledge we don't ever try to make
> this kind of revert in the archive because of the knock-on effects it'll
> have everywhere else. I believe both Debian and Ubuntu will hold the
> same opinion on this: now that the epoch bump has been published, we
> will have to live with it.

The Debian archive simply does not support rolling version numbers
backwards, and while it would be possible to do so in Launchpad, this
doesn't change the behavior of the package manager clients.  There is no way
to make the whole system "forget" about newer versions if those versions are
already deployed to end installs, which will be the case for at least some
pre-release consumers of bionic.

So no, I don't think we are going to remove the existing packages from the
bionic archive and roll back the version number.

We would also not add an Ubuntu revision solely to keep the package from
syncing from Debian.  At the moment, we are past Feature Freeze (and thus
past Debian Import Freeze), so the package would not be automatically
updated anyway until after the 18.04 release; and a delta added to block
autosyncing does not communicate when it would again be acceptable to sync
(or why it isn't).

A more suitable path forward, that works for both Debian and Ubuntu:

 - The maintainer uploads to Debian unstable whatever is the correct and
   releasable version of mariadb, with a version number >= the current
   versions there (options: 2:10.1.28-3; 1:10.1.29+really.10.1.28-1)
 - The maintainer requests a sync of this new version into Ubuntu bionic
 - Everything moves forward.


> I suggest that we:

> 1. Ask the Ubuntu archive admins to remove src:mariadb-10.2 (10.2.7-1)
> from the archive. I see that Debian has already done this, so Debian and
> Ubuntu will be the same.

This is now done.  (I took this thread as an excuse to process recent Debian
removals in bionic; no further paperwork required.)

> 2. Re-publish exactly your known good version mariadb-10.1 10.1.28-2 but
> bump the version string to 1:10.1.29-7really10.1.28. The binaries that
> will build from this will all have version 1:10.1.29-7really10.1.28
> which is higher than all binaries previously published, so should
> publish fine. I believe this would be appropriate to fix the mess in
> Debian too. Therefore you can do this in Debian and we can sync it over
> in Ubuntu. This doesn't need to wait for step 1, but it might be wise to
> have the archive admins review this entire plan first.

This corresponds to my suggestion above.

> 3. Once the dust has settled, you can prepare a 1:10.1.28-8 or a
> 1:10.1.29-1 (if that exists) or a 1:10.2.7-1 at your leisure, and they
> can go into Bionic according to the normal freeze requirements. Again,
> you can continue uploading to Debian and we can sync over to Ubuntu as
> appropriate.

1:10.1.28-8 is not an option in this scenario because 1:10.1.29-6 is already
published.  But in general, yes.

> Consequences:

> 4. Users already on the broken mariadb-10.2 will end up "upgrading" to
> mariadb-10.1, which isn't a supported data migration path as you point
> out. They will need to fix their systems manually - but as they were
> using pre-release software, I think this is acceptable even if
> unfortunate.

There is no broken mariadb-10.2 in Ubuntu; this package never built from
source (except on s390x, and was rejected at binary new).  So there is no
upgrade issue for mariadb-10.2 for us.

> 5. Everyone shipping MariaDB packages, including upstream, PPAs, etc,
> will need to follow the epoch bump in order for everything to work
> smoothly. This is, AIUI, unavoidable now.

Yes, once an epoch is in the wild in Debian or Ubuntu, it's irreversible. 
Others will simply need to follow suit.

> If a PPA does not do this, then users will end up downgraded, with a
> failed data migration and therefore broken.  This is again unfortunate but
> I think acceptable: this is the risk of following a PPA.

It's not clear to me that there is any risk of failed data migration, since
the versions involved are 10.1.29 and 10.1.28 - 10.2.7 is not in play.

> Options I'm deliberately opining against:

> 6. Going backwards in version numbers. AIUI, Launchpad will not permit
> this anyway and nor will Debian ftpmasters.

> 7. Directly fixing mariadb-10.2 without reverting 

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Jeremy Bicha]

On Thu, Mar 15, 2018 at 9:47 AM, Robie Basak  wrote:
> Does this plan (steps 1 to 3 above) seem reasonable to everyone?

It sounds reasonable to me. Thank you for taking the time to prepare
this proposal.

Jeremy Bicha

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Jeremy Bicha]

On Thu, Mar 15, 2018 at 5:40 PM, Otto Kekäläinen  wrote:
> The main point here is not the corner cases of somebody running Debian
> unstable, testing, Ubuntu alpha, beta or so, but what is expected to
> happen when Bionic is released and real production machines will start
> upgrading to Bionic. Those numbers are big, and I expect massive
> problems.

I feel that you're missing the point that Robie and I are trying to communicate.

What is your plan to fix Debian? Have you made this "exceptional"
proposal to the Debian FTP Masters yet?

Thanks,
Jeremy Bicha

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Otto Kekäläinen]

Hello!

Thanks for the reply and for including a more appropriate team as recipient.

Replies inline:


2018-03-11 15:35 GMT+02:00 Jeremy Bicha :
> I'm replying to this email but I wasn't subscribed to that list:
> https://lists.ubuntu.com/archives/ubuntu-quality/2018-March/007069.html
>
> Please send replies to ubuntu-release.
>
> Otto, thanks for taking the time to email us. I am not on the Ubuntu
> Release Team but here are my thoughts.
>
> I don't like your proposal to drop the epoch. That will cause everyone
> already using Ubuntu 18.04 (which is now in Beta) to have a version of
> mariabdb installed that will not get any updates (for security or bug
> fixes). Ubuntu isn't that much different than Debian here. You can't
> really remove the epoch in Debian and I don't see how you can
> reasonably remove it from Ubuntu either.

Yes, those who are already on Ubuntu 18:04 will slightly suffer, but
they know they are running a beta and the procedure for them to
recover is quite easy, just reinstall the package using the latest
MariaDB package version in the repository. Since they reinstall
another version of 10.1.x there would be no "downgrade" type of issues
and it would be completely painless.

I think it is much better to have a slight hickup in a beta release
than go into production and have massive issues for X thousand or
million users.

> It feels to me like it might be better to move Ubuntu 18.04 to 10.2
> and completely remove the 10.1 packages.

Yes, it is better to have a newer version, but that will not remove
the epoch thing, all the those epoch related problems will remain. The
package is from my point of view now sabotaged and I cannot fix it
because of the epoch.

> Do you know when 10.3 is expected to be officially "stable"? How risky
> is it for Ubuntu 18.04 to switch to the current 10.3 RC [1] instead of
> 10.1 or 10.2?

Yes, I can upload 10.3.5 within a week if you want. I would have done
that already if I could, but I cannot, since 1:10.1.29-6 is considered
higher than 10.3.5 and Debian/Ubuntu archives would not accept the
upload.


> How long would it take to get 10.2 or 10.3 ready for Ubuntu?

I can commit to do it in one week. Note however my problem with the
epoch, I don't want to have my name on a package that prevents users
of Ubuntu 18.04 LTS in the year 2019 to upgrade to MariaDB 10.4 or in
2020 to upgrade to MariaDB 10.5 etc.


> The support lifecycle for either 10.2 or 10.3 look a lot better than
> 10.1 for Ubuntu 18.04 LTS. [2]
>
> [1] https://downloads.mariadb.org/mariadb/+releases/
> [2] https://mariadb.org/about/maintenance-policy/
>
> And one more link for reference: https://bugs.debian.org/891641

Yes, the mariadb-10.2 removal is now done in Debian. It should have
been done a lot earlier, but I didn't notice this mess earlier and
thus only now got to trying to clean up things.

- Otto

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Jeremy Bicha]

On Sun, Mar 11, 2018 at 12:54 PM, Otto Kekäläinen  wrote:
> Yes, it is better to have a newer version, but that will not remove
> the epoch thing, all the those epoch related problems will remain. The
> package is from my point of view now sabotaged and I cannot fix it
> because of the epoch.

Ok, I see. But why can't you just add the epoch to the 10.2 and 10.3
packages too?

I mean I don't see any way you'll be able to fix this in Debian
without keeping the epoch.

> Because of the epoch, anybody running for example mariadb-server version 
> 10.3.x will have
their packages either break.

mariadb 10.3 isn't in any Debian or Ubuntu release so that doesn't
really matter. If people are installing beta versions of low-level
stuff from third-party repositories, that's not really Ubuntu's
problem.

Even 10.2 isn't in any *stable* release of Debian or Ubuntu, so people
using it now have an unsupported system.

epochs do get added to packages sometimes and sometimes the epochs
didn't really need to be bumped but the Debian archive can handle
epochs. Any third-party repositories should be aware of the epochs for
relevant packages for the series they target.

Thanks,
Jeremy Bicha

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Jeremy Bicha]

I'm replying to this email but I wasn't subscribed to that list:
https://lists.ubuntu.com/archives/ubuntu-quality/2018-March/007069.html

Please send replies to ubuntu-release.

Otto, thanks for taking the time to email us. I am not on the Ubuntu
Release Team but here are my thoughts.

I don't like your proposal to drop the epoch. That will cause everyone
already using Ubuntu 18.04 (which is now in Beta) to have a version of
mariabdb installed that will not get any updates (for security or bug
fixes). Ubuntu isn't that much different than Debian here. You can't
really remove the epoch in Debian and I don't see how you can
reasonably remove it from Ubuntu either.

It feels to me like it might be better to move Ubuntu 18.04 to 10.2
and completely remove the 10.1 packages.

Do you know when 10.3 is expected to be officially "stable"? How risky
is it for Ubuntu 18.04 to switch to the current 10.3 RC [1] instead of
10.1 or 10.2?

How long would it take to get 10.2 or 10.3 ready for Ubuntu?

The support lifecycle for either 10.2 or 10.3 look a lot better than
10.1 for Ubuntu 18.04 LTS. [2]

[1] https://downloads.mariadb.org/mariadb/+releases/
[2] https://mariadb.org/about/maintenance-policy/

And one more link for reference: https://bugs.debian.org/891641

Thanks,
Jeremy Bicha

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release