Bug#1013876: webext-keepassxc-browser: Version 1.8.0+repack1-2 fail to load in chromium

[Bruno Kleinert]

Am Sonntag, dem 26.06.2022 um 14:11 +0200 schrieb Guillem Jover:
> Package: webext-keepassxc-browser
> Version: 1.8.0+repack1-2
> Severity: serious
> 
> Hi!
> 
> This version seems to fail load on chromium 103.0.5060.53-1, with the
> following warnings and errors shown on the extensions settings page:
> 
>   (W) Unrecognized manifest key 'applications'.
>   (W) Manifest version 2 is deprecated, and support will be removed
> in 2023.
>   See https://developer.chrome.com/blog/mv2-transition/ for more
> details.
>   (E) Uncaught TypeError: Bootstrap's JavaScript requires jQuery.
> jQuery must be included before Bootstrap's JavaScript.
>   Context: popups/popup.html
>   Stack Trace: bootstrap/bootstrap.js:221 (anonymous function)
>   (E) Uncaught (in promise) ReferenceError: browser is not defined
>   Context: popups/popup.html
>   Stack Trace: popups/popup_functions.js:74 (anonymous function)
>   (E) Uncaught ReferenceError: browser is not defined
>   Context: popups/popup.html
>   Stack Trace: common/translate.js:11 (anonymous function)
>   (E) Uncaught (in promise) ReferenceError: browser is not defined
>   Context: popups/popup.html
>   Stack Trace: popups/popup_functions.js:40 (anonymous function)
>   (E) Uncaught ReferenceError: browser is not defined
>   Context: _generated_background_page.html
>   Stack Trace: common/global.js:161 (anonymous function)
>   (E) Uncaught ReferenceError: browser is not defined
>   Context: _generated_background_page.html
>   Stack Trace: background/keepass.js:39 (anonymous function)
>   (E) Uncaught ReferenceError: browser is not defined
>   Context: _generated_background_page.html
>   Stack Trace: background/init.js:23 (anonymous function)
> 
> Thanks,
> Guillem

Hi Guillem,

thanks for the report. Something else in 1.8.0 is bugging me that may
be related to upstream's jQuery removal. I'm expecting upstream may
release 1.8.1 soonish.

Kind regards,
Bruno


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

Bug#1013902: RFS: bosch_career/1.0.1 [ITP] -- Avoid possible misuse of a package ID

[Frederik]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: debian-report...@frederikheld.de

Dear Mentors,

I am looking for a sponsor for my package "bosch_career":

* Package name: bosch_career
  Version: 1.0.1
* URL: https://github.com/frederikheld/bosch_career
* License: GNU GPLv3
* VCS: https://github.com/frederikheld/bosch_career

The Source builds the following binary packages:

  bosch_career - Educational package about package security and the question 
what 'being a software company' means.

To access further information about this package, please visit the following 
URL:

  https://github.com/frederikheld/bosch_career/README.md
  
https://github.com/frederikheld/bosch_career/blob/main/bosch_career/__main__.py

Regards,
Frederik

Bug#1013900: O: sigscheme -- Scheme Interpreter to be embedded

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: normal
Control: affects -1 src:sigscheme

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the sigscheme package.

The package decription is:
 SigScheme is a Scheme interpreter, which targets embedded programs.
 SigScheme is used as extension engine for uim, universal input method
 system.  It conforms to R5RS, some of SRFI-s.

It works and has reverse dependency with uim.

My personal life became busy and I finally lost my motivation,
so I intend to orphan this package.
- -- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEECynYjkLmt2W42OpQeDlhndQ5Zo4FAmK5CDoPHGRhaUBkZWJp
YW4ub3JnAAoJEHg5YZ3UOWaOSugQAMxFKjIYJ1J9F+3a6es7JzoB00TIOcaBs++m
zosWqMrKMzrNRcWApBAe1dXFPj0Cgsq9XP6E+NiajjdB9WJQn3Ks6/FWgm1osrGt
13+bMGmdgsoCHwXk2B/IxveQQ9Z5zhvwhxYDhQSVMBW1zlpwd5AxLDlxbCKoNIwm
sAHUeR7N/yJ+Y2jHRvBSAlggWN+pkvFyTkbCneFEDZZVViN3rbsiTkut1tbkw2iq
TOCkbJpaNDkDqkmX/eNWF8EYBK7c7XBZKqRSgwAstGiCwaoxJFLR+yrR5kWKCh25
sLiVof/4GLhu3ABHzskls3YS9rn055TNp0mT1RWgYg7V9dfo+B/K5HAABxZAsm1w
kxAw0S574NK57uQs0pu/N/YWjL48vBmJYTb3DBpoWynXea5/4Koo9psJlG00jU1L
TOXqm57Si2ZwLsqRJOMOMVwci3wFIU2p+VslF/0i86KevmOPDOimew2MH4l4aU2V
xaexM6xRjsJsNGEK69KmicKFah4fO7EICbNIwLs1aY7u05rsN47JKQuJ7rMJsonh
Z0F8UZJDDFhevNW+87blbfxsoH2//LK8YS/aUnpw7pITFsxtO6v3Wjs233wq2i94
lnp+8XMNslb7g11ydtNOpwcdsHIWVRJflmk1bvLWeNMfAhW5ftQBDx11d58/Jggf
FcssK1D9
=eFmK
-END PGP SIGNATURE-

Bug#1012847: (no subject)

[William Desportes]

Control: tags 1012847 + fixed

Upload is done, it is in process now.

Bug#1013899: O: t-code -- Japanese direct input method environment for emacsen

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: normal
Control: affects -1 src:t-code

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the t-code package.

The package decription is:
 This package is provides tc2. the T-Code input environment for emacsen,
 which enables you to input Japanese characters with T-Code or TUT-Code.
 .
 T-Code is a Japanese input method that doesn't use Kana-to-Kanji
 conversion.  You can input Kanji characters directly in the same way
 of inputting Hiragana.  TUT-Code is an alternative to T-Code.

It works and has reverse dependency with uim.

My personal life became busy and I finally lost my motivation,
so I intend to orphan this package.
- -- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEECynYjkLmt2W42OpQeDlhndQ5Zo4FAmK5AmYPHGRhaUBkZWJp
YW4ub3JnAAoJEHg5YZ3UOWaOixoP/39xq6TCFb31EbZNIhcip5fhQcSb3nbUBnOk
RevvoDvvn4ufygwdNmdb5nY5CRH8gVW/+VLi3t5FdQ390i82ald3Wp6y1YFmwO57
T0hbB7yQZZ5j3Srp2ruDXcO42KdSCuWCk96qao8ctQamnOe3TyE5BGK7JxrEugpB
nBa/gWsJHQjxQ95A8T1bv3gyICxlKrhQEVfEiim/CIn0abKk8T+JuBcftHpH4Czo
NCOuwZRn1gE3JBcx+lufHRxu78dTQndIBdt4NKERjZPOgfdScuoL8/GwMh66Q3vL
Pb5eSIGz7b8M59foDsxgeZ927eEmoK9kb0vmAlS5PgmWqu44sKel9tI1NKGfaYtO
tIkSpn8EFlG47RyqJN8FcV1qPt7dJp6qkP8MNlQ3fc25pGF7XHBjeqvB1pCQgL4C
AAJgUEpoMjgVmjwQl9wQ9w/5SyvHgnHs6Bb9MU6d34tPa1M+deVZDohkfVqDwuXo
ZXrVZDBbxbnI6wHPiSGnIwELtMu+AryxCZUuXEmKMNi5k05yh6f4+MO7FAuJuGuq
e/sHmeT+nAEOp/4PnS4A0097F9mb7eeJ6OmtRbSr0YKd3EFmazh9lfGSuFHHQF3F
Th63nVH9FleG/2V0pY9qXFuYvCHzOyEyoxSCJFROo9CeI4pt4pJPnOu/RDeBM3C1
m8hgrw/v
=6a8I
-END PGP SIGNATURE-

Bug#1013869: rust-reqwest: feature rustls-tls has disappeared

[plugwash]

On 27/06/2022 01:15, Jonas Smedegaard wrote:

Thanks for clarifying.

I consider it a *horrific* bug that an interface is explicitly
advertised as available, linking against it succeeds, yet it is
non-functional.

In my opinion this renders the whole package unsuitable for release, and
I hereby flag this bugreport as such.

Please as a minimum ensure that broken or missing features are *not*
advertised by the package.


I'll remove the rustls support completely until/unless it can be 
re-enabled in a sane form.


but lets be clear not every "feature" that exists in a rust crate 
actually provides useful functionality. The "feature" 
"rustls-native-certs" was never advertised as providing any particular 
functionality. At this point I have only removed features, I have not 
changed the functionality of any existing features. Depending on the 
"feature" "rustls-native-certs" would be just as useless with the 
unmodified upstream source as it would be with my patched version.


Assuming tokio-rustls and hyper-rustls are packaged, I do intend to 
switch the "rustls-tls" feature from being an alias for 
"rustls-tls-webpki-roots" to being an alias for 
"rustls-tls-native-roots" in line with what I believe is appropriate for 
Debian. Indeed I already have a patch in the package doing that, but the 
feature is currently removed completely by a patch later in the series.

Bug#1013898: significantly slower than 3.0.17.4-3

[Joey Hess]

Package: vlc
Version: 3.0.17.4-4
Severity: normal

I'm seeing only a few frames per second with -4 on 1080p H264 video.
After downgrading to -3, it's back to ~60 FPS.

This is the last part of the output of -4. The VA-API stuff seems relevant
somehow since the changelog says that was disabled in this version, but
I'm only guessing.

[7fb0d8028210] gl gl: Initialized libplacebo v4.192.1 (API v192)
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
[7fb0f0c1f940] avcodec decoder: Using OpenGL/VAAPI backend for VDPAU for 
hardware decoding

With -3, the output is the same except for the last line, which is:

[7fcc00c1d530] avcodec decoder: Using Intel iHD driver for Intel(R) Gen 
Graphics - 22.4.3 () for hardware decoding

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 vlc depends on:
ii  vlc-bin  3.0.17.4-4
ii  vlc-plugin-base  3.0.17.4-4
ii  vlc-plugin-qt3.0.17.4-4
ii  vlc-plugin-video-output  3.0.17.4-4

Versions of packages vlc recommends:
pn  vlc-l10n   
pn  vlc-plugin-access-extra
pn  vlc-plugin-notify  
pn  vlc-plugin-samba   
ii  vlc-plugin-skins2  3.0.17.4-4
pn  vlc-plugin-video-splitter  
pn  vlc-plugin-visualization   

Versions of packages vlc suggests:
pn  vlc-plugin-fluidsynth  
pn  vlc-plugin-jack
ii  vlc-plugin-pipewire3-2
pn  vlc-plugin-svg 

Versions of packages libvlc-bin depends on:
ii  libc62.33-7
ii  libvlc5  3.0.17.4-4

Versions of packages libvlc5 depends on:
ii  libc62.33-7
ii  libvlccore9  3.0.17.4-4

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.17.4-4

Versions of packages libvlccore8 depends on:
ii  dpkg 1.21.8
ii  libc62.33-7
ii  libdbus-1-3  1.14.0-1
ii  libidn11 1.33-3

Versions of packages libvlccore8 recommends:
ii  libproxy-tools  0.4.17-2

Versions of packages vlc-bin depends on:
ii  libc6   2.33-7
ii  libvlc-bin  3.0.17.4-4
ii  libvlc5 3.0.17.4-4

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-20
ii  libarchive13 3.6.0-1
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.2.6.1-2+b1
ii  libass9  1:0.16.0-1
ii  libavahi-client3 0.8-6
ii  libavahi-common3 0.8-6
ii  libavc1394-0 0.5.4-5
ii  libavcodec59 7:5.0.1-3
ii  libavformat597:5.0.1-3
ii  libavutil57  7:5.0.1-3
ii  libbluray2   1:1.3.1-2
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libcddb2 1.3.2-7
ii  libchromaprint1  1.5.1-2+b1
ii  libdav1d61.0.0-2
ii  libdbus-1-3  1.14.0-1
ii  libdc1394-25 2.2.6-4
ii  libdca0  0.0.7-2
ii  libdvbpsi10  1.3.3-1
ii  libdvdnav4   6.1.1-1
ii  libdvdread8  6.1.3-1
ii  libebml5 1.4.2-2
ii  libfaad2 2.10.0-2
ii  libflac8 1.3.4-2
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-3
ii  libfribidi0  1.0.8-2.1
ii  libgcc-s112.1.0-4
ii  libgcrypt20  1.10.1-2
ii  libglib2.0-0 2.72.2-2
ii  libgnutls30  3.7.6-2
ii  libgpg-error01.45-2
ii  libharfbuzz0b2.7.4-1+b1
ii  libixml101:1.8.4-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  libkate1 0.4.1-11
ii  liblirc-client0  0.10.1-7
ii  liblua5.2-0  5.2.4-2
ii  libmad0  0.15.1b-10
ii  libmatroska7 1.6.3-2
ii  libmpcdec6   2:0.1~r495-2
ii  libmpeg2-4   0.5.1-9
ii  libmpg123-0  1.29.3-1
ii  libmtp9  1.1.19-1
ii  libncursesw6 

Bug#1013869: rust-reqwest: feature rustls-tls has disappeared

[Jonas Smedegaard]

Control: severity -1 serious

Quoting Peter Michael Green (2022-06-26 23:40:37)
> 
> On 26/06/2022 18:40, Jonas Smedegaard wrote:
> > Quoting Peter Michael Green (2022-06-26 19:01:04)
> >> To enable rustls support with native or manual roots two crates which
> >> are not in Debian, tokio-rustls and hyper-rustls. For tokio-rustls
> >> Alexander Kjäll prepared a package, which I have just sponsored into
> >> NEW. I don't see any evidence that anyone is working on hyper-rustls
> >> however.
> > Not sure what you are saying above.  Feature "rustls-native-certs" *is*
> > currently offered.  Are you saying that that is broken until either of
> > tokio-rustls or hyper-rustls gets into Debian?!?
> 
> In rust every optional dependency is automatically a "feature"
> even if it is not actually intended to be used as one by downstream
> crates.
> 
> I could have stripped out the rustls stuff completely, in retrospect
> it would have been less confusing to do it that way, rather than
> what I did which was going through the unsatisfiable optional
> dependencies one by one patching out the optional depedency
> and the features that depend on it. This left some "orphan" optional
> dependencies which are satisfiable but aren't much use right now.
> 
> Depending on the "rustls-native-certs" feature is not a route to
> functioning tls support.
> 

Thanks for clarifying.

I consider it a *horrific* bug that an interface is explicitly
advertised as available, linking against it succeeds, yet it is
non-functional.

In my opinion this renders the whole package unsuitable for release, and
I hereby flag this bugreport as such.

Please as a minimum ensure that broken or missing features are *not*
advertised by the package.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1012600: fixed in zfs-linux 2.1.5-1

[yahg]

On Thu, 23 Jun 2022 04:06:10 + Debian FTP Masters 
 wrote:


> Source: zfs-linux
> Source-Version: 2.1.5-1
> Done: Mo Zhou 
>
> We believe that the bug you reported is fixed in the latest version of
> zfs-linux, which is due to be installed in the Debian FTP archive.

For those of you who are using bookworm/testing and don't want to wait 
for the packages to drop from sid/unstable, you can download the 
sid/unstable packages as .deb files and install them yourself. This is 
potentially dangerous so don't proceed if you can wait.


I have installed: zfs-dkms, zfsutils-linux and zfs-zed. By starting at 
the top I found the dependencies. Below are the files in the order I had 
success with. I installed:

  sudo dpkg -i /tmp/zfs/libnvpair3linux_2.1.5-1_amd64.deb
  sudo dpkg -i /tmp/zfs/libuutil3linux_2.1.5-1_amd64.deb
  sudo dpkg -i /tmp/zfs/libzfs4linux_2.1.5-1_amd64.deb
  sudo dpkg -i /tmp/zfs/libzpool5linux_2.1.5-1_amd64.deb
  sudo dpkg -i /tmp/zfs/zfsutils-linux_2.1.5-1_amd64.deb

The last failed but only because it was waiting for the next package:

  sudo dpkg -i /tmp/zfs/zfs-dkms_2.1.5-1_all.deb

I next reinstalled the one that failed on the assumption that it might 
not be totally finished


  sudo dpkg -i /tmp/zfs/zfsutils-linux_2.1.5-1_amd64.deb
  sudo dpkg -i /tmp/zfs/zfs-zed_2.1.5-1_amd64.deb

A quick reboot, but zfs did not restart. I found in the syslog:
  Import ZFS pools by cache file was skipped because of a failed 
condition check (ConditionFileNotEmpty=/etc/zfs/zpool.cache)


I found a fix:
  sudo zpool import -a

After this I am able to use zfs in testing on linux 5.18. I don't know 
if I will have to repeat "zpool import -a" at my next reboot, but it 
seems like it is a possibility. I want to make clear I have no more than 
a superficial understanding of why this worked, nor do I know what the 
implications of hand-installing packages will be on later updates. Use 
this information at your own risk.

Bug#1007717: Ballot and call for votes

[Elana Hashman]

On Mon, Jun 20, 2022 at 05:31:16PM -0700, Sean Whitton wrote:
> Hello,
> 
> I hereby call for votes on the following resolution:
> 
> BEGIN BALLOT
> 
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
> 
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
> 
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
> 
>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
> 
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
> 
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
> 
>   This is because ... [second paragraph as in 4a].
> 
>   5. We decline to comment on the recent source package format MBF.
> 
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.
> 
> END BALLOT

I vote:

C > A > X > N

- e


signature.asc
Description: PGP signature

Bug#1010595: xsimd: Bug#1010595 Please make xsimd available on all platforms

[Drew Parsons]

I don't know myself which xsimd test is which in order to implement the 
scalar test division discussed in upstream Issue#756. For sure upstream 
will know.


While we're resolving that, one simple thing we could do temporarily for 
the packaging is to restrict the CI tests to only run on the known 
vector-supported arches.  This can be done with just an Architecture: 
field added to the Test entries in debian/tests/control.


e.g. could copy the restricted Architecture line from debian/control 
over to the two tests in debian/tests/control, and then update 
debian/control to Architecture: any.


Drew

Bug#1013897: ITP: cfn-lint -- Validate AWS CloudFormation yaml/json templates against the AWS CloudFormation

[Guilherme de Paula Xavier Segundo]

Package: wnpp
Severity: wishlist
Owner: Guilherme de Paula Xavier Segundo 
X-Debbugs-Cc: debian-de...@lists.debian.org, guilherme@gmail.com

* Package name: cfn-lint
  Version : 0.61.1
  Upstream Author : Amazon.com, Inc. or its affiliates
* URL : https://github.com/aws-cloudformation/cfn-lint
* License : Expat
  Programming Lang: Python
  Description : CloudFormation Linter

 Validate AWS CloudFormation yaml/json templates against the AWS
 CloudFormation Resource Specification and additional checks. Includes
 checking valid values for resource properties and best practices.

Bug#1013896: qtbase-opensource-src: Use KDE Qt as upstream instead of qt.io

[Shmerl]

Source: qtbase-opensource-src
Version: 5.15.4+dfsg-3
Severity: wishlist
X-Debbugs-Cc: shtetl...@gmail.com

Dear Maintainer,

KDE team maintains important patchset over official Qt that has a lot of bug
fixes especially for the Wayland session use case.

May be you can switch upstream directly to KDE Qt instead of pulling it from
qt.io and then trying to add some patches?

See: https://invent.kde.org/qt/qt/qt5/-/tree/kde/5.15

Thanks!


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

Kernel: Linux 5.18.7 (SMP w/24 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1013895: RTL8188EUS 802.11n Wireless Network Adapter not working on 5.18

[Santiago Ruano Rincón]

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

Dear linux maintainers,

Not sure if this should be filed against firmware-realtek, and sorry if
that is the case. I have a WiFi USB dongle that doesn't work on linux
5.18, but it does work on 5.15.

You can see this error in the logs below during boot, or when I replug
the dongle:

 r8188eu 1-1.2:1.0: _rtw_init_xmit_priv failed

Maybe this is relevant:
https://lkml.org/lkml/2022/5/21/527

Thanks for your work,

 -- Santiago


lsusb -d 0bda:8179 -v:

Couldn't open device, some information will be missing

Bus 001 Device 003: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n 
Wireless Network Adapter
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0bda Realtek Semiconductor Corp.
  idProduct  0x8179 RTL8188EUS 802.11n Wireless Network Adapter
  bcdDevice0.00
  iManufacturer   1 Realtek
  iProduct2 802.11n NIC
  iSerial 3 00E04C0001
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x0027
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0


-- Package-specific info:
** Version:
Linux version 5.18.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.3.0-3) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.50.20220615) #1 SMP 
PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16)

** Command line:
BOOT_IMAGE=/vmlinuz-5.18.0-2-amd64 root=/dev/mapper/nomada--vg-root ro quiet

** Tainted: C (1024)
 * staging driver was loaded

** Kernel log:
[   65.967972] sr 1:0:0:0: Attached scsi generic sg1 type 5
[   66.200182] input: PC Speaker as /devices/platform/pcspkr/input/input9
[   66.205789] at24 0-0050: supply vcc not found, using dummy regulator
[   66.211386] iTCO_vendor_support: vendor-support=0
[   66.220396] at24 0-0050: 256 byte spd EEPROM, read-only
[   66.262644] EXT4-fs (sda1): mounting ext2 file system using the ext4 
subsystem
[   66.264240] EXT4-fs (sda1): mounted filesystem without journal. Quota mode: 
none.
[   66.264268] ext2 filesystem being mounted at /boot supports timestamps until 
2038 (0x7fff)
[   66.334031] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 163840 ms 
ovfl timer
[   66.334038] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules
[   66.334040] RAPL PMU: hw unit of domain package 2^-16 Joules
[   66.334042] RAPL PMU: hw unit of domain pp1-gpu 2^-16 Joules
[   66.359000] iTCO_wdt iTCO_wdt.1.auto: Found a Panther Point TCO device 
(Version=2, TCOBASE=0x0460)
[   66.359986] iTCO_wdt iTCO_wdt.1.auto: initialized. heartbeat=30 sec 
(nowayout=0)
[   66.360743] dcdbas dcdbas: Dell Systems Management Base Driver (version 
5.6.0-3.4)
[   66.373820] dell-smbios A80593CE-A997-11DA-B012-B622A1EF5492: WMI SMBIOS 
userspace interface not supported(0), try upgrading to a newer BIOS
[   66.406003] ACPI: AC: AC Adapter [AC] (off-line)
[   66.519073] audit: type=1400 audit(1656278514.058:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=574 
comm="apparmor_parser"
[   66.524501] audit: type=1400 audit(1656278514.062:3): 

Bug#1013894: findutils: d/copyright: Missing licenses

[Bastian Germann]

Source: findutils
Version: 4.9.0-3
Severity: important
Tags: patch

findutils' copyright file misses at least the following licenses:
LGPL-2.1+,
BSD-4-clause (UC -> 3-clause), and
ISC

Please find a d/copyright file attached that contains the missing licensesFormat: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Source: ftp://ftp.gnu.org/gnu/findutils
Comment: Debian maintainer history:
 The original package was put together by Ian Murdock ,
 afterwards Kevin Dalley  took over.
 2003-07 Andreas Metzler  followed.
 .
 GNU find was written by Eric Decker ,
 with enhancements by David MacKenzie ,
 Jay Plett ,
 and Tim Wood .
 The idea for -print0 and xargs -0 came from
 Dan Bernstein .
 Improvements have been made by James Youngman .
 .
 GNU xargs
 was originally written by Mike Rendell, with enhancements by David
 MacKenzie. Modifications by James Youngman Dmitry V. Levin
 .
 GNU locate and its associated utilities were originally
 written by James Woods, with enhancements by David MacKenzie, James Youngman
 and Bas van Gompel.
 .
 Upstream's AUTHORS lists these major contributors:
 Eric B. Decker
 Michael Rendell
 David J. MacKenzie
 Jim Meyering
 Tim Wood
 Kevin Dalley 
 Paul Eggert 
 James Youngman 
 Jay Plett
 Paul Sheer
 Dmitry V. Levin
 Bas van Gompel
 Eric Blake 
 Andreas Metzler
 Kamil Dudka  
 Bernhard Voelker 
Upstream-Contact: Current upstream maintainer is James Youngman .

Files: *
Copyright: (C) 1990-2022 Free Software Foundation, Inc.
License: GPL-3+

License: GPL-3+
   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation, either version 3 of the License, or
   (at your option) any later version.
 .
   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.
 .
   You should have received a copy of the GNU General Public License
   along with this program.  If not, see .
 .
 On Debian GNU/Linux systems, the complete text of the GNU General
 Public License version 3 can be found in `/usr/share/common-licenses/GPL-3'.

Files: doc/*
Copyright: (C) 1994-2022 Free Software Foundation, Inc.
License: GFDL-NIV-1.3
 Permission is granted to copy, distribute and/or modify this
 document under the terms of the GNU Free Documentation License,
 Version 1.3 or any later version published by the Free Software
 Foundation; with no Invariant Sections, no Front-Cover Texts, and
 no Back-Cover Texts.  A copy of the license is included in the
 section entitled "GNU Free Documentation License".
 .
 On Debian GNU/Linux systems, the complete text of the GNU Free Documentation
 License, Version 1.3 can be found in `/usr/share/common-licenses/GFDL-1.3'.

Files: gl/lib/cdefs.h
Copyright: (C) 1992-2022 Free Software Foundation, Inc.
   The GNU Toolchain Authors.
License: LGPL-2.1+

Files: gl/lib/fts.c
   gl/lib/fts_.h
Copyright: (C) 2004-2022 Free Software Foundation, Inc.
   (c) 1989, 1993 The Regents of the University of California.  All 
rights reserved.
License: GPL-3+ and BSD-4-clause-UC

Files: gnulib-tests/inet_pton.c
Copyright: (C) 2006, 2008-2022 Free Software Foundation, Inc.
   (c) 1996,1999 by Internet Software Consortium.
License: LGPL-2.1+ and ISC

License: LGPL-2.1+
   This file is free software: you can redistribute it and/or modify
   it under the terms of the GNU Lesser General Public License as
   published by the Free Software Foundation; either version 2.1 of the
   License, or (at your option) any later version.
 .
   This file is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU Lesser General Public License for more details.
 .
   You should have received a copy of the GNU Lesser General Public License
   along with this program.  If not, see .  */
 .
 On Debian GNU/Linux systems, the complete text of the GNU Lesser General
 Public License version 2.1 can be found in 
`/usr/share/common-licenses/LGPL-2.1'.

License: BSD-4-clause-UC
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
 1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
 2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
 4. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this 

Bug#1013869: rust-reqwest: feature rustls-tls has disappeared

[Peter Michael Green]

On 26/06/2022 18:40, Jonas Smedegaard wrote:

Quoting Peter Michael Green (2022-06-26 19:01:04)

To enable rustls support with native or manual roots two crates which
are not in Debian, tokio-rustls and hyper-rustls. For tokio-rustls
Alexander Kjäll prepared a package, which I have just sponsored into
NEW. I don't see any evidence that anyone is working on hyper-rustls
however.

Not sure what you are saying above.  Feature "rustls-native-certs" *is*
currently offered.  Are you saying that that is broken until either of
tokio-rustls or hyper-rustls gets into Debian?!?


In rust every optional dependency is automatically a "feature"
even if it is not actually intended to be used as one by downstream
crates.

I could have stripped out the rustls stuff completely, in retrospect
it would have been less confusing to do it that way, rather than
what I did which was going through the unsatisfiable optional
dependencies one by one patching out the optional depedency
and the features that depend on it. This left some "orphan" optional
dependencies which are satisfiable but aren't much use right now.

Depending on the "rustls-native-certs" feature is not a route to
functioning tls support.

Bug#1013892: qqwing: Solver gets stuck in an infinite loop on ARM

[Krzysztof Aleksander Pyrkosz]

Package: qqwing
Version: 1.3.4-1.1+b1
Severity: important
Tags: upstream
X-Debbugs-Cc: krzpyrk...@gmail.com

Dear Maintainer,

qqwing solver gets stuck in an infinite loop caused by casting return
value of getchar() from int to char. The comparison c == EOF is never
going to be true on systems where char is by default unsigned.

The offending line of code is:

main.cpp:491
char c = getchar();

Changing char to int solves the issue.

Bug#1013893: bullseye-pu: package rhonabwy/0.9.13-3+deb11u1

[Nicolas Mora]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
Fix possible buffer overflow when decrypting forged jwe with invalid iv or
cypherkey

[ Impact ]
program might crash or execute arbitrary code

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Check iv and cypherkey len before decoding them

[ Other info ]
CVE id pending
diff -Nru rhonabwy-0.9.13/debian/changelog rhonabwy-0.9.13/debian/changelog
--- rhonabwy-0.9.13/debian/changelog2021-09-22 07:29:46.0 -0400
+++ rhonabwy-0.9.13/debian/changelog2022-06-26 17:27:39.0 -0400
@@ -1,3 +1,9 @@
+rhonabwy (0.9.13-3+deb11u2) bullseye; urgency=medium
+
+  * d/patches/aesgcm.patch: Fix aesgcm buffer overflow
+
+ -- Nicolas Mora   Sun, 26 Jun 2022 17:27:39 -0400
+
 rhonabwy (0.9.13-3+deb11u1) bullseye; urgency=medium
 
   * d/patches/bugfixes: apply upstream bugfixes
diff -Nru rhonabwy-0.9.13/debian/patches/aesgcm.patch 
rhonabwy-0.9.13/debian/patches/aesgcm.patch
--- rhonabwy-0.9.13/debian/patches/aesgcm.patch 1969-12-31 19:00:00.0 
-0500
+++ rhonabwy-0.9.13/debian/patches/aesgcm.patch 2022-06-26 17:26:58.0 
-0400
@@ -0,0 +1,32 @@
+Description: Fix aesgcm buffer overflow
+Author: Nicolas Mora 
+Forwarded: not-needed
+--- a/src/jwe.c
 b/src/jwe.c
+@@ -226,14 +226,24 @@
+ ret = RHN_ERROR;
+ break;
+   }
++  if (!o_base64url_decode((const unsigned char 
*)r_jwe_get_header_str_value(jwe, "iv"), 
o_strlen(r_jwe_get_header_str_value(jwe, "iv")), NULL, _len) || iv_len > 96) 
{
++y_log_message(Y_LOG_LEVEL_ERROR, "r_jwe_aesgcm_key_unwrap - Invalid 
header iv");
++ret = RHN_ERROR_INVALID;
++break;
++  }
+   if (!o_base64url_decode((const unsigned char 
*)r_jwe_get_header_str_value(jwe, "iv"), 
o_strlen(r_jwe_get_header_str_value(jwe, "iv")), iv, _len)) {
+ y_log_message(Y_LOG_LEVEL_ERROR, "r_jwe_aesgcm_key_unwrap - Error 
o_base64url_decode iv");
+-ret = RHN_ERROR;
++ret = RHN_ERROR_INVALID;
++break;
++  }
++  if (!o_base64url_decode((const unsigned char 
*)jwe->encrypted_key_b64url, o_strlen((const char *)jwe->encrypted_key_b64url), 
NULL, _len) || cipherkey_len > 64) {
++y_log_message(Y_LOG_LEVEL_ERROR, "r_jwe_aesgcm_key_unwrap - Invalid 
cipherkey");
++ret = RHN_ERROR_INVALID;
+ break;
+   }
+   if (!o_base64url_decode((const unsigned char 
*)jwe->encrypted_key_b64url, o_strlen((const char *)jwe->encrypted_key_b64url), 
cipherkey, _len)) {
+ y_log_message(Y_LOG_LEVEL_ERROR, "r_jwe_aesgcm_key_unwrap - Error 
o_base64url_decode cipherkey");
+-ret = RHN_ERROR;
++ret = RHN_ERROR_INVALID;
+ break;
+   }
+   key_g.data = key;
diff -Nru rhonabwy-0.9.13/debian/patches/series 
rhonabwy-0.9.13/debian/patches/series
--- rhonabwy-0.9.13/debian/patches/series   2021-09-22 07:29:46.0 
-0400
+++ rhonabwy-0.9.13/debian/patches/series   2022-06-26 17:25:31.0 
-0400
@@ -1,3 +1,4 @@
 library_info.patch
 disable_test_rhonabwy_generate_key_pair.patch
 bugfixes.patch
+aesgcm.patch

Bug#1013752: Transition KDE PIM 22.04

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-06-26 12:11:16 -0500, Steven Robbins wrote:
> Hello,
> 
> Patrick suggested I chime in here, as the Digikam maintainer.
> 
> 
> On Sat, 25 Jun 2022 23:42:47 +0200 Sebastian Ramacher  
> wrote:
> > On 2022-06-25 20:45:37 +0200, Patrick Franz wrote:
> > > Hi Sebastian,
> > > 
> > > Am Samstag, 25. Juni 2022, 20:30:32 CEST schrieb Sebastian Ramacher:
> > > [...]
> > > > > A fixed version of kgpg is in experimental and just needs to be
> > > > > uploaded to unstable once KDE PIM 22.04 is uploaded there. There
> > > > > are patches available for both digikam and kjots. I can patch kjots
> > > > > myself and point the digikam maintainers to the existing patch.
> > > > 
> > > > Just to be clear: is the patch for digikam for kdepim compat or does
> > > > it also fix the build failure with ffmpeg 5.0?
> > > 
> > > It would be purely for KDE PIM (https://invent.kde.org/graphics/
> > > digikam/-/commit/51efe295a222070743187af0367b0bf957879337).
> > 
> > I see. If you (and the KDE team) are okay with temporarly removing
> > digikam from testing, then please feel free to go ahead.
> 
> I'm comfortable with digikam being temporarily removed from testing.  As was 
> pointed out, we still have the ffmpeg issue to deal with and I don't see any 
> value in holding up kdepim for that.

ACK, then please go ahead. I'll add a hint to remove digikam from
testing once kdepim is ready to migrate.

Cheers

> 
> Regards,
> -Steve



-- 
Sebastian Ramacher

Bug#1007717: Ballot and call for votes

[Niko Tyni]

On Mon, Jun 20, 2022 at 05:31:16PM -0700, Sean Whitton wrote:
 
> BEGIN BALLOT
> 
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
> 
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
> 
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
> 
>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
> 
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
> 
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
> 
>   This is because ... [second paragraph as in 4a].
> 
>   5. We decline to comment on the recent source package format MBF.
> 
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.
> 
> END BALLOT

I vote: C > A > X > N

-- 
Niko Tyni   nt...@debian.org


signature.asc
Description: PGP signature

Bug#1007884: bullseye-pu: package glewlwyd/2.5.2-2+deb11u2

[Nicolas Mora]

Control: tags -1 - moreinfo

Can you please review the last debdiff?

Bug#1013891: RM: foptions -- RoM: Retired upstream

[Dirk Eddelbuettel]

Package: ftp.debian.org
Severity: normal

The foptions package (binary: r-cran-foptions) is no longer on
CRAN and can be removed from unstable as well. It had two dependencies
(fasianoptions, fexoticoptions) which were already removed in #1013234 and
#1013235. 

If needed, old versions remain at
https://cran.r-project.org/web/packages/fOptions/index.html

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1012789: Bug#1012825: Removed symbol without major SONAME bump

[Petter Reinholdtsen]

[László Böszörményi]
> You are right that removing public symbols from a library interface
> is an ABI break and requires a SONAME change. Per coding standards
> function names starting with underscore are part of the private API
> and a) not to be used outside of the library, b) if used nevertheless,
> it's accepted that the other code can break anytime.

Which coding standards?  I believe the Debian policy require SONAME
changes when the ABI break.  Did I misunderstand?

> First of all, critical is used for several issues like making the
> system unbootable or causing huge data loss. That's not the case.

I base my understanding on
https://www.debian.org/Bugs/Developer#severities >, which state
the following for critical:

  * critical - makes unrelated software on the system (or the whole
system) break, or causes serious data loss, or introduces a security
hole on systems where you install the package.

My observation is that the libtiff change 'made unreleated software on
the system break', making this a bug with severity 'critical'.

> What you proposed is to diverge from tiff upstream and adding back the
> mentioned function, then forcing a SONAME change, doing a transition
> with over two hundred code rebuilds on fourteen architectures. This
> makes no sense.

To me it is the only approach that make sense when the ABI is broken.

> As noted above, the Python Tk library copies an internal tiff function
> and probably not just one but a whole set of those (just check its
> compat/libtiff/libtiff source directory).

Note, I do not try to defend the libtk-img developers.  To me their
behaviour is beside the point, which is that the tiff ABI broke (a
public symbol was removed) and the SONAME as not bumped.

-- 
Happy hacking
Petter Reinholdtsen

Bug#806960: Stardict leaking user data in default configuration.

[David Heidelberg]

Hello,

is it fixed in recent Debian packages or is it still leaking data?

If yes, shouldn't this bug have higher severity?

Thank you

--
David Heidelberg
Consultant Software Engineer

Matrix: @okias:matrix.org

Bug#1013890: gmp-ecm breaks sagemath autopkgtest: lots of issues

[Paul Gevers]

Source: gmp-ecm, sagemath
Control: found -1 gmp-ecm/7.0.5+ds-1
Control: found -1 sagemath/9.5-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of gmp-ecm the autopkgtest of sagemath fails in 
testing when that autopkgtest is run with the binary packages of gmp-ecm 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
gmp-ecmfrom testing7.0.5+ds-1
sagemath   from testing9.5-4
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of gmp-ecm to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gmp-ecm

https://ci.debian.net/data/autopkgtest/testing/amd64/s/sagemath/23080949/log.gz

sage -t --random-seed=254306892368924504610037307929798433555 
sage/src/sage/calculus/calculus.py

**
File "sage/src/sage/calculus/calculus.py", line 1642, in 
sage.calculus.calculus.laplace

Failed example:
a, cond
Expected:
(-oo, True)
Got:
(0, True)
**
1 item had failures:
   1 of  46 in sage.calculus.calculus.laplace
[451 tests, 1 failure, 11.81 s]

sage -t --random-seed=254306892368924504610037307929798433555 
sage/src/sage/combinat/cluster_algebra_quiver/interact.py

**
File "sage/src/sage/combinat/cluster_algebra_quiver/interact.py", line 
29, in sage.combinat.cluster_algebra_quiver.interact.cluster_interact

Failed example:
S.interact()   # indirect doctest
Expected:
VBox(children=...
Got:
doctest:warning
  File "/usr/bin/sage-runtests", line 155, in 
err = DC.run()
  File "/usr/lib/python3/dist-packages/sage/doctest/control.py", 
line 1261, in run

self.run_doctests()
  File "/usr/lib/python3/dist-packages/sage/doctest/control.py", 
line 962, in run_doctests

self.dispatcher.dispatch()
  File "/usr/lib/python3/dist-packages/sage/doctest/forker.py", 
line 2004, in dispatch

self.parallel_dispatch()
  File "/usr/lib/python3/dist-packages/sage/doctest/forker.py", 
line 1899, in parallel_dispatch

w.start()  # This might take some time
  File "/usr/lib/python3/dist-packages/sage/doctest/forker.py", 
line 2173, in start

super(DocTestWorker, self).start()
  File "/usr/lib/python3.10/multiprocessing/process.py", line 121, 
in start

self._popen = self._Popen(self)
  File "/usr/lib/python3.10/multiprocessing/context.py", line 224, 
in _Popen

return _default_context.get_context().Process._Popen(process_obj)
  File "/usr/lib/python3.10/multiprocessing/context.py", line 277, 
in _Popen

return Popen(process_obj)
  File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 
19, in __init__

self._launch(process_obj)
  File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 
71, in _launch

code = process_obj._bootstrap(parent_sentinel=child_r)
  File "/usr/lib/python3.10/multiprocessing/process.py", line 315, 
in _bootstrap

self.run()
  File "/usr/lib/python3/dist-packages/sage/doctest/forker.py", 
line 2145, in run

task(self.options, self.outtmpfile, msgpipe, self.result_queue)
  File "/usr/lib/python3/dist-packages/sage/doctest/forker.py", 
line 2475, in __call__

doctests, extras = self._run(runner, options, results)
  File "/usr/lib/python3/dist-packages/sage/doctest/forker.py", 
line 2527, in _run

result = runner.run(test)
  File "/usr/lib/python3/dist-packages/sage/doctest/forker.py", 
line 861, in run

return self._run(test, compileflags, out)
  File "/usr/lib/python3/dist-packages/sage/doctest/forker.py", 
line 694, in _run

self.compile_and_execute(example, compiler, test.globs)
  File "/usr/lib/python3/dist-packages/sage/doctest/forker.py", 
line 1088, in compile_and_execute

exec(compiled, globs)
  File "sage.combinat.cluster_algebra_quiver.interact.cluster_interact[1]>", 
line 1, in 

S.interact()   # indirect doctest
  File 
"/usr/lib/python3/dist-packages/sage/combinat/cluster_algebra_quiver/cluster_seed.py", 
line 1067, in interact

return cluster_interact(self, fig_size, circular, kind='seed')
  File 
"/usr/lib/python3/dist-packages/sage/combinat/cluster_algebra_quiver/interact.py", 
line 47, 

Bug#1013889: rpmlint: autopkgtest regression: No module named 'zstandard'

[Paul Gevers]

Source: rpmlint
Version: 2.3.0+ds1-0.1
Severity: serious
X-Debbugs-CC: Boyuan Yang 
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s), Boyuan,

With a recent upload of rpmlint the autopkgtest of rpmlint fails in 
testing when that autopkgtest is run with the binary packages of rpmlint 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
rpmlintfrom testing2.3.0+ds1-0.1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rpmlint

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rpmlint/23083611/log.gz

 ERRORS 

__ ERROR collecting test/test_cli.py 
___
ImportError while importing test module 
'/tmp/autopkgtest-lxc.i2hlbh7a/downtmp/build.cyC/src/test/test_cli.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3/dist-packages/_pytest/python.py:578: in _importtestmodule
mod = import_path(self.fspath, mode=importmode)
/usr/lib/python3/dist-packages/_pytest/pathlib.py:524: in import_path
importlib.import_module(module_name)
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
:1050: in _gcd_import
???
:1027: in _find_and_load
???
:1006: in _find_and_load_unlocked
???
:688: in _load_unlocked
???
/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:170: in 
exec_module

exec(co, module.__dict__)
test/test_cli.py:4: in 
from rpmlint.cli import process_lint_args
rpmlint/cli.py:6: in 
from rpmlint.lint import Lint
rpmlint/lint.py:14: in 
from rpmlint.pkg import FakePkg, get_installed_pkgs, Pkg
rpmlint/pkg.py:27: in 
import zstandard as zstd
E   ModuleNotFoundError: No module named 'zstandard'


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011272: nvidia-graphics-drivers-legacy-390xx 390.151-1~deb10u1 flagged for acceptance

[Paul Gevers]

Dear Andreas,

On 19-06-2022 18:54, Adam D Barratt wrote:

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers-legacy-390xx
Version: 390.151-1~deb10u1

Explanation: new upstream release; fix out-of-bound write issues 
[CVE-2022-28181 CVE-2022-28185]


Your upload contained an autopkgtest, but as can be seen on the our 
queue overview [1], the test fails on amd64 and armhf. Should that worry us?


Paul

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


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011156: First steps

[Pierre Gruet]

Hello,

In version 2.27.2+dfsg-1, I removed the problematic classes but another 
error shows up (see below). I wonder if this is a gradle issue or 
something else, I'm not investigating further for the moment.


Relevant part (hopefully):



dh_auto_build -- jar javadoc
mkdir -p .gradle/init.d
cp /usr/share/gradle-debian-helper/init.gradle .gradle/init.d/
gradle --info --console plain --offline --stacktrace 
--no-daemon --refresh-dependencies --gradle-user-home .gradle 
-Duser.home=. -Duser.name=debian -Ddebian.package=picard-tools 
-Dfile.encoding=UTF-8 --parallel --max-workers=4 jar javadoc
OpenJDK 64-Bit Server VM warning: Ignoring option 
--illegal-access=permit; support was removed in 17.0

Initialized native services in: /<>/.gradle/native
To honour the JVM settings for this build a new JVM will be forked. 
Please consider using the daemon: 
https://docs.gradle.org/4.4.1/userguide/gradle_daemon.html.
Starting process 'Gradle build daemon'. Working directory: 
/<>/.gradle/daemon/4.4.1 Command: 
/usr/lib/jvm/java-17-openjdk-amd64/bin/java 
-Xbootclasspath/a:/usr/share/java/gradle-helper-hook.jar:/usr/share/java/maven-repo-helper.jar 
-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

Successfully started process 'Gradle build daemon'
An attempt to start the daemon took 1.138 secs.
The client will now receive all logging from the daemon (pid: 1466549). 
The daemon log file: 
/<>/.gradle/daemon/4.4.1/daemon-1466549.out.log

Daemon will be stopped at the end of the build stopping after processing
Closing daemon's stdin at end of input.
The daemon will no longer process any standard input.
Using 4 worker leases.
Creating new cache for fileHashes, path 
/<>/.gradle/caches/4.4.1/fileHashes/fileHashes.bin, access 
org.gradle.cache.internal.DefaultCacheAccess@4bf2c6ca
Creating new cache for resourceHashesCache, path 
/<>/.gradle/caches/4.4.1/fileHashes/resourceHashesCache.bin, 
access org.gradle.cache.internal.DefaultCacheAccess@4bf2c6ca
Creating new cache for fileHashes, path 
/<>/.gradle/4.4.1/fileHashes/fileHashes.bin, access 
org.gradle.cache.internal.DefaultCacheAccess@1951b69e


FAILURE: Build failed with an exception.

* What went wrong:
Could not create service of type ScriptPluginFactory using 
BuildScopeServices.createScriptPluginFactory().
> Could not create service of type PluginResolutionStrategyInternal 
using BuildScopeServices.createPluginResolutionStrategy().


* Try:
Run with --debug option to get more log output. Run with --scan to get 
full insights.


* Exception is:
org.gradle.internal.service.ServiceCreationException: Could not create 
service of type ScriptPluginFactory using 
BuildScopeServices.createScriptPluginFactory().
at 
org.gradle.internal.service.DefaultServiceRegistry$FactoryMethodService.invokeMethod(DefaultServiceRegistry.java:797)
at 
org.gradle.internal.service.DefaultServiceRegistry$FactoryService.create(DefaultServiceRegistry.java:748)
at 
org.gradle.internal.service.DefaultServiceRegistry$ManagedObjectProvider.getInstance(DefaultServiceRegistry.java:574)
at 
org.gradle.internal.service.DefaultServiceRegistry$SingletonService.get(DefaultServiceRegistry.java:623)
at 
org.gradle.internal.service.DefaultServiceRegistry$FactoryService.assembleParameters(DefaultServiceRegistry.java:761)
at 
org.gradle.internal.service.DefaultServiceRegistry$FactoryService.create(DefaultServiceRegistry.java:747)
at 
org.gradle.internal.service.DefaultServiceRegistry$ManagedObjectProvider.getInstance(DefaultServiceRegistry.java:574)
at 
org.gradle.internal.service.DefaultServiceRegistry$SingletonService.get(DefaultServiceRegistry.java:623)
at 
org.gradle.internal.service.DefaultServiceRegistry$FactoryService.assembleParameters(DefaultServiceRegistry.java:761)
at 
org.gradle.internal.service.DefaultServiceRegistry$FactoryService.create(DefaultServiceRegistry.java:747)
at 
org.gradle.internal.service.DefaultServiceRegistry$ManagedObjectProvider.getInstance(DefaultServiceRegistry.java:574)
at 
org.gradle.internal.service.DefaultServiceRegistry$SingletonService.get(DefaultServiceRegistry.java:623)
at 
org.gradle.internal.service.DefaultServiceRegistry.doGet(DefaultServiceRegistry.java:344)
at 
org.gradle.internal.service.DefaultServiceRegistry.get(DefaultServiceRegistry.java:325)
at 
org.gradle.initialization.DefaultGradleLauncherFactory.doNewInstance(DefaultGradleLauncherFactory.java:174)
at 
org.gradle.initialization.DefaultGradleLauncherFactory.newInstance(DefaultGradleLauncherFactory.java:106)
at 
org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:40)
at 
org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:30)
  

Bug#1013610: (no subject)

[tsteven4]

The underlying issue here is likely 
https://bugreports.qt.io/browse/QTBUG-91558

Bug#1012059: bind9: autopkgtest regression on amd64 and armhf: connection refused

[Bernhard Schmidt]

Control: tags -1 pending

Hi,
With a recent upload of bind9 the autopkgtest of bind9 fails in 
testing on amd64 and armhf when that autopkgtest is run with the 
binary packages of bind9 from unstable. It passes when run with only 
packages from testing. In tabular form:


I have had a brief look and it seems we are just too quick. Adding a 
sleep 1 into the setup function makes the test succeed.


However, I cannot figure out the current repository layout anymore. 
debian/main appears to be outdated. The closest thing that matches 
Debian sid right now is the isc/9.18 branch.

 > Could you please tell me how to handle this repository?


Since you have changed the structure of the repo again and I'm now 
reasonably sure that I have to look at the debian/9.18 branch I've 
pushed a commit fixing the autopkgtest regression in there. Not sure 
when it will land, since there is already a 9.18.4-1 tagged in there but 
not yet uploaded.


Bernhard

Bug#1012059: bind9: autopkgtest regression on amd64 and armhf: connection refused

[Bernhard Schmidt]

Control: tags -1 pending

Hi,
With a recent upload of bind9 the autopkgtest of bind9 fails in 
testing on amd64 and armhf when that autopkgtest is run with the 
binary packages of bind9 from unstable. It passes when run with only 
packages from testing. In tabular form:


I have had a brief look and it seems we are just too quick. Adding a 
sleep 1 into the setup function makes the test succeed.


However, I cannot figure out the current repository layout anymore. 
debian/main appears to be outdated. The closest thing that matches 
Debian sid right now is the isc/9.18 branch.

 > Could you please tell me how to handle this repository?


Since you have changed the structure of the repo again and I'm now 
reasonably sure that I have to look at the debian/9.18 branch I've 
pushed a commit fixing the autopkgtest regression in there. Not sure 
when it will land, since there is already a 9.18.4-1 tagged in there but 
not yet uploaded.


Bernhard

Bug#1012195: dpkg: lintian autopkgtest *may* have spotted a regression in security update of dpkg

[Guillem Jover]

On Sat, 2022-06-25 at 22:09:12 +0200, Salvatore Bonaccorso wrote:
> In fact I think this regression can be included as fix in the upcoming
> point releases if SRM agree, and so avoid an out of order dpkg update
> again to fix this rather edge-case regression (and instread batch it
> with other updates for the point releases).

Yes, was planning to do that after uploading this fix to unstable. But
got sick and was not able to do much.

> Did you found time already for fixes? The bullseye 11.4 point release
> has now been settled for the July 9th, with freezing the upload window
> the preceeding weekend.

I'll try to finish this up for today, and send a proposal for a stable
update once this hits unstable.

Thanks,
Guillem

Bug#995492: lintian: Broken --fails-on=none as default never got reverted

[Guillem Jover]

Hi!

On Tue, 2022-06-14 at 01:26:02 +0200, Axel Beckert wrote:
> Guillem Jover wrote:
> > So the problematic --fail-on default change never got actually reverted
> > as the patch applied in commit 3758bfafd5dd742c327f2312dac8e3a71b1f036e
> > omitted the relevant part that would make it work. :(
> 
> Can you please elaborate what exactly is the bug? You refer to
> something being problematic without explaining what actually is
> problematic.
> 
> You refer to 3758bfafd5dd742c327f2312dac8e3a71b1f036e and
> https://bugs.debian.org/962158 which has been closed about 2 years and
> ca. 35 Lintian releases ago. That thread in #962158 is quite long and
> difficult to grasp.

lintian used to exit with a non-zero value when it emitted at least
one error tag. This was changed, for some reason, and then it stopped
doing that, instead requiring users to specify --fail-on=error. This
was supposedly reverted, but the patch that got applied that fixed
this at the time of submission did not apply at the time it got
committed due to refactoring, and it was ineffective. As such the
--help output now is misleading, mentioning that the default --fail-on
is "error" when it is not.

The above caused the below problems. ↓

> > None of the previous arguments against the default change brought up
> > in #962158 have stopped being relevant (also contrary to the commit
> > message…). Worse, this sneaked in what has shipped now in a stable
> > Debian release. :( So any errors found in CI systems and through other
> > tooling has been silently ignored since then. :/
> 
> This doesn't really makes the issue easier to understand. I don't ask
> for a patch, but at least for a list of defects what is wrong where
> and probably why.
> 
> So far I got that there is an issue with the exit codes having changed
> to be somewhat less helpful for automatic usage. (When did it change
> and how? Do you happen to know a commit id? What condition should in
> your opinion cause which exit code?)

I'd have to re-dig all this. I might just try to provide a patch, I
think should probably be a one-liner.

> > Only noticed now due to #994414, a great excuse to now keep the broken
> > behavior I guess.
> 
> So this bug report actually should no more be fixed?!?

The point of that comment, was that because Felix was pushing for that
behavior change even when no apparent good reasons were given, and
then after the behavior was supposedly reverted (but in fact it was
not), when that bug report about the man page also mismatching the
current behavior was filed, instead of properly fixing the behavior,
he used the opportunity to keep pushing for the IMO broken behavior.

> > (Where the --help output still does not match…)
> 
> So --help seems outdated. At which line or option exactly and what
> should it say instead?

IMO it should stay as it is and the behavior reverted. But if you also
disagree, then it should reflect reality.

Thanks,
Guillem
 

Bug#1013887: totem: Unable to play DVDs

[Guy Durrieu]

Package: totem
Version: 42.0-1
Severity: normal

Dear Maintainer,

Totem worked fine in the past, but now when trying to DVD with totem I 
get the

following error message:


Missing plugin: gstreamer|1.0|totem|Source DVD|urisource-dvd


However, all gstreamer packages are installed, especially 
gstreamer1.0-plugins-bad.



What happens ?

Thanks in advance for your help !

Best regards.

-- Guy Durrieu



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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 totem depends on:
ii  grilo-plugins-0.3   0.3.14-1
ii  gsettings-desktop-schemas   42.0-1
ii  gstreamer1.0-gl 1.20.3-dmo1
ii  gstreamer1.0-gtk3   1.20.3-dmo1
ii  gstreamer1.0-plugins-base   1.20.3-dmo1
ii  gstreamer1.0-plugins-good   1.20.3-dmo1
ii  gstreamer1.0-x  1.20.3-dmo1
ii  libc6   2.33-7
ii  libcairo2   1.16.0-5
ii  libgdk-pixbuf-2.0-0 2.42.8+dfsg-1
ii  libglib2.0-0    2.72.2-2
ii  libgstreamer-plugins-base1.0-0  1.20.3-dmo1
ii  libgstreamer1.0-0   1.20.3-1
ii  libgtk-3-0  3.24.34-1
ii  libhandy-1-0    1.6.2-1
ii  libpango-1.0-0  1.50.7+ds-1
ii  libpangocairo-1.0-0 1.50.7+ds-1
ii  libtotem-plparser18 3.26.6-1
ii  libtotem0   42.0-1
ii  libx11-6    2:1.7.5-1
ii  totem-common    42.0-1

Versions of packages totem recommends:
ii  gstreamer1.0-libav 1:1.20.3-dmo1
ii  gstreamer1.0-plugins-bad   1:1.20.3-dmo1
ii  gstreamer1.0-plugins-ugly  1:1.20.3-dmo1
ii  gstreamer1.0-pulseaudio    1.20.3-dmo1
ii  totem-plugins  42.0-1

Versions of packages totem suggests:
pn  gnome-codec-install  

-- no debconf information

Bug#1012227: webkitgtk: CPU usage

[tmcconnell168]

On Fri, 2022-06-10 at 21:51 +, Alberto Garcia wrote:
> On Fri, Jun 10, 2022 at 02:25:28PM -0500,
> tmcconnell...@gmail.com wrote:
> > I had a better idea, and piped it to the attached file and let it
> > run
> > until the CPU usage went down. Currently my CPU is between 9 - 15 %
> > Sorry for the big file, it took a while. 
> > Tim
> 
> Ok, it looks like it's just drawing text all the time, do you have
> any
> particular website or page open, or when does this happen?
> 
> Berto

Hi Berto, 
As an FYI I sent a question about this to the Evolution mailing list
and was told to run this command. 
gdb --batch --ex "t a a bt" --pid=27250 &>>~/bt.txt
Here's the output (it does it when I'm in Evoution->On This Computer -
>Inbox viewing Cron Jobs, etc) 

[New LWP 27261]
[New LWP 27265]
[New LWP 27267]
[New LWP 27278]
[New LWP 27281]
[New LWP 27282]
[New LWP 27283]
[New LWP 27317]
[New LWP 27320]
[New LWP 27321]
[New LWP 27322]

warning: .dynamic section for "/lib/x86_64-linux-gnu/libgnutls.so.30"
is not at the expected address (wrong library or version mismatch?)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-
gnu/libthread_db.so.1".
0x7f013000a87f in __GI___poll (fds=0x55648400ae00, nfds=2,
timeout=29685) at ../sysdeps/unix/sysv/linux/poll.c:29
29  ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.

Thread 12 (Thread 0x7f0078eaa640 (LWP 27322) "WebKitWe:shlo0"):
#0  0x7f012be280fa in __futex_abstimed_wait_common64
(futex_word=futex_word@entry=0x556484224898, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0, cancel=cancel@entry=true) at
../sysdeps/nptl/futex-internal.c:74
#1  0x7f012be2815b in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x556484224898, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:123
#2  0x7f012be21c30 in __pthread_cond_wait_common (abstime=0x0,
clockid=0, mutex=0x556484224848, cond=0x556484224870) at
pthread_cond_wait.c:504
#3  __pthread_cond_wait (cond=0x556484224870, mutex=0x556484224848) at
pthread_cond_wait.c:619
#4  0x7f00cdf4048b in  () at /usr/lib/x86_64-linux-
gnu/dri/radeonsi_dri.so
#5  0x7f00cdf400d7 in  () at /usr/lib/x86_64-linux-
gnu/dri/radeonsi_dri.so
#6  0x7f012be1bd80 in start_thread (arg=0x7f0078eaa640) at
pthread_create.c:481
#7  0x7f013001676f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 11 (Thread 0x7f00796ab640 (LWP 27321) "WebKitWebP:sh0"):
#0  0x7f012be280fa in __futex_abstimed_wait_common64
(futex_word=futex_word@entry=0x556484224328, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0, cancel=cancel@entry=true) at
../sysdeps/nptl/futex-internal.c:74
#1  0x7f012be2815b in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x556484224328, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:123
#2  0x7f012be21c30 in __pthread_cond_wait_common (abstime=0x0,
clockid=0, mutex=0x5564842242d8, cond=0x556484224300) at
pthread_cond_wait.c:504
#3  __pthread_cond_wait (cond=0x556484224300, mutex=0x5564842242d8) at
pthread_cond_wait.c:619
#4  0x7f00cdf4048b in  () at /usr/lib/x86_64-linux-
gnu/dri/radeonsi_dri.so
#5  0x7f00cdf400d7 in  () at /usr/lib/x86_64-linux-
gnu/dri/radeonsi_dri.so
#6  0x7f012be1bd80 in start_thread (arg=0x7f00796ab640) at
pthread_create.c:481
#7  0x7f013001676f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 10 (Thread 0x7f00cc87b640 (LWP 27320) "WebKitW:disk$0"):
#0  0x7f012be280fa in __futex_abstimed_wait_common64
(futex_word=futex_word@entry=0x556483f44708, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0, cancel=cancel@entry=true) at
../sysdeps/nptl/futex-internal.c:74
#1  0x7f012be2815b in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x556483f44708, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:123
#2  0x7f012be21c30 in __pthread_cond_wait_common (abstime=0x0,
clockid=0, mutex=0x556483f446b8, cond=0x556483f446e0) at
pthread_cond_wait.c:504
#3  __pthread_cond_wait (cond=0x556483f446e0, mutex=0x556483f446b8) at
pthread_cond_wait.c:619
#4  0x7f00cdf4048b in  () at /usr/lib/x86_64-linux-
gnu/dri/radeonsi_dri.so
#5  0x7f00cdf400d7 in  () at /usr/lib/x86_64-linux-
gnu/dri/radeonsi_dri.so
#6  0x7f012be1bd80 in start_thread (arg=0x7f00cc87b640) at
pthread_create.c:481
#7  0x7f013001676f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 9 (Thread 0x7f00cfffd640 (LWP 27317) "ReceiveQueue"):
#0  0x7f013000a87f in __GI___poll (fds=0x556483fabb50, nfds=2,

Bug#774668: xscreensaver: check libxss-dev:XScreenSaverQueryInfo() during idle loop

[Jamie Zawinski]

>> xscreensaver does not use the MIT SCREEN-SAVER server extension
>> because it is a flaky, unreliable piece of shit that tends to cause
>> the sever to crash.
> 
> Is it still the case after 7 years?

I suppose somewhere in the multiverse there is a world where the 
MIT-SCREEN-SAVER extension is under active development. In our universe, that 
code almost certainly hasn't been touched since the 90s.

XScreenSaver does not and will not use that server extension.

Install XScreenSaver 6.04 and then "man xscreensaver-systemd".

-- 
Jamie Zawinski • jwz.org • dnalounge.com

Bug#1013885: src:bind9: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: bind9
Version: 1:9.18.1-1
Severity: serious
Control: close -1 1:9.18.3-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1012059

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:bind9 has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. A recent upload caused 
autopkgtest regression on multiple architectures, which I reported in 
bug #1012059.


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=bind9



OpenPGP_signature
Description: OpenPGP digital signature

Bug#835146: dpkg: please enable bindow hardening flag by default

[Guillem Jover]

Hi!

On Fri, 2022-06-17 at 16:04:27 +0200, Christian Göttsche wrote:
> With LTO being considered to be enabled by default [1] can this please
> also get another deliberation.

If you want to see this enabled by default, please bring it up again
on debian-devel. AFAIR last time there was push back.

Thanks,
Guillem

Bug#1012840: xscreensaver-systemd doesn't exit at end of Xfce session

[Jamie Zawinski]

On Jun 26, 2022, at 5:43 AM, Sergio Gelato  wrote:
> 
>> Huh. Well, xscreensaver-systemd calls XOpenDisplay specifically to make this 
>> happen
> 
> I see that there is code to that effect in version 6.04 (it seems to have 
> first appeared in 6.00, although I see no mention of it on the What's New 
> page), but (as indicated on the Version: line) this bug report is against the 
> version in Debian stable (5.45). I take it that you would suggest backporting 
> a newer version (6.02 is in Debian testing) or cherry-picking the change?

Oh, for fuck's sake, this is why I have, for years now, requested that Debian 
simply *stop shipping XScreenSaver*. I am so sick to death of this continuous 
bullshit of "well, there's a bug in your software from two years and six 
releases ago."

To Debian as a whole, please, I beg of you, stop wasting my fucking time with 
this bullshit.

To Sergio: before you submit a bug report in anything, UPGRADE. Not to the 
version that some slacking upstream asshat has made easily available to you, 
but to the ACTUAL LATEST VERSION.

https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/

-- 
Jamie Zawinski • jwz.org • dnalounge.com

Bug#1004637: libquicktime: FTBFS with ffmpeg 5.0

[Nicholas Guriev]

Control: tag -1 patch

Here is a possible patch. Not tested, though.

Upstream author decided to disable FFmpeg plugin with the new version of the
library. Perhaps, we have to do the same.
https://sourceforge.net/p/libquicktime/git/ci/974ad1489bb1d7d1ebc94f301508702f8ac2083b/
--- a/plugins/ffmpeg/audio.c
+++ b/plugins/ffmpeg/audio.c
@@ -423,8 +423,8 @@ static int a52_header_read(a52_header *
 typedef struct
   {
   AVCodecContext * avctx;
-  AVCodec * encoder;
-  AVCodec * decoder;
+  AVCodec const * encoder;
+  AVCodec const * decoder;
 
   int initialized;
   
@@ -512,7 +512,6 @@ static int decode_chunk_vbr(quicktime_t
 
 #if DECODE_AUDIO4
   AVFrame f;
-  int got_frame;
 #endif
   
   chunk_packets = lqt_audio_num_vbr_packets(file, track, track_map->cur_chunk, _samples);
@@ -548,13 +547,14 @@ static int decode_chunk_vbr(quicktime_t
 codec->pkt.size = packet_size + AV_INPUT_BUFFER_PADDING_SIZE;
 
 #if DECODE_AUDIO4
-frame_bytes = avcodec_decode_audio4(codec->avctx, ,
-_frame, >pkt);
-if(frame_bytes < 0)
+if(avcodec_send_packet(codec->avctx, >pkt) < 0 &&
+   avcodec_receive_frame(codec->avctx, ) < 0)
   {
   lqt_log(file, LQT_LOG_ERROR, LOG_DOMAIN, "avcodec_decode_audio4 error");
   break;
   }
+frame_bytes = codec->pkt.size;
+
 bytes_decoded = f.nb_samples * 2 * track_map->channels;
 memcpy(>sample_buffer[track_map->channels *
  (codec->sample_buffer_end -
@@ -615,7 +615,6 @@ static int decode_chunk(quicktime_t * fi
 
 #if DECODE_AUDIO4
   AVFrame f;
-  int got_frame;
 #endif
   
   /* Read chunk */
@@ -764,14 +763,14 @@ static int decode_chunk(quicktime_t * fi
 codec->pkt.size = codec->bytes_in_chunk_buffer + AV_INPUT_BUFFER_PADDING_SIZE;
 
 #if DECODE_AUDIO4
-
-frame_bytes = avcodec_decode_audio4(codec->avctx, ,
-_frame, >pkt);
-if(frame_bytes < 0)
+if(avcodec_send_packet(codec->avctx, >pkt) < 0 ||
+   avcodec_receive_frame(codec->avctx, ) < 0)
   {
   lqt_log(file, LQT_LOG_ERROR, LOG_DOMAIN, "avcodec_decode_audio4 error");
   break;
   }
+frame_bytes = codec->pkt.size;
+
 bytes_decoded = f.nb_samples * 2 * track_map->channels;
 memcpy(>sample_buffer[track_map->channels *
  (codec->sample_buffer_end -
@@ -1198,7 +1197,6 @@ static int lqt_ffmpeg_encode_audio(quick
 #if ENCODE_AUDIO2
   AVFrame f;
   AVPacket pkt;
-  int got_packet;
 #endif
   
   if(!codec->initialized)
@@ -1274,15 +1272,11 @@ static int lqt_ffmpeg_encode_audio(quick
  codec->avctx->frame_size * channels * 2, 
  1);
 
-if(avcodec_encode_audio2(codec->avctx, ,
- , _packet) < 0)
+if(avcodec_send_frame(codec->avctx, ) < 0 ||
+   avcodec_receive_packet(codec->avctx, ) < 0)
   return 0;
 
-if(got_packet && pkt.size)
-  frame_bytes = pkt.size;
-else
-  frame_bytes = 0;
-
+frame_bytes = pkt.size;
 #else
 frame_bytes = avcodec_encode_audio(codec->avctx, codec->chunk_buffer,
codec->chunk_buffer_alloc,
@@ -1474,8 +1468,9 @@ static int read_packet_ac3(quicktime_t *
   }
 
 void quicktime_init_audio_codec_ffmpeg(quicktime_codec_t * codec_base,
-   quicktime_audio_map_t *atrack, AVCodec *encoder,
-   AVCodec *decoder)
+   quicktime_audio_map_t *atrack,
+   const AVCodec *encoder,
+   const AVCodec *decoder)
   {
   quicktime_ffmpeg_audio_codec_t *codec;
   
--- a/plugins/ffmpeg/ffmpeg.h
+++ b/plugins/ffmpeg/ffmpeg.h
@@ -30,10 +30,12 @@
 
 void quicktime_init_video_codec_ffmpeg(quicktime_codec_t * codec,
quicktime_video_map_t *vtrack,
-   AVCodec *encoder, AVCodec *decoder);
+   const AVCodec *encoder,
+   const AVCodec *decoder);
 void quicktime_init_audio_codec_ffmpeg(quicktime_codec_t * codec,
quicktime_audio_map_t *vtrack,
-   AVCodec *encoder, AVCodec *decoder);
+   const AVCodec *encoder,
+   const AVCodec *decoder);
 
 void lqt_ffmpeg_set_parameter(AVCodecContext * ctx,
 #if LIBAVCODEC_VERSION_MAJOR >= 54
--- a/plugins/ffmpeg/lqt_ffmpeg.c
+++ b/plugins/ffmpeg/lqt_ffmpeg.c
@@ -315,8 +315,8 @@ struct CODECIDMAP
   {
   int id;
   int index;
-  AVCodec *encoder;
-  AVCodec *decoder;
+  AVCodec const *encoder;
+  AVCodec const *decoder;
   lqt_parameter_info_static_t * encode_parameters;
   lqt_parameter_info_static_t * decode_parameters;
   lqt_image_size_static_t * 

Bug#1013869: rust-reqwest: feature rustls-tls has disappeared

[Jonas Smedegaard]

Quoting Peter Michael Green (2022-06-26 19:01:04)
> To enable rustls support with native or manual roots two crates which 
> are not in Debian, tokio-rustls and hyper-rustls. For tokio-rustls 
> Alexander Kjäll prepared a package, which I have just sponsored into 
> NEW. I don't see any evidence that anyone is working on hyper-rustls 
> however.

Not sure what you are saying above.  Feature "rustls-native-certs" *is*
currently offered.  Are you saying that that is broken until either of
tokio-rustls or hyper-rustls gets into Debian?!?


> To enable rustls support with webpki roots it would additionally be 
> necessary to re-introduce the rust-webpki-roots package. I personally 
> would be very skeptical about reintroducing it though, having root 
> certificates hardcoded into application binaries is just not something 
> packages in Debian should be doing without an extremely good reason.

I agree - which was the reason I closed this bugreport, and instead
patched the projct I am preparing to use feature "rustls-native-certs".

Fine that you reopen this bugreport if _you_ want to continue tracking
this, but since I no longer have a need for reqwest feature "rustls-tls"
please then adopt this bugreport - e.g. with `bts owner 1013869 !`.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1013237: bullseye-pu: package phpmyadmin/4:5.0.4+dfsg2-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-06-19 at 19:27 +0200, William Desportes wrote:
> Some users have 500 errors when using some queries.
> Previous versions of Debian where not affected.
> 

Please go ahead.

Regards,

Adam

Bug#1012140: bullseye-pu: package docker.io/20.10.5+dfsg1-1+deb11u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2022-05-30 at 21:04 +0200, Felix Geyer wrote:
> Docker uses containerd to manage containers but fails to setup the
> proper
> dependencies in the systemd service.
> https://bugs.debian.org/989490
> 
> [ Impact ]
> On system shutdown Docker often is unable to properly shutdown
> containers
> and just hangs. This delays shutdown until it reaches the timeout
> (by default 90s).
> 

Please go ahead.

Regards,

Adam

Bug#1012033: bullseye-pu: package gnutls28/3.7.1-5+deb11u1

[Adam D. Barratt]

On Tue, 2022-06-14 at 19:24 +0200, Andreas Metzler wrote:
> On 2022-05-29 Andreas Metzler  wrote:
> [...]
> > as requested in #1011246 I would like fix miscalculation of SHA384
> > in
> > the SSA accelarated implementation.
> > It is a one-line change and was part of the 3.7.3 release.
> [...]
> 
> Actually this seems like a good opportunity to fix a minor CVE, which
> was also fixed in 3.7.3.

Please go ahead.

Regards,

Adam

Bug#1012047: bullseye-pu: package composer/2.0.9-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-05-29 at 12:23 +0200, David Prévot wrote:
> I’d like to address CVE-2022-24828 that has been tagged as no-dsa.
> Some
> people may also wish to see #989315 fixed (it was reported twice),
> and
> the fix is trivial, so I’m proposing a fix for it too.
> 

Please go ahead.

Regards,

Adam

Bug#885433: Blocked too

[Mariusz]

Why is this happened?

I-ve trying to make an account, to add some supported hardware, than I 
was blocked.


Not cool.

Bug#1013882: fails to read certificates not "directly" readable by _chrony user

[Vincent Blut]

Hi Daniel,

Le 2022-06-26 17:45, Daniel Baumann a écrit :
> Package: chrony
> Version: 4.2-2
> 
> Hi,
> 
> thank you for maintaining chrony in Debian.

You're welcome! :-)
 
> When configuring NTS and using letsencrypt, I'd like to have the
> certificates owned by root:ssl-cert with directory permissions set to
> 0750 and file permissions set to 0640.
> 
> For every other daemon used so far, that works perfectly fine when
> putting the daemon user to the ssl-cert group.
> 
> However, with chrony, this does not work. I confirmed that _chrony can
> read the files. Anything but having the files/directories-along-the-path
> either world-readable or readable by _chrony directly does not work.
> 
> It would be nice if this could be fixed, looking at the sources I don't
> see anything obvious that would make it fail though.
> 
> Let me know if you need more information to reproduce it.

The behavior you are describing here is expected. chronyd reads the
certificates and private keys after dropping root privileges. Consequently,
those files need to be readable by the user under which chronyd is running.
 
> Regards,
> Daniel

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1013752: Transition KDE PIM 22.04

[Steven Robbins]

Hello,

Patrick suggested I chime in here, as the Digikam maintainer.


On Sat, 25 Jun 2022 23:42:47 +0200 Sebastian Ramacher  
wrote:
> On 2022-06-25 20:45:37 +0200, Patrick Franz wrote:
> > Hi Sebastian,
> > 
> > Am Samstag, 25. Juni 2022, 20:30:32 CEST schrieb Sebastian Ramacher:
> > [...]
> > > > A fixed version of kgpg is in experimental and just needs to be
> > > > uploaded to unstable once KDE PIM 22.04 is uploaded there. There
> > > > are patches available for both digikam and kjots. I can patch kjots
> > > > myself and point the digikam maintainers to the existing patch.
> > > 
> > > Just to be clear: is the patch for digikam for kdepim compat or does
> > > it also fix the build failure with ffmpeg 5.0?
> > 
> > It would be purely for KDE PIM (https://invent.kde.org/graphics/
> > digikam/-/commit/51efe295a222070743187af0367b0bf957879337).
> 
> I see. If you (and the KDE team) are okay with temporarly removing
> digikam from testing, then please feel free to go ahead.

I'm comfortable with digikam being temporarily removed from testing.  As was 
pointed out, we still have the ffmpeg issue to deal with and I don't see any 
value in holding up kdepim for that.

Regards,
-Steve


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

Bug#1013418: bullseye-pu: package dbus-broker/26-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2022-06-23 at 11:33 +0100, Luca Boccassi wrote:
> A low-severity CVE has been published for dbus-broker, and it affects
> bullseye. In accordance with the Security Team, it does not warrant a
> DSA, so we would like to fix it via p-u instead. The fix is a clean
> backport, and the diff is minimal. Debdiff attached.
> 
> Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013343
> 

Please go ahead.

Regards,

Adam

Bug#1013306: bullseye-pu: package libsdl2/2.0.14+dfsg2-3+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2022-06-21 at 10:55 +0100, Simon McVittie wrote:
> Backport two out-of-bounds reads, one of which has a CVE ID,
> presumably
> because it could be an exploitable vulnerability for games that are
> willing to load untrusted graphics data.
> 
> The security team marked the CVE as unimportant and didn't open a
> bug,
> so presumably they don't intend to do a DSA.
> 

Please go ahead.

Regards,

Adam

Bug#1013869: rust-reqwest: feature rustls-tls has disappeared

[Peter Michael Green]

reopen 1013869
thanks.


the (to me, at least) relatively cryptic changelog entry

Sorry if the changelog wasn't clear. I was building a stack of patches
with the expectation that some of them would be removed later.

reqwest upstream offers several options for tls.

native-tls/default-tls (enabled by default): this uses the 
rust-native-tls crates which on Linux systems means it uses openssl
rustls-tls-manual-roots: rustls with the application expected to supply 
root certificates.
rustls-tls-webpki-roots/rustls-tls: rustls with roots from the 
webpki-roots crate
rustls-rls-native-roots: rustls with roots from the operating system 
certificate store.


Presently only the default/native tls option is supported by the Debian 
package,


To enable rustls support with native or manual roots two crates which 
are not in Debian, tokio-rustls and hyper-rustls. For tokio-rustls 
Alexander Kjäll prepared a package, which I have just sponsored into 
NEW. I don't see any evidence that anyone is working on hyper-rustls 
however.


To enable rustls support with webpki roots it would additionally be 
necessary to re-introduce the rust-webpki-roots package. I personally 
would be very skeptical about reintroducing it though, having root 
certificates hardcoded into application binaries is just not something 
packages in Debian should be doing without an extremely good reason.

Bug#1013565: libitext5-java: FTBFS: dh_auto_test: error:

[Markus Koschany]

Same here. Looks related to maven-resource-plugins / maven-filtering and
#1013582 and #1013586 


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

Bug#1013884: ITP: golang-github-gonvenience-neat -- create neat strings like colored YAML output

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬) 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: golang-github-gonvenience-neat
  Version : v1.3.11
  Upstream Author : 2019 The Homeport Team
* URL : https://github.com/gonvenience/neat
* License : Expat
  Programming Lang: Go
  Description : create neat strings like colored YAML output

 This package will be maintained under Debian Go Packaging Team.
 This is dependencies of dyff (https://bugs.debian.org/1013751).

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1013883: ITP: golang-github-gonvenience-bunt -- true color output in terminals

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬) 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: golang-github-gonvenience-bunt
  Version : v1.3.4
  Upstream Author : The Homeport Team
* URL : https://github.com/gonvenience/bunt
* License : Expat
  Programming Lang: Go
  Description : true color output in terminals

This package will be maintained under Debian Go Packaging Team.
This is dependencies of dyff (https://bugs.debian.org/1013751).

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1013586: Bug#1013595: plexus-io: FTBFS: Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.1.0:testResources

[Markus Koschany]

I believe this is related to a bug in maven-filtering or maven-resources-
plugin. According to

https://issues.apache.org/jira/browse/MRESOURCES-237

the behavior how symlinks are handled has changed between version 2.7 and 3.0.x
of maven-resources-plugin. This is apparently fixed in maven-filtering 3.3.0. I
don't know why we see this problem only now because the bug has been reported
four years ago. I have pushed a new upstream version of maven-filtering to the
experimental branch but I have not uploaded it yet. The upgrade would break
Maven with "No implementation ... was bound" error and I presume some extra
steps have to be taken in order to match this package with our Maven version.


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

Bug#1013882: fails to read certificates not "directly" readable by _chrony user

[Daniel Baumann]

Package: chrony
Version: 4.2-2

Hi,

thank you for maintaining chrony in Debian.

When configuring NTS and using letsencrypt, I'd like to have the
certificates owned by root:ssl-cert with directory permissions set to
0750 and file permissions set to 0640.

For every other daemon used so far, that works perfectly fine when
putting the daemon user to the ssl-cert group.

However, with chrony, this does not work. I confirmed that _chrony can
read the files. Anything but having the files/directories-along-the-path
either world-readable or readable by _chrony directly does not work.

It would be nice if this could be fixed, looking at the sources I don't
see anything obvious that would make it fail though.

Let me know if you need more information to reproduce it.

Regards,
Daniel

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Daniel Lewart]

Ben, et al,

On Mon, 13 Jun 2022 18:23:18 +0200 Ben Hutchings  wrote:

> Since the truncated signatures are in the source packages, this is a
> problem introduced by the code signing service and will need to be
> fixed there.

Assuming that the code-signing service uses the kernel's scripts/sign-file
and calls PKCS7_sign() ...

Which version of OpenSSL/libssl is used?

Are kernel build logs available for download or viewing?

Thank you!
Dan
Urbana, Illinois

Bug#1010595: #1013568 scipy: FTBFS: conjugate.hpp:22:36: error: type/value mismatch at argument 2 in template parameter list for ‘template class xsimd::batch’

[Drew Parsons]

Control: reopen 1010595
Control: forwarded 1010595 
https://github.com/xtensor-stack/xsimd/issues/756

Control: block 1013568 by 1010595 1012437

A number of upgrades including scipy got interrupted by the upgrade of 
xsimd to v8.  We're working through the transition now. scipy needs a 
working pythran but pythran needs xsimd available on all arches, even 
those without specific vector acceleration hardware (in which case xsimd 
scalar mode is used). We need to reconfigure xsimd tests to not attempt 
vector-mode functionality on unsupported arches.

Bug#1013881: libpyside2-py3-5.15: unstable soname?

[Tobias Frost]

Package: libpyside2-py3-5.15
Version: 5.15.2-2
Severity: serious
Justification: breaks reverse dependencies.
Control: affects -1 freecad

Dear Maintainers,

freecad, on a sid machine fails to start with:

freecad
freecad: error while loading shared libraries: 
libpyside2.cpython-39-x86_64-linux-gnu.so.5.15: cannot open shared object file: 
No such file or directory

Looking up the shared library, it is in the pyside binary package 
libpyside2-py3-5.15 Version 5.15.2-1 -- the version from bookworm.

However, the package in testing/sid has:

/usr/lib/x86_64-linux-gnu/libpyside2.cpython-310-x86_64-linux-gnu.so.5.15.2

It seems that there is some extra numberi (possibly the python version?) coded 
into the filename
of the shared library.

That breaks reverse dependencies, as e.g freecad is not able to find the file.

I'm not sure if that can be avoided by providing "stable" filename (not sure
if the libraries are ABI compatible). If they are not, you MUST do a library
transistion as described here: 
https://wiki.debian.org/Teams/ReleaseTeam/Transitions

-- 
tobi

Bug#774668: xscreensaver: check libxss-dev:XScreenSaverQueryInfo() during idle loop

[Piotr Engelking]

Jamie Zawinski :

> xscreensaver does not use the MIT SCREEN-SAVER server extension
> because it is a flaky, unreliable piece of shit that tends to cause
> the sever to crash.

Is it still the case after 7 years?

Also, the workaround given by the submitter no longer works, I use this
instead:

$ cat ~/.config/mpv/scripts/screensaver.lua
local function deactivate_screensaver()
mp.command_native({name={'subprocess'},
args={'xscreensaver-command', '--deactivate'}})
end

local timer = mp.add_periodic_timer(30, deactivate_screensaver)

local function on_pause_change(name, value)
if value then
timer:kill()
else
timer:resume()
end
end

mp.observe_property('pause', 'bool', on_pause_change)
$

Bug#1012245: nvidia-graphics-drivers-tesla-470: fails on ppc64el due to transitive GPL symbol usage

[Andreas Beckmann]

Control: severity -1 important
Control: tag -1 - sid bookworm

I've temporarily disabled the autopkgtest on ppc64el.


Andreas

Bug#1013880: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.129.06-5~deb11u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Let's update nvidia-graphics-drivers-tesla-470 in stable (which is being
introduced via -pu) to a new upstream release to fix some more CVEs.
This is a rebuild of the package in sid with no further changes.

The diff and this request are more or less the same as for
nvidia-graphics-drivers (#1013879).


Andreas


ngd-tesla-470-470.129.06-5~deb11u1.diff.xz
Description: application/xz

Bug#1013341: /usr/bin/ld.bfd: warning: /usr/lib/crt0-efi-x86_64.o: missing .note.GNU-stack section implies executable stack

[Steve McIntyre]

On Wed, Jun 22, 2022 at 12:47:34PM +0200, Michael Biebl wrote:
>
>Am 22.06.22 um 11:49 schrieb Julien Cristau:
>> On Wed, Jun 22, 2022 at 10:50:48AM +0200, Michael Biebl wrote:
>
>> > Marking as RC, as it causes a FTBFS
>> > 
>> Not using -Wl,--fatal-warnings might be a workaround for systemd until
>> gnu-efi fixes this?
>
>Yeah, I'll probably add a workaround like
>
>
>diff --git a/src/boot/efi/meson.build b/src/boot/efi/meson.build
>index 52e2a71a7c..18311ede25 100644
>--- a/src/boot/efi/meson.build
>+++ b/src/boot/efi/meson.build
>@@ -251,6 +251,8 @@ efi_ldflags = [
> '-L', efi_libdir,
> '-nostdlib',
> '-T', efi_lds,
>+'-Wl,--no-warn-execstack',
>+'-Wl,--no-warn-rwx-segments',
> '-Wl,--build-id=sha1',
> '-Wl,--fatal-warnings',
> '-Wl,--no-undefined',
>
>to systemd for the time being.

ACK, that's probably your best bet for now. The EFI toolchain has
quite special needs here yet...


-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

Bug#1013879: bullseye-pu: package nvidia-graphics-drivers/470.129.06-5~deb11u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Hi,

in oder to fix some more CVEs in the proprietary NVIDIA driver, let's
update the version in stable to a new upstream release. This is a
rebuild of the package from sid with no further changes.

The biggest part of the diff are changes to the set of supported PCI IDs
- according to the README from the 510 driver (in experimental), the
470 driver series still supports more legacy gpu models. (Looks like
NVIDIA had planned to remove support for Kepler nodebook GPUs at some
point, but that does not seem to have happened, only the 470 README
"lost" any information about these cards at some point.)

Andreas


ngd-470.129.06-5~deb11u1.diff.xz
Description: application/xz

Bug#1012825: Removed symbol without major SONAME bump

[GCS]

Control: merge 1013877 1013878

On Sun, Jun 26, 2022 at 2:18 PM László Böszörményi (GCS)  
wrote:
> See the attached patch, basically it's a one liner. Sergei just needs
> to add it to the libtk-img package source.
 Then it's just one bug, sorry for the duplication. As soon as Sergei
uploads this fix, linuxcnc will work again as well.
Just a note that tiff will no longer export its private functions,
breaking libtk-img entirely. Of course, tiff upstream reported it for
libtk-img. See its bug tracker [1].

Hope this helps,
Laszlo/GCS
[1] https://sourceforge.net/p/tkimg/bugs/109/

Bug#1012789: Bug#1012825: Removed symbol without major SONAME bump

[GCS]

Control: tags 1012825 -patch
Control: clone 1012789 -1
Control: reassign -1 libtk-img
Control: retitle -1 libtk-img: add _TIFFsetString to its internal tiff library
Control: tags -1 +patch

On Sat, Jun 25, 2022 at 5:07 PM Petter Reinholdtsen  wrote:
> While it might sound sensible on the surface, the realities is that the
> libraries binary interface (aka ABI) changed, removing a public symbol
> from the library.  Such API change require a no major SONAME number to
> avoid breaking programs using the library.
 You are right that removing public symbols from a library interface
is an ABI break and requires a SONAME change. Per coding standards
function names starting with underscore are part of the private API
and a) not to be used outside of the library, b) if used nevertheless,
it's accepted that the other code can break anytime.

> It is not linuxcnc-uspace that is using it.  It is the tcl/tk Img
> library.  To test for yourself, try running 'wish' and give it the
> 'package require Img' command to load the Img library.  linuxcnc do the
> equivalent loading, but using the python Tk library.
 Yup, I was tricked by the bug reports. . In this case, the Python Tk
library must follow the internal change of tiff.

> Removing the symbol without bumping the SONAME made it impossible for
> programs using the symbol to keep the old working library version.  This
> was the ratinale for my severity setting critical.  Given that the
> symbol removal without bumping SONAME broken libtk-img and linuxcnc,
> what is your argument for lowering the severity to normal?
 First of all, critical is used for several issues like making the
system unbootable or causing huge data loss. That's not the case. Then
as noted above, projects using others internal structures and/or
functions must follow that when the latter changes.
What you proposed is to diverge from tiff upstream and adding back the
mentioned function, then forcing a SONAME change, doing a transition
with over two hundred code rebuilds on fourteen architectures. This
makes no sense.
As noted above, the Python Tk library copies an internal tiff function
and probably not just one but a whole set of those (just check its
compat/libtiff/libtiff source directory). It must accept to follow
tiff development and act on such changes. Especially that the
mentioned removed function is a one liner, being a wrapper for another
function. If libtk-img needs that function, right. Copy it to their
code like it copied others already.
See the attached patch, basically it's a one liner. Sergei just needs
to add it to the libtk-img package source.

Regards,
Laszlo/GCS
Description: add _TIFFsetString function for being removed from tiff
 The _TIFFsetString private function was internal of tiff and removed in
 tiff 4.4.0+ versions. As Tk library used it in its source, copy the function
 to its source.
Author: Laszlo Boszormenyi (GCS) 
Forwarded: no
Last-Update: 2022-06-25

---

--- libtk-img-1.4.13+dfsg.orig/compat/libtiff/libtiff/tif_unix.c
+++ libtk-img-1.4.13+dfsg/compat/libtiff/libtiff/tif_unix.c
@@ -352,6 +352,12 @@ _TIFFmemcmp(const void* p1, const void*
 	return (memcmp(p1, p2, (size_t) c));
 }
 
+void
+_TIFFsetString(char** cpp, char* cp)
+{
+   _TIFFsetByteArray((void**) cpp, (void*) cp, strlen(cp)+1);
+}
+
 static void
 unixWarningHandler(const char* module, const char* fmt, va_list ap)
 {

Bug#1013876: webext-keepassxc-browser: Version 1.8.0+repack1-2 fail to load in chromium

[Guillem Jover]

Package: webext-keepassxc-browser
Version: 1.8.0+repack1-2
Severity: serious

Hi!

This version seems to fail load on chromium 103.0.5060.53-1, with the
following warnings and errors shown on the extensions settings page:

  (W) Unrecognized manifest key 'applications'.
  (W) Manifest version 2 is deprecated, and support will be removed in 2023.
  See https://developer.chrome.com/blog/mv2-transition/ for more details.
  (E) Uncaught TypeError: Bootstrap's JavaScript requires jQuery. jQuery must 
be included before Bootstrap's JavaScript.
  Context: popups/popup.html
  Stack Trace: bootstrap/bootstrap.js:221 (anonymous function)
  (E) Uncaught (in promise) ReferenceError: browser is not defined
  Context: popups/popup.html
  Stack Trace: popups/popup_functions.js:74 (anonymous function)
  (E) Uncaught ReferenceError: browser is not defined
  Context: popups/popup.html
  Stack Trace: common/translate.js:11 (anonymous function)
  (E) Uncaught (in promise) ReferenceError: browser is not defined
  Context: popups/popup.html
  Stack Trace: popups/popup_functions.js:40 (anonymous function)
  (E) Uncaught ReferenceError: browser is not defined
  Context: _generated_background_page.html
  Stack Trace: common/global.js:161 (anonymous function)
  (E) Uncaught ReferenceError: browser is not defined
  Context: _generated_background_page.html
  Stack Trace: background/keepass.js:39 (anonymous function)
  (E) Uncaught ReferenceError: browser is not defined
  Context: _generated_background_page.html
  Stack Trace: background/init.js:23 (anonymous function)

Thanks,
Guillem

Bug#1013875: lintian: false-postive for experimental-to-unstable-without-comment

[Andreas Metzler]

Package: lintian
Version: 2.115.1
Severity: normal

P: exim4-base: experimental-to-unstable-without-comment 
[usr/share/doc/exim4-base/changelog.Debian.gz:1]
(sid)ametzler@argenau:/tmp/EXIM4/exim-4.96$ dpkg-parsechangelog --file 
debian/exim4-base/usr/share/doc/exim4-base/changelog.Debian.gz
Source: exim4
Version: 4.96-1
[...]
Changes:
 exim4 (4.96-1) unstable; urgency=low
 .
   * New upstream version, almost identical to RC2.
   * Upload to unstable.
   * Extend debian/NEWS.

cu Andreas

Bug#1013873: lintian: "Cannot open" warnings on symlinks to files in other packages from same source

[Andreas Metzler]

Package: lintian
Version: 2.115.1
Severity: normal
X-Debbugs-Cc: ex...@packages.debian.org

Hello,

lintian has recently started throwing errors like this for when run on
exim4_..._amd64.changes (source + binary upload):

--
Warning in processable ../exim4-daemon-heavy_4.96-1_amd64.deb: Cannot open 
/dev/shm/lintian-pool-b_2HrMSwnf/exim4/exim4-daemon-heavy_4.96-1_amd64_binary/unpacked/usr/share/doc/exim4-daemon-heavy/README.Debian.gz
 at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109.
warning: cannot run debian/readme check on package 
binary:exim4-daemon-heavy_4.96-1_amd64
--

The respective file is a symlink to the file in exim4-base/:
(sid)ametzler@argenau:/tmp/EXIM4/exim-4.96$ ls -l 
debian/exim4-daemon-heavy/usr/share/doc/exim4-daemon-heavy/README.Debian.gz
lrwxrwxrwx 1 ametzler ametzler 30 Jun 26 11:53 
debian/exim4-daemon-heavy/usr/share/doc/exim4-daemon-heavy/README.Debian.gz -> 
../exim4-base/README.Debian.gz

cu Andreas

Bug#1013872: salt: CVE-2022-22967

[Salvatore Bonaccorso]

Source: salt
Version: 3004.1+dfsg-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for salt.

CVE-2022-22967[0]:
| An issue was discovered in SaltStack Salt in versions before 3002.9,
| 3003.5, 3004.2. PAM auth fails to reject locked accounts, which allows
| a previously authorized user whose account is locked still run Salt
| commands when their account is locked. This affects both local shell
| accounts with an active session and salt-api users that authenticate
| via PAM eauth.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-22967
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22967
[1] 
https://saltproject.io/security_announcements/salt-security-advisory-release-june-21st-2022/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Daniel Lewart]

Ben, et al,

BH> I wrote a script to check for short signatures (and other unexpected
BH> things) in detached signature files:
BH> 
https://salsa.debian.org/kernel-team/kernel-team/-/blob/master/scripts/benh/check-sig-params

DL> I tried running your script, but it generates an error (see below).
DL> What am I doing wrong?

I was running it for the kernel module instead of the detached signature.  D'oh!

This works:
$ extract-module-sig.pl -s
/lib/modules/5.10.0-15-amd64/kernel/net/netfilter/xt_l2tp.ko
2>/dev/null | check-sig-params /dev/stdin

Sorry for the noise,
Dan
Urbana, Illinois

Bug#1011845: FTBFS: make[1]: *** [Makefile:272: testdeps] Error 1

[Andrew Ruthven]

Hey Lucas,

I expect the the output from rt-test-dependencies in this case is a
false lead. I believe this is actually caused by the update of OpenSSL
to 3.0 causing one of the tests to fail. I filed a bug for this
yesterday: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013730 .

Today I happened update our packaging to resolve the dependencies issue
as mentioned in this bug report.

Cheers,
Andrew
-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |

Bug#1013871: libvmod-re2: Fails to build in Debian on most architectures and in Ubuntu on armhf

[Sebastian Ramacher]

Control: severity -1 important

On 2022-06-26 11:26:50 +0100, Luís Infante da Câmara wrote:
> Source: libvmod-re2
> Version: 2.0.0-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source
> 
> Dear Maintainer,
> 
> This source package fails to build in Debian on all architectures supported
> by
> Debian except amd64, arm64, ppc64el and s390x and all unofficial
> architectures

The package never built there, so this bug is of severity important at
most.

Cheers

> except ppc64. This source package also fails to build on Ubuntu only on
> armhf.
> 
> Debian build logs:
> https://buildd.debian.org/status/package.php?p=libvmod-re2=sid
> Ubuntu build log: 
> https://launchpadlibrarian.net/591045344/buildlog_ubuntu-jammy-armhf.libvmod-re2_2.0.0-1_BUILDING.txt.gz

-- 
Sebastian Ramacher

Bug#1012840: xscreensaver-systemd doesn't exit at end of Xfce session

[Jamie Zawinski]

On Jun 26, 2022, at 1:59 AM, Sergio Gelato  wrote:
> 
>> The display connection that both xscreensaver and xscreensaver-systemd have 
>> open will close with SIGPIPE.
> 
> This does not match my observations. xscreensaver does appear to have a 
> connection to the X server, but xscreensaver-systemd does not. (It seems to 
> have connections to DBus instead.)

Huh. Well, xscreensaver-systemd calls XOpenDisplay specifically to make this 
happen, and when I run xscreensaver-systemd and then kill the X server, I get 
this:

# ./xscreensaver-systemd -v
xscreensaver-systemd: 02:07:08: registered as "org.jwz.XScreenSaver"
xscreensaver-systemd: 02:07:08: registered as "org.freedesktop.ScreenSaver"
xscreensaver-systemd: 02:07:08: "org.gnome.SessionManager" not in use
xscreensaver-systemd: 02:07:08: "org.kde.Solid.PowerManagement.PolicyAgent" not 
in use

[ kill server ]

xscreensaver-systemd: 02:07:26: X connection closed
Exit 1


-- 
Jamie Zawinski • jwz.org • dnalounge.com

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Thomas Schmitt]

Hi,

Zhang Boyang wrote:
> Theoretically if both file is already sorted, we can use the `-m' option

I like this idea. Just in case Debian grows to a million packages.
But i understand that i would need two separate files for sorting.

  grep ' ./pool/' file1
  fgrep -v ' ./pool/' file2
  sort -k 2 -m file1 file2 >temp_file

More temporary files means more need for pre-existence tests and more
cleanup effort.
Currently i just have to concatenate two stdout streams.


> However I don't think O(n * log(n)) is a bottleneck so we may just keep it
> simple and stupid.

Seems to be the best decision for now.
(Unless some shell wizzard shows a way to pipe both streams separately
into sort -m while staying dash compatible and without the need for new
persistent file objects which have to be cleaned up afterwards.)

Actually we did not yet identify a use case where md5sum.txt needs to
be sorted at all. I only sort it because the input files are sorted.


New version:
  
https://dev.lovelyhq.com/libburnia/libisoburn/commit/0e8227e76ae4c4f24097cfac2f415ef8e25ae4e7


Have a nice day :)

Thomas

Bug#1011712: olm: FTBFS: unsatisfiable build-dependency: binaryen (< 105+) but 106-1 is to be installed

[Hubert Chathi]

On Sat, 25 Jun 2022 00:49:15 +0200, Evangelos Ribeiro Tzaras 
 said:

[...]

> - Drop the javascript bindings for olm (libjs-olm). The only reverse
> dependency of libjs-olm is libjs-matrix-sdk which itself has no
> reverse dependencies.

FWIW, libjs-matrix-js-sdk upstream is looking into switching to the new
rust implementation of olm, so some future version may stop using
libjs-olm anyways.  But I'm not sure of the timeline for that.

Aside from that, I'd like to look into updating emscripten somehow, but
I'm currently on VAC so I won't be able to do it for a little while.  So
in the mean time, I don't have any objection to someone doing something
to resolve the situation temporarily.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#1013869: rust-reqwest: feature rustls-tls has disappeared

[Jonas Smedegaard]

Source: rust-reqwest
Version: 0.9.19-5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

t-reqwest is finally installable.  Yay!

Unfortunately, the feature rustls-tls has disappeared.

Please re-enable support for feature rustls-tls, needed by packages I am
preparing for Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmK4GJ4ACgkQLHwxRsGg
ASHHkw/8CJpyEa5k2dowRHlsrVG+u1KfUJZFmCz/k49xrzaDdog8UfdNOw7YQTet
NPpgT+EV48I2eKebYAGv1kY1vX+vxKD8CmFhn0TAAlRr8e6LB7/pBeiefsAKfOtT
O+UZaO0uMivQuRwyfzx4EzHVRg5sHRDEdKfVVCKDEeyOgz6lv0Y9vmTTKSETY/zB
BBTxR0Ow6196SqTk+KH49wyZ2cKIa7nqQoieIpiJ+5RfodIElow/RcgS6wh443md
0zU3RR6BEPA5fVRQ7dRs8J9RNMbsTC5F+DxlvBB+FHTrPrKDCXw4CHrRRwI14mvc
f69g/81qGsRM4n0xIZNvG3A49bmzaS6b3xBHUvcCjo2CG4FjbAKeA1mQSg1algSO
ycE1E4YQTiw6rBNXiln2/7ErRrD7ISg98LEKV2uJX75GYYleaMapO+PUHijsbC5P
BW9sf4yq6mUBfgld8K7hVOvvFhP1eb+1nTK8GvYge5rbqC8QZ1ODmZKgjEFsCYX1
1f+SIKmVhaHDCrKXFO9eU9xv9XGblZjpuMV4cs717mm4iK3X2OHBunXBTkGnRrY+
Fgfae9senYcQ8hYhQ63WkViArB1KCqqAvkZW8Faq4eV8n3V++jsyRXnS95vn/ary
puzKnVBpJLcZGyTnay2qghPbkebhV6q7U7eGCbZQt0MFpWoqE/g=
=alj6
-END PGP SIGNATURE-

Bug#1013827: varnish-modules: Tests fail in Ubuntu only on armhf

[Stig Sandbeck Mathisen]

Package: varnish-modules
Version: 0.20.2-1
Followup-For: Bug #1013827

Post-build tests fail on armel and armhf on Debian.  See
https://buildd.debian.org/status/package.php?p=varnish-modules

-- 
Stig

Bug#1013868: nfs-common: Split between Python scripts to separate package

[Gioele Barabucci]

Package: nfs-common
Version: 1:2.6.1-2

Dear maintainers of nfs-common,

could you please move the three Python scripts included in nfs-common to 
a separate -extras package?


Currently nfs-common Depends on `python3` and, on lean/containerized 
client systems, it is the only package that requires it. For this 
reason, in 2019 Fedora moved the scripts `mountstats`, `nfsiostat` and 
`nfsconvert` to a separate package [1,2], required on servers (for 
`nfsconver`) but not on clients.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1667889
[2] https://github.com/coreos/fedora-coreos-tracker/issues/121

Kind regards,

--
Gioele Barabucci

Bug#1013867: Don't use user ntpsec if package ntp is installed

[Klaus Ethgen]

Package: ntpsec
Version: 1.2.1+dfsg1-7+b1

When package ntp is installed (from long history), the ntp daemon is
started by this /etc/init.d/ntp which uses user ntp:ntp. So all
auxiliary directories and files are owned by ntp:ntp.

When ntpsec starts to start the same daemon with ntpsec:ntpsec (which is
counter expected) the ntp daemon is not running properly and more over,
it is creating/changing some file rights so neither daemon is running
properly afterwards.

Even better would be to drop that ntpsec:ntpsec user fully and use
ntp:ntp as this would be the expected user a ntp is running under.

And please, don't conflict for ntp package as usually ntp is managed by
configuration management which is depending on ntp init script named
ntp. Nobody would expect init script ntpsec!

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

Kernel: Linux 5.16.17 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ntpsec depends on:
ii  adduser  3.121
ii  init-system-helpers  1.63devuan1
ii  libbsd0  0.11.6-1
ii  libc62.33-7
ii  libcap2  1:2.44-1
ii  libssl3  3.0.4-2
ii  lsb-base 11.2
ii  netbase  6.3
ii  python3  3.10.4-1+b1
ii  python3-ntp  1.2.1+dfsg1-7+b1
ii  tzdata   2022a-1

Versions of packages ntpsec recommends:
ii  cron [cron-daemon]  3.0pl1-144

Versions of packages ntpsec suggests:
pn  apparmor   
ii  certbot1.25.0-1
ii  ntpsec-doc 1.2.1+dfsg1-7
pn  ntpsec-ntpviz  

-- Configuration Files:
/etc/default/ntpsec changed:
exit 0
NTPD_OPTS="-g -N"
IGNORE_DHCP="yes"
NTPSEC_CERTBOT_CERT_NAME=""

/etc/ntpsec/ntp.conf changed:
driftfile /var/lib/ntpsec/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
pool 0.ch.pool.ntp.org iburst
pool 1.ch.pool.ntp.org iburst
pool 2.ch.pool.ntp.org iburst
pool 3.ch.pool.ntp.org iburst
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict 192.168.17.0 mask 255.255.255.0 nomodify
restrict ::1
restrict source notrap nomodify noquery


-- no debconf information

-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1013581: Please rebuild to pick up the new libXi.6 dependency.

[Vincent Bernat]

Version: 3.19-9

On 6/24/22 13:39, Peter Pentchev wrote:

If this is the case, could you just request a binNMU?


Hm, that's actually an interesting idea... I'll look into it, and,
in that case, sorry for bothering you! :) So yeah, I will look into
it and probably close this bug accordingly.


I have uploaded a new version.

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Hi,

On 2022/6/26 03:30, Thomas Schmitt wrote:

Complexity-wise this replaces a slow O(n) algorithm by a faster O(n) and
an additional O(n * log(n)) run. At some size of Debian the slow speed
of the linear loop will be compensated by the sorting complexity.
But there is still room: A sort of 11,000 lines lasts about 0.03 seconds.



Theoretically if both file is already sorted, we can use the `-m' option 
(e.g. `sort -m -k 2 A.txt B.txt') to merge them in O(n) like mergesort. 
However I don't think O(n * log(n)) is a bottleneck so we may just keep 
it simple and stupid.



Best Regards,
Zhang Boyang