New component-mismatches for source universe -> main
The following universe packages have new reverse dependencies in main or got seeded. They need to get a MainInclusionReport and be promoted, or the reverse dependencies in main need to be dropped: [Reverse-Depends: Rescued from graphene, gstreamer1.0-gl (MAIN)] Please see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt for the full report. Please contact https://launchpad.net/~ubuntu-archive for problems with this notification. -- 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
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
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: xchat and hexchat
Hello, >I've added this to the TB agenda. I imagine it'll take quite a bit of >reading of the various references (I've added them to the agenda item) >so appreciate you may not be able to decide by tomorrow's meeting. just to give my quick maintainer point of view. 1) the security issues it has, are also applicable to hexchat (we will upload a fixed hexchat soon, upstream after all this debate quickly found and fixed some issues and released a new upstream tarball) this said, the security issues, can crash hexchat or xchat if you connect to a malicious server, sending non standard irc replies. (so, an exceptional use case I would say) 2) the package is not upstream maintained but it is fully Debian/Ubuntu downstream maintained. I did fix a lot of bugs, and did ~10 uploads in the archive, making it suitable again for release (in my maintainer opinion, feel free to have whatever different opinion) 3) I still need to reproduce the ctrl+i crash, I failed so far 4) see my point here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891982#35 5) having 40 patches is a complete nonsense, what is the problem if somebody is willing to maintain it that way? would it be better if I create a new "upstream" release and upload a no-patch package? it would end up in a similar result, I don't see the difference 6) I'm willing to maintain it for bionic lifespan. 7) people debating about something is not a good reason from stopping adoption or remove it (cfr: init systems war :p ) 8) both upstream/hexchat and Ubuntu/xchat maintainers opinion are biased, so, consider that here I'm just making a point for xchat, not against. just my .02$, feel free to do whatever your hat demands to do, I'll happily accept any decision you will take on this matter :) (I'll continue to maintain it in my ppa anyway, unless you ask me to stop doing it :p ) thanks for reading, (Robie, please bounce the email in case it doesn't reach the two lists) Gianfranco -- 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
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