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: >

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

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

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

Hello Ubuntu QA team! ## 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

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 <adcon...@ubuntu.com>: > 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 h

Re: Bugs in built-in file explorer in Ubuntu Desktop 18.04

> > Bug no. 2: > > > > The following happens for me very frequently. > > I've been observing that for ages on Ubuntu 16.04, I think I might > even have reported it. > Unbelievable it's still unfixed in 18.04. This is most likely not an Ubuntu packaging bug, but something in the upstream Gnome

Re: Ubuntu 19.10 to 20.04 upgrade after dpkg lock

> kokoye2007@ubuntu:~$ sudo apt-get update > Reading package lists... Done > E: Could not get lock /var/lib/apt/lists/lock. It is held by process 2169 > (packagekitd) - open (11: Resource temporarily unavailable) > N: Be aware that removing the lock file is not a solution and may break > your