Bug#1012238: further information

[David Christensen]

bug 1012238:

Apparently, Thunderbird confused me and/or vice-versa.  After continuing 
to work with Thunderbird, including closing the application and then 
opening it again, the PDF attachments are now accessible.  My WAG is 
that Thunderbird was doing work in the background and I was driving the 
GUI faster than it could respond (?).



Please close the ticket.


David

Bug#1012241: dia: depends on libgtk2.0-dev

[Raphaël Halimi]

Package: dia
Version: 0.97.3+git20220525-1
Severity: minor

Hi,

The new dia package depends on libgtk2.0-dev, which itself depends on 
other headers packages, resulting in nearly 70 new packages to install 
on an upgrade of dia.


I may be wrong but I thought that binary packages are not supposed to 
depend on headers packages. I think this should be fixed.


Regards,

--
Raphaël Halimi


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012196: ITP: exaile/4.1.2-beta1-1 -- Exaile is a music player with a simple interface

[André Flechs]

The point is that we published the package with - on GitHub. So the 
watch test says there is a newer version available (as in upload #9). 
But finally I think we could publish a final 4.1.2 without beta.



Am 01.06.22 um 18:49 schrieb Bastian Germann:
Also, please keep the - to ~ conversion in the version string as with 
your previous updates.

The problem with 4.1.2-beta1-1 is that it is later than 4.1.2-1.

Please remove the Vcs-Git field when you do not maintain your package 
in git. This is not for the upstream Vcs.

Bug#1012240: winbind does not return AD groups a user is a member of AT ALL, or only one

[Matthew Grant]

Package: winbind
Version: 2:4.16.1+mag-1
Severity: important

Dear Maintainer,

I have rebuilt samba 4.16.1 packages as I am including a samba INTERNAL DNS
patch, bt I have not altered the packaging significantly other than this, and
have not touched winbind

I have been finding that when I login to the machine using a user from samba 
AD,with groups from samba AD, none of those AD groups that user is a member of
show up in the output from the 'groups' command.

Further more:

shalom: -root- [/home/admin] 
# wbinfo -r grantma
failed to call wbcGetGroups: WBC_ERR_DOMAIN_NOT_FOUND
Could not get groups for user grantma

And in the samba logs:

[2022/06/02 16:30:45.687576,  0] 
../../source3/winbindd/winbindd_samr.c:71(open_internal_samr_conn)
  open_internal_samr_conn: Could not connect to samr pipe: 
NT_STATUS_ACCESS_DENIED

The above works fine when the samba package is installed along with winbind.

After the call find that the following programs are running:

shalom: -root- [/home/admin] 
# ps -ef | grep samba
root  139564   1  0 16:29 ?00:00:00 
/usr/libexec/samba/samba-dcerpcd --libexec-rpcds --ready-signal-fd=40 
--np-helper --debuglevel=0
root  139574  139564  0 16:29 ?00:00:00 
/usr/libexec/samba/rpcd_lsad --configfile=/etc/samba/smb.conf --worker-group=4 
--worker-index=5 --debuglevel=0
root  139576  139564  0 16:29 ?00:00:00 
/usr/libexec/samba/rpcd_lsad --configfile=/etc/samba/smb.conf --worker-group=4 
--worker-index=6 --debuglevel=0
root  139578  139564  0 16:29 ?00:00:00 
/usr/libexec/samba/rpcd_lsad --configfile=/etc/samba/smb.conf --worker-group=4 
--worker-index=7 --debuglevel=0
root  139580  139564  0 16:29 ?00:00:00 
/usr/libexec/samba/rpcd_lsad --configfile=/etc/samba/smb.conf --worker-group=4 
--worker-index=8 --debuglevel=0
root  139583  136857  0 16:29 pts/500:00:00 grep samba

When the above binaries permisions are set by:

shalom: -root- [/home/admin] 
# chmod 400 /usr/libexec/samba/samba-dcerpcd /usr/libexec/samba/rpcd_lsad

the following happens:

shalom: -root- [/home/admin] 
# chmod 400 /usr/libexec/samba/samba-dcerpcd /usr/libexec/samba/rpcd_lsad

It appears that wind bind needs samba-dcerpcd and rpcd_lsad to function
correctly.  Could these binaries and dependent libraries be moved to the
winbind package please?

Thank you!

Matt Grant


-- Package-specific info:
* /etc/samba/smb.conf present, and attached
* /var/lib/samba/dhcp.conf not present

-- System Information:
Debian Release: 11.3
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.40-amd64-mag-lts (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages winbind depends on:
ii  init-system-helpers  1.60
ii  libbsd0  0.11.3-1
ii  libc62.31-13+deb11u3
ii  libgnutls30  3.7.1-5
ii  libldap-2.4-22.4.57+dfsg-3+deb11u1
ii  libpopt0 1.18-2
ii  libtalloc2   2.3.3+mag-1~0mag0
ii  libtdb1  1.4.6+mag-1
ii  libtevent0   0.11.0+mag-1~0mag0
ii  libwbclient0 2:4.16.1+mag-1
ii  lsb-base 11.1.0
ii  samba-common 2:4.16.1+mag-1
ii  samba-common-bin 2:4.16.1+mag-1
ii  samba-libs   2:4.16.1+mag-1

winbind recommends no packages.

Versions of packages winbind suggests:
ii  libnss-winbind  2:4.16.1+mag-1
ii  libpam-winbind  2:4.16.1+mag-1

-- no debconf information
[Global]
netbios name = SHALOM
realm = AD.ANATHOTH.NET
workgroup = AD
kerberos method = secrets and keytab
dedicated keytab file = /etc/krb5.keytab
server string = %h DebianLinux Host
security = ads
client signing = auto
server signing = auto

# TLS setup
tls certfile = /etc/ipsec.d/certs/anathoth_shalom.ad.anathoth.net.crt
tls keyfile = /etc/ipsec.d/private/anathoth_shalom.ad.anathoth.net.key
tls cafile = /etc/ipsec.d/cacerts/anathoth_vpn_ca.crt

# Winbind settings
#
# Winbind idmap setup
idmap config * : backend = autorid
idmap config * : range = 20-200020
idmap config * : rangesize = 20
idmap config AD : backend = ad
idmap config AD : range = 1-5
idmap config AD : unix_primary_group = yes
idmap config AD : unix_nss_info = yes

# Winbind offline logon
winbind offline logon = no

winbind use default domain = yes
winbind enum users = no
winbind enum groups = no
winbind nested groups = yes
winbind refresh tickets = yes
winbind cache time = 300
template shell = /bin/bash
template homedir = /home/%D/%U

Bug#1012239: ITP: christianriesen-otp -- PHP library to check HOTP and TOTP one time passwords

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-de...@lists.debian.org, j...@nahmias.net, 
chris.rie...@gmail.com, pkg-php-p...@lists.alioth.debian.org

* Package name: christianriesen-otp
  Version : 1.4.3
  Upstream Author : Christian Riesen 
* URL : https://github.com/ChristianRiesen/otp
* License : MIT
  Programming Lang: PHP
  Description : PHP library to check HOTP and TOTP one time passwords

 Implements hotp according to RFC4226 and totp according to RFC6238 (only
 sha1 algorithm). Once you have a secret, you can use it directly in this
 class to create the passwords themselves (mainly for debugging use) or use
 the check functions to safely check the validity of the keys. The checkTotp
 function also includes a helper to battle timedrift.
 .
 Also includes a static GoogleAuthenticator function class to generate a
 correct url for the QR code, so you can easy scan it with your device.
 Google Authenticator is available as application for iPhone and Android.
 This removes the burden to create such an app from the developers of
 websites by using this set of classes.

Dependency of KanBoard.
Will be maintained within PHP Team.

Bug#1012231: tinyows: FTBFS: problems with boolean types and constants

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/MapServer/tinyows/issues/98

On 6/2/22 02:00, Andreas Beckmann wrote:

tinyows recently started to FTBFS after some build-dependency got
updated:


Thanks for reporting this issue, I've forwarded it upstream.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1012238: thunderbird: Thunderbird is destroying attachments

[David Christensen]

Package: thunderbird
Version: 1:91.9.0-1~deb11u1
Severity: important
X-Debbugs-Cc: dpchr...@holgerdanske.com

Dear Maintainer,

I double-clicked on a PDF attachment to an e-mail.  Thunderbird opened
the attachment in another tab.  I closed Thunderbird.  When I opened
Thunderbird again, the tab that had the PDF document was empty and the
attachment to the e-mail is gone.


I have experienced similar problems with Thunderbird in the past, so
I implemented a rule to make copies of incoming mails to another
folder.  When I went to this other folder, selected the message, right-
clicked, and copied the message to my inbox, the rule fired again
and the attachment was destroyed in all four copies of the message!


David



-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-14-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.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 thunderbird depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libbotan-2-172.17.3+dfsg-2
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13+deb11u3
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libjson-c5   0.15-2
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.3-1.1
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.4-2
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.11.dfsg-2+deb11u1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2019.10.06-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.6-10
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.18.3-6+deb11u1

-- no debconf information

Bug#1012236: mirror submission for mirror.01link.hk

[Host Master]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.01link.hk
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Maintainer: Host Master 
Country: AF Afghanistan
Location: Hong Kong
Sponsor: 01Link Network Services Ltd https://www.01link.net




Trace Url: http://mirror.01link.hk/debian/project/trace/
Trace Url: http://mirror.01link.hk/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.01link.hk/debian/project/trace/mirror.01link.hk

Bug#1012237: mirror submission for mirror.01link.hk

[Host Master]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.01link.hk
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Maintainer: Host Master 
Country: HK Hong Kong
Location: Hong Kong
Sponsor: 01Link Network Services Ltd https://www.01link.net




Trace Url: http://mirror.01link.hk/debian/project/trace/
Trace Url: http://mirror.01link.hk/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.01link.hk/debian/project/trace/mirror.01link.hk

Bug#1010883: dkms breaks nvidia-graphics-drivers autopkgtest on arm64: unmet dependencies

[Andreas Beckmann]

On 27/05/2022 16.22, Andreas Beckmann wrote:
> On 27/05/2022 10.59, Paul Gevers wrote:
>>> My guess is that apt pinning comes into play here, installing
>>
>> That aligns with my suspicion that it's related to the mixing of
>> unstable and testing.
> 
> Uploaded a first attempt on the fix. Works for me, let's see how ci.d.o
> likes it. There are probably still corner cases to be handled ...

Looks not too bad.

Current problems:

lime-forensics: used dkms-autopkgtest manually, not via
  Testsuite: autopkgtest-pkg-dkms
merge-request !2
(only autopkgtest buggy, module builds fine)

r8125: bug #1012014 - r8125: fails to build module for Linux 5.17
(new upstream release available)

nvidia-graphics-drivers-tesla-470: fails on ppc64el due to transitive
GPL symbol usage, reported upstream

nvidia-graphics-drivers-tesla-510: improved version in experimental, but
has the same problem on ppc64el as 470 (not yet in sid due to moving a
package from nvidia-graphics-drivers to -tesla-510)
feel free to temporarily remove from testing

Since these bugs (modules failing to build) are already present in
testing and only exposed by the new dkms by making the autopkgtest run
no longer a no-op, perhaps you could just ignore the failing tests and
hint dkms into testing? (-tesla-510 would need some forced hint for
reintroduction into testing as well, since I don't think an upstream fix
for ppc64el will be available in time when I move
nvidia-graphics-drivers from 470 to 510 as default in sid)


Andreas

Bug#992786: passenger uses many vendored libraries

[Antonio Terceiro]

Control: severity -1 important

Hi,

On Mon, Aug 23, 2021 at 03:00:16PM +0300, Adrian Bunk wrote:
> Source: passenger
> Severity: serious
> 
> passenger-5.0.30/src/cxx_supportlib/vendor-copy:
> adhoc_lve.h  libcurl  libuv  nghttp2  utf8  utf8.h
> 
> passenger-5.0.30/src/cxx_supportlib/vendor-modified:
> SmallVector.h  jsoncpp  modp_b64.cpp  modp_b64_data.h
> boost  libevmodp_b64.hpsg_sysqueue.h
> 
> passenger-6.0.10/src/cxx_supportlib/vendor-copy:
> adhoc_lve.h  libuv  utf8  utf8.h  websocketpp
> 
> passenger-6.0.10/src/cxx_supportlib/vendor-modified:
> boostlibev modp_b64.h   modp_b64_strict_aliasing.cpp
> jsoncpp  modp_b64.cpp  modp_b64_data.h  psg_sysqueue.h
> 
> 
> The problem is that these vendored copies seem to actually be used.
> 
> Does for example CVE-2021-22918 in libuv1 need fixing in passenger?

6.0.13+ds-1 drops the embedded copies of both libuv and libev, who seem
to be the most high-profile libraries; and it's now actually possible to
build passenger against system-provided copies of those.

There is still an embeded copy of boost, but that's modified from
upstream boost in a way that the code does not build about system boost.

Ideally we would want to drop all of the other embeded copies, but
realistically that would involve a amount of work that is not available
at the moment.

Because this is still a relevant issue, but IMO not worth removing
passenger because of it, I am downgrading this bug to important.


signature.asc
Description: PGP signature

Bug#1012235: lintian: check validity of autopkgtest names

[Andreas Beckmann]

Package: lintian
Version: 2.114.0
Severity: normal

I had this stanza in d/tests/control (src:libthrust):

  Test-Command: debian/tests/upstream-testsuite CPP/CUDA 17 g++-10
  Features: test-name=compile_testsuite_CPP/CUDA_C++17_g++-10
  ...

but autopkgtest doesn't like that and returns
 
  compile_testsuite_CPP/CUDA_C++17_g++-10 SKIP test name may not contain / 
character


Please add a lintian check for the validity of

  Features: test-name=...


Andreas

Bug#1007222: transition: onetbb

[M. Zhou]

On Wed, 2022-06-01 at 20:29 +0200, Graham Inggs wrote:
> Control: tags -1 + moreinfo
> 
> I noticed some packages in the tracker not appearing in your list;
> e.g. openimageio, pcl and yade.  These packages have transitive
> build-dependencies on libtbb-dev through e.g. libopenvdb-dev or
> libvtk9-dev, and should be investigated as well.

My bad. So solely `reverse-depends -b` may miss something. I'll
investigate and append results to the transition bug.

> Note that we will require fixes, or at least patches, for "key
> packages" [1] before starting with this transition, and at least
> trilinos is currently on that list.
> 
> It may be worth considering again Matthias' suggestion in #1006920 to
> keep the old tbb package around as libtbb2-dev and libtbb2-doc in
> order to allow packages like numba to get the new tbb soon, and other
> packages stuck with the old tbb more time to get fixed.

I personally dislike making the old package libtbb2-dev.
How about we make the old src:tbb package go through NEW again
with the following renames:

libtbb-dev -> libtbb-legacy-dev, this sounds much better than libtbb2-dev
  because it explains itself to be a to-be-deprecated version.

In this way we can finish the transition very quickly and leave
longer time for broken packages to migrate to onetbb.

For me, submitting patches is as well much easier as I only have to
change libtbb-dev -> libtbb-legacy-dev for broken packages.

Bug#1012234: reportbug: please redirect bugs against the 'general' psuedo-package to the Debian support web page

[Paul Wise]

Package: reportbug
Severity: wishlist

Bugs reported against the 'general' pseudo-package are usually of very
low quality and are usually not actionable, except to close the bug and
ask the submitter to discuss the problem with Debian support folks.

When the user does start reportbug without a package name, reportbug
has some features to redirect bugs reported against 'general' to the
Debian support channels, but these features aren't not applied if the
user specifically does `reportbug general`. I think it might help
reduce the amount of off-topic mail on debian-devel to include the
redirect features in `reportbug general` too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1012233: python3-ml-collections: overly generic python module name: /usr/lib/python3/dist-packages/docs/conf.py

[Andreas Beckmann]

Package: python3-ml-collections
Version: 0.1.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package uses a very generic
python module name that now clashes with other packages:

/usr/lib/python3/dist-packages/docs/conf.py


Andreas

Bug#998820: lintian: overly generic python modules /usr/lib/python3/dist-packages/benchmarks/*.py

[Andreas Beckmann]

Followup-For: Bug #998820

Please add this file to the list of overly generic python modules, too:

/usr/lib/python3/dist-packages/docs/conf.py


Andreas

Bug#1012167: ITP: haskell-tz -- Efficient time zone handling

[Paul Wise]

On Tue, 2022-05-31 at 20:15 +, Robert Greener wrote:

> I've patched haskell-tzdata (where haskell-tz gets the data from) so
> that it uses the system files instead of supplying them. So it should
> be ok.

Are the system files used at build time or at runtime? After an update
of the tzdata source/binary packages, will haskell-tzdata, haskell-tz
or any packages depending on them need a rebuild?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1012227: general: CPU usage is 50% or higher with WebKitWebProcess

[Paul Wise]

Control: reassign -1 libwebkit2gtk-4.0-37
Control: retitle -1 webkitgtk: CPU usage is 50% or higher with WebKitWebProcess

On Wed, 2022-06-01 at 14:57 -0500, Tim McConnell wrote:

> WebKitWebProcess will use 50% of CPU by itself and will often take
> the CPU usage to 100%

Bugs in WebKit should not be reported against 'general', but against
the appropriate WebKit package, reassigning the bug.

The webkit-help mailing list or the WebKit IRC/Matrix channel can
probably help you figure out why this is occurring and what workarounds
that you might be able to try.

https://webkitgtk.org/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1012232: freespace2: FTBFS: ./configure: line 17040: syntax error near unexpected token `ax_cxx_compile_cxx11_required=falsednl'

[Andreas Beckmann]

Source: freespace2
Version: 3.7.4+repack-1.1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source

Hi,

freespace2 recently started to FTBFS after some (transitive) build
dependency got updated:

[...]
checking how to hardcode library paths into programs... immediate
./configure: line 17040: syntax error near unexpected token 
`ax_cxx_compile_cxx11_required=falsednl'
./configure: line 17040: `ax_cxx_compile_cxx11_required=falsednl'
[...]


Andreas


freespace2_3.7.4+repack-1.1.log.gz
Description: application/gzip

Bug#965348: schroot: [INTL:pt] Initial Portuguese translation of manpage

[Américo Monteiro]

A segunda-feira, 30 de maio de 2022 18:44:54 WEST Christoph Biedl escreveu:
> Control: tags 965348 moreinfo
> 
> Américo Monteiro wrote...
> 
> > Updated Portuguese translation for  schroot's manpage
> > Translator: Américo Monteiro 
> > Feel free to use it.
> 
> Bom dia,
> 
> schroot 1.6.10-13 (uploaded yesterday) had a few changes to the related
> input files. Can you please review the translation and provide an
> updated version? I'll be happy to include them then.
> 
> (My Português is too rusty to use it in this message.)
> 
> Christoph

Hi

version 1.6.10-13 of manpage updated

Regards
Américo


schroot_1.6.10-13_schroot-man.pt.po.gz
Description: application/gzip

Bug#1012231: tinyows: FTBFS: problems with boolean types and constants

[Andreas Beckmann]

Source: tinyows
Version: 1.2.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

tinyows recently started to FTBFS after some build-dependency got
updated:

   dh_auto_build
make -j3
make[1]: Entering directory '/build/tinyows-1.2.0'
gcc -g -O2 -ffile-prefix-map=/build/tinyows-1.2.0=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=c99 -pedantic -Wall -I/usr/include/postgre
sql -I/usr/include/libxml2   src/fe/fe_comparison_ops.c src/fe/fe_error.c 
src/fe/fe_filter.c src/fe/fe_filter_capabilities.c src/fe/fe_function.c 
src/fe/fe_logical_ops.c src/fe/fe_spatial_ops.c src/mapfile/mapfile
.c src/ows/ows_bbox.c src/ows/ows.c src/ows/ows_config.c src/ows/ows_error.c 
src/ows/ows_geobbox.c src/ows/ows_get_capabilities.c src/ows/ows_layer.c 
src/ows/ows_metadata.c src/ows/ows_psql.c src/ows/ows_request.c
 src/ows/ows_srs.c src/ows/ows_storage.c src/ows/ows_version.c 
src/struct/alist.c src/struct/array.c src/struct/buffer.c 
src/struct/cgi_request.c src/struct/list.c src/struct/mlist.c 
src/struct/regexp.c src/wfs/wf
s_describe.c src/wfs/wfs_error.c src/wfs/wfs_get_capabilities.c 
src/wfs/wfs_get_feature.c src/wfs/wfs_request.c src/wfs/wfs_transaction.c 
src/ows/ows_libxml.c -o tinyows -lfl -L/usr/lib/x86_64-linux-gnu -lpq -lxml
2 -lfcgi
In file included from /usr/include/unicode/umachine.h:52,
 from /usr/include/unicode/utypes.h:38,
 from /usr/include/unicode/ucnv_err.h:88,
 from /usr/include/unicode/ucnv.h:51,
 from /usr/include/libxml2/libxml/encoding.h:31,
 from /usr/include/libxml2/libxml/parser.h:812,
 from /usr/include/libxml2/libxml/globals.h:18,
 from /usr/include/libxml2/libxml/threads.h:35,
 from /usr/include/libxml2/libxml/xmlmemory.h:218,
 from /usr/include/libxml2/libxml/tree.h:1307,
 from /usr/include/libxml2/libxml/xmlreader.h:14,
 from src/fe/../ows/ows.h:30,
 from src/fe/fe_comparison_ops.c:29:
src/fe/../ows/../ows_struct.h:33:3: error: expected identifier before numeric 
constant
   33 |   false,
  |   ^
src/fe/../ows/../ows_struct.h:37:19: error: two or more data types in 
declaration specifiers
   37 | typedef enum Bool bool;
  |   ^~~~
In file included from src/fe/../ows/ows.h:38,
 from src/fe/fe_comparison_ops.c:29:
src/fe/../ows/../ows_struct.h:37:14: warning: empty declaration with storage 
class specifier does not redeclare tag
   37 | typedef enum Bool bool;
  |  ^~~~
[...]


Andreas


tinyows_1.2.0-1.log.gz
Description: application/gzip

Bug#1012230: systemd: emergency target fails to stop journald

[westlake]

Package: systemd
Version: 247.3
Severity: normal

"systemctl isolate emergency" fails to stop systemd-journald..

it's not an upstream issue since the problem does not occurr with other 
distributions.


having systemd-journald to be stopped is desirable since the 
administrator can then use e2fsck to repair filesystems(after the 
problematic filesystem read-only -- "mount -o ro,remount /" for instance)


upstream won't look into this because it is not happening on other 
distributions.


please take a look
thanks

Bug#1011545: [Debian Bug Tracking System] Bug#1011545 closed by Debian FTP Masters (reply to Anthony Fok ) (Bug#1011545: fixed in gh 2.4.0+dfsg1-3)

[Anthony Fok]

Control: reopen -1
Control: severity -1 important

Hi Antoine!

Thank you for your quick response!

On Tue, May 31, 2022 at 9:58 AM Antoine Beaupré  wrote:
>
> Hum. Now I'm a little confused: why did you do this?
>
> * Add diversion for /usr/bin/gh to allow concurrent install with gitsome
>   and remove Conflicts with gitsome. This is inspired by the conflict
>   resolution between the moreutils and parallel packages where both
>   contain /usr/bin/parallel.  See discussions in #749355.

This is an idea that has been brewing in my mind some weeks ever since
I came to realize Debian has two "parallel" programs while working on
, and thought
to myself, if moreutils and (GNU) parallel can do it, why can't
gitsome and (GitHub's) gh?

But I was too busy with work, and also not sure how to break the file
conflict deadlock in #1005858 (especially with the manual block to
both packages), so I didn't act on it.
Many thanks to you for getting us out of that embarrassing situation!

So, as I was dealing with this new bug that you opened, my old idea
came back to me again, I decided to give it a try, for better or for
worse.  The changelog is a reflection of the Git commits that I made
in that order...  

> This seems like it's the opposite of what I was suggesting in the bug
> report (#1011545). And you even refer to that bug report in the
> changelog:
>
> * Limit "Conflicts: gitsome" to older (<< 0.8.0+ds-7.1) versions.
>   Thanks to Antoine Beaupre for the suggestion, and for resolving the
>   file conflict with gitsome (#1005858) so amicably! (Closes: #1011545)
>
> What actually happened, from what I can tell, is that you just removed
> the Conflicts... I don't think that's the right resolution here: gitsome
> has been fixed, in unstable, and gh doesn't need to go around with fancy
> diversion stuff, because we're *precisely* not in a situation like
> moreutils and parallel...

Thank you for clarifying to me that it is a different situation than
moreutils and parallel.

>From my understanding of the gitsome, the "gitsome" command itself is
mostly just a wrapper that calls xonsh, and gitsome's main
functionalities are actually in the "/usr/bin/gh" Python executable,
so perhaps removing /usr/bin/gh altogether in some sense cripples the
gitsome package, and a rename to /usr/bin/gh.gitsome or something else
would be more appropriate.

That said, I now agree with you that renaming gitsome's /usr/bin/gh
via dpkg-divert from GitHub CLI gh package is not the right way to go,
particularly because the /usr/bin/gh meaning different things
depending on which packages are installed (just gitsome or both
gitsome and gh) can be very confusing.)

> Could this change be reverted?

Yes, most definitely!  I will do it ASAP.

After that, I will probably try to work on the gitsome package too and
install its gh as /usr/bin/gh.gitsome and hopefully get its
command-line completion to work with the name change, but that's
unrelated to this particular bug report and to GitHub CLI gh.  Let's
keep this package clean and free of the fancy and confusing diversion
stuff.  :-)

Thanks again for writing to me and put some common sense back into me!

Cheers,

Anthony Fok


> --
> When I came back to the United States, I decided that if you could use
> propaganda for war, you could certainly use it for peace. And
> "propaganda" got to be a bad word because of the Germans using it, so
> what I did was to try and find some other words so we found the words
> "public relations".  - Edward Bernays
>
>
>
>
>
> -- Forwarded message --
> From: Debian Bug Tracking System 
> To: Antoine Beaupre 
> Cc:
> Bcc:
> Date: Tue, 31 May 2022 15:51:05 +
> Subject: Bug#1011545 closed by Debian FTP Masters 
>  (reply to Anthony Fok ) 
> (Bug#1011545: fixed in gh 2.4.0+dfsg1-3)
> This is an automatic notification regarding your Bug report
> which was filed against the gh package:
>
> #1011545: please version the Conflicts: with gitsome
>
> It has been closed by Debian FTP Masters  
> (reply to Anthony Fok ).
>
> 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 Anthony Fok ) by
> replying to this email.
>
>
> --
> 1011545: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011545
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 1011545-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 31 May 2022 15:49:21 +
> Subject: Bug#1011545: fixed in gh 2.4.0+dfsg1-3
> Source: gh
> Source-Version: 2.4.0+dfsg1-3
> Done: Anthony Fok 
>
> We believe that the bug you reported is fixed in the latest version of
> gh, which is due to be installed in the Debian FTP archive.
>
> A summary of the 

Bug#1012152: firmware-amd-graphics: All firmware are included in initrd even in dep mode

[Ben Hutchings]

Control: reassign -1 src:initramfs-tools

On Mon, 2022-05-30 at 23:04 +0200, Adrien CLERC wrote:
> Package: firmware-amd-graphics
> Version: 20210818-1
> Severity: minor
> 
> Dear Maintainer,
> 
> Since the integration of built-in drivers in initramfs-tools (see
> https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/35),
> firmware files are also included with the corresponding kernel module.
> I don't know why, but it only hits my system (AMD Ryzen PRO 4750G) since 
> May,
> 7th with Linux 5.17.0. Before that, amdgpu was NOT included in the initrd.
>
> Now that it's included, it brings all firmwares for all AMD graphics card,
> making the initrd from 11MB to 38MB.
[...]

This really is unfortunate, but the way you've tried to fix wouldn't
work in general:

- Not all drivers log in the same way (at least in the upstream kernel)
- Those messages may have been expired from the kernel message buffer
  when mkinitramfs runs
- The firmware files requested by a driver can change between kernel
  versions

To solve this we would need kernel drivers to specify a mapping between
device IDs and firmware files.

One thing we could perhaps do in initramfs-tools is to add a
configuration variable that lets you override which firmware files get
included (like MODULES=list, but for firmware).  Would that work for
you?

Ben.

-- 
Ben Hutchings
Horngren's Observation:
  Among economists, the real world is often a special case.


signature.asc
Description: This is a digitally signed message part

Bug#1012018: texlive-bin: FTBFS during separate binary-indep build

[Hilmar Preuße]

Am 28.05.2022 um 21:53 teilte Andreas Beckmann mit:

Hi,


Looks like you need to move some bits that are irrelevant for the
binary-indep build to a override_dh_install-arch (or probably
better execute_after_dh_install-arch) target.

Our build system did not change between TL 2021 & 2022. The only 
difference is, that we introduced some transitional packages, which are 
of arch "all" and hence the sbuild is started for arch "all". Now the 
d/rules files makes some assumption about, which files are there after 
build, which differs between arch "any" and "all".
What would work is to convert the transitional packages into arch "any", 
but I'm pretty sure some people would not like the idea.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011346: Enabling V4L2 Driver in Chromium Builds

[Bastian Germann]

I second this request.

Bug#1012228: rar: new upstream version with security fix

[Bastian Germann]

Package: rar
Severity: important
Version: 2:6.11-0.1
X-Debbugs-Cc: t...@security.debian.org

The whatsnew file says for Version 6.12:

   1. Security vulnerability allowing to create unpacked files outside
  of destination directory is fixed. This issue exists in Unix RAR only
  and doesn't affect WinRAR and Android RAR.

So please import the new version.

Bug#1012227: general: CPU usage is 50% or higher with WebKitWebProcess

[Tim McConnell]

Package: general
Severity: important
X-Debbugs-Cc: tmcconnell...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?Unsure, I've been having this issue for a
while now
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Don't know other than keeping my system up to date
   * What was the outcome of this action? WebKitWebProcess will use 50% of CPU
by itself and will often take the CPU usage to 100%
   * What outcome did you expect instead?Lower CPU usage

*** End of the template - remove these template lines ***

Bug#1012073: perl: restoring default signal handler may warn with 'SIGTERM handler "DEFAULT" not defined'

[Damyan Ivanov]

-=| Niko Tyni, 30.05.2022 09:27:40 +0100 |=-
> On Sun, May 29, 2022 at 05:38:40PM +, Damyan Ivanov wrote:
> > Package: perl
> > Version: 5.34.0-4
> > Severity: normal
> 
> > While infestigating a random FTBFS in starlet (#923829), it appeared to me 
> > that 
> > the problem is actually in perl.
> 
> > #   Failed test 'No warnings'
> > #   at t/12bad_request_line.t line 24.
> > # SIGTERM handler "DEFAULT" not defined.
> > #  at /usr/share/perl5/Parallel/Prefork.pm line 71.
> > #   Parallel::Prefork::start(Parallel::Prefork=HASH(0x55cd856355b8)) called 
> > at .../lib/Plack/Handler/Starlet.pm line 78
> > #   
> > Plack::Handler::Starlet::run(Plack::Handler::Starlet=HASH(0x55cd849b0ad8), 
> > CODE(0x55cd8562ac98)) called at t/12bad_request_line.t line 28
> 
> Just a quick reply that a smaller reproducer would obviously help.

Yeah. Sorry about that. When I posted this I was already a bit tired 
chasing where the warning comes from.

Here's a cleaner reproducer:

$ cat <<'EOF' > default-signal.pl
use strict;
use warnings;
use Carp::Always;   # to get a line number for the warning

$SIG{TERM} = sub{};
while() {
my $pid = fork();
defined($pid) or die 0;

if ($pid) {
sleep(0.1);
kill TERM => $pid;
wait;
}
else {
$SIG{TERM} = "DEFAULT";
exit(0);
}
}
EOF

$ perl default-signal.pl
SIGTERM handler "DEFAULT" not defined.
 at default-signal.pl line 16.
…

On my laptop the warnings start to pour in a second or two.

If I comment out that sleep(), no warnings are shown.

> FWIW this looks somewhat similar to
> 
> https://github.com/perl/perl5/issues/10913
> 
> but I assume the 'prefork' references mean threads are not involved
> here. So perhaps unrelated after all.

This is what I looked at too and came to the same conclusion (threads 
≠ forks).


-- Damyan

Bug#1012226: unattended-upgrades: flaky autopkgtest: kernel-patterns seems to regularly get confused

[Paul Gevers]

Source: unattended-upgrades
Version: 2.8
Severity: serious

Dear maintainer,

unattended-upgrades showed up in the stable-proposed queue viewer [1]
because it appears to regress with the new xz-utils. However,
inspecing other failures in other suites, I think the test doesn't
behave well in archives where there are more than one version of
src:linux available. This happens regularly in pure unstable, in
unstable-to-testing and in stable-proposed-to-stable testing.

Can you please have a look? Because the unstable-to-testing migration
software now blocks on regressions in testing, flaky tests, i.e. tests
that flip between passing and failing without changes to the list of
installed packages, are causing people unrelated to your package to
spend time on these tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul 

[1] https://release.debian.org/proposed-updates/stable.html

Bug#1012018: texlive-bin: FTBFS during separate binary-indep build

[Hilmar Preuße]

Am 28.05.2022 um 21:53 teilte Andreas Beckmann mit:

Hi Andreas,


texlive-bin fails to build the arch-indep packages during a separate run
as would be done by the buildds.

Many thanks for the report! Unfortunately it came to me very late as the 
mailing list does not like large E-Mails containing build logs. Please 
avoid attaching large log files.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#900799: linux-image-arm64: dts: rockchip: correct voltage selector Firefly-RK3399

[Diederik de Haas]

On Wednesday, 1 June 2022 19:04:27 CEST Heinrich Schuchardt wrote:
> On 6/1/22 11:28, Diederik de Haas wrote:
> > On Fri, 22 Jun 2018 21:58:30 +0100 Ben Hutchings  
wrote:
> >> Version: 4.17.2-1~exp1
> >> 
> >> On 5 Jun 2018 07:33:11 +0200 Heinrich Schuchardt  
wrote:
> >>> Please, add this patch to the Debian kernel patches until it is added
> >>> upstream. Cf.
> >>> https://lkml.org/lkml/2018/6/4/781
> >> 
> >> This was applied in the above merge but not mentioned in the changelog
> >> due to a mis-merge.
> > 
> > In response Heiko says in https://lkml.org/lkml/2018/6/19/1167:
> > "and dropped again.
> > 
> > Sadly it looks like the patch causes conflicts with at least one firefly
> > board in a kernelci lab. My own is currently not ready to use, so I cannot
> > look myself right now.
> > 
> > The issue kernelci people described sounded quite a lot like the one
> > in your commit message, so my current theory is that the
> > suspend-voltage-selector must in some form corespond to the
> > cpu_b_sleep_h gpio setting we're currently not handling at all, which
> > would therefore depend on how the bootloader sets this up."
> > 
> > It's also not part of current upstream master, so this is a DTS change
> > that is specific for Debian and possibly not needed and/or incorrect?
> > 
> > Heinrich, can you tell us more about the current status of this patch?
> 
> I have not been working on the board in the last years.
> 
> My impression at the time was that one would have to detect the current
> state of the board at runtime which matches what you wrote.

Thanks for your response.
FTR: It was all part of Heiko's quote; I have no insight in this matter.

Normally, AIUI, patches like these are added in expectation that they can be 
dropped later when it's merged into upstream source code.
As that did not happen in this case I think it would be better to just drop 
this patch from the Debian kernel.

It may be that upstream has fixed this issue in another way (I have no idea 
whether this is the case). And if the issue resurfaces again (against a 
current kernel), then we can see whether this patch would fix it (again) and 
then we'd have a better case to actually get it integrated in the upstream 
source.

But that's a decision that one of the Debian kernel maintainers should make.

Cheers,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Bug#1012225: src:xwayland: fails to migrate to testing for too long: unresolved RC bug

[Paul Gevers]

Source: xwayland
Version: 2:22.1.0-1
Severity: serious
Control: close -1 2:22.1.1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1008992

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:xwayland has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. The migration of your package is 
blocked by an unresolved RC bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=xwayland



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012215: gradle-debian-helper: unknown option --add-opens breaks OpenJDK 11 packages

[Markus Koschany]

Am Mittwoch, dem 01.06.2022 um 17:36 +0200 schrieb Emmanuel Bourg:
> gradle-debian-helper/2.2 already checks if the JDK supports modules before
> adding the --add-opens options, but it checks the default JDK and not the one
> specified by JAVA_HOME, that's why it fails when OpenJDK 8 is used.

ok, cool. Thanks for fixing it!


signature.asc
Description: This is a digitally signed message part

Bug#1012215: gradle-debian-helper: unknown option --add-opens breaks OpenJDK 11 packages

[Emmanuel Bourg]

gradle-debian-helper/2.2 already checks if the JDK supports modules before 
adding the --add-opens options, but it checks the default JDK and not the one 
specified by JAVA_HOME, that's why it fails when OpenJDK 8 is used.

Bug#1012077: add one riscv CPU info for linuxinfo package, T-HEAD XuanTie C910

[Helge Kreutzmann]

Hello all,
I'll work on this at the weekend, thanks for providing the
information, it is highly helpful!

Best greetings

 Helge



-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1007222: transition: onetbb

[Graham Inggs]

Control: tags -1 + moreinfo

Hi

I noticed some packages in the tracker not appearing in your list;
e.g. openimageio, pcl and yade.  These packages have transitive
build-dependencies on libtbb-dev through e.g. libopenvdb-dev or
libvtk9-dev, and should be investigated as well.

Note that we will require fixes, or at least patches, for "key
packages" [1] before starting with this transition, and at least
trilinos is currently on that list.

It may be worth considering again Matthias' suggestion in #1006920 to
keep the old tbb package around as libtbb2-dev and libtbb2-doc in
order to allow packages like numba to get the new tbb soon, and other
packages stuck with the old tbb more time to get fixed.

Regards
Graham


[1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#951354: wget2: Please package new version (1.99.2)

[Boyuan Yang]

X-Debbugs-CC: n...@debian.org

Hi Noel,

I believe the a upstream version 2.0.1 was just released. It has been more
than 4 years since last maintainer upload; are you still going to maintain
wget2 in Debian? If not, please feel free to let us know so that others can
work on it and package new versions.

Thanks,
Boyuan Yang

On Sat, 08 Jan 2022 18:59:56 -0500 Boyuan Yang  wrote:
> X-Debbugs-CC: n...@debian.org
> 
> Dear maintainer,
> 
> It has been a while; is there any update on packaging new wget2? If you are
in
> lack of time doing packaging, please let us know so that those interested
can
> have a chance to step in.
> 
> Thanks,
> Boyuan Yang
> 
> On Fri, 15 Oct 2021 16:34:47 -0400 Boyuan Yang  wrote:
> > Control: retitle -1 wget2: Please package new 2.0.0 version
> > 
> > On Fri, 14 Feb 2020 22:22:36 -0500 Boyuan Yang  wrote:
> > > Source: wget2
> > > Version: 1.99.1-2.1
> > > Severity: normal
> > > 
> > > Dear wget2 maintainer,
> > > 
> > > A new release of wget2 (wget2 1.99.1) is now available. Please consider
> > > packaging it in Debian. Thanks!
> > 
> > Dear Debian wget2 packge maintainer,
> > 
> > The upstream has released the 2.0.0 new version. Please consider packaging
> it
> > in Debian. Thanks!
> > 
> > Regards,
> > Boyuan Yang
> 



signature.asc
Description: This is a digitally signed message part

Bug#1012224: python-tornado: autopkgtest regression in testing

[Graham Inggs]

Source: python-tornado
Version: 6.1.0-3
Severity: serious
Tags: ftbfs
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Sometime around 2022-05-08, python-tornado's autopkgtests regressed in
testing [1].
I've copied what I hope is the relevant part below.

The package also now FTBFS on reproducible builds [2] with the same error.

Regards
Graham


[1] https://ci.debian.net/packages/p/python-tornado/testing/amd64/
[2] https://tests.reproducible-builds.org/debian/rb-pkg/python-tornado.html


==
ERROR: test_multi_line_headers
(tornado.test.curl_httpclient_test.CurlHTTPClientCommonTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/tornado/testing.py", line 98, in __call__
result = self.orig_method(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/tornado/test/httpclient_test.py",
line 534, in test_multi_line_headers
resp = self.fetch("http://127.0.0.1:%d/; % port)
  File "/usr/lib/python3/dist-packages/tornado/testing.py", line 443, in fetch
return self.io_loop.run_sync(
  File "/usr/lib/python3/dist-packages/tornado/ioloop.py", line 530, in run_sync
return future_cell[0].result()
tornado.curl_httpclient.CurlError: HTTP 599: Header without colon

--
Ran 1167 tests in 16.585s

FAILED (errors=1, skipped=6)
Some tests were skipped because: Prevent internet access during build,
needs fix, no testable future imports, pycares module not present

Bug#1012223: transition: ace

[Sudip Mukherjee]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Hi,

Small transition with only two affected packages: diagnostics, ivtools,
Both of them builds fine with ace 7.0.7+dfsg-1 version in experimental.

The autogenerated ben tracker looks good. Please consider 'ace' for
transition.
Thanks in advance.


--
Regards
Sudip

Bug#1005650: squid: FTBFS with OpenSSL 3.0

[Nicholas Guriev]

Control: tags -1 patch

Hello everyone interested!

To fix FTBFS of the squid package, I offer to apply my changes with the
-Wno-error=deprecated-declarations flag and an original patch. This will
allow us to proceed with the OpenSSL transition.

See also my MR on Salsa.
https://salsa.debian.org/squid-team/squid/-/merge_requests/20

diff -Nru squid-5.5/debian/changelog squid-5.5/debian/changelog
--- squid-5.5/debian/changelog	2022-04-15 15:39:54.0 +0300
+++ squid-5.5/debian/changelog	2022-05-31 23:13:38.0 +0300
@@ -1,3 +1,23 @@
+squid (5.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Nicholas Guriev ]
+  * Fixing build against OpenSSL 3.0 (Closes: #1005650, LP: #1946205)
+
+  * debian/rules
+- Do not fail on errors about deprecated declarations from OpenSSL.
+- Remove -Wall in CFLAGS from the debian/rules file since upstream build
+  scripts already pass this flag.
+
+  * debian/patches/
+- New 0006-Fix-build-against-OpenSSL-3-0.patch
+
+  [ Simon Deziel ]
+  * apparmor: allow reading /etc/ssl/openssl.cnf
+
+ -- Nicholas Guriev   Tue, 31 May 2022 23:13:38 +0300
+
 squid (5.5-1) unstable; urgency=medium
 
   [ Amos Jeffries  ]
diff -Nru squid-5.5/debian/patches/0006-Fix-build-against-OpenSSL-3-0.patch squid-5.5/debian/patches/0006-Fix-build-against-OpenSSL-3-0.patch
--- squid-5.5/debian/patches/0006-Fix-build-against-OpenSSL-3-0.patch	1970-01-01 03:00:00.0 +0300
+++ squid-5.5/debian/patches/0006-Fix-build-against-OpenSSL-3-0.patch	2022-05-31 22:31:08.0 +0300
@@ -0,0 +1,210 @@
+From: Nicholas Guriev 
+Date: Tue, 31 May 2022 22:31:08 +0300
+Subject: Make build against OpenSSL-3.0 possible
+ In OpenSSL, the SSL_get_ex_new_index macro (substituted to
+ CRYPTO_get_ex_new_index) requires CRYPTO_EX_dup as the second callback. This
+ typedef, for some reason, has got an extra asterisk near void* within
+ arguments into the third version. Freely conversions from void* to void** is
+ okay in C but prohibited in C++. So I've updated the callback prototype to
+ match the last OpenSSL version.
+ .
+ OpenSSL pre-3.0 defined all of the SSL_OP_* macros with numeric hexadecimal
+ literals. However, the third version uses there casting expressions with
+ shifts which preprocessor is unable to compute. So I check only macros
+ existence, this lets Squid accept obsolete options. But it's nothing,
+ OpenSSL should ignore them anyway.
+
+---
+ acinclude/lib-checks.m4 |2 -
+ src/security/PeerOptions.cc |   50 ++--
+ src/ssl/support.cc  |2 -
+ 3 files changed, 27 insertions(+), 27 deletions(-)
+
+--- a/acinclude/lib-checks.m4
 b/acinclude/lib-checks.m4
+@@ -236,7 +236,7 @@ AC_DEFUN([SQUID_CHECK_OPENSSL_CONST_CRYP
+   AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
+ #include 
+ 
+-int const_dup_func(CRYPTO_EX_DATA *, const CRYPTO_EX_DATA *, void *, int, long, void *) {
++int const_dup_func(CRYPTO_EX_DATA *, const CRYPTO_EX_DATA *, void **, int, long, void *) {
+ return 0;
+ }
+ ],[
+--- a/src/security/PeerOptions.cc
 b/src/security/PeerOptions.cc
+@@ -297,130 +297,130 @@ static struct ssl_option {
+ 
+ } ssl_options[] = {
+ 
+-#if SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG
++#ifdef SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG
+ {
+ "NETSCAPE_REUSE_CIPHER_CHANGE_BUG", SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG
+ },
+ #endif
+-#if SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG
++#ifdef SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG
+ {
+ "SSLREF2_REUSE_CERT_TYPE_BUG", SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG
+ },
+ #endif
+-#if SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER
++#ifdef SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER
+ {
+ "MICROSOFT_BIG_SSLV3_BUFFER", SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER
+ },
+ #endif
+-#if SSL_OP_SSLEAY_080_CLIENT_DH_BUG
++#ifdef SSL_OP_SSLEAY_080_CLIENT_DH_BUG
+ {
+ "SSLEAY_080_CLIENT_DH_BUG", SSL_OP_SSLEAY_080_CLIENT_DH_BUG
+ },
+ #endif
+-#if SSL_OP_TLS_D5_BUG
++#ifdef SSL_OP_TLS_D5_BUG
+ {
+ "TLS_D5_BUG", SSL_OP_TLS_D5_BUG
+ },
+ #endif
+-#if SSL_OP_TLS_BLOCK_PADDING_BUG
++#ifdef SSL_OP_TLS_BLOCK_PADDING_BUG
+ {
+ "TLS_BLOCK_PADDING_BUG", SSL_OP_TLS_BLOCK_PADDING_BUG
+ },
+ #endif
+-#if SSL_OP_TLS_ROLLBACK_BUG
++#ifdef SSL_OP_TLS_ROLLBACK_BUG
+ {
+ "TLS_ROLLBACK_BUG", SSL_OP_TLS_ROLLBACK_BUG
+ },
+ #endif
+-#if SSL_OP_ALL
++#ifdef SSL_OP_ALL
+ {
+ "ALL", (long)SSL_OP_ALL
+ },
+ #endif
+-#if SSL_OP_SINGLE_DH_USE
++#ifdef SSL_OP_SINGLE_DH_USE
+ {
+ "SINGLE_DH_USE", SSL_OP_SINGLE_DH_USE
+ },
+ #endif
+-#if SSL_OP_EPHEMERAL_RSA
++#ifdef SSL_OP_EPHEMERAL_RSA
+ {
+ "EPHEMERAL_RSA", SSL_OP_EPHEMERAL_RSA
+ },
+ #endif
+-#if SSL_OP_PKCS1_CHECK_1
++#ifdef SSL_OP_PKCS1_CHECK_1
+ {
+ "PKCS1_CHECK_1", SSL_OP_PKCS1_CHECK_1
+ },
+ #endif
+-#if SSL_OP_PKCS1_CHECK_2
++#ifdef SSL_OP_PKCS1_CHECK_2
+ {
+ "PKCS1_CHECK_2", SSL_OP_PKCS1_CHECK_2
+ },
+ #endif
+-#if 

Bug#900799: linux-image-arm64: dts: rockchip: correct voltage selector Firefly-RK3399

[Heinrich Schuchardt]

On 6/1/22 11:28, Diederik de Haas wrote:

On Fri, 22 Jun 2018 21:58:30 +0100 Ben Hutchings  wrote:

Version: 4.17.2-1~exp1

On 5 Jun 2018 07:33:11 +0200 Heinrich Schuchardt  wrote:

Please, add this patch to the Debian kernel patches until it is added
upstream. Cf.
https://lkml.org/lkml/2018/6/4/781


This was applied in the above merge but not mentioned in the changelog
due to a mis-merge.


In response Heiko says in https://lkml.org/lkml/2018/6/19/1167:
"and dropped again.

Sadly it looks like the patch causes conflicts with at least one firefly
board in a kernelci lab. My own is currently not ready to use, so I cannot
look myself right now.

The issue kernelci people described sounded quite a lot like the one
in your commit message, so my current theory is that the
suspend-voltage-selector must in some form corespond to the
cpu_b_sleep_h gpio setting we're currently not handling at all, which
would therefore depend on how the bootloader sets this up."

It's also not part of current upstream master, so this is a DTS change that is
specific for Debian and possibly not needed and/or incorrect?

Heinrich, can you tell us more about the current status of this patch?


I have not been working on the board in the last years.

My impression at the time was that one would have to detect the current
state of the board at runtime which matches what you wrote.

Best regards

Heinrich

Bug#973578: qemu-system-arm: -machine sbsa-ref does not boot UEFI

[Marcin Juszkiewicz]

W dniu 02.11.2020 o 05:00, Ryutaroh Matsumoto pisze:

Package: qemu-system-arm
Version: 1:5.1+dfsg-4+b1
Severity: minor

Dear Maintainer,

# cp /usr/share/AAVMF/AAVMF_VARS.fd /var/tmp/efivars.fd; qemu-system-aarch64 \
  -machine sbsa-ref -cpu cortex-a57  -nographic -net nic,model=virtio \
  -net user -object rng-random,filename=/dev/urandom,id=rng0 \
  -device virtio-rng-pci,rng=rng0,id=rng-device0 \
  -drive file=/var/lib/debci/qemu/sid-arm64.img,if=virtio,index=0,format=qcow2 \
  -drive if=pflash,format=raw,read-only,file=/usr/share/AAVMF/AAVMF_CODE.fd \
  -drive if=pflash,format=raw,file=/var/tmp/efivars.fd -m 1024

gives the error
qemu-system-aarch64: device requires 268435456 bytes, block backend provides 
67108864 bytes

On the other hand, if I change -machine sbsa-ref to -machine virt,
it works fine as


SBSA Reference Platform requires both UEFI firmware and UEFI variables 
file to be 256MB in size.


Virt machine uses 64MB files.

So it is not a bug in qemu.

Bug#1012210: linux-image-5.10.0-14-amd64: Kernels of Bullseye and Testing (5.10 and 5.17) hang at boot

[Diederik de Haas]

Hi Markus,

On Wednesday, 1 June 2022 17:22:35 CEST Markus Kolb wrote:
> Am 01.06.2022 13:34, schrieb Diederik de Haas:
> > On Wednesday, 1 June 2022 13:23:26 CEST Diederik de Haas wrote:
> >> The current version in Sid/Unstable is 5.17.11-1 and it would be
> >> useful if you could test that as well.
> > 
> > In the screenshot you sent to the bug report, I saw mentions of an USB
> > hub.
> > Could you try to unplug any peripherals that are not strictly needed?
> > IOW: only attach a keyboard and monitor and see if that makes a
> > difference.
> 
> I've just tested
>linux-image-5.17.0-2-amd645.17.6-1+b1
> but also doesn't boot.

I was expecting 5.17.11-1, but that version does have the SATA fix from the 
other bug report too. And there's another thing to focus on ...
 
> The computer has only attached USB mouse. The keyboard is PS/2. Next to
> this only Ethernet cable and VGA is connected.

Ok, that is fine.

> In the meantime I've built
>linux-image-5.10.119
> from kernel.org sources and it boots successful.

... and this is VERY significant (afaict) :-)

> I've used localmodconfig while running the
>linux-image-4.19.0-20-amd64   4.19.235-1
> and afterwards used mostly defaults for new config options but also
> deactivated many options and modules, I don't need and was quite sure
> about it, for faster build finishing.

The exact implications of this is 'above my pay grade', but hopefully one of 
the kernel maintainers (who should understand this) chimes in.

> I've attached dmesg output, config and lsmod output for my 5.10.119.
> Maybe it helps to find the right patch.

Via https://packages.debian.org/bullseye/linux-config-5.10 I retrieved the 
Debian kernel config for 5.10.106-1 (which is likely close enough) and compared 
it with the config you attached.

The diff was *huge*, but the fact that you were able to boot your self-built 
5.10 kernel while the Debian 5.10 kernel failed, points (strongly) towards a 
Debian kernel configuration difference which is the cause of this bug.

I have no idea how to make any intelligent recommendations wrt kernel config 
changes, so I have to defer to people 'smarter' then me (wrt this).

> Next I build 5.10.114 which is date corresponding to the 5.17.6 and see
> if I can find the version with patch with going upwards.
> Or someone already any idea what it could be? :-)

Building 5.10.113 with your custom config sounds like a good test case.
Debian's 5.10.113 didn't boot (with Debian's config), but if the (exact) same 
version with a different config does work, then it seems almost certain to me 
that the bug is in the Debian kernel configuration.

Cheers,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Bug#1012221: rust-stdweb-internal-macros (build-)depends on old version of rust-sha1.

[Peter Green]

Package: rust-stdweb-internal-macros
Version: 0.2.9-1
Severity: serious

rust-stdweb-internal-macros depends on version 0.6 of rust-sha1

As I understand it the new version of rust-sha1 is a completely different
code base with the old rust-sha1 having been renamed to sha1-smol

stdweb appears to be unmaintained upstream 
https://rustsec.org/advisories/RUSTSEC-2020-0056.html
and has an open soundness issue https://github.com/koute/stdweb/issues/411

No applications in Debian appear to use stdweb, Nevertheless this issue
is blocking the migration of the new version of rust-sha1 to testing.
Thanks to the use of collapse_features in instant and parking-lot it is also
making the build-dependencies of debcargo unsatisfiable.

Possible ways forward:

1. Attempt to port stdweb to the rustcrypto version of sha1
2. Introduce a sha1-0.6 package
3. Package sha1-smol and patch stdweb to use it
4. Remove the stdweb features in instant and parking-lot and allow stdweb to be 
removed from testing.

Given the lack of upstream maintinance of stdweb i'm inclined towards
option 4, does anyone else have any opinions before I go ahead and do it?

Bug#1012220: linux-headers-5.16.0-0.bpo4-amd64: package nvidia-kernel can not be build with this kernel version

[Hans-J. Ullrich]

Package: linux-headers-5.16.0-0.bpo4-amd64
Severity: important

Dear Maintainer,

since kernel version 5.10 the nvidia kernel can not build any more. I tested 
with the latest actual kernel and header versions in debian/stable, which is 
5.16, backported, 4th version, but the build failes.

I checked the buuild log, and it appears, that the build crash is related to a 
missing file . Please see youself below, IMHO the missing file 
"pahole-flags.sh" iss missing.

This is the make.log:

- snip 

make[3]: *** 
[/usr/src/linux-headers-5.16.0-0.bpo.4-common/scripts/Makefile.build:292: 
/var/lib/dkms/nvidia-legacy-340xx/340.108/build/nv-acpi.o] Fehler 1
make[2]: *** [/usr/src/linux-headers-5.16.0-0.bpo.4-common/Makefile:1870: 
/var/lib/dkms/nvidia-legacy-340xx/340.108/build] Fehler 2
make[2]: Verzeichnis „/usr/src/linux-headers-5.16.0-0.bpo.4-amd64“ wird 
verlassen
make[1]: *** [Makefile:231: __sub-make] Fehler 2
make[1]: Verzeichnis „/usr/src/linux-headers-5.16.0-0.bpo.4-common“ wird 
verlassen
make: *** [Makefile:211: nvidia.ko] Fehler 2
make: Verzeichnis „/var/lib/dkms/nvidia-legacy-340xx/340.108/build/uvm“ wird 
betreten
cd ./..; make module SYSSRC=/lib/modules/5.16.0-0.bpo.4-amd64/source 
SYSOUT=/lib/modules/5.16.0-0.bpo.4-amd64/build KBUILD_EXTMOD=./..
make[1]: Verzeichnis „/var/lib/dkms/nvidia-legacy-340xx/340.108/build“ wird 
betreten
NVIDIA: calling KBUILD...
make NV_MODULE_SUFFIX= KBUILD_OUTPUT=/lib/modules/5.16.0-0.bpo.4-amd64/build 
KERNEL_SOURCES=/lib/modules/5.16.0-0.bpo.4-amd64/source 
KERNEL_OUTPUT=/lib/modules/5.16.0-0.bpo.4-amd64/build KBUILD_VERBOSE=1 -C 
/lib/modules/5.16.0-0.bpo.4-amd64/source 
M=/var/lib/dkms/nvidia-legacy-340xx/340.108/build ARCH=x86_64 modules
make[2]: Verzeichnis „/usr/src/linux-headers-5.16.0-0.bpo.4-common“ wird 
betreten
make -C /usr/src/linux-headers-5.16.0-0.bpo.4-amd64 -f 
/usr/src/linux-headers-5.16.0-0.bpo.4-common/Makefile modules
make[3]: Verzeichnis „/usr/src/linux-headers-5.16.0-0.bpo.4-amd64“ wird betreten
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
\
echo >&2;   \
echo >&2 "  ERROR: Kernel configuration is invalid.";   \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are 
missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix 
it.";  \
echo >&2 ;  \
/bin/false)
/bin/sh: 1: 
/usr/src/linux-headers-5.16.0-0.bpo.4-common/scripts/pahole-flags.sh: not found
/bin/sh: 1: 
/usr/src/linux-headers-5.16.0-0.bpo.4-common/scripts/pahole-flags.sh: not found
make -f /usr/src/linux-headers-5.16.0-0.bpo.4-common/scripts/Makefile.build 
obj=.. \
single-build= \
need-builtin=1 need-modorder=1
/bin/sh: 1: 
/usr/src/linux-headers-5.16.0-0.bpo.4-common/scripts/pahole-flags.sh: not found
/usr/src/linux-headers-5.16.0-0.bpo.4-common/scripts/Makefile.build:44: 
/usr/src/linux-headers-5.16.0-0.bpo.4-common/../Makefile: Datei oder 
Verzeichnis nicht gefunden
make[4]: *** Keine Regel, um 
„/usr/src/linux-headers-5.16.0-0.bpo.4-common/../Makefile“ zu erstellen.  
Schluss.
make[3]: *** [/usr/src/linux-headers-5.16.0-0.bpo.4-common/Makefile:1870: ..] 
Fehler 2
make[3]: Verzeichnis „/usr/src/linux-headers-5.16.0-0.bpo.4-amd64“ wird 
verlassen
make[2]: *** [Makefile:231: __sub-make] Fehler 2
make[2]: Verzeichnis „/usr/src/linux-headers-5.16.0-0.bpo.4-common“ wird 
verlassen
make[1]: *** [Makefile:211: nvidia.ko] Fehler 2
make[1]: Verzeichnis „/var/lib/dkms/nvidia-legacy-340xx/340.108/build“ wird 
verlassen
make: *** [Makefile:225: ../Module.symvers] Fehler 2
make: Verzeichnis „/var/lib/dkms/nvidia-legacy-340xx/340.108/build/uvm“ wird 
verlassen

-- snap 

I hope this makes things clear. Thank you for any hints and helps. 

Best regards

Hans
 

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#738537:

[ONLY DROCK]

Bug#1012210: linux-image-5.10.0-14-amd64: Kernels of Bullseye and Testing (5.10 and 5.17) hang at boot

[Markus Kolb]

Am 01.06.2022 13:34, schrieb Diederik de Haas:

On Wednesday, 1 June 2022 13:23:26 CEST Diederik de Haas wrote:
The current version in Sid/Unstable is 5.17.11-1 and it would be 
useful if

you could test that as well.


In the screenshot you sent to the bug report, I saw mentions of an USB 
hub.

Could you try to unplug any peripherals that are not strictly needed?
IOW: only attach a keyboard and monitor and see if that makes a 
difference.


Hey Diederik,

I've just tested
  linux-image-5.17.0-2-amd645.17.6-1+b1
but also doesn't boot.

The computer has only attached USB mouse. The keyboard is PS/2. Next to 
this only Ethernet cable and VGA is connected.


In the meantime I've built
  linux-image-5.10.119
from kernel.org sources and it boots successful.

I've used localmodconfig while running the
  linux-image-4.19.0-20-amd64   4.19.235-1
and afterwards used mostly defaults for new config options but also 
deactivated many options and modules, I don't need and was quite sure 
about it, for faster build finishing.


I've attached dmesg output, config and lsmod output for my 5.10.119. 
Maybe it helps to find the right patch.
Next I build 5.10.114 which is date corresponding to the 5.17.6 and see 
if I can find the version with patch with going upwards.

Or someone already any idea what it could be? :-)

cu
Markus

config-5.10.119.xz
Description: application/xz


dmesg-5.10.119.txt.xz
Description: application/xz


lsmod.txt.xz
Description: application/xz

Bug#886358:

[ONLY DROCK]

Bug#1004285: davical: problems after upgrade to php 8, calendar clients reports "500"

[Tino Mettler]

Hi,

Maybe this helps: I recently upgraded to bullseye and my macOS calendar
(from macOS 12.2.1) still works fine with DAViCal.

I did not migrate DAViCal to the PostgreSQL 13 in bullseye yet, so I
still use PostgreSQL 11 for the DAViCal database.

Regards,
Tino

Bug#987292:

[ONLY DROCK]

Bug#1006562: Bug waiting on OpenSSL to migrate

[Thomas Goirand]

This bug will be fixed in Testing when OpenSSL migrates...

Cheers,

Thomas Goirand (zigo)

Bug#866314: linux-image-4.9.0-3-686-pae: 100+ times slower disk writes on 4.x+/i386/16+RAM, compared to 3.x

[Diederik de Haas]

On Wednesday, 1 June 2022 16:15:51 CEST Holger Levsen wrote:
> you seem to assume that I know how to report upstream bugs to the kernel.
> yet I don't know.

https://bugzilla.kernel.org/show_bug.cgi?id=196157 is a (standard) Bugzilla 
instance where you could create an account if you don't have it and then add
your response to that bug.

Andrew Morton seems to prefer plain email and his' message can be found
on lore.kernel.org here: 
https://lore.kernel.org/linux-mm/20170622123736.1d80f1318eac41cd661b7...@linux-foundation.org/

That message also contains instructions at the bottom how to do it (properly).

If you have further questions, I'll do my best to answer them.

HTH,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Bug#1012219: r-cran-rstan: FTBFS with onetbb/2021.5.0-9 in experimental

[Andrius Merkys]

Source: r-cran-rstan
Version: 2.21.5-1
Severity: normal
Tags: ftbfs

Hello,

tbb/onetbb transition (#1007222) is currently in the planning. During
test rebuild of libtbb-dev reverse dependencies with onetbb/2021.5.0-9
in experimental, current source failed to build with the following:

** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for 'rstan' in dyn.load(file,
DLLpath = DLLpath, ...):
 unable to load shared object
'/home/merkys/r-cran-rstan-2.21.5/debian/r-cran-rstan/usr/lib/R/site-library/00LOCK-r-cran-rstan-2.21.5/00new/rstan/libs/rstan.so':

/home/merkys/r-cran-rstan-2.21.5/debian/r-cran-rstan/usr/lib/R/site-library/00LOCK-r-cran-rstan-2.21.5/00new/rstan/libs/rstan.so:
undefined symbol: _ZN3tbb8internal26task_scheduler_observer_v37observeEb
Error: loading failed
Execution halted

Andrius

Bug#987292:

[ONLY DROCK]

Bug#866314: linux-image-4.9.0-3-686-pae: 100+ times slower disk writes on 4.x+/i386/16+RAM, compared to 3.x

[Holger Levsen]

On Wed, Jun 01, 2022 at 04:01:10PM +0200, Diederik de Haas wrote:
> On Wednesday, 1 June 2022 15:11:37 CEST Holger Levsen wrote:
> > On Wed, Jun 01, 2022 at 02:53:06PM +0200, Diederik de Haas wrote:
> > > So it would be really helpful if this would be added to the upstream bug
> > > report.
> > then please do so?!?
> 
> And with that I've lost any motivation to further reduce the Debian kernel 
> bug 
> list. Let's keep this and other pointless bug open for ever.
> Well done.

you seem to assume that I know how to report upstream bugs to the kernel.
yet I don't know.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The past is over.


signature.asc
Description: PGP signature

Bug#866314: linux-image-4.9.0-3-686-pae: 100+ times slower disk writes on 4.x+/i386/16+RAM, compared to 3.x

[Diederik de Haas]

On Wednesday, 1 June 2022 15:11:37 CEST Holger Levsen wrote:
> On Wed, Jun 01, 2022 at 02:53:06PM +0200, Diederik de Haas wrote:
> > So it would be really helpful if this would be added to the upstream bug
> > report.
> 
> then please do so?!?

And with that I've lost any motivation to further reduce the Debian kernel bug 
list. Let's keep this and other pointless bug open for ever.

Well done.

signature.asc
Description: This is a digitally signed message part.

Bug#1012217: isc-dhcp-server-ldap: Does not handle LDAP sizelimit correctly

[Christian Kreidl]

Package: isc-dhcp-server-ldap
Version: 4.4.1-2.3
Severity: important

Dear Maintainer,

dhcpd doesn't handle LDAP sizelimits correctly.

If LDAP-server returns error code 4 (LDAP_SIZELIMIT_EXCEEDED) then dhcpd seems to hang until a 
segmentation fault occurs.


When using LDAPS instead of LDAP then dhcpd prints:
-- snip --
Internet Systems Consortium DHCP Server 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Cannot set LDAP TLS crl check option: Can't contact LDAP server
LDAPS session successfully enabled to zitisrv01.ziti.uni-heidelberg.de:636
Cannot set LDAP TLS crl check option: Can't contact LDAP server
LDAPS session successfully enabled to zitisrv01.ziti.uni-heidelberg.de:636
Cannot set LDAP TLS crl check option: Can't contact LDAP server
LDAPS session successfully enabled to zitisrv01.ziti.uni-heidelberg.de:636
-- continues until segmentation fault --

relevant slapd log lines:
-- snip --
slapd[1753072]: conn=1618 fd=27 ACCEPT from IP=127.0.0.1:44080 
(IP=127.0.0.1:389)
slapd[1753072]: conn=1618 op=0 BIND dn="cn=dhcp,ou=dsa,dc=example,dc=com" 
method=128
slapd[1753072]: conn=1618 op=0 BIND dn="cn=dhcp,ou=dsa,dc=example,dc=com" 
mech=SIMPLE ssf=0
slapd[1753072]: conn=1618 op=0 RESULT tag=97 err=0 text=
slapd[1753072]: conn=1618 op=1 SRCH base="cn=dhcp-group,cn=dhcp-config,dc=example,dc=com" scope=1 
deref=0 filter="(!(|(|(objectClass=dhcpTSigKey)(objectClass=dhcpClass))(objectClass=dhcpFailOverPeer)))"

slapd[1753072]: conn=1618 op=1 SEARCH RESULT tag=101 err=4 nentries=50 text=
slapd[1753072]: conn=1618 op=2 UNBIND
-- snip --

in slapd config:
 sizelimit size.soft=50 size.hard=1000

The DHCP group "dhcp-group" requested in the failing LDAP search contains 100 
host entries.

When changing the slapd sizelimit to 100 or larger, then dhcpd works.

Thanks!
Christian

Bug#1012215: gradle-debian-helper: unknown option --add-opens breaks OpenJDK 11 packages

[Markus Koschany]

Am Mittwoch, dem 01.06.2022 um 15:03 +0200 schrieb Emmanuel Bourg:
> The --add-opens option was introduced in Java 9, so this shouldn't cause an
> issue with Java 11. What error did you get?


The compiler complains about "unknown option --add-opens" when I try to rebuild
kotlin in unstable. 

Starting process 'Gradle build daemon'. Working directory:
/<>/.gradle/daemon/4.4.1 Command: /usr/lib/jvm/java-11-openjdk-
amd64/bin/java -Xbootclasspath/a:/usr/share/java/gradle-helper-
hook.jar:/usr/share/java/maven-repo-helper.jar --add-opens
java.base/java.lang=ALL-UNNAMED -Dfile.encoding=UTF-8 -Duser.country -
Duser.language=en -Duser.variant -cp /usr/share/gradle/lib/gradle-launcher-
4.4.1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 4.4.1

It might be related to the build-dependency on openjdk-8 but the command
mentions java-11 which is strange. In any case we should be more careful when
we force new options to all packages. A conditional is safer and prevents
regressions.



signature.asc
Description: This is a digitally signed message part

Bug#1012208: closed by Debian FTP Masters (reply to Jonas Smedegaard ) (Bug#1012208: fixed in python-pytest-asyncio 0.18.3-1)

[Julian Gilbey]

Wow, that was fast!  Thanks Jonas!

:-)

   Julian

On Wed, Jun 01, 2022 at 01:21:04PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the python3-pytest-asyncio package:
> 
> #1012208: python3-pytest-asyncio: please add Breaks: python3-pytest-mock (<< 
> 3.7.0)
> 
> It has been closed by Debian FTP Masters  
> (reply to Jonas Smedegaard ).
> 
> 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 Jonas Smedegaard ) 
> by
> replying to this email.
> 
> 
> -- 
> 1012208: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012208
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Wed, 01 Jun 2022 13:19:59 +
> From: Debian FTP Masters 
> Subject: Bug#1012208: fixed in python-pytest-asyncio 0.18.3-1
> To: 1012208-cl...@bugs.debian.org
> 
> Source: python-pytest-asyncio
> Source-Version: 0.18.3-1
> Done: Jonas Smedegaard 
> 
> We believe that the bug you reported is fixed in the latest version of
> python-pytest-asyncio, 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 1012...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Jonas Smedegaard  (supplier of updated python-pytest-asyncio 
> 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: SHA512
> 
> Format: 1.8
> Date: Wed, 01 Jun 2022 14:40:22 +0200
> Source: python-pytest-asyncio
> Architecture: source
> Version: 0.18.3-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Jonas Smedegaard 
> Changed-By: Jonas Smedegaard 
> Closes: 1012208
> Changes:
>  python-pytest-asyncio (0.18.3-1) unstable; urgency=medium
>  .
>[ upstream ]
>* new release
>  .
>[ Jonas Smedegaard ]
>* break python3-pytest-mock;
>  closes: bug#1012208, thanks to Julian Gilbey and Graham Inggs
>* avoid module pytest_trio not in Debian
> Checksums-Sha1:
>  7d784145b4c2e022f933790bd67b9b5f331130ba 2402 
> python-pytest-asyncio_0.18.3-1.dsc
>  06dd7f5516a995ad12b2dbfb81686928f4aaff28 25049 
> python-pytest-asyncio_0.18.3.orig.tar.gz
>  79b204a7d2671e89bdd5d191039f2f7ecda030a5 3816 
> python-pytest-asyncio_0.18.3-1.debian.tar.xz
>  b983ed46053ad4e49cb2cce8b7e1dcb25fae6738 7404 
> python-pytest-asyncio_0.18.3-1_amd64.buildinfo
> Checksums-Sha256:
>  add95ac3647e01686a2b08927b0725a390613beb085429ad64af985208d334af 2402 
> python-pytest-asyncio_0.18.3-1.dsc
>  9c129d780f1120da6f512eddc09180fa716b58fd647dd9f2efb544b8b33bc3f9 25049 
> python-pytest-asyncio_0.18.3.orig.tar.gz
>  83de46abd82e0c93af7287a002e76765cf92a30fe6f78457a67ae426e385bc14 3816 
> python-pytest-asyncio_0.18.3-1.debian.tar.xz
>  2ce847ecdb19373dde0e6e38a2a6c20b127c075dc66f418d0cc5e0951dda1107 7404 
> python-pytest-asyncio_0.18.3-1_amd64.buildinfo
> Files:
>  753c6f1193c17d63e35a9489388315e8 2402 python optional 
> python-pytest-asyncio_0.18.3-1.dsc
>  fc3f20f40629190a96efebda44e37c4a 25049 python optional 
> python-pytest-asyncio_0.18.3.orig.tar.gz
>  0dd7fe16cee615f337d0435b4b81381e 3816 python optional 
> python-pytest-asyncio_0.18.3-1.debian.tar.xz
>  e5788639a4827da9d4844bcd5e09cf4c 7404 python optional 
> python-pytest-asyncio_0.18.3-1_amd64.buildinfo
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmKXZOUACgkQLHwxRsGg
> ASEN8A/+LPZ+M6dnY+UFqAmns5uJKWhX0W+AY+PC7J5BDugJfi57FvEVowf4DXH+
> avcLlf6qOmaa+q+3IaRnnW8U5g/vAcI20vtnuTXCKr9JCY5CjCVA4JmCoFBPDWwX
> uAe/9izxEwLPnTqEOuoK2qSwuSa/PYP1FWL+nyuEiKoa/cBQqlh2HX5W4ChZWYJW
> vZrDEIOosFn8ji3dcOgklH9EtqcPOUL3f8l/UIe4v/Xr2MSfwsA4B23fxjUS98nt
> qfRUbkgx2jMkQsx+P+q51ZT3jKFpuGYqJUwLRVVdoS3C6dcDK5SrsYTzeI20ukw3
> Sniet3WXmUVr/mWtmIisaKThH7jd6zkt8r5Fb058RlyPeBL1LJh84SZuHm4NPo52
> yjZ2cJdFP+Med7Abxc8ry4RCfZZ0xCpvhW0qgJFdRfRgVDgFrtNu5ccaLXrb7qu2
> ajcZHDYJtI1/1rDvvFVJMlYC5LVv1J9UXelEjXzu9hETmBzynURD08YW/5WwjQRy
> rt5P+j1HnrpRo0CzGdVMzjmF3r5qHY2oy6PVXH6Tzh3I5kKw/UBXwSXFq8UIN5T7
> obU9+Tkv13ef9Lw8o96FO65dTyOeyuu5Lu6uVR298EuZH/fkLxx05z42dJp1HczA
> 5pKxjZFrVsXVEAQuHyefuHXITaZWjrjH39ZfYEq8OG/QGVdp5jA=
> =d1Pc
> -END PGP SIGNATURE-

> Date: Wed, 01 Jun 2022 10:59:33 +0100
> From: Julian Gilbey 
> Subject: unblock: python-pytest-asyncio/0.18.2-1
> To: Debian Bug Tracking System 
> 
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package 

Bug#1012213: amide: new upstream version

[Andreas Tille]

Hi Bastian,

Am Wed, Jun 01, 2022 at 02:31:30PM +0200 schrieb Bastian Germann:
> Source: amide
> Version: 1.0.5-16
> 
> Upstream has a new version 1.0.6 available and links to
> https://github.com/ferdymercury/amide for the source.
> 
> Please change the watch file and update to the new version.

Thanks a lot for pointing this out which is extremely helpful.
Unfortunately upstream did not tagged their releases which I
reported on Github[1].  May be you respond to that tag as well
to stress its importance.

Kind regards

Andreas.

[1] https://github.com/ferdymercury/amide/issues/17

-- 
http://fam-tille.de

Bug#1012215: gradle-debian-helper: unknown option --add-opens breaks OpenJDK 11 packages

[Emmanuel Bourg]

The --add-opens option was introduced in Java 9, so this shouldn't cause an 
issue with Java 11. What error did you get?

Bug#1012216: Bug on Debian 11 Bullseye - systemd v.247.3-7

[pham...@bluewin.ch]

Package: systemd
Version: 247.3-7
Debian 11 64 Bits on Cinnamon desktop and kernel 5.17.3-1

Bug Description:

These errors appear in the boot log of my machine journalctl -b (journalctl -b)
jun 01 14:52:41 station systemd-xdg-autostart-generator[1827]: Exec binary 
'/usr/libexec/evolution-data-server/evolution-alarm-notify' does not exist: No 
such file or directory
jun 01 14:52:41 station systemd-xdg-autostart-generator[1827]: Not generating 
service for XDG autostart 
app-org.gnome.Evolution\x2dalarm\x2dnotify-autostart.service, error parsing 
Exec= line: No such file or directory
jun 01 14:52:41 station systemd-xdg-autostart-generator[1827]: Exec binary 
'/usr/lib/x86_64-linux-gnu/libexec/kdeconnectd' does not exist: No such file or 
directory
jun 01 14:52:41 station systemd-xdg-autostart-generator[1827]: Not generating 
service for XDG autostart app-org.kde.kdeconnect.daemon-autostart.service, 
error parsing Exec= line: No such file or directory
Debian 11 64 Bits on Cinnamon and kernel 5.17.3-1
Best regards.

Philippe

Bug#866314: linux-image-4.9.0-3-686-pae: 100+ times slower disk writes on 4.x+/i386/16+RAM, compared to 3.x

[Holger Levsen]

On Wed, Jun 01, 2022 at 02:53:06PM +0200, Diederik de Haas wrote:
> So it would be really helpful if this would be added to the upstream bug 
> report.

then please do so?!?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Bottled water companies don't produce water, they produce plastic bottles.


signature.asc
Description: PGP signature

Bug#919937: status update

[Antoine Beaupré]

On 2022-06-01 11:11:40, Nilesh Patra wrote:
> Hi Micah, Antione,
>
> On Tue, 02 Apr 2019 09:50:55 -0400 micah anderson  wrote:
>> Antoine Beaupré  writes:
>> 
>> > We've processed a bunch of the dependencies for this, and uploaded some
>> > to NEW (with related git repos in salsa). Some are not done yet, mostly
>> > because their license is unclear.
>> 
>> The packages indicated in this table as having unclear licenses have had
>> that issue resolved, so those packages can be built now.
>
> It has been a long time since you sent this email -- is there any progress
> about it/[...]

Not as far as I know.

> any known blockers?

The bug has at least two other bugs blocking it at the moment, but
considering how old the last report is, I wouldn't be surprised if
upstream introduced new dependencies that need packaging as well.

> I would very much like to see riseup-vpn in debian archive, and I would also
> be willing to help out in getting this packaged.

As far as I am concerned, please go ahead, but the bug is owned by micah
so maybe checkin with him first. I would be surprised if he has any
objection to getting help, that said. :)

I should also note that I happen to be the Debian maintainer of a few of
the dependencies that were packaged for this ITP, and I have seriously
considered orphaning those because I have limited cycles to take care of
them. So if you want to look into those, feel free to take them over.

a.

-- 
Les écrivains qui ont recours à leurs doigts pour savoir s'ils ont leur
compte de pieds ne sont pas des poètes, ce sont des dactylographes.
- Léo Ferré, "Préface"

Bug#866314: linux-image-4.9.0-3-686-pae: 100+ times slower disk writes on 4.x+/i386/16+RAM, compared to 3.x

[Diederik de Haas]

On Wednesday, 1 June 2022 14:09:28 CEST Holger Levsen wrote:
> On Wed, Jun 01, 2022 at 01:27:32AM +0200, Diederik de Haas wrote:
> > What's the current status wrt this bug?
> 
> we downgraded the memory of our nodes to 8gb to work around the issue...

Andrew Morton said in https://bugzilla.kernel.org/show_bug.cgi?id=196157#c21 :
"People are still hurting from this.  It does seem a pretty major
regression for highmem machines.

I'm surprised that we aren't hearing about this from distros.  Maybe it
only affects a subset of highmem machines?

Anyway, can we please take another look at it?  Seems that we messed up
highmem dirty pagecache handling in the 4.2 timeframe."

I didn't see a mention of this bug in that upstream bug report.

A mention of "the i386 build nodes for tests.reproducible-builds.org" may also 
help to increase the priority for the upstream devs.
And if it's possible to equip one of the machines with 16G again and provide 
access to the upstream devs to that machine, that will likely increase the 
chances that something may happen.

So it would be really helpful if this would be added to the upstream bug 
report. Otherwise it's extremely unlikely anything will change.

signature.asc
Description: This is a digitally signed message part.

Bug#1012077: add one riscv CPU info for linuxinfo package, T-HEAD XuanTie C910

[肖盛文]

Hi,

There is one riscv CPU info:

Name: T-HEAD XuanTie C910

Info: https://www.t-head.cn/product/C910

cat /proc/cpuinfo



   

processor   :
0   

  
 
hart    :
0   

  
 
isa :
rv64imafdcsu

  
 
mmu :
sv39

  
 
model name  : T-HEAD
C910

   
 
freq    :
1.2GHz  

  
 
icache  :
64kB

  
 
dcache  :
64kB

  
 
l2cache :
2MB 

  
 
tlb : 1024
4-ways  

 
 
cache line  :
64Bytes 

  
 
address sizes   : 40 bits physical, 39 bits
virtual 

 
vector version  : 0.7.1   

The board hardware info:
https://linux-hardware.org/?probe=bcb55ce8ce


I hope this CPU info add into linuxinfo package.

If need more infos about this CPU, please tell me.


Thanks!

在 2022/6/1 11:36, xiao sheng wen (肖盛文) 写道:
> Is there anybody use the riscv CPU other than sifive,u74-mc?
> Welcome to supply CPU info.
>
-- 
肖盛文 xiao sheng wen Faris Xiao 
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012215: gradle-debian-helper: unknown option --add-opens breaks OpenJDK 11 packages

[Markus Koschany]

Package: gradle-debian-helper
Version: 2.2
Severity: serious
X-Debbugs-Cc: a...@debian.org

Hi,

The newly added --add-opens option is only valid for OpenJDK 17. I
understand that we switch to it for Debian 12 but it currently breaks
all packages that are built with OpenJDK 11. I am currently in the
process to update gradle to a newer upstream release. We should try to
use a conditional clause depending on the JVM in use.

Markus

Bug#1012214: gradle: unknown option --add-opens breaks OpenJDK 11 packages

[Markus Koschany]

Package: gradle
Version: 4.4.1-14
Severity: serious
X-Debbugs-Cc: a...@debian.org

Hi,

The newly added --add-opens option is only valid for OpenJDK 17. I
understand that we switch to it for Debian 12 but it currently breaks
all packages that are built with OpenJDK 11. I am currently in the
process to update gradle to a newer upstream release. We should try to
use a conditional clause depending on the JVM in use.

Markus

Bug#1012213: amide: new upstream version

[Bastian Germann]

Source: amide
Version: 1.0.5-16

Upstream has a new version 1.0.6 available and links to
https://github.com/ferdymercury/amide for the source.

Please change the watch file and update to the new version.

Bug#910388: please allow to use "external viewers" for n-way diffs

[Nilson Silva]

Hi!

I decided to adopt this package that has been very useful to me in my packaging.

Taking advantage of it, I'm already applying the patch.

Thank you Tomas Pospisek for contributing to this tool.

Nilson F. Silva

Bug#866314: linux-image-4.9.0-3-686-pae: 100+ times slower disk writes on 4.x+/i386/16+RAM, compared to 3.x

[Holger Levsen]

On Wed, Jun 01, 2022 at 01:27:32AM +0200, Diederik de Haas wrote:
> What's the current status wrt this bug?

we downgraded the memory of our nodes to 8gb to work around the issue...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

So what CAN we actually do? Well, individual decisions (eating less meat,
taking public transport, buying less fast fashion) are all important, but we
also need to change the system. As you may know, just 100 companies are
responsible for 71% of global emissions. (@JessicaTheLaw)
https://www.theguardian.com/sustainable-business/2017/jul/10/100-fossil-fuel-companies-investors-responsible-71-global-emissions-cdp-study-climate-change


signature.asc
Description: PGP signature

Bug#1012212: node-react-audio-player: Intent to remove from Debian

[Nicolas Mora]

Package: node-react-audio-player
Version: 0.17.0-2
Severity: normal
X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org

I intent to remove node-react-audio-player from the Debian archive, it has
originally been added to Debian to help build a bigger package.
But considering the amount of work to build this big package, I have cancelled
it. Therefore, node-react-audio-player has no real purpose in Debian, and
maintaining it with its dependencies upgrades is a waste of time.

/Nicolas

Bug#1012208: unblock: python-pytest-asyncio/0.18.2-1

[Julian Gilbey]

reassign 1012208 python3-pytest-asyncio
retitle 1012208 python3-pytest-asyncio: please add Breaks: python3-pytest-mock 
(<< 3.7.0)
thanks

Dear Jonas,

I've updated python3-pytest-mock to fix #1006736.  Unfortunately, the
two packages are still not transitioning to testing.  I've had the
following brief conversation with release.d.o about this:

On Wed, Jun 01, 2022 at 12:39:38PM +0100, Julian Gilbey wrote:
> On Wed, Jun 01, 2022 at 01:14:31PM +0200, Graham Inggs wrote:
> > Hi Julian
> > 
> > On Wed, 1 Jun 2022 at 12:03, Julian Gilbey  wrote:
> > > [ Reason ]
> > > python-pytest-asyncio and pytest-mock need to be upgraded together;
> > > pytest-mock 3.7.0-2 build-depends on the newer version of
> > > python-pytest-asyncio (0.18.2-1), while the older version of
> > > pytest-mock (3.6.1-1) breaks with it.
> > 
> > It seems to me that python3-pytest-asyncio misses an appropriate
> > Breaks on python3-pytest-mock then.
> > 
> > Regards
> > Graham
> 
> Ah, OK; I'll ask the maintainer to put one in.
> 
> Best wishes,
> 
>Julian

Please could you upload a new version of python3-pytest-asyncio which
has a Breaks: python3-pytest-mock (<= 3.7.0) clause?

Thanks!

   Julian

Bug#1012208: unblock: python-pytest-asyncio/0.18.2-1

[Julian Gilbey]

On Wed, Jun 01, 2022 at 01:14:31PM +0200, Graham Inggs wrote:
> Hi Julian
> 
> On Wed, 1 Jun 2022 at 12:03, Julian Gilbey  wrote:
> > [ Reason ]
> > python-pytest-asyncio and pytest-mock need to be upgraded together;
> > pytest-mock 3.7.0-2 build-depends on the newer version of
> > python-pytest-asyncio (0.18.2-1), while the older version of
> > pytest-mock (3.6.1-1) breaks with it.
> 
> It seems to me that python3-pytest-asyncio misses an appropriate
> Breaks on python3-pytest-mock then.
> 
> Regards
> Graham

Ah, OK; I'll ask the maintainer to put one in.

Best wishes,

   Julian

Bug#1012035: reprotest: Salsa CI randomly fails because dpkg-source can't change timestamp

[Holger Levsen]

merge 961064 1012035 993339
severity 961064 important
tags 961064 + help newcomer
thanks

On Sun, May 29, 2022 at 08:26:18PM +0200, Samuel Thibault wrote:
> Zhang Boyang, le dim. 29 mai 2022 14:10:35 +0800, a ecrit:
> > I found Salsa CI reprotest on my repo fails when "FAKETIME variation:
> > faketime = [balabala]" is decided. The relevant output is:
> > 
> > dpkg-source: error: cannot change timestamp for
> > build-experiment-1/.pc/applied-patches: Invalid argument
> I have seen reprotest randomly fail in the salsa CI for various packages
> indeed.

indeed, merging with "#961064: reprotest: should not default to vary time and 
date"
and raising the severity and tagging help because reprotest is (almost) 
unmaintained
upstream, and tagging newcomer as the fix should be really easy, so if you are
looking for ways to start contributing to reproducible builds, please do! ;p :)

I'll certainly be happy to review, merge and upload.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

It's not climate change nor climate crisis, it's climate disaster.


signature.asc
Description: PGP signature

Bug#1012210: linux-image-5.10.0-14-amd64: Kernels of Bullseye and Testing (5.10 and 5.17) hang at boot

[Diederik de Haas]

On Wednesday, 1 June 2022 13:23:26 CEST Diederik de Haas wrote:
> The current version in Sid/Unstable is 5.17.11-1 and it would be useful if
> you could test that as well.

In the screenshot you sent to the bug report, I saw mentions of an USB hub. 
Could you try to unplug any peripherals that are not strictly needed?
IOW: only attach a keyboard and monitor and see if that makes a difference.

signature.asc
Description: This is a digitally signed message part.

Bug#1012210: linux-image-5.10.0-14-amd64: Kernels of Bullseye and Testing (5.10 and 5.17) hang at boot

[Diederik de Haas]

Control: found -1 linux/5.17.3-1

On Wednesday, 1 June 2022 12:17:56 CEST Markus Kolb wrote:
> The kernel linux-image-4.19.0-20-amd64 from Buster works.
> This one is used at the moment for reportbug!
> 
> But anything from the newer versions hangs during boot.
> I've tried the release kernel of Bullseye,
> the security-updated linux-image-5.10.0-14-amd64,
> the newest one from backports
> and the latest version from testing, which has been a 5.17 version.
> 
> ...
> 
> Between working and crashing kernel there is some difference in the SATA
> ports. And these are the last lines of output before the screen becomes
> black and there isn't any reaction of the computer any longer.

Bug https://bugs.debian.org/1006149 was also about a boot failure (and SATA) 
and that got fixed in version 5.17.6-1, but due to the openssl transition, that 
didn't get into Testing (which currently has 5.17.3-1).
The current version in Sid/Unstable is 5.17.11-1 and it would be useful if you 
could test that as well.

This does seem like a different issue as it happens with much older kernels 
then that bug report, so I don't expect it to fix it.
But it's still useful info and it may result in some extra info.

signature.asc
Description: This is a digitally signed message part.

Bug#1012154: binfmt-support.service errors with "unable to close /proc/sys/fs/binfmt_misc/register: File exists"

[Colin Watson]

On Wed, Jun 01, 2022 at 11:25:21AM +0200, Michael Biebl wrote:
> what you see here is a race condition between binfmt-support.service and
> systemd-binfmt.service.
> E.g. qemu installs binfmt config files for both binfmt-support and
> systemd-binfmt leading to the issue you see.
> 
> I plan to add a
> ConditionFileIsExecutable=!/usr/sbin/update-binfmts
> to systemd-binfmt.service. This will disable systemd-binfmt.service when
> binfmt-support is installed and should mitigate this issue.
> (thus reassigning to systemd)

Thanks for investigating that.

> Afaics binfmt-support has remained a Debian-only solution, so long-term I'd
> think it would be beneficial if we'd consider systemd-binfmt as a
> cross-distro solution.
> 
> There aren't that many packages installing config snippets in
> /usr/share/binfmts, so a transition seems reasonably doable.

I am not interested in this.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1012208: unblock: python-pytest-asyncio/0.18.2-1

[Graham Inggs]

Hi Julian

On Wed, 1 Jun 2022 at 12:03, Julian Gilbey  wrote:
> [ Reason ]
> python-pytest-asyncio and pytest-mock need to be upgraded together;
> pytest-mock 3.7.0-2 build-depends on the newer version of
> python-pytest-asyncio (0.18.2-1), while the older version of
> pytest-mock (3.6.1-1) breaks with it.

It seems to me that python3-pytest-asyncio misses an appropriate
Breaks on python3-pytest-mock then.

Regards
Graham

Bug#889076: linux-image-4.9.0-5-rt-amd64: at boot computer starts beeping and image in screen becomes corrupted.

[Diederik de Haas]

Control: tag -1 -moreinfo

On Wednesday, 1 June 2022 12:27:38 CEST Miguel Negrão wrote:
> Unfortunatelly I can't test as I don't use this macbook pro anymore.

Thanks for responding :-)
As it's no longer reproducible then, which is a prerequisite for fixing, I'm 
going to close this issue. 
Sorry we weren't able to properly fix it.

Cheers,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Bug#1011153: dh-cargo, sometimes includes generated cargo.lock in lib package.

[James McCoy]

On Tue, May 17, 2022 at 04:25:19PM +0100, Peter Green wrote:
> It appears the cause is that librust-rpassword-dev contains a Cargo.lock file 
> which
> was generated from the versions of packages in debian at the time of it's 
> upload.
> 
> Doing some poking around it appears that the Cargo.lock file is generated by 
> the
> "dh_auto_test -- test --all" command in debian/rules. What I haven't figured 
> out
> is under what circumstances this happens, there appears to be at least* one 
> other
> rust library package containing a Cargo.lock file in it's root 
> librust-os-pipe-dev
> and it's autopkgtest is failing in the same way.
> 
> I think the most sensible way to deal with this is to exclude Cargo.lock in 
> dh-cargo,
> does anyone else have any thoughts before I go ahead and do that?

Sounds good to me.  I was just looking into this yesterday and was going
to suggest the same thing.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#889076: linux-image-4.9.0-5-rt-amd64: at boot computer starts beeping and image in screen becomes corrupted.

[Miguel Negrão]

Hi

Unfortunatelly I can't test as I don't use this macbook pro anymore.

Best regards,
Miguel Negrão

Às 14:18 de 31/05/22, Diederik de Haas escreveu:

Control: tag -1 moreinfo

On Thu, 01 Feb 2018 19:40:32 + Miguel Negrao  wrote:

Package: src:linux
Version: 4.9.65-3+deb9u2

After updating from linux-image-4.9.0-4-rt version 4.9.65-3+deb9u1 to linux-
image-4.9.0-5-rt version 4.9.65-3+deb9u2 when booting, when the kernel
reports something about changing the framebuffer, the computer starts beeping
and screen becomes filled with ghost copies of what was there before, at that
point I have to hard-reboot the machine. Booting with linux-image-4.9.0-4-rt
version 4.9.65-3+deb9u1 continues to work fine. Booting with version
4.9.65-3+deb9u2 also works fine, so the problem is only in the rt version.

I have a macbook pro 2011 with a radeon graphics card.


Can you still reproduce this issue with a recent kernel, like 5.10 from
current Debian Stable?



--
Miguel Negrão
http://www.friendlyvirus.org/miguelnegrao

Bug#891748: all-numeric usernames

[Marc Haber]

Control: -1 - patch

On Tue, May 24, 2022 at 11:05:41PM -0400, Matt Barry wrote:
> Hi!  I've added a patch[0] that rejects all-numeric usernames in
> adduser.. feedback welcome!

Applied! Thanks!

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1011624: kdesu: kdesu fails to authenticate with sudo from testing/unstable

[Marc Haber]

On Wed, Jun 01, 2022 at 12:35:01PM +0200, Aurélien COUDERC wrote:
> Le 26/05/2022 à 16:09, Marc Haber a écrit :
> > On Wed, May 25, 2022 at 01:58:58PM +0100, Rik Mills wrote:
> > > The issue can be worked around by adding /etc/sudoers.d/kdesu with the
> > > contents
> > > 
> > > Defaults!/usr/lib/*/libexec/kf5/kdesu_stub !use_pty
> > 
> > kdesu is cordially invited to ship that file in the package, fixing the
> > issue for everybody. Please add a comment with the reference to this bug
> > report and remove the file once kdesu was fixed upstream.
> 
> kdesu is now cordially shipping the file in the package. :-)

;-)

> Would you mind to comment why this is OK from a security perspective ?

There is a discussion in the KDE bug ticket that seems to make sense to
me. kdesu is exploiting a vulnerability in sudo that we fixed by forcing
the pty. If we don't want to lose kdesu's functionality, we need either
fixing kdesu so that is uses "legal" methods to use sudo, or we need to
re-open the vulnerability to allow unmodified kdesu to work.

This is kdesu's vulnerability now ;-)

I would love to see kdesu fixed in some future, so that the "insecure"
sudo rule can be removed. It would be an idea to ship the file with the
rule commented out by default so that every local admin can cause their
own vulnerability, but that'd probable cause a new avalanche of "kdesu
broken" bug reports.

> I’m no security expert at all but if I read the CVE description correctly,
> the issue is with the su'ed command being able to escape the su user
> session.
> Is it OK in this case because kdesu is used to gain root from non-root and
> so escaping the su session only gives you back the original non-root user
> rights ?

I hope that other people can comment on that, I would need to ponder
about that for some time.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1011624: kdesu: kdesu fails to authenticate with sudo from testing/unstable

[Aurélien COUDERC]

Dear Marc,

Le 26/05/2022 à 16:09, Marc Haber a écrit :

On Wed, May 25, 2022 at 01:58:58PM +0100, Rik Mills wrote:

The issue can be worked around by adding /etc/sudoers.d/kdesu with the
contents

Defaults!/usr/lib/*/libexec/kf5/kdesu_stub !use_pty


kdesu is cordially invited to ship that file in the package, fixing the
issue for everybody. Please add a comment with the reference to this bug
report and remove the file once kdesu was fixed upstream.


kdesu is now cordially shipping the file in the package. :-)

Would you mind to comment why this is OK from a security perspective ?

I’m no security expert at all but if I read the CVE description 
correctly, the issue is with the su'ed command being able to escape the 
su user session.
Is it OK in this case because kdesu is used to gain root from non-root 
and so escaping the su session only gives you back the original non-root 
user rights ?



Thanks,
--
Aurélien

Bug#868875: Your thoughts about #868875

[Paride Legovini]

Hi,

IIUC we can mark this as done in Version: 0.31-1, which includes 
upstream commit 98b048f9d2f4319689d46507537587d391e41332, am I right?


See: https://github.com/canonical/cloud-utils/commit/98b048f9d2f4

Cheers,

Paride

Bug#1012210: linux-image-5.10.0-14-amd64: Kernels of Bullseye and Testing (5.10 and 5.17) hang at boot

[Markus Kolb]

Package: src:linux
Version: 5.10.113-1
Severity: important

Dear Maintainer,

I've updated an older typewriter computer from Stretch to Buster and
from there to Bullseye.

The kernel linux-image-4.19.0-20-amd64 from Buster works.
This one is used at the moment for reportbug!

But anything from the newer versions hangs during boot.
I've tried the release kernel of Bullseye, 
the security-updated linux-image-5.10.0-14-amd64, 
the newest one from backports 
and the latest version from testing, which has been a 5.17 version.

I've tried to start up with boot option boot_delay=1000, but then it
already hangs/crashes after the line of loading the initial ramdisk.
Can only switch off/on the computer afterwards. Num-lock switch is
dead.

Without the boot_delay option, there is some fast kernel output and I've
filmed with my camera.

Between working and crashing kernel there is some difference in the SATA
ports. And these are the last lines of output before the screen becomes
black and there isn't any reaction of the computer any longer.

This is a working boot with the Buster-kernel:

[1.800181] hub 7-0:1.0: USB hub found
[1.800226] hub 7-0:1.0: 2 ports detected
[1.816820] scsi host1: ahci
[1.817122] scsi host3: ahci
[1.817395] scsi host4: ahci
[1.817663] scsi host5: ahci
[1.817939] scsi host6: ahci
[1.818297] scsi host7: ahci
[1.818430] ata3: SATA max UDMA/133 abar m2048@0xf01a6000 port
0xf01a6100 irq 25
[1.818489] ata4: SATA max UDMA/133 abar m2048@0xf01a6000 port
0xf01a6180 irq 25
[1.818547] ata5: DUMMY
[1.818582] ata6: DUMMY
[1.818618] ata7: SATA max UDMA/133 abar m2048@0xf01a6000 port
0xf01a6300 irq 25
[1.818678] ata8: SATA max UDMA/133 abar m2048@0xf01a6000 port
0xf01a6380 irq 25
[1.819353] scsi host2: ata_generic
[1.819448] ata1: PATA max UDMA/100 cmd 0x1218 ctl 0x1240 bmdma
0x1200 irq 18
[1.819494] ata2: PATA max UDMA/100 cmd 0x1220 ctl 0x1244 bmdma
0x1208 irq 18
[1.879056] pci :00:00.0: Intel Q35 Chipset
[1.879122] pci :00:00.0: detected gtt size: 524288K total,
262144K mappable
[1.879855] pci :00:00.0: detected 8192K stolen memory
[1.879947] [drm] Replacing VGA console driver
[1.880476] Console: switching to colour dummy device 80x25
[1.880940] [drm] ACPI BIOS requests an excessive sleep of 1124034056
ms, using 1500 ms instead
[1.884726] [drm] Supports vblank timestamp caching Rev 2
(21.10.2013).
[1.884730] [drm] Driver supports precise vblank timestamp query.


With Bullseye-kernel I can't see the line for scsi hosts 1 and 3.
But maybe the order is differently and it is not viewable before the
screen becomes black. So maybe also a problem with console switching and
i915 graphic?

I'll upload the video to opened bug report.

I hope you can help me?! Do you know some boot options for the kernel I
could try to get the newer kernels to work?

br
Markus


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Hewlett-Packard
product_name: HP Compaq dc7800p Small Form Factor
product_version: 
chassis_vendor: Hewlett-Packard
chassis_version: 
bios_vendor: Hewlett-Packard
bios_version: 786F1 v01.35
board_vendor: Hewlett-Packard
board_name: 0AA8h
board_version: 

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 82Q35 Express DRAM Controller 
[8086:29b0] (rev 02)
Subsystem: Hewlett-Packard Company 82Q35 Express DRAM Controller 
[103c:2818]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation 82Q35 Express 
Integrated Graphics Controller [8086:29b2] (rev 02) (prog-if 00 [VGA 
controller])
Subsystem: Hewlett-Packard Company 82Q35 Express Integrated Graphics 
Controller [103c:2818]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:03.0 Communication controller [0780]: Intel Corporation 82Q35 Express MEI 
Controller [8086:29b4] (rev 02)
Subsystem: Hewlett-Packard Company 82Q35 Express MEI Controller 
[103c:2818]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel modules: mei_me

00:03.2 IDE interface [0101]: Intel Corporation 82Q35 Express PT IDER 
Controller [8086:29b6] (rev 02) (prog-if 85 [PCI native mode-only controller, 
supports bus mastering])
Subsystem: Hewlett-Packard Company 82Q35 Express PT IDER Controller 
[103c:2818]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 

Bug#1012208: unblock: python-pytest-asyncio/0.18.2-1

[Julian Gilbey]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python-pytest-asyncio

(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)

[ Reason ]
python-pytest-asyncio and pytest-mock need to be upgraded together;
pytest-mock 3.7.0-2 build-depends on the newer version of
python-pytest-asyncio (0.18.2-1), while the older version of
pytest-mock (3.6.1-1) breaks with it.  So python-pytest-asyncio can't
transition because it will break the version of pytest-mock already in
testing, and pytest-mock can't transition because of the
build-dependency on the newer python-pytest-asyncio.

[ Impact ]
(What is the impact for the user if the unblock isn't granted?)
python3-jupyter-kernels won't transition, and so I can't get the newer
verion of spyder into testing either (I haven't uploaded it to
unstable yet, though).

[ Tests ]
(What automated or manual tests cover the affected code?)
It's the autopkgtests that are blocking things; they succeed (at least
for me) if the newer versions of both packages are used.

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)
A lot of packages use these in their testing suites.

[ Checklist ]
  [ ] all changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing
  not so relevant here?

[ Other info ]
(Anything else the release team should know.)

unblock python-pytest-asyncio/0.18.2-1

Bug#1012209: debian-boot: Please include dm-cache in rescue kernel

[Nagy Attila]

Package: debian-boot
Version: 4.19.0-20-amd64
Severity: wishlist

Dear Maintainer,


Please include dm-cache and possibly all dm-* modules in the rescue kernel. The 
lack of these modules
makes the rescue process very complicated for a sytem where dm-cache was
applied to an important logical volume.


   * What led up to the situation?

We are using LVM2 and an dm-cache to speed up some of the volumes with SSD that 
are
run on HDD-s. We had an issue where we could not boot the system, so as
normally we turned to the rescue mode of the installer to reinstall the boot
partition and parts of the kernel. Unfortunately the /var partition is
backed up by lvm-cache and the rescue disk was not able to bring it up.


   * What exactly did you do (or not do) that was effective (or ineffective)?

We tried several ways to load the missing modules from the installer, but
were not able to find any.

As a last resolt we were able to find a rescue disk matching the exact
kernel version the system was on, so we could load the kernel modules from
the still accessible logical volumes.


   * What was the outcome of this action?

We were able to recover the system, but the process was much more
complicated than it normally would.


   * What outcome did you expect instead?

Because dm-cache and the relevant modules are part of the official debian
kernel package (linux-image-4.19.0-20-amd64) we expected these modules
readily be available for the rescue kernel as well.

An alternative, but more complication solution would be if the installer
would detect these types of LVs and download the driver automatically or
upon request.

Thank you


-- System Information:
Debian Release: 10.12
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-20-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#782323: linux-image-3.16.0-4-amd64: setting net.ipv6.conf.all.accept_ra to 0 has no effect, thus does not protect against SLAAC attacks

[Diederik de Haas]

On Wednesday, 1 June 2022 11:36:03 CEST Vincent Lefevre wrote:
> I may have an explanation of the issue (this would not be a kernel bug and
> the switch to systemd may have fixed it). There's an upstream related
> kernel bug
> 
> Now, with systemd, there is documentation at
> 
>   https://www.freedesktop.org/software/systemd/man/sysctl.d.html
> 
> which says in particular:
> 
>   The settings configured with sysctl.d files will be applied early
>   on boot. The network interface-specific options will also be
>   applied individually for each network interface as it shows up in
>   the system. (More specifically, net.ipv4.conf.*, net.ipv6.conf.*,
>   net.ipv4.neigh.* and net.ipv6.neigh.*).
> 
> So, if I understand correctly, the settings are now read much earlier,
> and normally before the network interfaces show up. Thus everything
> should now be fine.

Great that you found a (potential) proper fix. I hope it works for you :-)

signature.asc
Description: This is a digitally signed message part.

Bug#782323: linux-image-3.16.0-4-amd64: setting net.ipv6.conf.all.accept_ra to 0 has no effect, thus does not protect against SLAAC attacks

[Vincent Lefevre]

Hi,

On 2022-06-01 00:35:03 +0200, Diederik de Haas wrote:
> This bug was filed against kernel version 3.16 and the chance that
> an upstream kernel developer will devote time to it is ~ 0%, so I'm
> closing this bug.
> 
> If you can reproduce it with
> 
> - the current version in unstable/testing
> - the latest kernel from backports
> 
> please reopen the bug, see https://www.debian.org/Bugs/server-control
> for details.

I cannot test (at least at the moment), but after some search, I may
have an explanation of the issue (this would not be a kernel bug and
the switch to systemd may have fixed it). There's an upstream related
kernel bug

  https://bugzilla.kernel.org/show_bug.cgi?id=11655
  "/proc/sys/net/ipv6/conf/all/* controls don't work"

regarded as invalid, because the user was changing the settings
manually, and it is said that *.all.* variables must be set before
the device is created so that they are taken into account.

Now, in my case, I wasn't setting the variable manually, but via
the /etc/sysctl.conf file. So everything depends on when this file
is read. I've looked at old boot log files, and it was apparently
read via the /etc/init.d/procps script, which could be run rather
late, sometimes after the network was set up! So this was definitely
wrong.

Now, with systemd, there is documentation at

  https://www.freedesktop.org/software/systemd/man/sysctl.d.html

which says in particular:

  The settings configured with sysctl.d files will be applied early
  on boot. The network interface-specific options will also be
  applied individually for each network interface as it shows up in
  the system. (More specifically, net.ipv4.conf.*, net.ipv6.conf.*,
  net.ipv4.neigh.* and net.ipv6.neigh.*).

So, if I understand correctly, the settings are now read much earlier,
and normally before the network interfaces show up. Thus everything
should now be fine.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1010202: MatIO test failures against HDF5 1.12.0

[Sébastien Villemot]

Control: forcemerge 1011805 1010202

Le jeudi 19 mai 2022 à 23:39 +0200, Gilles Filippini a écrit :
> Thomas Beutlich a écrit le 19/05/2022 à 22:36 :
> > Am 19.05.2022 um 10:06 schrieb Sébastien Villemot:
> > > Le mardi 03 mai 2022 à 20:59 +0200, Thomas Beutlich a écrit :
> > > > Hi Sébastien,
> > > > it is the same test case that fails for three different HDF5-based
> > > > MAT files. My guess is some concurrency issue of the hdf5lib. Can you
> > > > please try:
> > > > * to run the testsuite sequentially
> > > >   * to not build libhdf with --enable-parallel, i.e. to have the
> > > > serial version of hdf5lib
> > > >   * set env var HDF5_USE_FILE_LOCKING=FALSE
> 
> Setting the above environment variable fixes the problem when running 
> the testsuite in parallel mode.

Thanks to both of you for your help on this issue.

Actually, it turns out that the problem is not related to HDF5 1.12.0,
but to a new debhelper version. More specifically, debhelper 13.7
enabled parallelization of autotest testsuites by default, which
exposed the underlying issue related to concurrency in HDF5.

In particular, the problem is also present in unstable (see #1011805).
Incidentally, this debhelper release also enabled verbose output of the
testsuite, which unfortunately makes the output look rather bad.

I am going to set HDF5_USE_FILE_LOCKING=FALSE when running the
testsuite.

Cheers,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org




signature.asc
Description: This is a digitally signed message part

Bug#900799: linux-image-arm64: dts: rockchip: correct voltage selector Firefly-RK3399

[Diederik de Haas]

On Fri, 22 Jun 2018 21:58:30 +0100 Ben Hutchings  wrote:
> Version: 4.17.2-1~exp1
> 
> On 5 Jun 2018 07:33:11 +0200 Heinrich Schuchardt  wrote:
> > Please, add this patch to the Debian kernel patches until it is added
> > upstream. Cf.
> > https://lkml.org/lkml/2018/6/4/781
> 
> This was applied in the above merge but not mentioned in the changelog
> due to a mis-merge.

In response Heiko says in https://lkml.org/lkml/2018/6/19/1167:
"and dropped again.

Sadly it looks like the patch causes conflicts with at least one firefly
board in a kernelci lab. My own is currently not ready to use, so I cannot
look myself right now.

The issue kernelci people described sounded quite a lot like the one
in your commit message, so my current theory is that the
suspend-voltage-selector must in some form corespond to the
cpu_b_sleep_h gpio setting we're currently not handling at all, which
would therefore depend on how the bootloader sets this up."

It's also not part of current upstream master, so this is a DTS change that is 
specific for Debian and possibly not needed and/or incorrect?

Heinrich, can you tell us more about the current status of this patch?

signature.asc
Description: This is a digitally signed message part.

Bug#1012154: binfmt-support.service errors with "unable to close /proc/sys/fs/binfmt_misc/register: File exists"

[Michael Biebl]

Control: reassign -1 systemd
Control: severity -1 important
Control: affects -1 binfmt-support

Hi Facundo,

what you see here is a race condition between binfmt-support.service and 
systemd-binfmt.service.
E.g. qemu installs binfmt config files for both binfmt-support and 
systemd-binfmt leading to the issue you see.


I plan to add a
ConditionFileIsExecutable=!/usr/sbin/update-binfmts
to systemd-binfmt.service. This will disable systemd-binfmt.service when 
binfmt-support is installed and should mitigate this issue.

(thus reassigning to systemd)

Afaics binfmt-support has remained a Debian-only solution, so long-term 
I'd think it would be beneficial if we'd consider systemd-binfmt as a 
cross-distro solution.


There aren't that many packages installing config snippets in 
/usr/share/binfmts, so a transition seems reasonably doable.


Colin, what's your take on this?

Michael




On Mon, 30 May 2022 19:22:09 -0300 Facundo Gaich  
wrote:

Package: binfmt-support
Version: 2.2.1-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The binfmt-support service fails to start, with the following output:

systemd[1]: Starting Enable support for additional executable binary formats...
update-binfmts[536]: update-binfmts: warning: unable to close 
/proc/sys/fs/binfmt_misc/register: File exists
update-binfmts[536]: update-binfmts: warning: unable to close 
/proc/sys/fs/binfmt_misc/register: File exists
update-binfmts[536]: update-binfmts: warning: unable to close 
/proc/sys/fs/binfmt_misc/register: File exists
update-binfmts[536]: update-binfmts: exiting due to previous errors
systemd[1]: binfmt-support.service: Main process exited, code=exited, 
status=2/INVALIDARGUMENT
systemd[1]: binfmt-support.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Enable support for additional executable binary 
formats.

Best,
Facundo

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-3-amd64 (SMP w/6 CPU threads; PREEMPT)
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 binfmt-support depends on:
ii  libc6 2.33-7
ii  libpipeline1  1.5.6-1
ii  lsb-base  11.2

binfmt-support recommends no packages.

binfmt-support suggests no packages.

-- no debconf information




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012207: restic: Please package new upstream version 0.13.1

[WMR]

Package: restic
Version: 0.12.1-2
Severity: wishlist
Tags: upstream

Dear Maintainer,

it would be nice if 0.13.x was available. 


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Architecture: aarch64

Kernel: Linux 5.15.32-v8+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages restic depends on:
ii  libc6  2.31-13+rpt2+rpi1+deb11u2

Versions of packages restic recommends:
ii  fuse  2.9.9-5

Versions of packages restic suggests:
ii  libjs-sphinxdoc  3.4.3-2
pn  sphinx-rtd-theme-common  

-- no debconf information

Bug#1012203: purple-matrix: Plugin not usable anymore

[Alberto Garcia]

On Wed, Jun 01, 2022 at 09:29:47AM +0200, Jean-Philippe MENGUAL wrote:

> using the plugin to connect to matrix, the server seems to require
> ssl and says that is not supported. Perhaps an upgrade of the
> package could implement it?

Hello,

I have given up this package for adoption more than 6 months ago
because I don't use it and I'm no longer interested in maintaining it:

   https://bugs.debian.org/998660

Fixing this (i.e. updating it to the latest version) should be trivial
to do, but if no one is interested in taking over the maintenance I
don't think it makes much sense.

The maintenance itself is very little work, it should be easy to
handle by anyone.

Berto

Bug#1012206: skeleton plugin cmake file causing build errors for consumers

[Guido Berhoerster]

Package: qtpim5-dev
Version: 5.0~git20201102.f9a8f0fc+dfsg1-1
Owner: sunwea...@debian.org
Severity: important
Tags: patch

The Debian package removes the skeleton plugin but installs the
corresponding cmake file. Qt5OrganizerConfig.cmake includes all
plugin cmake files and which results in an error because the actual
plugin is not found, i.e. this causes build errors for all consumers
using cmake.

If the plugin isn't there the corresponding cmake file shouldn't be
there. Attached patch fixes the packaging.
-- 
Guido Berhoerster
>From 7a9d3a97847caee774a02f6628ce78966cea267e Mon Sep 17 00:00:00 2001
From: Guido Berhoerster 
Date: Fri, 27 May 2022 15:38:38 +0200
Subject: [PATCH] Remove cmake file belonging skeleton plugin

The skeleton plugin cmake file needs to be removed as well, otherwise
find_package() will error out due to the missing plugin.
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 7093392..3b6e3f3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -73,7 +73,8 @@ override_dh_auto_install:
 	# Remove libtool-like files
 	rm -f debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/*.la
 	# Don't install the skeleton plugin
-	rm -f debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/qt5/plugins/organizer/libqtorganizer_skeleton.so
+	rm -f debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/qt5/plugins/organizer/libqtorganizer_skeleton.so \
+	debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/cmake/Qt5Organizer/Qt5Organizer_QSkeletonOrganizerPlugin.cmake
 
 	if [ -e /usr/lib/$(DEB_HOST_MULTIARCH)/qt5/bin/qdoc ]; then \
 	mkdir -p debian/tmp/usr/share/doc/qtpim-doc-html/; \
-- 
2.25.1

Bug#1012191: tzdata: /usr/share/zoneinfo/leap-seconds.list will expire on 2022-06-28 in Debian Stable 11.x/Bullseye

[Patrik Schindler]

This bug currently appears also with Bullseye on some dozens of installs for me.

Bug#1012205: O: rush -- restricted user shell

[Bastian Germann]

Package: wnpp

The current maintainer of rush, Mats Erik Andersson
, is apparently not active anymore.
Therefore, this package has been orphaned (see related #986997).

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.