Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations
On Fri, May 22, 2020 at 10:57:23AM -0300, Andreas Hasenack wrote: > I don't know how the above behaves in a release upgrade either. I'm > about to test my change (but without the debconf critical prompt) in a > release upgrade. I assume such prompts are disabled by > do-release-upgrade anyway. They are definitely not disabled by do-release-upgrade. -- 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 Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations
I just did a do-release-upgrade with slapd from my ppa which exits 1 in slapd.preinst when it detects the nssov in use, and the release upgrader crashed, giving the option to send a report. Note this test doesn't have a debconf critical prompt, I don't know if that would have changed anything. On Fri, May 22, 2020 at 10:57 AM Andreas Hasenack wrote: > > Hello, > > On Fri, May 22, 2020 at 10:45 AM Robie Basak wrote: > > > > On Fri, May 22, 2020 at 02:27:48PM +0100, Robie Basak wrote: > > > We implemented a least-worst solution there, involving IIRC a > > > critical debconf prompt. I don't remember the details, but that might be > > > relevant. > > > > Looks like we made the maintainer scripts exit with a success code, but > > we always present a debconf critical note first if we haven't been able > > to complete. IIRC, we thought that this would be better than breaking a > > release upgrade. I think this is limited to dealing with things already > > being broken though - for every other type of problem we do exit > > non-zero as normal. > > > > It might still be a reasonable pattern to follow if we can't come up > > with anything better. > > The maintainer scripts in the package itself already have some cases > like this, but always followed by a critical prompt. For example, in > slapd.preinst: > (...) > db_input critical slapd/ppolicy_schema_needs_update || true > db_go || true > db_get slapd/ppolicy_schema_needs_update > if [ "$RET" = 'abort installation' ]; then > db_stop > exit 1 > fi > The above is similar to what I tested, and you would end up with > having some of the binary packages from src:openldap packages updated, > but not the bin:slapd package. It's also handling a case where a > modification is needed. In fact, in this "hook" is where I inserted my > "exit 1 in preinst" test for the nss overlay removal. > > I don't know how the above behaves in a release upgrade either. I'm > about to test my change (but without the debconf critical prompt) in a > release upgrade. I assume such prompts are disabled by > do-release-upgrade anyway. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations
Hello, On Fri, May 22, 2020 at 10:45 AM Robie Basak wrote: > > On Fri, May 22, 2020 at 02:27:48PM +0100, Robie Basak wrote: > > We implemented a least-worst solution there, involving IIRC a > > critical debconf prompt. I don't remember the details, but that might be > > relevant. > > Looks like we made the maintainer scripts exit with a success code, but > we always present a debconf critical note first if we haven't been able > to complete. IIRC, we thought that this would be better than breaking a > release upgrade. I think this is limited to dealing with things already > being broken though - for every other type of problem we do exit > non-zero as normal. > > It might still be a reasonable pattern to follow if we can't come up > with anything better. The maintainer scripts in the package itself already have some cases like this, but always followed by a critical prompt. For example, in slapd.preinst: (...) db_input critical slapd/ppolicy_schema_needs_update || true db_go || true db_get slapd/ppolicy_schema_needs_update if [ "$RET" = 'abort installation' ]; then db_stop exit 1 fi The above is similar to what I tested, and you would end up with having some of the binary packages from src:openldap packages updated, but not the bin:slapd package. It's also handling a case where a modification is needed. In fact, in this "hook" is where I inserted my "exit 1 in preinst" test for the nss overlay removal. I don't know how the above behaves in a release upgrade either. I'm about to test my change (but without the debconf critical prompt) in a release upgrade. I assume such prompts are disabled by do-release-upgrade anyway. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations
On Fri, May 22, 2020 at 02:27:48PM +0100, Robie Basak wrote: > We implemented a least-worst solution there, involving IIRC a > critical debconf prompt. I don't remember the details, but that might be > relevant. Looks like we made the maintainer scripts exit with a success code, but we always present a debconf critical note first if we haven't been able to complete. IIRC, we thought that this would be better than breaking a release upgrade. I think this is limited to dealing with things already being broken though - for every other type of problem we do exit non-zero as normal. It might still be a reasonable pattern to follow if we can't come up with anything better. signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations
Hello, thanks for your feedback On Fri, May 22, 2020 at 10:27 AM Robie Basak wrote: > > One of the options outlined > > in [4] is an exit 1 in preinst. That would leave the previous package > > installed, the daemon running, and the original functionality there, > > but the admin then has to take action as the upgrade was done half-way > > (libraries were updated, but the daemon package remains at the > > previous version). > > What would happen in the do-release-upgrade case? Would the upgrade fail > at the start (not so bad), or in the middle (really bad)? Because the > preinst won't necessarily run at the start of the release upgrade - only > at the start of a batch of package upgrades - right? I don't know, I can test that scenario. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations
On Thu, May 21, 2020 at 05:25:46PM -0300, Andreas Hasenack wrote: > Is there any pattern, or precedence, in Ubuntu or Debian, of where a > package upgrade removes a piece of the software and it cannot be > easily handled in the maintainer scripts? Unfortunately this is an area for which I don't think we've ever found a satisfactory solution. I think it's important that if an upgrade does have to leave something broken, then the user is aware of it. So some maintainer script somewhere should fail. However... MySQL packaging faced a similar because packaging does a schema upgrade but that cannot be done if mysqld cannot be started - for example if it if the database is broken with mysqld already not running before the upgrade. We implemented a least-worst solution there, involving IIRC a critical debconf prompt. I don't remember the details, but that might be relevant. > One of the options outlined > in [4] is an exit 1 in preinst. That would leave the previous package > installed, the daemon running, and the original functionality there, > but the admin then has to take action as the upgrade was done half-way > (libraries were updated, but the daemon package remains at the > previous version). What would happen in the do-release-upgrade case? Would the upgrade fail at the start (not so bad), or in the middle (really bad)? Because the preinst won't necessarily run at the start of the release upgrade - only at the start of a batch of package upgrades - right? signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[+1 maintenance] May 21, May 22
Following Lucasz's shift, here is the status after the next shift. I'm not summarizing the status here in the email, but reviving the old wiki page, and added Lucasz's open items (which are still open after my shift). See https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Status The wiki page avoids following the status in emails, avoids the hassle with discourse permissions, and is accessible to community people wanting to work on +1 maintenance as well. Things I did during my shift: - looked at failed builds without a build log, and gave those back (mostly arm64, armhf), also amd64 around 2020-05-20 12:30 UTC - retried some autopkg tests with /unknown version - pyflakes NBS (python2 removal): - upload fixed probert game-data-packager - game-data-packager, autopkgtest, cloud-init: can be ignored, alternate b-d - apt-btrfs-snapshot: Drop python2 support, build using pyflakes3. - check-all-the-things: Removed, RC issue, not in testing, no rdeps - python-lxml NBS (python2 removal) - lokalize recommends python2 packages, can be ignored for the NBS - svg-tune: can be ignored, alternate b-d - removed scap-security-guide, and rdeps openscap openscap-daemon, removed in testing for about two years. - removed aseba-plugin-blockly, scheduled for removal in Debian - remove the python-lxml binary - nulib2: filed a Debian issue for the s390x test failure. - libmath-gsl-perl: Removed, no rdeps, enabling the gsl transition. The Ubuntu fix introduced test failures, waiting on Debian for the fix. #960011. Already removed in testing. - gemma: Removed, no rdeps, enabling the gsl transition. Removed in testing - gave back the pbcopper builds, failed on some archs because of uninstallabilities package now properly ftbfs. See #959409, #960219. - volk transition: No-change rebuilds for gnss-sdr gr-gsm gnuradio gr-iio gr-osmosdr gr-radar - remove mandelbulber2, scheduled for removal in Debian, #959583, blocking gsl - fixed fig2dev autopkg test failure on 32bit archs, was blocking texlive-bin for 22 days. Filed an issue for Debian. retriggered the autopkg test - fix urwid ftbfs, filed a Debian issue. - looked at zita-convolver transition, turned out a failing pulseeffects build on armhf, given back. - gave back astropy on riscv64, blocking gsl - fix sinfo ftbfs, patch taken from the Debian BTS - fix sslsniff ftbfs, patches taken from the Debian BTS - fix spdlog ftbfs on ppc64el, symbols file. Filed Debian issue - fix another spdlog issue, referring to uninstalled header files. - force-sync biosig4c++ to resolved build deps for other packages - fix sarg ftbfs with hardening defaults and -O3, filed Debian report - fix sidplay ftbfs - fix rlvm ftbfs, fix taken from the Debian BTS Package removals: - removed python3.7, introduced again by the Debian syncs. - remove valentina binaries on s390x, ftbfs, no rdeps - remove uuagc, ftbfs, removed in testing - remove srg, ftbfs, removed in testing - remove sigx, removed in Debian testing and unstable - remove snort s390x binaries, unsatisfyable b-d's - remove universal-ctags, ftbfs, removed in testing Sorry for sending this late. I already had the status communicated to my co-worker Balint, who started his shift on Thursday. Matthias -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
