Re: Triage and Migration report Wed Mar 4th, 2020
On Wed, Mar 4, 2020 at 8:54 PM Bryce Harrington < bryce.harring...@canonical.com> wrote: > ## Proposed Migration ## > > I've already been working on php and ruby migration issues this past > week, so will mostly use my time to just keep plugging on those. > > However, real quick look at a couple items on the board: > > * corosync's log shows a testbed timeout for a single arch. I > re-triggered the test in case it case it's just a system issue. > > * openssh has an unsatisfiable depends on libfido2-1, which looks like a > universe package? MIR needed? > libfido2-1 | 1.3.1-1build1 | focal/universe | amd64, arm64, armhf, i386, > ppc64el, s390x > > Exists already here https://bugs.launchpad.net/ubuntu/+source/libfido2/+bug/1864439 > > > ## Bug Triage ## > > Bugs last updated on 2020-03-03 (Tuesday) > Date range identified as: "Wednesday triage" > Found 8 bugs > > LP: #1865501 - (Incomplete) [libpcap]- libpcap-dev and > derivatives missing libpcap.pc > --> Attached actual patch from the debian release with the fix > --> Targeted to affected series > --> New > > LP: #1865900 - (New)[apache2]- apache > 2.4.29-1ubuntu4.12 authentication with client certificate broken > * Appears to be a regression from the ubuntu4.12 update > * No logs or confs provided though > --> Tagged 'regression-update' > --> Mentioned it to the relevant SRU bug, LP: #1845263 > --> Requested reporter provide logs & conf > --> Incomplete > > -- > ubuntu-server mailing list > ubuntu-server@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-server > More info: https://wiki.ubuntu.com/ServerTeam -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: proposed migration duty - special php edition - v2
On Thu, Mar 5, 2020 at 6:01 AM Bryce Harrington < bryce.harring...@canonical.com> wrote: > On Wed, Mar 04, 2020 at 04:45:12PM +0100, Christian Ehrhardt wrote: > > Synced again with Bryce and Rbasak on the php-trasks-of-the-day to help. > > The following summarizes the work one and the state we left it so Bryce > can > > continue on it. > > Today I did zeroc-ice and uwsgi-plugin-php, which should hopefully get > the transition tracker down to one package: > > > https://people.canonical.com/~ubuntu-archive/transitions/html/html/html/php7.4.html > > The last package, php-mailparse, is the one with the weird .orig.orig > situation. Guessing there's a way to workaround that, just have to > figure out what that might be. > > > I've got quite some stuff done, but the very busy autopkgtest queue > stalls > > further progress right now > > > > --- > > > > #1 PHPUnit test issues in proposed migration > > - Upload phpunit and dependent fixes as identified by rbasak and me > > - Rbasak uploaded > > https://launchpad.net/ubuntu/+source/phpunit/8.5.2-1ubuntu1 > > - Then later (Depending on the former) I uploaded > > https://launchpad.net/ubuntu/+source/php-net-ldap2/2.2.0-3ubuntu3 > > > https://launchpad.net/ubuntu/+source/php-http-request2/2.3.0-1ubuntu2 > > - Depends on php-codecoverage and phpunit-global-state which after the > > efforts yesterday are both good to go (test-wise). > > - The next step would be triggering test cases with the right > components > > together. > > Actually for a first shot let's use all-proposed=1 on those. > > But for now the tests are still running, need to wait for the results > > first and then trigger those failing. > > > > TODO wait for tests to complete the first time, then trigger the failing > > ones wirth all-proposed (or global-state + php7.4 + phpunit + ..?) > > The failing ones are: > > Recheck - Still failing: composer doctrine pdepend php-codecoverage Tests didn't run yet: php-masterminds-html5 php-mikey179-vfsstream php-sabredav php-tijsverkoyen-css-to-inline-styles phpunit-comparator phpunit-global-state => Those need to be looked after, if there is a break in Fra I'll do so and let you know what I find. Failing in old, but working in the new version that I uploaded yesterday: php-httprequest2 php-net-ldap2 I've done these triggers, will recheck those later as well. > I've just now retriggered these with: > > dependencies=( > ["phpunit"]="8.5.2-1ubuntu1", > ["php7.4"]="7.4.3-4build2" > ) > > > > --- > > > > #Info > > - For bonus confusion there also is a rebuild of php7.3 ongoing at the > > moment. Also php7.4 was rebuilt (due to the ICU transition) > > => https://launchpad.net/ubuntu/+source/php7.3/7.3.15-3build1 > > => https://launchpad.net/ubuntu/+source/php7.4/7.4.3-4build2 > > So test lists will be testing 7.4/7.3 stay sharp which one you actually > > look at. > > @Bryce the intention is to remove 7.4 before Focal releases right? > > If by 7.4 you mean 7.3, then yes that's the plan. :-) > > It looks like php7.4 is in main now, so I think once php-mailparse is > squared away I could file for the php7.2 removal. If by 7.2 you mean 7.3 then that sounds good :-) Sorry couldn't resist :-P > Tomorrow maybe. > > > --- > > > > #2 php-horde ?? > > - Look at php-horde-* if they need something > > Bryce asked for the following: > > - php-horde-nag > > - php-horde-mnemo > > - php-horde-lz4 > > - php-horde-kronolith > > - php-horde-imp > > - php-horde-ansel > > - php-horde-text-filter > > - php-horde-mime > > => All of them passed migration, and the tests on php7.[34] are reset > we > > have to wait until those complete > > > > Looking at these I found in update excuses that the following two are > > hanging since 130 days. Mostly php and phpunit version issues - time to > > re-test them with the new versions we have in proposed. > > - php-horde-icalendar > > - php-horde-image > > > > TODO check new results once the new tests ran > > Thanks for tending these. > > > --- > > > > #4 Check FTBFS of php-msgpack > > Upload was from: > > > > > https://code.launchpad.net/~bryce/ubuntu/+source/php-msgpack/+git/php-msgpack/+merge/379773 > > https://launchpad.net/ubuntu/+source/php-msgpack/2.1.0beta1-0ubuntu1 > > Breaks on arm64 armhf > > Failed: Profiling perf test. [tests/035.phpt] > > Didn't I fix or at least write about that test recently? > > Yeah I had done so in: > > > https://lists.ubuntu.com/archives/ubuntu-server/2020-February/008160.html > > I already had an analysis and a fix there. > > After asking for review I got by Rafael and then uploaded the fix. > > It built fine at > > https://launchpad.net/ubuntu/+source/php-msgpack/2.1.0beta1-0ubuntu2 > > > > @Bryce - that should properly build now and resolve whatever you wanted > > to sove > > with the initial merge of that new version > > Great, thanks! > > > --- > > > > #5 rebuilds
Re: proposed migration duty - special php edition - v2
On Wed, Mar 04, 2020 at 04:45:12PM +0100, Christian Ehrhardt wrote: > Synced again with Bryce and Rbasak on the php-trasks-of-the-day to help. > The following summarizes the work one and the state we left it so Bryce can > continue on it. Today I did zeroc-ice and uwsgi-plugin-php, which should hopefully get the transition tracker down to one package: https://people.canonical.com/~ubuntu-archive/transitions/html/html/html/php7.4.html The last package, php-mailparse, is the one with the weird .orig.orig situation. Guessing there's a way to workaround that, just have to figure out what that might be. > I've got quite some stuff done, but the very busy autopkgtest queue stalls > further progress right now > > --- > > #1 PHPUnit test issues in proposed migration > - Upload phpunit and dependent fixes as identified by rbasak and me > - Rbasak uploaded > https://launchpad.net/ubuntu/+source/phpunit/8.5.2-1ubuntu1 > - Then later (Depending on the former) I uploaded > https://launchpad.net/ubuntu/+source/php-net-ldap2/2.2.0-3ubuntu3 > https://launchpad.net/ubuntu/+source/php-http-request2/2.3.0-1ubuntu2 > - Depends on php-codecoverage and phpunit-global-state which after the > efforts yesterday are both good to go (test-wise). > - The next step would be triggering test cases with the right components > together. > Actually for a first shot let's use all-proposed=1 on those. > But for now the tests are still running, need to wait for the results > first and then trigger those failing. > > TODO wait for tests to complete the first time, then trigger the failing > ones wirth all-proposed (or global-state + php7.4 + phpunit + ..?) The failing ones are: composer doctrine pdepend php-codecoverage php-httprequest2 php-masterminds-html5 php-mikey179-vfsstream php-net-ldap2 php-sabredav php-tijsverkoyen-css-to-inline-styles phpunit-comparator phpunit-global-state I've just now retriggered these with: dependencies=( ["phpunit"]="8.5.2-1ubuntu1", ["php7.4"]="7.4.3-4build2" ) > --- > > #Info > - For bonus confusion there also is a rebuild of php7.3 ongoing at the > moment. Also php7.4 was rebuilt (due to the ICU transition) > => https://launchpad.net/ubuntu/+source/php7.3/7.3.15-3build1 > => https://launchpad.net/ubuntu/+source/php7.4/7.4.3-4build2 > So test lists will be testing 7.4/7.3 stay sharp which one you actually > look at. > @Bryce the intention is to remove 7.4 before Focal releases right? If by 7.4 you mean 7.3, then yes that's the plan. :-) It looks like php7.4 is in main now, so I think once php-mailparse is squared away I could file for the php7.2 removal. Tomorrow maybe. > --- > > #2 php-horde ?? > - Look at php-horde-* if they need something > Bryce asked for the following: > - php-horde-nag > - php-horde-mnemo > - php-horde-lz4 > - php-horde-kronolith > - php-horde-imp > - php-horde-ansel > - php-horde-text-filter > - php-horde-mime > => All of them passed migration, and the tests on php7.[34] are reset we > have to wait until those complete > > Looking at these I found in update excuses that the following two are > hanging since 130 days. Mostly php and phpunit version issues - time to > re-test them with the new versions we have in proposed. > - php-horde-icalendar > - php-horde-image > > TODO check new results once the new tests ran Thanks for tending these. > --- > > #4 Check FTBFS of php-msgpack > Upload was from: > > https://code.launchpad.net/~bryce/ubuntu/+source/php-msgpack/+git/php-msgpack/+merge/379773 > https://launchpad.net/ubuntu/+source/php-msgpack/2.1.0beta1-0ubuntu1 > Breaks on arm64 armhf > Failed: Profiling perf test. [tests/035.phpt] > Didn't I fix or at least write about that test recently? > Yeah I had done so in: > https://lists.ubuntu.com/archives/ubuntu-server/2020-February/008160.html > I already had an analysis and a fix there. > After asking for review I got by Rafael and then uploaded the fix. > It built fine at > https://launchpad.net/ubuntu/+source/php-msgpack/2.1.0beta1-0ubuntu2 > > @Bryce - that should properly build now and resolve whatever you wanted > to sove > with the initial merge of that new version Great, thanks! > --- > > #5 rebuilds for migration of php7.4 > - Those are no-change rebuilds by Byce, check build results and migration: > - php-cache-lite => build ok => still waiting in queue migrated! > - php-db => build ok => still waiting in queue migrated! > - php-text-password => build ok => fails with old phpunit, triggered with > new one 1.2.1-4ubuntu1 still in proposed. Still pulling 7.3 stuff. Maybe worth trying again after some of the other things finish migrating, otherwise just need to see which of its dependencies is still in proposed... php7.3-mbstring php-mbstring php-doctrine-instantiator php-deepcopy php-phar-io-version php-phar-io-manifest
[Bug 1865340] Re: "secret" parameter not available in mod_proxy_ajp on focal
https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html seems to indicate "secret" will be available in 2.4.42: ?secret 0x0CString Supported since 2.4.42 >From https://bugzilla.redhat.com/show_bug.cgi?id=1397241, looks like redhat has had "secret" support for quite a while. That bug report links to this changeset: https://svn.apache.org/viewvc?view=revision=1738878 Looks like this is the 2.4.42 commit: https://github.com/apache/httpd/commit/d8b6d798c177dfdb90cef1a29395afcc043f3c86 With a follow-up doc update: https://github.com/apache/httpd/commit/4de7604dd086c7bebdcab4ae9dbbec24b59edabc I grabbed the above from the 2.4.x branch ** Bug watch added: Red Hat Bugzilla #1397241 https://bugzilla.redhat.com/show_bug.cgi?id=1397241 ** Changed in: apache2 (Ubuntu) Status: New => Triaged ** Changed in: apache2 (Ubuntu) Importance: Undecided => High ** Tags added: server-next -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to apache2 in Ubuntu. https://bugs.launchpad.net/bugs/1865340 Title: "secret" parameter not available in mod_proxy_ajp on focal To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1865340/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Monday/weekend (late) triage: 2020-03-02
Bugs last updated between 2020-02-28 (Friday) and 2020-03-01 (Sunday) inclusive Date range identified as: "Monday triage" Found 32 bugs. Some comments on a few of them: LP: #1613423 - +(New) [libvirt]- Mitaka + Trusty (kernel 3.13) not using apparmor capability by default, when it does, live migration doesn't work (/tmp/memfd-XXX can't be created) Tinoco intervened on this one (he filed it that many years ago). LP: #1825712 - *+(New) [bind9] - bind9 is compiled without support for EdDSA DNSSEC keys Tentatively confirmed, but I have to check if the version of bind9 in Bionic can correctly use this algorithm or if there were bugs that were fixed in later releases. LP: #1859773 - *(Triaged) [apache2]- Apache DBD Auth not working with mysql Focal 20.04 This one actually made me propose a fix for both focal and eoan, it's up for review. LP: #1863950 - (Incomplete) [qemu] - Failure installing ubuntu 20.04 in virtual machine at 19.10 The keyboard is missing sometimes. Lots of back and forth, no clear reproducer yer. LP: #1865152 - (New)[rdma-core] - SoftRoCE device disappears Tried same steps, they worked, asked for more information. LP: #1865340 - (New)[apache2]- secret parameter not available in mod_proxy_ajp on focal Located the upstream commits that implement "secret", and tagged server-next. This will be in 2.4.42, not released yet. Not sure when it will happen, so we could have the patch in focal's 2.4.41 before that. --- Bugs tagged 'server-next' and not touched in 60 days Found 0 bugs --- Bugs in backlog and not touched in 180 days Found 0 bugs -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
[Bug 1865152] Re: SoftRoCE device disappears
Hello, I just tried this on a eoan vm, but didn't experience the same as you. I did: rxe_cfg start rxe_cfg add ens2 (my nic) Now I have: root@eoan:~# rxe_cfg status Name Link Driver Speed NMTU IPv4_addr RDEV RMTU ens2 yes virtio_net 1458 10.48.132.219 rxe0 1024 (3) root@eoan:~# rxe_cfg persistent ens2 Could you please verify your steps and try to reproduce this on a clean eoan vm? And maybe attach logs, like dmesg and /var/log/syslog. For example, my dmesg recorded this: [ 59.829728] rdma_rxe: loaded [ 88.526483] infiniband rxe0: set active [ 88.526487] infiniband rxe0: added ens2 [ 88.659926] Loading iSCSI transport class v2.0-870. [ 88.676175] iscsi: registered transport (iser) [ 88.711353] RPC: Registered named UNIX socket transport module. [ 88.711355] RPC: Registered udp transport module. [ 88.711356] RPC: Registered tcp transport module. [ 88.711357] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 88.732917] RPC: Registered rdma transport module. [ 88.732919] RPC: Registered rdma backchannel transport module. ** Changed in: rdma-core (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to rdma-core in Ubuntu. https://bugs.launchpad.net/bugs/1865152 Title: SoftRoCE device disappears To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rdma-core/+bug/1865152/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1862602] Re: GPSD does not serve network clients even -G is used
That's a good suggestion, I'll reopen this bug with a severity of wishlist. Thanks! ** Changed in: gpsd (Ubuntu) Status: Invalid => Triaged ** Changed in: gpsd (Ubuntu) Importance: Undecided => Wishlist ** Summary changed: - GPSD does not serve network clients even -G is used + Better document how to listen on the network -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to gpsd in Ubuntu. https://bugs.launchpad.net/bugs/1862602 Title: Better document how to listen on the network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpsd/+bug/1862602/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1859773] Re: Apache DBD Auth not working with mysql Focal 20.04
PPA with builds for eoan and focal: https://launchpad.net/~ahasenack/+archive/ubuntu/mysql8-my-init/ Note: focal build does not have proposed enabled. ** Changed in: apr-util (Ubuntu Focal) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** Changed in: apr-util (Ubuntu Focal) Status: Triaged => In Progress ** Changed in: apr-util (Ubuntu Eoan) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** Changed in: apr-util (Ubuntu Eoan) Status: Triaged => In Progress ** Description changed: + [Impact] + + * An explanation of the effects of the bug on users and + + * justification for backporting the fix to the stable release. + + * In addition, it is helpful, but not required, to include an +explanation of how the upload fixes this bug. + + [Test Case] + + * detailed instructions how to reproduce the bug + + * these should allow someone who is not familiar with the affected +package to reproduce the bug and verify that the updated package fixes +the problem. + + [Regression Potential] + + * discussion of how regressions are most likely to manifest as a result + of this change. + + * It is assumed that any SRU candidate patch is well-tested before +upload and has a low overall risk of regression, but it's important +to make the effort to think about what ''could'' happen in the +event of a regression. + + * This both shows the SRU team that the risks have been considered, +and provides guidance to testers in regression-testing the SRU. + + [Other Info] + + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance + + [Original Description] + Using Apache DBD auth for MySQL server 8 causes an error in Focal 20.04 Same setup is working fine in 16.04 and 18.04 The following line in Apache2/conf-enabled/ causes the error: DBDriver mysql apache start failed: apachectl[1188]: Can't load driver file apr_dbd_mysql.so The file exists in /usr/lib/x86_64-linux-gnu/apr-util-1/apr_dbd_mysql.so linking the file to /lib/apache2/modules/ doesn't change the error message ** Summary changed: - Apache DBD Auth not working with mysql Focal 20.04 + Apache DBD Auth not working with mysql ** Description changed: [Impact] + The MySQL dbd driver fails to load into apache. This causes apache2 to fail to start if it's configured in this way. - * An explanation of the effects of the bug on users and + Since MySQL 8.0.2[1], the my_init() function is no longer exported, and + it's not expected that clients will call it. - * justification for backporting the fix to the stable release. + Confirming that, the current build logs for apr-util show: + /home/ubuntu/deb/apr-util/apr-util-1.6.1/dbd/apr_dbd_mysql.c:1267:5: warning: implicit declaration of function ‘my_init’; did you mean ‘mysql_init’? [-Wimplicit-function-declaration] + 1267 | my_init(); + | ^~~ + | mysql_init - * In addition, it is helpful, but not required, to include an -explanation of how the upload fixes this bug. + Furthermore, they also show[2] that loading the mysql driver failed, but + that doesn't cause the build to fail (unknown reason: not addressed in + this update): + + (...) + Loaded pgsql driver OK. + Failed to open pgsql[] + Failed to load driver file apr_dbd_mysql.so <<< + Loaded sqlite3 driver OK. + (...) + + The fix is to not call my_init(). This was confirmed with MySQL + upstream. + [Test Case] - * detailed instructions how to reproduce the bug + * detailed instructions how to reproduce the bug - * these should allow someone who is not familiar with the affected -package to reproduce the bug and verify that the updated package fixes -the problem. + * these should allow someone who is not familiar with the affected + package to reproduce the bug and verify that the updated package fixes + the problem. [Regression Potential] - * discussion of how regressions are most likely to manifest as a result + * discussion of how regressions are most likely to manifest as a result of this change. - * It is assumed that any SRU candidate patch is well-tested before -upload and has a low overall risk of regression, but it's important -to make the effort to think about what ''could'' happen in the -event of a regression. + * It is assumed that any SRU candidate patch is well-tested before + upload and has a low overall risk of regression, but it's important + to make the effort to think about what ''could'' happen in the + event of a regression. - * This both shows the SRU team that the risks have been considered, -and provides guidance to testers in regression-testing the SRU. + * This both shows the SRU team that the risks have been considered, + and provides guidance to testers in
[Bug 1866119] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
** Description changed: + OBS: This bug was originally into LP: #1865523 but it was split. + + SRU: pacemaker + + [Impact] + + * fence_scsi is not currently working in a share disk environment + + * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't + be able to start the fencing agents OR, in worst case scenarios, the + fence_scsi agent might start but won't make scsi reservations in the + shared scsi disk. + + * this bug is taking care of pacemaker 1.1.18 issues with fence_scsi, + since the later was fixed at LP: #1865523. + + [Test Case] + + * having a 3-node setup, nodes called "clubionic01, clubionic02, + clubionic03", with a shared scsi disk (fully supporting persistent + reservations) /dev/sda, with corosync and pacemaker operational and + running, one might try: + + rafaeldtinoco@clubionic01:~$ crm configure + crm(live)configure# property stonith-enabled=on + crm(live)configure# property stonith-action=off + crm(live)configure# property no-quorum-policy=stop + crm(live)configure# property have-watchdog=true + crm(live)configure# commit + crm(live)configure# end + crm(live)# end + + rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ + stonith:fence_scsi params \ + pcmk_host_list="clubionic01 clubionic02 clubionic03" \ + devices="/dev/sda" \ + meta provides=unfencing + + And see the following errors: + + Failed Actions: + * fence_clubionic_start_0 on clubionic02 'unknown error' (1): call=6, status=Error, exitreason='', + last-rc-change='Wed Mar 4 19:53:12 2020', queued=0ms, exec=1105ms + * fence_clubionic_start_0 on clubionic03 'unknown error' (1): call=6, status=Error, exitreason='', + last-rc-change='Wed Mar 4 19:53:13 2020', queued=0ms, exec=1109ms + * fence_clubionic_start_0 on clubionic01 'unknown error' (1): call=6, status=Error, exitreason='', + last-rc-change='Wed Mar 4 19:53:11 2020', queued=0ms, exec=1108ms + + and corosync.log will show: + + warning: unpack_rsc_op_failure: Processing failed op start for + fence_clubionic on clubionic01: unknown error (1) + + [Regression Potential] + + * LP: #1865523 shows fence_scsi fully operational after SRU for that + bug is done. + + * LP: #1865523 used pacemaker 1.1.19 (vanilla) in order to fix + fence_scsi. + + * TODO + + [Other Info] + + * Original Description: + Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ - params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ - meta provides=unfencing + params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ + meta provides=unfencing property cib-bootstrap-options: \ - have-watchdog=false \ - dc-version=1.1.18-2b07d5c5a9 \ - cluster-infrastructure=corosync \ - cluster-name=clubionic \ - stonith-enabled=on \ - stonith-action=off \ - no-quorum-policy=stop \ - symmetric-cluster=true + have-watchdog=false \ + dc-version=1.1.18-2b07d5c5a9 \ + cluster-infrastructure=corosync \ + cluster-name=clubionic \ + stonith-enabled=on \ + stonith-action=off \ + no-quorum-policy=stop \ + symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: - fence_clubionic (stonith:fence_scsi): Started clubionic01.private + fence_clubionic (stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda - LIO-ORG cluster.bionic. 4.0 - Peripheral device type: disk - PR generation=0x0, there are NO registered reservation keys + LIO-ORG cluster.bionic. 4.0 + Peripheral device type: disk + PR generation=0x0, there
[Bug 1865523] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
** No longer affects: pacemaker (Ubuntu) ** No longer affects: pacemaker (Ubuntu Bionic) ** Description changed: + OBS: I have split this bug into 2 bugs: + - fence-agents (this) and pacemaker (LP: #1866119) + SRU: fence-agents [Impact] * fence_scsi is not currently working in a share disk environment * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't be able to start the fencing agents OR, in worst case scenarios, the fence_scsi agent might start but won't make scsi reservations in the shared scsi disk. [Test Case] * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, one might try the following command: sudo fence_scsi --verbose -n clubionic01 -d /dev/sda -k 3abe -o off from nodes "clubionic02 or clubionic03" and check if the reservation worked: (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there are NO registered reservation keys (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there is NO reservation held * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, with corosync and pacemaker operational and running, one might try: rafaeldtinoco@clubionic01:~$ crm configure crm(live)configure# property stonith-enabled=on crm(live)configure# property stonith-action=off crm(live)configure# property no-quorum-policy=stop crm(live)configure# property have-watchdog=true crm(live)configure# property symmetric-cluster=true crm(live)configure# commit crm(live)configure# end crm(live)# end rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ stonith:fence_scsi params \ pcmk_host_list="clubionic01 clubionic02 clubionic03" \ devices="/dev/sda" \ meta provides=unfencing And see that crm_mon won't show fence_clubionic resource operational. [Regression Potential] - * Comments #3 and #4 show this new version fully working. - - * This fix has a potential of breaking other "nowadays working" fencing agent. If that happens, I suggest that ones affected revert previous to previous package AND open a bug against either pacemaker and/or fence-agents. + * Comments #3 and #4 show this new version fully working. + + * This fix has a potential of breaking other "nowadays working" fencing + agent. If that happens, I suggest that ones affected revert previous to + previous package AND open a bug against either pacemaker and/or fence- + agents. * Judging by this issue, it is very likely that any Ubuntu user that have tried using fence_scsi has probably migrated to a newer version because fence_scsi agent is broken since its release. * The way I fixed fence_scsi was this: I packaged pacemaker in latest 1.1.X version and kept it "vanilla" so I could bisect fence-agents. At that moment I realized that bisecting was going to be hard because there were multiple issues, not only one. I backported the latest fence-agents together with Pacemaker 1.1.19-0 and saw that it worked. From then on, I bisected the following intervals: 4.3.0 .. 4.4.0 (eoan - working) 4.2.0 .. 4.3.0 4.1.0 .. 4.2.0 4.0.25 .. 4.1.0 (bionic - not working) In each of those intervals I discovered issues. For example, Using 4.3.0 I faced problems so I had to backport fixes that were in between 4.4.0 and 4.3.0. Then, backporting 4.2.0, I faced issues so I had to backport fixes from the 4.3.0 <-> 4.2.0 interval. I did this until I was at 4.0.25 version, current Bionic fence-agents version. [Other Info] * Original Description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \
[Bug 1866119] [NEW] [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
Public bug reported: OBS: This bug was originally into LP: #1865523 but it was split. SRU: pacemaker [Impact] * fence_scsi is not currently working in a share disk environment * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't be able to start the fencing agents OR, in worst case scenarios, the fence_scsi agent might start but won't make scsi reservations in the shared scsi disk. * this bug is taking care of pacemaker 1.1.18 issues with fence_scsi, since the later was fixed at LP: #1865523. [Test Case] * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, with corosync and pacemaker operational and running, one might try: rafaeldtinoco@clubionic01:~$ crm configure crm(live)configure# property stonith-enabled=on crm(live)configure# property stonith-action=off crm(live)configure# property no-quorum-policy=stop crm(live)configure# property have-watchdog=true crm(live)configure# commit crm(live)configure# end crm(live)# end rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ stonith:fence_scsi params \ pcmk_host_list="clubionic01 clubionic02 clubionic03" \ devices="/dev/sda" \ meta provides=unfencing And see the following errors: Failed Actions: * fence_clubionic_start_0 on clubionic02 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:12 2020', queued=0ms, exec=1105ms * fence_clubionic_start_0 on clubionic03 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:13 2020', queued=0ms, exec=1109ms * fence_clubionic_start_0 on clubionic01 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:11 2020', queued=0ms, exec=1108ms and corosync.log will show: warning: unpack_rsc_op_failure: Processing failed op start for fence_clubionic on clubionic01: unknown error (1) [Regression Potential] * LP: #1865523 shows fence_scsi fully operational after SRU for that bug is done. * LP: #1865523 used pacemaker 1.1.19 (vanilla) in order to fix fence_scsi. * TODO [Other Info] * Original Description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: fence_clubionic (stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there are NO registered reservation keys (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there is NO reservation held ** Affects: pacemaker (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: pacemaker (Ubuntu Bionic) Importance: Undecided Status: In Progress ** Also affects: pacemaker (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: pacemaker (Ubuntu) Status: New => Fix Released ** Changed in: pacemaker (Ubuntu Bionic) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1866119 Title: [bionic] fence_scsi not working properly with
[Bug 1859773] Re: Apache DBD Auth not working with mysql Focal 20.04
** Also affects: apr-util (Ubuntu) Importance: Undecided Status: New ** No longer affects: apache2 (Ubuntu) ** Changed in: apr-util (Ubuntu Eoan) Status: New => Triaged ** Changed in: apr-util (Ubuntu Focal) Status: New => Triaged ** Changed in: apr-util (Ubuntu Eoan) Importance: Undecided => High ** Changed in: apr-util (Ubuntu Focal) Importance: Undecided => High ** No longer affects: apache2 (Ubuntu Eoan) ** No longer affects: apache2 (Ubuntu Focal) -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1859773 Title: Apache DBD Auth not working with mysql Focal 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apr-util/+bug/1859773/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Triage and Migration report Wed Mar 4th, 2020
## Proposed Migration ## I've already been working on php and ruby migration issues this past week, so will mostly use my time to just keep plugging on those. However, real quick look at a couple items on the board: * corosync's log shows a testbed timeout for a single arch. I re-triggered the test in case it case it's just a system issue. * openssh has an unsatisfiable depends on libfido2-1, which looks like a universe package? MIR needed? libfido2-1 | 1.3.1-1build1 | focal/universe | amd64, arm64, armhf, i386, ppc64el, s390x ## Bug Triage ## Bugs last updated on 2020-03-03 (Tuesday) Date range identified as: "Wednesday triage" Found 8 bugs LP: #1865501 - (Incomplete) [libpcap]- libpcap-dev and derivatives missing libpcap.pc --> Attached actual patch from the debian release with the fix --> Targeted to affected series --> New LP: #1865900 - (New)[apache2]- apache 2.4.29-1ubuntu4.12 authentication with client certificate broken * Appears to be a regression from the ubuntu4.12 update * No logs or confs provided though --> Tagged 'regression-update' --> Mentioned it to the relevant SRU bug, LP: #1845263 --> Requested reporter provide logs & conf --> Incomplete -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
[Bug 1859773] Re: Apache DBD Auth not working with mysql Focal 20.04
The build logs show this:
/home/ubuntu/deb/apr-util/apr-util-1.6.1/dbd/apr_dbd_mysql.c:1267:5: warning:
implicit declaration of function ‘my_init’; did you mean ‘mysql_init’?
[-Wimplicit-function-declaration]
1267 | my_init();
| ^~~
| mysql_init
Checking the mysql 8 release notes at
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-2.html we see:
"""
The my_init() function is no longer included in the list of symbols exported
from libmysqlclient. It need not be called explicitly by client programs
because it is called implicitly by other C API initialization functions.
"""
In the dbd/apr_dbd_mysql.c code, it is called like this:
static void dbd_mysql_init(apr_pool_t *pool)
{
#if MYSQL_VERSION_ID < 10
my_init();
#endif
mysql_thread_init();
--
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1859773
Title:
Apache DBD Auth not working with mysql Focal 20.04
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1859773/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1859773] Re: Apache DBD Auth not working with mysql Focal 20.04
Dropping that my_init() call fixed the loading of the module for me. I'll publish a ppa for people to test. -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1859773 Title: Apache DBD Auth not working with mysql Focal 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1859773/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1865523] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
** Description changed: + SRU: fence-agents + + [Impact] + + * fence_scsi is not currently working in a share disk environment + + * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't + be able to start the fencing agents OR, in worst case scenarios, the + fence_scsi agent might start but won't make scsi reservations in the + shared scsi disk. + + [Test Case] + + * having a 3-node setup, nodes called "clubionic01, clubionic02, + clubionic03", with a shared scsi disk (fully supporting persistent + reservations) /dev/sda, one might try the following command: + + sudo fence_scsi --verbose -n clubionic01 -d /dev/sda -k 3abe -o off + + from nodes "clubionic02 or clubionic03" and check if the reservation + worked: + + (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda + LIO-ORG cluster.bionic. 4.0 + Peripheral device type: disk + PR generation=0x0, there are NO registered reservation keys + + (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda + LIO-ORG cluster.bionic. 4.0 + Peripheral device type: disk + PR generation=0x0, there is NO reservation held + + * having a 3-node setup, nodes called "clubionic01, clubionic02, + clubionic03", with a shared scsi disk (fully supporting persistent + reservations) /dev/sda, with corosync and pacemaker operational and + running, one might try: + + rafaeldtinoco@clubionic01:~$ crm configure + crm(live)configure# property stonith-enabled=on + crm(live)configure# property stonith-action=off + crm(live)configure# property no-quorum-policy=stop + crm(live)configure# property have-watchdog=true + crm(live)configure# property symmetric-cluster=true + crm(live)configure# commit + crm(live)configure# end + crm(live)# end + + rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ + stonith:fence_scsi params \ + pcmk_host_list="clubionic01 clubionic02 clubionic03" \ + devices="/dev/sda" \ + meta provides=unfencing + + And see that crm_mon won't show fence_clubionic resource operational. + + [Regression Potential] + + * Judging by this issue, it is very likely that any Ubuntu user that + have tried using fence_scsi has probably migrated to a newer version + because fence_scsi agent is broken since its release. + + * The way I fixed fence_scsi was this: + + I packaged pacemaker in latest 1.1.X version and kept it "vanilla" so I + could bisect fence-agents. At that moment I realized that bisecting was + going to be hard because there were multiple issues, not only one. I + backported the latest fence-agents together with Pacemaker 1.1.19-0 and + saw that it worked. + + From then on, I bisected the following intervals: + + 4.3.0 .. 4.4.0 (eoan - working) + 4.2.0 .. 4.3.0 + 4.1.0 .. 4.2.0 + 4.0.25 .. 4.1.0 (bionic - not working) + + In each of those intervals I discovered issues. For example, Using 4.3.0 + I faced problems so I had to backport fixes that were in between 4.4.0 + and 4.3.0. Then, backporting 4.2.0, I faced issues so I had to backport + fixes from the 4.3.0 <-> 4.2.0 interval. I did this until I was at + 4.0.25 version, current Bionic fence-agents version. + + [Other Info] + + * Original Description: + Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ - params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ - meta provides=unfencing + params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ + meta provides=unfencing property cib-bootstrap-options: \ - have-watchdog=false \ - dc-version=1.1.18-2b07d5c5a9 \ - cluster-infrastructure=corosync \ - cluster-name=clubionic \ - stonith-enabled=on \ - stonith-action=off \ - no-quorum-policy=stop \ - symmetric-cluster=true + have-watchdog=false \ + dc-version=1.1.18-2b07d5c5a9 \ + cluster-infrastructure=corosync \ + cluster-name=clubionic \ + stonith-enabled=on \ + stonith-action=off \ + no-quorum-policy=stop \ + symmetric-cluster=true
[Bug 1865218] Re: mod_php gets disabled during do-release-upgrade
Thanks for the reproduction steps, marking as triaged. ** Changed in: php-defaults (Ubuntu) Status: New => Triaged ** Changed in: php-defaults (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to php-defaults in Ubuntu. https://bugs.launchpad.net/bugs/1865218 Title: mod_php gets disabled during do-release-upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/php-defaults/+bug/1865218/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1864555] Re: focal: upgrade if multipath-tools results in modprobe error messages
*** This bug is a duplicate of bug 1864992 *** https://bugs.launchpad.net/bugs/1864992 I believe this is a duplicate of https://bugs.launchpad.net/curtin/+bug/1864992 and not related to multipath ** This bug has been marked a duplicate of bug 1864992 depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1864555 Title: focal: upgrade if multipath-tools results in modprobe error messages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1864555/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1864338] Re: samba does not install cleanly on machine with no IPv4 address
*** This bug is a duplicate of bug 1731502 *** https://bugs.launchpad.net/bugs/1731502 This is bug #1731502, also filed upstream at https://bugzilla.samba.org/show_bug.cgi?id=13111 ** Bug watch added: Samba Bugzilla #13111 https://bugzilla.samba.org/show_bug.cgi?id=13111 ** This bug has been marked a duplicate of bug 1731502 nmbd starts fine with no interfaces, but doesn't notify systemd that it started -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1864338 Title: samba does not install cleanly on machine with no IPv4 address To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1864338/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1825712] Re: bind9 is compiled without support for EdDSA DNSSEC keys
It's a valid request, I'm just not sure if the version of bind in bionic is good enough for this support. I vaguely remember reading somewhere that certain encryption types were not working well in certain versions of bind9 (sorry, very vague, I know). Because of that I'm confirming the bug, but this would have to be investigated. ** Changed in: bind9 (Ubuntu Bionic) Status: New => Triaged ** Changed in: bind9 (Ubuntu Bionic) Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1825712 Title: bind9 is compiled without support for EdDSA DNSSEC keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1825712/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
proposed migration duty - special php edition - v2
Synced again with Bryce and Rbasak on the php-trasks-of-the-day to help. The following summarizes the work one and the state we left it so Bryce can continue on it. I've got quite some stuff done, but the very busy autopkgtest queue stalls further progress right now --- #1 PHPUnit test issues in proposed migration - Upload phpunit and dependent fixes as identified by rbasak and me - Rbasak uploaded https://launchpad.net/ubuntu/+source/phpunit/8.5.2-1ubuntu1 - Then later (Depending on the former) I uploaded https://launchpad.net/ubuntu/+source/php-net-ldap2/2.2.0-3ubuntu3 https://launchpad.net/ubuntu/+source/php-http-request2/2.3.0-1ubuntu2 - Depends on php-codecoverage and phpunit-global-state which after the efforts yesterday are both good to go (test-wise). - The next step would be triggering test cases with the right components together. Actually for a first shot let's use all-proposed=1 on those. But for now the tests are still running, need to wait for the results first and then trigger those failing. TODO wait for tests to complete the first time, then trigger the failing ones wirth all-proposed (or global-state + php7.4 + phpunit + ..?) --- #Info - For bonus confusion there also is a rebuild of php7.3 ongoing at the moment. Also php7.4 was rebuilt (due to the ICU transition) => https://launchpad.net/ubuntu/+source/php7.3/7.3.15-3build1 => https://launchpad.net/ubuntu/+source/php7.4/7.4.3-4build2 So test lists will be testing 7.4/7.3 stay sharp which one you actually look at. @Bryce the intention is to remove 7.4 before Focal releases right? --- #2 php-horde ?? - Look at php-horde-* if they need something Bryce asked for the following: - php-horde-nag - php-horde-mnemo - php-horde-lz4 - php-horde-kronolith - php-horde-imp - php-horde-ansel - php-horde-text-filter - php-horde-mime => All of them passed migration, and the tests on php7.[34] are reset we have to wait until those complete Looking at these I found in update excuses that the following two are hanging since 130 days. Mostly php and phpunit version issues - time to re-test them with the new versions we have in proposed. - php-horde-icalendar - php-horde-image TODO check new results once the new tests ran --- #4 Check FTBFS of php-msgpack Upload was from: https://code.launchpad.net/~bryce/ubuntu/+source/php-msgpack/+git/php-msgpack/+merge/379773 https://launchpad.net/ubuntu/+source/php-msgpack/2.1.0beta1-0ubuntu1 Breaks on arm64 armhf Failed: Profiling perf test. [tests/035.phpt] Didn't I fix or at least write about that test recently? Yeah I had done so in: https://lists.ubuntu.com/archives/ubuntu-server/2020-February/008160.html I already had an analysis and a fix there. After asking for review I got by Rafael and then uploaded the fix. It built fine at https://launchpad.net/ubuntu/+source/php-msgpack/2.1.0beta1-0ubuntu2 @Bryce - that should properly build now and resolve whatever you wanted to sove with the initial merge of that new version --- #5 rebuilds for migration of php7.4 - Those are no-change rebuilds by Byce, check build results and migration: - php-cache-lite => build ok => still waiting in queue - php-db => build ok => still waiting in queue - php-text-password => build ok => fails with old phpunit, triggered with new one - phpmd => wasn't uploaded! => last build on 7.3 at 2020-02-24 => uploaded it now - php-imagick => already built against 7.4 on 2020-02-28 TODO check results again later once the queue was drained -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
[Bug 1613423] Re: Mitaka + Trusty (kernel 3.13) not using apparmor capability by default, when it does, live migration doesn't work (/tmp/memfd-XXX can't be created)
Preferred way for this fix was: commit 0d34fbabc13891da41582b0823867dc5733fffef Author: Rafael David Tinoco Date: Mon Oct 24 15:35:03 2016 vhost: migration blocker only if shared log is used Commit 31190ed7 added a migration blocker in vhost_dev_init() to check if memfd would succeed. It is better if this blocker first checks if vhost backend requires shared log. This will avoid a situation where a blocker is added inappropriately (e.g. shared log allocation fails when vhost backend doesn't support it). Signed-off-by: Rafael David Tinoco Reviewed-by: Marc-André Lureau Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin And accepted upstream. I'm closing this bug. ** Changed in: libvirt (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to libvirt in Ubuntu. https://bugs.launchpad.net/bugs/1613423 Title: Mitaka + Trusty (kernel 3.13) not using apparmor capability by default, when it does, live migration doesn't work (/tmp/memfd-XXX can't be created) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1613423/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1613423] Re: Mitaka + Trusty (kernel 3.13) not using apparmor capability by default, when it does, live migration doesn't work (/tmp/memfd-XXX can't be created)
QEMU BUG: https://bugs.launchpad.net/qemu/+bug/1626972 ** Changed in: libvirt (Ubuntu) Status: Fix Released => Incomplete -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to libvirt in Ubuntu. https://bugs.launchpad.net/bugs/1613423 Title: Mitaka + Trusty (kernel 3.13) not using apparmor capability by default, when it does, live migration doesn't work (/tmp/memfd-XXX can't be created) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1613423/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: proposed migration duty - special php edition
On Tue, Mar 03, 2020 at 11:01:54PM -0800, Bryce Harrington wrote:
> On Tue, Mar 03, 2020 at 12:38:08PM +0100, Christian Ehrhardt wrote:
>
> I emailed the Debian php maintainer and asked their plans:
>
> > Hi Ondřej,
> >
> > We noticed that with php7.4 there seems to be a change in how php-recode
> > is packaged. It looks like it's no longer provided by php7.4, and we're
> > wondering if that is intended to be its own separate package, or if it's
> > intended to go away entirely? If the former, do you know there has
> > already been work to package it? Or, of the latter, it looks to us like
> > this would impact src:fusiondirectory and src:gosa, which presumably
> > would need dropped from the archive? I'm curious if you're aware of
> > this and if you have plans for dealing with it - our preference would be
> > to follow your plans here.
>
> Hi Bryce,
>
> recode extension has been unbundled from PHP:
> https://www.php.net/manual/en/intro.recode.php
>
> It should be fairly easy to package, but intl extension is so much better,
> so I am not sure it’s worth it.
>
> Ondrej
And the recode package in PECL is not really maintained at the moment, so I
would recommend
just dropping it.
The src gosa has:
samba/personal/samba/class_sambaMungedDial.inc: if
(function_exists("recode")){
samba/personal/samba/class_sambaMungedDial.inc: $utfName=
recode("ISO8859-15..UTF-16",
$paramName);
so it’s safe to drop the dependency
and the same class_sambaMungedDial.inc is in fusiondirectory.
I would not shed a single tear about this :-)
Ondrej
--
So looks like we can safely drop.
Bryce
> > [07:09] + exim4 - retriggered (E: Can not write log (Is
> > => Your retrigger worked
>
> \o/
>
>
> > [07:09] + xdebug (php-codecoverage, php-unit)
> > => Results good - all done
>
> \o/
>
>
> > => But phpunit had further issues.
> > At least all 39 errors are about the same two things above, so one fix
> > should do it for all.
> > => https://github.com/sebastianbergmann/global-state/issues/21
> > But as we learned from other threads in this whole topic there also is a
> > new phpunit - lets add that as well.
> > => These tests are still ongoing - I'll reply later
>
> I followed along the research and patch reviews, but don't have anything
> meaningful to add. Hope you and Robie get a chance to continue work on
> this; let me know if I can assist.
>
> I looked a bit at the new 9.0.1 release. It looks like it removes a
> fair bit of deprecated functionality. I think Robie's approach of
> cherrypicking the actual fix and leaving the merge until later, is the
> safest approach here.
>
>
> > [07:09] + php-memcache (php-doctrine-cache-bundle?)
> > => Results good - all done
>
> \o/
>
>
> > - php-doctrine-cache-bundle test for php-memcached still failed `so:
> > undefined symbol: php_msgpack_serialize` - does that ring a bell for
> > someone?
> > -> it might need the new php-memcache as well?
> > - Nope, it must be something else
> > -> This issue in php-memcached is free for anyone to pick up
>
> It's just yet another case of php7.3 getting pulled in (first thing to
> look for, 99% of the time that's what it is). I've uploaded a no-change
> rebuild which should resolve this.
>
> I also added the package to my list for next go-around. (I don't know
> why ben doesn't flag packages like this one -- it should have been
> in its list...)
>
>
> > [07:09] + php-horde-lz4 (TestCase::setUp() -- looks familiar)
> > And another case of "Class 'DOMDocument' not found"
> > Trying the same fix with a php-defaults retrigger.
> > Results look good, triggered on all architectures now.
> > => Results good - all done
>
> \o/
>
> Some other php-horde packages that might need attention:
>
> php-horde-nag
> php-horde-mnemo
> php-horde-lz4
> php-horde-kronolith
> php-horde-imp
> php-horde-ansel
> php-horde-text-filter
> php-horde-mime
>
> I plan on looking at these, but if anyone wants to beat me, feel free.
> They may merely need no-change rebuilds.
>
>
> > I've realized looking at the above that phpunit also has a lot of things
> > that try to move together and are influenced by the 7.4 transition.
> > Tests that are broken seem to come in three classes:
> >
> > Class I:
> > - php-cache-lite - FAIL stderr: PHP Warning:
> > file_put_contents(/usr/bin/.phpunit.result.cache): failed to open stream
> > (no idea yet)
> > - php-db - same I/O error
> > - php-imagick - same I/O error
> > - php-text-password - same I/O error
> > - phpmd - there are two versions, the newer 2.8.1-2 failed on the same I/O
> > error
> > => Rbasak offered to take a look at these, he'll reply to this mail later
>
> I've seen this in Debian's test logs too, e.g.:
>
>
> https://ci.debian.net/data/autopkgtest/unstable/amd64/p/php-imagick/4439426/log.gz
>
> Notably, we don't get that
