Bug#1059972: LGTM, added to git
Control: tags 1059972 + patch pending Hi, thank you for your prep work. I've opened [1] to add it to the git branch. The intention is to upload it to experimental once 23.11.1 is around, check if all loong64 builds are correct and then push to unstable. [1]: https://salsa.debian.org/debian/dpdk/-/merge_requests/78 -- Christian Ehrhardt Director of Engineering, Ubuntu Server Canonical Ltd
Bug#1060655: Tests are flaky on slow machines
Package: nut Version: 2.8.1-3 Hi, the sync in Ubuntu of the latest nut version failed to test correctly [1][2]. I looked around and found that it is just a race when run on slow machines as it also happened on an intentionally slowed down x86 machine. Then I found that this is a problem of Debian as well for reiscv64 [3]. My experiments showed that we can easily bump up the sleeps used by an order of magnitude and still complete the tests itself in 15 minutes which I think is fine. When looking at the fix (I'll submit a PR in a bit) feel free to use other values. I've found x3 to work as well, but I was scared that it might still be flaky on a bad day (e.g. other load on the same virt host) that way. Thanks in advance for considering this, Christian Ehrhardt [1]: https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/armhf/n/nut/20240111_033045_a6fb1@/log.gz [2]: https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/arm64/n/nut/20240110_191721_ce77c@/log.gz [3]: https://ci.debian.net/packages/n/nut/unstable/riscv64/41595099/
Bug#1060041: Is the python3-objgraph dependency too much
libsm6 libsqlite3-0 libsvtav1enc1d1 libthai-data libthai0 libtiff6 libwayland-client0 libwayland-cursor0 libwayland-egl1 libwebp7 libx265-199 libxaw7 libxcb-render0 libxcb-shm0 libxcomposite1 libxcursor1 libxdamage1 libxfixes3 libxft2 libxi6 libxinerama1 libxkbcommon0 libxml2 libxmu6 libxpm4 libxrandr2 libxrender1 libxt6 libxtst6 libyuv0 media-types openssl python3 python3-autocommand python3-cairo python3-cffi-backend python3-cheroot python3-cherrypy3 python3-cryptography python3-gi python3-gi-cairo python3-graphviz python3-inflect python3-jaraco.collections python3-jaraco.context python3-jaraco.functools python3-jaraco.text python3-minimal python3-more-itertools python3-numpy python3-objgraph python3-openssl python3-pkg-resources python3-portend python3-pydantic python3-repoze.lru python3-routes python3-simplejson python3-six python3-tempora python3-typing-extensions python3-tz python3-webob python3-zc.lockfile python3.11 python3.11-minimal python3.12 python3.12-minimal readline-common shared-mime-info x11-common xdg-user-dirs xdot xkb-data 0 upgraded, 181 newly installed, 0 to remove and 0 not upgraded. Need to get 78.6 MB of archives. After this operation, 363 MB of additional disk space will be used. And as I wrote at the beginning, I think this isn't just a Ubuntu component mismatch problem. I couldn't find a use case of objgraph with cherrypy3 that is important enough to add all of this as dependency. Therefore now I wonder: - Is there a use case that I overlooked that makes it worth having this dependency? - Or if not - would you be ok to also reduce it to a Suggests as I've done in Ubuntu [4]? [1]: https://bugs.launchpad.net/ubuntu/+source/cherrypy3/+bug/2047821 [2]: https://github.com/cherrypy/cherrypy/blob/30d9a141c67ecb958ce305810203d89d60ef318b/setup.py#L89 [3]: https://src.fedoraproject.org/rpms/python-cherrypy/blob/rawhide/f/python-cherrypy.spec [4]: https://git.launchpad.net/~paelzer/ubuntu/+source/cherrypy3/commit/?id=f64dcc0f0c01b29a6b622e330e5cf2ee4dce -- Christian Ehrhardt
Bug#1059985: apc_modbus pulls in libmodbus in the default installation
Package: nut Version: 2.8.1-1 Hi, the most recent version of nut added the new apc_modbus driver, but it did so to the base nut-server package. Due to that on upgrade people will get more dependencies installed: The following additional packages will be installed: libmodbus5 This feels odd as there is the explicit nut-modbus package to encapsulate those drivers with a dependency to it. From d/control: "This package provides nut-modbus, a collection of drivers for UPS systems with Modbus-based communication protocols." This might as well be intentional, but then OTOH what would we keep nut-modbus for? If it was not intentional I'd prefer to move apc_modbus to nut-modbus (which for transparency [1] would also help me on the Ubuntu side with dependencies) For the second option I provided you a PR to consider [2], let me know what you think. [1]: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/2046263 [2]: https://salsa.debian.org/debian/nut/-/merge_requests/8 Thanks in advance for thinking about this and a happy start to 2024! Christian Ehrhardt
Bug#1059036: Thank you Athos, merged and uploading ...
Thanks to Athos proposed fix that was easy to fix. In the meantime it also has been upstream accepted and I ran a test build with and without nocheck which both worked fine. I updated git and I'm uploading debian/1.2.0-6
Bug#1050972: Ready for review
The build was fine, I'm asking Bernd and/or Bryce to have another pair of eyes for a sanity check. => https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/merge_requests/23 After an approval and the tests passing it should be good for an upload to unstable. -- Christian Ehrhardt Director of Engineering, Ubuntu Server Canonical Ltd
Bug#1050970: Preparing 12.3.0
Hi, FYI I'm currently preparing 12.3.0 (see bug 1050972) which will close this bug for trixie. -- Christian Ehrhardt Director of Engineering, Ubuntu Server Canonical Ltd
Bug#1050972: Preparing that upload
Hi John, thanks for the report. I had a look at it and it really seems mostly just a safe maintenance update. We already have the new dependencies and are not affected by the deprecation of some xml libs. It seems the former grpc issue is fixed, I was able to drop that and it LGTM so far. I imported the new version to git, updates upstream/pristine-tar branches and I'm currently test building the new version to check that out. -- Christian Ehrhardt Director of Engineering, Ubuntu Server Canonical Ltd
Bug#1037546: Uploaded to unstable
Hi, just as FYI I've not got any response from Bernd on IRC, bug, salsa so I went ahead and uploaded this. Bryce will soon merge this in Ubuntu and go through some deeper testing together with vmware - so we should soon know if any issue hides and needs to be fixed. -- Christian Ehrhardt Senior Staff Engineer and acting Director, Ubuntu Server Canonical Ltd
Bug#1037546: PRs prepared
Hi, I've had a look and these are really straight forward. I prepared salsa PRs at https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/merge_requests/17 https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/merge_requests/18 https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/merge_requests/19 I hope Bernd has some time to give them a look, if not I can still upload in a bit (probably next week to give him the chance over the weekend). -- Christian Ehrhardt Senior Staff Engineer and acting Director, Ubuntu Server Canonical Ltd
Bug#1032875: Further insights and TODOs
I was tracking a TODO file for the remaining tasks. And after the recent setback of expectations reported above I have entered testing and found quite a list of things that should be tackled before going to the NEW queue with this. If you are curious, feel free to have a look and tackle any of [1]. But since at least some seem to reflect the package upstream repo getting outdated (again) I'm not yet too confident in continuing on this. Either way, documenting this in the repo and the ITP is an important step. [1]: https://salsa.debian.org/paelzer-guest/dool/-/blob/create-dool-based-on-dstat/debian/TODO -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1032875: Small setback
Hi, I'm not entirely convinced on how up to date and frequently maintained the new repository is. I've found that it breaks on just checkout + make. This wasn't unknown, but PRs to fix it were open for quite some time without action - https://github.com/scottchiefbaker/dool/pull/28 - https://github.com/scottchiefbaker/dool/pull/30 It IMHO also need: - https://github.com/scottchiefbaker/dool/pull/37 on top. But the point is, if PRs and issues are not handled we will only get a singular update and not an active replacement for dstat. I'll be waiting to see if there is a response to the open PRs. -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1032615: Dool ITP is now bug 1032875
Thanks for your feedback, accordingly I've opened an ITP for dool at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032875 -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1032875: ITP: dool -- Dool as further maintained fork of Dstat
Package: wnpp Severity: wishlist Owner: Christian Ehrhardt * Package name: dool Version : 1.1.0 Upstream Author : Scott Baker * URL : https://github.com/scottchiefbaker/dool * License : GPL-2 Programming Lang: Python Description : Dool is a python3 compatible fork of Dstat and thereby is a versatile replacement for vmstat, iostat and ifstat. Dool overcomes some of the limitations of these programs and adds some extra features. As discussed and somewhat pre-coordinated on [1] this is about replacing (over time) dstat with dool. dstat was always great and well developed. I wondered why it recently had more issues, so I had a look at [2]. Reading there didn't make me too happy as it is essentially dead since almost 4 years now due to [3]. But it made me spot that there is a continued fork in the form of [4] I did check, but there is no ITP yet listed in [5] which this report is creating now to have the upload refer to it once it is ready. As discussed in [1] the intent is to package dool separately first and maybe take over dstat fully once it is considered ready. Development wise this will be based on the dstat packaging (retaining history) and all former dstat maintainers/uploaders should start as co-uploader/maintainer. A (very!) preliminary packaging branch has been started on salsa in the namespace of my user [6]. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032615 [2]: https://github.com/dstat-real/dstat [3]: https://github.com/dstat-real/dstat/issues/170 [4]: https://github.com/scottchiefbaker/dool [5]: https://www.debian.org/devel/wnpp/requested [6]: https://salsa.debian.org/paelzer-guest/dool/-/commits/create-dool-based-on-dstat
Bug#1032615: dstat is discontinued, let us consider dool ?
Package: dstat Version: 0.7.4-6.1 (Resent as I forgot to add package and version due to all the writing) Hi, I've used dstat for years and was always happy. Then I stepped away for a while and recently found it would break if some options were used. For example in current sid: root@d10-sid:~# dstat --cpu-adv --noupdate --output foo.csv 10 6 Traceback (most recent call last): File "/usr/bin/dstat", line 2847, in main() File "/usr/bin/dstat", line 2687, in main scheduler.run() File "/usr/lib/python3.11/sched.py", line 151, in run action(*argument, **kwargs) File "/usr/bin/dstat", line 2806, in perform oline = oline + o.showcsv() + o.showcsvend(totlist, vislist) ^^^ File "/usr/bin/dstat", line 547, in showcsv if isinstance(self.val[name], types.ListType) or isinstance(self.val[name], types.TupleType): ^ NameError: name 'types' is not defined. Did you mean: 'type'? Since I remembered this as rather well developed I wondered and had a look at [1]. Reading there didn't make me too happy as it is essentially dead since almost 4 years now due to [2]. But it made me spot that there is a continued fork in the form of [3] That not only fixes the issue I had above, but many many others. So I wondered if/how we should consider replacing dstat with dool in Debian? I did check, but there is no ITP yet listed in [4] So it seems there was no discussion yet AFAICS. Hence I wanted to ask how/if you'd want to play this out. 1. Should we add dool independent of dstat, and once dool looks good make dstat a transitional (and add a name alias and conflicts to dool to take over as drop in)? 2. Should we keep src:dstat even though it actually isn't and use the dool content (just adding a license and wording changes in some places, and adding both binary names, probably man page alternatives as well) 3. Anything else (there are too many details to predict) Please let me know what you think and prefer, based on that I could prepare an ITP+upload or a proposal to change src:dstat once I have some weekend time again. Due to the freezes we have some time anyway :-) Thanks in advance for thinking about this with me, Christian [1]: https://github.com/dstat-real/dstat [2]: https://github.com/dstat-real/dstat/issues/170 [3]: https://github.com/scottchiefbaker/dool [4]: https://www.debian.org/devel/wnpp/requested -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1030545: More data points
Hi, since I have regular access to a s390x box I was able to test a few more (Ubuntu centric) versions and can confirm that I do not see such a hang. Hope these data points might help. Tested qemu-img: - 1:7.2+dfsg-2ubuntu1~lunarppa1 - 1:6.2+dfsg-2ubuntu6.6 Under Kernel 5.15.0-60-generic All done on a real disk, not tmpfs. Since it hangs, what do strace and/or gdb report where it is stuck? Also to start with - is it continuing to consume cpu cycles or just stuck?
Bug#1028655: Confirmed and Thanks!
fixed 1028655 1.2.0-3 tags 1028655 +pending Thanks Peter, I'll upload this now, so that we are early enough before the next stage of freeze in a few weeks.
Bug#1027781: This problem is Chip dependent
Hi, I just wanted to mention that arm32 support is possible, but optional in arm64. So far only a few chips had neglected arm32. So on most aarch64 systems you can "just run" armhf code and it would work. Now the M1 chip AFAIK has no arm32 and that causes the issue you face, but at the same time explains to some extent why it wasn't much of a problem before. I thought I should mention that as it will affect the solution (do only some arm64 platforms want that, would others regress potentially going from HW to TCG emulation) and testing (as it will behave differently based on which HW you use for aarch64). And while the code to change to do what you ask for in debian/binfmt-install is simple. Past issues like [1] have hit just such issues as I'm afraid we might re-face here. Maybe this needs to become more advanced than just checking $DEB_HOST_ARCH, but that is up for discussion. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604712
Bug#1006341: Does not seem to be reproducible
Thanks for finding this, I agree that it seems to fail due to the
number of cores as you suggested:
...
obj-x86_64-linux-gnu/app/test/dpdk-test '-l 0-143'
...
| EAL: Detected 128 lcore(s)
...
| EAL: invalid core list syntax
But when trying to recreate this I've found the -l argument to not
even be passed to the tests.
Neither with the coming 22.11 which we work on, nor with 21.11-5
(unstable) nor with 22.11.6 (stable).
The code in app/test/meson.build does not really add anything in
between the binary and the no-huge argument:
463 dpdk_test = executable('dpdk-test',
483 test_args = []
487 test_args += test_no_huge_args
Also in all other builds there is no -l at all:
"... app/test/dpdk-test --no-huge -m 2048 --file-prefix=bitmap_autotest"
https://buildd.debian.org/status/fetch.php?pkg=dpdk=amd64=21.11-5%2Bb2=1667749698=0
https://launchpadlibrarian.net/623152077/buildlog_ubuntu-kinetic-amd64.dpdk_21.11.2-0ubuntu1_BUILDING.txt.gz
Therefore I wanted to ask if you could execute the very same you did
on a smaller host and let us know if then the -l in the test calls is
gone or if you see it still there but with smaller values matching
your build environment?
If yes, then we need to assume that the environment size somehow
causes this arg to be added, but otherwise it stays a mystery.
--
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd
Bug#1021231: Yes, let us bump it to see if it gets better
Hi, thanks for the report. I've usually looked for the synced builds to test on the Ubuntu autopkgtest environment and there it was usually fine [1][2][3]. In the past we had issues with the more container based environment to trigger a few more odd tests, but that has gotten much better these days. And you are right, those you call out are just flaky (as they sometimes work) and hit the timeout. It should be rather save to double (or even more) that and then have a look again after some time if this improved the situation. I'll add it to the upcoming 22.11 that we work on. [1]: https://autopkgtest.ubuntu.com/packages/dpdk/kinetic/arm64 [2]: https://autopkgtest.ubuntu.com/packages/dpdk/kinetic/ppc64el [3]: https://autopkgtest.ubuntu.com/packages/dpdk/kinetic/amd64 -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1023569: Progress update from DPDK 22.11
Hi, we are working on getting 22.11 ready which fixes this issue (adding libxdp-dev build depends fixed this). >From the build log: 50833 drwxr-xr-x root/root 0 2022-11-11 13:08 ./ 50834 drwxr-xr-x root/root 0 2022-11-11 13:08 ./usr/ 50835 drwxr-xr-x root/root 0 2022-11-11 13:08 ./usr/lib/ 50836 drwxr-xr-x root/root 0 2022-11-11 13:08 ./usr/lib/x86_64-linux-gnu/ 50837 drwxr-xr-x root/root 0 2022-11-11 13:08 ./usr/lib/x86_64-linux-gnu/dpdk/ 50838 drwxr-xr-x root/root 0 2022-11-11 13:08 ./usr/lib/x86_64-linux-gnu/dpdk/pmds-23.0/ 50839 lrwxrwxrwx root/root 0 2022-11-11 13:08 ./usr/lib/x86_64-linux-gnu/dpdk/pmds-23.0/librte_net_af_xdp.so.23 -> librte_net_af_xdp.so.23.0 50840 -rw-r--r-- root/root 47232 2022-11-11 13:08 ./usr/lib/x86_64-linux-gnu/dpdk/pmds-23.0/librte_net_af_xdp.so.23.0 50841 lrwxrwxrwx root/root 0 2022-11-11 13:08 ./usr/lib/x86_64-linux-gnu/librte_net_af_xdp.so.23 -> dpdk/pmds-23.0/librte_net_af_xdp.so.23 50842 lrwxrwxrwx root/root 0 2022-11-11 13:08 ./usr/lib/x86_64-linux-gnu/librte_net_af_xdp.so.23.0 -> dpdk/pmds-23.0/librte_net_af_xdp.so.23.0 50843 drwxr-xr-x root/root 0 2022-11-11 13:08 ./usr/share/ 50844 drwxr-xr-x root/root 0 2022-11-11 13:08 ./usr/share/doc/ 50845 drwxr-xr-x root/root 0 2022-11-11 13:08 ./usr/share/doc/librte-net-af-xdp23/ 50846 -rw-r--r-- root/root 7584 2022-11-11 13:08 ./usr/share/doc/librte-net-af-xdp23/changelog.Debian.gz 50847 -rw-r--r-- root/root 4250 2022-11-11 13:08 ./usr/share/doc/librte-net-af-xdp23/copyright 50848 drwxr-xr-x root/root 0 2022-11-11 13:08 ./usr/share/lintian/ 50849 drwxr-xr-x root/root 0 2022-11-11 13:08 ./usr/share/lintian/overrides/ 50850 -rw-r--r-- root/root16 2022-11-11 13:08 ./usr/share/lintian/overrides/librte-net-af-xdp23 -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1019589: FYI upgrading to 22.11 which contains these fixes
This has to go through experimental (for dependencies) and NEW queue (new package due to ABI bump). But it is on the way ... -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd
Bug#997178: Build tested and ready as PR
> Hello, just to make sure we are aligned on this bug resolution, thanks for > fixing! > > However, I would like to make sure that this isn't a "silly warning" and that Thanks for pushing it further, the file name is this way due to being auto-created from the upstream commit title.
Bug#1017369: Thanks for the report and the pre-work
Hi, thanks Peter for the report and debdiff. Ack to the d/control dependency change and the d/rules cleanup improvement. For the code changes [1] landed upstream now and I think I'll use that instead. [1]: https://github.com/mdevctl/mdevctl/commit/58cd8604db2e5a3fb9ceb76cbbf09675873cce77
Bug#1013551: fixed by this commit
This FTFBS which - as reported - is good if build from git is fixed by commit 69c911989e4752c3b56851877cfcf7cc6a23bde2 Author: Athos Ribeiro Date: Tue Jun 7 19:44:38 2022 -0300 d/control: depend on librust-uuid+rand-dev for v4 I'll mark that as fixing this bug -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1003777: bug acknowledged
fixed 1003777 1.1.0-2 tags 1003777 +pending
Bug#1003777: Thanks for the report
Hi Martin, yes that dir got lost in the switch to 1.x - thanks for the report. This formerly was created by the upstream build and thereby available automatically. Old users upgrading from e.g. 0.59 would still have it. But indeed the new version lacks that, I'll add the dir to the build so that it is properly created. -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1013551: bug acknowledged
fixed 1013551 1.1.0-2 tags 1013551 +pending
Bug#1013551: probably a transient issue of the rand version upgrade
Hi, sorry that I didn't see that bug earlier :-/ Well better late than never ... I at least saw the removal :-( I had a look and I'm confused by how your re-build broke here. > searched package name: `rand` That should be provided by librust-rand-dev and all its variations. The build dependency is there: - we build depend on librust-uuid+rand-dev - That has Depends: ... librust-rand-0.8+default-dev So therefore it should be around at build time. I checked the last good build [1] and there it did behave as expected installing librust-rand* packages and building fine. The packages are there - rmadison output: librust-uuid+rand-dev | 0.8.1-5 | testing| amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x librust-uuid+rand-dev | 0.8.1-5 | unstable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x librust-rand-dev | 0.8.4-2 | testing| amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x librust-rand-dev | 0.8.4-2 | unstable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x The latter has: Provides: ... librust-rand-0.8+default-dev (= 0.8.4-2) I did a run of sbuild in unstable and testing - both worked just fine. Without digging much further I can only assume that this was a transitional issue while librust-rand went from 0.6.3-2 to the current 0.8.4-2. A simple rebuild should fix this and along the way I can fix another bug that was opened recently. [1]: https://buildd.debian.org/status/fetch.php?pkg=mdevctl=amd64=1.1.0-1%2Bb1=1651440805=1 -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1012814: force merge duplicates
forcemerge 1011633 1012814
Bug#1011633: Clear open-vm-tools duplicates - this is actually asking for 12.0.5
retitle 1011633 Open-vm-tools 12.0.5 has been released
Bug#1012814: Duplicate
Hi, thanks for your report - this is actually already covered by [1] which I just now realized had a bad title saying 12.0.0 instead of 12.0.5 - I fixed that by now. Therefore I'm merging this bug here with [1]. Current state is that it is already fixed in experimental and was just uploaded to unstable. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011633 -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1014749: debian/clean already fixed in git
Turns out the dh_clena issue was already fixed [1] in git (where I checked for trailing /) and not yet in experimental where you and I tested against :-/ Confusion resolved :-) We just need to work on the discussion on the python fixes and then can upload a fixed version. [1]: https://salsa.debian.org/openstack-team/third-party/openvswitch/-/commit/2ab99f31aa60d3056ea76a9085f90398dc0b0587
Bug#1014749: Work in progress
tags 1014749 + confirmed FYI fixes to the python file duplication are proposed and discussed in Salsa at [1] For the d/clean portion I'm still puzzled ... The file already has trailing slashes $ cat debian/clean _debian/ _dpdk/ This works just fine: $ mkdir _debian $ touch debian/foo $ ./debian/rules clean py3versions: no X-Python3-Version in control file, using supported versions dh clean debian/rules execute_before_dh_auto_clean make[1]: Entering directory '/home/paelzer/work/openvswitch/openvswitch' py3versions: no X-Python3-Version in control file, using supported versions find . -name "*.pyc" -delete make[1]: Leaving directory '/home/paelzer/work/openvswitch/openvswitch' dh_clean I ran a full local build via ./debian/rules build which left around what seems like normal directories 2408 tests were successful. 3 tests were skipped. make[5]: Leaving directory '/root/openvswitch-2.17.2/_dpdk' make[4]: Leaving directory '/root/openvswitch-2.17.2/_dpdk' make[3]: Leaving directory '/root/openvswitch-2.17.2/_dpdk' make[2]: Leaving directory '/root/openvswitch-2.17.2/_dpdk' make[1]: Leaving directory '/root/openvswitch-2.17.2' create-stamp debian/debhelper-build-stamp root@k:~/openvswitch-2.17.2# echo $? 0 $ ls -laFd _dpdk _debian drwxr-xr-x 14 root root 26 Jul 12 06:52 _debian/ drwxr-xr-x 14 root root 25 Jul 12 07:10 _dpdk/ A subsequent ./debian/rules clean now did fail ... interesting ... Setting this to confirmed but need to debug what really happens [1]: https://salsa.debian.org/openstack-team/third-party/openvswitch/-/merge_requests/11
Bug#1014749: Thanks
Odd, we had piuparts running as part of the CI pipeline every time. Thank you for the report, we will have a look...
Bug#1007888: Updated fix - PR available
Hi, I agree with Steve that it would overall be useful to have this. I updated his related upload to Ubuntu in regard to the last comments about those fixes that were referred above. Indeed that makes the symbols file more useful and correct (having proper @ _1/_2/_3 mappings). I've kept it all to start at 1.0.2 (where we start tracking symbols) and from here on it should help us to avoid mistakes. I've opened a PR with the combined fix at: https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/merge_requests/7 Hope that helps to discuss or accept this. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#994204: Affects libvirt as well
Hi, almost as expected by some on the bug here this now hits libvirt as well. Recent builds will shutdown guests (via libvirt-guest.service) and fence guests (via virtlogd.service) now. This is due to their postinst having replaced the former safe `start` with `restart` for `--no-stop-on-upgrade` units due to this bug here. For now I had to follow the example of dbus and try to handle the system services that shall not be restarted ourselves (proposed in [1]). The libvirt case even seems slightly worse, as the bug described here also affects `.socket` files which - even if the service isn't restarted - will implicitly re-cycle the related `.service` and thereby cause the same effect. Maybe I'm not deep enough in the reasoning that led to adding this new behavior. But from a bit away it seems wrong that using the `--no-stop-on-upgrade` option no more allows you to "not restart" services through debhelper anymore. And furthermore if we acknowledge that there are valid cases that do not want to be stopped/restarted ever but keep the current `--no-stop-on-upgrade` handling as-is, what would a new option look like '--really-no-stop-on-upgrade'? P.S. Thanks to Mbiebl for helping me to spot this known bug when I was confused about my dying guests and service behavior when testing our new libvirt package builds. [1]: https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/132 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1001466: FYI - upstream request to support 21.11
Since Ubuntu needs to move to 21.11 sooner I filed a bug upstream which you might want to track as well: => https://github.com/EttusResearch/uhd/issues/547 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#990660: Is this really a file owned/created by the package?
tags 990660 + moreinfo unreproducible Hi Christoph, The package installs /etc/vmware-tools/tools.conf since 2007.09.04-56574-1 It was never moved or removed since then and still is present these days. Being a conffile if you had modifications it would have stayed as-is. And even if we would have moved it, then dpkg-maintscript-helper would have suffixed the remainders with .dpkg-*. I didn't find anything in the git log of the open-vm-tools package, not around 2011 nor elsewhere. I might miss a potential path how this was created, but right now to me it seems this was not created by the package and thereby the package is not supposed to remove it (not even on purge) Do you happen to know/see how/when this file was created in the first place? -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#976686: This issue is happening again (as forecast by the bug report)
Hi, I just wanted to mention that 1.30.4-6.1+b4 still is affected (as there were no changes since then) and right now glom exposed that issue when rebuilt in debian/sid. Binaries currently in Sid: root@d10-sid:~# objdump -p /usr/bin/glom | grep python NEEDED libpython3.9.so.1.0 NEEDED libboost_python39.so.1.74.0 No change rebuilt in Sid: (unstable-amd64-sbuild)root@Keschdeichel:/build/glom-tXBWCg/glom-1.30.4# objdump -p ./glom/.libs/glom | grep python NEEDED libpython3.9.so.1.0 NEEDED libboost_python310.so.1.74.0 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#931470: Fixed in 7.5
fixed 931470 7.6.0-1 Hi, I came across the same issue in Ubuntu [1] and realized that it was fixed upstream by now. The fix is [2] and part of v7.5.0 Since v7.6.0 is in Debian testing and unstable this can be considered fixed by now I think. [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1881969 [2]: https://gitlab.com/libvirt/libvirt/-/commit/4f2811eb816ed1da215b86778dfcf483917666a1 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#997178: Build tested and ready as PR
Hi, I have opened PR [1] which fixes this (without the full bump to the new ABI) [1]: https://salsa.debian.org/debian-gps-team/pkg-gpsd/-/merge_requests/11 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#997178: FYI - Patch is upstream
Hi, I just wanted to say that the patch for this is upstream [1] so we could either pick it as-is (as I know there were often enough problems with the ABI making it hard to move) or even go for the new version. $ git tag --contains 283fc17de8 release-3.23.1 [1]: https://gitlab.com/gpsd/gpsd/-/commit/283fc17de89f666d16b8cef45e7b8ecd602927cf -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1000431: Suggested change in sals
FYI I submitted a PR that disables this via salsa at https://salsa.debian.org/d-team/ldc/-/merge_requests/3 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1000431: Please consider disabling LDC_DYNAMIC_COMPILE
Package: ldc Version: 1:1.28.0-1+b1 Hi, with llvm >=12 you will be forced to disable LDC_DYNAMIC_COMPILE and thereby libldc-jit.so. The background of this is that the used ORCv1 API was dropped in that newer llvm version. But in addition the discussion on the related upstream issue to support ORCv2 [2] revealed that it was only meant to be a personal experiment, so it might generally (even before llvm >=12) be a good idea to disable LDC_DYNAMIC_COMPILE. [1]: https://github.com/ldc-developers/ldc/commit/d8bc064cfbc766347d563cb139a72d238312bd38#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20a [2]: https://github.com/ldc-developers/ldc/issues/3747 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1000388: Fix as PR
Available on salsa at https://salsa.debian.org/gkarsay/parlatype/-/merge_requests/2 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#1000388: FTBFS on s390x due to whitespace damage
Package: parlatype Version: 3.0-1 Build is currently broken like here [1] dpkg-buildpackage: info: host architecture s390x debian/rules clean debian/rules:19: *** missing separator. Stop. It is odd that this is only happening on s390x, but it is in fact whitespace damage. The rules do not start all lines with tabs, some are mixed space/tabs and that causes this. I'll open an MP with the (trivial) fix once I have a bug reference. [1]: https://buildd.debian.org/status/fetch.php?pkg=parlatype=s390x=3.0-1=1637515334=0 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#998600: Confirmed and fix verified
tags 998600 + confirmed fixed pending I was able to confirm the FTBFS and also that the 1.1.0-1 that I prepared has fixed it. I'll mark it in the changelog and upload it later. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#998600: Ack
Thanks for the rebuild report Lucas, I'll have a look. I was working on 1.1.0 anyway and thereby should be able to resolve this. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#999619: Confirmed to be caused by tcmalloc that is default in 10.0
Hi, I was able to confirm that rebuilding glusterfs without tcmalloc (now also on x86) fixes this issue. Debugging revealed that this is due to tgt late dlopening optional storage backends. So if you have some of them installed like packages tgt-rbd + tgt-glusterfs they will initialize late. Since glusterfs now will pull in tcmalloc when doing so it will late-override symbols and we have a conflict of allocations by libc and tcmalloc leading to this crash. I've found many similar issues: - https://github.com/gperftools/gperftools/issues/1066 - https://github.com/kcat/openal-soft/issues/134 - https://tracker.ceph.com/issues/23653 - https://bugzilla.redhat.com/show_bug.cgi?id=1569391 The already linked Ubuntu bug also has some more debugging data for those curious about it, but the TL;DR seems to be: "using tcmalloc in a lib (like libgf* of glusterfs) is calling for issues as anyone loading it late or multiple of them will likely crash the program." Therefore this needs the same fix done for [1], just dropping the arch restriction. I'll NMU upload this based on Patrick's request to resolve 999700 as NMU [2] since this one here is essentially the same issue but on x86. Once he is back he can have a look (or discuss with upstream) if there is a way to re-enable tcmalloc without causing all these issues. Attached is the debdiff that will implement this. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999700 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999700#15 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd fix-tcmalloc-x86-debian-999619.debdiff Description: Binary data
Bug#999619: Some debugging info - also about tcmalloc
Hi, the log messages are misleading at best, when reproducing in autopkgtest in a local VM I've found: $ sudo /usr/sbin/tgtd -f tgtd: iser_ib_init(3431) Failed to initialize RDMA; load kernel modules? tgtd: work_timer_start(146) use timer_fd based scheduler src/tcmalloc.cc:333] Attempt to free invalid pointer 0x55abdf028b00 Aborted It is only glusterfs, as this resolves the issue: $ sudo apt remove tgt-glusterfs $ sudo /usr/sbin/tgtd -f tgtd: iser_ib_init(3431) Failed to initialize RDMA; load kernel modules? tgtd: work_timer_start(146) use timer_fd based scheduler tgtd: bs_init(387) use signalfd notification This sounds very much like https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1950777 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999700 Reported the same to Ubuntu under https://bugs.launchpad.net/debian/+source/glusterfs/+bug/1951126 and hoping to find some time for it tomorrow. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#999700: tcmalloc in glusterfs 10 breaks on arm64 and s390x
On Mon, Nov 15, 2021 at 11:41 AM Patrick Matthäi wrote:
>
> Thanks for your detailed Report. I am cirrently in vacation Till the 25.,
> Maybe you could NMU it? 0-day welcome
Sure, enjoy your Vacation!
> Am 15.11.2021 11:04 schrieb Christian Ehrhardt
> :
>
> Package: glusterfs
> Version: 10.0-1
>
> Hi,
> as found in Fedora [1] and Ubuntu [2] the default usage of tcmalloc in
> glusterfs 10 [3] is causing issues.
>
> One example consequence is libvirt which thereby has become an FTBFS in sid.
> But there might be much more failing due to that as essentially it can
> not be dlopen'ed at all there.
>
> AFAICS it fails on arm64 and s390x, maybe more architectures are
> affected as I couldn't test them all.
>
> A simplified reproducer is this (on s390x):
>
> $ apt install libglusterfs-dev gcc
> $ cat gtest.c
> #include
> #include
> #include
>
> int main(int argc, char **argv)
> {
> void *h = dlopen("/usr/lib/s390x-linux-gnu/libglusterfs.so.0", RTLD_NOW);
> if (!h) fprintf (stderr, "dlerror = %s\n", dlerror());
> return 0;
> }
> $ gcc -Wall gtest.c -o gtest -ldl -g
> $ ./gtest
> $ ./gtest
> dlerror = /lib/s390x-linux-gnu/libtcmalloc.so.4: cannot allocate
> memory in static TLS block
>
> Until this is resolved more in depth I'd suggest to follow Fedora [1]
> and disable tcmalloc on non-amd64 (which will make it use the former
> gluster mempool on those).
>
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2018439
> [2]: https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1950777
> [3]:
> https://src.fedoraproject.org/rpms/glusterfs/c/80badd1442cc0de438a78d0c35a7d11377e72bea?branch=rawhide
>
> --
> Christian Ehrhardt
> Staff Engineer, Ubuntu Server
> Canonical Ltd
>
>
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
Bug#999700: NMU upload
FYI - Patrick asked me to do an NMU of this, which I have now uploaded. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#999700: patch to mitigate the issue
Hi, attached is a patch to disable tcmalloc on non-x86 (as done by Fedora) which I already successfully tested on Ubuntu builds and it fixes dependent usage e.g. by Libvirt in all my tests. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd gluster-tcmalloc.debdiff Description: Binary data
Bug#999700: tcmalloc in glusterfs 10 breaks on arm64 and s390x
Package: glusterfs
Version: 10.0-1
Hi,
as found in Fedora [1] and Ubuntu [2] the default usage of tcmalloc in
glusterfs 10 [3] is causing issues.
One example consequence is libvirt which thereby has become an FTBFS in sid.
But there might be much more failing due to that as essentially it can
not be dlopen'ed at all there.
AFAICS it fails on arm64 and s390x, maybe more architectures are
affected as I couldn't test them all.
A simplified reproducer is this (on s390x):
$ apt install libglusterfs-dev gcc
$ cat gtest.c
#include
#include
#include
int main(int argc, char **argv)
{
void *h = dlopen("/usr/lib/s390x-linux-gnu/libglusterfs.so.0", RTLD_NOW);
if (!h) fprintf (stderr, "dlerror = %s\n", dlerror());
return 0;
}
$ gcc -Wall gtest.c -o gtest -ldl -g
$ ./gtest
$ ./gtest
dlerror = /lib/s390x-linux-gnu/libtcmalloc.so.4: cannot allocate
memory in static TLS block
Until this is resolved more in depth I'd suggest to follow Fedora [1]
and disable tcmalloc on non-amd64 (which will make it use the former
gluster mempool on those).
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2018439
[2]: https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1950777
[3]:
https://src.fedoraproject.org/rpms/glusterfs/c/80badd1442cc0de438a78d0c35a7d11377e72bea?branch=rawhide
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
Bug#998532: in progress
Hi, I found the same today when working on 21.11 This is caused by [1] removing the option quite a while ago. It was a no-op since then but now became fatal. It can just be removed, doing so in my 21.11 branch and from there we can then consider backports as/if needed. [1]: https://github.com/DPDK/dpdk/commit/cba806e07d6f7e6cfa9749346f2dc75288f984f7 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#998309: Thanks
Thank you Guillem Jover for the quick and great response to this! -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#998309: Please mark the package as non-lto compatible
Package: libaio Version: 0.3.112-11 Hi, Debian hasn't enabled LTO by default yet, but could do that later. So far libaio isn't compatible with LTO, see this upstream issue [1]. Ubuntu has enabled LTO by default and that made us add this little delta. Adding this in Debian will ease the maintenance of the Ubuntu package and help you to avoid an issue once LTO is enabled either by default or by someone testing the PKG build with alternative options. In a Debian build this option is a no-op, so right now it doesn't change anything. Here is a build-log with this applied [2] (Debian pastebin refused it for being spam). As mentioned the change needed is rather minimal and available for you to cherry pick here [3]. [1]: https://pagure.io/libaio/issue/10 [2]: https://paste.ubuntu.com/p/MsXXGP9WRH/ [3]: https://git.launchpad.net/~paelzer/ubuntu/+source/libaio/commit/?id=dfb28c74fcecde4ee117656cec01431d92b1c76e -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#986575: FYI: Upstream issue and suggested fix
Hi, I've seen the same issue and think I found the root cause. I filed it upstream at https://github.com/mdbtools/mdbtools/issues/352 TL;DR the problem is the "potential" not the actual NULL that is passed to printf. This triggers the new error case detection in the newer toolchain and breaks the build. The upstream report also contains a suggestion to fix it that worked in a local try on ppc64. Hope that helps to resolve this. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#995248: umockdev 0.16.3-1 breaks autopkgtest of bolt
Package: umockdev Version: 0.16.3-1 Hi, the new version fails the tests of bolt as seen at https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz That crash seem weird, but it actually is only an effect of a fail with a mocked directory. The bolt tests would behave the same way if not mocked at all. The root cause for this is in this change in 0.16.3 https://github.com/martinpitt/umockdev/commit/5e829601434 That breaks the bolt tests here https://gitlab.freedesktop.org/bolt/bolt/-/blob/master/tests/mock-sysfs.c#L183 Due to $tmp/sys/bus now already existing the g_mkdir fails and that breaks the test. So we either need to stop umockdev from doing that (but that will re-break whatever it fixed) or we need to teach bolt tests to be ok, if the directory already exists. I can't make the call which approach is better, but since Pitti owns this Debian package and upstream I hope he will see this bug and make the call where to better fix it. P.S. I have started to analyze this in Ubuntu, so there is a related bug and I'd appreciate a bug ref in the changelog if there is an upload for this. => https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/1945321 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#984009: Fix is upstream available
Hi, I had a look at this today and found that this is a known and expected change as it is part of a set of deprecations scheduled for removal in 2018 [1]. The page holds hints how to replace this, but actually upstream has already a commit that fixes the problem [2]. Would be great to add that or just rebase to a newer git snapshot that includes this. [1]: https://dlang.org/changelog/2.075.0.html#pattern-deprecate [2]: https://github.com/theyamo/CheeseCutter/commit/68d6518f0e6249a2a5d122fc80201578337c1277 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#984272: FYI - fixed in 11.3.0
fixed 984272 2:11.3.0-1 Hi, just as an FYI the gcc-11 FTBFS is fixed in 11.3.0 which is in experimental. I guess that will finally be marked fixed together with 990163 once 11.3 moves to unstable/testing. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#992029: qemu-system-x86: microvm binary has no virtio device emulation
> qemu-system-x86_64-mircovm binary has no virtio device emulation. Yeah it is pretty minimal as - after all - this is what it is about. > $ qemu-system-x86_64-microvm -device ? |grep virtio | grep -v pci > name "vhost-user-fs-device", bus virtio-bus > name "virtio-serial-device", bus virtio-bus > name "vhost-user-vsock-device", bus virtio-bus > name "vhost-vsock-device", bus virtio-bus This somewhat intentional as it is what you get with --without-default-devices which is the root of the microvm thought. And you also see how the devices that are present match the competitors in the same space like firecracker - serial/user-fs/vsock is almost an exact match to that. > I want to use device emulations on qemu-system-x86_64-microvm, > virtconsole > virtio-blk-device > virtio-net-device > virtio-balloon-device > virtio-rng-device I agree that some of them may be in the scope of a microvm. blk / net / rng - I think those have valid use cases - not too aligned to firecracker but in a minimal VM. Balloon IMHO might be too much, OTOH microvms are even more about density than usual VMs so maybe it is ok. You see I'm torn ... Eventually the microvm examples at https://github.com/bonzini/qemu/blob/master/docs/system/i386/microvm.rst use virtio-blk-device and virtio-net-device, so that might suggest some "agreement" with your request. OTOH I'm still somewhat afraid that if we add devices with each request that is valid on its own we end up with another full qemu. And TBH I'd not even know if there are configure flags to enable those after --without-default-devices, might be a set of messing with config-target.h which sounds wrong. Maybe one should even first start a discussion with Paolo about what set of devices would be "the right ones" to configure for a microvm instead of us and maybe others changing it every now and then. TL;DR I appreciate the bug and discussion but I'm unsure how to continue on this :-/ Michael do you have a strict opinion on this other than not being 100% convinced of the microvm approach in the first place?
Bug#991360: FYI build and manual test ok
Hi, Build in unstable [1] and manual testing of the formerly failing firewalld testcase (as it does skip in debci) worked. So to me it looks good to go other than the aging period. That is the state we wanted it to be as Arturo and myself will then be unavailable for a while. But due to that, if anything comes up and only a minor/trivial bump of any kind is needed I'd ask to do so instead of waiting for us. [1]: https://buildd.debian.org/status/package.php?p=nftables -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#986488: Further test issues on s390x
Hi - as an FYI on s390x tests https://ci.debian.net/data/autopkgtest/unstable/s390x/p/pyspread/13200913/log.gz there are further test issues of the new tests added in 1.99.6 I've reported them upstream at https://gitlab.com/pyspread/pyspread/-/issues/93 To fix the test is easy (just drop the special case for not little endian), but while I'm 95% sure that is fine I'm lacking the final 5% and would want to have upstreams answers to it before suggesting to change this in freeze time. P.S. I'm unsure if a second forwarded tag might cause problems and this issue is related but not necessarily considered the very same, so I'm intentionally NOT adding a new forwarded tag. Test fail log: __ test_RGB32 __ def test_RGB32(): qimg = QtGui.QImage(320, 240, QtGui.QImage.Format_RGB32) qimg.fill(0) v = _qimageview(qimg) qimg.fill(23) qimg.setPixel(12, 10, QtGui.qRgb(0x12, 0x34, 0x56)) assert_equal(v.shape, (240, 320)) assert_equal(v[10, 10], 23 | 0xff00) > assert_equal(v[10, 12], 0xff123456 if sys.byteorder == 'little' else 0x563412ff) pyspread/lib/test/test_qimageview.py:145: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ a = 4279383126, b = 1446253311 def assert_equal(a, b): > assert a == b E assert 4279383126 == 1446253311 pyspread/lib/test/test_qimageview.py:72: AssertionError _ test_ARGB32 __ def test_ARGB32(): qimg = QtGui.QImage(320, 240, QtGui.QImage.Format_ARGB32) qimg.fill(0) v = _qimageview(qimg) qimg.setPixel(12, 10, QtGui.qRgb(0x12, 0x34, 0x56)) assert_equal(v.shape, (240, 320)) > assert_equal(v[10, 12], 0xff123456 if sys.byteorder == 'little' else 0x563412ff) pyspread/lib/test/test_qimageview.py:156: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ a = 4279383126, b = 1446253311 def assert_equal(a, b): > assert a == b E assert 4279383126 == 1446253311 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#991309: Uploaded and filed an unblock bug
FYI, I got the expected mail "nftables_0.9.8-3.1_source.changes ACCEPTED into unstable" And I filed an unblock bug for it at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991360
Bug#991360: unblock: nftables/0.9.8-3.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: Arturo Borrero Gonzalez Please unblock package nftables [ Reason ] Fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991309 Under certain conditions nftables tends to be greedy and can delete too much rules. This was identified via an issue to firewalld which had a test that failed on it [1] but was then found and fixed in nftables [2]. [ Impact ] The change looks bigger than it is as it moves code around to be available earlier in the code. It really comes down to dependency killing of rules and should not have a different impact to nftables than that. [ Tests ] While the Debian tests skip the tests e.g. of firewalld [3] I have uploaded the same to Ubuntu where all the tests (including those that failed due to the issue) already completed. On this upload the debci will again skip the tests that would have flagged this bug, others will run but they have worked before and will afterwards. [ Risks ] I'd hope that it is low as it is not just from git, but also part of an official release (0.9.9) already. We don't want to bump versions so late, but this gives some extra confidence in the testing that was done. As mentioned above the risk should be limited to the dependent rule removal. [ Other info ] * I've prepared a debdiff (attached) which matches testing vs unstable at the moment that the request here asks to unblock. * The unstable version has just been uploaded, please give it some time to build and be tested (by tools and myself), but I wanted to give a heads up as early as possible. P.S. The usual maintainer asked for an NMU and driving the unblocking, details on the bug we fix that is linked above. [1]: https://github.com/firewalld/firewalld/issues/752 [2]: https://git.netfilter.org/nftables/commit/?id=533565244d88a [3]: https://ci.debian.net/data/autopkgtest/testing/amd64/f/firewalld/13738304/log.gz -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd fix-debian-991309.debdiff Description: Binary data
Bug#991309: FYI Merge Request open
As discussed I have provided you the content as MR at [1] and will upload this as NMU now. [1]: https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/merge_requests/6 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#991309: Copy from IRC
I wanted to document somewhere that this is a pre-acknowledged NMU, just in case someone else looks at it and wonders. [14:08] Hi, I've recently filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991309 but Arturo said (on the bug) that he is short of time. I wanted to ask the release team about their jdgement if this is worth an NMU followed by tests+unblock bug OR if that should be fine to wait after the release [14:08] I'd appreciate an update on the bug, but otherwise answer here and I can copy it over [14:09] thanks for paying attention to this cpaelzer [14:51] cpaelzer: (not a member of the release team) The release team prefers to discuss this in bugs, "reportbug release.debian.org" and then attach the debdiff from the bug. (looking at the diff, I'd expect it gets accepted without problem) [15:14] arturo: when prep the unblocker it is almost no difference in the amount of work for me to also do an NMU of it to unstable - are you (in general) ok with me doing that? [15:15] arturo: and if so would you mind to branch off a bullseye branch from https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/tags/debian%2F0.9.8-3 - if you do so I can throw you a MR to integrate (later if you want) what I prepare for you [15:35] cpaelzer: yes to all (sorry, I'm having food ATM) Also I can confirm that in the meantime the very same change was built and tested fine in Ubuntu [1] and migrated there. I know it isn't the same, but it is one more bit of confidence that the change should be ok. [1]: https://launchpad.net/ubuntu/+source/nftables/0.9.8-3ubuntu1 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#991309: suggested fix
> Thanks for the detailed bug report and the debdiff! > > Unfortunately I wont be able to handle this until September because summer > vacations. No problem ... > the required permissions. Even with this, I can't promise anything. TBH I'm not a 100% sure on the severity, it could be super-bad or not. But the bug has all that is needed to do an upload for any DD. I understand that the process is requesting a lot right now since we are in final freeze. Maybe the usual flow of actions should be inverted here, let us first ask the release team if they think this is a fix they would want to have in the coming release. If they say it is fine without then you don't have to do anything, and can pick it up early in the next release when you have time. If OTOH they say that they'd want the fix in bullseye then you still don't have to do anything. I could do a NMU for it and file an unblock bug later this week. But I have to admit that I'm myself out for some time starting after this Friday, so it is now or never :-) I'll ping on #debian-release and ask them to do an update on this bug to state their opinion on this.
Bug#986488: Forwarded and Fix proposed
Forwarded: https://gitlab.com/pyspread/pyspread/-/issues/92 Hi, I was looking into this today and eventually reported it upstream [1]. I have found what it IMHO is and provided a fix for it [2]. Let us see what upstream thinks, but if you want to un-break pyspread now feel free to do so already. [1]: https://gitlab.com/pyspread/pyspread/-/issues/92 [2]: https://gitlab.com/pyspread/pyspread/-/merge_requests/36 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#977805: FYI - Fixed in 4.2
Tags: fixed-upstream Hi, while looking at this FTFBS I've found that the new upstream version 4.2 [1] would fix this problem. I found no clear documentation on how the dfsg was generated (some vendored libs removed, some not), so I had the feeling "just trying" might make things worse. But I wanted to pass this FYI to the bug to avoid anyone to re-debug this. The timeline/reason for all of this this is: Dec 2019 - ndpi 3.0 / ntopng 3.8.1 uploaded by the maintainer June 2020 - ntopng removed for blocking ndpi [2] Winter 20/21 - various helpful people bumped ndpi for CVEs and some bug fixes But the new ndpi makes ntopng an FTFBS. And in turn the old ntopng would block ndpi. Bonus: Also AFAICS ndpi (lib) only exists (from the Archives POV) for ntopng, so there is almost no gain for it to stay around alone. [1]: https://github.com/ntop/ntopng/releases/tag/4.2 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953181 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#991309: suggested fix
Since there is no branch from debian/0.9.8-3 yet to propose against here a suggested fix as a debdiff. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd fix-nftables-991309.debdiff Description: Binary data
Bug#991309: nftables 0.9.8 regresses icmp rule deletion
Package: nftables Version: 0.9.8-3 Tags: fixed-in-experimental Hi, I wanted to raise awareness for an issue [1] that was originally filed by Michael Biebl but not further pursued in the nftables package AFAICS. In Debian CI that isn't obvious as the tests are all skipped https://ci.debian.net/data/autopkgtest/testing/amd64/f/firewalld/13738304/log.gz But the Ubuntu CI flags the issue https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/f/firewalld/20210510_135128_36f9c@/log.gz I was looking into the case in [2] and found that in the meantime there is a fix for that [3] available upstream. I see that there is nftables 0.9.9-1~exp1 in experimental and I have tagged this bug as fixed there. Surely we would not want to move to 0.9.9 in the current release while in the final freeze. But given that it would be a regression for upgraders buster->bullseye I wonder if the isolated patch [3] should maybe be applied. I have done so in an Ubuntu PPA [4] and re-run the firewalld tests against it. Those tests - and in general the issue of deleting too many icmp rules - is fixed by that. [1]: https://github.com/firewalld/firewalld/issues/752 [2]: https://bugs.launchpad.net/ubuntu/+source/nftables/+bug/1936902 [3]: https://git.netfilter.org/nftables/commit/?id=533565244d88a818d8828ebabd7625e5a8a4c374 [4]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4626/+packages -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#991300: 1:0.4.30-1 is FTFBS on s390x (bytes per pixel in header is 4096 instead of 16)
Package: gegl Version: 1:0.4.30-1 Hi, I saw this build fail in Debian and Ubuntu today: https://buildd.debian.org/status/fetch.php?pkg=gegl=s390x=1%3A0.4.30-1=1626634928=0 https://launchpadlibrarian.net/549105404/buildlog_ubuntu-impish-s390x.gegl_1%3A0.4.30-1_BUILDING.txt.gz It comes down to two breaking testcases 118/249 gegl:composition / hdr_color FAIL 0.67s (exit status 250 or signal 122 SIGinvalid) 150/249 gegl:composition / rgb_params FAIL 0.67s (exit status 250 or signal 122 SIGinvalid) I have found that on s390x the data gets corrupted and the header eventually reports 4096 bytes per pixel (instead of the 16 it should be). That then breaks the imgcmp program used in the tests. I have reported the issue upstream at: https://gitlab.gnome.org/GNOME/gegl/-/issues/289 The same issue is tracked in Ubuntu as: https://bugs.launchpad.net/gegl/+bug/1936901 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#976808: Solved in qemu 6.0
Tags: fixed-in-experimental Hi, this was fixed by [1] which is available in experimental qemu | 1:6.0+dfsg-1~exp0| experimental | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x It is thereby fixed, although to fully be available you'll need to wait for a backport or the next Debian release. [1]: https://git.qemu.org/?p=qemu.git;a=commit;h=8eb13bbbac08aa077e -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#990559: Please unblock package mdevctl 0.81-1
On Sun, Jul 4, 2021 at 9:46 PM Sebastian Ramacher wrote: > > Control: tags -1 moreinfo > > On 2021-07-02 07:37:22 +0200, Christian Ehrhardt wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > Hi, > > please unblock mdevctl 0.81-1. > > > > It fixes a problem with an allowed combined usage two parameters. > > v0.78 -> 0.81 sounds a lot, but that is due to the way upstream creates > > versions which essentially is a counter of git commits. > > Therefore the only real change is [1] which should be ok for the freeze > > time. > > > > There are two packaging-only changes which I had in git but not > > uploaded yes (as they didn't qualify for an upload without any fix. > > But both are no-impact changes (compat level while the package has not much > > that is affected by it and the drop of the unused d/source/local-options. > > > > The builds all LGTM, see [2]. I have installed the new build and it works > > as expected: > > > > Before > > # mdevctl define -p 0.0.0033 --jsonfile mdev_nodedev.json > > /usr/sbin/mdevctl: line 183: > > /etc/mdevctl.d/0.0.0033/eea1c8dc-ce6d-42dd-bd26-02e3b707ff95: No such > > file or directory > > After > > # mdevctl define -p 0.0.0033 --jsonfile mdev_nodedev.json > > 83123a52-3147-44d1-9154-1175e266804e > > > > The package has no autopkgtests as they would be superficial and not much > > worth or would need mdev splittable GPUs or such on the test systems which > > we > > can not assume/expect to have. Therefore I need to ask you via this ubblock > > request. I hope that this is sufficient to unblock, if you need anything > > else please let me know. > > > > [1]: https://github.com/mdevctl/mdevctl/commit/e6cf620b4b04c6 > > [2]: > > https://buildd.debian.org/status/fetch.php?pkg=mdevctl=all=0.78-1=1606290427 Hi Sebastian, I missed your question before today, so sorry for the delay in clarifying this. > Please attach a debdiff between the version in testing and unstable. Attached is the debdiff "mdevctl-to-0.81.debdiff" as requested. > Regarding the packaging changes: it's too late to bump debhelper compat. > See https://release.debian.org/bullseye/freeze_policy.html. Please > revert that change (or show that the change does not cause any > differences in the produced binary packages). Furthermore in regard to compat I have extracted the full content and control of 0.78 and 0.81 locally (with dpkd -x and -e out of the debs in the archive). You can see in the attached "effective-changes.diff" that the only changes are only: - version number - wanted fix in lsmdev (link to mdevctl, so it is the same change in two places) - wanted fix in mdevctl - changelog binary AFAICS there are no unexpected changes built into the binaries or the maintainer scripts. > Cheers > -- > Sebastian Ramacher -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd diff -Naur 0.78/content/usr/sbin/lsmdev 0.81/content/usr/sbin/lsmdev --- 0.78/content/usr/sbin/lsmdev 2020-11-25 07:02:19.0 + +++ 0.81/content/usr/sbin/lsmdev 2021-07-01 14:07:15.0 + @@ -3,7 +3,7 @@ persist_base=/etc/mdevctl.d mdev_base=/sys/bus/mdev/devices parent_base=/sys/class/mdev_bus -version="0.78" +version="0.81" # Alias 'lsmdev' to 'mdevctl list' if [ $(basename $0) == "lsmdev" ]; then @@ -609,6 +609,7 @@ exit 1 fi +mkdir -p "$persist_base/$parent" write_config "$persist_base/$parent/$uuid" if [ $? -ne 0 ]; then exit 1 diff -Naur 0.78/content/usr/sbin/mdevctl 0.81/content/usr/sbin/mdevctl --- 0.78/content/usr/sbin/mdevctl 2020-11-25 07:02:19.0 + +++ 0.81/content/usr/sbin/mdevctl 2021-07-01 14:07:15.0 + @@ -3,7 +3,7 @@ persist_base=/etc/mdevctl.d mdev_base=/sys/bus/mdev/devices parent_base=/sys/class/mdev_bus -version="0.78" +version="0.81" # Alias 'lsmdev' to 'mdevctl list' if [ $(basename $0) == "lsmdev" ]; then @@ -609,6 +609,7 @@ exit 1 fi +mkdir -p "$persist_base/$parent" write_config "$persist_base/$parent/$uuid" if [ $? -ne 0 ]; then exit 1 diff -Naur 0.78/content/usr/share/doc/mdevctl/changelog.Debian.gz 0.81/content/usr/share/doc/mdevctl/changelog.Debian.gz --- 0.78/content/usr/share/doc/mdevctl/changelog.Debian.gz 2020-11-25 07:02:19.0 + +++ 0.81/content/usr/share/doc/mdevctl/changelog.Debian.gz 2021-07-01 14:07:15.0 + @@ -1,2 +1,3 @@ - ? ??M??0???#
Bug#868273: The newer files indeed need cleanup
Now I'm having a look at the two new suspects that you reported. /etc/vmware-tools/vm-support /etc/vmware-tools/guestproxy-ssl.conf I agree they exist, but they are not orphaned. You can still remove them (you need purge since they are config files) as dpkg remembers that they belong to that package. After clarifying that those were not added by the package itself I tracked down my assumption that upstreams install has placed and added them. That is true for a few of them. /etc/vmware-tools/guestproxy-ssl.conf Was indeed dropped by 11.0.0 via [1] This was meant to go away, so I agree we should remove it now. And /etc/vmware-tools/vm-support was dropped by 11.1.0 via [2] This has a new place in /bin - I guess if we try to use mv_conffile or similar for that we make it worse - since this is long gone already we should just rm_conffile it. For those two I'll add an rm_conffile in the 11.3.0 branch that I'm preparing for Bernd. I'll consider the bug done by that, but please let me know if there are really any relevant package upgrade paths anywhere which contain the two initially reported files. [1]: https://github.com/vmware/open-vm-tools/commit/49eb56393323c9344d10313d104bf20630813578 [2]: https://github.com/vmware/open-vm-tools/commit/00d44381a374d60245f286a3faaf3be678a8 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#868273: File /etc/xdg/autostart/vmware-user.desktop still matters
Hi, this seems still owned: # dpkg -S /etc/xdg/autostart/vmware-user.desktop open-vm-tools-desktop: /etc/xdg/autostart/vmware-user.desktop So that one IMHO isn't obsole. And AFAICS it is that way for a long time already. A very long ago it was part of another package. The timeline is 2007.09.04-56574-1: install -D -m 0644 debian/config/vmware-user.desktop debian/open-vm-tools/usr/share/autostart/vmware-user.desktop 2008.06.03-96374-2 Then made it part of open-vm-toolbox 2:9.2.3-1031360-2 Moved it to open-vm-tools-desktop debian/2%9.4.0-1280544-7 Moved it to open-vm-tools-desktop in a new style and under /etc/xdg path that we have today Since even oldoldstable is at 2:9.4.6-1770165-8 I don't see any reasonable upgrade path with anything left from that. And as explained above the path "/etc/xdg/autostart/vmware-user.desktop" still is in use. And some remains of that that needed cleanup were resolved long ago in bug 639811. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#868273: File /etc/modprobe.d/open-vm-tools.conf seems to have never existed in the package
You'd think that the file "/etc/modprobe.d/open-vm-tools.conf" really is gone. Timeline: This is from debian/2%8.8.0+2012.05.21-724730-2 It moved from package open-vm-tools-dkms to open-vm-tools in debian/2%9.4.6-1770165-3 It was dropped in debian/2%10.0.0-3000743-1 Even oldstable already has 2:10.1.5-5055683-4+deb9u2 so this also is quite long ago. But in more detail, all that was about file /lib/modules-load.d/open-vm-tools.conf Being in /lib made it a non-conffile so it was removed correctly. The file you reported seems to never have existed in the packaging. I looked further and found that upstream once had such files created and added in their scripts and that way it might have slipped in. But all of that still was part of the dkms/module handling that is long gone. There were a bunch of other /etc/modprobe.d/vm* files, also all long gone. The only mention in upstream code for this is on their error-collection in `vm-support` - but not as a file deployed. I'm tempted to assume that "/etc/modprobe.d/open-vm-tools.conf" was from maybe a howto or a guid on the internet - or from a non-archive build of the tool? Again - I tried, but my analysis might be wrong. Do you happen to know exactly where this is from - maybe a package version that still contained this? -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#990559: Please unblock package mdevctl 0.81-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, please unblock mdevctl 0.81-1. It fixes a problem with an allowed combined usage two parameters. v0.78 -> 0.81 sounds a lot, but that is due to the way upstream creates versions which essentially is a counter of git commits. Therefore the only real change is [1] which should be ok for the freeze time. There are two packaging-only changes which I had in git but not uploaded yes (as they didn't qualify for an upload without any fix. But both are no-impact changes (compat level while the package has not much that is affected by it and the drop of the unused d/source/local-options. The builds all LGTM, see [2]. I have installed the new build and it works as expected: Before # mdevctl define -p 0.0.0033 --jsonfile mdev_nodedev.json /usr/sbin/mdevctl: line 183: /etc/mdevctl.d/0.0.0033/eea1c8dc-ce6d-42dd-bd26-02e3b707ff95: No such file or directory After # mdevctl define -p 0.0.0033 --jsonfile mdev_nodedev.json 83123a52-3147-44d1-9154-1175e266804e The package has no autopkgtests as they would be superficial and not much worth or would need mdev splittable GPUs or such on the test systems which we can not assume/expect to have. Therefore I need to ask you via this ubblock request. I hope that this is sufficient to unblock, if you need anything else please let me know. [1]: https://github.com/mdevctl/mdevctl/commit/e6cf620b4b04c6 [2]: https://buildd.debian.org/status/fetch.php?pkg=mdevctl=all=0.78-1=1606290427 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#990535: Problem when using -p (parent) and json content together
Package: mdevctl Version: 0.78-1 There is a problem when using -p (parent) and json content together as it misses a directory and fails. While it will be more of a problem with libvirt 7.3 and later which we won't have in this release it still is an issue that people might face today when working with mdevctl on the command line. This is fixed by [1] which is the only functional change of 0.78 -> 0.81. I think it would be worth to fix this before the current release and it would qualify as fix-only. P.S. This will also pick up the non-uploaded changes in git of 0.78-2 but those are also non critical in regard to the freeze. [1]: https://github.com/mdevctl/mdevctl/commit/e6cf620b4b04c6a5826473f1ffecbc6ea05665ef -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#989410: FYI recent master fixes these issues
Hi, from working at a related s390x issue in Ubuntu [1] I can confirm that the recent fixes in nss master resolve this issue. Upstream bug [2], fixes [3][4] If you can't just wait for 3.67 I hope that FYI will help you to fix it. [1]: https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1931104 [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1566124 [3]: https://github.com/nss-dev/nss/commit/32ebd26354548fc3f883a56e8bfafc78f5265ce8 [4]: https://github.com/nss-dev/nss/commit/73b47b7cb5133302087980ef321a83670d383db1 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#989647: With glib2 2.68 gdebi is an FTBFS (hangs)
Package: gdebi
Version: 0.9.5.7+nmu5
At build time it is getting stuck until a timeout kills it:
For example in Ubuntu here:
https://launchpadlibrarian.net/542966965/buildlog_ubuntu-impish-amd64.gdebi_0.9.5.7+nmu5_BUILDING.txt.gz
This isn't a problem yet as 2.68 is only in experimental for now.
Log:
```
running build_ext
test_simple (tests.test_gdebi_gtk.GDebiGtkTestCase) ...
WARNING:root:Error loading logo gtk-icon-theme-error-quark: Icon
'gnome-mime-application-x-deb' not present in theme Yaru (0)
(setup.py:7825): Gtk-WARNING **: 05:55:50.408: Error loading theme
icon 'dialog-error' for stock: Icon 'dialog-error' not present in
theme Yaru
E: Build killed with signal TERM after 150 minutes of inactivity
```
This is reproducible locally and the process tree looks like:
F UID PIDPPID PRI NIVSZ RSS WCHAN STAT TTYTIME COMMAND
4 0 39842 0 20 0 9328 3000 do_wai Ss pts/2 0:00 bash
0 0 40835 39842 20 0 22136 13032 do_wai S+ pts/2
0:00 \_ /usr/bin/perl /usr/bin/debuild -i -us -uc -b
0 0 40852 40835 20 0 7392 604 pipe_w S+ pts/2
0:00 \_ tee ../gdebi_0.9.5.7+nmu5_amd64.build
0 0 40853 40835 20 0 25328 16328 do_wai S+ pts/2
0:00 \_ /usr/bin/perl /usr/bin/dpkg-buildpackage -us -uc -ui -i
-b
0 0 40891 40853 20 0 7764 1616 do_wai S+ pts/2
0:00 \_ /usr/bin/make -f debian/rules build
0 0 40892 40891 20 0 24356 15260 do_wai S+ pts/2
0:00 \_ /usr/bin/perl /usr/bin/dh build --with python3
--buildsystem pybuild
0 0 41533 40892 20 0 7764 1572 do_wai S+ pts/2
0:00 \_ /usr/bin/make -f debian/rules
override_dh_auto_test
0 0 41535 41533 20 0 2620 1320 do_wai S+ pts/2
0:00 \_ /bin/sh /usr/bin/xvfb-run -a python3.9
setup.py test
4 0 41545 41535 20 0 1034648 37536 ep_pol Sl+ pts/2
0:00 \_ Xvfb :99 -screen 0 1280x1024x24
-nolisten tcp -auth /tmp/xvfb-run.RlZdX8/Xauthority
0 0 41560 41535 20 0 1331396 131060 poll_s Sl+ pts/2
0:01 \_ python3.9 setup.py test
>From there the test is stuck.
Some debugging revealed that it does no more come back from:
GDebiGtkTestCase
-> test_lintian
-> GDebiGtk (init)
-> gio_copy_in_place
-> show_alert
That alert only happens because we run as root, but even if that is avoided
(e.g. by running as another user) then it blocks at the next message. E.g.
when failing to download.
But these blocking alerts are only secondary symptoms.
I've found that all issues come back to a check that seems wrong.
The test wants to copy a non-existing file into a temp path.
At least the current version of Gio.File hates this and errors out
g-io-error-quark: Operation not supported (15)
Maybe Gio was more tolerant in the past, but checking a non existing
file makes no sense anyway. We can guard that step a bit better than all works.
A fix could look like:
--- /home/ubuntu/gdebi-0.9.5.7+nmu5/GDebi/GDebiGtk.py 2021-06-09
10:17:06.516869439 +
+++ /root/gdebi-0.9.5.7+nmu5/GDebi/GDebiGtk.py 2021-06-09
10:09:35.113662314 +
@@ -119,7 +119,8 @@
self.on_window_main_drag_data_received)
# Check file with gio
-file = self.gio_copy_in_place(file)
+if file != "" and os.path.exists(file):
+file = self.gio_copy_in_place(file)
#self.vte_terminal.set_font_from_string("monospace 10")
self.cprogress = self.CacheProgressAdapter(self.progressbar_cache)
I've proposed the same to the project [1], but I'm unsure about the speed this
is picked up there - so to avoid this being broken once the switch to 2.68
happens I filed this bug for you.
[1]: https://code.launchpad.net/~paelzer/gdebi/gdebi-fix-glib-2.68/+merge/403954
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
Bug#989638: qemu-kvm dependency isn't available on all Architecture: any
Package: qemu-web-desktop
Version: 21.05.03-1
Hi,
I've seen that this is blocked migrating in Debian and Ubuntu due to
missing dependencies.
Debian:
qemu-web-desktop/mips64el has unsatisfiable dependency
qemu-web-desktop/mipsel has unsatisfiable dependency
qemu-web-desktop/s390x has unsatisfiable dependency
Ubuntu:
qemu-web-desktop/riscv64 has unsatisfiable dependency
That is due to the explicit listing of qemu-kvm
This package is most likely no more the right package to depend on anyway.
Usually it is expected to depend on just the right qemu-system-$arch
that you'd need - and if you really can't decide at all then qemu-system
which depends on all the others.
qemu-kvm doesn't exist anymore as a package, you only see old ones:
qemu-kvm | 1:2.1+dfsg-12+deb8u6 | oldoldstable | amd64, i386
qemu-kvm | 1:2.8+dfsg-6+deb9u9 | oldstable| amd64, i386
qemu-kvm | 1:3.1+dfsg-8+deb10u8 | stable | amd64, i386
But the newer qemu-system-$arch have a provides
root@d10-sid:~# apt-cache show qemu-system-x86 | grep '^Provides'
Provides: qemu-kvm, qemu-system-i386, qemu-system-x86-64
The description of the also old "qemu" outlines it the best IMHO:
142 If you want full system emulation of some architecture, install one or more
143 of qemu-system-ARCH packages. If you want user-mode emulation, install
144 qemu-user or qemu-user-static package. If you need utilities, use
qemu-utils
145 package.
So what does qemu-web-desktop actually use:
$ grep -Hrn qemu-system
README.md:173:qemu-system-x86_64 -m 4096 -smp 4 -hda machine1.qcow2
-name MySuperbVM -boot d -cdrom file.iso -enable-kvm -cpu host -vga
qxl -net user -net nic,model=ne2k_pci
README.md:378:qemu-system-x86_64: -device
vfio-pci,host=:4c:00.0,multifunction=on: VFIO_MAP_DMA: -12
README.md:379:qemu-system-x86_64: -device
vfio-pci,host=:4c:00.0,multifunction=on:
vfio_dma_map(0x55966269d230, 0x10, 0xbff0, 0x7f55b7f0) =
-12 (Cannot allocate memory)
README.md:411:qemu-system-x86_64 -m 8192 -smp 4 -hda
machine1-snapshot.qcow2 -device ich9-ahci,id=ahci -enable-kvm -cpu
host -vga qxl -netdev user,id=mynet0 -device virtio-net,netdev=mynet0
-device virtio-balloon
src/config.pl:63:$config{qemu_exec}= "qemu-system-x86_64";
So the default is x86 only, there is nothing in d/rules that overwrites this.
Thereby chances are quite high that this was only ever tested and meant for
x86_64 anyway. Therefore the simple and most reasonable short term fix
would IMHO be:
--- qemu-web-desktop-21.05.03/debian/control 2021-05-17 18:51:33.0 +0200
+++ qemu-web-desktop-21.05.03/debian/control 2021-06-09 09:43:35.0 +0200
@@ -10,7 +10,7 @@
Homepage:
https://gitlab.com/soleil-data-treatment/soleil-software-projects/remote-desktop
Package: qemu-web-desktop
-Architecture: any
+Architecture: amd64
Depends: ${shlibs:Depends}, ${misc:Depends},
apache2,
libapache2-mod-perl2,
If you want to really support other architectures then you'd most likely want
to
1. overwrite the default in config.pl at build time per architecture
2. select the architectures you really expect to work (e.g. there is no system
emulation at all for risscv yet) and mark it only for those
3. depend on the matching qemu-system-$arch
4. after having done so have at least a quick try if it works there at all
before moving it out of experimental
!Untested! example for this more complex solution:
diff -Nru qemu-web-desktop-21.05.03/debian/control
qemu-web-desktop-21.05.03/debian/control
--- qemu-web-desktop-21.05.03/debian/control 2021-05-17 18:51:33.0 +0200
+++ qemu-web-desktop-21.05.03/debian/control 2021-06-09 09:43:44.0 +0200
@@ -10,13 +10,15 @@
Homepage:
https://gitlab.com/soleil-data-treatment/soleil-software-projects/remote-desktop
Package: qemu-web-desktop
-Architecture: any
+Architecture: amd64 ppc64el arm64
Depends: ${shlibs:Depends}, ${misc:Depends},
apache2,
libapache2-mod-perl2,
libapache2-mpm-itk,
websockify,
- qemu-kvm,
+ qemu-system-x86 [amd64],
+ qemu-system-arm [arm64],
+ qemu-system-ppc [ppc64el],
bridge-utils,
qemu,
iptables,
diff -Nru qemu-web-desktop-21.05.03/debian/rules
qemu-web-desktop-21.05.03/debian/rules
--- qemu-web-desktop-21.05.03/debian/rules 2021-05-03 17:06:35.0 +0200
+++ qemu-web-desktop-21.05.03/debian/rules 2021-06-09 09:43:44.0 +0200
@@ -1,10 +1,19 @@
#!/usr/bin/make -f
+SYSEMULATOR=qemu-system-x86_64
+ifeq ($(DEB_HOST_ARCH),arm64)
+ SYSEMULATOR=qemu-system-aarch64
+endif
+ifeq ($(DEB_HOST_ARCH),ppc64el)
+ SYSEMULATOR=qemu-system-ppc64
+endif
+
%:
dh $@ --with apache2 --with sysuser
override_dh_auto_build:
mkdir build
+ sed -e 's/qemu-system-x86_64/$(SYSEMULATOR)/' src/config.pl
cp src/apache.conf build/qemu-web-desktop.conf
pandoc -s -o build/qwdctl.1 src/qwdctl.md
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
Bug#989634: autopkgtest fails by missing python3-tomlkit dependency
Package: lintian-brush Version: 0.104 Hi, I've seen the autopkgtests fail in Debian https://ci.debian.net/data/autopkgtest/unstable/amd64/l/lintian-brush/12796854/log.gz And Ubuntu https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/l/lintian-brush/20210524_182220_e891a@/log.gz While it seems that there might be more hidden underneath as tests behave differently on re-runs and if executed locally there is one issue that persists everywhere. from lintian_brush.fixer import control, report_result, LintianIssue File "/usr/lib/python3/dist-packages/lintian_brush/fixer.py", line 235, in from debmutate.debcargo import DebcargoControlShimEditor, DebcargoEditor File "/usr/lib/python3/dist-packages/debmutate/debcargo.py", line 28, in from tomlkit import loads, dumps ModuleNotFoundError: No module named 'tomlkit' Installing python3-tomlkit avoids that issue as one would expect. It only is an indirect recommends and therefore isn't auto-installed. Resolving this gets the test working in a local autopkgtest VM based run (in Ubuntu). Logs => https://paste.ubuntu.com/p/8bSFTkNCFS/ Let me know if you need an MP or debdiff for this, but since it is so trivial I've just posted it here: diff -Nru lintian-brush-0.104/debian/tests/control lintian-brush-0.104/debian/tests/control --- lintian-brush-0.104/debian/tests/control 2021-03-29 19:56:27.0 +0200 +++ lintian-brush-0.104/debian/tests/control 2021-03-29 19:56:27.0 +0200 @@ -1,5 +1,5 @@ Tests: tool-testsuite -Depends: lintian-brush, python3-breezy.tests, gpg, dos2unix, libdebhelper-perl, lintian (>= 2.104.0), python3-iniparse, python3-levenshtein, decopy, po-debconf, python3-toml | python3-upstream-ontologist (>> 0.1.12), python3-markdown, python3-docutils, python3-bs4, python3-lxml +Depends: lintian-brush, python3-breezy.tests, gpg, dos2unix, libdebhelper-perl, lintian (>= 2.104.0), python3-iniparse, python3-levenshtein, decopy, po-debconf, python3-toml | python3-upstream-ontologist (>> 0.1.12), python3-markdown, python3-docutils, python3-bs4, python3-lxml, python3-tomlkit Restrictions: allow-stderr Test-Command: deb-scrub-obsolete --version I hope that helps to resolve this, Christian Ehrhardt
Bug#989633: breezy 3.2 breaks lintian-brush patch handling
Package: lintian-brush Version: 0.104 Hi, while debugging another issue in the lintian-brush autopkgtests I've seen this issue: Next I've seen that with python3-breezy 3.2 that is in unstable you get Traceback (most recent call last): File "/tmp/autopkgtest.tAETVe/build.tjd/src/lintian_brush/tests/test_patches.py", line 299, in test_upstream_branch with upstream_with_applied_patches(self.tree, patches) as t: File "/usr/lib/python3.9/contextlib.py", line 117, in __enter__ return next(self.gen) File "/tmp/autopkgtest.tAETVe/build.tjd/src/lintian_brush/patches.py", line 193, in upstream_with_applied_patches with AppliedPatches(upstream_tree, patches) as tree: File "/tmp/autopkgtest.tAETVe/build.tjd/src/lintian_brush/patches.py", line 133, in __enter__ from breezy.transform import TransformPreview ImportError: cannot import name 'TransformPreview' from 'breezy.transform' (/usr/lib/python3/dist-packages/breezy/transform.py) I've found that this is from the new: breezy | 3.2.0+bzr7542-1| unstable| source You can switch in/out that state by switching back to breezy | 3.1.0-8| testing | source It seems this was split from breezy/transform.py:1971:class TransformPreview(DiskTreeTransform): Into: breezy/git/transform.py:1520:class GitTransformPreview(GitTreeTransform): breezy/bzr/transform.py:1860:class TransformPreview(InventoryTreeTransform): The following fixes this for me in a local autopkgtest VM run: --- lintian-brush-0.104/lintian_brush/patches.py 2021-03-29 19:56:27.0 +0200 +++ lintian-brush-0.104/lintian_brush/patches.py 2021-03-29 19:56:27.0 +0200 @@ -130,7 +130,7 @@ def __enter__(self): if self.patches: -from breezy.transform import TransformPreview +from breezy.bzr.transform import TransformPreview self._tt = TransformPreview(self.tree) apply_patches(self._tt, self.patches, prefix=self.prefix) I don't know if you eventually want a version dependent switch for the import, but that should get you going and since I was not finding a bug for it yet I thought filing this for awareness might help in any case. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#989589: Real fix just got merged
FYI - at https://sourceforge.net/p/gptfdisk/code/merge-requests/26/ a real fix for the underlying problem has been merged upstream. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#989589: Actually read/display is good now, but write was always wrong
If you follow the discussion I linked when opening the bug as [3] you'll find more. But the TL;DR is that sgdisk/gdisk always (and still) write the labels/names byte-swapped on s390x (or probably in general big endian). So I'd suggest to not revert the change, and instead wait for a fix to the write code-path that then should be applied. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#983843: 0.9.16 contains the related fixes
Hi, I wanted to ping on this bug to let you know that 0.9.16 was tagged on 30th of April and among other things it contains the fixes for this on s390x and ppc64el: https://github.com/neutrinolabs/xrdp/commit/1d1ec9614f84243e4a08256f82994278d082b592 https://github.com/neutrinolabs/xrdp/commit/3b81df3f9e894dd164f86d8cf87c3a171ced6d08 So I think either backporting these two for now (since we are in freeze) or going to 0.9.16 (maybe later on) should resolve this issue. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#989589: Upstream engaged and Salsa interim fix
Hi, the discussion upstream started on https://sourceforge.net/p/gptfdisk/mailman/gptfdisk-general/thread/8db702c5-642c-705d-294c-2df60a070ff6%40gmail.com/#msg37298402 Until then (which will likely be a 1.0.8) this MP would fix the issue in Debian on 1.0.7: https://salsa.debian.org/debian/gdisk/-/merge_requests/2 Reverting this isn't too bad as it is the very same behavior that we have in 1.0.6-1.1 in testing. But it would allow us to gain the other bits of 1.0.7 like the support for three more partition types and the fix of some spurious error messages. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#989589: FTFBS on s390x in 1.0.7
Package: gdisk Version: 1.0.7-1 Hi, I wanted to let you know that the recent FTFBS on s390x in Debian [1] and Ubuntu [2] is caused by a try to fix big endian byte swapping in 1.0.7 that actually made it break. When you look at the logs it seems it is just failing for no apparent reason, but with -x enabled in gdisk_test.sh one quickly sees there is some string-mangling happening: Number Start (sector)End (sector) Size Code Name 12048 131038 63.0 MiB8300 䰀椀渀甀砀 昀椀氀攀猀礀猀琀攀洀 Reading the very same file with the old gdisk is good - so likely the on-dis content is good as well: Number Start (sector)End (sector) Size Code Name 12048 131038 63.0 MiB8300 Linux filesystem This is caused by GPTPart::GetDescription due to this change [3] in 1.0.7 Reverting this fixes change fixes the problem, so that is what I'd suggest for the gdisk package that is stuck in unstable due to that. P.S. I've reported the same upstream as well but their archive seems slow to pick it up, so there is no linkable reference yet. [1]: https://buildd.debian.org/status/fetch.php?pkg=gdisk=s390x=1.0.7-1=1617791278=0 [2]: https://launchpadlibrarian.net/540613637/buildlog_ubuntu-impish-s390x.gdisk_1.0.7-1_BUILDING.txt.gz [3]: https://sourceforge.net/p/gptfdisk/code/ci/86dd5fea351a5a55bea26b7622eb85ebd6075a60/ [4]: -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#989378: Avoid leases to be issued forever when not set
Package: dnsmasq
Version: 2.85-1
Hi,
This isn't a new topic at all, but I wonder what else I could do to raise
awareness.
It was initially submitted and discussed:
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014341.html
I pinged about the case whenever I touched dnsmasq in Ubuntu:
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014387.html
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014639.html
The discussion was abit back and forth but I thought that eventually the
change suggested by Dominik dl6er at dl6er.de seemed to be simple and working.
Since then Ubuntu carries this as:
diff --git a/src/radv.c b/src/radv.c
index 3255904b..d10f2b6b 100644
--- a/src/radv.c
+++ b/src/radv.c
@@ -628,8 +628,9 @@ static int add_prefixes(struct in6_addr *local, int prefix,
/* find floor time, don't reduce below 3 * RA interval.
If the lease time has been left as default, don't
-use that as a floor. */
- if ((context->flags & CONTEXT_SETLEASE) &&
+use that as a floor.
+Always set lease time if requested to do so. */
+ if ((context->flags & CONTEXT_SETLEASE) ||
time > context->lease_time)
{
time = context->lease_time;
Any chance to apply that upstream and/or in Debian?
Or did I miss a part of the dsicussion that identified this as being wrong?
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
Bug#987710: Consider adding some helpful links to SC/DFSG page
Package: www.debian.org Severity: wishlist Hi, I'm aware that I'm walking a fine line, but it came up in a discussion so I wanted to file the bug for your consideration. To be clear, if you consider this to need a foundation document change as in [1] then it clearly isn't worth it and I'd ask you to close this as won't fix. But if you agree that adding helpful links WITHOUT changing the wording could be done as a normal change of the web-pages then please give this a thought. Suggestions when reading [2]: - At the top "The Debian Free Software Guidelines (DFSG)" is a link to https://www.debian.org/social_contract#guidelines a few paragraphs later "the document entitled The Debian Free Software Guidelines" is not a link, but IMHO it should be the same one - there are some references to "The Debian system" and "Debian" which in my reading some mean more "the project" and others mean "the components that make up Debian". As I'm sure you don't mean the #1 hit on search engines which is https://en.wikipedia.org/wiki/The_Debian_System It might be better to throw in some links like https://www.debian.org/intro/about And maybe to differntiate https://www.debian.org/doc/debian-policy/ch-archive.html#the-debian-archive - "bug report database" should be a link to https://www.debian.org/Bugs/ - "create distributions containing both the Debian system and other works" could be a link to https://www.debian.org/derivatives/ Furthermore I think there should be a link to https://people.debian.org/~bap/dfsg-faq.html. But I list this separately because, while helpful, I'd not know where to put it without changing the text - and that would clearly put us into foundation document change land. [1]: https://www.debian.org/devel/constitution#item-4 [2]: https://www.debian.org/social_contract -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#986371: Add some more info - seems to affect (recent) Ubuntu as well.
> Is there anything I can/should do in order to re-target this bug? Sorry, I’m > a very green newbie > in this low-level linux environment… No, MJT already forwarded it to upstream (qemu) It turns out to be a known, but not yet fixed kernel bug [1] I've collected all the pointers that I could find atm in an Ubuntu launchpad bug [2] as that is affected just as much with >=5.9 kernels. It seems we need to wait until the kernel folks agree on some solution :-/ There is not much for you to do, other than (if you want) chime in on any of the kernel discussions with like "hey this is important to me, any news?" [1]: https://bugzilla.kernel.org/show_bug.cgi?id=209831 [2]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1922846 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#986371: Add some more info - seems to affect (recent) Ubuntu as well.
This made me wonder: > In the stock linux kernel, as far as I can see, there's no counting for this > info for x86 > architecture, - it is only counted for ia64, powerpc and s390x architectures. And for [1] account_guest_time it indeed seems that way. But while ia64/s390/powerpc have special code on their entry/exit path $ grep -Hrn account_guest_time * arch/ia64/kernel/time.c:77: account_guest_time(tsk, cycle_to_nsec(ti->gtime)); arch/powerpc/kernel/time.c:430: account_guest_time(tsk, cputime_to_nsecs(acct->gtime)); arch/s390/kernel/vtime.c:172: account_guest_time(tsk, cputime_to_nsecs(guest)); include/linux/kernel_stat.h:99:extern void account_guest_time(struct task_struct *, u64); kernel/sched/cputime.c:140:void account_guest_time(struct task_struct *p, u64 cputime) There also are these calls from generic code: kernel/sched/cputime.c:190: account_guest_time(p, cputime); kernel/sched/cputime.c:388: account_guest_time(p, cputime); kernel/sched/cputime.c:678: account_guest_time(tsk, vtime->gtime); Which match these functions irqtime_account_process_tick, account_guest_time, vtime_account_guest Double checked x86 in Ubuntu 5.8.0-49-generic (groovy) worked fine. But indeed 5.11.0-13-generic (hirsute) seemed to not account for these values anymore. I haven't chased this further down, but these functions sound pretty generic. @MJT - have you checked those and they all end up only being used in arch-code/calls? And as I said, there doesn't seem to be Ubuntu Delta for it [2][3], yet there it is working. IMHO this might be an upstream change between 5.8 and 5.10 introducing the issue. I'm afraid this really has to be looked at more in depth why it isn't accounting anymore. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/sched/cputime.c#n140 [2]: https://kernel.ubuntu.com/git/ubuntu/ubuntu-hirsute.git/log/kernel/sched/cputime.c [3]: https://kernel.ubuntu.com/git/ubuntu/ubuntu-groovy.git/log/kernel/sched/cputime.c -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#986371: Indeed this should work (also adding trivial test-case)
Hi, we had Delta in Ubuntu a long long time ago, but afaik there isn't any delta-need for years. To be clear, guest time as well as the guest visibility into steal time is very useful, but there shouldn't be any lack of it in Debian. I had a try in (an old) debian 10.1 with 5.7.0-2-amd64 And there I can see the accounting moving just fine ubuntu@debian:~$ cat /proc/stat cpu 196 0 259 9243 60 0 1 23 0 0 cpu0 82 0 172 4579 39 0 1 10 0 0 qemu-system-x86_64 -nodefaults -nographic -accel kvm # wait a few seconds, and then abort it ubuntu@debian:~$ cat /proc/stat cpu 213 0 283 10926 73 0 4 32 7 0 cpu0 98 0 193 5397 52 0 3 15 7 0 cpu1 115 0 90 5528 20 0 0 16 0 0 The 7 seconds of boring some rom startup code is the accounting that you are looking for. Also as you can see in [1] there isn't any architecture note on this anymore (and I think there only was for steal time). So it really should work and does so in my experiment above. The original change is even in the history git pre 2.6.12 and the latter modifications are not new wither [2][3] I was updating and rebooting into 5.10.0-5-amd64 and I can confirm that it no longer works. (The same experiment as above) I've looked at the Ubuntu kernels for groovy [4] and hirsute [5], but found no related Delta on a quick check. IIRC the last upstream change [6] in that area was around v5.5 - so there should be no change. IMHO a kernel bug would be appropriate, @mjt I think you could even just re-target this one, there is no need to make it a different bug. @Thomas if instead you want to file a new bug, then look at [7] [1]: https://www.kernel.org/doc/html/latest/filesystems/proc.html#miscellaneous-kernel-statistics-in-proc-stat [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce0e7b28 [3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c574358e [4]: https://kernel.ubuntu.com/git/ubuntu/ubuntu-groovy.git/ [5]: https://kernel.ubuntu.com/git/ubuntu/ubuntu-hirsute.git/ [6]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5720821b [7]: https://wiki.debian.org/DebianKernelReportingBugs -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#984439: Maybe related issue ...
Hi, I wasn't able to perfectly derive from the log that is linked here if this is the same issue. But it is the same package hitting the same "SigBus due to alignment" issue at a similar time. So I thought dropping a link as FYI might be worth even if eventually they turn out to be different issues. I've documented for Ubuntu in https://bugs.launchpad.net/debian/+source/netgen/+bug/1919335 And filed the issue upstream at: https://github.com/NGSolve/netgen/issues/89 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#984952: only affects loading of old data files - test mitigation available
Hi, I've looked at this case and it seems to only affect the loading of "old" data that go through the migration modules for old data. The current file can be loaded in the test. I'd wish to say I have reported it upstream, but TBH [1] drives me mad and I fail to see where/how to properly report it there. I hope that you might be experienced enough communicating with this upstream to know where/how to submit it there ? Until then a mitigation for the current situation is available at [2]. Since Cad@s390x isn't that much of a real thing and loading of new files works I think adding that would be a good trade-off for the time being. What do you think? [1]: https://tracker.freecadweb.org/my_view_page.php [2]: https://salsa.debian.org/science-team/freecad/-/merge_requests/19 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#979500: [pkg-apparmor] Bug#979500: dh-apparmor: please support local includes of abstractions like "abstraction/name"
On Sat, Feb 6, 2021 at 8:08 AM intrigeri wrote: > > Hi, > > intrigeri (2021-01-08): > > Christian Boltz (2021-01-07): > >> I'd argue that this is a problem that is already solved ;-) > >> > >> Starting with AppArmor 3.0, all[1] upstream abstractions come with a > >> rule like (example taken from abstractions/base): > >> > >> include if exists > >> > >> so if you create that directory and place a file there, it will be > >> included by the abstraction. > > > >> [...] > > > >> For abstractions shipped by individual package (like libvirt), it would > >> also make sense to add an include if exists > >> rule to make it easy to add something to an abstraction. > > > > I like what Christian Boltz is proposing (thanks!): as far as > > I understand, it can happen in libvirt upstream, will benefit even > > non-Debian distros, and does not require modifying dh-apparmor. > > > > Christian Ehrhardt, how does it sound? Any reason why the approach you > > initially suggested on this bug report is better? > > Ping? I beg your pardon I totally lost your and Christian B. replies on this one in my inbox-cracks. Thanks Intrigeri for the ping. I'm already part of the crowd waiting for "Include if exists" to be widely available. And yes, that would solve my problem as well. But IMHO a huge problem with "Include if exists" is, that on older apparmor it totally breaks the rule parsing. That makes it hard to fully jump onto the new feature yet: - upstreams don't know how far back their SW will be built, this would need to become at least a build time version/feature check against apparmor - distro-packaging often enough is used for backports, where again we'd need code to handle old and new feature sets But thinking more about it I think I still agree that we can close this bug. That is because in the (hopefully few) places we need this we can handle it (a bit ugly) in the maintscripts. If we'd fully support it in dh-apparmor it might encourage people "too much" to use that instead of the hopefully better future of "include-if-exists". > I'd like to add that one of the reasons for adding support for > "include if exists" in AppArmor upstream was to cancel the need for > distros to manage local override files via packaging machinery, > which long term will allow us to simplify things like dh-apparmor, > making them easier to maintain and to use :) > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
