Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
Hi Otto, On Sat, Mar 31, 2018 at 08:33:53PM +0300, Otto Kekäläinen wrote: > 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. mariadb-10.1 is an unseeded universe package; certainly if there are no library ABI changes this should be straightforward to include for 18.04, and if there are library ABI changes I would still consider it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
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-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
[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-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
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-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
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-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
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-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
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-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
Hi Steve, Your reply has made me notice a couple of mistakes in my proposal - thanks. I want to acknowledge them here to minimise confusion for anyone else reading. I've also illustrated an example of what I think is a failed migration case below together with a solution. On Thu, Mar 15, 2018 at 03:38:09PM -0700, Steve Langasek wrote: > 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. > On Thu, Mar 15, 2018 at 01:47:39PM +, Robie Basak wrote: > > I suggest that we: > > [...] > > 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. My suggestion of 1:10.1.29-7really10.1.28 can't work because the upstream version wouldn't match the tarball. Your suggestions of 2:10.1.28-3 or 1:10.1.29+really.10.1.28-1 are correct. > > 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. Ah, right. We wouldn't be to lose the "really" until 10.2 or 10.1.30. [...] > 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. Robie [1] Or does do-release-upgrade have some magic to prevent this? signature.asc Description: PGP signature -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
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 exter
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
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 maria
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
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 suggest > should be comparative
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
Hi Otto, Thank you for your efforts in resolving this. For the record, I'm not on the Ubuntu release or archive admin teams, but due to my existing involvement in the MySQL/MariaDB packaging team and in Ubuntu I guess it makes sense for me to get involved. 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. 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. 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. 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. 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. 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. 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 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 suggest should be comparatively trivial and will not impact any move to 10.2 or 10.3 whether in this cycle or in the future. Does this plan (steps 1 to 3 above) seem reasonable to everyone? Robie signature.asc Description: PGP signature -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
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-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
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-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality