Bug#1006872: RFH: apparmor -- user-space parser utility for AppArmor
Hi, On Mon, 7 Mar 2022, at 10:17, intrigeri wrote: > But regarding maintenance of src:apparmor itself, the bus factor of in Debian > is > 1, which is not great. I don't feel comfortable with this situation. > > src:apparmor includes: > > - system initialization bits > > - AppArmor parser, which is required to compile AppArmor profiles and load > them >into the kernel for use by the AppArmor Linux Security Module > > - abstractions, i.e. reusable bits of policy > > The workload is not particularly big: I would say a few hours per month > on average. > > Upstream is very cooperative. This reminded me I promised to work on dh-apparmor. I should find time for that, maybe also for apparmor itself. -- Cheers, Andrej
Bug#676937:
condominio
Bug#1006874: PTS: bug, version, ... information does not get updated
Package: qa.debian.org Severity: normal Hi, some parts of the pages generated by the (old) PTS no longer get updated: E.g. https://packages.qa.debian.org/s/spirv-llvm-translator-12.html (a relatively new package) * 'versions' box: only lists the version in unstable, not the one in testing * 'bugs' box: (the package has no bugs) does not show bug counts of zero, but only a box with minimal height, while the individual bug classes (e.g. RC: (w/o count)) overlap the "links" box below it (tried with Firefox and Chromium, see attached screenshot) E.g. https://packages.qa.debian.org/n/nvidia-graphics-drivers-tesla-418.html * 'bugs' box: shows all counts as zero, while the package has an RC bug open for 14 days now (and some other bugs, too) E.g. https://packages.qa.debian.org/p/pyopencl.html * 'version' box: shows stale information for testing * 'todo' box: shows new upstream version 2021.2.10 while sid has 2021.2.13 and upstream 2022.1 Andreas
Bug#958427: libsrtp2: FTBFS on x32: bogus printf with time_t, then segfaults [regression]
Hello, This should have been fixed upstream with the following patch: https://github.com/cisco/libsrtp/commit/4f1d945fe3eb302fa2bab2aea63fdf6ea7485e95 Do you think you could do an upload with that includes it? Thanks Laurent Bigonville
Bug#1006873: DDPO: use a less eye-catching symbol/color for "neutral" CI state
Package: qa.debian.org Severity: normal Hi, DDPO currently uses the "No Entry" sign with read background ⛔ (U+26D4) for the "neutral" CI state. I find this more eye-catching than the "fail" state (which uses the word "fail" in red). The CI pages itself use the "No Entry" sign with a blue background (), maybe DDPO could use something similar. What about 'CIRCLED MINUS' ⊖ (U+2296) in the blue text color? Andreas
Bug#1006872: RFH: apparmor -- user-space parser utility for AppArmor
Package: wnpp Severity: normal X-Debbugs-Cc: debian-de...@lists.debian.org, pkg-apparmor-t...@alioth-lists.debian.net Control: affects -1 src:apparmor Hi, I request assistance with maintaining the apparmor package. AppArmor has been enabled by default on the Linux ports of Debian since Buster. The big picture of AppArmor maintenance in Debian is pretty good: - Vincas Dargis has been helping quite a lot on the policy (profiles) side of things — thanks! - Various package maintainers are taking care of AppArmor profiles shipped in their packages, asking help when needed, which is awesome. - Debian folks have generally been very cooperative when it comes to making AppArmor work on their system, e.g. by submitting merge requests upstream when suggested. - The kernel part of things happens upstream. AFAIK it did not require dedicated work on the Debian side for years. But regarding maintenance of src:apparmor itself, the bus factor of in Debian is 1, which is not great. I don't feel comfortable with this situation. src:apparmor includes: - system initialization bits - AppArmor parser, which is required to compile AppArmor profiles and load them into the kernel for use by the AppArmor Linux Security Module - abstractions, i.e. reusable bits of policy The workload is not particularly big: I would say a few hours per month on average. Upstream is very cooperative. Cheers!
Bug#1006871: pmacctd: SEGV when ICMP/ICMPv6 traffic was processed and 'flows' are used
Package: pmacct X-Debbugs-Cc: deb...@seufer.de Version: 1.7.6-2 Severity: important Dear Maintainer, The pmacct version (1.7.6) segfaults in Debian Bullseye, when you use the 'flows' feature. I already reported this problem upstream: https://github.com/pmacct/pmacct/issues/586 And Paolo provided a patch for this problem: https://github.com/pmacct/pmacct/commit/73af9545ea33cd87846306f648f634063ac41765 Please also fix this in Debian Bullseye 11 Stripped down configuration file to reproduce: daemonize: true pidfile: /var/run/pmacctd.pid pcap_interface: enp8s0f1 promisc: true plugins: pgsql[all] plugin_pipe_size: 1024 sql_db: pmacct sql_host: localhost sql_user: pmacct sql_passwd: *** sql_table_version: 5 sql_history: 1m sql_history_roundoff: m sql_refresh_time: 60 sql_dont_try_update: true aggregate[all]: src_mac,dst_mac,vlan,src_host,dst_host,src_port,dst_port,tos,proto,flows Then capture ICMP/ICMPv6 traffic. Best regards, Oliver Seufer
Bug#730226: qbittorrent: file creation on startup creates huge loadavg spike
AFAIK there are two possible reasons for this behaviour: 1) In Preferences->Download the option 'Pre-allocate disk space for all files' is checked (but that's not the default). 2) The option above is not checked but the download folder is within a filesystem that doesn't support sparse files (at least on Linux) like FAT32 and exFAT. Assuming that sequential download is not checked, when a torrent piece located GB away from the file beginning is received, the file has to be extended by physically writing zeros to seek to that position and write the piece. When downloading to filesystems with sparse file support (like ext4 for example) I could not observe such I/O overload, even with file preallocation (at least with recent versions of libtorrent-rasterbar). OTOH the issue is still present for downloads to certain filesystems (i.e. FAT32, etc) and can cause severe performance issues especially with slow storage. Regards BZ
Bug#841988: qbittorrent: Crashing at random intervals
There are several reports in upstream bug tracker ( [1], [2] ) that show the same stacktrace. They both point to a bug in libtorrent-rasterbar 1.1.0 in ip-filtering code, fixed in 1.1.1. so chances are this bug is solved now. Regards BZ [1] https://github.com/qbittorrent/qBittorrent/issues/5730 [2] https://github.com/qbittorrent/qBittorrent/issues/5428
Bug#1006870: sdl12-compat: please make the build reproducible
Source: sdl12-compat Version: 1.2.52-3 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: environment X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi Simon, Whilst working on the Reproducible Builds effort [0] we noticed that sdl12-compat could not be built reproducibly. This is because avoiding execute permissions in /usr/libexec/installed-tests meant that the package varied depending on the umask — the group bits were varying. Instead of not calling dh_fixperms at all, a patch is attached that lets it run as usual but then removes the executable bits. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2022-03-07 07:51:04.278872668 + --- b/debian/rules 2022-03-07 08:00:17.399357994 + @@ -26,5 +26,5 @@ # debhelper >= 13.4 makes all of /usr/libexec executable, which is not # quite right for installed-tests -override_dh_fixperms: - dh_fixperms -Xusr/libexec/installed-tests +execute_after_dh_fixperms: + find debian -path "*/usr/libexec/installed-tests/*" -type f -print0 | xargs -0r chmod -x
