Bug#1004466: fail2ban: courier-auth failregex does not match FAILED LOGIN
Le 28/01/2022 à 08:16, Daan Willems a écrit : Package: fail2ban Version: 0.11.2-2 Severity: normal Tags: patch Dear Maintainer, * What led up to the situation? fail2ban didn't find/ban failed logins in the configured courier-auth jail. * What exactly did you do (or not do) that was effective (or ineffective)? Failed courier-imapd logins are logged in /var/log/mail.log as: Jan 27 09:00:00 servername imapd: LOGIN FAILED, user=xxx, ip=[:::xxx.xxx.xxx.xxx], port=[x] The current courier-auth failregex fails to match this because there is a port mentioned after the ip section. An update to the failregex is needed to reflect this. failregex = ^%(__prefix_line)sLOGIN FAILED, (?:user|method)=.*, ip=\[\]$ failregex = ^%(__prefix_line)sLOGIN FAILED, (?:user|method)=.*, ip=\[\].*$ * What was the outcome of this action? Fail2ban matches failed courier-imapd(-ssl) logins again as expected. Could you please propose a PR upstream? https://github.com/fail2ban/fail2ban/ Thanks, Sylvestre
Bug#995289: foolscap: ready for upload
Hello, I have removed unneeded files from python3-foolscap binary package. Furthermore, there was an issue with building package with git-buildpackage, which I solved by updating the certificates used for tests. The package is ready for the upload now. If it is OK, I can upload it myself. Andrius
Bug#1004456: php-common 2:92 erroneously promoted to testing
Control: reassign -1 src:php-raphf Control: found -1 2.0.1+1.1.2-1 Control: fixed -1 2.0.1+1.1.2-13 Control: close 998594 2.0.1+1.1.2-13 > php-common 2:92 erroneously promoted to testing No, not really. php-raphf just needs to migrate to testing as it is currently not present in testing. Paul, it seems that php-raphf is manually blocked? > Not touching package due to block request by elbrus (Follow the freeze policy > when applying for an unblock) Could you take a look? Cheers, Ondrej -- Ondřej Surý (He/Him) ond...@sury.org > On 28. 1. 2022, at 0:00, David Walker wrote: > > Package: php-common > Version: 2:76 > Severity: important > X-Debbugs-Cc: d0sbo...@gmail.com > > The current version of php-common in testing is 2:92, which is the same as > sid. > The current version of php-raphf in testing is 2.0.1+1.1.2-1. > The current version of php-raphf in sid is 2.0.1+1.1.2-13. > php-common 2:92 breaks php-raphf < 2.0.1+1.1.2-13~. > > Therefore, it should not have been promoted to testing, since the applicable > version of php-raphf is not available yet. Its promotion makes php-raphf > uninstallable. > > As a side note, this seems like it would be better expressed in the > dependencies of php-raphf, instead of as a Breaks in php-common? > > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (501, 'testing'), (100, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages php-common depends on: > ii psmisc 23.4-2 > ii sed 4.7-1 > > php-common recommends no packages. > > php-common suggests no packages. > > -- no debconf information >
Bug#1004467: libostree-1-1: flatpak crashes when creating a bundle
Package: libostree-1-1 Version: 2020.8-2 Severity: important Tags: upstream patch On Debian Bullseye, flatpak crashes when trying to create a bundle. That issue has also already been reported here: https://github.com/flatpak/flatpak/issues/4673 I could solve the issue by applying the absolutely minimal patch from https://gitlab.gnome.org/GNOME/libglnx/-/merge_requests/30 Please apply this patch to the package in Bullseye, thanks! Best wishes Philipp
Bug#1004466: fail2ban: courier-auth failregex does not match FAILED LOGIN
Package: fail2ban
Version: 0.11.2-2
Severity: normal
Tags: patch
Dear Maintainer,
* What led up to the situation?
fail2ban didn't find/ban failed logins in the configured courier-auth jail.
* What exactly did you do (or not do) that was effective (or ineffective)?
Failed courier-imapd logins are logged in /var/log/mail.log as:
Jan 27 09:00:00 servername imapd: LOGIN FAILED, user=xxx,
ip=[:::xxx.xxx.xxx.xxx], port=[x]
The current courier-auth failregex fails to match this because there is a port
mentioned after the ip section.
An update to the failregex is needed to reflect this.
failregex = ^%(__prefix_line)sLOGIN FAILED, (?:user|method)=.*, ip=\[\]$
failregex = ^%(__prefix_line)sLOGIN FAILED, (?:user|method)=.*,
ip=\[\].*$
* What was the outcome of this action?
Fail2ban matches failed courier-imapd(-ssl) logins again as expected.
Not sure if this applies to Debian systems only.
Best regards,
Daan Willems
-- System Information:
Debian Release: 11.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages fail2ban depends on:
ii lsb-base 11.1.0
ii python3 3.9.2-3
Versions of packages fail2ban recommends:
ii iptables 1.8.7-1
ii nftables 0.9.8-3.1
ii python3-pyinotify 0.9.6-1.3
ii python3-systemd234-3+b4
ii whois 5.5.10
Versions of packages fail2ban suggests:
ii bsd-mailx [mailx]8.1.2-0.20180807cvs-2
pn monit
ii rsyslog [system-log-daemon] 8.2102.0-2
pn sqlite3
-- Configuration Files:
/etc/fail2ban/filter.d/courier-auth.conf changed:
[INCLUDES]
before = common.conf
[Definition]
_daemon = (?:courier)?(?:imapd?|pop3d?)(?:login)?(?:-ssl)?
failregex = ^%(__prefix_line)sLOGIN FAILED, (?:user|method)=.*, ip=\[\].*$
ignoreregex =
datepattern = {^LN-BEG}
-- no debconf information
Bug#993232: lxc: Cannot add ipv4 gateway for network device "eth0" when not bringing up the interface.
On 1/28/22 08:19, Pierre-Elliott Bécue wrote: Control: tags -1 +moreinfo Le dimanche 29 août 2021 à 12:23:09+0800, John a écrit : Package: lxc Version: 1:4.0.10-1 Severity: normal X-Debbugs-Cc: jo...@wonghome.net Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** After upgraded lxc from 4.0.6-2 to 4.0.10-1. lxc container cannot start. I find the error with "lxc-start -l trace" like below: network.c:lxc_network_setup_in_child_namespaces_common:3894 - Cannot add ipv4 gateway for network device "eth0" when not bringing up the interface network.c:lxc_setup_network_in_child_namespaces:4038 - Function not implemented - Failed to setup netdev conf.c:lxc_setup:4080 - Failed to setup network start.c:do_start:1291 - Failed to setup container "vbox" If I rollback to 4.0.6-2, everything work fine as before. If I remove the line "lxc.net.0.ipv4.gateway = 10.0.3.1" in "/var/lib/lxc/vbox/config" (container config), the container can start again, but result no network , only loopback interface (lo) in container (no eth0 in container). From where I stand, I'm unable to reproduce: ❯ sudo lxc-create toto -t debian -- -r bullseye [snip] ❯ sudo service lxc-net start ❯ ip a [snip] 7: lxcbr0: mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0 valid_lft forever preferred_lft forever ❯ sudo lxc-ls -f NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED toto STOPPED 0 - --false ❯ sudo vim /var/lib/lxc/toto/config [adding ip conf] ❯ sudo cat /var/lib/lxc/toto/config # Template used to create this container: /usr/share/lxc/templates/lxc-debian # Parameters passed to the template: -r bullseye # For additional config options, please look at lxc.container.conf(5) # Uncomment the following line to support nesting containers: #lxc.include = /usr/share/lxc/config/nesting.conf # (Be aware this has security implications) lxc.net.0.type = veth lxc.net.0.hwaddr = 00:16:3e:cb:a1:76 lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.ipv4.address = 10.0.3.3/24 lxc.net.0.ipv4.gateway = 10.0.3.1 lxc.apparmor.profile = generated lxc.apparmor.allow_nesting = 1 lxc.rootfs.path = dir:/var/lib/lxc/toto/rootfs # Common configuration lxc.include = /usr/share/lxc/config/debian.common.conf # Container specific configuration lxc.tty.max = 4 lxc.uts.name = toto lxc.arch = amd64 lxc.pty.max = 1024 ❯ sudo lxc-start toto ❯ sudo lxc-ls -f NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED toto RUNNING 0 - 10.0.3.3 -false Please, try creating a new unprivileged container and make some tests with it, as for what I see, it doesn't seem like LXC is buggy. Cheers! Since the bug report is over a half year, and somehow I don't have the problem anymore, so I will close it first, if anyone has the problem present, please try to create a new bug report, thanks. Regards, John.
Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition
Hi, Am Thu, Jan 27, 2022 at 02:52:18PM -0700 schrieb Sean Whitton: > > We don't remove files for the sole reason that they're intended for use > on other platforms. It's typically only done if the files are huge. So > please remove this one from the list. > > How about just saying: we always remove non-DFSG files if the package is > intended for main or contrib, and sometimes there are other files that > are removed for technical reasons or because they are both unneeded and > very large, and both these sorts of removal are documented using this > field? I like this wording. I'm not sure whether we might add what I'm doing in practice: If there is the need to remove non-DFSG files it might make sense to use other files that are typically unused for Debian and thus are just bluring the content of the tarball. I'm unsure whether we should really add this to policy but this is what I'm doing. > > + > > +These types of files, or any others that Debian does not want to > > +include in our archive, must be stripped from the upstream tarball > > +prior to uploading. The Files-Excluded field > > serves > > How about "are stripped" not "must be stripped", as the normative stuff > is explained more precisely over in the Policy manual itself? +1 > > +to document the removal of these files from the original upstream > > +source. This allows others to understand or audit how the source > > +distribution in Debian is derived from the upstream source. > > + > > + > > +Additionally, once documented in this manner, various tools such as > > +uscan or mk-origtargz can use > > +this information as instructions on how to automatically repack an > > +upstream source distribution into one suitable for use within > > Debian. > > Nice. Thanks a lot for working on this in Debian policy Andreas. -- http://fam-tille.de
Bug#1003972: marked as done (libphonenumber: New upstream release - please update)
I saw the build errors. I think I've seen them before in local dev, and I think they're to do with parallel builds. The file with the compilation error is a generated file, and I think make is trying to compile it before it's fully generated. I'll investigate tomorrow.
Bug#998280: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core
Hi Amr, On Mon, Nov 01, 2021 at 07:33:35PM +, Amr Ibrahim wrote: > Please switch the dependency from ttf-bitstream-vera to fonts-dejavu- > core. The dejavu font extends the bitstream vera font, the bitstream > vera font is very obsolete, looks worse than dejavu and sometimes as a > negative side-effect it takes over as a default font when installed. Is ttf-bitstream-vera going away? If so, I'll just go back to distributing the copy from upstream. Otherwise, I'd prefer to stick with upstream's choice. EFL embeds font files in some of it's data structures. Bitstream Vera is used in one of the examples. So it isn't displayed anywhere. Ross
Bug#975074: libefreet-bin has circular Depends on libeio1
Control: tags 975074 wontfix Control: tags 963881 wontfix On Thu, Nov 19, 2020 at 08:58:43AM -0800, Ross Vandegrift wrote: > EFL's various libraries have dependency cycles between them. We haven't been > able to robustly eliminate them with split binary packages. The next step is > to bundle them into a single binary package. > > Upstream is working on linking all of them into a single lib. I'd like to > hold > off on the bundling until that is ready or abandoned. I played around with this and wrote about the results at [1]. The result was more complex, less maintainable, and didn't clearly result in the elimination of all cycles. Ross [1] - https://alioth-lists.debian.net/pipermail/pkg-e-devel/2021-May/004009.html
Bug#977469: matplotlib: Please make package bootstrappable
> > As suggested in an other bug report, moving the build-dependencies that > > are only needed to build -doc/arch:all packages to Build-Depends-Indep > > would also help here I guess but i am not willing to complicate the maintenance of matplotlib by splitting b-d and b-d-i. > I've made this merge request: > https://salsa.debian.org/python-team/packages/matplotlib/-/merge_requests/1 > > I duplicated some of the build-dependencies to make it more clear that > they are needed by both, if that's no OK I can rework my change and only > keep one You provide this patch as a one-off, and then i will be the one that will have to take care of maintaining it forever. that's not something i'm not willing to commit to. All of this to support the bootstrap of unofficial ports. bootstrapping is (AFAICT) a manual operation sometimes. I'm ok with annotating the current b-d with !stage1 where needed (or fix the current annotations if they are incorrect), if that facilitates your work. Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#1004465: libklibc-dev: headers not installed
Package: libklibc-dev Version: 2.0.10-3 Severity: grave Justification: renders package unusable X-Debbugs-Cc: t...@mirbsd.de Quite some files are missing: $ comm <($bullseye dpkg -L libklibc-dev | sort) <($sid dpkg -L libklibc-dev | sort) /. /usr /usr/bin /usr/bin/klcc /usr/lib /usr/lib/klibc /usr/lib/klibc/include /usr/lib/klibc/include/Kbuild /usr/lib/klibc/include/alloca.h /usr/lib/klibc/include/arch /usr/lib/klibc/include/arch/alpha /usr/lib/klibc/include/arch/alpha/klibc /usr/lib/klibc/include/arch/alpha/klibc/archconfig.h /usr/lib/klibc/include/arch/alpha/klibc/archsetjmp.h /usr/lib/klibc/include/arch/alpha/klibc/archsignal.h /usr/lib/klibc/include/arch/alpha/klibc/archstat.h /usr/lib/klibc/include/arch/alpha/machine /usr/lib/klibc/include/arch/alpha/machine/asm.h /usr/lib/klibc/include/arch/arm /usr/lib/klibc/include/arch/arm/klibc /usr/lib/klibc/include/arch/arm/klibc/archconfig.h /usr/lib/klibc/include/arch/arm/klibc/archsetjmp.h /usr/lib/klibc/include/arch/arm/klibc/archsignal.h /usr/lib/klibc/include/arch/arm/klibc/archstat.h /usr/lib/klibc/include/arch/arm/klibc/asmmacros.h /usr/lib/klibc/include/arch/arm64 /usr/lib/klibc/include/arch/arm64/klibc /usr/lib/klibc/include/arch/arm64/klibc/archconfig.h /usr/lib/klibc/include/arch/arm64/klibc/archsetjmp.h /usr/lib/klibc/include/arch/arm64/klibc/archsignal.h /usr/lib/klibc/include/arch/arm64/klibc/archstat.h /usr/lib/klibc/include/arch/i386 /usr/lib/klibc/include/arch/i386/klibc /usr/lib/klibc/include/arch/i386/klibc/archconfig.h /usr/lib/klibc/include/arch/i386/klibc/archinit.h /usr/lib/klibc/include/arch/i386/klibc/archsetjmp.h /usr/lib/klibc/include/arch/i386/klibc/archsignal.h /usr/lib/klibc/include/arch/i386/klibc/archstat.h /usr/lib/klibc/include/arch/i386/klibc/diverr.h /usr/lib/klibc/include/arch/i386/sys /usr/lib/klibc/include/arch/i386/sys/io.h /usr/lib/klibc/include/arch/i386/sys/vm86.h /usr/lib/klibc/include/arch/ia64 /usr/lib/klibc/include/arch/ia64/klibc /usr/lib/klibc/include/arch/ia64/klibc/archconfig.h /usr/lib/klibc/include/arch/ia64/klibc/archsetjmp.h /usr/lib/klibc/include/arch/ia64/klibc/archsignal.h /usr/lib/klibc/include/arch/ia64/klibc/archstat.h /usr/lib/klibc/include/arch/m68k /usr/lib/klibc/include/arch/m68k/klibc /usr/lib/klibc/include/arch/m68k/klibc/archconfig.h /usr/lib/klibc/include/arch/m68k/klibc/archsetjmp.h /usr/lib/klibc/include/arch/m68k/klibc/archsignal.h /usr/lib/klibc/include/arch/m68k/klibc/archstat.h /usr/lib/klibc/include/arch/mips /usr/lib/klibc/include/arch/mips/klibc /usr/lib/klibc/include/arch/mips/klibc/archconfig.h /usr/lib/klibc/include/arch/mips/klibc/archfcntl.h /usr/lib/klibc/include/arch/mips/klibc/archsetjmp.h /usr/lib/klibc/include/arch/mips/klibc/archsignal.h /usr/lib/klibc/include/arch/mips/klibc/archsocket.h /usr/lib/klibc/include/arch/mips/klibc/archstat.h /usr/lib/klibc/include/arch/mips/machine /usr/lib/klibc/include/arch/mips/machine/asm.h /usr/lib/klibc/include/arch/mips/sgidefs.h /usr/lib/klibc/include/arch/mips/spaces.h /usr/lib/klibc/include/arch/mips64 /usr/lib/klibc/include/arch/mips64/klibc /usr/lib/klibc/include/arch/mips64/klibc/archconfig.h /usr/lib/klibc/include/arch/mips64/klibc/archsetjmp.h /usr/lib/klibc/include/arch/mips64/klibc/archsignal.h /usr/lib/klibc/include/arch/mips64/klibc/archsocket.h /usr/lib/klibc/include/arch/mips64/klibc/archstat.h /usr/lib/klibc/include/arch/mips64/machine /usr/lib/klibc/include/arch/mips64/machine/asm.h /usr/lib/klibc/include/arch/parisc /usr/lib/klibc/include/arch/parisc/klibc /usr/lib/klibc/include/arch/parisc/klibc/archconfig.h /usr/lib/klibc/include/arch/parisc/klibc/archsetjmp.h /usr/lib/klibc/include/arch/parisc/klibc/archsignal.h /usr/lib/klibc/include/arch/parisc/klibc/archstat.h /usr/lib/klibc/include/arch/ppc /usr/lib/klibc/include/arch/ppc/klibc /usr/lib/klibc/include/arch/ppc/klibc/archconfig.h /usr/lib/klibc/include/arch/ppc/klibc/archsetjmp.h /usr/lib/klibc/include/arch/ppc/klibc/archsignal.h /usr/lib/klibc/include/arch/ppc/klibc/archstat.h /usr/lib/klibc/include/arch/ppc64 /usr/lib/klibc/include/arch/ppc64/klibc /usr/lib/klibc/include/arch/ppc64/klibc/archconfig.h /usr/lib/klibc/include/arch/ppc64/klibc/archsetjmp.h /usr/lib/klibc/include/arch/ppc64/klibc/archsignal.h /usr/lib/klibc/include/arch/ppc64/klibc/archstat.h /usr/lib/klibc/include/arch/riscv64 /usr/lib/klibc/include/arch/riscv64/klibc /usr/lib/klibc/include/arch/riscv64/klibc/archconfig.h /usr/lib/klibc/include/arch/riscv64/klibc/archsetjmp.h /usr/lib/klibc/include/arch/riscv64/klibc/archsignal.h /usr/lib/klibc/include/arch/riscv64/klibc/archstat.h /usr/lib/klibc/include/arch/riscv64/machine /usr/lib/klibc/include/arch/riscv64/machine/asm.h /usr/lib/klibc/include/arch/s390 /usr/lib/klibc/include/arch/s390/klibc /usr/lib/klibc/include/arch/s390/klibc/archconfig.h /usr/lib/klibc/include/arch/s390/klibc/archsetjmp.h
Bug#1004464: python-django FTBFS: FAIL: test_custom_fields (inspectdb.tests.InspectDBTestCase)
Source: python-django
Version: 2:3.2.7-1
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/fetch.php?pkg=python-django=all=2%3A3.2.11-1=1641309500=0
...
==
FAIL: test_custom_fields (inspectdb.tests.InspectDBTestCase)
Introspection of columns with a custom field (#21090)
--
Traceback (most recent call last):
File "/usr/lib/python3.10/unittest/case.py", line 59, in testPartExecutor
yield
File "/usr/lib/python3.10/unittest/case.py", line 591, in run
self._callTestMethod(testMethod)
File "/usr/lib/python3.10/unittest/case.py", line 549, in _callTestMethod
method()
File "/<>/tests/inspectdb/tests.py", line 313, in
test_custom_fields
self.assertIn("text_field = myfields.TextField()", output)
File "/usr/lib/python3.10/unittest/case.py", line 1112, in assertIn
self.fail(self._formatMessage(msg, standardMsg))
File "/usr/lib/python3.10/unittest/case.py", line 675, in fail
raise self.failureException(msg)
AssertionError: 'text_field = myfields.TextField()' not found in "# This is an
auto-generated Django model module.\n# You'll have to do the following manually
to clean this up:\n# * Rearrange models' order\n# * Make sure each model
has one field with primary_key=True\n# * Make sure each ForeignKey and
OneToOneField has `on_delete` set to the desired behavior\n# * Remove
`managed = False` lines if you wish to allow Django to create, modify, and
delete the table\n# Feel free to rename the models, but don't rename db_table
values or field names.\nfrom django.db import models\n\n\nclass
InspectdbColumntypes(models.Model):\nid =
models.TextField(primary_key=True) # This field type is a guess.\n
big_int_field = models.BigIntegerField()\nbool_field = models.TextField()
# This field type is a guess.\nnull_bool_field =
models.TextField(blank=True, null=True) # This field type is a guess.\n
char_field = models.TextField() # This field type is a guess.\n
null_char_field = models.TextField(blank=True, null=True) # This field type is
a guess.\ndate_field = models.TextField() # This field type is a guess.\n
date_time_field = models.TextField() # This field type is a guess.\n
decimal_field = models.TextField() # This field type is a guess.\n
email_field = models.TextField() # This field type is a guess.\nfile_field
= models.TextField() # This field type is a guess.\nfile_path_field =
models.TextField() # This field type is a guess.\nfloat_field =
models.TextField() # This field type is a guess.\nint_field =
models.TextField() # This field type is a guess.\ngen_ip_address_field =
models.TextField() # This field type is a guess.\npos_big_int_field =
models.TextField() # This field type is a guess.\npos_int_field =
models.TextField() # This field type is a guess.\npos_small_int_field =
models.TextField() # This field type is a guess.\nslug_field =
models.TextField() # This field type is a guess.\nsmall_int_field =
models.TextField() # This field type is a guess.\ntext_field =
models.TextField() # This field type is a guess.\ntime_field =
models.TextField() # This field type is a guess.\nurl_field =
models.TextField() # This field type is a guess.\nuuid_field =
models.TextField() # This field type is a guess.\n\nclass Meta:\n
managed = False\ndb_table = 'inspectdb_columntypes'\n"
--
Ran 14650 tests in 151.514s
FAILED (failures=1, skipped=1141, expected failures=4)
Destroying test database for alias 'default'
('file:memorydb_default?mode=memory=shared')...
Destroying test database for alias 'default'
('file:memorydb_default?mode=memory=shared')...
Destroying test database for alias 'default'
('file:memorydb_default?mode=memory=shared')...
Destroying test database for alias 'default'
('file:memorydb_default?mode=memory=shared')...
Destroying test database for alias 'default'
('file:memorydb_default?mode=memory=shared')...
Destroying test database for alias 'other'
('file:memorydb_other?mode=memory=shared')...
Destroying test database for alias 'other'
('file:memorydb_other?mode=memory=shared')...
Destroying test database for alias 'other'
('file:memorydb_other?mode=memory=shared')...
Destroying test database for alias 'other'
('file:memorydb_other?mode=memory=shared')...
Destroying test database for alias 'other'
('file:memorydb_other?mode=memory=shared')...
make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1
Bug#1004463: python3-jsondiff,cbmc: File conflict for /usr/bin/jdiff
Package: python3-jsondiff,cbmc Version: python3-jsondiff/1.3.1-1 Version: cbmc/5.12-5 Severity: serious Upgrading python3-jsondiff from 1.1.1-4 to 1.3.1-1 fails for me as follows: Preparing to unpack .../python3-jsondiff_1.3.1-1_all.deb ... Unpacking python3-jsondiff (1.3.1-1) over (1.1.1-4) ... dpkg: error processing archive /var/cache/apt/archives/python3-jsondiff_1.3.1-1_all.deb (--unpack): trying to overwrite '/usr/bin/jdiff', which is also in package cbmc 5.12-5 (Note: There might be more file conflict than this one between those two packages, because dpkg already aborts on the first conflict and doesn't report potential further ones. Typical example: program and man pages) Since I suspect that these two variants of "jdiff" do completely different things, it's probably no option to use the alternatives system in this case. Which leaves the following options: * Renaming the file in either or both packages. * Making the packages conflict with each other. (Suffices to be fixed in one package.) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages python3-jsondiff depends on: ii python3 3.9.8-1 python3-jsondiff recommends no packages. python3-jsondiff suggests no packages. -- no debconf information
Bug#1004462: ITP: node-should-sinon -- Sinon.js assertions for should.js
Package: wnpp Severity: wishlist Owner: Doug Torrance X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu * Package name: node-should-sinon Version : 0.0.6 Upstream Author : Denis Bardadym * URL : https://github.com/shouldjs/sinon * License : Expat Programming Lang: JavaScript Description : Sinon.js assertions for should.js should is an expressive, readable, framework-agnostic assertion library. The main goals of this library are to be expressive and to be helpful. It keeps your test code clean, and your error messages helpful. This module adds additional assertions for sinon.js, which provides standalone test spies, stubs and mocks. Node.js is an event-based server-side JavaScript engine. I plan to maintain this package as a member of the Debian JavaScript Team. signature.asc Description: PGP signature
Bug#1004461: python-anyio FTBFS on IPV6-only buildds
Source: python-anyio
Version: 3.3.0-4
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/logs.php?pkg=python-anyio=all
...
_ TestTLSListener.test_handshake_fail[asyncio] _
tests/streams/test_tls.py:328: in test_handshake_fail
listener = await create_tcp_listener(local_host='127.0.0.1')
anyio/_core/_sockets.py:236: in create_tcp_listener
gai_res = await getaddrinfo(local_host, local_port, family=family, # type:
ignore[arg-type]
anyio/_core/_sockets.py:419: in getaddrinfo
gai_res = await get_asynclib().getaddrinfo(encoded_host, port,
family=family, type=type,
anyio/_backends/_asyncio.py:1570: in getaddrinfo
result = await get_running_loop().getaddrinfo(
/usr/lib/python3.9/asyncio/base_events.py:856: in getaddrinfo
return await self.run_in_executor(
/usr/lib/python3.9/concurrent/futures/thread.py:58: in run
result = self.fn(*self.args, **self.kwargs)
/usr/lib/python3.9/asyncio/base_events.py:839: in _getaddrinfo_debug
addrinfo = socket.getaddrinfo(host, port, family, type, proto, flags)
/usr/lib/python3.9/socket.py:954: in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
E socket.gaierror: [Errno -9] Address family for hostname not supported
=== short test summary info
SKIPPED [1] tests/test_taskgroups.py:57: could not import 'trio': No module
named 'trio'
SKIPPED [1] tests/test_fileio.py:119: Drive only makes sense on Windows
SKIPPED [1] tests/test_fileio.py:159: Only makes sense on Windows
SKIPPED [2] tests/test_fileio.py:318: os.lchmod() is not available
=== 57 failed, 696 passed, 5 skipped, 2 deselected in 28.27s ===
E: pybuild pybuild:367: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.9/build; python3.9 -m pytest --verbose -W
ignore -k "not test_is_block_device"
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9
--before-test "{interpreter} {dir}/setup.py egg_info
--egg-base={dir}/.pybuild/egg" --test-pytest --test-args "--verbose -W ignore
-k \"not test_is_block_device\"" returned exit code 13
make[1]: *** [debian/rules:14: override_dh_auto_test] Error 25
Bug#1004460: ruby-html-proofer accesses the internet during the build
Source: ruby-html-proofer Version: 3.19.2-2 Severity: serious Tags: ftbfs https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/ruby-html-proofer.html https://buildd.debian.org/status/fetch.php?pkg=ruby-html-proofer=all=3.19.2-3=1643324945=0 ... Failures: 1) Command test works with as-links [31mFailure/Error: [0m[32mexpect[0m(output).to match([31m[1;31m'[0m[31m1 failure[1;31m'[0m[31m[0m)[0m [31m[0m [31m expected "Running [\"LinkCheck\"] on [\"www.github.com\", \"foofoofoo.biz\"]... \n\n\nChecking 2 external link...message (if any) from the server is: Couldn't connect to server\n\nHTML-Proofer found 2 failures!\n" to match "1 failure"[0m [31m Diff:[0m[0m [31m [0m[34m@@ -1,16 +1,31 @@[0m [31m [0m[31m-1 failure[0m [31m [0m[32m+Running ["LinkCheck"] on ["www.github.com", "foofoofoo.biz"]... [0m [31m [0m[32m+[0m [31m [0m[32m+[0m [31m [0m[32m+Checking 2 external links...[0m [31m [0m[32m+[0m [31m [0m[32m+- [0m [31m [0m[32m+ * External link http://foofoofoo.biz/ failed: response code 0 means something's wrong.[0m [31m [0m[32m+ It's possible libcurl couldn't connect to the server or perhaps the request timed out.[0m [31m [0m[32m+ Sometimes, making too many requests at once also breaks things.[0m [31m [0m[32m+ Either way, the return message (if any) from the server is: Couldn't resolve host name[0m [31m [0m[32m+ * External link http://www.github.com/ failed: response code 0 means something's wrong.[0m [31m [0m[32m+ It's possible libcurl couldn't connect to the server or perhaps the request timed out.[0m [31m [0m[32m+ Sometimes, making too many requests at once also breaks things.[0m [31m [0m[32m+ Either way, the return message (if any) from the server is: Couldn't connect to server[0m [31m [0m[32m+[0m [31m [0m[32m+HTML-Proofer found 2 failures![0m [31m [0m[0m [36m# ./spec/html-proofer/command_spec.rb:8:in `block (2 levels) in '[0m Finished in 29.48 seconds (files took 1.11 seconds to load) [31m289 examples, 1 failure, 2 pending[0m Failed examples: [31mrspec ./spec/html-proofer/command_spec.rb:6[0m [36m# Command test works with as-links[0m Randomized with seed 53943 /usr/bin/ruby2.7 -I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib /usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec --pattern ./spec/\*\*/\*_spec.rb --format documentation failed ERROR: Test "ruby2.7" failed. Exiting. dh_auto_install: error: dh_ruby --install /<>/debian/ruby-html-proofer returned exit code 1 make: *** [debian/rules:8: binary-indep] Error 25
Bug#997666: flufl.bounce: please update to 4.0
Pierre-Elliott Bécue writes: > Sorry for having taken that long. > > I've not put a close statement in my upload because I wanted to make > sure that you are aware that uploading 4.0 in stable is probably not an > option. > > Would you like me to backport this package? > For whatever reason, I've stopped getting those particular bounces in the mean time. So I think it makes sense to backport the package as it kind of needs to keep up with the weirdness of the internet, but it's not urgent for me personally. Thanks for your attention, David
Bug#1002564: [pkg-lxc-devel] Bug#1002564: lxc: packaging adjustments for LXD
Le dimanche 26 décembre 2021 à 16:03:41+, Mathias Gibbens a écrit : > On Sun, 26 Dec 2021 12:33:43 -0300 Antonio Terceiro > wrote: > > On Sat, Dec 25, 2021 at 02:25:06PM +, Evgeni Golov wrote: > > > On December 25, 2021 12:35:45 PM UTC, Antonio Terceiro > wrote: > > > >They probably would need to be provided by a (NEW) lxc-common > package. > > > >If we ever need to transition to liblxc2, we don't want both > liblxc* > > > >packages providing those files. > > > > > > On Ubuntu, this package us called liblxc-common, which we probably > > > should also use, to make life of other consumers easier? > > > > Sure! I didn't check there first. > > I think a liblxc-common package should work just fine. I haven't > found any other files in the lxc package that LXD is expecting to have > around, but if I do I'll update this bug. > > I'm happy to help test any changes to the packaging when they're > ready. > > Thanks! I've made some changes I've decided to upload on salsa and on experimental. If you're able to test these changes on some clean environment, I'd be happy if you could do it as I like the time to redo a clean testing environment for lxc right now. If you can't, I'll try to do it this weekend or during the next week. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1004459: bullseye-pu: package lxc/1:4.0.6-2+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
This update fixes the download of container images using the "download"
template. pool.sks-keyservers.net is not active anymore, so the patch
(already included in the upstream release present in sid/bookworm)
changes that to keyserver.ubuntu.com.
[ Impact ]
Creating containers with the lxc-download template (`-t download`) does
not work because the key that signs the images cannot be retrieved.
[ Tests ]
This has been tested on lxc and was verified to fix the issue. The patch
is trivial.
[ Risks ]
None.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Replace pool.sks-keyservers.net with keyserver.ubuntu.com.
diff --git a/debian/changelog b/debian/changelog
index 6a5c2db..e6bcbc6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+lxc (1:4.0.6-2+deb11u1) bullseye; urgency=medium
+
+ * lxc-download: Switch GPG server.
+The default server used to download gpg keys from has ben deprecated,
+and therefore creating containers using the `download` template is now
+broken. This is fixed with an upstream patch by Stéphane Graber that
+points to a valid server. (Closes: #991615)
+
+ -- Antonio Terceiro Thu, 13 Jan 2022 16:57:39 -0300
+
lxc (1:4.0.6-2) unstable; urgency=medium
* d/contrib/lxc-net: Add a commented dnsmasq reference for the users to be
diff --git a/debian/patches/0005-lxc-download-Switch-GPG-server.patch b/debian/patches/0005-lxc-download-Switch-GPG-server.patch
new file mode 100644
index 000..ac7074c
--- /dev/null
+++ b/debian/patches/0005-lxc-download-Switch-GPG-server.patch
@@ -0,0 +1,30 @@
+From: =?utf-8?q?St=C3=A9phane_Graber?=
+Date: Sun, 27 Jun 2021 23:42:52 -0400
+Subject: lxc-download: Switch GPG server
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Stéphane Graber
+---
+ templates/lxc-download.in | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/templates/lxc-download.in b/templates/lxc-download.in
+index d688b8f..2f6cf2a 100644
+--- a/templates/lxc-download.in
b/templates/lxc-download.in
+@@ -56,11 +56,11 @@ LXC_PATH=
+ LXC_ROOTFS=
+
+ if [ -z "${DOWNLOAD_KEYSERVER:-}" ]; then
+- DOWNLOAD_KEYSERVER="hkp://pool.sks-keyservers.net"
++ DOWNLOAD_KEYSERVER="hkp://keyserver.ubuntu.com"
+
+ # Deal with GPG over http proxy
+ if [ -n "${http_proxy:-}" ]; then
+-DOWNLOAD_KEYSERVER="hkp://p80.pool.sks-keyservers.net:80"
++DOWNLOAD_KEYSERVER="hkp://keyserver.ubuntu.com:80"
+ DOWNLOAD_GPG_PROXY="--keyserver-options http-proxy=\"${http_proxy}\""
+ fi
+ fi
diff --git a/debian/patches/series b/debian/patches/series
index f952766..d98fa8f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
0005-lxc.service-Starts-after-remote-fs.target.patch
0006-lxc.pc.in-removes-DLOG_LIBS-which-is-not-expanded-up.patch
0007-conf-fix-containers-retaining-CAP_NET_ADMIN.patch
+0005-lxc-download-Switch-GPG-server.patch
signature.asc
Description: PGP signature
Bug#993232: lxc: Cannot add ipv4 gateway for network device "eth0" when not bringing up the interface.
Control: tags -1 +moreinfo Le dimanche 29 août 2021 à 12:23:09+0800, John a écrit : > Package: lxc > Version: 1:4.0.10-1 > Severity: normal > X-Debbugs-Cc: jo...@wonghome.net > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > After upgraded lxc from 4.0.6-2 to 4.0.10-1. lxc container cannot start. > I find the error with "lxc-start -l trace" like below: > > network.c:lxc_network_setup_in_child_namespaces_common:3894 - Cannot > add ipv4 gateway for network device "eth0" when not bringing up the interface > network.c:lxc_setup_network_in_child_namespaces:4038 - Function not > implemented - Failed to setup netdev > conf.c:lxc_setup:4080 - Failed to setup network > start.c:do_start:1291 - Failed to setup container "vbox" > > If I rollback to 4.0.6-2, everything work fine as before. > If I remove the line "lxc.net.0.ipv4.gateway = 10.0.3.1" in > "/var/lib/lxc/vbox/config" (container config), > the container can start again, but result no network , only loopback > interface (lo) in container (no eth0 in container). From where I stand, I'm unable to reproduce: ❯ sudo lxc-create toto -t debian -- -r bullseye [snip] ❯ sudo service lxc-net start ❯ ip a [snip] 7: lxcbr0: mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0 valid_lft forever preferred_lft forever ❯ sudo lxc-ls -f NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED toto STOPPED 0 - --false ❯ sudo vim /var/lib/lxc/toto/config [adding ip conf] ❯ sudo cat /var/lib/lxc/toto/config # Template used to create this container: /usr/share/lxc/templates/lxc-debian # Parameters passed to the template: -r bullseye # For additional config options, please look at lxc.container.conf(5) # Uncomment the following line to support nesting containers: #lxc.include = /usr/share/lxc/config/nesting.conf # (Be aware this has security implications) lxc.net.0.type = veth lxc.net.0.hwaddr = 00:16:3e:cb:a1:76 lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.ipv4.address = 10.0.3.3/24 lxc.net.0.ipv4.gateway = 10.0.3.1 lxc.apparmor.profile = generated lxc.apparmor.allow_nesting = 1 lxc.rootfs.path = dir:/var/lib/lxc/toto/rootfs # Common configuration lxc.include = /usr/share/lxc/config/debian.common.conf # Container specific configuration lxc.tty.max = 4 lxc.uts.name = toto lxc.arch = amd64 lxc.pty.max = 1024 ❯ sudo lxc-start toto ❯ sudo lxc-ls -f NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED toto RUNNING 0 - 10.0.3.3 -false Please, try creating a new unprivileged container and make some tests with it, as for what I see, it doesn't seem like LXC is buggy. Cheers! -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1004458: RFS: utf8gen/1.1-4 [QA] -- convert ASCII hexadecimal Unicode code points to UTF-8
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: lourisva...@figueredo.tec.br Dear mentors, I am looking for a sponsor for my package "utf8gen": * Package name: utf8gen Version : 1.1-4 Upstream Author : Paul Hardy * URL : https://unifoundry.com/utf8gen/ * License : GPL-2+, GFDL-1.3+ * Vcs : https://salsa.debian.org/debian/utf8gen Section : text It builds those binary packages: utf8gen - convert ASCII hexadecimal Unicode code points to UTF-8 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/utf8gen/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/utf8gen/utf8gen_1.1-4.dsc Changes since the last upload: utf8gen (1.1-4) unstable; urgency=medium . * QA upload. * Using new DH level format. Consequently: - debian/compat: removed. - debian/control: changed from 'debhelper' to 'debhelper-compat' in Build-Depends field and bumped to 13. * debian/control: - Added 'Rules-Requires-Root: no' to source stanza. - Added Vcs-* fields. - Bumped Standards-Version to 4.6.0.1. - Using a secure URI in Homepage field. * debian/copyright: - Using a secure URI in Source field. - Removed duplicate license. - Separated packaging license from upstream license. * debian/salsa-ci.yml: created to provide CI tests for salsa. * debian/tests/control: updated. * debian/watch: cleaned and using a secure URI. The git repository is on my salsa account[1]. Please, move this to debian repository[2]. Any tips or suggestions given will be welcome. Regards, -- Lourisvaldo Figueredo Junior [1] https://salsa.debian.org/figueredo/utf8gen [2] https://salsa.debian.org/debian/utf8gen
Bug#1004406: ffmpeg: symbol lookup error undefined symbol drmModeGetFB2
Hello again. Hmm. I'm guessing all you need is this. $ ldd -r /usr/lib/x86_64-linux-gnu/libavdevice.so.58 | grep drm libdrm.so.2 => /opt/amdgpu/lib/x86_64-linux-gnu/libdrm.so.2 (0x7fdb5039) libva-drm.so.2 => /usr/lib/x86_64-linux-gnu/libva-drm.so.2 (0x7fdb49758000) undefined symbol: drmModeGetFB2 (/usr/lib/x86_64-linux-gnu/libavdevice.so.58) undefined symbol: drmModeFreeFB2 (/usr/lib/x86_64-linux-gnu/libavdevice.so.58) Le jeu. 27 janv. 2022 à 16:33, Sebastian Ramacher a écrit : > On 2022-01-26 19:34:51 -0500, Le Déchaîné wrote: > > $ echo $LD_LIBRARY_PATH > > (not set) > > > > $ locate libdrm.so > > /opt/amdgpu/lib/i386-linux-gnu/libdrm.so.2 > > /opt/amdgpu/lib/i386-linux-gnu/libdrm.so.2.4.0 > > /opt/amdgpu/lib/x86_64-linux-gnu/libdrm.so.2 > > /opt/amdgpu/lib/x86_64-linux-gnu/libdrm.so.2.4.0 > > /usr/lib/i386-linux-gnu/libdrm.so.2 > > /usr/lib/i386-linux-gnu/libdrm.so.2.4.0 > > /usr/lib/x86_64-linux-gnu/libdrm.so > > /usr/lib/x86_64-linux-gnu/libdrm.so.2 > > /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0 > > And if you run lddr -r /usr/lib/x86_64-linux-gnu/libavdevice.so.58, > which of those is useD? > > Cheers > > > (except /var/lib/flatpaks (augh!) and some steamapps/SteamLinuxRuntime > > files) > > > > Le mer. 26 janv. 2022 à 18:28, Sebastian Ramacher > a > > écrit : > > > > > Control: tags -1 moreinfo > > > > > > On 2022-01-26 18:08:00 -0500, Jimmy K. wrote: > > > > Package: ffmpeg > > > > Version: 7:4.4.1-3 > > > > Severity: important > > > > X-Debbugs-Cc: ledecha...@gmail.com > > > > > > > > Dear Maintainer, > > > > this version of ffmpeg has been useless on my system, for many > months. > > > > > > > > $ ffmpeg > > > > ffmpeg: symbol lookup error: > > > /usr/lib/x86_64-linux-gnu/libavdevice.so.58: undefined symbol: > drmModeGetFB2 > > > > > > > > -Downgrading with sudo apt-get install ffmpeg=7:4.3.3-0+deb11u1 fixes > > > it, but > > > > it's too late for that, apparently. > > > > -BUT getting the source from github and "configure, make, sudo make > > > install", > > > > worked. I don't know what's different. > > > > > > Since libavdevice58 depends on a recent enough version of libdrm2, I > > > suppose that you have an old version of libdrm.so.2 somewhere in > > > /usr/local/lib or your LD_LIBRARY_PATH. Can you confirm that? > > > > > > Cheers > > > > > > > > > > > -- System Information: > > > > Debian Release: bookworm/sid > > > > APT prefers stable-updates > > > > APT policy: (500, 'stable-updates'), (500, 'testing'), (500, > 'stable') > > > > Architecture: amd64 (x86_64) > > > > Foreign Architectures: i386 > > > > > > > > Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) > > > > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > > > > Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), > > > LANGUAGE=fr_CA:fr > > > > Shell: /bin/sh linked to /bin/dash > > > > Init: systemd (via /run/systemd/system) > > > > LSM: AppArmor: enabled > > > > > > > > Versions of packages ffmpeg depends on: > > > > ii libavcodec587:4.4.1-3 > > > > ii libavdevice58 7:4.4.1-3 > > > > ii libavfilter77:4.4.1-3 > > > > ii libavformat58 7:4.4.1-3 > > > > ii libavutil56 7:4.4.1-3 > > > > ii libc6 2.33-3 > > > > ii libpostproc55 7:4.4.1-3 > > > > ii libsdl2-2.0-0 2.0.20+dfsg-2 > > > > ii libswresample3 7:4.4.1-3 > > > > ii libswscale5 7:4.4.1-3 > > > > > > > > ffmpeg recommends no packages. > > > > > > > > Versions of packages ffmpeg suggests: > > > > pn ffmpeg-doc > > > > > > > > -- no debconf information > > > > > > > > > > -- > > > Sebastian Ramacher > > > > > -- > Sebastian Ramacher >
Bug#1003689: chromium: Chromium doesn't start
On 1/27/22 18:50, Amr Ibrahim wrote: Hello, I just want to give a small guide into how to enable Wayland again for people like me who prefer Wayland and it works well for them: 1. Start chromium 2. Type chrome://flags in the address bar 3. Search for ozone 4. Change "Preferred Ozone platform" into "Auto" 5. Restart chromium Best, Amr Thanks. Yes, you can also run "chromium --ozone-platform=wayland" to get native wayland. Cc'ing to the wayland bug report so others see this as well.
Bug#1003689: chromium: Chromium doesn't start
Hello, I just want to give a small guide into how to enable Wayland again for people like me who prefer Wayland and it works well for them: 1. Start chromium 2. Type chrome://flags in the address bar 3. Search for ozone 4. Change "Preferred Ozone platform" into "Auto" 5. Restart chromium Best, Amr
Bug#976402: Proposed official virtual packages - todo and todo.txt
On 1/27/22 5:11 PM, Sean Whitton wrote: Hello David, ... Reviewing this bug, it is still not clear to me that a virtual package is wanted as opposed to just making /usr/bin/todo a path managed by the alternatives system. I'm closing the bug, but if development that has taken place in the todo.txt world since our previous dicsussion has changed matters such that there are concrete usecases for the virtual packages that you can explain, then please consider opening a new bug with that explanation. We have a significant disconnect here. The todo.txt-base (and gtd) packages place more requirements on an alternative implementations other than just owning the name. The proposed virtual package would codify that contract. That represents a concrete set of use cases, laid out previously in this thread, in Dec 2020 (the stuff about autodiscovery of the datafile, and support of hooks - both allow todo.txt-gtd to properly interact). The packages that interact with todo.txt are released: https://tracker.debian.org/pkg/todo.txt-base https://github.com/davesteele/todo.txt-base https://packages.debian.org/sid/todo.txt-gtd Also, aesthetically, I believe that Debian should have a package named todo.txt that installs todo.txt-cli by default. OTOH, I undertook this process only because Ondrej required it before supporting integration of todo.txt-cli with todo.txt-base. I'd be happy to support the majority consensus between the three of us on how to proceed. OpenPGP_signature Description: OpenPGP digital signature
Bug#964745: lxc-start fails when specifying a custom lxc.net.0.hwaddr (on armv7l)
Hi Santiago, I'd like to resume on that bug: did you either find a solution for it or an explanation for this behaviour? Could you try to have a go with lxc4? Cheers! -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1004457: okular segfaults upon opening specific pdf (worked with previous version)
Package: okular Version: 4:21.08.3-1 Severity: important Dear Maintainer, After updating my system, Okular segfaults upon opening a specific pdf file. I have previously viewed it using okular (not sure exactly which version was previously installed) -- and can still view it with zathura -- without incident. I can provide the offending file, though I would prefer to do so off-list. Backtrace: (gdb) r 211227-zichron-menachem-NIS-1750.pdf Starting program: /usr/bin/okular 211227-zichron-menachem-NIS-1750.pdf [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x718f8640 (LWP 21480)] (okular:21462): dbind-WARNING **: 01:05:01.357: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files [New Thread 0x7fffebf6d640 (LWP 21481)] Icon theme "nuoveXT-1.6" not found. Icon theme "Tango" not found. Icon theme "gnome" not found. Icon theme "crystalsvg" not found. Icon theme "breeze" not found. Thread 1 "okular" received signal SIGSEGV, Segmentation fault. Poppler::Document::signatures (this=0x55ba7e40) at ./qt5/src/poppler-document.cc:822 Download failed: Invalid argument. Continuing without source file ./obj-x86_64-linux-gnu/qt5/src/./qt5/src/poppler-document.cc. 822 ./qt5/src/poppler-document.cc: No such file or directory. (gdb) bt #0 Poppler::Document::signatures (this=0x55ba7e40) at ./qt5/src/poppler-document.cc:822 #1 0x7fffe90b73a4 in PDFGenerator::loadPages (this=this@entry=0x55ab2a00, pagesVector=..., rotation=rotation@entry=0, clear=clear@entry=false) at ./generators/poppler/generator_pdf.cpp:790 #2 0x7fffe90b789a in PDFGenerator::init (this=0x55ab2a00, pagesVector=..., password=...) at ./generators/poppler/generator_pdf.cpp:654 #3 0x7fffeb468639 in Okular::DocumentPrivate::openDocumentInternal (this=0x5566ae00, offer=..., isstdin=isstdin@entry=false, docFile=..., filedata=..., password=...) at ./core/document.cpp:890 #4 0x7fffeb468d81 in Okular::Document::openDocument (this=this@entry=0x5575abb0, docFile=..., url=..., _mime=..., password=...) at ./core/document.cpp:2330 #5 0x7fffeb5c0205 in Okular::Part::doOpenFile (this=this@entry=0x5571f000, mimeA=..., fileNameToOpenA=..., isCompressedFile=isCompressedFile@entry=0x7fffda47) at ./part/part.cpp:1393 #6 0x7fffeb5c0fb3 in Okular::Part::openFile (this=0x5571f000) at ./part/part.cpp:1511 #7 0x77f78325 in KParts::ReadOnlyPartPrivate::openLocalFile (this=this@entry=0x55699200) at ./src/readonlypart.cpp:180 #8 0x77f793fe in KParts::ReadOnlyPart::openUrl (this=this@entry=0x5571f000, url=...) at ./src/readonlypart.cpp:141 #9 0x7fffeb5b1983 in Okular::Part::openUrl (this=, _url=..., swapInsteadOfOpening=) at ./part/part.cpp:1743 #10 0x5556a761 in Shell::openUrl (this=, url=..., serializedOptions=...) at ./shell/shell.cpp:285 #11 0x5556aa53 in Shell::openDocument (serializedOptions=..., url=..., this=0x55669a30) at ./shell/shell.cpp:236 #12 Shell::openDocument (this=this@entry=0x55669a30, url=..., serializedOptions=...) at ./shell/shell.cpp:224 #13 0x55561d8a in Okular::main (paths=..., serializedOptions=...) at ./shell/okular_main.cpp:162 #14 0x55561a6b in main (argc=, argv=) at ./shell/main.cpp:91 quit) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_IL:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages okular depends on: ii kinit 5.88.0-1 ii kio 5.88.0-1 ii libc6 2.33-4+b1 ii libfreetype6 2.11.1+dfsg-1 ii libjpeg62-turbo 1:2.1.2-1 ii libkf5activities5 5.88.0-1 ii libkf5archive55.88.0-1 ii libkf5bookmarks5 5.88.0-1 ii libkf5codecs5 5.88.0-1 ii libkf5completion5 5.88.0-1 ii libkf5configcore5 5.88.0-1 ii libkf5configgui5 5.88.0-1 ii libkf5configwidgets5 5.88.0-1 ii libkf5coreaddons5 5.88.0-1 ii libkf5crash5 5.88.0-1 ii libkf5i18n5 5.88.0-2 ii libkf5itemviews5 5.88.0-1 ii libkf5jobwidgets5 5.88.0-1 ii libkf5kexiv2-15.0.0 21.08.0-1 ii libkf5kiocore55.88.0-1 ii libkf5kiowidgets5 5.88.0-1 ii libkf5parts5 5.88.0-1 ii libkf5pty55.88.0-1 ii libkf5purpose-bin 5.88.0-1 ii libkf5purpose55.88.0-1 ii
Bug#991759: lxc fails to start a container with xfs root after host is booted
Control: tags -1 +wontfix Le dimanche 01 août 2021 à 12:05:05+0300, Markus Iehoven a écrit : > Package: lxc > Version: 1:4.0.6-2 > Severity: important > > Debian GNU/Linux 11 (bullseye) 5.10.0-8-amd64 #1 SMP Debian 5.10.46-3 > > I have a lxc container with root on a LVM volume formated to XFS. The > container can not be started after host is rebooted. look like XFS > module is not loaded at this time. modprobe xfs fixes the problem. But > I thinks that it should be done automatically > > ~# lxc-start -n mongo -F > > lxc-start: mongo: storage/storage_utils.c: mount_unknown_fs: 298 > Failed to determine FSType for "/dev/fast/mongo" > lxc-start: mongo: conf.c: lxc_mount_rootfs: 1257 Failed to mount > rootfs "/dev/fast/mongo" onto "/usr/lib/x86_64-linux-gnu/lxc/rootfs" > with options "(null)" > lxc-start: mongo: conf.c: lxc_setup_rootfs_prepare_root: 3142 Failed > to setup rootfs for > lxc-start: mongo: conf.c: lxc_setup: 3278 Failed to setup rootfs > lxc-start: mongo: start.c: do_start: 1218 Failed to setup container "mongo" > lxc-start: mongo: sync.c: __sync_wait: 36 An error occurred in > another process (expected sequence number 5) > lxc-start: mongo: start.c: __lxc_start: 1999 Failed to spawn container > "mongo" > lxc-start: mongo: tools/lxc_start.c: main: 308 The container failed to start > lxc-start: mongo: tools/lxc_start.c: main: 313 Additional information > can be obtained by setting the --logfile and --logpriority options > > it works: > ~# modprobe xfs && lxc-start -n mongo Hi, I am sorry but this is not something to be done by LXC: LXC is an end user program that should not load any third party driver automatically. It's the job of the system administrator to add to modules-load.d the configuration to load such modules on their machines. With best regards, -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1004456: php-common 2:92 erroneously promoted to testing
Package: php-common Version: 2:76 Severity: important X-Debbugs-Cc: d0sbo...@gmail.com The current version of php-common in testing is 2:92, which is the same as sid. The current version of php-raphf in testing is 2.0.1+1.1.2-1. The current version of php-raphf in sid is 2.0.1+1.1.2-13. php-common 2:92 breaks php-raphf < 2.0.1+1.1.2-13~. Therefore, it should not have been promoted to testing, since the applicable version of php-raphf is not available yet. Its promotion makes php-raphf uninstallable. As a side note, this seems like it would be better expressed in the dependencies of php-raphf, instead of as a Breaks in php-common? -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (501, 'testing'), (100, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages php-common depends on: ii psmisc 23.4-2 ii sed 4.7-1 php-common recommends no packages. php-common suggests no packages. -- no debconf information
Bug#1004455: python3-mappy: undefined symbol ksw_extz2_sse on several architectures
Package: python3-mappy Version: 2.22+dfsg-3 Severity: serious Control: block 1001716 by -1 Control: affects -1 src:nanolyse https://tracker.debian.org/pkg/minimap2 Migration status for minimap2 (2.17+dfsg-12 to 2.22+dfsg-3): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: ∙ ∙ autopkgtest for nanolyse/1.2.0-2: amd64: Pass, arm64: Pass, armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻) This is due to: (sid_armhf-dchroot)bunk@amdahl:~$ python3 Python 3.9.10 (main, Jan 16 2022, 17:12:18) [GCC 11.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import mappy Traceback (most recent call last): File "", line 1, in ImportError: /usr/lib/python3/dist-packages/mappy.cpython-39-arm-linux-gnueabihf.so: undefined symbol: ksw_extz2_sse >>>
Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines?
It looks like the missing patch made its way into
5.15.0-0.bpo.2-powerpc64le, as f4d3da72a76a9ce... I think. As a
result, I think this bug is overcome by events and can be closed.
On Tue, Nov 2, 2021 at 12:37 PM Christian König
wrote:
>
>
>
> Am 30.10.21 um 16:32 schrieb Salvatore Bonaccorso:
> > On Wed, Oct 13, 2021 at 10:08:21PM +0200, Salvatore Bonaccorso wrote:
> >> Hi,
> >>
> >> On Mon, Oct 11, 2021 at 10:30:21AM +0200, Christian König wrote:
> >>> Am 10.10.21 um 16:14 schrieb Xi Ruoyao:
> On Sun, 2021-10-10 at 14:46 +0100, Nathaniel Filardo wrote:
> > It occurs to me, quite belatedly, that it may be worth asking the
> > author, reviewers, and signers of the change in question their
> > thoughts on this bug report:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D990279data=04%7C01%7Cchristian.koenig%40amd.com%7C3eab702e82bc4ab81fbd08d99bb21419%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637712012456263348%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=KFxF9He7545uxYylgQ%2F4HdljVuGoGUbvHh9xohbxu4o%3Dreserved=0
> >
> > In particular, on ppc64 systems, Linux typically is configured to use
> > a 64KiB page (i.e., shift 16) rather than 4KiB (shift 12) page. It
> > looks, however, that AMDGPU_GPU_PAGE_SIZE is always 4096, and so
> > something (perhaps in userspace, even, eek?) is requesting
> > 4KiB-but-not-64KiB alignment of this buffer.
> Christian told me the buffer should be aligned to *CPU* page boundary,
> or the page table in AMDGPU driver will be corrupted:
> >>> Yeah, that's indeed correct. And that intentionally breaks because
> >>> otherwise
> >>> we can corrupt the page tables and potentially cause much worse trouble.
> >>>
> >>> Question is more why userspace isn't told the correct value in your
> >>> branch.
> >>>
> > the value of num_entries must always be a multiple of
> > AMDGPU_GPU_PAGES_IN_CPU_PAGE or otherwise we corrupt the page tables.
> > You need to identify the root cause of this, most likely start or last
> > are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
> IMO f4d3da72a76a9ce5f57bba64788931686a9dc333 "drm/amdgpu: Set a suitable
> dev_info.gart_page_size" should be backported along with this, which
> makes the kernel to provide the CPU page size to libdrm and mesa and
> correct userspace behavior. I'm not sure why only one is backported.
> >>>
> >>> Yes, exactly that sounds like the correct fix to me as well.
> >> So, the 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo
> >> map") was backported to several stable series 4.14.229, 4.19.185,
> >> 5.4.110, 5.10.28 and 5.11.12 but not the
> >> f4d3da72a76a9ce5f57bba64788931686a9dc333 "drm/amdgpu: Set a suitable
> >> dev_info.gart_page_size".
> >>
> >> What is confusely is that all of those backports reference as upstream
> >> commit e3512fb67093fabdf27af303066627b921ee9bd8 and not
> >> 9a89a721b41b23c6da8f8a6dd0e382966a850dcf which might be in part source
> >> of the confusion?
> >>
> >> Can any of you request to backport
> >> f4d3da72a76a9ce5f57bba64788931686a9dc333 as well for those stable
> >> series where relevant?
> > Here is the proposed change. Should this be submitted to stable for
> > 5.10.y?
>
> You can drop the max_t(), just using PAGE_SIZE should work since there
> can't be any smaller page size than 4k or the driver won't work at all.
>
> Regards,
> Christian.
>
> >
> > Regards,
> > Salvatore
> >
> > From 02c987eb2ab0cdfd536d08bf812f4e37d3cc150a Mon Sep 17 00:00:00 2001
> > From: Huacai Chen
> > Date: Tue, 30 Mar 2021 23:33:33 +0800
> > Subject: [PATCH] drm/amdgpu: Set a suitable dev_info.gart_page_size
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > commit f4d3da72a76a9ce5f57bba64788931686a9dc333 upstream.
> >
> > In Mesa, dev_info.gart_page_size is used for alignment and it was
> > set to AMDGPU_GPU_PAGE_SIZE(4KB). However, the page table of AMDGPU
> > driver requires an alignment on CPU pages. So, for non-4KB page system,
> > gart_page_size should be max_t(u32, PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE).
> >
> > Signed-off-by: Rui Wang
> > Signed-off-by: Huacai Chen
> > Link:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Floongson-community%2Flinux-stable%2Fcommit%2Fcaa9c0a1data=04%7C01%7Cchristian.koenig%40amd.com%7C3eab702e82bc4ab81fbd08d99bb21419%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637712012456273340%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=C8Dz22MXtb6u012FMN%2BRm0i9vDNkn5LJrkqX2qACzqY%3Dreserved=0
> > [Xi: rebased for drm-next, use max_t for checkpatch,
> > and reworded commit message.]
> > Signed-off-by: Xi Ruoyao
> > BugLink:
> >
Bug#1004348: hurd: FTBFS on hurd-i386 locally
Svante Signell, le jeu. 27 janv. 2022 23:17:38 +0100, a ecrit: > On Thu, 2022-01-27 at 20:23 +0100, Samuel Thibault wrote: > > Svante Signell, le jeu. 27 janv. 2022 12:08:47 +0100, a ecrit: > > > On Wed, 2022-01-26 at 17:54 +0100, Samuel Thibault wrote: > > > > So here the problem is that > > > > > > > > test ! -d /home > > > > > > > > says that /home is not a directory. Is there anything special about your > > > > /home path? Perhaps show the output of > > > > > > > > stat /home > > > > > > File: /home > > > Size: 4096Blocks: 8 IO Block: 8192 directory > > > Device: 1a0h/416d Inode: 2 Links: 4 > > > Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) > > > Access: 2022-01-27 07:58:34.0 +0100 > > > Modify: 2017-01-20 13:14:35.0 +0100 > > > Change: 2017-01-20 13:14:35.0 +0100 > > > Birth: - > > > > > > > > > On all boxes the little script > > > #! /bin/sh > > > if test ! -d /home; then > > > echo "/home is not a directory" > > > else > > > echo "/home is a directory" > > > fi > > > returns : /home is a directory > > > > One additional thing is that make install is run under fakeroot, so > > you'll have to also involve fakeroot in your tests. > > The packages was built with dpkg-buildpackage -b 2>&1 | tee ../build.log where > fakeroot is automatically called. > > But here is one result: > fakeroot stat /home > File: /home > Size: 4096Blocks: 8 IO Block: 8192 directory > Device: 1a1h/417d Inode: 2 Links: 4 > Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) > Access: 2022-01-26 23:12:36.0 +0100 > Modify: 2019-07-05 23:29:24.0 +0200 > Change: 2019-07-05 23:29:24.0 +0200 > Birth: - > > fakeroot ./test_for_directory.sh > /home is a directory I'm out of ideas for now. Perhaps you could add the stat call inside the mkinstalldirs script, to make sure that yes the stat() call does report non-directory here. And perhaps also call ps there, to perhaps see the actual situation it's getting run under. Perhaps fakeroot-tcp vs fakeroot-hurd? Samuel
Bug#1004374: [Pkg-privacy-maintainers] Bug#1004374: obfs4proxy: Traffic is trivially distinguishable (Elligator2 public key representative leak)
Hi, I've been in touch with Debian Security last week, they suggested an update to unstable first. I'm now working on packaging the dependencies for version 0.0.11 and shipping an update. Thanks, Ana On 26/01/2022 07:00, intrigeri wrote: Package: obfs4proxy Version: 0.0.8-1+b6 Severity: important Tags: security Hi, Please see https://lists.torproject.org/pipermail/anti-censorship-team/2022-January/000213.html tl;dr: All existing versions prior to the migration to the new code […] are fatally broken, and trivial to distinguish via some simple math. Given obfs4proxy's explicit traffic obfuscation goal, this looks like an important security issue to me. (For those who might be wondering: whether/when this bug is fixed in Debian does not impact Tails since we've switched to using the obfs4proxy binary from the Tor Browser tarball.) Thanks for maintaining obfs4proxy in Debian, cheers! ___ Pkg-privacy-maintainers mailing list pkg-privacy-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-privacy-maintainers
Bug#1004454: kiwi-systemdeps-bootloaders is not installable on several architectures
Hi Adrian! On 1/27/22 23:40, Adrian Bunk wrote: > The following packages have unmet dependencies: > kiwi-systemdeps-bootloaders : Depends: grub2 but it is not installable > > > Package: grub2 > Architecture: any-i386 any-amd64 any-powerpc any-ppc64 any-ppc64el any-sparc > any-sparc64 I have already prepared a fix for that. I was just waiting for the mips* builds to finish to see whether any other issues occur [1]. Adrian > [1] https://buildd.debian.org/status/package.php?p=kiwi=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1004454: kiwi-systemdeps-bootloaders is not installable on several architectures
Package: kiwi-systemdeps-bootloaders Version: 9.24.12-1 Severity: serious The following packages have unmet dependencies: kiwi-systemdeps-bootloaders : Depends: grub2 but it is not installable Package: grub2 Architecture: any-i386 any-amd64 any-powerpc any-ppc64 any-ppc64el any-sparc any-sparc64
Bug#1002706: Fwd: nftables stateless NAT in raw table mangles fragmented UDP packets
Salvatore Bonaccorso wrote: > Hi, > > On Thu, Jan 27, 2022 at 06:26:10PM +0100, Steffen Weinreich wrote: > > Hi all, > > > > The patch made its way to mainline / latest > > > > Any chance to get it backported to 4.19? > > It would be need to have a backport sent sta...@vger.kernel.org . Once > it lands in the older stable series, we can include it as well > downstream in Debian. What does Pablo say on the backport for the > older series? I see it has been applied to 5.15.17 and 5.16.3, but is > not yet queued for older series. Thats because the patch won't compile as-is on those older kernels, it needs a minor change. I can try to do it tomorrow and send it to stable.
Bug#984928: Acknowledgement (slurmctld: fails to start on reboot)
Hi David, sorry for getting back to you so late. Thanks to your valuable contribution I managed to find a working solution. On Fri, Aug 06, 2021 at 11:01:48AM -0300, David Bremner wrote: > I think (one) underlying problem is that the systemd unit file for > slurmctld is incorrect. The details are in [1], but it seems like > network.target is not correct (I think it very rarely is a useful > target). I added the following > > # /etc/systemd/system/slurmctld.service.d/override.conf > [Unit] > After=network-online.target munge.service > Wants=network-online.target Yes this change is now part of the service file. > I've switched to systemd-networkd on the hosts in question, so I can't > easily test how this works with ifupdown, but I notice ifupdown provides > > /lib/systemd/system/ifupdown-wait-online.service > > which (guessing based on the name) should provide similar functionality > to those documented in [1] for NetworkManager and systemd-networkd. > > [1]: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Unfortunately using ifupdown-wait-online didn't help if I use ifupdown and allow-hotplug interfaces, but I did not tested it thoroughly since I want a solution that works out of the box. Therefore I decided to patch the slurm code that is failing in order to retry getaddrinfo before giving up starting daemons. Best regards, -- Gennaro Oliva
Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition
On Thu, Jan 27, 2022 at 02:52:18PM -0700, Sean Whitton wrote: > Hello Joe, > > + > > +These types of files, or any others that Debian does not want to > > +include in our archive, must be stripped from the upstream tarball > > +prior to uploading. The Files-Excluded field > > serves This feature is orthogonal to the machine readable copyright format. It should be possible to use it with the plain old copyright format too, otherwise we are kind of renegating on our promise that the machine readable copyright format be optionnal. Cheers, -- Bill. Imagine a large red swirl here.
Bug#997666: flufl.bounce: please update to 4.0
Hi David, Le samedi 23 octobre 2021 à 20:27:10-0300, David Bremner a écrit : > Source: flufl.bounce > Version: 3.0.1-1 > Severity: wishlist > Tags: upstream > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > flufl.bounce is an important part of the operation of > mailman3. Mailmain3 upstream informs me that the bounces currently > bugging me are detected properly with version 4.0 of the library. It > would be nice to be able to fix this mailman3 problem within Debian. Sorry for having taken that long. I've not put a close statement in my upload because I wanted to make sure that you are aware that uploading 4.0 in stable is probably not an option. Would you like me to backport this package? Cheers. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1004348: hurd: FTBFS on hurd-i386 locally
On Thu, 2022-01-27 at 20:23 +0100, Samuel Thibault wrote: > Svante Signell, le jeu. 27 janv. 2022 12:08:47 +0100, a ecrit: > > On Wed, 2022-01-26 at 17:54 +0100, Samuel Thibault wrote: > > > So here the problem is that > > > > > > test ! -d /home > > > > > > says that /home is not a directory. Is there anything special about your > > > /home path? Perhaps show the output of > > > > > > stat /home > > > > File: /home > > Size: 4096Blocks: 8 IO Block: 8192 directory > > Device: 1a0h/416d Inode: 2 Links: 4 > > Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) > > Access: 2022-01-27 07:58:34.0 +0100 > > Modify: 2017-01-20 13:14:35.0 +0100 > > Change: 2017-01-20 13:14:35.0 +0100 > > Birth: - > > > > > > On all boxes the little script > > #! /bin/sh > > if test ! -d /home; then > > echo "/home is not a directory" > > else > > echo "/home is a directory" > > fi > > returns : /home is a directory > > One additional thing is that make install is run under fakeroot, so > you'll have to also involve fakeroot in your tests. The packages was built with dpkg-buildpackage -b 2>&1 | tee ../build.log where fakeroot is automatically called. But here is one result: fakeroot stat /home File: /home Size: 4096Blocks: 8 IO Block: 8192 directory Device: 1a1h/417d Inode: 2 Links: 4 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2022-01-26 23:12:36.0 +0100 Modify: 2019-07-05 23:29:24.0 +0200 Change: 2019-07-05 23:29:24.0 +0200 Birth: - fakeroot ./test_for_directory.sh /home is a directory
Bug#1004453: libcmark-dev generates broken dependencies.
Package: libcmark-dev Version: 0.9.0-1 Severity: serious Rebuilding nheko in current sid results in the following dependencies. Depends: libc6 (>= 2.33), libcmark0 (>= 0.30.2-4), libcmark0 (<< 0.30.2-4+), libcurl4 (>= 7.16.3), libevent-core-2.1-7 (>= 2.1.8-stable), libevent-pthreads-2.1-7 (>= 2.1.8-stable), libfmt8 (>= 8.1.1+ds1), libgcc-s1 (>= 3.0), libglib2.0-0 (>= 2.22.0), libgstreamer-plugins-bad1.0-0 (>= 1.18.5), libgstreamer-plugins-base1.0-0 (>= 1.18.0), libgstreamer1.0-0 (>= 1.18.0), liblmdb0 (>= 0.9.7), libolm3 (>= 3.1.3), libqt5core5a (>= 5.15.1), libqt5dbus5 (>= 5.14.1), libqt5gui5 (>= 5.14.1) | libqt5gui5-gles (>= 5.14.1), libqt5keychain1 (>= 0.7.0), libqt5multimedia5 (>= 5.6.0~beta), libqt5network5 (>= 5.10), libqt5qml5 (>= 5.14.1), libqt5quick5 (>= 5.9.0~beta) | libqt5quick5-gles (>= 5.9.0~beta), libqt5quickwidgets5 (>= 5.3.0), libqt5svg5 (>= 5.6.0~beta), libqt5widgets5 (>= 5.15.1), libspdlog1-fmt8, libssl1.1 (>= 1.1.0), libstdc++6 (>= 11), libxcb-ewmh2 (>= 0.4.1), libxcb1, qml-module-qt-labs-platform, qml-module-qt-labs-settings, qml-module-qtgraphicaleffects, qml-module-qtmultimedia, qml-module-qtquick2, qml-module-qtquick-controls2, qml-module-qtquick-layouts, qml-module-qtquick-window2, gstreamer1.0-nice, gstreamer1.0-qt5, gstreamer1.0-vaapi Which are not satisfiable as libcmark0 does not exist in bookworm/sid This appears to be a result of https://salsa.debian.org/debian/cmark/-/commit/8be8ebaab1a6d4966b87dfe1eb18710aa20db045 Which seems wrong in several ways and IMO should be reverted. 1. It adds dependencies on a package that doesn't exist. 2. It doesn't seem necessary in the first place, cmark already incorporates the upstream version number as part of the binary package name. 3. The versioning used is too strict, it would force reverse dependencies to be rebuilt every time there was a Debian revision to cmark.
Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@fifthhorseman.net
X-Debbugs-Cc: pkg-gnupg-ma...@lists.alioth.debian.org
Control: affects -1 src:gnupg2
Please consider an update to GnuPG in debian bullseye, from version
2.2.27-2 to 2.2.27-2+deb11u1.
The fixes, by Christoph Biedel and Raphaël Hertzog, are narrowly
targeted and fix real, significant issues that a subset of users have.
They have been in debian unstable and testing for a while now without
issue:
--
[ Raphaël Hertzog ]
* Avoid network interaction in generator. Closes: #993578
[ Christoph Biedl ]
* Backport "Scd: Fix CCID driver for SCM SPR332/SPR532". Closes: #982546
--
The debdiff from the version in bullseye (2.2.27-2) is attached.
This proposed release is also available on the "debian/bullseye" branch at
the git repo for GnuPG packaging:
https://salsa.debian.org/debian/gnupg2
Please followup on this ticket to confirm whether I should upload this
revision to bullseye's proposed updates.
Regards,
--dkg
diff -Nru gnupg2-2.2.27/debian/changelog gnupg2-2.2.27/debian/changelog
--- gnupg2-2.2.27/debian/changelog 2021-04-22 14:40:36.0 -0400
+++ gnupg2-2.2.27/debian/changelog 2022-01-27 14:46:11.0 -0500
@@ -1,3 +1,16 @@
+gnupg2 (2.2.27-2+deb11+1) bullseye; urgency=medium
+
+ [ Raphaël Hertzog ]
+ * Avoid network interaction in generator. Closes: #993578
+
+ [ Christoph Biedl ]
+ * Backport "Scd: Fix CCID driver for SCM SPR332/SPR532". Closes: #982546
+
+ [ Daniel Kahn Gillmor ]
+ * update git to point to debian/bullseye branch
+
+ -- Daniel Kahn Gillmor Thu, 27 Jan 2022 14:46:11 -0500
+
gnupg2 (2.2.27-2) unstable; urgency=medium
* Add a NEWS entry about the end of support for ~/.gnupg/options.
diff -Nru gnupg2-2.2.27/debian/control gnupg2-2.2.27/debian/control
--- gnupg2-2.2.27/debian/control 2021-04-22 14:40:36.0 -0400
+++ gnupg2-2.2.27/debian/control 2022-01-27 14:45:43.0 -0500
@@ -43,7 +43,7 @@
libnpth-mingw-w64-dev (>= 1.2),
libz-mingw-w64-dev,
mingw-w64,
-Vcs-Git: https://salsa.debian.org/debian/gnupg2.git -b debian/main
+Vcs-Git: https://salsa.debian.org/debian/gnupg2.git -b debian/bullseye
Vcs-Browser: https://salsa.debian.org/debian/gnupg2
Homepage: https://www.gnupg.org/
Rules-Requires-Root: no
diff -Nru gnupg2-2.2.27/debian/gbp.conf gnupg2-2.2.27/debian/gbp.conf
--- gnupg2-2.2.27/debian/gbp.conf 2021-02-08 14:38:26.0 -0500
+++ gnupg2-2.2.27/debian/gbp.conf 2022-01-27 14:45:33.0 -0500
@@ -1,5 +1,5 @@
[DEFAULT]
-debian-branch = debian/main
+debian-branch = debian/bullseye
pristine-tar = True
upstream-vcs-tag = gnupg-%(version)s
diff -Nru gnupg2-2.2.27/debian/patches/cherry-picked/1617856888.gnupg-2.3.0-4-gab66c4357.scd-fix-ccid-driver-for-scm-spr332-spr532.patch gnupg2-2.2.27/debian/patches/cherry-picked/1617856888.gnupg-2.3.0-4-gab66c4357.scd-fix-ccid-driver-for-scm-spr332-spr532.patch
--- gnupg2-2.2.27/debian/patches/cherry-picked/1617856888.gnupg-2.3.0-4-gab66c4357.scd-fix-ccid-driver-for-scm-spr332-spr532.patch 1969-12-31 19:00:00.0 -0500
+++ gnupg2-2.2.27/debian/patches/cherry-picked/1617856888.gnupg-2.3.0-4-gab66c4357.scd-fix-ccid-driver-for-scm-spr332-spr532.patch 2022-01-27 14:44:28.0 -0500
@@ -0,0 +1,48 @@
+Subject: Scd: Fix CCID driver for SCM SPR332/SPR532
+Origin: gnupg-2.3.0-4-gab66c4357
+Upstream-Author: NIIBE Yutaka
+Date: Thu Apr 8 13:41:28 2021 +0900
+Bug-Debian: https://bugs.debian.org/982546
+
+* scd/ccid-driver.c (ccid_vendor_specific_pinpad_setup): New.
+(ccid_vendor_specific_setup): Only send CLEAR_HALT.
+(ccid_transceive_secure): Each time, use send_escape_cmd.
+
+--
+
+GnuPG-bug-id: 5297
+Signed-off-by: NIIBE Yutaka
+
+--- a/scd/ccid-driver.c
b/scd/ccid-driver.c
+@@ -1304,10 +1304,20 @@
+ {
+ if (handle->id_vendor == VENDOR_SCM && handle->id_product == SCM_SPR532)
+ {
++ libusb_clear_halt (handle->idev, handle->ep_intr);
++}
++ return 0;
++}
++
++
++static int
++ccid_vendor_specific_pinpad_setup (ccid_driver_t handle)
++{
++ if (handle->id_vendor == VENDOR_SCM && handle->id_product == SCM_SPR532)
++{
+ DEBUGOUT ("sending escape sequence to switch to a case 1 APDU\n");
+ send_escape_cmd (handle, (const unsigned char*)"\x80\x02\x00", 3,
+NULL, 0, NULL);
+- libusb_clear_halt (handle->idev, handle->ep_intr);
+ }
+ return 0;
+ }
+@@ -3583,6 +3593,8 @@
+ if (pininfo->fixedlen < 0 || pininfo->fixedlen >= 16)
+ return CCID_DRIVER_ERR_NOT_SUPPORTED;
+
++ ccid_vendor_specific_pinpad_setup (handle);
++
+ msg = send_buffer;
+ msg[0] = cherry_mode? 0x89 : PC_to_RDR_Secure;
+ msg[5] = 0; /* slot */
diff -Nru gnupg2-2.2.27/debian/patches/series gnupg2-2.2.27/debian/patches/series
--- gnupg2-2.2.27/debian/patches/series 2021-02-08 17:56:55.0 -0500
+++ gnupg2-2.2.27/debian/patches/series 2022-01-27
Bug#1004262: [debian-mysql] Bug#1004262: Acknowledgement (mariadb-server: Instead of being upgraded, mariadb-server gets removed after apt update)
On 27-01-2022 19:05, Otto Kekäläinen wrote: Note that apt-get and apt use different resolvers. Did you specifically run 'apt' or 'apt-get'? apt, apt-get and aptitude are showing all the same behavior in this one.
Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition
Hello Joe, Thanks for the patch. Here's a review: On Sat 13 Nov 2021 at 11:21PM -05, Joe Nahmias wrote: > + > + Pre-compiled executable binary or other non human-editable > files; > + The reason we remove these is also DFSG. > + > + > + > + Files intended for use with other platforms. > + We don't remove files for the sole reason that they're intended for use on other platforms. It's typically only done if the files are huge. So please remove this one from the list. How about just saying: we always remove non-DFSG files if the package is intended for main or contrib, and sometimes there are other files that are removed for technical reasons or because they are both unneeded and very large, and both these sorts of removal are documented using this field? > + > +These types of files, or any others that Debian does not want to > +include in our archive, must be stripped from the upstream tarball > +prior to uploading. The Files-Excluded field > serves How about "are stripped" not "must be stripped", as the normative stuff is explained more precisely over in the Policy manual itself? > +to document the removal of these files from the original upstream > +source. This allows others to understand or audit how the source > +distribution in Debian is derived from the upstream source. > + > + > +Additionally, once documented in this manner, various tools such as > +uscan or mk-origtargz can use > +this information as instructions on how to automatically repack an > +upstream source distribution into one suitable for use within Debian. Nice. -- Sean Whitton
Bug#1004451: RFS: pinpoint/1:0.1.8-6 [ITA] -- hacker-friendly presentation program
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pinpoint": * Package name: pinpoint Version : 1:0.1.8-6 Upstream Author : [fill in name and email of upstream] * URL : https://wiki.gnome.org/action/show/Apps/Pinpoint * License : LGPL-2.1+ * Vcs : https://salsa.debian.org/debian/pinpoint Section : x11 It builds those binary packages: pinpoint - hacker-friendly presentation program To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pinpoint/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pinpoint/pinpoint_0.1.8-6.dsc Changes since the last upload: pinpoint (1:0.1.8-6) unstable; urgency=medium . * New maintainer. (Closes:#1000155) * debian/control: - Bumped Standards-Version to 4.6.0. - Updated debhelp-compat for version 13. * debian/copyright: - Updated names. - Use secure copyright format uri. * debian/compat: Removed. * debian/control: Declare Rules-Requires-Root: no * debian/metadata: Add upstream metadata. * debian/rules: Use -Wl,--as-needed linker flag. This drops a few * debian/watch: Update standard to version 4. Regards, -- Joao Paulo
Bug#1004450: emscripten: slow tests are not really skipped
Source: emscripten Version: 3.1.1~dfsg+~1.39.6-5 tags: patch Hello, now test/runner is accepting a --skip-slow and not an env variable anymore. -TESTS_RUNNER = $(_ENV) EMTEST_SKIP_SLOW=1 EMTEST_LACKS_CLOSURE_COMPILER=1 EMTEST_SKIP_V8=1 tests/runner.py +TESTS_RUNNER = $(_ENV) EMTEST_LACKS_CLOSURE_COMPILER=1 EMTEST_SKIP_V8=1 tests/runner.py --skip-slow The above should fix the issue. G.
Bug#1004406: ffmpeg: symbol lookup error undefined symbol drmModeGetFB2
On 2022-01-26 19:34:51 -0500, Le Déchaîné wrote: > $ echo $LD_LIBRARY_PATH > (not set) > > $ locate libdrm.so > /opt/amdgpu/lib/i386-linux-gnu/libdrm.so.2 > /opt/amdgpu/lib/i386-linux-gnu/libdrm.so.2.4.0 > /opt/amdgpu/lib/x86_64-linux-gnu/libdrm.so.2 > /opt/amdgpu/lib/x86_64-linux-gnu/libdrm.so.2.4.0 > /usr/lib/i386-linux-gnu/libdrm.so.2 > /usr/lib/i386-linux-gnu/libdrm.so.2.4.0 > /usr/lib/x86_64-linux-gnu/libdrm.so > /usr/lib/x86_64-linux-gnu/libdrm.so.2 > /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0 And if you run lddr -r /usr/lib/x86_64-linux-gnu/libavdevice.so.58, which of those is useD? Cheers > (except /var/lib/flatpaks (augh!) and some steamapps/SteamLinuxRuntime > files) > > Le mer. 26 janv. 2022 à 18:28, Sebastian Ramacher a > écrit : > > > Control: tags -1 moreinfo > > > > On 2022-01-26 18:08:00 -0500, Jimmy K. wrote: > > > Package: ffmpeg > > > Version: 7:4.4.1-3 > > > Severity: important > > > X-Debbugs-Cc: ledecha...@gmail.com > > > > > > Dear Maintainer, > > > this version of ffmpeg has been useless on my system, for many months. > > > > > > $ ffmpeg > > > ffmpeg: symbol lookup error: > > /usr/lib/x86_64-linux-gnu/libavdevice.so.58: undefined symbol: drmModeGetFB2 > > > > > > -Downgrading with sudo apt-get install ffmpeg=7:4.3.3-0+deb11u1 fixes > > it, but > > > it's too late for that, apparently. > > > -BUT getting the source from github and "configure, make, sudo make > > install", > > > worked. I don't know what's different. > > > > Since libavdevice58 depends on a recent enough version of libdrm2, I > > suppose that you have an old version of libdrm.so.2 somewhere in > > /usr/local/lib or your LD_LIBRARY_PATH. Can you confirm that? > > > > Cheers > > > > > > > > -- System Information: > > > Debian Release: bookworm/sid > > > APT prefers stable-updates > > > APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') > > > Architecture: amd64 (x86_64) > > > Foreign Architectures: i386 > > > > > > Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) > > > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > > > Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), > > LANGUAGE=fr_CA:fr > > > Shell: /bin/sh linked to /bin/dash > > > Init: systemd (via /run/systemd/system) > > > LSM: AppArmor: enabled > > > > > > Versions of packages ffmpeg depends on: > > > ii libavcodec587:4.4.1-3 > > > ii libavdevice58 7:4.4.1-3 > > > ii libavfilter77:4.4.1-3 > > > ii libavformat58 7:4.4.1-3 > > > ii libavutil56 7:4.4.1-3 > > > ii libc6 2.33-3 > > > ii libpostproc55 7:4.4.1-3 > > > ii libsdl2-2.0-0 2.0.20+dfsg-2 > > > ii libswresample3 7:4.4.1-3 > > > ii libswscale5 7:4.4.1-3 > > > > > > ffmpeg recommends no packages. > > > > > > Versions of packages ffmpeg suggests: > > > pn ffmpeg-doc > > > > > > -- no debconf information > > > > > > > -- > > Sebastian Ramacher > > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#1002645: RFS: pass-audit/1.1-1 [ITP] -- Pass extension for auditing your password repository (Python library)
Hi Antoine, First, thanks for reviewing this package. Second, thanks for the code audit, I've clearly not enough security knowledge to be able to spot potential security issues like this, so thanks for that. (and btw the [0] reference seems to be missing) Hum, I forgot to put it and now to be honest, I don't remember what link I wanted to put. You can check the packages I maintain in my QA page: https://qa.debian.org/developer.php?email=thomas.per...@phyx.fr These are mainly the paperwork[0] software and its dependencies with the exception of gfsecret[1] a package that could take advantage of your sharp eyes. Le 13/01/2022 à 19:47, Antoine Beaupré a écrit : On 2022-01-13 13:37:47, Antoine Beaupré wrote: Any reason why you split the package in two binary packages? I don't see why the python3-* package would really be useful outside of the extension... I wasn't sure about that, I can undo the split if you think it's unnecessary. It was also because from what I understood from the section 5.3 of the Debian Python Policy[2], it would become a private module and would require to be installed in /usr/share/pass-audit. So out of laziness, I split the package. But I'm not sure now, while I read the policy again, that I'm understanding it the same. Another thing is that I can't build the package here, it seems to fail on some weird gnupg error in the test suite. Log attached. other than that, things look somewhat sane. i'm a little worried about the security of the code, details in private (and sent to upstream on twitter). Hum, yes indeed. I only tried to build it using pbuilder which built fine but I can reproduce it locally with sbuild (and was present also on salsa[3]). Though, I'm not sure where the problem comes from. I'll need to investigate. I'm not able to spend as much time as I would like for Debian currently so it will surely take me some time to fix that. But I guess, I should wait for the next upstream release before uploading to Debian. Thomas [0]: https://openpaper.work [1]: https://incenp.org/dvlpt/gfsecret.html [2]: https://www.debian.org/doc/packaging-manuals/python-policy/index.html#programs-shipping-private-modules [3]: https://salsa.debian.org/debian/pass-audit/-/jobs/2322260
Bug#1002706: Fwd: nftables stateless NAT in raw table mangles fragmented UDP packets
Hi,
On Thu, Jan 27, 2022 at 06:26:10PM +0100, Steffen Weinreich wrote:
> Hi all,
>
> The patch made its way to mainline / latest
>
> Any chance to get it backported to 4.19?
It would be need to have a backport sent sta...@vger.kernel.org . Once
it lands in the older stable series, we can include it as well
downstream in Debian. What does Pablo say on the backport for the
older series? I see it has been applied to 5.15.17 and 5.16.3, but is
not yet queued for older series.
Let's CC Pablo and Florian.
Pablo, Florian, Steffen is asking for a fix as well back to 4.19.y to
address the issue fixed in mainline with 4e1860a38637 ("netfilter:
nft_payload: do not update layer 4 checksum when mangling fragments").
Do you know will it be picked up as well for the older stable series
affected?
Regards,
Salvatore
Bug#996876: systemd bogus(?) remounts since upgrade to 249.5-1
reassign 996876 src:linux retitle 996876 filesystem being remounted supports timestamps until 2038 thanks On Wed, 20 Oct 2021 08:51:44 +0200 10dmar10 <10dma...@gmail.com> wrote: Package: systemd Version: 249.5-1 Severity: normal Hi, I noticed since upgrade to systemd 249.5-1 on 2021-10-15 following remount warnings in my log files, usually when some service is started. While there are no problems caused by this behavior so far (besides spamming into log a lot), I assume it is unintended and may indicate some underlying problem. log snippets: Okt 17 23:54:14 tetranode systemd[1]: Starting Network Name Resolution... Okt 17 23:54:14 tetranode systemd[1]: Starting Network Time Synchronization... Okt 17 23:54:14 tetranode systemd[1]: Starting Record System Boot/Shutdown in UTMP... Okt 17 23:54:14 tetranode systemd[1]: Finished Record System Boot/Shutdown in UTMP. Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fff) Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fff) Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fff) Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fff) Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/lib/systemd/timesync supports timestamps until 2038 (0x7fff) Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fff) Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fff) Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fff) Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/lib/systemd/timesync supports timestamps until 2038 (0x7fff) Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fff) Okt 17 23:54:14 tetranode systemd[1]: Started Network Time Synchronization. Okt 17 23:54:14 tetranode systemd[1]: Reached target System Initialization. Okt 17 23:57:49 tetranode dbus-daemon[575]: [system] Activating via systemd: service name='org.freedesktop.UPower' unit='upower.service' requested by ':1.27' (uid=1000 pid=2052 comm="/usr/lib/chromium/chromium --show-component-extens") Okt 17 23:57:50 tetranode systemd[1]: Starting Daemon for power management... Okt 17 23:57:50 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/lib/upower supports timestamps until 2038 (0x7fff) Okt 17 23:57:50 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fff) Okt 17 23:57:50 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fff) Okt 17 23:57:50 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fff) Okt 17 23:57:50 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/lib/upower supports timestamps until 2038 (0x7fff) Okt 17 23:57:50 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fff) It was concluded that this is a kernel bug. See also https://lore.kernel.org/lkml/CAHk-=wim6vgnxqmjfk_tdg6fbhykl4efkmntjvr9qnrqjdb...@mail.gmail.com/ and should be addressed in the kernel by only issuing this warning once per mount, but not on a remount. Thus reassigning. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1004449: rfcomm busyloops taking 35% CPU due to needlessly low busy loop timeout
Package: bluez Version: all tools/rfcomm.c has a ppoll() with 200ns timeout. It just appears to be there to detect when the program should end, and takes about 35% CPU on a raspberry pi 4. If I change it to 10'000'000 (10ms) it seems to not have any functional impact aside from making the CPU problems go away. E.g. running: sudo tools/rfcomm watch hci0 1 getty rfcomm0 115200 vt100 doesn't take any CPU initially, but if one connects to the port it busyloops. It works, but it busyloops. The fix is simple. Change line 260 of tools/rfcomm.c to read: ts.tv_nsec = 1000;
Bug#987355: closed by Debian FTP Masters (reply to Gianfranco Costamagna ) (Bug#987355: fixed in phpldapadmin 1.2.6.3-0.2)
Ciao Gianfranco On Thu, Jan 27, 2022 at 05:21:11PM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the phpldapadmin package: > > #987355: CVE-2020-35132 > > It has been closed by Debian FTP Masters > (reply to Gianfranco Costamagna ). > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > (reply to Gianfranco Costamagna > ) by > replying to this email. > > > -- > 987355: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987355 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > From: Debian FTP Masters > Reply-To: Gianfranco Costamagna > Date: Thu, 27 Jan 2022 17:19:45 + > To: 987355-cl...@bugs.debian.org > Subject: Bug#987355: fixed in phpldapadmin 1.2.6.3-0.2 > Message-Id: > > Source: phpldapadmin > Source-Version: 1.2.6.3-0.2 > Done: Gianfranco Costamagna > > We believe that the bug you reported is fixed in the latest version of > phpldapadmin, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 987...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Gianfranco Costamagna (supplier of updated > phpldapadmin package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Thu, 27 Jan 2022 17:56:42 +0100 > Source: phpldapadmin > Architecture: source > Version: 1.2.6.3-0.2 > Distribution: unstable > Urgency: medium > Maintainer: Fabio Tranchitella > Changed-By: Gianfranco Costamagna > Closes: 717205 834279 952635 987355 > Changes: > phpldapadmin (1.2.6.3-0.2) unstable; urgency=medium > . >* Non-maintainer upload >* Previous changelog also closed: >* Make build reproducible (Closes: #834279) >* Update to github new upstream release (Closes: #952635) >* Fix CVE-2020-35132 (Closes: #987355) I reopened the issue, due to https://github.com/leenooks/phpLDAPadmin/issues/137 . Can you check with upstream on the status for the correct fix for CVE-2020-35132? Thanks a lot already for your time! Regards, Salvatore
Bug#1003317: [Debian-science-sagemath] [RFP]: primecount -- count the primes below an integer
Hi Jerome, any news on this? If you prefer I could also take care of it. Best, Tobias On 1/8/22 20:10, Jerome BENOIT wrote: > Hello, > > I think it the best idea. > I cannot do that this week-end. > > I think I can have a look on it the next week-end or the week-end after. > > If it is ok, I can put an ITP. > > Best wishes, > Jerome > > On 08/01/2022 12:14, Tobias Hansen wrote: >> Hi, >> >> we need to package primecount and primecountpy for sagemath 9.5. Jerome, I >> saw that you are already maintaining primesieve by the same upstream. Are >> you interested in packaging these two or should I take care of it? >> >> Best wishes, >> Tobias >> >> On Sat, 08 Jan 2022 06:35:05 + Preetham Gujjula >> wrote: >>> Package: wnpp >>> Severity: wishlist >>> >>> * Package name : primecount >>> Version : 7.2 >>> Upstream Author : Kim Walisch >>> * URL : https://github.com/kimwalisch/primecount >>> * License : BSD-2-Clause >>> Programming Lang: C/C++ >>> Description : count the primes below an integer >>> >>> primecount is a command-line program and C/C++ library that counts the >>> primes >>> below an integer <= 10^31 using highly optimized implementations of the >>> combinatorial prime counting algorithms. >>> >>> It is related to and created by the same developer as primesieve, which is >>> already packaged into Debian. >>> >>> >>> >> >> ___ >> Debian-science-sagemath mailing list >> debian-science-sagem...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath >> > > > ___ > Debian-science-sagemath mailing list > debian-science-sagem...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
Bug#1004448: gnome-session: should manage session with systemd --user, if available
Package: gnome-session Version: 40.1.1-3 Severity: wishlist Recent-ish upstream versions of gnome-session have been able to manage the whole login session as a group of `systemd --user` services: https://wiki.gnome.org/Initiatives/SystemdUser In Debian terms, this requires libpam-systemd and dbus-user-session. In particular, one benefit of this is that it makes gnome-shell able to survive Xwayland crashing or being killed. At the moment, we compile the code for this but do not enable it. It can be enabled by hacking /usr/bin/gnome-session (or the session registration .desktop file) to pass the --systemd option to the executable. Alternatively, we could configure with it enabled by default. To be nice to dbus-x11 and sysvinit users, we should make sure that on systems lacking the prerequisites, this gracefully degrades to the equivalent of `gnome-session --builtin` (the opposite of --systemd). I think it already does, but haven't tried it yet. smcv
Bug#1004447: modemmanager: Sierra Wireless EM7455 stops working after upgrade to 1.18.4-1 (stays in FCC lock)
Package: modemmanager Version: 1.18.4-1 Severity: normal Hi, after upgrading to the latest unstable version of modemmanager to 1.18.4-1, the Sierra Wireless EM7455 Qualcomm Snapdragon X7 LTE-A in my Lenovo Thinkpad T470 stopped working. I have a rough idea, what's going on, but not enough insight into mm to actually fix it properly (see below) What I see as user: After booting or resume from suspend, the modem seems to get available after a few seconds and network-manager tries to start my usual connection. This fails immediately and the only visible thing is a flashing Dock-Icon of network-manager. At the same time, the system journal is flooded with this type of messages in high frequency: 22:04:52 NetworkManager[1133]: [1643231092.2962] modem["cdc-wdm1"]: modem state changed, 'disabled' --> 'enabling' (reason: user-requested) 22:04:52 ModemManager[1180]: [modem0] state changed (enabling -> disabled) 22:04:52 NetworkManager[1133]: [1643231092.2968] modem["cdc-wdm1"]: modem state changed, 'enabling' --> 'disabled' (reason: unknown) 22:04:52 NetworkManager[1133]: [1643231092.2969] device (cdc-wdm1): state change: prepare -> disconnected (reason 'user-requested', sys-iface-state: 'managed') 22:04:52 NetworkManager[1133]: [1643231092.2980] policy: auto-activating connection 'T-Mobile IPv6 only' (...) 22:04:52 NetworkManager[1133]: [1643231092.2985] device (cdc-wdm1): Activation: starting connection '...) 22:04:52 NetworkManager[1133]: [1643231092.2986] device (cdc-wdm1): state change: disconnected -> prepare naged') 22:04:52 ModemManager[1180]: [modem0] simple connect started... 22:04:52 ModemManager[1180]: [modem0] simple connect state (3/8): enable 22:04:52 ModemManager[1180]: [modem0] state changed (disabled -> enabling) 22:04:52 ModemManager[1180]: [modem0] MBIM protocol error: NotOpened 22:04:52 ModemManager[1180]: [modem0] MBIM protocol error: NotOpened 22:04:52 ModemManager[1180]: [modem0] couldn't enable interface: 'Invalid transition' mmcli lists the modem as: - General | dbus path: /org/freedesktop/ModemManager1/Modem/0 - Hardware | manufacturer: Sierra Wireless, Incorporated | model: Sierra Wireless EM7455 Qualcomm Snapdragon X7 LTE-A | firmware revision: SWI9X30C_02.20.03.00 |carrier config: default | h/w revision: EM7455 | supported: gsm-umts, lte | current: gsm-umts, lte - System |device: /sys/devices/pci:00/:00:14.0/usb1/1-6 | drivers: cdc_mbim |plugin: sierra | primary port: cdc-wdm1 | ports: cdc-wdm1 (mbim), wwan0 (net) - Status |unlock retries: sim-pin2 (3) | state: disabled | power state: low |signal quality: 0% (cached) - Modes| supported: allowed: 3g; preferred: none |allowed: 4g; preferred: none |allowed: 3g, 4g; preferred: 4g |allowed: 3g, 4g; preferred: 3g | current: allowed: 3g, 4g; preferred: 4g - Bands| supported: utran-1, utran-3, utran-4, utran-5, utran-8, utran-2, |eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, eutran-8, |eutran-12, eutran-13, eutran-20, eutran-25, eutran-26, eutran-41 | current: utran-1, utran-3, utran-4, utran-5, utran-8, utran-2, |eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, eutran-8, |eutran-12, eutran-13, eutran-20, eutran-25, eutran-26, eutran-41 - IP | supported: ipv4, ipv6, ipv4v6 - 3GPP | imei: x | enabled locks: fixed-dialing - SIM | dbus path: /org/freedesktop/ModemManager1/SIM/0 Things I tried so far: * Downgrading to 1.14.12-0.2 doesn't help, the modem will not be detected at all. * Booting with mm 1.18.4-1 installed, then *downgrading* modemmanager, waiting for roughly 10 seconds and *upgrading* again (without rebooting), will make the modem available until shutdown/suspend. After next resume, the modem is inaccessible again. * After poking arund for some time, I found this: root@spiff:~# qmicli --device-open-proxy --device=/dev/cdc-wdm1 --dms-set-fcc-authentication [/dev/cdc-wdm1] Successfully set FCC authentication Does immediately solve the problem until shutdown/reboot. However, I am unsure, which component is the
Bug#757151: printf(3) manpage: please document L + integer conversion
On Tue, Aug 05, 2014 at 09:03:34PM +0200, Jakub Wilk wrote: > As a GNU extension, you can use the "L" length modifier with integer > conversion. "L" is equivalent to "ll" for these conversions. Please document > this fact in the manual page. The current man page contains | As a nonstandard extension, the GNU implementations treats ll and L as | synonyms, so that one can, for example, write llg (as a synonym for the | standards-compliant Lg) and Ld (as a synonym for the standards compliant | lld). Such usage is nonportable. which IMO provides sufficient documentation for this. As such I think this bug could just be closed. This part has first been added to upstream 4.10 so was first present in Debian in 4.10-1. Cheers, Flo signature.asc Description: PGP signature
Bug#803731: manpages: tcp_ecn details out of date
On Mon, Nov 02, 2015 at 11:24:51AM +0900, c wrote: > man tcp: > > tcp_ecn section refers to deprecates version and talks to a boolean value > defaulting to disabled. > This is not the case as kernel defaults to '2'; ip-sysctl.txt text should > prevale. > > tcp_ecn - INTEGER > Control use of Explicit Congestion Notification (ECN) by TCP. > ECN is used only when both ends of the TCP connection indicate > support for it. This feature is useful in avoiding losses due > to congestion by allowing supporting routers to signal > congestion before having to drop packets. > Possible values are: > 0 Disable ECN. Neither initiate nor accept ECN. > 1 Enable ECN when requested by incoming connections and > also request ECN on outgoing connection attempts. > 2 Enable ECN when requested by incoming connections > but do not request ECN on outgoing connections. > Default: 2 The current manpage instead reads | tcp_ecn (Integer; default: see below; since Linux 2.4) |Enable RFC 3168 Explicit Congestion Notification. | |This file can have one of the following values: | |0 Disable ECN. Neither initiate nor accept ECN. This was |the default up to and including Linux 2.6.30. | |1 Enable ECN when requested by incoming connections and |also request ECN on outgoing connection attempts. | |2 Enable ECN when requested by incoming connections, but do |not request ECN on outgoing connections. This value is |supported, and is the default, since Linux 2.6.31. | |When enabled, connectivity to some destinations could be |affected due to older, misbehaving middle boxes along the path, |causing connections to be dropped. However, to facilitate and |encourage deployment with option 1, and to work around such |buggy equipment, the tcp_ecn_fallback option has been |introduced. I.e. the defaults are stated correctly. As such I think this bug could just be closed. This seems to have been fixed in man-pages-4.03 (first present in Debian with 4.04-0.1) whose Changes lists | tcp.7 | Daniel Borkmann [Michael Kerrisk] | Improve paragraphs on tcp_ecn and add tcp_ecn_fallback bullet | Improve description of tcp_ecn, fix the RFC number and it's | not a boolean anymore since long time, and add a description | for tcp_ecn_fallback. | | See also kernel doc under Documentation/networking/ip-sysctl.txt | on tcp_ecn and tcp_ecn_fallback. Cheers, Flo signature.asc Description: PGP signature
Bug#944388: tzfile(5): missing field charcnt in description of fields after the header
On Sat, Nov 09, 2019 at 02:00:58AM +0200, Omer Zak wrote: > In 'man 5 tzfile', after the header description, six fields are > described: tzh_timecnt*4, tzh_timecnt*1, tzh_typecnt*6, tzh_leapcnt*8, > tzh_ttisstdcnt*1, tzh_ttisgmtcnt*1. > > According to https://tools.ietf.org/html/rfc8536 (section 3.2. TZif > Data Block), there should be also a tzh_charcnt field after the first > three fields (i.e. total of seven fields). The current manpage seems to match https://tools.ietf.org/html/rfc8536, and for tzh_charcnt it states | tzh_charcnt |The number of bytes of time zone abbreviation strings stored in the file. As such I think this bug could just be closed. Hmm, I found tzh_charcnt to be listed in that manpage all the way back to upstream 3.27, and according to rfc8536 that field is part of the header. So maybe there was something missed when filing this bug? Cheers, Flo signature.asc Description: PGP signature
Bug#1004446: cdist: FTBFS against python 3.10
Package: cdist
Version: 6.9.4-1
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy
Dear Maintainer,
This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1959330
autopkgtest will fail when python3.10 is used. Upstream has fixed relevant
things already, so here's a patch with those commits.
-Dan
diff -Nru cdist-6.9.4/debian/changelog cdist-6.9.4/debian/changelog
--- cdist-6.9.4/debian/changelog2021-02-07 00:45:26.0 -0700
+++ cdist-6.9.4/debian/changelog2022-01-27 11:45:53.0 -0700
@@ -1,3 +1,11 @@
+cdist (6.9.4-1.1) jammy; urgency=medium
+
+ * Cherry-pick 2 commits for python 3.10 compatibility
+* Fix version compare
+* Fix transition of some classes from collections to collections.abc
+
+ -- Dan Bungert Thu, 27 Jan 2022 11:45:53 -0700
+
cdist (6.9.4-1) unstable; urgency=medium
* QA upload.
diff -Nru cdist-6.9.4/debian/patches/collections-abc.patch
cdist-6.9.4/debian/patches/collections-abc.patch
--- cdist-6.9.4/debian/patches/collections-abc.patch1969-12-31
17:00:00.0 -0700
+++ cdist-6.9.4/debian/patches/collections-abc.patch2022-01-27
11:45:53.0 -0700
@@ -0,0 +1,36 @@
+Description: Python 3.10: collections.X -> collections.abc.X
+Origin:
https://code.ungleich.ch/ungleich-public/cdist/commit/3a321469a8ba5aea55220bd70bd4900de732e917
+Author: Timothée Floure
+Forwarded: 'not-needed'
+Last-Update: 2022-01-27
+--- a/cdist/integration.py
b/cdist/integration.py
+@@ -84,7 +84,7 @@
+ """
+ if isinstance(host, str):
+ hosts = [host, ]
+-elif isinstance(host, collections.Iterable):
++elif isinstance(host, collections.abc.Iterable):
+ hosts = host
+ else:
+ raise cdist.Error('Invalid host argument: {}'.format(host))
+--- a/cdist/util/fsproperty.py
b/cdist/util/fsproperty.py
+@@ -33,7 +33,7 @@
+ return 'Absolute path required, got: %s' % self.path
+
+
+-class FileList(collections.MutableSequence):
++class FileList(collections.abc.MutableSequence):
+ """A list that stores it's state in a file.
+
+ """
+@@ -102,7 +102,7 @@
+ self.__write(lines)
+
+
+-class DirectoryDict(collections.MutableMapping):
++class DirectoryDict(collections.abc.MutableMapping):
+ """A dict that stores it's items as files in a directory.
+
+ """
diff -Nru cdist-6.9.4/debian/patches/series cdist-6.9.4/debian/patches/series
--- cdist-6.9.4/debian/patches/series 2021-02-07 00:45:26.0 -0700
+++ cdist-6.9.4/debian/patches/series 2022-01-27 11:45:53.0 -0700
@@ -1 +1,3 @@
explicitly-specify-path-one-remote-side.patch
+collections-abc.patch
+version-compare.patch
diff -Nru cdist-6.9.4/debian/patches/version-compare.patch
cdist-6.9.4/debian/patches/version-compare.patch
--- cdist-6.9.4/debian/patches/version-compare.patch1969-12-31
17:00:00.0 -0700
+++ cdist-6.9.4/debian/patches/version-compare.patch2022-01-27
11:45:53.0 -0700
@@ -0,0 +1,33 @@
+Description: [bin/cdist] Fix Python version check
+Origin:
https://code.ungleich.ch/ungleich-public/cdist/commit/1c047353a95e7ac079ccf89af8fc232451b8f891
+Author: Dennis Camera
+Forwarded: 'not-needed'
+Last-Update: 2021-04-17
+--- a/bin/cdist
b/bin/cdist
+@@ -72,9 +72,11 @@
+
+
+ if __name__ == "__main__":
+-if sys.version < cdist.MIN_SUPPORTED_PYTHON_VERSION:
+-print('Python >= {} is required on the source host.'.format(
+-cdist.MIN_SUPPORTED_PYTHON_VERSIO), file=sys.stderr)
++if sys.version_info[:3] < cdist.MIN_SUPPORTED_PYTHON_VERSION:
++print(
++'Python >= {} is required on the source host.'.format(
++".".join(map(str, cdist.MIN_SUPPORTED_PYTHON_VERSION))),
++file=sys.stderr)
+ sys.exit(1)
+
+ exit_code = 0
+--- a/cdist/__init__.py
b/cdist/__init__.py
+@@ -64,7 +64,7 @@
+ REMOTE_CMDS_CLEANUP_PATTERN = "ssh -o User=root -O exit -S {}"
+
+
+-MIN_SUPPORTED_PYTHON_VERSION = '3.5'
++MIN_SUPPORTED_PYTHON_VERSION = (3, 5)
+
+
+ class Error(Exception):
Bug#686623: manpages-dev: The sprintf(3) man page is misleading
On Tue, Sep 04, 2012 at 02:27:17AM +0200, Vincent Lefevre wrote: > The sprintf(3) man page says about sprintf(): > > sprintf(), snprintf(), vsprintf() and vsnprintf() write to the > character string str. > > but it does not say that a terminating null byte is written (this > is said only for snprintf() and vsnprintf() later). > [...] > The C99 standard is much more clear than the man page. It says: > > The sprintf function is equivalent to fprintf, except that the > output is written into an array (specified by the argument s) > rather than to a stream. A null character is written at the end > of the characters written; it is not counted as part of the > returned value. If copying takes place between objects that > overlap, the behavior is undefined. > > The man page could say: > > sprintf(), snprintf(), vsprintf() and vsnprintf() write a > sequence of characters to the array str; a null character > is written [or added] at the end of this sequence. FWIW, the man page already states in RETURN VALUE | Upon successful return, these functions return the number of characters | printed (excluding the null byte used to end output to strings). providing some further hint at the terminating null byte. Still, in light of your counterexample (which I had omitted here) I feel this point might indeed need more stressing ... Cheers, Flo signature.asc Description: PGP signature
Bug#1004445: RM: clazy [i386] -- RoQA; no longer builds on i386
Package: ftp.debian.org Severity: normal See #1000934 for background.
Bug#1004444: RM: sight [i386] -- RoQA; no longer builds on i386
Package: ftp.debian.org Severity: normal The new build dependency libinsighttoolkit5-dev is not available on i386.
Bug#1004348: hurd: FTBFS on hurd-i386 locally
Svante Signell, le jeu. 27 janv. 2022 12:08:47 +0100, a ecrit: > On Wed, 2022-01-26 at 17:54 +0100, Samuel Thibault wrote: > > So here the problem is that > > > > test ! -d /home > > > > says that /home is not a directory. Is there anything special about your > > /home path? Perhaps show the output of > > > > stat /home > > File: /home > Size: 4096Blocks: 8 IO Block: 8192 directory > Device: 1a0h/416d Inode: 2 Links: 4 > Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) > Access: 2022-01-27 07:58:34.0 +0100 > Modify: 2017-01-20 13:14:35.0 +0100 > Change: 2017-01-20 13:14:35.0 +0100 > Birth: - > > With similar results for the other two boxes. > > cat /etc/fstab: > /dev/hd0s6 /home ext2defaults0 2 > /dev/hd0s2 /home ext2defaults0 2 > /dev/hd0s2 /home ext2defaults0 2 > > /bin/sh is linked to dash. > dash 0.5.11+git20210903+057cd650a4ed-3 > > On all boxes the little script > #! /bin/sh > if test ! -d /home; then > echo "/home is not a directory" > else > echo "/home is a directory" > fi > returns : /home is a directory One additional thing is that make install is run under fakeroot, so you'll have to also involve fakeroot in your tests. Samuel
Bug#1003972: libphonenumber: New upstream release - please update
On 2022-01-26 22:48, tony mancill wrote: I expect to be able to upload in the next few days. Thanks, Tony. That would be great. I'm hoping Ubuntu will also be able to pick it up before the 22.04 feature freeze on Feb 23.
Bug#1004443: smartctl -i /dev/nvme0n1: "Read NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Inappropriate ioctl for device"
Package: smartmontools Version: 7.2-1 The smartctl man page reads: Use the forms "/dev/nvme[0-9]" (broadcast namespace) or "/dev/nvme[0-9]n[1-9]" (specific namespace 1-9) for NVMe devices. The broadcast namespace indeed works: # smartctl -i /dev/nvme0 smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-3-amd64] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Number: CT500P2SSD8 ... But when I try to use the specific namespace, I get: # smartctl -i /dev/nvme0n1 smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-3-amd64] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org Read NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Inappropriate ioctl for device Please make the other form work too. (I'm actually interested in using /dev/disk/by-id/nvme-* symlinks, and they point to /dev/nvme[0-9]n[1-9].) -- System Information: Architecture: i386 Versions of packages smartmontools depends on: ii debianutils 5.7-0.1 ii lsb-base 11.1.0 ii libc62.33-5 ii libcap-ng0 0.7.9-2.2+b1 ii libgcc-s111.2.0-14 ii libselinux1 3.3-1+b1 ii libstdc++6 11.2.0-14 ii libsystemd0 250.3-2 -- Jakub Wilk
Bug#1004442: spirv-cross: please build all libraries with -fPIC
Source: spirv-cross Version: 2021.01.15-4 Severity: wishlist Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, I need to link against various spirv-cross-*.a libraries from a shared object, which requires said libraries to be built with position independent code. I would appreciate it if you could add the following patch to your package: diff --git a/debian/rules b/debian/rules index 3ce1dac2..e2a9788f 100755 - --- a/debian/rules +++ b/debian/rules @@ -6,5 +6,6 @@ override_dh_auto_configure: dh_auto_configure -- \ -DSPIRV_CROSS_SHARED=ON \ + -DSPIRV_CROSS_FORCE_PIC=ON \ -DSPIRV_CROSS_CLI=ON \ -DSPIRV_CROSS_ENABLE_TESTS=OFF Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmHy6wQACgkQ+C8H+466 LVlV8gwAhqz6slp9ijk5YcGUr1gmibDFP9qlsuZjcxYqIjod6wcJ88GAnHYwXwjY bUoMo+AULAoVsCWBCqMJZUVvVF3oqcZngm+42yeTsBKB9eq7c8AT8mv2nDd5Otyf Vpfc8uy2cc2A9iHFSFXUQ8oA7ZzZgePVUJafp5UpUiEPB6xTPVrga9rUPL45PVf0 Z0k4BjT3W496g4u45owxuN+rAfWx6nT/WWPsn5f2ZIkvqv8mI/Kvmr19hVs3IuEf 82k/NLxauKWKStb8GVwu6RNTVXkfL8mznnpmd4diN/2z8QA+iSiLpYFj16c2G1R7 Gx5Cl13TNpOkWAw7NKU0r3CPGaYs3A/cASQChgcFCdK6Ua+TF96aGIcyaRk59rr7 c3LlVuCsijQeA7J0LVNU10ooO26bVJmrFsaIk7wcawZJzCDMLHIip8TuCrNMMSX/ b3nagFJMzRp3ZlOxvHETOnv3OFBDZop1ERPmE7qA++wN/kxMxJea2+LxFQAbsvSu j+M4CQBS =ZRRP -END PGP SIGNATURE-
Bug#1002496: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled
Chris Lamb wrote:
> [...]
Just some further scrappy braindumping here; this is, unfortunately, not a
complete solution yet.
Looking into this further, a lot of this revolves around this method in
src/core.c/CompUnit/Repository/Installation.pm6:
method id() {
return $!id if $!id;
my $name = self.path-spec;
$name ~= ',' ~ self.next-repo.id if self.next-repo;
my $dist-dir = $.prefix.add('dist');
$!id = nqp::sha1(nqp::sha1($name) ~ ($dist-dir.e ?? $dist-dir.dir !!
''))
}
... and this one in lib/CompUnit/Repository/Staging.rakumod:
method path-spec(CompUnit::Repository::Staging:D:) {
self.^name ~ '#name(' ~ $!name ~ ')#' ~ $.prefix.absolute;
}
Taken together, these basically hash together two things:
a) All of the repository names/paths used in the precompilation process.
b) The target directory for the precompilation.
This value is then encoded in the filename of the repo-id file and
similar. (Just to check: is this file even needed?)
Just to take these two things in turn:
## A. Repository paths
It is fine that the hash includes things like /usr/lib/perl6/site.
However, pre-compilation looks in $HOME/.raku for modules and encodes
that value into the hash of the precompiled files. The hash therefore
varies on the build user's home directory location/name.
This occurs via RepositoryRegistry.pm6:
nqp::bindkey($custom-lib,'home',
$next-repo := self!register-repository(
$home-spec,
CompUnit::Repository::Installation.new(
:prefix($home),
:$next-repo
)
)
) if $home-spec and nqp::not_i(nqp::existskey($unique,$home-spec));
It probably isn't a good idea that Debian package builds inherits anything from
the build user's home directory anyway, so the following should be okay:
--- a/dh_raku_build
+++ b/dh_raku_build
@@ -39,6 +39,7 @@ foreach my $pkg (getpackages()) {
--from=. --to=debian/tmp/pre-compiled!;
doit({
update_env => {
+HOME => "/nonexistent",
RAKUDO_RERESOLVE_DEPENDENCIES => 0,
}
},@cmd);
## B. Target directory
This directory is typically `debian/tmp/pre-compiled` in Debian (via
`dh_raku_build`). Although this is a relative path name and should
therefore not embed the full path name, the directory is converted to
its absolute version within Staging.rakumod:
self.^name ~ '#name(' ~ $!name ~ ')#' ~ $.prefix.absolute;
Raku will thus embed the fully-qualified pathname such as
/tmp/arbitrary-build-dir/perl6-module/debian/tmp/pre-compiled).
This could be fixed via:
--- a/lib/CompUnit/Repository/Staging.rakumod
+++ b/lib/CompUnit/Repository/Staging.rakumod
@@ -11,7 +11,7 @@ class CompUnit::Repository::Staging is
CompUnit::Repository::Installation {
$!name
}
method path-spec(CompUnit::Repository::Staging:D:) {
-self.^name ~ '#name(' ~ $!name ~ ')#' ~ $.prefix.absolute;
+self.^name ~ '#name(' ~ $!name ~ ')#' ~ ($!name ne 'vendor' ??
$.prefix.absolute !! '');
}
method source-file(Str $name --> IO::Path) {
my $file = self.prefix.add($name);
This cannot be fixed by replacing $.prefix.absolute with
$.prefix.relative, otherwise the build will vary on the number of
directory levels (eg. "../../../target" vs "../../../../target"). And
it doesn't appear to be fixable using $.prefix.path either; this is also
an absolute value, so something is converting it.
(Oh, misc: this proof-of-concept patch only changes the value for
"vendor" types. This is the repository type for local/Debian builds,
leaving the global "inst" types such as /usr/lib/perl6/site, etc.
unchanged.)
Another solution might be to do something quite aggressive like this:
--- a/src/core.c/CompUnit/Repository/Installation.pm6
+++ b/src/core.c/CompUnit/Repository/Installation.pm6
@@ -616,6 +616,11 @@ sub MAIN(:$name, :$auth, :$ver, *@, *%) {
method id() {
return $!id if $!id;
+if %*ENV -> $sde {
+$!id = nqp::sha1($sde);
+return $!id;
+}
my $name = self.path-spec;
$name ~= ',' ~ self.next-repo.id if self.next-repo;
my $dist-dir = $.prefix.add('dist');
Whilst this sidesteps some of the above issues, it strangely doesn't
fix the contents of the files, which still seem to contain the target
(and possibly the source) directory.
Anyway, again, just braindumping here so I don't forget stuff. Thanks
for maintaining Rakudo.
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#1004441: Chromium: decide before the freeze if it can be part of bookworm
Package: release.debian.org Severity: serious Control: affects -1 src:chromium This bug is to make sure we don't forget to make a decision on shipping chromium in bookworm. The decision will depend on how chromium updates are handled between filing this bug and approximately the freeze, both in sid and supported releases. If there's no good track record before the bookworm release, chromium will *not* be shipped with bookworm. Discussion happened here: https://lists.debian.org/debian-release/2022/01/msg00266.html Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1004440: libgtk-3-0: File selection dialog filters incorrectly on NFS mounted directories
Package: libgtk-3-0 Version: 3.24.24-4 Severity: normal Dear Maintainer, When using the GTK file selection dialog - for example, from mouse pad - it's possible to start typing a filename and the dialog progressively filters out files that don't match. That works fine on a locally mounted directoy. When viewing an NFS mounted directory, the filtered results show momentarily (for maybe half a second), and are then hidden and "No Results Found" is displayed. Despite that, if one continues to type more characters, the momentarily-appearing list is clearly being filtered by what is typed, then it's hidden. -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgtk-3-0 depends on: ii adwaita-icon-theme 3.38.0-1 ii hicolor-icon-theme 0.17-2 ii libatk-bridge2.0-0 2.38.0-1 ii libatk1.0-0 2.36.0-2 ii libc62.31-13+deb11u2 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libcolord2 1.4.5-3 ii libcups2 2.3.3op2-3+deb11u1 ii libepoxy01.5.5-1 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libfribidi0 1.0.8-2 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-common 3.24.24-4 ii libharfbuzz0b2.7.4-1 ii libjson-glib-1.0-0 1.6.2-1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libpangoft2-1.0-01.46.2-3 ii librest-0.7-00.8.1-1.1 ii libwayland-client0 1.18.0-2~exp1.1 ii libwayland-cursor0 1.18.0-2~exp1.1 ii libwayland-egl1 1.18.0-2~exp1.1 ii libx11-6 2:1.7.2-1 ii libxcomposite1 1:0.4.5-1 ii libxcursor1 1:1.2.0-2 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxi6 2:1.7.10-1 ii libxinerama1 2:1.1.4-2 ii libxkbcommon01.0.3-2 ii libxrandr2 2:1.5.1-1 ii shared-mime-info 2.0-1 Versions of packages libgtk-3-0 recommends: ii libgtk-3-bin 3.24.24-4 ii librsvg2-common 2.50.3+dfsg-1 Versions of packages libgtk-3-0 suggests: ii gvfs 1.46.2-1 Versions of packages libgtk-3-0 is related to: pn appmenu-gtk3-module pn fcitx-frontend-gtk3 pn gcin-gtk3-immodule pn gtk-vector-screenshot pn gtk3-engines-xfce pn gtk3-im-libthai pn hime-gtk3-immodule ii ibus-gtk3 1.5.23-2 pn imhangul-gtk3 ii libcanberra-gtk3-module 0.30-7 pn libcaribou-gtk3-module pn libgtk3-nocsd0 pn maliit-inputcontext-gtk3 pn packagekit-gtk3-module pn scim-gtk-immodule pn topmenu-gtk3 pn uim-gtk3 pn uim-gtk3-immodule -- no debconf information
Bug#664257:
Bug#1004262: [debian-mysql] Bug#1004262: Acknowledgement (mariadb-server: Instead of being upgraded, mariadb-server gets removed after apt update)
Since 'apt' always outputs 'WARNING: apt does not have a stable CLI interface. Use with caution in scripts.' we don't use it in our CI infra. Instead our install/upgrade testing uses apt-get, see https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/salsa-ci.yml Latest run shows no upgrade regressions: https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines/335209 On Thu, Jan 27, 2022 at 10:05 AM Otto Kekäläinen wrote: > > Note that apt-get and apt use different resolvers. Did you > specifically run 'apt' or 'apt-get'?
Bug#1004439: ausweisapp2: Please add Recommends: for ReinerSCT cyberjack readers
Package: ausweisapp2 Version: 1.22.0-1 Severity: normal X-Debbugs-Cc: sm...@smurf.noris.de The ReinerSCT cyberjack requires these packages to work: # libccid libpcsclite1 pcscd pcsc-tools libifd-cyberjack6 Please add them as Recommends: to the AusweisApp2 package so that these readers work out of the box. Source: https://matrica.de/wiki/index.php/Cyberjack and tests on my system. -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'oldstable'), (500, 'unstable'), (450, 'focal'), (350, 'oldoldstable'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_USER Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ausweisapp2 depends on: ii libc6 2.33-2 ii libhttp-parser2.9 2.9.4-4 ii libpcsclite1 1.9.1-1 ii libqt5core5a 5.15.2+dfsg-14 ii libqt5gui5 5.15.2+dfsg-14 ii libqt5network5 5.15.2+dfsg-14 ii libqt5qml5 5.15.2+dfsg-6 ii libqt5quick5 5.15.2+dfsg-6 ii libqt5svg5 5.15.2-3 ii libqt5websockets5 5.15.2-2 ii libqt5widgets5 5.15.2+dfsg-14 ii libssl1.1 1.1.1k-1+deb11u1 ii libstdc++6 12-20220116-1 ii libudev1 247.3-6 ii qml-module-qt-labs-platform5.15.2+dfsg-2 ii qml-module-qtgraphicaleffects 5.15.2-2 ii qml-module-qtqml 5.15.2+dfsg-6 ii qml-module-qtqml-models2 5.15.2+dfsg-6 ii qml-module-qtqml-statemachine 5.15.2+dfsg-6 ii qml-module-qtquick-controls5.15.2-2 ii qml-module-qtquick-controls2 5.15.2+dfsg-2 ii qml-module-qtquick-layouts 5.15.2+dfsg-6 ausweisapp2 recommends no packages. ausweisapp2 suggests no packages. -- debconf-show failed
Bug#1004262: [debian-mysql] Bug#1004262: Acknowledgement (mariadb-server: Instead of being upgraded, mariadb-server gets removed after apt update)
Note that apt-get and apt use different resolvers. Did you specifically run 'apt' or 'apt-get'?
Bug#1004438: reportbug: gstreamer1.0-plugins-bad 1.18.5-1+b4 has an invalid dependency on a contrib package
Package: gstreamer1.0-plugins-bad Version: 1.18.5-1+b4 Severity: serious Justification: Policy 2.2.1 X-Debbugs-Cc: fgou...@free.fr Dear Maintainer, gstreamer1.0-plugins-bad is part of the main archive area. However in Debian Testing's version 1.18.5-1+b4 it depends on libgstreamer-gl1.0-0 which is now in the contrib archive area. This is a violation of section 2.2.1 of the Policy which states that: None of the packages in the main archive area require software outside of that area to function. So to fix this one of the following should be done: * Demote this dependency to a 'Suggest', assuming the package is still usable without it. * Remove the dependency entirely with the same caveat. * Or libgstreamer-gl1.0-0 should be moved back to the main archive area. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/36 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages gstreamer1.0-plugins-bad depends on: ii gstreamer1.0-plugins-base 1.18.5-1 ii libaom3 3.2.0-2 ii libass9 1:0.15.2-1 ii libbs2b03.1.0+dfsg-2.2+b1 ii libbz2-1.0 1.0.8-5 ii libc6 2.33-3 ii libcairo2 1.16.0-5 ii libchromaprint1 1.5.1-1 ii libcurl3-gnutls 7.81.0-1 ii libdc1394-252.2.6-4 ii libdca0 0.0.7-2 ii libde265-0 1.0.8-1 ii libdrm2 2.4.109-2 ii libdvdnav4 6.1.1-1 ii libdvdread8 6.1.2-1 ii libfaad22.10.0-2 ii libflite1 2.2-2 ii libfluidsynth3 2.2.4-2 ii libgcc-s1 11.2.0-14 ii libglib2.0-02.70.2-1 ii libgme0 0.6.3-2 ii libgsm1 1.0.18-2 ii libgstreamer-gl1.0-01.18.5-1 ii libgstreamer-plugins-bad1.0-0 1.18.5-1+b4 ii libgstreamer-plugins-base1.0-0 1.18.5-1 ii libgstreamer1.0-0 1.18.5-1 ii libgudev-1.0-0 237-2 ii libilmbase252.5.7-2 ii libkate10.4.1-11 ii liblcms2-2 2.12~rc1-2 ii liblilv-0-0 0.24.12-2 ii libltc111.3.1-1 ii libmfx1 22.1.0-1 ii libmjpegutils-2.1-0 1:2.1.0+debian-6 ii libmms0 0.6.4-3 ii libmodplug1 1:0.8.9.0-3 ii libmpcdec6 2:0.1~r495-2 ii libmpeg2encpp-2.1-0 1:2.1.0+debian-6 ii libmplex2-2.1-0 1:2.1.0+debian-6 ii libnettle8 3.7.3-1 ii libnice10 0.1.18-2 ii libofa0 0.9.3-21 ii libopenal1 1:1.19.1-2 ii libopenexr252.5.7-1 ii libopenjp2-72.4.0-6 ii libopenmpt0 0.6.0-1 ii libopenni2-02.2.0.33+dfsg-15 ii libopus01.3.1-0.1 ii liborc-0.4-01:0.4.32-2 ii libpango-1.0-0 1.50.3+ds1-4 ii libpangocairo-1.0-0 1.50.3+ds1-4 ii librsvg2-2 2.50.7+dfsg-2 ii librtmp12.4+20151223.gitfa8646d.1-2+b2 ii libsbc1 1.5-3 ii libsndfile1 1.0.31-2 ii libsoundtouch1 2.3.1+ds1-1+b1 ii libspandsp2 0.0.6+dfsg-2 ii libsrt1.4-gnutls1.4.2-1.4 ii libsrtp2-1 2.4.2-2 ii libssl1.1 1.1.1m-1 ii libstdc++6 11.2.0-14 ii libusb-1.0-02:1.0.24-3 ii libva-drm2 2.13.0-1 ii libva2 2.13.0-1 ii libvo-aacenc0 0.1.3-2 ii libvo-amrwbenc0 0.1.3-2 ii libwayland-client0 1.19.0-2+b1 ii libwebp60.6.1-2.1 ii libwebrtc-audio-processing1 0.3-1+b1 ii libwildmidi20.4.3-1 ii libx11-62:1.7.2-2+b1 ii libx265-199 3.5-2 ii libxml2 2.9.12+dfsg-5+b1 ii libzbar00.23.92-4 ii libzvbi00.2.35-19 gstreamer1.0-plugins-bad recommends no packages. Versions of packages gstreamer1.0-plugins-bad suggests: pn frei0r-plugins -- no debconf information
Bug#1004437: pyserial-asyncio: Dependency on sphinx-related packages
Source: pyserial-asyncio
Version: 0.5-2
Severity: normal
Dear Maintainer,
I just noticed, that the python3-serial-asyncio package announces the
following packages as hard dependencies ("Depends"):
python3-serial, python3:any, libjs-sphinxdoc, sphinx-rtd-theme-common
I guess, that the two sphinx-related packages are not strictly relevant
for using the python module?
Maybe these are just build dependencies?
Or these packages should just be downgraded to "Suggests" (or
"Recommends", if they are really relevant under most circumstances).
I am using pyserial-asyncio in an embedded environment and I would like
to just use 88 kB for pyserial-asyncio (and avoid the extra 4,5 MB for
the sphinx-related dependencies).
Thank you for maintaining this package!
Cheers,
Lars
Bug#1002706: Fwd: nftables stateless NAT in raw table mangles fragmented UDP packets
Hi all,
The patch made its way to mainline / latest
Any chance to get it backported to 4.19?
> From: Pablo Neira Ayuso
>
> [ Upstream commit 4e1860a3863707e8177329c006d10f9e37e097a8 ]
>
> IP fragments do not come with the transport header, hence skip bogus
> layer 4 checksum updates.
>
> Fixes: 1814096980bb ("netfilter: nft_payload: layer 4 checksum adjustment for
> pseudoheader fields")
> Reported-and-tested-by: Steffen Weinreich
> Signed-off-by: Pablo Neira Ayuso
> Signed-off-by: Sasha Levin
> ---
> net/netfilter/nft_payload.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/netfilter/nft_payload.c b/net/netfilter/nft_payload.c
> index a44b14f6c0dc0..132875cd7fff2 100644
> --- a/net/netfilter/nft_payload.c
> +++ b/net/netfilter/nft_payload.c
> @@ -502,6 +502,9 @@ static int nft_payload_l4csum_offset(const struct
> nft_pktinfo *pkt,
>struct sk_buff *skb,
>unsigned int *l4csum_offset)
> {
> + if (pkt->fragoff)
> + return -1;
> +
> switch (pkt->tprot) {
> case IPPROTO_TCP:
> *l4csum_offset = offsetof(struct tcphdr, check);
> -- 2.34.1
Bug#983985: bctoolbox: ftbfs with GCC-11
X-Debbugs-CC: Andrea Pappacoda On Thu, Jan 27, 2022 at 04:21:29PM +0100, Andrea Pappacoda wrote: > I got here because bctoolbox depends on MbedTLS, and I'm working on its > transition. As the release team told me that I can proceed with the upload > to unstable, would it be an issue for you if I push the update? MbedTLS 2.28 > should be API compatible with 2.16 and shouldn't cause issues (the current > version of bctoolbox builds fine with it), but I'd like to be sure that I > don't break stuff (again). As I can't test the version you're working on, > could you please test if your updated bctoolbox builds fine with the mbedtls > package in experimental? No, it's alright, proceed ahead. Because the version number was different I didn't realize you are doing essentially a BinNMU. bctoolbox 5.0.37 builds perfectly with mbedtls 2.28.0-0.1 here, I will test with 2.28.0-0.2 ASAP. Regards.
Bug#1004436: ikiwiki-hosting-web should depend only on known-working C compilers
Package: ikiwiki-hosting-web Version: 0.20180719-2 Severity: important Depends: ..., gcc | c-compiler,... There is no defined semantics what "c-compiler" actually provides, e.g. 'cc' might or might not be provided. There are mysterious ppc64el debci failures that might be related to bcc being installed on ppc64el while tcc gets installed on other architectures. Please change this dependency to either only gcc, or a list of known-working C compiler alternatives.
Bug#717205: phpldapadmin: [INTL:ja] New Japanese translation
control: tags -1 patch pending New NMU is ongoing G. On Thu, 18 Jul 2013 07:10:24 +0900 victory wrote: Package: phpldapadmin Version: 1.2.2-5 Severity: wishlist Tags: patch l10n Dear phpldapadmin package maintainer, Here's Japanese po-debconf template translation (ja.po) file that reviewed by several Japanese Debian developers and users. Could you apply it, please? -- victory http://userscripts.org/scripts/show/102724 0.0.1.4 http://userscripts.org/scripts/show/163846 0.0.1 http://userscripts.org/scripts/show/163848 0.0.1 phpldapadmin_1.2.6.3-0.2.debian.tar.xz Description: application/xz
Bug#995171: [Help] Bug#995171: need newer release
Hi, Am Thu, Jan 27, 2022 at 11:52:26PM +0800 schrieb Shengjing Zhu: > On Thu, Jan 27, 2022 at 8:53 PM Nilesh Patra wrote: > > c) Port code to the version 7 of this package (which you uploaded) > > The port is rather straightforward. I just send the patch to upstream, > please see https://github.com/apptainer/apptainer/pull/182 Looks straightforward (even if incomplete - I needed another patch[1]. This leads to some progress in the configure step - but the build fails later (see salsa-ci[2]). Any further help would be really welcome. > Andreas, are you aware that singularity is now hosted by linux > foundation and renamed to apptainer? > http://apptainer.org/news/community-announcement-20211130 Thanks a lot for the hint. I was not aware of this. However, I need to admit that I do not consider myself as an active maintainer of the singularity-container package. I simply found out that the package that is called as "bread for containerized computing in scientific context" here in this bug log is neither in stable nor can I find obvious signs that someone cares for open CVEs. My main intention is to get singulatity into testing first. The next steps should be decided by the hopefully re-activated maintainers team. Kind regards and thanks again for your help Andreas. [1] https://salsa.debian.org/hpc-team/singularity-container/-/blob/master/debian/patches/bump_further_mbp_from_v4_to_v7.patch [2] https://salsa.debian.org/hpc-team/singularity-container/-/jobs/2404165 -- http://fam-tille.de
Bug#1004426: Acknowledgement (linux-image-5.10.0-10-amd64: webcam Live! Cam Sync HD VF0770 unusable after updating to linux-image-5.10.0-10)
> Is this the same problem as reported in bug #1003236? Yes, it looks the same. On Thu, Jan 27, 2022 at 2:51 PM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1004426: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004426. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > As you requested using X-Debbugs-CC, your message was also forwarded to > lxk...@wp.pl > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > Debian Kernel Team > > If you wish to submit further information on this problem, please > send it to 1004...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 1004426: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004426 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#1004435: transition: dart
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello! I'm the maintainer of dart, we have a new version in experimental that builds on the previous platforms supported, 6.12.1+dfsg4-8. I've run ratt and the expected dependency, Gazebo, builds just fine: https://release.debian.org/transitions/html/auto-dart.html https://build.osrfoundation.org/job/debian-ratt-builder/145/ """ 2022/01/26 13:50:25 dose-ceve(1) failed (exit status 64), falling back to interpreting Sources directly 2022/01/26 13:50:25 Loading sources index "/var/lib/apt/lists/ftp.us.debian.org_debian_dists_experimental_main_source_Sources" 2022/01/26 13:50:26 Loading sources index "/var/lib/apt/lists/deb.debian.org_debian_dists_experimental_main_source_Sources" 2022/01/26 13:50:26 Found 1 reverse build dependencies 2022/01/26 13:50:26 Setting -sbuild_dist=experimental (from .changes file) 2022/01/26 13:50:26 Packages to rebuild gazebo_11.9.1+dfsg-7 gazebo_11.9.1+dfsg-7 2022/01/26 13:50:26 Building package 1 of 1: gazebo 2022/01/26 14:42:42 Build results: 2022/01/26 14:42:42 PASSED: gazebo """ Ben file: title = "dart"; is_affected = .depends ~ /\b(libdart\-collision\-bullet6\.12|libdart\-collision\-ode6\.12|libdart\-external\-convhull\-3d\-dev|libdart\-external\-imgui6\.12|libdart\-external\-lodepng6\.12|libdart\-external\-odelcpsolver6\.12|libdart\-gui\-osg6\.12|libdart\-gui6\.12|libdart\-optimizer\-ipopt6\.12|libdart\-optimizer\-nlopt6\.12|libdart\-utils\-urdf6\.12|libdart\-utils6\.12|libdart6\.12|python3\-dartpy|libdart\-collision\-bullet6|libdart\-collision\-ode6|libdart\-external\-imgui6|libdart\-external\-lodepng6|libdart\-external\-odelcpsolver6|libdart\-gui\-osg6|libdart\-gui6|libdart\-optimizer\-ipopt6|libdart\-optimizer\-nlopt6|libdart\-planning\-dev|libdart\-planning6|libdart\-utils\-urdf6|libdart\-utils6|libdart6|libkido\-dev|libkido\-gui\-dev|libkido\-gui\-osg\-dev|libkido\-gui\-osg0|libkido\-gui0|libkido\-optimizer\-ipopt\-dev|libkido\-optimizer\-ipopt0|libkido\-optimizer\-nlopt\-dev|libkido\-optimizer\-nlopt0|libkido\-planning\-dev|libkido\-planning0|libkido\-utils\-dev|libkido\-utils0|libkido0)\b/; is_good = .depends ~ /\b(libdart\-collision\-bullet6\.12|libdart\-collision\-ode6\.12|libdart\-external\-convhull\-3d\-dev|libdart\-external\-imgui6\.12|libdart\-external\-lodepng6\.12|libdart\-external\-odelcpsolver6\.12|libdart\-gui\-osg6\.12|libdart\-gui6\.12|libdart\-optimizer\-ipopt6\.12|libdart\-optimizer\-nlopt6\.12|libdart\-utils\-urdf6\.12|libdart\-utils6\.12|libdart6\.12|python3\-dartpy)\b/ is_bad = .depends ~ /\b(libdart\-collision\-bullet6|libdart\-collision\-ode6|libdart\-external\-imgui6|libdart\-external\-lodepng6|libdart\-external\-odelcpsolver6|libdart\-gui\-osg6|libdart\-gui6|libdart\-optimizer\-ipopt6|libdart\-optimizer\-nlopt6|libdart\-planning\-dev|libdart\-planning6|libdart\-utils\-urdf6|libdart\-utils6|libdart6|libkido\-dev|libkido\-gui\-dev|libkido\-gui\-osg\-dev|libkido\-gui\-osg0|libkido\-gui0|libkido\-optimizer\-ipopt\-dev|libkido\-optimizer\-ipopt0|libkido\-optimizer\-nlopt\-dev|libkido\-optimizer\-nlopt0|libkido\-planning\-dev|libkido\-planning0|libkido\-utils\-dev|libkido\-utils0|libkido0)\b/
Bug#1004345: RFS: ricochet-refresh/3.0.11-1
Hi. I put on my "Debian" hat had a look at this package. I started with the git branch g...@github.com:m-simonelli/ricochet-refresh 885f03138fe6e88006bdb672ce478751d119eff3 and then also ended up downloading the dsc and comparing it. Here are my comments. I hope they're not too discouraging... 1. Embedded copy of Tor I observe that this source package contains a copy of tor. Debian really doesn't like embedded copies like that. Is there some reason why you can't use the copy of Tor that's in Debian already ? Please forgive me if the answer to this is something I ought to already know. But I think if there is a good answer it ought to be in some in-tree document, maybe debian/README.source. (After I noticed this, I stopped my review, since it seemed likely that changing this would cause substantial other changes.) 2. In debian/rules, there is a bunch of stuff to modify the compile flags. I think it is good practice to leave a comment next to all override_dh_* to explain why it is needed, if it is not enitrely obvious. In particular, * Why does dh + cmake not get the install prefix etc. right by itself ? Is there a Debian bug about that ? * There are various options like -z now, -D_FORTIFY_SOURCE=2, -g, etc, which, again, ISTM that dh cmake ought to get right. * Why are we hand-tuning the parallelism ? etc. I'm not very familiar with cmake so perhaps this is all "normal for cmake" but if so that would be me as contrary to the usual philosophy of dh(1), which is usually to do the right thing by default. 3. Use of git and tarballs This is not a blocker. And I'm going to make some comments which will definitely not be shared by everyone. And I appreciate that much Debian packaging really likes to think about tarballs. I'll work with .dscs and tarballs if there isn't a better way. But: I see you used git submodules. IMO git submodules are extremely poor. This message is not the right place for a full explanation, but they (i) fundamentally break many of git's basic design principles, and (ii) consequently break many very normal git operations. Separately (iii) the design and implementation are full of avoidable bugs. In general, I would recommend git subtree instead - at least if the subproject is not too large compared to the superproject, which isn't the case here. But I'm not sure this program ought to have a bundled copy of Tor anyway. So what precisely ought to be done about this depends on what to do about the embedded Tor copy. And, I see that the "uptream tarball" you provided in your RFS is not identical to (any version of?) the git branch. I'm not sure how it was produced. AFAICT from the upstream web page, the official source code is in git. So I would have expected any upstream tarball to be the result of "git archive". If you *do* have official upstream tarballs, then the most common Debian practice nowadays is to use pristine-tar. Additionally, I see you have a contraption to remove .gitignore and .gitattributes from your tarballs. I think this is ill-conceived. There is no reason you can't put a .gitignore into a tarball. I think the .gitignore is part of the preferred form for modification (ie, part of the source code.) Of course I'm happy to talk about everything more (here, irc, or private email). Regards, Ian.
Bug#1003273: pipewire: headset mic not working
On Thu, 27 Jan 2022, Dylan Aïssi wrote: Pipewire 0.3.43 is now in testing, this version includes f8cdc05720bf1. Could you check if it works without having to modify the config file? I've reverted the manual change and rebooted, and the mic still seems to work. Looks fixed :-) -- Marc Glisse
Bug#1004434: ITP: python-rangehttpserver -- SimpleHTTPServer with support for Range requests
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: python-rangehttpserver Version : 1.2.0 Upstream Author : Dan Vanderkam * URL : https://github.com/danvk/RangeHTTPServer * License : Apache 2.0 Programming Lang: Python Description : SimpleHTTPServer with support for Range requests RangeHTTPServer is a Python module for running a simple HTTP server with support for range requests. It is suitable for use in local testing, not Internet scale production use. . HTTP range requests ask the server to send only a portion of an HTTP message back to a client and are useful for clients like media players that support random access, data tools that know they need only part of a large file, and download managers that let the user pause and resume the download. I will maintain this in the Debian Python Team. It is required to make the serve option in clamav-cvdupdate work (currently disabled until this gets in). Also, it looks like there is an embedded copy in python3-asdf, so perhaps it could be updated to use a system version.
Bug#995171: [Help] Re: Bug#995171: need newer release
Hi On Thu, Jan 27, 2022 at 8:53 PM Nilesh Patra wrote: > c) Port code to the version 7 of this package (which you uploaded) The port is rather straightforward. I just send the patch to upstream, please see https://github.com/apptainer/apptainer/pull/182 Andreas, are you aware that singularity is now hosted by linux foundation and renamed to apptainer? http://apptainer.org/news/community-announcement-20211130 -- Shengjing Zhu
Bug#977469: matplotlib: Please make package bootstrappable
On Mon, 10 Jan 2022 11:06:56 +0100 Laurent Bigonville wrote: > Hello, > > As suggested in an other bug report, moving the build-dependencies that > are only needed to build -doc/arch:all packages to Build-Depends-Indep > would also help here I guess > I've made this merge request: https://salsa.debian.org/python-team/packages/matplotlib/-/merge_requests/1 I duplicated some of the build-dependencies to make it more clear that they are needed by both, if that's no OK I can rework my change and only keep one
Bug#1003273: pipewire: headset mic not working
Hi Marc, Le ven. 7 janv. 2022 à 13:03, Marc Glisse a écrit : > > Editing a file in /usr is obviously not good. I don't know if it would > make sense to backport > https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/f8cdc05720bf13bd78e42eb6890fc2f855c8f554 > for the debian package (and I haven't checked if that actually works, > although it does look likely). > > Since this used to work, I don't know if something used to enable > multi-rate, or if some new client appeared that uses a "bad" rate, that > could point to another workaround. > Pipewire 0.3.43 is now in testing, this version includes f8cdc05720bf1. Could you check if it works without having to modify the config file? Best, Dylan
Bug#1004433: CVE-2022-23959: VSV00008 Varnish HTTP/1 Request Smuggling Vulnerability
Package: varnish Severity: normal Hello! There is a new vendor-announcement regarding a request smuggling attack - this time affects HTTP/1 connections. It's apparently affecting all versions >= Stretch. https://varnish-cache.org/security/VSV8.html https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23959 Best Regards, Andreas
Bug#1004432: ITP: cloud-enum -- Enumerate public resources in cloud
Package: wnpp Severity: wishlist Owner: Guilherme de Paula Xavier Segundo X-Debbugs-Cc: debian-de...@lists.debian.org, guilherme@gmail.com * Package name: cloud-enum Version : 0.6 Upstream Author : initstring * URL : https://github.com/initstring/cloud_enum * License : GPL3+ Programming Lang: Python Description : Enumerate public resources in cloud Enumerates public resources matching user requested keywords in public clouds as Amazoan (Open / Protected S3 Buckets awsapps), Azure (Storage Accounts, Open Blob Storage Containers, Hosted Databases, Virtual Machines Web Apps), Google Cloud (Open / Protected GCP Buckets, Open / Protected Firebase Realtime Databases, Google App Engine sites, Cloud Functions).
Bug#1004426: linux-image-5.10.0-10-amd64: webcam Live! Cam Sync HD VF0770 unusable after updating to linux-image-5.10.0-10
On donderdag 27 januari 2022 14:47:51 CET Jakub wrote: > Version: 5.10.84-1 > > After updating from 5.10.0-9-amd64 to 5.10.0-10-amd64 the camera stopped > working. It still works if I boot with previous image. Is this the same problem as reported in bug #1003236? If that's the case it should help narrow down which commit caused it. signature.asc Description: This is a digitally signed message part.
Bug#1004422: mrtg: [INTL:fr] French templates translation
Thanks Jean-Pierre! Cheers, Eriberto
Bug#1004431: at 0x4008854: cached_fpabi_reject_phdr_p (dl-machine-reject-phdr.h:57)
Source: valgrind Version: 1:3.18.1-1 valgrind is making the test suite to fail on dumpasn1: * https://buildd.debian.org/status/fetch.php?pkg=dumpasn1=mips64el=20210212-1=1639576768=0 The report seems to be bogus: ==22912== Memcheck, a memory error detector ==22912== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==22912== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==22912== Command: ./dumpasn1 - ==22912== ==22912== Conditional jump or move depends on uninitialised value(s) ==22912==at 0x4008854: cached_fpabi_reject_phdr_p (dl-machine-reject-phdr.h:57) ==22912==by 0x4008854: elf_machine_reject_phdr_p (dl-machine-reject-phdr.h:217) ==22912==by 0x4008DFC: open_verify.constprop.0 (dl-load.c:1791) ==22912==by 0x400C158: _dl_map_object (dl-load.c:2274) ==22912==by 0x4002D74: map_doit (rtld.c:652) ==22912==by 0x401F70C: _dl_catch_exception (dl-error-skeleton.c:208) ==22912==by 0x401F7D0: _dl_catch_error (dl-error-skeleton.c:227) ==22912==by 0x4002CB4: do_preload (rtld.c:829) ==22912==by 0x4004268: handle_preload_list (rtld.c:921) ==22912==by 0x40070CC: dl_main (rtld.c:1838) ==22912==by 0x401E164: _dl_sysdep_start (dl-sysdep.c:250) ==22912==by 0x400375C: _dl_start_final (rtld.c:489) ==22912==by 0x40039F4: _dl_start (rtld.c:584) ==22912==
Bug#1004430: tar: `numeric-owner` not honored for ACLs
Package: tar Version: 1.34+dfsg-1 Severity: normal Tags: patch X-Debbugs-Cc: f.gruenbich...@proxmox.com filed upstream (with similar patch): http://savannah.gnu.org/bugs/?61934 ACL entries store references to numeric uids/gids. on platforms that have libacl, use `acl_to_any_text` to generate ACL strings that preserve those numeric identifiers if `numeric-owner` is set (instead of doing a conversion to user/group name, like the acl_to_text function does). reproducer (similar ones exist where a user/group of the stored name exists, but has a different numeric identifier): system A with user foo with uid 1001 system B with no user foo file with ACL referencing uid 1001 on system A on A: $ echo 'bar' > file $ setfacl -m u:foo:r file $ tar --acls --xattrs --numeric-owner -cf test.tar file $ tar -vv --acls --xattrs -tf test.tar expected output: -rw-r--r--+ 0/0 4 2022-01-26 14:32 file a: user::rw-,user:1001:r--,group::r--,mask::r--,other::r-- actual output: -rw-r--r--+ 0/0 4 2022-01-26 14:32 file a: user::rw-,user:fakeuser:r--,group::r--,mask::r--,other::r-- on B: $ tar --acls --xattrs -xf test.tar $ getfacl -n file expected output (extraction) - none expected output (getfacl): # file: file # owner: 0 # group: 0 user::rw- user:1001:r-- group::r-- other::r-- actual output (extraction): tar: file: Warning: Cannot acl_from_text: Invalid argument actual output (getfacl) - note the missing user entry: # file: file # owner: 0 # group: 0 user::rw- group::r-- other::r-- attached patch changes the behaviour of archive creation to honor `numeric-owner` iff libacl is available. the extraction side remains unchanged (it handles both numeric and symbolic references in ACL entries). -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tar depends on: ii libacl1 2.3.1-1 ii libc62.33-5 ii libselinux1 3.3-1+b1 tar recommends no packages. Versions of packages tar suggests: ii bzip21.0.8-5 pn ncompress pn tar-doc pn tar-scripts ii xz-utils 5.2.5-2 -- no debconf information Index: tar-1.34+dfsg/src/xattrs.c === --- tar-1.34+dfsg.orig/src/xattrs.c +++ tar-1.34+dfsg/src/xattrs.c @@ -53,6 +53,10 @@ static struct #ifdef HAVE_POSIX_ACLS # include "acl.h" # include +#ifdef HAVE_ACL_LIBACL_H +/* needed for numeric-owner support */ +# include +#endif #endif #ifdef HAVE_POSIX_ACLS @@ -285,7 +289,13 @@ xattrs__acls_get_a (int parentfd, const return; } - val = acl_to_text (acl, NULL); +#ifdef HAVE_ACL_LIBACL_H + if (numeric_owner_option) +val = acl_to_any_text(acl, NULL, '\n', TEXT_SOME_EFFECTIVE | TEXT_NUMERIC_IDS); + else +#endif +val = acl_to_text (acl, NULL); + acl_free (acl); if (!val) @@ -315,7 +325,13 @@ xattrs__acls_get_d (int parentfd, char c return; } - val = acl_to_text (acl, NULL); +#ifdef HAVE_ACL_LIBACL_H + if (numeric_owner_option) +val = acl_to_any_text(acl, NULL, '\n', TEXT_SOME_EFFECTIVE | TEXT_NUMERIC_IDS); + else +val = acl_to_text (acl, NULL); +#endif + acl_free (acl); if (!val)
Bug#1004427: openssh-server: Connection reset when trying to establish a connection on armhf
Hello, On Thu, Jan 27, 2022 at 02:52:31PM +0100, Benedikt Wildenhain wrote: > Package: openssh-server > Version: 1:8.4p1-5 > Severity: important > X-Debbugs-Cc: benedikt.wildenh...@hs-bochum.de > > ii libc6 2.33-3 the issue can be fixed by downgrading libc6 to 2.31-13+deb11u2 (stable) or upgrading openssh-server to testing (8.7p1-4). Regards, Benedikt Wildenhain
Bug#1004429: libllvm12: Cannot install due to package conflicts
Package: libllvm12 Version: 1:12.0.1-17+b1 Severity: important Dear Maintainer, Trying to install libllvm12:i386 on an amd64 system causes apt to want to remove most of the desktop environment. I tried the unstable package as well, with the same result. libllvm12:i386 is needed as a dependency of libgl1-mesa-dri:i386 which in turn is needed as a dependency of third party software "Steam". See the console output: julian@Niffa:~$ sudo apt install libllvm12:i386 [sudo] password for julian: Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: apache2-bin cheese-common cinnamon-session-common cjs dconf-cli dleyna-server dns-root-data dnsmasq-base docbook-xml fonts-dejavu fonts-dejavu-extra fonts- symbola gir1.2-ayatanaappindicator3-0.1 gir1.2-caribou-1.0 gir1.2-cmenu-3.0 gir1.2-gdesktopenums-3.0 gir1.2-gnomedesktop-3.0 gir1.2-handy-1 gir1.2-javascriptcoregtk-4.0 gir1.2-json-1.0 gir1.2-keybinder-3.0 gir1.2-malcontent-0 gir1.2-nemo-3.0 gir1.2-nm-1.0 gir1.2-nma-1.0 gir1.2-soup-2.4 gir1.2-timezonemap-1.0 gir1.2-totemplparser-1.0 gir1.2-upowerglib-1.0 gjs gkbd-capplet gnome-backgrounds gnome-control-center-data gnome-settings-daemon gnome- settings-daemon-common gnome-user-share grilo-plugins-0.3 iio-sensor-proxy iptables iw libapache2-mod-dnssd libappstream-glib8 libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libbotan-2-18 libcaribou-common libcaribou0 libcjs0 libclutter-1.0-common libcogl-common libcolord-gtk1 libdc1394-25 libdca0 libdecor-0-0 libdecor-0-plugin-1-cairo libdee-1.0-4 libdleyna-connector-dbus-1.0-1 libdleyna-core-1.0-5 libdmapsharing-3.0-2 libdrm-amdgpu1 libdrm-nouveau2 libdrm-radeon1 libdvdnav4 libegl-mesa0 libegl1 libevdev2 libfaad2 libflatpak0 libfluidsynth3 libgeoclue-2-0 libgeocode-glib0 libgjs0g libglapi-mesa libglvnd0 libgnome-bluetooth13 libgom-1.0-0 libgpod-common libgpod4 libgrilo-0.3-0 libgstreamer-plugins-bad1.0-0 libgupnp-av-1.0-2 libgupnp-dlna-2.0-3 libgweather-3-16 libgweather-common libibus-1.0-5 libimagequant0 libinput-bin libinput10 libinstpatch-1.0-2 libip6tc2 libjavascriptcoregtk-4.0-18 libkate1 libkeybinder-3.0-0 liblirc-client0 libltc11 libmalcontent-ui-0-0 libmanette-0.2-0 libmediaart-2.0-0 libmjpegutils-2.1-0 libmms0 libmodplug1 libmozjs-78-0 libmpcdec6 libmpeg2encpp-2.1-0 libmplex2-2.1-0 libmtdev1 libndp0 libnetfilter-conntrack3 libnfnetlink0 libnl-3-200 libnl-genl-3-200 libnl-route-3-200 libnss-myhostname liboauth0 libofa0 libopenal-data libopenal1 libopenni2-0 libostree-1-1 libpcsclite1 libpipewire-0.3-0 libpipewire-0.3-common libpipewire-0.3-modules libraqm0 librest-0.7-0 librygel-core-2.6-2 librygel- db-2.6-2 librygel-renderer-2.6-2 librygel-server-2.6-2 libsdl2-2.0-0 libsgutils2-2 libsndio7.0 libsoundtouch1 libsoup-gnome2.4-1 libspa-0.2-modules libspandsp2 libsrtp2-1 libteamdctl0 libtimezonemap-data libtimezonemap1 libtspi1 libunity-protocol-private0 libunity-scopes-json-def- desktop libunity9 libvo-aacenc0 libvo-amrwbenc0 libwildmidi2 libwpe-1.0-1 libwpebackend-fdo-1.0-1 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-randr0 libxcb-res0 libxcb-shape0 libxcb- sync1 libxcb-xfixes0 libxfont2 libxshmfence1 libxvmc1 libxxf86dga1 libz3-4 libzbar0 malcontent malcontent-gui metacity-common mobile-broadband-provider- info muffin-common network-manager network-manager-gnome pipewire pipewire-bin pipewire-media-session python- tinycss2-common python3-distro python3-mako python3-markupsafe python3-olefile python3-pampy python3-pil python3-pyinotify python3-tinycss2 python3-tz realmd sgml-base sgml-data shotwell-common timgm6mb-soundfont totem-common wireless-regdb wpasupplicant x11-apps x11-session-utils xdg-dbus-proxy xdg-desktop-portal xdg-desktop-portal-gtk xfonts-100dpi xfonts-75dpi xfonts-base xfonts-scalable xinit xml-core xserver- common xserver-xorg-legacy yelp-xsl zenity-common Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: libatomic1:i386 libedit2:i386 libffi8:i386 libicu67:i386 liblzma5:i386 libstdc++6:i386 libtinfo6:i386 libxml2:i386 libz3-4:i386 zlib1g:i386 The following packages will be REMOVED: blueman cheese cinnamon cinnamon-common cinnamon-control-center-goa cinnamon- core cinnamon-desktop-environment cinnamon-session gir1.2-clutter-1.0 gir1.2-cogl-1.0 gir1.2-coglpango-1.0 gir1.2-gst-plugins-bad-1.0 gir1.2-gst- plugins-base-1.0 gir1.2-gtkclutter-1.0 gir1.2-meta-muffin-0.0 gir1.2-rb-3.0 gir1.2-totem-1.0 gir1.2-webkit2-4.0 gnome-2048 gnome-control-center gnome-games gnome-nibbles gnome-online-accounts gnome-sound-recorder gnome-user-docs gnome-video-effects gstreamer1.0-clutter-3.0 gstreamer1.0-gl gstreamer1.0-gtk3 gstreamer1.0-plugins-bad libcheese-gtk25 libcheese8 libclutter-1.0-0 libclutter-gst-3.0-0 libclutter-gtk-1.0-0 libcogl-pango20 libcogl-path20 libcogl20 libges-1.0-0 libgl1 libgl1-mesa-dri libglu1-mesa libglx-mesa0
Bug#1004428: [PATCH] Add remaining options to exiqgrep.8
Package: exim4 Version: 4.95-3 Tags: patch Hi, the provided patch adds al yet undocumented options to exiqgrep.8. I hope the quality matches your expectations. Regards Janne diff --git a/debian/manpages/exiqgrep.8 b/debian/manpages/exiqgrep.8 index e436237..300bc17 100644 --- a/debian/manpages/exiqgrep.8 +++ b/debian/manpages/exiqgrep.8 @@ -2,7 +2,7 @@ .\" First parameter, NAME, should be all caps .\" Second parameter, SECTION, should be 1-8, maybe w/ subsection .\" other parameters are allowed: see man(7), man(1) -.TH EXIQGREP 8 "March 26, 2003" +.TH EXIQGREP 8 "January 27, 2022" .\" Please adjust this date whenever revising the manpage. .\" .\" Some roff macros, for reference: @@ -21,7 +21,8 @@ exiqgrep \- Search in the exim queue .SH SYNOPSIS .B exiqgrep -.I [\-a] [\-c] +.I [\-h] [\-C file] [\-f regexp] [\-r regexp] [\-s regexp] [\-y seconds] +[\-o seconds] [\-z] [\-x] [\-G queuename] [\-c] [\-l] [\-i] [\-b] [\-R] [\-a] .SH DESCRIPTION The @@ -35,6 +36,9 @@ does not need to be invoked in a pipe. \fB\-h\fR Print help .TP +\fB\-C \fR +Specify which exim.conf to use +.TP \fB\-f \fR Match sender address (field is \(lq< >\(rq wrapped) .TP @@ -56,6 +60,9 @@ Frozen messages only (exclude non-frozen) \fB\-x\fR Non-frozen messages only (exclude frozen) .TP +\fB\-G \fR +Match in given queue only +.TP \fB\-c\fR Display match count .TP @@ -70,6 +77,9 @@ Brief Format .TP \fB\-R\fR Reverse order +.TP +\fB\-a\fR +All recipients (including delivered) .SH BUGS This manual page needs a major re-work. If somebody knows better groff
Bug#1004230: libgpuarray: please drop upstreamtestsclblas until bug 949767 is fixed
Hi, The latest failure (https://ci.debian.net/data/autopkgtest/unstable/armhf/libg/libgpuarray/18386433/log.gz) does not seem directly related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997908 as now multiple tests trigger a segfault: should we open another bug for that or can you confirm that it is related? FYI the same segfault happen in Ubuntu (https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/armhf/libg/libgpuarray/20220122_104616_37fcb@/log.gz). Thanks, Alex
Bug#1004427: openssh-server: Connection reset when trying to establish a connection on armhf
Package: openssh-server Version: 1:8.4p1-5 Severity: important X-Debbugs-Cc: benedikt.wildenh...@hs-bochum.de Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I installed openssh-server using taskel. * What was the outcome of this action? Trying to connect fails (also from external hosts): # ssh -v localhost OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k 25 Mar 2021 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: Connecting to localhost [::1] port 22. debug1: Connection established. debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa_sk type -1 debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: identity file /root/.ssh/id_ed25519_sk type -1 debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /root/.ssh/id_xmss type -1 debug1: identity file /root/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5 debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-5 debug1: match: OpenSSH_8.4p1 Debian-5 pat OpenSSH* compat 0x0400 debug1: Authenticating to localhost:22 as 'root' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: compression: none debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY journalctl -u ssh outputs the following at the same time (with Loglevel debug): Jan 27 14:48:31 jupiter sshd[3812]: debug1: Set /proc/self/oom_score_adj to 0 Jan 27 14:48:31 jupiter sshd[3812]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8 Jan 27 14:48:31 jupiter sshd[3812]: debug1: inetd sockets after dupping: 4, 4 Jan 27 14:48:31 jupiter sshd[3812]: Connection from 127.0.0.1 port 45200 on 127.0.0.1 port 22 rdomain "" Jan 27 14:48:31 jupiter sshd[3812]: debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5 Jan 27 14:48:31 jupiter sshd[3812]: debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-5 Jan 27 14:48:31 jupiter sshd[3812]: debug1: match: OpenSSH_8.4p1 Debian-5 pat OpenSSH* compat 0x0400 Jan 27 14:48:31 jupiter sshd[3812]: debug1: permanently_set_uid: 105/65534 [preauth] Jan 27 14:48:31 jupiter sshd[3812]: debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Jan 27 14:48:31 jupiter sshd[3812]: debug1: SSH2_MSG_KEXINIT sent [preauth] Jan 27 14:48:31 jupiter sshd[3812]: debug1: monitor_read_log: child log fd closed Jan 27 14:48:31 jupiter sshd[3812]: debug1: do_cleanup Jan 27 14:48:31 jupiter sshd[3812]: debug1: Killing privsep child 3813 Jan 27 14:48:31 jupiter sshd[3812]: debug1: audit_event: unhandled event 12 Jan 27 14:48:31 jupiter sshd[2759]: debug1: main_sigchld_handler: Child exited journalctl -k outputs: Jan 27 14:48:31 jupiter kernel: audit: type=1326 audit(1643291311.540:31): auid=4294967295 uid=105 gid=65534 ses=4294967295 subj==unconfined pid=3813 comm="sshd" exe="/usr/sbin/sshd" sig=31 arch=4028 syscall=413 compat=0 ip=0xb6a8e3c6 > * What outcome did you expect instead? I can authenticate against the server. Kind regards, Benedikt Wildenhain -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 5.15.0-3-armmp-lpae (SMP w/2 CPU threads) Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE Locale: LANG=eo, LC_CTYPE=eo (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-server depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.77 ii dpkg 1.20.9 ii libaudit1 1:3.0-2 ii libc6 2.33-3 ii libcom-err21.46.2-2 ii libcrypt1 1:4.4.18-4 ii libgssapi-krb5-2 1.18.3-6+deb11u1 ii libkrb5-3 1.18.3-6+deb11u1 ii libpam-modules 1.4.0-9+deb11u1 ii libpam-runtime 1.4.0-9+deb11u1 ii libpam0g 1.4.0-9+deb11u1 ii libselinux13.1-3 ii libssl1.1
