Bug#1070073: check_libs_ng sometimes returns "No such file or directory"

[Evgeni Golov]

On Mon, Apr 29, 2024 at 08:35:28PM +0200, Evgeni Golov wrote:
> UNKNOWN Exception: [Errno 2] No such file or directory: 
> 
> This is because the process might have already ended between calling
> os.listdir() and os.stat().

Turns out, os.path.realpath() also can raise FileNotFoundError.

Updated patch attached.
diff --git a/check_libs_ng/check_libs_ng b/check_libs_ng/check_libs_ng
index f260491..d042326 100644
--- a/check_libs_ng/check_libs_ng
+++ b/check_libs_ng/check_libs_ng
@@ -61,15 +61,18 @@ def main():
 logger.debug('checking process %s', proc_name)
 os.chdir(os.path.join(proc, 'map_files'))
 for map_file in os.listdir('.'):
-# all files in /map_files/ are absolute symlinks, so we don't 
need abspath()
-real_map_file_path = os.path.realpath(map_file)
-if not '/lib/' in real_map_file_path:
-logger.debug('skipping non-lib path %s', 
real_map_file_path)
-continue
-else:
-logger.debug('checking lib %s', real_map_file_path)
-if os.stat(map_file).st_nlink == 0:
-needs_reload.setdefault(proc_name, set()).add(proc_pid)
+try:
+# all files in /map_files/ are absolute symlinks, so we 
don't need abspath()
+real_map_file_path = os.path.realpath(map_file)
+if not '/lib/' in real_map_file_path:
+logger.debug('skipping non-lib path %s', 
real_map_file_path)
+continue
+else:
+logger.debug('checking lib %s', real_map_file_path)
+if os.stat(map_file).st_nlink == 0:
+needs_reload.setdefault(proc_name, set()).add(proc_pid)
+except FileNotFoundError:
+pass
 else:
 logger.debug('skipping kernel process %s', os.path.basename(proc))
 

Bug#1061770: ipmitool: unsupported LAN parameter lookup command returns an error

[Miao Wang]

control: severity -1 important

> 2024年4月30日 13:37，Miao Wang  写道：
> 
> Hi, all
> 
> The ipmitool repo has been migrated to https://codeberg.org/IPMITool/ipmitool
> and I have fixed this problem in the commit 
> https://codeberg.org/IPMITool/ipmitool/commit/137aeb
> 
> I raised the severity because this bug makes ipmitool lan unusable on several
> different platforms. I also hope maintainers can also backport this fix to the
> current stable version.
> 
> Cheers,
> 
> Miao Wang

Bug#1070040: bookworm-pu: package dm-writeboost/???

[Paul Gevers]

Hi,

On 30-04-2024 12:43 a.m., Andreas Beckmann wrote:

Testsuite: autopkgtest-pkg-dkms


Right. I was talking about Testsuite-Triggers in the sources file 
generated by dpkg. Unfortunately the automation one gets with autodep8 
doesn't extend that far and the triggers you are interested in are 
missing. Currently in unstable dm-writeboost has:

Testsuite-Triggers: dkms, dmsetup, stress-ng

(The dependencies for the first test contain unreleased changes that 
will try to fix the isolation-machine test, so you might see fewer deps 
on the package currently in the archive.)


That will fix the problem at hand.

Perhaps you can spot what's wrong with this setup s.t. it does not 
trigger as intended.


I hope it's clear now. Related, for future reference, we also have the 
hint-testsuite-triggers [1] restriction in autopkgtest.


Paul

[1] 
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061770: ipmitool: unsupported LAN parameter lookup command returns an error

[Miao Wang]

Hi, all

The ipmitool repo has been migrated to https://codeberg.org/IPMITool/ipmitool
and I have fixed this problem in the commit 
https://codeberg.org/IPMITool/ipmitool/commit/137aeb

I raised the severity because this bug makes ipmitool lan unusable on several
different platforms. I also hope maintainers can also backport this fix to the
current stable version.

Cheers,

Miao Wang

Bug#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Elliott Mitchell]

On Tue, Apr 30, 2024 at 05:55:15AM +0200, Andreas Metzler wrote:
> On 2024-04-29 Elliott Mitchell  wrote:
> > Package: libgnutls30
> > Version: 3.7.9-2+deb12u2
> > Severity: important
> 
> > Long story to finding this one.  Trying to get LDAP setup on this
> > network.  As a recent deployment it seemed appropriate to use IPv6.
> 
> > From `nslcd` on clients I was getting the message:
> > nslcd[12345]: [1a2b3c]  failed to bind to LDAP server 
> > ldaps://[fd12:3456:7890:abcd::3]/: Can't contact LDAP server: The TLS 
> > connection was non-properly terminated.: Resource temporarily unavailable
> 
> > Running `nslcd` in debug mode failed to yield any additional useful
> > information.
> 
> > Once I finally figured out `slapd`'s debug mode ('-h ldaps:/// ldapi:///'
> > is two arguments, the ldaps and ldapi are a single argument).  I got
> > traces from `slapd`: (serial numbers filed off)
> 
> > tls_read: want=5, got=5
> >   :  16 03 01 01 8f
> 
> > tls_read: want=399, got=399
> >   0160:fd12  
> >   0170::3456:7890:abcd:  
> >   0180::3.-.@.   
> > TLS: can't accept: A disallowed SNI server name has been received..
> > connection_read(13): TLS accept failure error=-1 id=1005, closing
> 
> > Further tracing of the error message appears to point to the function
> > `_gnutls_dnsname_is_valid()` in gnutls/lib/str.h.  Seems libgnutls30 is
> > incompatible with numeric IPv6 addresses.
> 
> > While IPv6-only hosts are presently uncommon, there is now quite a bit of
> > IPv6 traffic in many places.  I think this is worthy of having a severity
> > of "critical" as "bookworm" may remain as "stable" past when there is
> > more IPv6 traffic than IPv4 traffic.  For "trixie" this seems very
> > likely.
> [...]
> 
> Good morning,
> 
> I guess you used the IPv6 address as either CN or Subject Alternative
> Name. Both take names, not IP addresses. There is a different field for
> IP addresses.
> 
> gnutls-cli --port 636 fd12:3456:7890:abcd::3 
> 
> will probably give more info.
> 
> FWIW I have just generated a local test certificate with "IPAddress:"
> set to '::1' and things work for me as expected.

Hmm, `gnutls-cli --port ldaps` gave a different result.  The connection
successfully established and I was left being able to type to `slapd`.

Unfortunately that causes there to be 3 packages which could be the one
responsible for the problem.  Could be libgnutls30 as I originally
suspected.  Yet `slapd` and `nslcd` could also be responsible for the
problem.

The string "A disallowed SNI server name has been received." is found in
`libgnutls.so.30`.

The string "connection_read(%d): input error=%d id=%lu, closing." is
found in `/usr/sbin/slapd`.

Anything further is purely guesswork.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#908868: Want to help for upgrading docker.io package

[Prusty, Badrikesh]

Hello,

I am Badrikesh Prusty and wanted to help upgrading the docker.io package.

With the Debian packaging knowledge, I tried packaging docker.io v26.0.1 and 
its dependency components such as containerd, runc, etc.

When we tried installing this on Debian 11 and 12, docker and its components 
seems to work normally.

Kindly, provide further information on how the docker packages are validated, 
before it is pushed to apt repository.


Thanks & Regards,
Badrikesh Prusty

Bug#1070102: Requesting patch for llvm-toolchain-14

[Diane Trout]

Source: llm-toolchain-14
Version: 1:14.0.6-12

Hello,

python3-numba and packages using numba like python3-sparse are
segfaulting on ARM64, upstream maintainers are suggesting we backport
this small change.

https://github.com/llvm/llvm-project/commit/2e1b838a889f9793d4bcd5dbfe10db9796b77143

diff --git a/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp
b/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp
index 3c7f4ec47eb84c..282c357f2de2c4 100644
--- a/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp
+++ b/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp
@@ -2406,6 +2406,7 @@ Error RuntimeDyldELF::finalizeLoad(const
ObjectFile ,
 }
   }
 
+  GOTOffsetMap.clear();
   GOTSectionID = 0;
   CurrentGOTIndex = 0;
 

Here's the sparse developer recommending it;

https://github.com/pydata/sparse/issues/628#issuecomment-2076366957

And here's the numba comment.

https://github.com/numba/numba/issues/9109#issuecomment-2042747383

I tried to figure out how to build llvm, but wasn't sure how to get the
right set of patches for the branch I had checked out.

Thanks,
Diane

Bug#1070101: Judy: Please consider using VCS and host on Salsa for easier collaboration

[otto]

Package: judy
Severity: wishlist

Hi!

Based on package metadata and "VCS: unknown" at
https://tracker.debian.org/pkg/judy seems this package is not using any
version control.

Please consider using version control (preferably git) and host the package on
salsa.debian.org so that it is easier for others to contribute to the packaging
by submitting merge requests on Salsa, and just in general being able to view
package source and change history, and submit relevant patches/commits on the
latest version the original packager may be preparing for upload at any given
time.

Using Salsa may also help with package quality assurance, as it offers a CI for
automatic testing, and a Merge Request process for reviewing and accepting
contributions in a systematic way.

Thanks for considering!

Bug#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Andreas Metzler]

On 2024-04-29 Elliott Mitchell  wrote:
> Package: libgnutls30
> Version: 3.7.9-2+deb12u2
> Severity: important

> Long story to finding this one.  Trying to get LDAP setup on this
> network.  As a recent deployment it seemed appropriate to use IPv6.

> From `nslcd` on clients I was getting the message:
> nslcd[12345]: [1a2b3c]  failed to bind to LDAP server 
> ldaps://[fd12:3456:7890:abcd::3]/: Can't contact LDAP server: The TLS 
> connection was non-properly terminated.: Resource temporarily unavailable

> Running `nslcd` in debug mode failed to yield any additional useful
> information.

> Once I finally figured out `slapd`'s debug mode ('-h ldaps:/// ldapi:///'
> is two arguments, the ldaps and ldapi are a single argument).  I got
> traces from `slapd`: (serial numbers filed off)

> tls_read: want=5, got=5
>   :  16 03 01 01 8f

> tls_read: want=399, got=399
>   0160:fd12  
>   0170::3456:7890:abcd:  
>   0180::3.-.@.   
> TLS: can't accept: A disallowed SNI server name has been received..
> connection_read(13): TLS accept failure error=-1 id=1005, closing

> Further tracing of the error message appears to point to the function
> `_gnutls_dnsname_is_valid()` in gnutls/lib/str.h.  Seems libgnutls30 is
> incompatible with numeric IPv6 addresses.

> While IPv6-only hosts are presently uncommon, there is now quite a bit of
> IPv6 traffic in many places.  I think this is worthy of having a severity
> of "critical" as "bookworm" may remain as "stable" past when there is
> more IPv6 traffic than IPv4 traffic.  For "trixie" this seems very
> likely.
[...]

Good morning,

I guess you used the IPv6 address as either CN or Subject Alternative
Name. Both take names, not IP addresses. There is a different field for
IP addresses.

gnutls-cli --port 636 fd12:3456:7890:abcd::3 

will probably give more info.

FWIW I have just generated a local test certificate with "IPAddress:"
set to '::1' and things work for me as expected.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1070100: conky-all: Lua Scripts Not working with cairo_xlib_surface_create

[Tareeq Ali]

Package: conky-all
Version: 1.20.2-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: terroreek@chessclub.space

Dear Maintainer,

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

   * What led up to the situation? Upgraded Conky to 1.20.2-1
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I believe this is related to the upstream bug here; 
https://github.com/brndnmtthws/conky/issues/1867
   * What was the outcome of this action? Rolled conky back to 1.19.6-1+b1
   * What outcome did you expect instead? Rolling back fixed the problem

when on version 1.20.2-1 when starting conky, I would get this error; "conky: 
'gnome' wayland session running 'GNOME' destop
conky: llua_do_call: function conky_draw_bg execution failed: 
/home/terroreek/.conky/draw_bg.lua:32: attempt to call a nil value (global 
'cairo_xlib_surface_create')"


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


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

Kernel: Linux 6.8.8-1-siduction-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages conky-all depends on:
ii  libaudclient23.5~rc2-2+b1
ii  libc62.37-19
ii  libcairo21.18.0-3+b1
ii  libcurl3t64-gnutls   8.7.1-5
ii  libdbus-glib-1-2 0.112-3+b2
ii  libfontconfig1   2.15.0-1.1
ii  libgcc-s1    14-20240429-1
ii  libglib2.0-0t64  2.78.4-7
ii  libical3t64  3.0.17-1.1+b1
ii  libimlib2t64 1.12.1-1.1
ii  libircclient11.9-1+b2
ii  libiw30t64   30~pre9-17
ii  liblua5.3-0  5.3.6-2+b2
ii  libncurses6  6.4+20240414-1
ii  libpango-1.0-0   1.52.1+ds-1
ii  libpangocairo-1.0-0  1.52.1+ds-1
ii  libpangoft2-1.0-01.52.1+ds-1
ii  libpulse016.1+dfsg1-5
ii  librsvg2-2   2.58.0+dfsg-1
ii  libstdc++6   14-20240429-1
ii  libtinfo66.4+20240414-1
ii  libwayland-client0   1.22.0-2.1+b1
ii  libx11-6 2:1.8.7-1+b1
ii  libxdamage1  1:1.1.6-1+b1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2+b1
ii  libxft2  2.3.6-1+b1
ii  libxi6   2:1.8.1-1
ii  libxinerama1 2:1.1.4-3+b1
ii  libxml2  2.9.14+dfsg-1.3+b3
ii  libxnvctrl0  535.171.04-1

conky-all recommends no packages.

Versions of packages conky-all suggests:
pn  apcupsd
pn  audacious  
pn  moc
pn  mpd

-- no debconf information

Bug#1070099: RocksDB: Please consider using VCS and host on Salsa for easier collaboration

[otto]

Package: rocksdb
Severity: wishlist

Hi!

Based on package metadata and "VCS: unknown" at
https://tracker.debian.org/pkg/rocksdb seems this package is not using any
version control.

Please consider using version control (preferrably git) and host the package on
salsa.debian.org so that it is easier for others to contribute to the packaging
by submitting MRs on Salsa, and just in general being able to view package
source and change history, and submit relevant patches/commits on the latest
version the original packager may be preparing for upload at any given time.

Using Salsa may also help with package quality assurance, as it offers a CI for
automatic testing, and a Merge Request process for reviewing and accepting
contributions in a systematic way.

Thanks for considering!

Bug#1070098: openssh-sftp-server: False dependency on openssh-client

[Wolf]

Package: openssh-sftp-server
Version: 1:9.2p1-2+deb12u2
Severity: normal
X-Debbugs-Cc: wolfwi...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?

Was switching from OpenSSH to Dropbear due to installing on an extremely limited
system with <1GB total disk space available at the time, but needed to retain
SFTP support which requires the openssh-sftp-server package.

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

Manually installed the openssh-sftp-server package.

dpkg --ignore-depends=openssh-client -P openssh-client

This purged the openssh-client contents while leaving openssh-sftp-server 
intact,
allowing me to test functionality.

   * What was the outcome of this action?

Dependencies installed openssh-client package as well.

SFTP still worked after purging openssh-client, and openssh-sftp-server only has
a single executable inside of it so this appears to be a safe decoupling?

   * What outcome did you expect instead?

Only the openssh-sftp-server package to be installed, as it has no ties to the
openssh-client files and is in fact only used by the server side components.

Related but dropbear-bin also has a suggestion to install openssh-client,
however dropbear-bin includes all relevant key-generation tools natively,
so perhaps this 'Suggestion' should point to openssh-sftp-server instead?

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


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

Kernel: Linux 6.1.0-20-amd64 (SMP w/56 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openssh-sftp-server depends on:
ii  libc6   2.36-9+deb12u6
ii  openssh-client  1:9.2p1-2+deb12u2

Versions of packages openssh-sftp-server recommends:
ii  dropbear-bin [ssh-server]  2022.83-1+deb12u1

openssh-sftp-server suggests no packages.

-- no debconf information

Bug#1038435: libmariadb-java: Request to upgrade

[Otto Kekäläinen]

Control: retitle -1 libmariadb-java: Request to upgrade to MariaDB
Connector Java 3.x series

Hi!

Latest upstream version of MariaDB Connector Java is 3.3.3.
Current version in Debian is 2.7.6-1.

Do you have any plans to import the latest version to Debian?

- Otto

Bug#1002056: ITP: zlib-ng -- optimized zlib compression library

[David Heidelberg]

Hello,

I think it already makes sense to push zlib-ng and let it co-exist with 
zlib since you can port your software directly to the zlib-ng, which I'm 
currently doing for Mesa3D.


I dropped the zlib-ng sources into https://salsa.debian.org/dh/zlib-ng 
feel free to force push there any Debian relevant changes.


After introducing the zlib-ng, we could continue to the second phase 
migrating software still relying on zlib to zlib-ng compat layer.


What do you think?

David

On Mon, 6 Nov 2023 21:44:05 +0100 Sebastian Andrzej Siewior 
 wrote:


> On 2023-10-25 23:17:06 [+0200], Guillem Jover wrote:
> > Hi!
> Hi,
>
> > Ah, thanks! I had in my mind getting back to this ITP, given that the
> > zlib-ng project has continued to gain traction and seems to have
> > consolidated most of the other forks around it.
> >
> > So I'll draft another mail to Mark and probably to debian-devel to
> > discuss this.
>
> Do you want me to join your efforts? This looks interrestig. I may have
> time ;)
>
> > Thanks,
> > Guillem
>
> Sebastian
>
>

--
David Heidelberg

Bug#1070097: drawterm-9front: FTBFS: add support for loongarch64

[zhangdandan]

Source: drawterm-9front
Version: 1.15.1+dfsg-4.1
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the drawterm-9front failed for loong64 in the Debian Package 
Auto-Building environment.

The error log is as follows,
```
make[3]: Leaving directory '/<>/libip'
arch=`uname -m | sed -e 's/i.86/386/' \
         -e 's/Power Macintosh/power/' \
         -e 's/x86_64/amd64/' \
         -e 's/armv[567].*/arm/' \
         -e 's/\(aarch64\|armv8l\)/arm64/'`; \
(cd posix-$arch &&  make)
/bin/sh: 6: cd: can't cd to posix-loongarch64
make[2]: *** [Make.unix:22: libmachdep.a] Error 2
..
```

The Full log can be found at 
https://buildd.debian.org/status/logs.php?pkg=drawterm-9front=0%7Egit20220608.bee4db6-3=loong64.


I have added support for loongarch to drawterm-9front upstream and built 
successfully on my local ENV.
The pull request of the support for loongarch64, please see 
https://github.com/9fans/drawterm/pull/15.

Please review.

In addition, If you need a extra patch to Debian drawterm-9front 
package, you can contact me.

Your opinions are welcome.

Thanks,
Dandan Zhang

Bug#1070096: ITP: emacs-cfrs -- Child-frame based read-string for Emacs

[Xiyue Deng]

Package: wnpp
Severity: wishlist
Owner: Xiyue Deng 

* Package name: emacs-cfrs
  Version : 1.6.0
  Upstream Author : Alexander Miller  
* URL or Web page : https://github.com/Alexander-Miller/cfrs
* License : GPL-3+
  Programming lang: Emacs Lisp
  Description : Child-frame based read-string for Emacs
 cfrs.el is a simple alternative to `read-string' that allows reading
 input via a small child-frame spawned at the position of the
 cursor. Its goal is to make the string input interface closer to those
 used in modern GUI programs and to help the user with having to switch
 focus from whatever they are doing currently to look at the minibuffer.

This is a dependency of newer Emacs treemacs versions.  I intend to
maintain this package within the Debian Emacsen team
.

Bug#1070095: RFS: sslscan/2.1.3-1 -- Tests SSL/TLS enabled services to discover supported cipher suites

[Alejo Marín]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : sslscan
   Version  : 2.1.3-1
   Upstream contact : rbsec 
 * URL  : https://github.com/rbsec/sslscan
 * License  : GPL-3.0+ with OpenSSL exception
 * Vcs  : https://salsa.debian.org/debian/sslscan
   Section  : utils

The source builds the following binary packages:

  sslscan - Tests SSL/TLS enabled services to discover supported cipher suites

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

  https://mentors.debian.net/package/sslscan/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sslscan/sslscan_2.1.3-1.dsc

Changes since the last upload:

 sslscan (2.1.3-1) unstable; urgency=medium
 .
   [ Jhon Alejandro Marín Rodríguez ]
   * New upstream version 2.1.3
   * Update debian/watch file.
   * Created to perform a trivial smoke test.
   * Update Standards-Version to 4.7.0.
   * Add VCS-* fields with the repo URL in Salsa.d.o.
   * Extend debian copyright holder years.

Regards,
-- 
  jamarin90

-- 
*Jhon Alejandro Marín Rodríguez*

Bug#1036183:

[Jay]

It took me a while to wrap my mind around what was going on with PATH, gdm,
wayland sessions, X sessions, and systemd environment generators.

I'll try to summarize my findings here.

I initially found this change[0] to be the cause, but I am still not exactly
sure why or how it works.

I have been informed that we may be better off using systemd environment
generators[1][2] and import PATH from systemd which pulls from Debian's
/etc/profile.

Another suggestion is that we stop using /usr/games[3].


0: 
https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/92/diffs?commit_id=ccecd9c975d04da80db4cd547b67a1a94fa83292
1: https://gitlab.gnome.org/GNOME/gdm/-/issues/846
2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037084#10
3: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028543#15

Bug#1070094: RM: rust-gtk3-macros -- RoM; unmaintained library

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-gtk3-mac...@packages.debian.org
Control: affects -1 src:rust-gtk3-macros

Please remove rust-gtk3-macros from Debian. It is part of the Rust
GTK3 stack that is no longer maintained and is incompatible with the
Rust GNOME 46 packages.

https://bugs.debian.org/1064375

On behalf of the Debian Rust Maintainers,
Jeremy Bícha

Bug#1070093: RM: rust-gdk-sys -- RoM; unmaintained library

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-gdk-...@packages.debian.org
Control: affects -1 src:rust-gdk-sys

Please remove rust-gdk-sy from Debian. It is part of the Rust GTK3
stack that is no longer maintained and is incompatible with the Rust
GNOME 46 packages.

https://bugs.debian.org/1064375

On behalf of the Debian Rust Maintainers,
Jeremy Bícha

Bug#1070091: RM: rust-gdk -- RoM; unmaintained library

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-...@packages.debian.org
Control: affects -1 src:rust-gdk

Please remove rust-gdk from Debian. It is part of the Rust GTK3 stack
that is no longer maintained and is incompatible with the Rust GNOME
46 packages.

https://bugs.debian.org/1064375

On behalf of the Debian Rust Maintainers,
Jeremy Bícha

Bug#1070092: RM: rust-gtk -- RoM; unmaintained library

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-...@packages.debian.org
Control: affects -1 src:rust-gtk

Please remove rust-gtk from Debian. Rust GTK3 is no longer maintained
and is incompatible with the Rust GNOME 46 packages.

https://bugs.debian.org/1064375

On behalf of the Debian Rust Maintainers,
Jeremy Bícha

Bug#1070090: RM: rust-gdkx11- RoM; unmaintained library

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-gdk...@packages.debian.org
Control: affects -1 src:rust-gdkx11

Please remove rust-gdkx11 from Debian. It is part of the Rust GTK3
stack that is no longer maintained and is incompatible with the Rust
GNOME 46 packages.

https://bugs.debian.org/1064375

On behalf of the Debian Rust Maintainers,
Jeremy Bícha

Bug#1070086: RM: rust-gtk-sys -- RoM; unmaintained library

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Tags: moreinfo
X-Debbugs-Cc: rust-gtk-...@packages.debian.org
Control: affects -1 src:rust-gtk-sys
Control: block -1 by 1064373

Please remove rust-gtk-sys from Debian. It is part of the Rust GTK3
stack that is no longer maintained and is incompatible with the Rust
GNOME 46 packages.

https://bugs.debian.org/1064375

On behalf of the Debian Rust Maintainers,
Jeremy Bícha

Bug#1070089: RM: rust-gdkx11-sys-- RoM; unmaintained library

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-gdkx11-...@packages.debian.org
Control: affects -1 src:rust-gdkx11-sys

Please remove rust-gdkx11-sys from Debian. It is part of the Rust GTK3
stack that is no longer maintained and is incompatible with the Rust
GNOME 46 packages.

https://bugs.debian.org/1064375

On behalf of the Debian Rust Maintainers,
Jeremy Bícha

Bug#1070088: RM: rust-atk-sys -- RoM; unmaintained library

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-atk-...@packages.debian.org
Control: affects -1 src:rust-atk-sys

Please remove rust-atk-sys from Debian. It is part of the Rust GTK3
stack that is no longer maintained and is incompatible with the Rust
GNOME 46 packages.

https://bugs.debian.org/1064375

On behalf of the Debian Rust Maintainers,
Jeremy Bícha

Bug#1070087: RM: rust-atk -- RoM; unmaintained library

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-...@packages.debian.org
Control: affects -1 src:rust-atk

Please remove rust-atk from Debian. It is part of the Rust GTK3 stack
that is no longer maintained and is incompatible with the Rust GNOME
46 packages.

https://bugs.debian.org/1064375

On behalf of the Debian Rust Maintainers,
Jeremy Bícha

Bug#895897: Further comments on apt purge

[Andrew Athan]

Note that

apt purge ~c

does something, but apt(8) does not mention the support for the ~c 
parameter.


On my system, it seems to be attempting to remove all packages that have 
the "c" second character status in dpkg -l.  Unfortunately, this 
includes packages such as "locales" which I think are normally "ic", so 
this command does not seem appropriate for removing "rc" packages as 
suggested elsewhere.


The following packages will be REMOVED:
  bsdmainutils* grub-legacy-ec2* isc-dhcp-client* 
language-pack-en-base* linux-image-6.5.0-17-generic* 
linux-image-6.5.0-25-generic* linux-modules-6.5.0-17-generic* 
linux-modules-6.5.0-25-generic* linux-modules-extra-6.5.0-17-generic* 
linux-modules-extra-6.5.0-25-generic* locales*

  openvswitch-switch* reportbug* resolvconf* ufw* upower*

Bug#1070084: libkpimgapi-data: KAddressBook, and possibly related programs, fail to integrate with Google

[Daniel Melameth]

On Mon, Apr 29, 2024 at 4:56 PM Patrick Franz  wrote:
> Hi Daniel,
>
> this is a known problem as Google deprecated the Contacts API and
> replaced it with the People API. The KDE PIM in unstable, testing and
> stable is too old to support the People API which was added for 23.04.
>
> The only option to fix this is to update the entire KDE PIM stack
> (roughly 50 packages) to 23.04 or later. However, this is sadly not
> possible right now. I cannot give you a timeline when this is going to
> happen.
>
>
> --
> Med vänliga hälsningar
>
> Patrick Franz

Thanks for the prompt reply Patrick.  I realize this bug has been in
place for quite a while, but I wasn't sure if an official bug report
was needed to help get it resolved more timely as, yes, all releases
are affected.

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

[Miguel Landaeta]

On Sun, Apr 28, 2024 at 11:51 PM Guilherme Puida Moreira
 wrote:
>
> Hi Miguel,
>
> On Sun, Apr 28, 2024 at 10:54:54PM +0100, Miguel Landaeta wrote:
> > Can you also reach out to upstream and send your man page contribution
> > there, so you can gather feedback and other users can benefit if they
> > decide to merge it?
>
> Will do. Thanks for the ping!

qbe: https://ftp-master.debian.org/new/qbe_1.2-1.html

> By the way, you mentioned that you had a preliminary hare package on
> #1058645. If you need any help, just let me know.

I'll double check what's pending. Luckily these packages should be
very straightforward. I remember one concern from one of the
co-maintainers about maybe introducing a separate package for harec
and I think I also spotted a directory in the binary package that
could be not compliant with the Debian policy and the expected
filesystem layout.

However, those issues should be quick to sort, I hope. I'll check
what's up and post an update on the hare ITP bug (#1058645) soon.


--
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1058645: Do you need help with this package?

[Miguel Landaeta]

I apologize for dropping the ball on this one.

I just uploaded qbe to the archive and it's now waiting for NEW processing.

https://ftp-master.debian.org/new/qbe_1.2-1.html

The next step for me here is to get back to this bug report soon with
a link to the salsa repo for hare so other folks can take a look,
provide feedback and get this package uploaded in a reasonable time
frame.

--
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1070084: libkpimgapi-data: KAddressBook, and possibly related programs, fail to integrate with Google

[Patrick Franz]

Hi Daniel,

this is a known problem as Google deprecated the Contacts API and 
replaced it with the People API. The KDE PIM in unstable, testing and 
stable is too old to support the People API which was added for 23.04.

The only option to fix this is to update the entire KDE PIM stack 
(roughly 50 packages) to 23.04 or later. However, this is sadly not 
possible right now. I cannot give you a timeline when this is going to 
happen.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1070040: bookworm-pu: package dm-writeboost/???

[Andreas Beckmann]

On 29/04/2024 19.49, Paul Gevers wrote:
As I hinted at in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069600#25, once 
there's an *test* dependency relation with linux, this will be tested. 


There should be a test dependency on linux-doc, but unfortunately I 
cannot find any record that the uploads of src:linux to sid or 
bookworm-pu triggered a test for src:dm-writeboost. Nor any trace of the 
regression this should have caused. But I could be looking at the wrong 
places.


All *-dkms packages in bookworm (and trixie) do have
Testsuite: autopkgtest-pkg-dkms

and with autodep8 >= 0.26 (bookworm has 0.28) this should generate for 
src:dm-writeboost:



Tests: test-dm-writeboost.sh
Restrictions: needs-root, isolation-machine
Depends:
 dm-writeboost-dkms,
 linux-image-generic,
 linux-header-generic,
 stress-ng,
 dmsetup,
 sudo,


Test-Command: /usr/lib/dkms/dkms-autopkgtest
Restrictions: needs-root, breaks-testbed, allow-stderr, superficial,
Depends: dkms, openssl, linux-doc,
Features: test-name=dkms-autopkgtest


(The dependencies for the first test contain unreleased changes that 
will try to fix the isolation-machine test, so you might see fewer deps 
on the package currently in the archive.)


(The dependencies for the second test intentionally exclude 
dm-writeboost-dkms because we first need to disable dkms autoinstall 
before installing *-dkms (otherwise we could only get a non-verbose 
package installation failure). Then we can run the module build step by 
step and with improved error reporting including dumping make.log on 
failure.)


I chose linux-doc because
* it is a real package built from src:linux
* it does have an unversioned name
* it is available on all architectures
* it is available on all releases since (old)+stable for more 'old' 
releases than I could remember or lookup easily ;-)


Perhaps you can spot what's wrong with this setup s.t. it does not 
trigger as intended.



Andreas

Bug#1070042: libarchive: archive_entry_stat returns zero size on mips64el with _FILE_OFFSET_BITS=64

[Theodore Ts'o]

On Mon, Apr 29, 2024 at 11:12:54AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Source: libarchive
> Version: 3.7.2-2
> Severity: normal
> X-Debbugs-Cc: debian-m...@lists.debian.org, ty...@mit.edu
> Control: affects -1 src:e2fsprogs
> 
> the upload of e2fsprogs 1.47.1~rc1-1 to unstable yesterday uses a new
> feature where libarchive is used to create filesystem images from
> tarballs. This works on all architectures (main as well as ports) except
> on mips64el:
> 
> https://buildd.debian.org/status/package.php?p=e2fsprogs
> 
> I attached a minimal reproducer.

Thanks Johannes for doing the root cause analysis and coming up with
the minimal reproducer!

Please note that I am preparing to upload a new release of e2fsprogs
with qthe following workaround (see attached) so that e2fsprogs will
at least build on mips64el instead of FTBFS due to the rergression
test failure.

With this workaround, attempts to run mke2fs -d foo.tar will fail (but
only on mips64el):

(sid_mips64el-dchroot)tytso@eberlin:~/e2fsprogs/e2fsprogs$ 
./debian/BUILD-STD/misc/mke2fs -t ext4 -d foo.tar -Fq foo.img 1G
__populate_fs_from_tar: you need to compile e2fsprogs with libarchive to be 
able to process tarballs
mke2fs: Operation not permitted while populating file system

The build log which shows the failure without this work around can be
found here:

https://buildd.debian.org/status/fetch.php?pkg=e2fsprogs=mips64el=1.47.1%7Erc1-1=1714294103=0

Cheers,

- Ted


commit 018cd6e9a659917ac1374775f5a60b1cf0be182c
Author: Theodore Ts'o 
Date:   Mon Apr 29 16:31:14 2024 -0400

debian: don't build with libarchive on mips64el

The libarchive functionality in "mke2fs -d foo.tar" is breaking the
regression test[1].  Since this is working everywhere _except_
mips64el, as a short-term workaround disable libarchive support on
this platform until it can be fixed.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070042

Signed-off-by: Theodore Ts'o 

diff --git a/debian/rules b/debian/rules
index 6e98d9150..12dd56acc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -61,6 +61,11 @@ CC ?= $(DEB_HOST_GNU_TYPE)-gcc
 COMMON_CONF_FLAGS += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
 endif
 
+# work around Debian Bug #1070042
+ifeq ($(DEB_HOST_ARCH),mips64el)
+COMMON_CONF_FLAGS += --without-libarchive
+endif
+
 %:
dh $@ -B${stdbuilddir}
 

Bug#1070085: Enhancing default home folder permissions for improved privacy

[Håvard F . Aasen]

Package: login
Version: 1:4.13+dfsg1-4
Severity: normal


Hi,

Could default home folder permissions lean towards greater privacy,
while administrators can adjust permissions to be less strict if
necessary? In my mind, this is a more practical approach to both
security and privacy.

Several distributions, including Ubuntu, Fedora [1], Arch [2] and
openSUSE [3], have already implemented more privacy-oriented permissions.

What I would like is to have 'HOME_MODE' [4] uncommented.
Would it be possible to implement this, or a similar change in Debian?


Regards,
-- 
Håvard


[1] 
https://src.fedoraproject.org/rpms/shadow-utils/blob/rawhide/f/shadow-utils.login.defs
[2] 
https://gitlab.archlinux.org/archlinux/packaging/packages/shadow/-/blob/main/0003-Add-Arch-Linux-defaults-for-login.defs.patch?ref_type=heads
[3] 
https://build.opensuse.org/projects/openSUSE:Factory/packages/shadow/files/shadow-login_defs-suse.patch
[4] 
https://salsa.debian.org/debian/shadow/-/blob/master/debian/login.defs?ref_type=heads#L156

Bug#997441: squirrel3: FTBFS: '! LaTeX Error: File `tgtermes.sty' not found.'

[Pierre-Elliott Bécue]

Hi,

Thanks for the patch.

Fabian, I uploaded the NMU with a 7 days delay. Reach out if you see a
good reason to either cancel or delay further this NMU.

Bests,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for principles than to live up to them.
From e054c7aa6fdd402ab63709e15103aab1f50e6119 Mon Sep 17 00:00:00 2001
From: Matthias Geiger 
Date: Mon, 29 Apr 2024 23:38:16 +0200
Subject: [PATCH 1/2] Fix watch file to look for Github tags instead of
 releases

---
 debian/changelog | 7 +++
 debian/watch | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 592b24f..c303908 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+squirrel3 (3.1-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix watch file to look for Github tags instead of releases 
+
+ -- Matthias Geiger   Fri, 16 Feb 2024 17:46:43 +0100
+
 squirrel3 (3.1-8) unstable; urgency=medium
 
   * Change build dependency from texlive-generic-extra to
diff --git a/debian/watch b/debian/watch
index c174a72..e3733e4 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
 version=4
 opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%squirrel-$1.tar.gz%" \
- https://github.com/albertodemichelis/squirrel/releases \
+ https://github.com/albertodemichelis/squirrel/tags \
  (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
-- 
2.43.0

From fd3d4b9b6014eef4691759b264491a1a370b78c3 Mon Sep 17 00:00:00 2001
From: Matthias Geiger 
Date: Mon, 29 Apr 2024 23:39:24 +0200
Subject: [PATCH 2/2] Build-depend on tex-gyre

Closes: #997441
---
 debian/changelog | 5 +++--
 debian/control   | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index c303908..b2aacdd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,10 @@
-squirrel3 (3.1-8.1) UNRELEASED; urgency=medium
+squirrel3 (3.1-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
   * Fix watch file to look for Github tags instead of releases 
+  * Build-depend on tex-gyre (Closes: #997441)
 
- -- Matthias Geiger   Fri, 16 Feb 2024 17:46:43 +0100
+ -- Matthias Geiger   Mon, 29 Apr 2024 23:39:09 +0200
 
 squirrel3 (3.1-8) unstable; urgency=medium
 
diff --git a/debian/control b/debian/control
index c504be7..43afebb 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,8 @@ Build-Depends: debhelper-compat (= 12),
texlive,
texlive-latex-extra,
texlive-plain-generic,
-   latexmk
+   latexmk,
+   tex-gyre,
 Standards-Version: 4.4.0
 Homepage: http://squirrel-lang.org/
 Vcs-Git: https://salsa.debian.org/wolff-guest/squirrel3.git/
-- 
2.43.0



signature.asc
Description: PGP signature

Bug#1070084: libkpimgapi-data: KAddressBook, and possibly related programs, fail to integrate with Google

[Daniel]

Package: libkpimgapi-data
Version: 22.12.3-1
Severity: important
X-Debbugs-Cc: dan...@melameth.com

Dear Maintainer,

   * What led up to the situation?

I'm new to Linux, and, with the popularity of Gmail and related, I attempted to 
configure KAddressBook to access my Gmail Contacts, but it did not work.

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

I attempted to Add a New Address Book using Google Groupware, but it does not 
work.

   * What was the outcome of this action?

I was unable to use the program as intended.

   * What outcome did you expect instead?

I expected the program to integrate with my Gmail Contacts, much like 
KOrganizer integrates with my Gmail Calendar.

This bug appears to be resolved in newer versions of the program; some details 
may be found at https://bugs.kde.org/show_bug.cgi?id=446580 and 
https://bugs.kde.org/show_bug.cgi?id=439285.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#1070083: linux: Do we still need sched-autogroup-disabled.patch in 2024?

[Alex Volkov]

Source: linux
Severity: normal

Dear Maintainer,

I can't see why something which can be done with a kernel boot parameter or a
sysctl variable
needs to be forced in the source since 2011. Also, the very existence of this
new default is non-transparent for anyone relying on official kernel
documentation. Is it even mentioned in any README or something? Because I
couldn't find anything.


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 
'stable'), (99, 'testing'), (90, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.13-bootes0-p-1000 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#1068759: quickml: quickml fails to install

[Sudip Mukherjee]

Control: tags -1 patch
--

On Wed, Apr 10, 2024 at 01:38:17PM +0100, Sudip Mukherjee wrote:
> Package: quickml
> Version: 0.8-1
> Severity: normal
>
> Dear Maintainer,
>
> quickml fails to install with the error:

debdiff attached.

-- 
Regards
Sudip
diff -Nru quickml-0.8/debian/changelog quickml-0.8/debian/changelog
--- quickml-0.8/debian/changelog2022-12-28 14:47:16.0 +
+++ quickml-0.8/debian/changelog2024-04-29 21:44:49.0 +0100
@@ -1,3 +1,13 @@
+quickml (0.8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix quickml failure to install. (Closes: #1068759)
+- d/control: Add runtime dependency on ruby-thwait.
+- d/postinst: Create /etc/mailname if it does not exist.
+- d/postrm: Remove /etc/mailname.
+
+ -- Sudip Mukherjee   Mon, 29 Apr 2024 21:44:49 
+0100
+
 quickml (0.8-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru quickml-0.8/debian/control quickml-0.8/debian/control
--- quickml-0.8/debian/control  2022-12-28 14:47:01.0 +
+++ quickml-0.8/debian/control  2024-04-29 21:44:49.0 +0100
@@ -9,7 +9,7 @@
 Package: quickml
 Architecture: all
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ruby:any, lsb-base, ${misc:Depends}
+Depends: ruby:any, lsb-base, ruby-thwait, ${misc:Depends}
 Description: Very-easy-to-use mailing list system
  quickml server is a very-easy-to-use mailing list system.
  quickml server provides very-easy-to-use mailing list service.
diff -Nru quickml-0.8/debian/postinst quickml-0.8/debian/postinst
--- quickml-0.8/debian/postinst 2022-12-28 14:43:34.0 +
+++ quickml-0.8/debian/postinst 2024-04-29 21:43:51.0 +0100
@@ -26,6 +26,9 @@
 case "$1" in
 configure)
chown list:list /var/lib/quickml /var/log/quickml
+   if [ ! -e /etc/mailname ]; then
+   touch /etc/mailname
+   fi
 ;;
 
 abort-upgrade|abort-remove|abort-deconfigure)
diff -Nru quickml-0.8/debian/postrm quickml-0.8/debian/postrm
--- quickml-0.8/debian/postrm   2022-12-28 14:43:34.0 +
+++ quickml-0.8/debian/postrm   2024-04-29 21:43:51.0 +0100
@@ -22,6 +22,7 @@
 case "$1" in
 purge)
rm -rf /var/run/quickml
+   rm -f /etc/mailname
 ;;
 remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disapper)
 ;;

Bug#1070082: ponyprog: Add Appstream metainfo announcing HW support

[Petter Reinholdtsen]

Package: ponyprog
Version: 3.1.1+ds-1
Tags: patch

Here is a patch for ponyprog to add Appstream metainfo XML announcing
the hardware handled by this package.  The list of USB IDs in the
modalias list was fetched from udev/rules.d/90-ponyprog.rules.  I was
unsure if the disabled entries should be included, but thought it best
to keep the in the list.

Including this information in the package will ensure programs mapping
hardware to packages using Appstream information, like the isenkram
package, will know that this package is useful on machines where the USB
IDs are discovered.

diff --git a/debian/copyright b/debian/copyright
index 0115ef0..fc33ab3 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -28,6 +28,29 @@ Copyright: 2015-2017, Winfried Simon
  2017, Mykhailo Lytvyn 
 License: LGPL-2.1
 
+Files: debian/ponyprog.metainfo.xml
+Copyright: 2024 Petter Reinholdtsen
+License: MIT
+ Permission is hereby granted, free of charge, to any person obtaining
+ a copy of this software and associated documentation files (the
+ "Software"), to deal in the Software without restriction, including
+ without limitation the rights to use, copy, modify, merge, publish,
+ distribute, sublicense, and/or sell copies of the Software, and to
+ permit persons to whom the Software is furnished to do so, subject to
+ the following conditions:
+ .
+ The above copyright notice and this permission notice shall be
+ included in all copies or substantial portions of the Software.
+ .
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ SOFTWARE.
+
 License: GPL-2+
  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
diff --git a/debian/ponyprog.install b/debian/ponyprog.install
index 7f876ad..d6bf4f6 100644
--- a/debian/ponyprog.install
+++ b/debian/ponyprog.install
@@ -1,3 +1,4 @@
 icons/ponyprog.svg usr/share/icons/hicolor/scalable/apps
 lib/udev/rules.d/90-ponyprog.rules
 usr
+debian/ponyprog.metainfo.xml usr/share/metainfo
diff --git a/debian/ponyprog.metainfo.xml b/debian/ponyprog.metainfo.xml
new file mode 100644
index 000..3cc3bad
--- /dev/null
+++ b/debian/ponyprog.metainfo.xml
@@ -0,0 +1,41 @@
+
+
+  com.github.lancos.ponyprog
+  MIT
+  ponyprog
+  Serial device programmer
+  
+PonyProg is a serial device programmer software with a user
+friendly GUI framework available for Windows and Linux. It's
+purpose is reading and writing every serial device. With PonyProg
+and SI-Prog you can program Wafercard for SAT, eeprom within GSM,
+TV or CAR-RADIO.  Furthermore it can be used as a low cost starter
+kit for PIC and AVR.
+
+Ponyprog supports AVR, SPI eeprom, AVR micro, 12C bus 8bit
+eeprom, PIC 16 micro, PIC 12 micro, AT89S micro and SDE2506 eeprom
+family chips.
+
+You can open any HEX, e2p, mot, csm, rom, eep, bin files and
+burn them to uC or PIC. You can even backup the old program on the
+chip using Ponyprog. Ponyprog enables the user to write, verify
+and erase data on the microchip.
+
+Also setting fuse bits and locks using Ponyprog is
+possible. You can save any HEX file to BIN file or eep file, BIN
+file to HEX file or MOT file and vice versa so you can use
+Ponyprog as converter too. Ponyprog offers serial or parallel port
+programming for uC's. You can even change polarity of control
+lines without touching the wires using I/O port setup.
+
+Using Ponyprog together with generic USB2serial adapters is
+currently not possible! There are plans on upstream to use libusb
+to add such functionality.
+  
+  
+usb:v1A86p5523d*
+usb:v1A86p7523d*
+usb:v1A86p5512d*
+usb:v0403p6E38d*
+  
+

-- 
Happy hacking
Petter Reinholdtsen

Bug#1070081: i915 driver crash on 12th Gen in bzflag

[Malte]

Package: linux-image-6.6.15-amd64
Version: 6.6.15-2
Severity: normal

Dear Maintainers,

when I play bzflag, the screen freezes and only the mouse cursor is
active. These are the error messages I see in the logs:

Apr 29 21:27:54 aquin kernel: i915 :00:02.0: [drm] *ERROR* GT0:
GUC: Engine reset failed on 0:0 (rcs0) because 0x
Apr 29 21:27:54 aquin kernel: i915 :00:02.0: [drm] GPU HANG: ecode
12:1:84db, in bzflag [106852]
Apr 29 21:27:54 aquin kernel: i915 :00:02.0: [drm] Resetting chip
for GuC failed to reset engine mask=0x1
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): EDID vendor "AUO", prod id 53905
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): Using hsync ranges from config file
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): Using vrefresh ranges from config file
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): Printing DDC gathered Modelines:
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): Modeline "1920x1200"x0.0  156.10  1920 1936 1952 2104
1200 1203 1217 1236 -hsync -vsync (74.2 kHz eP)
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): EDID vendor "AUO", prod id 53905
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): Using hsync ranges from config file
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): Using vrefresh ranges from config file
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): Printing DDC gathered Modelines:
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): Modeline "1920x1200"x0.0  156.10  1920 1936 1952 2104
1200 1203 1217 1236 -hsync -vsync (74.2 kHz eP)
Apr 29 21:27:54 aquin kernel: i915 :00:02.0: [drm] *ERROR* rcs0
reset request timed out: {request: 0001, RESET_CTL: 0001}
Apr 29 21:27:54 aquin kernel: i915 :00:02.0: [drm] *ERROR* rcs0
reset request timed out: {request: 0001, RESET_CTL: 0001}
Apr 29 21:27:54 aquin kernel: i915 :00:02.0: [drm] Xorg[1585]
context reset due to GPU hang
Apr 29 21:27:54 aquin kernel: i915 :00:02.0: [drm] bzflag[106852]
context reset due to GPU hang
Apr 29 21:27:54 aquin kernel: i915 :00:02.0: [drm] GT0: GuC
firmware i915/adlp_guc_70.bin version 70.5.1
Apr 29 21:27:54 aquin kernel: i915 :00:02.0: [drm] GT0: HuC
firmware i915/tgl_huc.bin version 7.9.3
Apr 29 21:27:54 aquin kernel: i915 :00:02.0: [drm] GT0: HuC:
authenticated for all workloads
Apr 29 21:27:54 aquin kernel: i915 :00:02.0: [drm] GT0: GUC:
submission enabled
Apr 29 21:27:54 aquin kernel: i915 :00:02.0: [drm] GT0: GUC: SLPC enabled
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): EDID vendor "AUO", prod id 53905
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): Using hsync ranges from config file
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): Using vrefresh ranges from config file
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): Printing DDC gathered Modelines:
Apr 29 21:27:54 aquin /usr/libexec/gdm-x-session[1585]: (II)
modeset(0): Modeline "1920x1200"x0.0  156.10  1920 1936 1952 2104
1200 1203 1217 1236 -hsync -vsync (74.2 kHz eP)

I get this line from /proc/cpuinfo

12th Gen Intel(R) Core(TM) i5-1235U

I searched the internet and found almost the exact same problem in the
Archlinux forum here:

https://bbs.archlinux.org/viewtopic.php?id=287207

Thank you!

Malte

Bug#1070069: fossil: CVE-2024-24795 unreleated breakage

[Barak A. Pearlmutter]

uploaded

Bug#1051924: metadata

[Santiago Vila]

found 1051924 2.21.3+deb11u1
tags 1051924 + bullseye
thanks

Hello. The version in bullseye also fails in test test/test_debchange.

Thanks.

Bug#1070080: remmina: check old releases for compatibility with freerdp2 security updates

[Jeremy Bícha]

Source: remmina
Version: 1.3.3+dfsg-2
Severity: important
Tags: security

I noticed that the Ubuntu Security Team updated remmina in Ubuntu
20.04 LTS to make it compatible with the freerdp2 security update they
pushed a few days ago. Perhaps similar coordinated uploads need to
happen for old Debian releases.

https://launchpad.net/ubuntu/+source/remmina/1.4.25+dfsg-0ubuntu0.20.04.1
https://ubuntu.com/security/notices/USN-6752-1

Thank you,
Jeremy Bícha

Bug#1070079: nghttp3: Update to 1.1.0 or newer

[Samuel Henrique]

Source: nghttp3
X-Debbugs-Cc: c...@packages.debian.org, samuel...@debian.org
Version: 1.1.0-1
Severity: wishlist

Hello Sakirnth, I hope you're doing well.

I see that you uploaded nghttp3 1.1.0-1 and ngtcp2 1.1.0-1 to experimental
already.

Do you have any plans to push those to unstable anytime soon?

I would like to enable HTTP3 on libcurl-gnutls and it requires:
nghttp3: v1.1.0
ngtcp2: v1.2.0

The latest releases are:
nghttp3 v1.2.0
ngtcp2 v1.4.0

So maybe it even makes sense to get the latest releases for the transition.

Would you be interested in any kind of help for this?

If you would like, we could also put the package under the curl team. We are
not a "real team" in the sense that we don't gate contributions, that's just to
make it more easy and clear that people should feel free to do team-uploads.

Regards,

--
Samuel Henrique 

Bug#1070078: remmina: please build with freerdp3

[Jeremy Bícha]

Source: remmina
Version: 1.4.35+dfsg-1
Severity: wishlist

Please build remmina with freerdp3 now that it's available in Unstable.

If you do that, you'll need to also cherrypick the fix from
https://gitlab.com/Remmina/Remmina/-/merge_requests/2579
which is being tracked in Ubuntu 24.04 LTS as
https://launchpad.net/bugs/2062177 (since Ubuntu switched to freerdp3
early).

Thank you,
Jeremy Bícha

Bug#1070077: ships files directly in /usr/onionprobe

[Antoine Beaupre]

Package: onionprobe
Version: 1.0.0+ds-2.1+deb12u1
Severity: serious

The Debian package shipped in bookworm right now changed the path to
the examples/ directory. It used to be:

/usr/lib/python3/dist-packages/onionprobe/examples/tpo.py

 and now seems to be:

/usr/onionprobe/examples/tpo.py

Apart from the gratuitous change, this seems to be a violation of the
FHS policy, packages shouldn't ship their own stuff directly under
/usr like this...

I haven't checked in unstable to see if this is fixed.

A.

-- System Information:
Debian Release: 12.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages onionprobe depends on:
ii  adduser3.134
ii  init-system-helpers1.65.2
ii  python33.11.2-1+b1
ii  python3-cryptography   38.0.4-3
pn  python3-prometheus-client  
ii  python3-requests   2.28.1+dfsg-1
ii  python3-socks  1.7.1+dfsg-1
ii  python3-stem   1.8.1-2.1
ii  python3-yaml   6.0-3+b2
ii  tor0.4.7.16-1

onionprobe recommends no packages.

Versions of packages onionprobe suggests:
pn  prometheus  

Bug#1037084:

[Jay]

On Sat, Jun 17, 2023 at 4:55 AM Alban Browaeys  wrote:
> This bug would likely be fixed by Debian (the systemd package?)
> shipping a /usr/lib/systemd/user-environment-generators/ systemd user
> environment generator with the default PATH Debian already set in
> /etc/profile.
I plan to check with the Debian systemd package maintainers about this option.

But
> Or ship an  /usr/lib/environment.d/*.conf file (which itself is read by
> a systemd user environment generator : /usr/lib/systemd/user-
> environment-generators/30-systemd-environment-d-generator).
This might be the solution we're looking for. A
/usr/lib/environment.d/??-gdm3.conf file
provided by the gdm3 package?

Bug#1070057: mutter: Severe keyboard input lag/pauses

[Jeremy Bícha]

On Mon, Apr 29, 2024 at 8:42 AM Florian Cramer  wrote:
> Package: mutter
> Version: 46.0-1
> Severity: important
> X-Debbugs-Cc: flrnc...@gmail.com
>
> Dear Maintainer,
>
> In all programs that rely on mutter and/or Gnome/GTK libraries for keyboard
> input, I am experiencing severe keyboard input lag/pauses, sometimes for
> several seconds. This might be a problem that only occurs in xorg with the
> Nvidia driver, and is identical to what has been described here:
> https://gitlab.gnome.org/GNOME/mutter/-/issues/3384

I believe this is fixed in mutter 46.1 which I have just uploaded to
Experimental. Could you update to that version when it's available and
see if the problem goes away after you restart your computer?

Thank you,
Jeremy Bícha

Bug#1070069: fossil: CVE-2024-24795 unreleated breakage

[Barak A. Pearlmutter]

will do

Bug#1068951: new upstream (6.x)

[Daniel Baumann]

On 4/29/24 19:50, Daniel Baumann wrote:
pushing to the repo requires me to be added to the salsa project.. would 
you mind adding me?


in the meantime, I've pushed to here:
https://git.progress-linux.org/users/daniel.baumann/debian/todo/knot-resolver/log/

before I'll continue: what's the idea of adding knot-resolver-manager 
binary package?


I can't think of a reason why one would use kresd (knot-resolver-core) 
without the manager, and thus, would fold knot-resolver-manager and 
knot-resolver-core (back) into knot-resolver. But probably I'm missing 
something..


Regards,
Daniel

Bug#1027978: micro-httpd: sends invalid HTTP when listing unreadable directories

[Martin-Éric Racine]

ma 29. huhtik. 2024 klo 20.59 Sudip Mukherjee
(sudipm.mukher...@gmail.com) kirjoitti:
>
> On Mon, 29 Apr 2024 at 09:00, Martin-Éric Racine
>  wrote:
> >
> > On Thu, 05 Jan 2023 13:08:45 + Vincent Duvert  
> > wrote:
> > > Package: micro-httpd
> > > Version: 20140814-2.1+b2
> > > Severity: normal
> > > Tags: patch
> > > X-Debbugs-Cc: report...@duvert.net
> >
> > I have an NMU ready to cover this, debdiff attached.
>
> Thanks for the debdiff. But the diff is removing few of the Depends:
>
> micro-inetd | netcat-traditional | systemd-sysv
>
> Was that intentional or did you miss them? If intentional, then can
> you please explain why those are not needed now.

What is currently there is exactly what Lintian wants to see for any
package that updates any variant of inetd. Any additional alternative
makes Lintian barf, and overriding this particular one would not make
sense.

Meanwhile, systemd-sysv has a priority:important so it comes installed
by default on Linux-based hosts. If the Depends was only there because
you ship a systemd unit, it's not needed.

Martin-Éric

Bug#1070069: fossil: CVE-2024-24795 unreleated breakage

[Bastien Roucariès]

Le lundi 29 avril 2024, 18:40:39 UTC Barak A. Pearlmutter a écrit :
> Bastien,
> 
> Okay, got it. Thanks for letting me know.
> 
> I can cherry-pick that fossil commit, but you know the right magic for
> a versioned apache2 breakage and how to deal with proposed-updates.
> So I think it would make sense for you to do all of this in a
> coordinated fashion?

Yes except for unstable where you could go without coordination

Fixed apache is 2.4.59-1

So I think a
breaks: apache2 (<<2.4.59-1~) 

is safe on your side (transition will be blocked)

When done I will upload a apache2 version with
breaks: fossil ( << 2.4.59-2~)

I will do the bpu when done with release team

Bastien
> If that's okay with you, please feel free to just do a regular upload
> if you want, or an NMU, as you please.
> I will push your changes into the debian fossil branch, unless you'd
> like write access to my fossil packaging repo
>  https://people.debian.org/~bap/fossil.fsl
> which I'd be happy to set up.


> 
> Cheers,
> 
> --Barak.
> 



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

Bug#1070076: deborphan: [INTL:nl] Dutch translation for the deborphan package

[Frans Spiesschaert]

 
 
Package: deborphan 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the deborphan package. 
A draft has been posted to the debian-l10n-dutch mailing list allowing for
review. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1070075: kwartz-client: [INTL:nl] Dutch debconf templates translation

[Frans Spiesschaert]

 
 
Package: kwartz-client 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of kwartz-client
debconf messages. A draft has been posted to the debian-l10n-dutch mailing
list allowing for review. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1070069: fossil: CVE-2024-24795 unreleated breakage

[Barak A. Pearlmutter]

Bastien,

Okay, got it. Thanks for letting me know.

I can cherry-pick that fossil commit, but you know the right magic for
a versioned apache2 breakage and how to deal with proposed-updates.
So I think it would make sense for you to do all of this in a
coordinated fashion?
If that's okay with you, please feel free to just do a regular upload
if you want, or an NMU, as you please.
I will push your changes into the debian fossil branch, unless you'd
like write access to my fossil packaging repo
 https://people.debian.org/~bap/fossil.fsl
which I'd be happy to set up.

Cheers,

--Barak.

Bug#1070074: several errors on tab completion

[Ivan Sergio Borgonovo]

Package: bash-completion
Version: 1:2.12.0-1

Upgrading from  1:2.11-8 to 1:2.12.0-1 causes several errors at tab 
completion or starting bash.


...
bash: _comp_deprecate_func: command not found
bash: _comp_deprecate_var: command not found
bash: _comp_deprecate_var: command not found
bash: _comp_deprecate_var: command not found
bash: _comp_have_command: command not found
bash: _comp_have_command: command not found
...

Reverting to previous version didn't help.

This was due to util-linux-extra being put on hold, since once I updated
2.40-5 -> 2.40-8
util-linux-extra
util-linux
eject
bsdextrautils
libsmartcols1
libblkid1
libmount1
mount
libuuid1
util-linux
libfdisk1

the problem went away.

Probably some version dependency should be added.

thanks

--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#1064235:

[Noah Meyerhans]

On Thu, Apr 18, 2024 at 10:17:27AM +0200, Arthur LUTZ wrote:
>A small heads up on this issue, we have some minor impacts :
>* sudo commands show a warning
> 
>  sudo: unable to resolve host example: Name or service not known

Thanks for the report.  This is resolved with the 20240429 images.

noah

Bug#1070073: check_libs_ng sometimes returns "No such file or directory"

[Evgeni Golov]

Package: monitoring-plugins-contrib
Version: 42.20230308+deb12u1+b1
Tags: patch

Ohai,

on systems with many short-lived processes (like a monitoring server,
spawning many check_* commands), I regularly see check_libs_ng return

UNKNOWN Exception: [Errno 2] No such file or directory: 

This is because the process might have already ended between calling
os.listdir() and os.stat().

Attached is a patch that catches the exception and pretends the process
does not need restarting.
(FileNotFoundError is Python 3.3+, if you for some arcane reason need
support for older Pythons, catch OSError instead.)

Thanks
Evgeni
diff --git a/check_libs_ng/check_libs_ng b/check_libs_ng/check_libs_ng
index f260491..44ad0f1 100644
--- a/check_libs_ng/check_libs_ng
+++ b/check_libs_ng/check_libs_ng
@@ -68,8 +68,11 @@ def main():
 continue
 else:
 logger.debug('checking lib %s', real_map_file_path)
-if os.stat(map_file).st_nlink == 0:
-needs_reload.setdefault(proc_name, set()).add(proc_pid)
+try:
+if os.stat(map_file).st_nlink == 0:
+needs_reload.setdefault(proc_name, set()).add(proc_pid)
+except FileNotFoundError:
+pass
 else:
 logger.debug('skipping kernel process %s', os.path.basename(proc))
 

Bug#684425: closed by Vincent Cheng (Re: conky-std: please implement an alternative way to distinguish among hwmon devices)

[Francesco Poli]

On Mon, 29 Apr 2024 01:15:03 + Debian Bug Tracking System wrote:

> Version: 1.11.6-1
> 
> Closing since upstream has implemented this [1], as mentioned earlier by Jmkr.
> 
> [1] https://github.com/brndnmtthws/conky/commit/14e3b80c45254743e962f88d

Yes, sorry for not following up: I [said] I was testing this new way to
specify the hwmon device, but then I forgot to announce that the tests
went well.

[said]: 

Thanks for closing the bug report.
Bye!   :-)


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgppn6wK0L14m.pgp
Description: PGP signature

Bug#1069258: ruby-curb: test regression with curl 8.7.1: client read function EOF fail, only only 4/5 of needed bytes read

[Samuel Henrique]

Hello all,

> These messages with "only only (n)/(n+1) of needed bytes read" seem to
> be characteristic. As well as being a FTBFS, this is also an autopkgtest
> regression when upgrading curl, which is one of several factors preventing
> curl from migrating; that, in turn, blocks elfutils, which blocks GLib,
> which will likely be blocking a significant chunk of the 64-bit time_t
> transition.

I believe this is an issue on ruby-curb and not on curl, check the following
thread on curl-library for details and possible solutions:
https://curl.se/mail/lib-2024-03/0054.html

Cheers,

--
Samuel Henrique 

Bug#1027978: micro-httpd: sends invalid HTTP when listing unreadable directories

[Sudip Mukherjee]

On Mon, 29 Apr 2024 at 09:00, Martin-Éric Racine
 wrote:
>
> On Thu, 05 Jan 2023 13:08:45 + Vincent Duvert  
> wrote:
> > Package: micro-httpd
> > Version: 20140814-2.1+b2
> > Severity: normal
> > Tags: patch
> > X-Debbugs-Cc: report...@duvert.net
>
> I have an NMU ready to cover this, debdiff attached.

Thanks for the debdiff. But the diff is removing few of the Depends:

micro-inetd | netcat-traditional | systemd-sysv

Was that intentional or did you miss them? If intentional, then can
you please explain why those are not needed now.


-- 
Regards
Sudip

Bug#1070019: [Pkg-utopia-maintainers] Bug#1070019: udisks2: autopkgtest failure: fsconfig system call failed: /dev/sr1: Can't open blockdev

[Chris Hofstaedtler]

* Chris Hofstaedtler  [240429 15:24]:
> > udisks2's autopkgtest fails when tried together with util-linux 2.40. An
> > example can be seen here:
> > https://ci.debian.net/packages/u/udisks2/testing/amd64/46012968/
> > 
> > 537s ==
> > 537s FAIL: test_ext4 (__main__.FS.test_ext4)
> > 537s fs: ext4
> > 537s --
> > 537s Traceback (most recent call last):
> > 537s   File 
> > "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", line 
> > 1107, in _do_udisks_check
> > 537s cd_fs.call_mount_sync(ro_options, None)
> > 537s gi.repository.GLib.GError: udisks-error-quark: 
> > GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/sr1 
> > at /media/root/41b1acb1-744c-422a-9071-2dba5368a683: fsconfig system call 
> > failed: /dev/sr1: Can't open blockdev (0)
> > 537s
> > 537s During handling of the above exception, another exception occurred:
> > 537s
> > 537s Traceback (most recent call last):
> > 537s   File 
> > "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", line 
> > 725, in test_ext4
> > 537s self._do_fs_check('ext4')
> > 537s   File 
> > "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", line 
> > 894, in _do_fs_check
> > 537s self._do_udisks_check(fs_type)
> > 537s   File 
> > "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", line 
> > 1112, in _do_udisks_check
> > 537s self.fail('Mounting read-only device with \'rw\' option failed'
> > 537s AssertionError: Mounting read-only device with 'rw' option failedwith 
> > an unexpected error.
> > 537s Got: udisks-error-quark: 
> > GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/sr1 
> > at /media/root/41b1acb1-744c-422a-9071-2dba5368a683: fsconfig system call 
> > failed: /dev/sr1: Can't open blockdev (0)
> > 537s Expected: 'is write-protected but explicit read-write mode requested' 
> > or 'is write-protected but `rw' option given'
 

> I won't get to it this week (also re: stable v2.40.1), but maybe
> someone else has seen this failure already?

Having said that, it seems likely the test was broken by this
change in util-linux:
  libmount: report kernel message from new API
  
https://github.com/util-linux/util-linux/commit/9da5644e414cdc318f0311260dabc6035c85b58e

I don't know if the error messages are supposed to be stable or not,
but it looks like a very intentional change :-)

Orthogonally, "/dev/sr1: Can't open blockdev" seems not very
informative if it's supposed to mean "write-protected but `rw'
option given".

Chris

Bug#1068951: new upstream (6.x)

[Daniel Baumann]

On 4/23/24 14:45, Jakub Ružička wrote:
Awesome, I've forwarded your words of praise to the hard-working Knot 
Resolver team :)


(jftr: we switched in 2015 from cisco ncr to unbound, and in 2016 from 
unbound to knot-resolver.. and are super happy ever since)



I'm actually quite interested in (the nightmares of) python packaging


hehe :)

Cool, I've already mental-marked you as a person I'm gonna bother with 
reviewing my v6 changes even before your willing reply :)


no problem, looking forward to it :)

IOW ~/src/knot-resolver/distro/pkg/deb and ~/debian/knot-resolver/debian 
should be as close as possible.


+1

Feel free to push your changes (if any) to debian/experimental or use 
your branch as you prefer, I'm always eager to learn how other DDs do 
things.


pushing to the repo requires me to be added to the salsa project.. would 
you mind adding me?


Regards,
Daniel

Bug#1070040: bookworm-pu: package dm-writeboost/???

[Paul Gevers]

Hi Andreas,

On 29-04-2024 10:52 a.m., Andreas Beckmann wrote:

These failures could show up as autopkgtest failures in bookworm-pu.
Are they flagged somewhere in your tooling s.t. they don't go unnoticed?


As I hinted at in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069600#25, once 
there's an *test* dependency relation with linux, this will be tested. 
Current regressions can be seen here: 
https://release.debian.org/proposed-updates/stable.html, look for "c-i".


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#725712: Hello

[Aron Mafokate]

I am Crystal Ingram Patel, I've been trying to contact you.



The contents of this communication, including attachments is strictly 
confidential and legally privileged, and is intended for the use of the named 
recipient(s). Any review, retransmission, dissemination, copying, disclosure or 
other use of, or taking an action in reliance upon this information by persons 
or entities other than the intended recipient is prohibited. If you have 
received this message in error, please notify the sender immediately by return 
email and delete the message. Any views expressed in this e-mail are those of 
the individual sender and no liability will attach to Government of Botswana. 
Please note that the recipient must scan this email and any attached files for 
viruses and the like.

Bug#1069378: picom: FTBFS on arm64: cc: error: unrecognized command-line option '-Wunknown-warning-option'

[Nikos Tsipinakis]

block -1 by 1069408
thanks

Hi,

The title of this bug is not a compilation error, it's a feature test. This is 
actually failing because of 1069408. 

>> Pkg-config error with 'xcb-present': Could not generate cflags for 
>> xcb-present:
>> Package xcb-dri3 was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `xcb-dri3.pc'
>> to the PKG_CONFIG_PATH environment variable
>> Package 'xcb-dri3', required by 'xcb-present', not found
>> 
>> Dependency lookup for xcb-present with method 'pkgconfig' failed: Could not 
>> generate cflags for xcb-present:
>> Package xcb-dri3 was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `xcb-dri3.pc'
>> to the PKG_CONFIG_PATH environment variable
>> Package 'xcb-dri3', required by 'xcb-present', not found
>> 
>> CMake binary for host machine is cached as not found
>> Dependency lookup for xcb-present with method 'cmake' failed: CMake binary 
>> for machine host machine not found. Giving up.
>> Run-time dependency xcb-present found: NO 
>> 
>> ../src/meson.build:31:15: ERROR: Dependency lookup for xcb-present with 
>> method 'pkgconfig' failed: Could not generate cflags for xcb-present:
>> Package xcb-dri3 was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `xcb-dri3.pc'
>> to the PKG_CONFIG_PATH environment variable
>> Package 'xcb-dri3', required by 'xcb-present', not found

Cheers,
Nikos

Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?

[Xiyue Deng]

Xiyue Deng  writes:

> Xiyue Deng  writes:
>
>> Sean Whitton  writes:
>>
>>> Hello,
>>>
>>> On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote:
>>>
 Sean Whitton  writes:

> Hello,
>
> Rob, can you review the implementation in d/rules for Xiyue's patch to
> this bug, please?  I'm not sure it's the straightforward way to do it.
>
> Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2),
> for the relationships.

 Ah indeed, I should update the versions after the Emacs 29.3 upload,
 though I think you meant "1:29.3+1-2".  Also, as we are just moving
 files from emacs-common to emacs-pgtk, breaks/replaces is only needed
 from emacs-pgtk to emacs-common but no the other way around, so I
 dropped the breaks on emacs-pgtk from emacs-common.

 I have updated the patch accordingly and attached here.  PTAL.
>>>
>>> Thanks.
>>>
 (BTW, I'm always curious about the "+1" part of the version number.  I
 would expect something like "+dfsg" or "+ds" as we are dropping some
 of the non-DFSG conformant files, but why "+1"? :)
>>>
>>> It's just in case the DFSG split is done incorrectly and another attempt
>>> is required -- given how complex it is.
>>
>> Ack, totally understandable.
>>
>> With the release of Emacs 1:29.3+1-2, I have rebased the patch onto it
>> and bumped the breaks/replaces version.  PTAL.
>
> Rob suggested on IRC to be a bit more conservative by removing the file
> and remove the directories upwards recursively so that we can catch
> future addition to the directories more easily.  The patch has been
> adjusted accordingly.  PTAL.

Friendly ping.  Rob, do you have any more comments on the current approach?

-- 
Xiyue Deng

Bug#1066875: devscripts: debsign tries to parse gpg version from human-readable output, should use machine-readable output

[Daniel Kahn Gillmor]

Hi Guillem--

On Sat 2024-04-27 23:13:13 +0200, Guillem Jover wrote:
> I was just modifying this code for another report I'm about to file,
> and instead wondered why have it at all! I'm proposing simply removing
> the backwards compat code given that even in oldstable gnugp1 is
> already at verison 1.4.23. See attached patch.

yes, that seems like an even better choice.  the 1.4.x line of GnuPG is
poorly supported these days, and doesn't handle modern cryptography
(including the 25519 keys that are used by a lot of DDs these days).

Thanks for looking into this, Guillem!

   --dkg


signature.asc
Description: PGP signature

Bug#1068953: new upstream (10.0)

[Daniel Baumann]

On 4/29/24 18:31, David Lamparter wrote:

Did you run into issues that forced you up to 2.1.148?  The "officially
listed" (= in configure.ac) requirement is 2.1.128, if we(upstream)
missed something I'd look into getting that listed minimum bumped up
too.


Rechecking the frr 10 announcement.. says indeed 2.1.128 not 2.1.148. 
totally my fault, I'm very sorry about that!


(I'm running frr 10 with 2.1.148 here since some days now with no issues 
though)



Is there some way to debug this?


You can ask for (hppa) porterbox access; accounts to porterboxes are 
given to non-DD/DMs too:


  https://dsa.debian.org/doc/guest-account/

If you send me the data requested there, I'll sign it so you can get access.

Regards,
Daniel

Bug#1068953: new upstream (10.0)

[David Lamparter]

Quick offshoot mail on build details, ...

On Mon, Apr 29, 2024 at 06:13:14PM +0200, Daniel Baumann wrote:
> On 4/29/24 16:56, David Lamparter wrote:
> > FRR definitely requires libyang 2.1.128.
> 
> hm, frr 10 needs libyang2 2.1.148.

Did you run into issues that forced you up to 2.1.148?  The "officially
listed" (= in configure.ac) requirement is 2.1.128, if we(upstream)
missed something I'd look into getting that listed minimum bumped up
too.

> > There's also a bit of a problem in #1067077
> 
> I've fixed that already, just waiting some more minutes on the build to 
> finish on the armel porterbox.

I'll throw that upstream as well when I see it in your 0.3, Thanks!

Also, apropos porterbox, I have no way of debugging the hppa build
problem that has been there in 9.1 already;  FRR does some "slightly
cursed" things that have python code figuring out C struct sizes that
seems to be going wrong.  Is there some way to debug this?

Cheers,


-equi

Bug#1070016: quake4: hard-coded dependencies on pre-t64 libraries

[Simon McVittie]

On Mon, 29 Apr 2024 at 17:12:05 +0200, Sebastian Ramacher wrote:
> It will also help dak to decruft the pre-t64 from unstable and render
> game-data-packages as good on the transition trackers.

OK. Would it be OK to make these dependencies be of the form
"libasound2t64 | libasound2" and so on, or is it a requirement that we
use only the new name?

The version of game-data-packager in testing/unstable has generally
remained installable on older suites like stable, and I'd prefer that
to remain true if possible (but if that's a problem for the transition,
then we can sacrifice that desirable property to simplify things).

game-data-packager generates non-distributable .deb packages which can
be installed onto end-user systems, and some of those have dependencies
too, of which at least libsmpeg-0.4.so.0 has been affected by this
transition. To avoid needing to know the target Debian release when
generating those packages, I'd prefer to turn that into a dependency
on libsmpeg0t64 | libsmpeg0 rather than just libsmpeg0t64 if that isn't
going to be disruptive.

I believe libasound2t64 is the only one of these dependencies that will
affect the packages in contrib.

smcv

Bug#1068953: new upstream (10.0)

[Daniel Baumann]

Hi David,

On 4/29/24 16:56, David Lamparter wrote:

I can't do uploads myself (not a DM/DD)


no problem - I'm happy to sponsor your uploads if you want me to ;)


FRR definitely requires libyang 2.1.128.


hm, frr 10 needs libyang2 2.1.148.

which, as you noted, is already uploaded so for now - situation is fine.


I really need to merge master back
into the debian branches on the FRR repo to pick that up, I can probably
get to that today or tomorrow.


that would be nice; and again, happy to help/to sponsor any uploads.


There's also a bit of a problem in #1067077


I've fixed that already, just waiting some more minutes on the build to 
finish on the armel porterbox.


Regards,
Daniel

Bug#1067077: frr: FTBFS on armel: /usr/bin/ld: ./build/../bgpd/bgp_io.c:476:(.text+0x51c): undefined reference to `__atomic_store_8'

[Daniel Baumann]

tag 1067077 +pending
thanks

Hi,

my initial attempt in 10.0-0.2 to link with libatomic didn't work, I've 
fixed that locally but a build to confirming on an armel porterbox is 
runnning before uploading 10.0-0.3 in some minutes..


Regards,
Daniel

Bug#1070072: RM: moonshot-ui -- ROM; poorly maintained upstream

[Sam Hartman]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: moonshot...@packages.debian.org
Control: affects -1 + src:moonshot-ui



After discussing with upstream, we no longer believe it makes sense to
include the moonshot suite in a stable Linux distribution.
See the discussion from the moonshot-community list this weekend.

Bug#1070071: RM: moonshot-gss-eap -- ROM; poorly maintained upstream

[Sam Hartman]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: moonshot-gss-...@packages.debian.org
Control: affects -1 + src:moonshot-gss-eap



After discussing with upstream, we no longer believe it makes sense to
include the moonshot suite in a stable Linux distribution.
See the discussion from the moonshot-community list this weekend.

Bug#1070070: RM: moonshot-trust-router -- ROM; poorly maintained upstream

[Sam Hartman]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: moonshot-trust-rou...@packages.debian.org
Control: affects -1 + src:moonshot-trust-router



After discussing with upstream, we no longer believe it makes sense to
include the moonshot suite in a stable Linux distribution.
See the discussion from the moonshot-community list this weekend.

Bug#1070069: fossil: CVE-2024-24795 unreleated breakage

[Bastien Roucariès]

Package: fossil
Severity: serious
Justification: break unreleated package
affects: apache2

Dear Maintainer,

CVE-2024-24795 is fixed in apache2. However it break fossil

You need to apply https://fossil-scm.org/home/info/f4ffefe708793b03

See bug here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

I can help here and do proposed update

We also need to use breaks relationship in apache2, in order to allow smooth
upgrade

Bastien



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

Bug#1070016: quake4: hard-coded dependencies on pre-t64 libraries

[Sebastian Ramacher]

On 2024-04-28 18:39:22 +0100, Simon McVittie wrote:
> On Sun, 28 Apr 2024 at 17:27:21 +0200, Sebastian Ramacher wrote:
> > quake4 has hard-coded dependencies on shared libraries (at least
> > libasound2) that were renamed as part of the t64 transition. Please
> > update the dependencies accordingly.
> 
> quake4 is i386-only, and i386 has Provides for the old names and no real
> ABI break, so I don't think this is necessarily RC - although updating
> quake4 in src:game-data-packager might help apt to choose better upgrade
> paths, so it's a valid bug.
> 
> (The i386 binaries referenced by quake4 - really in the quake4-bin package
> produced by game-data-packager - are proprietary and non-modifiable,
> and target the pre-t64 ABI.)

It will also help dak to decruft the pre-t64 from unstable and render
game-data-packages as good on the transition trackers.

Cheer
-- 
Sebastian Ramacher

Bug#1067077: atomic operations on 64-bit time_t

[Sebastian Ramacher]

On 2024-04-29 16:45:16 +0200, David Lamparter wrote:
> On Mon, Mar 18, 2024 at 12:42:56AM +0100, Sebastian Ramacher wrote:
> > Source: frr
> > Version: 9.1-0.1
> > Justification: fails to build from source (but built successfully in the 
> > past)
> [...]
> > https://buildd.debian.org/status/fetch.php?pkg=frr=armel=9.1-0.1=1710631814=0
> [...]
> > ./build/../bgpd/bgp_vty.c:13678:(.text+0x1d934): undefined reference to 
> > `__atomic_load_8'
> [...]
> 
> This is due to FRR using "_Atomic time_t", which ... with the 64-bit
> time_t transition is now 8 bytes, and armel, hppa, m68k, powerpc and sh4
> can't do 64-bit atomic ops...

Linking with -latomic fixes that.

Cheers

> 
> I'm not sure what the best fix for this is, I looked at
> https://wiki.debian.org/ReleaseGoals/64bit-time but there is no mention
> of atomic ops on time_t.  Googling didn't yield anything either.  Is frr
> the only package using "_Atomic time_t"?
> 
> Input appreciated...
> 
> 
> -equi (David)

-- 
Sebastian Ramacher

Bug#1070068: add-apt-repository throw error with ppa

[Denis Chenu (Shnoulle)]

Package: software-properties-common
Version: 0.99.30-4

When try to install a PPA, always get a error : AttributeError: 
'NoneType' object has no attribute 'people'


follow instruction on https://github.com/yuezk/GlobalProtect-openconnect

root@Belgarion:~# add-apt-repository -P ppa:yuezk/globalprotect-openconnect
Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 362, in 
    sys.exit(0 if addaptrepo.main() else 1)
  ^
  File "/usr/bin/add-apt-repository", line 345, in main
    shortcut = handler(source, **shortcut_params)
   ^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 
86, in __init__

    if self.lpppa.publish_debug_symbols:
   ^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 
126, in lpppa

    self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
  ^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 
113, in lpteam

    self._lpteam = self.lp.people(self.teamname)
   ^^
AttributeError: 'NoneType' object has no attribute 'people'

Try with
# add-apt-repository ppa:yuezk/globalprotect-openconnect
# add-apt-repository -ppa yuezk/globalprotect-openconnect

Same error

Bug#1069254: nwipe: FTBFS: configure: error: libconfig library not found

[M. van Brummelen]

Hi,

On 2024-04-29 10:28, Bo YU wrote:

Tags: patch

hi,
On Thu, Apr 18, 2024 at 10:00:30PM +0200, Sebastian Ramacher wrote:


checking for libconfig... no
checking for main in -llibconfig... no
configure: error: libconfig library not found


It seems it shuold use libconfig-dev.



Thanks didn't have the time to test/verify this yet.
Will test/fix and upload in a few days.

Kind regards,
Martijn van Brummelen



Cheers
-- Sebastian Ramacher

Bug#1068953: new upstream (10.0)

[David Lamparter]

Hi Daniel,

On Sun, Apr 14, 2024 at 08:40:29AM +0200, Daniel Baumann wrote:
> it would be nice if you could upload the newly released frr version. If 
> you need/want help, I'm happy to do so, just let me know.

Sorry about this...  I've tried to improve this before, this problem is
social in nature in that I can't do uploads myself (not a DM/DD) and
unfortunately due to personal conditions the cost in "brain energy" to
do these interactions is... massive.

I see you've uploaded an FRR and libyang package.  I can't speak to
libyang2 at all, but (you probably saw) FRR definitely requires libyang
2.1.128.  Finding some solution for libyang2 is presumably a similar
problem, just with someone else ;).

Other than this, there are in fact updates to the debian/ directory in
FRR's master branch.  One thing that stood out to me is the missing
"mkdir /var/lib/frr" in postinst.  I really need to merge master back
into the debian branches on the FRR repo to pick that up, I can probably
get to that today or tomorrow.

There's also a bit of a problem in #1067077, which is caused by the
64-bit time_t transition.  I'm not sure what the solution for that will
be, but it's a blocker since armel is affected and that's still a
mainline Debian arch...

Cheers (& Apologies),


-equi (David)

Bug#1070067: debian-cd: daily arm64 netinst image: GRUB menu is complex

[Roland Clobus]

Package: debian-cd
Version: 3.2.1
Severity: minor
User: debian...@lists.debian.org
Usertags: openqa

Hello maintainers of the arm64 netinst image,

The issue:
Recently I've updated the openQA boot walk test [1] to match the actual 
GRUB boot menu for the arm64 netinst image (taken from the daily builds 
[2]). It has a very complex structure (up to 5 levels deep) and offers 
many similar options in the sub menus.

Is this intentional?

Expected:
The GRUB menu for arm64 is identical to or only slightly different from 
the amd64 netinst image.


With kind regards,
Roland Clobus

[1] https://openqa.debian.net/tests/255725


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070066: xserver-xorg-core: xserver doesn't come with XTEST extension

[dklonowski]

Package: xserver-xorg-core
Version: 2:21.1.12-1
Severity: normal
X-Debbugs-Cc: dklonowsk...@gmail.com

Hello,

I wanted to remotely use my main laptop. So as usuall i've installed and fired 
up x11vnc.
To my surprise no Windows VNC client was able to do anything input-wise besides 
moving mouse pointer.
I've tried to build x11vnc from source - no luck
Close investigation of x11vnc's output revealed this message in startup logs

29/04/2024 16:40:55 WARNING: XTEST extension not available (either missing from
29/04/2024 16:40:55   display or client library libXtst missing at build time).
29/04/2024 16:40:55   MOST user input (pointer and keyboard) will be DISCARDED.
29/04/2024 16:40:55   If display does have XTEST, be sure to build x11vnc with
29/04/2024 16:40:55   a working libXtst build environment (e.g. libxtst-dev,
29/04/2024 16:40:55   or other packages).
29/04/2024 16:40:55 No XTEST extension, switching to -xwarppointer mode for

running x11vnc with -debug_keyboard revealed this while pressing 'f' key on VNC 
client
(...)
29/04/2024 16:41:57 Using tight encoding for client 172.16.31.134
29/04/2024 16:41:59 # keyboard(down, 0x66 "f") uip=0  16.5888
29/04/2024 16:41:59 xkb_tweak_keyboard: down keysym=0x66 "f"
29/04/2024 16:41:59 XTestFakeKeyEvent(dpy, keycode=0x29 "f", down)
29/04/2024 16:41:59 skipped input: keyboard: no-XTEST
29/04/2024 16:41:59 # keyboard(up, 0x66 "f") uip=0  16.6694

i've tried to create xorg.conf snippet to load modules 'record', 'xtest' and/or 
'test' but no luck
xdpyinfo -ext all shows
(...)
BIG-REQUESTS
Composite
DAMAGE
DOUBLE-BUFFER
DPMS
DRI2
GLX
Generic Event Extension
MIT-SCREEN-SAVER
MIT-SHM
Present
RANDR
RENDER
SECURITY
SHAPE
SYNC
X-Resource
XC-MISC
XFIXES
XFree86-DGA
XFree86-VidModeExtension
XINERAMA
XInputExtension
XKEYBOARD
XVideo
(...)

I believe this might be missclick while building package as i haven't found 
verbose information in package's changelog about extension removal.
Else, if XTEST should be long gone, how else i could force x11vnc-alikes to 
work?

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Coffee Lake-S GT2 
[UHD Graphics P630] [8086:3e94]
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107GLM [Quadro 
P2000 Mobile] [10de:1cba] (rev a1)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 28
-rw-r--r-- 1 root root 193 Mar 29 21:01 00-zap
-rw-r--r-- 1 root root  56 Apr 29 16:12 01-x11vnc.conf
-rw-r--r-- 1 root root 289 Dec 22  2021 69-kotoskrol.conf
-rw-r--r-- 1 root root 101 Jul  3  2022 80-numpaddot.conf
-rw-r--r-- 1 root root 359 Mar 30 16:08 90-intel.conf
-rw-r--r-- 1 root root 226 Dec  6 21:55 90-xpra-virtual.conf
-rw-r--r-- 1 root root  36 Apr 20 12:50 99-virtualgl-dri.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 6.6.15-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.2.0-13) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP 
PREEMPT_DYNAMIC Debian 6.6.15-2 (2024-02-04)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 44016 Apr 29 16:25 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[626965.402] 
X.Org X Server 1.21.1.11
X Protocol Version 11, Revision 0
[626965.402] Current Operating System: Linux precision 6.6.15-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.6.15-2 (2024-02-04) x86_64
[626965.402] Kernel command line: BOOT_IMAGE=/vmlinuz-6.6.15-amd64 
root=/dev/mapper/dellstor-rootfs ro noibrs noibpb nopti nospectre_v2 
nospectre_v1 nospec_store_bypass_disable no_stf_barrier mitigations=off 
nvidia-drm.modeset=0
[626965.402] xorg-server 2:21.1.12-1 (https://www.debian.org/support) 
[626965.402] Current version of pixman: 0.42.2
[626965.402]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[626965.402] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[626965.402] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Apr 29 16:24:31 
2024
[626965.403] (==) Using config directory: "/etc/X11/xorg.conf.d"
[626965.403] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[626965.403] (==) ServerLayout "layout"
[626965.403] (**) |-->Screen "intel" (0)
[626965.403] (**) |   |-->Monitor ""
[626965.404] (**) |   |-->Device "intel"
[626965.404] (==) No monitor specified for screen "intel".
Using a default monitor 

Bug#1067077: atomic operations on 64-bit time_t

[David Lamparter]

On Mon, Mar 18, 2024 at 12:42:56AM +0100, Sebastian Ramacher wrote:
> Source: frr
> Version: 9.1-0.1
> Justification: fails to build from source (but built successfully in the past)
[...]
> https://buildd.debian.org/status/fetch.php?pkg=frr=armel=9.1-0.1=1710631814=0
[...]
> ./build/../bgpd/bgp_vty.c:13678:(.text+0x1d934): undefined reference to 
> `__atomic_load_8'
[...]

This is due to FRR using "_Atomic time_t", which ... with the 64-bit
time_t transition is now 8 bytes, and armel, hppa, m68k, powerpc and sh4
can't do 64-bit atomic ops...

I'm not sure what the best fix for this is, I looked at
https://wiki.debian.org/ReleaseGoals/64bit-time but there is no mention
of atomic ops on time_t.  Googling didn't yield anything either.  Is frr
the only package using "_Atomic time_t"?

Input appreciated...


-equi (David)

Bug#1070065: plymouth: Duplicate kernel logs on console with unconfigured plymouth package

[Laurent Cheylus]

Package: plymouth
Version: 24.004.60-1+b2
Severity: normal

Dear Maintainer,

on Debian testing/amd64 with Linux kernel 6.6.15-amd64, during the boot, I have 
duplicate kernel/system messages on my console:

- "normal" logs prefixed with timestamp
- some duplicate logs without timestamp displayed in light blue color

plymouth package is installed but not configured/used to display graphical
animation or logs during boot.

To fix my issue (display only "normal" kernel/system logs during boot), I need
to desinstall plymouth package via 'apt remove plymouth'.

Thanks, Laurent

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plymouth depends on:
ii  init-system-helpers  1.66
ii  initramfs-tools  0.142
ii  libc62.37-18
ii  libdrm2  2.4.120-2
ii  libplymouth5 24.004.60-1+b2
ii  systemd  255.4-1
ii  udev 255.4-1

plymouth recommends no packages.

Versions of packages plymouth suggests:
ii  desktop-base 12.0.6+nmu1
pn  plymouth-themes  

Bug#1070064: separate columns by 2 spaces in lists

[Christoph Berg]

Package: apt
Version: 2.9.2
Severity: wishlist

Hi,

I like the output to format lists of packages into ls-style tables
very much, thanks.

A suggestion: I would prefer if the columns were separated by 2 spaces
instead of just one, to make the spacing visually better. ls does that
as well, and my eyes are trained to reading that.

What makes it perhaps worse is that a lot of package names have - dashes
in them, which look a bit like (single) spaces on first glance. Using
double spaces would fix that problem as well.

Last instance of the problem here was this:

REMOVING:
  libhwy1 python3-editables

... which looked like libhwy1-python3-editables to me.

Thanks for considering,
Christoph

Bug#1069978: bash: incorrect value of $BASH for login shells

[Chet Ramey]

On 4/28/24 6:18 PM, Gioele Barabucci wrote:

On 28/04/24 22:50, Chet Ramey wrote:

On 4/28/24 3:07 PM, Gioele Barabucci wrote:

 $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'

 /bin/bash
 /usr/bin/bash-static
 -bash-static


So argv[0] == "-bash-static", which causes $0 to be set to -bash-static
and internally sets shell_name to "bash-static" and login_shell to 1
(which notes that bash was executed with argv[0][0] == '-').

Then when you get to setting $BASH, this code gets executed:

   if ((login_shell == 1) && RELPATH(shell_name))
 {
   if (current_user.shell == 0)
 get_current_user_info ();
   name = savestring (current_user.shell);
 }

which has been the way bash has behaved since the bash-1.x days. Is
this enough of an issue to change behavior that dates back that far?


The bash manual defines $BASH as follows:


Expands to the full filename used to invoke this instance of bash.

So, either the code or the manual should be changed.

I see why changing such an old behavior for the sake of correctness may not 
be worth the risk of breaking somebody's workflow. But at the same time it 
is hard to believe that anybody may be relying on "$BASH contains the user 
shell set up in /etc/passwd when read from a login shell".


I think the original intent of this code -- it was a very long time ago --
was that a login shell either came from login/getty/xterm or su. If it came
from su, the name in argv[0] was either "-su" (the traditional behavior of
`su -'/`su -l') or the user's login shell. The Linux-specific business of
specifying the shell to use didn't come along until much later. Non-Linux
systems still put "su"/"-su" in argv[0].

In that light, it's easy to see what's happening. You want to change "-su"
to something reasonable, and the user's login shell is what su always uses.
If it's already the login shell, no loss.

I think we can fix this Linux issue by checking for and changing "-su"/"su"
to the login shell and letting other pathnames through.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#956194: streamlit status

[Andrius Merkys]

Hello,

Is anybody still interested in streamlit? Some time ago I packaged its 
dependency node-xxhashjs and ended up maintaining it. I do not use 
node-xxhashjs myself and would like to pass its maintenance to people 
interested in streamlit.


Andrius

Bug#1059679: lua-json missing lua 5.4 files

[Samuel Wolf]

Hi,

I'm running into the same issue, is it possible to provide an update
for this package?

Thanks.

Samuel

Bug#1063417: bookworm-pu: package libapache2-mod-qos/11.74-1+deb12u1

[Jérôme Charaoui]

Le 2024-04-07 à 06 h 41, Jonathan Wiltshire a écrit :

On Mon, Feb 26, 2024 at 10:50:39AM -0500, Jérôme Charaoui wrote:

I had an exchange with a fellow DD about this update and uploading this to
bookworm-backports was suggested as a possible alternative considering the
large size of the .debdiff :


olasd | lavamind: in terms of policy, a backport would be allowed (it's a

new upstream release, it's in testing, and you seem to be using the package,
so you might as well upload it to bpo); That still leaves a buggy package in
bookworm, if the bookworm package has never worked, pulling in the newer
upstream release into a stable update may be deemed acceptable by the SRMs;
looking at the upstream changelog of libapache2-mod-qos, the changes for
compatibility with pcre2 (which is what our apache2 now builds against,
since 2.4.52-2) have been introduced in libapache2-mod-qos upstream 11.73.
Backporting the pcre2 support to the libapache2-mod-qos version in bookworm
isn't a very sensible option IMO, in terms of maintainability

If SRMs agree with this assessement, I can close this bug and prepare and
upload to bookworm-backports instead.


It's one sensible path forward and it gives you more flexibility, but it
leaves a gap for users upgrading from bullseye.

Long term, is a new maintainer forthcoming? The orphan bug doesn't seem to
have any interest since being opened in 2019 and there weren't any uploads
at all until last year. Maybe its future should be considered first and
then that will inform the decision about how to handle stable.


I don't think I can personnally adopt this package considering my 
packaging Debian work-load at the moment. I also noticed a dozen or so 
other Apache modules are also orphaned at the moment and in need of a 
new maintainer, so it seems like the issue might be even a little wider 
than just this single package.


I'll go ahead with uploading a backport, it will at least provide an 
upgrade path option for users, even if a manual one.


Thanks,

-- Jérôme

Bug#1069427: macaulay2: FTBFS on armhf: make[4]: *** [Makefile:50: check-ForeignFunctions] Error 1

[Torrance, Douglas]

Control: tags -1 unreproducible
Control: severity -1 important

On Sat 20 Apr 2024 08:57:46 AM -04, Lucas Nussbaum  wrote:

--no-preload --stop --silent -e
"needsPackage(\"ForeignFunctions\",LoadDocumentation=>true,DebuggingMode=>true)"
-e "debug Core; argumentMode = defaultMode - SetUlimit" -e
"check(ForeignFunctions,UserMode=>false,Verbose=>true); exit 0"

 -- capturing check(0, "ForeignFunctions")-- SIGSEGV
-* stack trace, pid: 2593432
 0# stack_trace(std::ostream&, bool) at ./M2/Macaulay2/d/main.cpp:119
 1# segv_handler at ./M2/Macaulay2/d/main.cpp:235
 2# 0xF64686C0 in /lib/arm-linux-gnueabihf/libc.so.6
-- end stack trace *-
make[4]: *** [Makefile:50: check-ForeignFunctions] Error 1


I haven't been able to reproduce this build error after several attempts on 
armhf machines, so
I'm dropping the severity of this bug to "important".



signature.asc
Description: PGP signature

Bug#1070059: p11-kit FTBFS with gcc-14 due to -Wincompatible-pointer-types having become an error

[Helmut Grohne]

Control: tags -1 patch upstream fixed-upstream
Control: forwarded -1 
https://github.com/p11-glue/p11-kit/commit/d49c92c8420db6ee4c88515bdb014f68f4d471d9

On Mon, Apr 29, 2024 at 03:02:07PM +0200, Helmut Grohne wrote:
> This will become a hard failure once we swicth to gcc-14.

It's already fixed upstream!

Helmut

Bug#1070063: Remmina fails to connect with Windows systems: Protocol Security Negotiation Failure (older release works)

[Daniel Leidert]

Package: remmina
Version: 1.4.35+dfsg-1+b1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

when I try to connect to a windows (11) system, I get errors saying something
like "check security protocol negotiation". When I set it the security protocol
negotiation to automatic detection, there is a connection attempt, but the
credentials are not accepted. As I haven't changed anything in the RDP setup, I
tried downgrading to version 1.4.34, and everything works now as expected
again. I'm not quite sure if this issue is related to
https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/2062177 and/or
https://gitlab.com/Remmina/Remmina/-/issues/3090, or if this is a complete
different issue.

Regards, Daniel


- -- System Information:
Debian Release: trixie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages remmina depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4+b1
ii  libavahi-client3  0.8-13+b2
ii  libavahi-common3  0.8-13+b2
ii  libavahi-ui-gtk3-00.8-13+b2
ii  libayatana-appindicator3-10.5.93-1+b1
ii  libc6 2.37-19
ii  libcairo2 1.18.0-3+b1
ii  libcurl4t64 [libcurl4]8.7.1-4
ii  libgcrypt20   1.10.3-2+b1
ii  libglib2.0-0t64 [libglib2.0-0]2.78.4-7
ii  libgtk-3-0t64 [libgtk-3-0]3.24.41-4
ii  libjson-glib-1.0-01.8.0-2+b1
ii  libpango-1.0-01.52.1+ds-1
ii  libsodium23   1.0.18-1+b1
ii  libssh-4  0.10.6-2+b1
ii  libssl3t64 [libssl3]  3.2.1-3
ii  libvte-2.91-0 0.75.92-1
ii  remmina-common1.4.34+dfsg-1

Versions of packages remmina recommends:
ii  remmina-plugin-rdp 1.4.34+dfsg-1
ii  remmina-plugin-secret  1.4.34+dfsg-1
ii  remmina-plugin-vnc 1.4.34+dfsg-1

Versions of packages remmina suggests:
ii  remmina-plugin-exec 1.4.34+dfsg-1
pn  remmina-plugin-kwallet  
pn  remmina-plugin-python   
ii  remmina-plugin-spice1.4.34+dfsg-1
ii  remmina-plugin-www  1.4.34+dfsg-1
pn  remmina-plugin-x2go 

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmYvo20ACgkQS80FZ8KW
0F019w/+L5a7P2ISCuVfYN0TDIXNvW97noLHv0798jJ3cX2zX1DJ0CSyF5oLXLbt
ctVCobfZitMax1mUCpxgQYbEody6bZVRMdnb1SQEbiue+sx5iqsd+tYDmfwNThV9
FpLs203BuFg2CmjblhxpJ2AWlpCxQJUv39EVNtYFDnCHFW0hFbtdtIx48d6n7Byt
N4Ys0d5z9c+BeTpSMgT26DeVoxE0dIGaL2/tC1X4/mjlf23NMZyweKHS1YSo8/v7
Or6Z0tAFhdSF49320LNCqu6Y/jLwW9/gcJuzkRT6QBc6kBThOJvtSiLvREdlfytm
Ou421mvqU7nG3FKM0g987wgCZw/3ZmizsZESh4J1b2yrXc/Lr+T+XmEA8v3u5e+j
XMy7rJ7a5mWZt3iaikCxuq3RHQJM4eAhtfp1Obp5gyS06+65SB2vppWPHIjIcOfh
X6uqULCcSITwesyOWvd0w/iPmVrGaSjJCp6VrzWVXngKOdYWnyU+cV+yPVcP+GKE
T/iSDmssoeoFE1AjF8O+fSu/qP2E0VnsJ+cYpkU4LrcZ+RiLpNolTlws0Jgw1Q/n
4x3pDc01KH7aSdEqZU8DB4/CXgiPsvxEWqcTX3gTX33Q5LXXtOmZOsSnfD7X3OqG
9CQsUosvRuEQyaxFG4KGgiwnllJHcSvn1Moa1uaIGBqeJuxBgvI=
=2ZY6
-END PGP SIGNATURE-

Bug#1070062: waylandpp: Missing build-depends libwayland-egl1-mesa

[Scott Kitterman]

Source: waylandpp
Version: 1.0.0-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

The libwayland-egl1-mesa package was a transitional package for libegl1 and
libwayland-egl1 and has been removed.  You will need to update your
build-depends appropriately.

Scott K

Bug#1070039: Acknowledgement (refpolicy: enforcing mode causes machine with GNOME desktop to crash)

[Henrik Ahlgren]

It seems the immediate crash was caused by gnome-shell trying to do
execmem, I guess some JavaScript JIT thing. After enabling the
allow_execmem boolean, gnome-shell no longer crashes.

I am not sure how, but it would be good to have better out-of-the-box
experience with SELinux on desktop systems. At least it should not
straight up crash, if the user is unaware of this boolean. The mindset
sometimes seem to be that SELinux only provides benefits on headless
servers. I don't see the logic in that, in fact, the use case where
SELinux has most success is mobile devices (Android) and Fedora Desktop
ships SELinux by default without much issues.

Bug#1069991: Intel i5-1340P is Unknown

[Helge Kreutzmann]

tags 1069991 + pending
thanks

Hello xiao
Am Sun, Apr 28, 2024 at 05:05:16PM +0800 schrieb xiao sheng wen:
> I buy a new notebook, It's CPU is Intel i5-1340P.
> Would linuxinfo support it?

Sure, added in git.

Thanks for reporting.

Greetings

Helge

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


signature.asc
Description: PGP signature

Bug#1069549: racket: FTBFS on armel: dh_install: error: missing files, aborting

[David Bremner]

Control: severity -1 important

> Source: racket
> Version: 8.12+dfsg1-7
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel

OK, I figured out why this doesn't show up on the buildd's: they don't
build the arch all packages on armel. For many years, armel hasn't been
able to build the documentation for racket, and it has been disabled
there. After some informal consultation with the release team I'm
downgrading this bug to non-RC. I'll work on having more clear
diagnostics for the build failure.

I don't know how common this scenario is, but it might make sense to
restrict such rebuilds to arch:any on armel (and armhf), depending on
your goals of course.

Bug#1070061: RM: python-ospurge -- ROM; unmaintained upstream, RC buggy

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

This package needs to be removed from Debian.

Cheers,

Thomas Goirand (zigo)