Bug#1028912: Consider this fixed with 2.2.1-3

[axxel]

With the arrival of 2.2.1-3 in testing, can this be considered fixed
or will the issue need to stay open until that reaches the next
'release'?

 - Axel

Bug#1061765: Help needed to fix python-coverage-test-runner

[Andrius Merkys]

Hi Andreas,

On 2024-02-23 09:15, Andreas Tille wrote:

I've attempted to fix python-coverage-test-runner in Git since this
package is finally responsible for the failure of vmdb2:

  File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 22,
in 
 import imp
ModuleNotFoundError: No module named 'imp'


I had a similar problem. I worked it around by depending on 
python3-zombie-imp, the original code did not require any modifications.


Best,
Andrius

Bug#1061765: Help needed to fix python-coverage-test-runner

[Andreas Tille]

Control: tags -1 help

Hi,

I've attempted to fix python-coverage-test-runner in Git since this
package is finally responsible for the failure of vmdb2:

 File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 22, 
in 
import imp
ModuleNotFoundError: No module named 'imp'

In the patch in Git[1] I replaced imp by importlib (and distutils by
setuptools but this is not causing actual problems).  Unfortunately
when trying to run vmdb2 test against this patched package I get:

./check
Running unit tests 
Traceback (most recent call last):
  File "", line 198, in _run_module_as_main
  File "", line 88, in _run_code
  File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 313, in 

run()
  File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 304, in run
result = runner.run()
 
  File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 211, in run
importlib.reload(module)
  File "/usr/lib/python3.11/importlib/__init__.py", line 148, in reload
raise ImportError(msg.format(name), name=name)
ImportError: module plugin not in sys.modules


The fact that
   importlib.reload(module)

makes me wonder whether my patch for _load_module_from_pathname() is
correct (despite when I added some debug lines it looked sensible).  Any
help is welcome.

Kind regards
Andreas.

[1] 
https://salsa.debian.org/python-team/packages/python-coverage-test-runner/-/blob/master/debian/patches/Python3.12.patch?ref_type=heads

-- 
http://fam-tille.de

Bug#525813: apt-file: Doesn't work very well when multiple package versions are available

[Niels Thykier]

Christoph Anton Mitterer:

On Thu, 2024-02-22 at 08:59 +0100, Niels Thykier wrote:

One challenge we have here is that a package can have multiple
versions
in a given suite at the same time; notably in unstable.


And multiple arches...



Indeed. Though, `apt-file` has the information needed to filter here and 
if you ask for only things in one architecture, you only get those (plus 
maybe the implicit arch:all).





For people that want better support here, please request the archive
maintainers to provide an index with versioning so that apt-file can
do
proper filtering.


Against what would one file such request? ftp.debian.org?


Cheers,
Chris.



That would be my best guess indeed. They are the provided of the 
metadata, apt-file consumes. I do not think it would need to be a major 
change to the format. Adding the version next to the package name would 
be sufficient (like turn foo/section to foo_version/section).


Best regards,
Niels

Bug#1064203: Typer is already available on Debian

[Antonio Valentino]

Hi Sergio,

On Thu, 22 Feb 2024 18:46:42 -0300 Sergio Cipriano 
 wrote:
Source: typer 
Source-Version: 0.9.0-2

Done: Sergio de Almeida Cipriano Junior 

Typer 0.9.0 is already available on Debian and it is being maintained
in the python team.

--
Sérgio Cipriano.



Sorry, an oversight om my side.


cheers
--
Antonio Valentino

Bug#1064494: libreoffice-calc: forcing "Wrap text automatically" when moving cells

[HIGUCHI Daisuke (VDR dai)]

Package: libreoffice-calc
Version: 4:24.2.0-1
Severity: normal
Control: forwarded -1 https://bugs.documentfoundation.org/show_bug.cgi?id=159690

Sorry, resending to BTS, not to debian-openoffice.

Dear Maintainer,

   * What led up to the situation?

Updating libreoffice-calc (with relative packages) from 4:7.4.7-1+deb12u1
to 4:24.2.0-1.

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

Opening previously creating file, and moving cell with no-wrapping long text
with no "Wrap text automatically".  (not reproducible newly creating file in
libreoffice-calc 4:24.2.0-1)

   * What was the outcome of this action?

The text is wrapped and the corresponding row height is auto-adjested,
and forced "Wrap text automatically" setting.

   * What outcome did you expect instead?

"Wrap text automatically" setting should stay.

Other reported:

   * https://bugs.documentfoundation.org/show_bug.cgi?id=97106#c12
   * https://bugs.documentfoundation.org/show_bug.cgi?id=158252
   * https://bugs.documentfoundation.org/show_bug.cgi?id=159834

-- Package-specific info:
Configuration filePackage Exists Changed
/etc/libreoffice/registry/calc.xcdlibreoffice-calcYes No
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:
false

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++--=--===
un  libreoffice-gtk3   (no description available)
un  libreoffice-kf5(no description available)
un  libreoffice-qt5(no description available)

Java (javaldx):
/usr/lib/jvm/java-14-openjdk-amd64/lib/amd64/client:/usr/lib/jvm/java-14-openjdk-amd64/lib/amd64/server:/usr/lib/jvm/java-14-openjdk-amd64/lib/amd64/native_threads:/usr/lib/jvm/java-14-openjdk-amd64/lib/amd64

Java:
http://openoffice.org/2004/java/framework/1.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>

file:///usr/lib/jvm/java-14-openjdk-amd64



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

Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to ja_JP.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 libreoffice-calc depends on:
ii  coinor-libcoinmp1v51.8.3-3+b1
ii  libc6  2.37-15
ii  libetonyek-0.1-1   0.1.10-5
ii  libgcc-s1  14-20240201-3
ii  libicu72   72.1-4+b1
ii  libmwaw-0.3-3  0.3.22-1
ii  libodfgen-0.1-10.1.8-2
ii  liborcus-0.18-00.19.2-3+b1
ii  liborcus-parser-0.18-0 0.19.2-3+b1
ii  libreoffice-base-core  4:24.2.0-1
ii  libreoffice-common 4:24.2.0-1
ii  libreoffice-core   4:24.2.0-1
ii  libreoffice-uiconfig-calc  4:24.2.0-1
ii  librevenge-0.0-0   0.0.5-3
ii  libstaroffice-0.0-00.0.7-1
ii  libstdc++6 14-20240201-3
ii  libuno-cppu3   4:24.2.0-1
ii  libuno-cppuhelpergcc3-34:24.2.0-1
ii  libuno-sal34:24.2.0-1
ii  libuno-salhelpergcc3-3 4:24.2.0-1
ii  libwps-0.4-4   0.4.14-2
ii  libxml22.9.14+dfsg-1.3+b2
ii  lp-solve   5.5.2.5-2+b1
ii  ucf3.0043+nmu1
ii  uno-libs-private   4:24.2.0-1

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
ii  ocl-icd-libopencl1  2.3.2-1

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.15.0-1
ii  fonts-opensymbol4:102.12+LibO24.2.0-1
ii  libabsl20220623 20220623.1-3
ii  libargon2-1 0~20190702+dfsg-4+b1
ii  libboost-locale1.83.0   1.83.0-2+b2
ii  libc6   2.37-15
ii  libcairo2   1.18.0-1+b1
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1.1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1.1+b1
ii  libcmis-0.6-6   0.6.2-2+b1
ii  libcups22.4.7-1+b1
ii  libcurl48.6.0-3
ii  libdbus-1-3 1.14.10-4
ii  libdconf1   0.40.0-4+b1
ii  libeot0 0.01-5+b1
ii  libepoxy0

Bug#1064493: geeqie: Narrow sidebars are clipped on left edge with "Expand menu and toolbar" unchecked

[HIGUCHI Daisuke (VDR dai)]

Package: geeqie
Version: 1:2.2-1
Severity: normal
Control: forwarded -1 https://github.com/BestImageViewer/geeqie/issues/1237

Dear Maintainer,

   * What led up to the situation?

Updating geeqie from 1:2.1-2 to 1:2.2-1.

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

Start geeqie with "Expand menu and toolbar" unchecked.

   * What was the outcome of this action?

The sidebar starts to left-clip, while rendering the menus completely
inaccessible.

   * What outcome did you expect instead?

The sidebar should clip the right end.

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

Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to ja_JP.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 geeqie depends on:
ii  geeqie-common1:2.2-1
ii  libarchive13 3.7.2-1
ii  libc62.37-15
ii  libcairo21.18.0-1+b1
ii  libdjvulibre21   3.5.28-2+b1
ii  libexiv2-27  0.27.6-1+b1
ii  libffmpegthumbnailer4v5  2.2.2+git20220218+dfsg-2+b1
ii  libgcc-s114-20240201-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.4-1
ii  libgspell-1-21.12.2-1+b1
ii  libgtk-3-0   3.24.41-1
ii  libheif1 1.17.6-1
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libjxl0.70.7.0-10.2+b1
ii  liblcms2-2   2.14-2+b1
ii  liblua5.3-0  5.3.6-2+b1
ii  libopenjp2-7 2.5.0-2+b2
ii  libpango-1.0-0   1.51.0+ds-4
ii  libpangocairo-1.0-0  1.51.0+ds-4
ii  libpoppler-glib8 22.12.0-2+b1
ii  libraw23 0.21.2-2
ii  libstdc++6   14-20240201-3
ii  libtiff6 4.5.1+git230720-4
ii  libwebp7 1.3.2-0.4
ii  sensible-utils   0.0.22

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.4.7-1+b1
pn  exiftran 
pn  exiv2
ii  imagemagick  8:6.9.12.98+dfsg1-5+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.12.98+dfsg1-5+b1
ii  librsvg2-common  2.54.7+dfsg-2
ii  zenity   4.0.1-1

Versions of packages geeqie suggests:
ii  gimp 2.10.36-2+b1
ii  libjpeg-turbo-progs [libjpeg-progs]  1:2.1.5-2+b2
pn  xpaint   

-- no debconf information

-- 
Regards,
dai

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


signature.asc
Description: PGP signature

Bug#1064492: libdemeter-perl: Use of wxTB_3DBUTTONS crashes the Artemis GUI

[Carlo Segre]

Package: libdemeter-perl
Version: 0.9.27
Severity: grave
Tags: patch upstream
Justification: renders package unusable

when invoking the "dartemis" executable, it fails when trying to use
wxTB_3DBUTTONS from Wx::ToolBar.  This is in line 174 of the GDS.pm script.
Removal of wxTB_3DBUTTONS from line 174 allows dartemis to run correctly.

I think there is a more serious problem.  The most recent official release
is
0.9.26, not 0.9.27.  The fix suggested above reverts to the code in 0.9.26.
Perhaps, 0.9.26 should be the version used in the Debian package.

There is also an error in executing "dhephaestus".  It crashes with the
following error:

$ dhephaestus
Can't use an undefined value as an ARRAY reference at
/usr/share/perl5/Demeter/UI/Hephaestus/LineFinder.pm line 46.
Compilation failed in require at /usr/share/perl5/Demeter/UI/Hephaestus.pm
line
298.

As far as I can tell, there is no difference in either Hephaestus.pm or
LineFinder.pm in the two versions so the problem is more subtle.  In any
case,
version 0.9.26 runs without errors in trixie with the same version of libwx-
perl.

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

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

Versions of packages libdemeter-perl depends on:
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-2
ii  libchemistry-elements-perl  1.077-1
ii  libchemistry-formula-perl   3.0.1-1.3
ii  libconfig-ini-perl  1:0.029-1
ii  libconst-fast-perl  0.014-2
ii  libdatetime-perl2:1.59-1+b1
ii  libdigest-sha-perl  6.04-1+b1
ii  libencoding-fixlatin-perl   1.04-3
ii  libfile-copy-recursive-perl 0.45-4
ii  libfile-countlines-perl 0.0.3-4
ii  libfile-touch-perl  0.12-2
ii  libfile-which-perl  1.27-2
ii  libgraph-perl   1:0.9727-1
ii  libgraphics-gnuplotif-perl  1.8-2
ii  libheap-perl0.80-5
ii  libifeffit-perl 2:1.2.11d-12.5+b1
ii  libjson-perl4.1-1
ii  liblist-moreutils-perl  0.430-2
ii  libmath-combinatorics-perl  0.09-6
ii  libmath-derivative-perl 1.01-3
ii  libmath-random-free-perl0.2.0-2
ii  libmath-random-perl 0.72-2+b3
ii  libmath-round-perl  0.08-1
ii  libmath-spline-perl 0.02-4
ii  libmoose-perl   2.2207-1
ii  libmoosex-aliases-perl  0.11-2
ii  libmoosex-types-laxnum-perl 0.04-2
ii  libmoosex-types-perl0.50-2
ii  libpdl-stats-perl   0.83-1+b1
ii  libpod-pom-perl 2.01-4
ii  libregexp-assemble-perl 0.38-2
ii  libregexp-common-perl   2017060201-3
ii  librpc-xml-perl 0.82-1
ii  libspreadsheet-writeexcel-perl  2.40-4
ii  libstar-parser-perl 0.59-4
ii  libstatistics-descriptive-perl  3.0801-1
ii  libtext-template-perl   1.61-1
ii  libtext-unidecode-perl  1.30-3
ii  libtree-simple-perl 1.34-2
ii  libwant-perl0.29-2+b2
ii  libxmlrpc-lite-perl 0.717-5
ii  libxray-absorption-perl 3.0.1-4
ii  libxray-scattering-perl 3.0.1-3
ii  libyaml-tiny-perl   1.74-1
ii  pdl 1:2.085-1
ii  perl [libdigest-sha-perl]   5.38.2-3

libdemeter-perl recommends no packages.

libdemeter-perl suggests no packages.

-- no debconf information


-- 
Carlo U. Segre (he/him) -- Duchossois Leadership Professor of Physics
Professor of Materials Science & Engineering
Director, Center for Synchrotron Radiation Research and Instrumentation
Illinois Institute of Technology
Phone: 312.567.3498
se...@iit.edu   http://phys.iit.edu/~segre   se...@debian.org

Bug#1064447: debuerreotype: ineffective diversions (due to /usr-merge DEP17) for obsolete upstart files

[Tianon Gravi]

On Thu, 22 Feb 2024 at 08:53, Helmut Grohne  wrote:
> On Thu, Feb 22, 2024 at 08:26:16AM -0800, Tianon Gravi wrote:
> > It is precisely those older versions that the code still exists for --
> > I use debuerreotype for creating reproducible rootfs builds all the
> > way back to slink. 
> >
> > You can see in [1] that it only runs that diversion iff "upstart"
> > exists in the repos we're pointed at.
> >
> > [1]: 
> > https://github.com/debuerreotype/debuerreotype/blob/60b625d1ce31bd81525bb67fc3a33f9686bc3433/scripts/debuerreotype-minimizing-config#L40
>
> Right. Given that upstart no longer exists, it won't be /usr-moved and
> hence that diversion should continue to work, right? I'm inclined to
> agree that nothing needs to be done here. Does it make sense to add a
> source code comment about this? If not, please just close this bug.

It's one better: that divert code won't even run.  It will only run
against older versions where upstart *did* exist (which were never
usr-merged, and that divert is inside the old chroot), so yes, it will
continue to work correctly even in a usr-merged world (unless we get
some *new* package named "upstart", but I hope we don't run into that
and I will adjust that conditional to be more defensive if we do). 

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#1064437: filename on command line gets mangled

[Rob Browning]

Zefram  writes:

> If it cannot be made to handle arbitrary filenames correctly, then
> guile-3.0(1) must at least detect that it can't handle the specified
> filename.  It must signal an error on any filename it can't handle, and
> not use any mangled form of the filename for any purpose.  Furthermore,
> this limitation must be documented.

Hmm, if I don't misunderstand, this doesn't sound like a Debian-specific
issue.  So if you're comfortable with it, I'd recommend pursuing issues
like this upstream at either bug-gu...@gnu.org or guile-de...@gnu.org,
since that's where the changes would need to be made.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#1064491: gdb: symbol lookup error: gdb: undefined symbol: rl_eof_found

[Natalia Lewandowska]

Package: gdb
Version: 13.1-3
Severity: important
X-Debbugs-Cc: nlewandow...@posteo.net

Dear Maintainer,

When trying to launch gdb I receive the following error message:
  symbol lookup error: gdb: undefined symbol: rl_eof_found
and gdb never starts.


-- 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-18-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gdb depends on:
ii  libbabeltrace1  1.5.11-1+b2
ii  libc6   2.36-9+deb12u4
ii  libdebuginfod1  0.188-2.1
ii  libexpat1   2.5.0-1
ii  libgcc-s1   12.2.0-14
ii  libgmp102:6.2.1+dfsg1-1.1
ii  libipt2 2.0.5-1
ii  liblzma55.4.1-0.2
ii  libmpfr64.2.0-1
ii  libncursesw66.4-4
ii  libpython3.11   3.11.2-6
ii  libreadline88.2-1.3
ii  libsource-highlight4v5  3.1.9-4.2+b3
ii  libstdc++6  12.2.0-14
ii  libtinfo6   6.4-4
ii  libxxhash0  0.8.1-1
ii  libzstd11.5.4+dfsg2-5
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.36-9+deb12u4

Versions of packages gdb suggests:
ii  gdb-doc13.1-1
pn  gdbserver  

-- no debconf information

Bug#1064490: inputplug - upcoming rust-nix and rust-x11rb updates.

[Peter Green]

Package: inputplug
Version: 0.4.0-2

We are preparing an update of rust-nix to version 0.27 and rust-x11rb to 0.13,
the new versions are available in experimental.

The new version of rustix does not seem to require any code changes, but it
does require the "process" feature to be explicitly enabled.

The new version of x11rb changed HierarchyInfo.flags from a u32 to a
HierarchyMask. Heirachymask implements into, so I just added
a conversion.

A debdiff is attached, if I get no response I will probablly NMU this
when I upload the new nix and x11rb packages to unstable.
diff -Nru inputplug-0.4.0/debian/changelog inputplug-0.4.0/debian/changelog
--- inputplug-0.4.0/debian/changelog2021-07-22 10:08:15.0 +
+++ inputplug-0.4.0/debian/changelog2024-02-23 00:48:38.0 +
@@ -1,3 +1,13 @@
+inputplug (0.4.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Explicitly enable the "process" feature in nix dependency (needed for nix 
0.27)
+  * Use u32::from on info.flags, with x11rb 0.10 and lower, this is a no-op
+because flags is already a u32. With x11rb 0.13 this will convert the flags
+to a u32.
+
+ -- Peter Michael Green   Fri, 23 Feb 2024 00:48:38 +
+
 inputplug (0.4.0-2) unstable; urgency=medium
 
   * Fix the copyright file.
diff -Nru inputplug-0.4.0/debian/control inputplug-0.4.0/debian/control
--- inputplug-0.4.0/debian/control  2021-07-22 10:08:15.0 +
+++ inputplug-0.4.0/debian/control  2024-02-23 00:48:38.0 +
@@ -14,7 +14,7 @@
  librust-nix-0+default-dev (>= 0.19.0-~~),
  librust-pidfile-rs-0.1+default-dev,
  librust-structopt-0.3+default-dev,
- librust-x11rb-0.8+default-dev,
+ librust-x11rb+default-dev (>= 0.8),
  pkgconf | pkg-config
 Standards-Version: 4.5.1
 Homepage: https://github.com/andrewshadura/inputplug
diff -Nru inputplug-0.4.0/debian/patches/nix-features.patch 
inputplug-0.4.0/debian/patches/nix-features.patch
--- inputplug-0.4.0/debian/patches/nix-features.patch   1970-01-01 
00:00:00.0 +
+++ inputplug-0.4.0/debian/patches/nix-features.patch   2024-02-23 
00:48:38.0 +
@@ -0,0 +1,12 @@
+Index: inputplug-0.4.0/Cargo.toml
+===
+--- inputplug-0.4.0.orig/Cargo.toml
 inputplug-0.4.0/Cargo.toml
+@@ -23,6 +23,7 @@ version = "1.0"
+ 
+ [dependencies.nix]
+ version = ">= 0.19, <1.0"
++features = ["process"]
+ 
+ [dependencies.pidfile-rs]
+ version = "0.1"
diff -Nru inputplug-0.4.0/debian/patches/series 
inputplug-0.4.0/debian/patches/series
--- inputplug-0.4.0/debian/patches/series   1970-01-01 00:00:00.0 
+
+++ inputplug-0.4.0/debian/patches/series   2024-02-23 00:48:38.0 
+
@@ -0,0 +1,2 @@
+nix-features.patch
+x11rb-0.13.patch
diff -Nru inputplug-0.4.0/debian/patches/x11rb-0.13.patch 
inputplug-0.4.0/debian/patches/x11rb-0.13.patch
--- inputplug-0.4.0/debian/patches/x11rb-0.13.patch 1970-01-01 
00:00:00.0 +
+++ inputplug-0.4.0/debian/patches/x11rb-0.13.patch 2024-02-23 
00:48:38.0 +
@@ -0,0 +1,26 @@
+Index: inputplug-0.4.0/Cargo.toml
+===
+--- inputplug-0.4.0.orig/Cargo.toml
 inputplug-0.4.0/Cargo.toml
+@@ -33,7 +34,7 @@ version = "0.3"
+ default-features = false
+ 
+ [dependencies.x11rb]
+-version = "0.8"
++version = ">= 0.8"
+ features = ["xinput"]
+ 
+ [features]
+Index: inputplug-0.4.0/src/main.rs
+===
+--- inputplug-0.4.0.orig/src/main.rs
 inputplug-0.4.0/src/main.rs
+@@ -222,7 +222,7 @@ fn main() -> Result<()> {
+ continue;
+ }
+ for info in hier_event.infos {
+-let flags = IterableMask::from(info.flags)
++let flags = IterableMask::from(u32::from(info.flags))
+ .map(|x| HierarchyMask::from(x as u8))
+ .collect::>();
+ 

Bug#1052917: scala-mode-el: FTBFS: make[1]: *** [Makefile:55: clean] Error 2

[Xiyue Deng]

Control: tags -1 pending

I have prepared a fix on mentors[1].  The changes are also committed to
the team repo[2].  Looking for sponsorship :)

[1] https://mentors.debian.net/package/scala-mode-el/
[2] https://salsa.debian.org/emacsen-team/scala-mode-el

-- 
Xiyue Deng

Bug#879723: can get stuck in state INSANE and stop responding

[Pali Rohár]

On Saturday 16 December 2023 11:26:14 Pali Rohár wrote:
> On Friday 15 December 2023 21:53:08 Chris Hofstaedtler wrote:
> > On Wed, Oct 25, 2017 at 12:01:32AM -0400, Joey Hess wrote:
> > > If the netplug script fails to bring up the interface, netplug can
> > > put it into state INSANE. Unfortunately, it never leaves that state,
> > > preventing netplug from responding to further link changes.
> > [..]
> > 
> > A user on #Debian today reported something similar, on their
> > downstream distro vyos: https://vyos.dev/T5686
> > 
> > I'm leaving this here, just in case somebody has any use for this
> > info.
> 
> Thanks for reminder, I will look at it during next weeks.

I have looked at the whole netplugd state machine and transitions
between states. I identified more bugs than the one described in this
issue report. I have prepared fixes for all of them.

Joey, would you be interested in testing netplugd fixes?

Btw, I was trying to contact vyos people but they are not interested in
any discussion about netplugd, so I see no reason to link vyos issues.

Bug#1064489: python-packaging: please remove obsolete package python3-six from the build dependency

[Alexandre Detiste]

Source: python-packaging
Version: 23.2-1
Severity: normal

Hi,

This package does not use python3-six,
the old dependency can be dropped.

Greetings,

Alexandre

Bug#1064488: protobuf: please remove python3-six from the build dependencies

[Alexandre Detiste]

Source: protobuf
Version: 3.21.12-8
Severity: normal


python3-six is being slowly removed from Debian,
this package needed it before but not anymore.

So please remove python3-six from the build dependencies.

Greetings


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1064486: rnp: FTBFS: Errors while running CTest

[Bo YU]

Source: rnp
Version: 0.17.0-3
Severity: serious 

Dear Maintainer,

The package has a ftbfs issue on my local amd64 build:

```
260/260 Test #255: cli_tests-Encryption 
..   Passed   60.86 sec

98% tests passed, 6 tests failed out of 260

Total Test time (real) =  71.61 sec

The following tests FAILED:
 90 - rnp_tests.test_ffi_security_profile (Failed)
159 - rnp_tests.test_rnp_access (Failed)
166 - rnp_tests.rnpkeys_generatekey_verifykeyHomeDirNoPermission 
(Failed)
174 - rnp_tests.test_key_add_userid (Failed)
258 - cli_tests-EncryptElgamal (Failed)
259 - cli_tests-Misc (Failed)
Errors while running CTest
make[1]: *** [Makefile:94: test] Error 8
make[1]: Leaving directory '/<>/build'
dh_auto_test: error: cd build && make -j16 test ARGS\+=--verbose ARGS\+=-j16 
returned exit code 2
make: *** [debian/rules:33: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Build finished at 2024-02-22T22:48:30Z
```

It was failed on riscv64 also, but less test cases than amd64:

```
The following tests FAILED:
 90 - rnp_tests.test_ffi_security_profile (Failed)
174 - rnp_tests.test_key_add_userid (Failed)
251 - cli_tests-EncryptElgamal (Failed)
Errors while running CTest
make[1]: *** [Makefile:94: test] Error 8
```

The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=rnp=riscv64=0.17.0-3%2Bb2=1708576037=0


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1064485: RFS: samplebrain/0.18.5-1 [ITP] -- Custom sample smashing app designed by Aphex Twin

[tous]

Package: sponsorship-requests

Severity: wishlist

Dear mentors,

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

* Package name : samplebrain
   Version  : 0.18.5-1
   Upstream contact : Dave Griffiths 
 * URL  : http://thentrythis.org/projects/samplebrain
 * License  : CC0-1.0, GPL-2+
 * Vcs  : https://salsa.debian.org/touss-guest/samplebrain
   Section  : sound

The source builds the following binary packages:

  samplebrain - Custom sample smashing app designed by Aphex Twin

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/s/samplebrain/samplebrain_0.18.5-1.dsc


Changes for the initial release:

 samplebrain (0.18.5-1) unstable; urgency=medium
 .
   * Initial release. (Closes: 1040745)

Regards,
--
  tous

Bug#1064484: pytorch-cuda: FTBFS: error: cannot convert ‘dnnl::memory::data_type’ to ‘const ideep::dims&’

[Andreas Beckmann]

Source: pytorch-cuda
Version: 2.0.1+dfsg-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

while locally rebuilding all packages build-depending on
nvidia-cuda-toolkit, I noticed that pytorch-cuda started to FTBFS:

[621/2435] /usr/bin/cuda-g++ -DAT_PER_OPERATOR_HEADERS -DFMT_HEADER_ONLY=1 
-DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_MMAP=1 -DHAVE_SHM_OPEN=1 -DHAVE_SHM_UNLINK=1 
-DMINIZ_DISABLE_ZIP_READER_CRC32_CHECKS -DONNXIFI_ENABLE_EXT=1 -DONNX_ML=1 
-DONNX_NAMESPACE=onnx -DUSE_
C10D_GLOO -DUSE_DISTRIBUTED -DUSE_EXTERNAL_MZCRC -DUSE_FLASH_ATTENTION 
-DUSE_RPC -DUSE_TENSORPIPE -D_FILE_OFFSET_BITS=64 -Dtorch_cpu_EXPORTS 
-I/build/pytorch-cuda-2.0.1+dfsg/build/aten/src 
-I/build/pytorch-cuda-2.0.1+dfsg/aten/src -I/build/pytorch-cuda-2.0.1
+dfsg/build -I/build/pytorch-cuda-2.0.1+dfsg 
-I/build/pytorch-cuda-2.0.1+dfsg/cmake/../third_party/benchmark/include 
-I/build/pytorch-cuda-2.0.1+dfsg/debian/foxi 
-I/build/pytorch-cuda-2.0.1+dfsg/build/debian/foxi 
-I/build/pytorch-cuda-2.0.1+dfsg/torch/csrc/a
pi -I/build/pytorch-cuda-2.0.1+dfsg/torch/csrc/api/include 
-I/build/pytorch-cuda-2.0.1+dfsg/caffe2/aten/src/TH 
-I/build/pytorch-cuda-2.0.1+dfsg/build/caffe2/aten/src/TH 
-I/build/pytorch-cuda-2.0.1+dfsg/build/caffe2/aten/src 
-I/build/pytorch-cuda-2.0.1+dfsg/b
uild/caffe2/../aten/src -I/build/pytorch-cuda-2.0.1+dfsg/torch/csrc 
-I/build/pytorch-cuda-2.0.1+dfsg/third_party/miniz-2.1.0 
-I/build/pytorch-cuda-2.0.1+dfsg/debian/kineto/libkineto/include 
-I/build/pytorch-cuda-2.0.1+dfsg/debian/kineto/libkineto/src -I/buil
d/pytorch-cuda-2.0.1+dfsg/aten/../third_party/catch/single_include 
-I/build/pytorch-cuda-2.0.1+dfsg/aten/src/ATen/.. 
-I/build/pytorch-cuda-2.0.1+dfsg/c10/.. 
-I/build/pytorch-cuda-2.0.1+dfsg/aten/src/ATen/native/quantized/cpu/qnnpack/include
 -I/build/pytorch-
cuda-2.0.1+dfsg/aten/src/ATen/native/quantized/cpu/qnnpack/src 
-I/build/pytorch-cuda-2.0.1+dfsg/aten/src/ATen/native/quantized/cpu/qnnpack/deps/clog/include
 -I/build/pytorch-cuda-2.0.1+dfsg/third_party/flatbuffers/include -isystem 
/build/pytorch-cuda-2.0.1+d
fsg/build/third_party/gloo -isystem 
/build/pytorch-cuda-2.0.1+dfsg/cmake/../third_party/gloo -isystem 
/build/pytorch-cuda-2.0.1+dfsg/cmake/../third_party/googletest/googlemock/include
 -isystem /build/pytorch-cuda-2.0.1+dfsg/cmake/../third_party/googletest/go
ogletest/include -isystem /usr/include/opencv4 -isystem /usr/include/eigen3 
-isystem /build/pytorch-cuda-2.0.1+dfsg/caffe2 -Wdate-time -D_FORTIFY_SOURCE=2 
-g -O2 -ffile-prefix-map=/build/pytorch-cuda-2.0.1+dfsg=. 
-fstack-protector-strong -fstack-clash-protec
tion -Wformat -Werror=format-security -fcf-protection -gsplit-dwarf 
-Wno-dangling-reference -fuse-ld=lld -I/usr -D_GLIBCXX_USE_CXX11_ABI=1 
-Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -DUSE_KINETO 
-DLIBKINETO_NOCUPTI -DLIBKINETO_NOROCTRACER
-DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -O2 -fPIC 
-Wall -Wextra -Werror=return-type -Werror=non-virtual-dtor 
-Werror=range-loop-construct -Werror=bool-operation -Wnarrowing 
-Wno-missing-field-initializers -Wno-type-limits -Wno-a
rray-bounds -Wno-unknown-pragmas -Wunused-local-typedefs -Wno-unused-parameter 
-Wno-unused-function -Wno-unused-result -Wno-strict-overflow 
-Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow 
-Wno-psabi -Wno-error=pedantic -Wno-err
or=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always 
-faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized 
-fno-math-errno -fno-trapping-math -Werror=format -Werror=cast-function-type 
-Wno-stringop-overflow -DHAVE_AVX512_CPU_
DEFINITION -DHAVE_AVX2_CPU_DEFINITION -O2 -g -DNDEBUG -std=gnu++17 -fPIC 
-DCAFFE2_USE_GLOO -DTH_HAVE_THREAD -Wall -Wextra -Wno-unused-parameter 
-Wno-unused-function -Wno-unused-result -Wno-missing-field-initializers 
-Wno-write-strings -Wno-unknown-pragmas -W
no-type-limits -Wno-array-bounds -Wno-sign-compare -Wno-strict-overflow 
-Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-missing-braces 
-Wno-maybe-uninitialized -fvisibility=hidden -O2 -DCAFFE2_BUILD_MAIN_LIB 
-fopenmp -Wno-deprecated-declarations
 -MD -MT 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp.o
 -MF 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp.o.d
 -o caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/
quantized/cpu/qlinear_prepack.cpp.o -c 
/build/pytorch-cuda-2.0.1+dfsg/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp
FAILED: 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp.o
/usr/bin/cuda-g++ -DAT_PER_OPERATOR_HEADERS -DFMT_HEADER_ONLY=1 
-DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_MMAP=1 -DHAVE_SHM_OPEN=1 -DHAVE_SHM_UNLINK=1 
-DMINIZ_DISABLE_ZIP_READER_CRC32_CHECKS -DONNXIFI_ENABLE_EXT=1 -DONNX_ML=1 
-DONNX_NAMESPACE=onnx -DUSE_C10D_GLOO -
DUSE_DISTRIBUTED -DUSE_EXTERNAL_MZCRC -DUSE_FLASH_ATTENTION 

Bug#1064289: mirror submission for elmirror.cl

[Jonathan Gutierrez]

Hello Adam.



This should be fixed now. Sorry for the inconvenience.



Best,


Jonathan Gutiérrez








 El jue., 22 feb. 2024 15:30:39 -0300, Adam D. Barratt 
 escribió 



Control: tags -1 + moreinfo 
 
On Mon, 2024-02-19 at 18:57 +, https://elmirror.cl wrote: 
> Site: elmirror.cl 
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd- 
> amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x 
> Archive-http: /debian/ 
 
Our automated checks noticed an issue with your setup: 
 
o The trace file at 
 http://elmirror.cl/debian/project/trace/elmirror.cl 
 is missing some required information. 
 
 We expect at least the Maintainer and Upstream-mirror values to be filled in, 
 and your trace file is missing one or both of them. 
 
 
Please fix that and let us know once it's done. 
 
Regards, 
 
Adam

Bug#1064483: ITP: rust-self-encryption -- self-encrypting files

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-self-encryption
  Version : 0.29.1
  Upstream Contact: MaidSafe.net limited
* URL : https://github.com/maidsafe/self_encryption
* License : GPL-3
  Programming Lang: Rust
  Description : self-encrypting files

 self_encryption implements a version of convergent encryption
 with an additional obfuscation step.
 This pattern allows secured data that can also be de-duplicated.
 .
 Convergent encryption, also known as content hash keying,
 is a cryptosystem
 that produces identical ciphertext from identical plaintext files.

This package is needed by safenet (bug#1008016).
It will be maintained in the collaborative Debian section of Salsa, at
.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXX2mIACgkQLHwxRsGg
ASGebBAAlpdeliOH5hFVNQGgEFWTK93RaB+FmdJlp6y8ug8jEZncuxzYZfb7Nf7L
K/tccUfifB9lqz6tGQBhqKFRJ8iOtYk0IqxIdhZqjAagmQMSZYS0+lTw/NY4WCrl
M3hGcrpu4+dibj59FNxj3uoMBBfe7wLMn5pHzzcBL3BBUl9VLAGH82YcLTAeh0jW
heBjdy4Ro3IQ8Y1ZcnXgr7QINlRrm57JtG0LxzSnrIKeISLsDO/YqIaM6e7gUcSd
4giz/2Urv9N3fysMR+JXyxq651z4LICh+jnUmVWB2O+Fbh1v5X4JqwxOAnr0BZQF
W667aj1MzOpC8A7wqxDGz24zKcgE0fHAVKoVSP45AG/lkVSWD+ppIiyZXXrX6fwE
lWXwwXnN7SaFNXxZzM4/w+GREnvqa7loNZ+AKFSh+qBQVjvd1/1Q4Dkn5jezNbjz
ZK6hcL7YmR8eMKOo08OpWBk9e1JRU4TGsLIKFR6PepvZCES71X4Vm8mPshSDSeQ3
Uadv1gQtTW5akLDz8s+SDwZ5V82GYM4H4JDHonaSCyDNR85oxeNASUz9VMCBv3BW
uJXMXa7xzDk/T5y7lMIA7D/ioKwEsHL/prYB3Tdfv+RLi0C4Z9VA5I+ftA9adzo5
G0dfPHNkzdLSMBfV7s4GT6Z6dbmsim6Qm7s3VHhqZ5zPAsLb5nA=
=mQH1
-END PGP SIGNATURE-

Bug#1064482: libdemeter-perl: Missing dependence on libwx-perl

[Carlo Segre]

Package: libdemeter-perl
Severity: grave
Justification: renders package unusable

The dathena program will not start without the libwx-perl package.


--
Carlo Segre 


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

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

Versions of packages libdemeter-perl depends on:
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-2
ii  libchemistry-elements-perl  1.077-1
ii  libconfig-ini-perl  1:0.029-1
ii  libconst-fast-perl  0.014-2
ii  libdatetime-perl2:1.59-1+b1
ii  libdigest-sha-perl  6.04-1+b1
ii  libencoding-fixlatin-perl   1.04-3
ii  libfile-copy-recursive-perl 0.45-4
ii  libfile-countlines-perl 0.0.3-4
ii  libfile-touch-perl  0.12-2
ii  libfile-which-perl  1.27-2
ii  libgraph-perl   1:0.9727-1
ii  libheap-perl0.80-5
ii  libifeffit-perl 2:1.2.11d-12.5+b1
ii  libjson-perl4.1-1
ii  liblist-moreutils-perl  0.430-2
ii  libmath-combinatorics-perl  0.09-6
ii  libmath-derivative-perl 1.01-3
ii  libmath-random-perl 0.72-2+b3
ii  libmath-round-perl  0.08-1
ii  libmath-spline-perl 0.02-4
ii  libmoose-perl   2.2207-1
ii  libmoosex-aliases-perl  0.11-2
ii  libmoosex-types-laxnum-perl 0.04-2
ii  libmoosex-types-perl0.50-2
ii  libpdl-stats-perl   0.83-1+b1
ii  libpod-pom-perl 2.01-4
ii  libregexp-assemble-perl 0.38-2
ii  libregexp-common-perl   2017060201-3
ii  librpc-xml-perl 0.82-1
ii  libspreadsheet-writeexcel-perl  2.40-4
pn  libstar-parser-perl 
ii  libstatistics-descriptive-perl  3.0801-1
ii  libtext-template-perl   1.61-1
ii  libtext-unidecode-perl  1.30-3
ii  libtree-simple-perl 1.34-2
ii  libwant-perl0.29-2+b2
ii  libxmlrpc-lite-perl 0.717-5
ii  libxray-absorption-perl 3.0.1-4
ii  libxray-scattering-perl 3.0.1-3
ii  libyaml-tiny-perl   1.74-1
ii  pdl 1:2.085-1
ii  perl [libdigest-sha-perl]   5.38.2-3

libdemeter-perl recommends no packages.

libdemeter-perl suggests no packages.

-- 
Carlo U. Segre (he/him) -- Duchossois Leadership Professor of Physics
Professor of Materials Science & Engineering
Director, Center for Synchrotron Radiation Research and Instrumentation
Illinois Institute of Technology
Phone: 312.567.3498
se...@iit.edu   http://phys.iit.edu/~segre   se...@debian.org

Bug#1064481: ITP: golang-github-liggitt-tabwriter -- Drop in replacement for https://golang.org/pkg/text/tabwriter with additional features

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: golang-github-liggitt-tabwriter
  Version : 0.0~git20181228.89fcab3-1
  Upstream Author : Jordan Liggitt
* URL : https://github.com/liggitt/tabwriter
* License : BSD-3-clause
  Programming Lang: Go
  Description : Drop in replacement for the golang text/tabwriter with some 
additional features

 This library is a drop-in replacement for the golang text/tabwriter
 .
 The following additional features are supported:
 - The RememberWidths flag allows remembering maximum widths seen per column
   even after Flush() is called.
 - RememberedWidths() []int and SetRememberedWidths([]int) *Writer allow
   obtaining and transferring remembered column width between writers.

Bug#1064480: aardvark-dns - upcoming rust-nix update.

[Peter Green]

Package: greetd
Version: 0.9.0-6

We are preparing an update of rust-nix to version 0.27, the new version has
been uploaded to experlmental.

To build with this new version of nix, aardvark-dns needs a small patch
taken from upstream. A debdiff is attached, if I get no response I will
likely NMU this once the new version of rust-nix is in unstable.diff -Nru greetd-0.9.0/debian/changelog greetd-0.9.0/debian/changelog
--- greetd-0.9.0/debian/changelog   2023-12-21 14:17:58.0 +
+++ greetd-0.9.0/debian/changelog   2024-02-22 22:50:17.0 +
@@ -1,3 +1,11 @@
+greetd (0.9.0-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch for nix 0.27
+  * Tighten build-dependency on nix.
+
+ -- Peter Michael Green   Thu, 22 Feb 2024 22:50:17 +
+
 greetd (0.9.0-6) unstable; urgency=medium
 
   * Relax dependency on rpassword (Closes: #1057931).
diff -Nru greetd-0.9.0/debian/control greetd-0.9.0/debian/control
--- greetd-0.9.0/debian/control 2023-12-21 14:17:58.0 +
+++ greetd-0.9.0/debian/control 2024-02-22 22:50:17.0 +
@@ -6,7 +6,7 @@
  debhelper-compat (= 13),
  dh-cargo,
 # greetd & greetd_ipc
- librust-nix-dev (>= 0.25),
+ librust-nix-0.27-dev,
  librust-pam-sys-dev (>= 0.5.6),
  librust-users-dev (>= 0.11.0),
  librust-serde-derive-dev (>= 1.0),
diff -Nru greetd-0.9.0/debian/patches/nix-0.27.patch 
greetd-0.9.0/debian/patches/nix-0.27.patch
--- greetd-0.9.0/debian/patches/nix-0.27.patch  1970-01-01 00:00:00.0 
+
+++ greetd-0.9.0/debian/patches/nix-0.27.patch  2024-02-22 22:46:40.0 
+
@@ -0,0 +1,43 @@
+This patch is based on the upstream commit described below, adapted for use
+in the Debian package by Peter Michael Green.
+
+commit 161218164d366482ab7fab9dcc59cbd40623ac2c
+Author: Kenny Levinsen 
+Date:   Wed Feb 7 15:14:24 2024 +0100
+
+Update dependencies
+
+diff --git a/greetd/Cargo.toml b/greetd/Cargo.toml
+index c206ac1..3b1446f 100644
+--- a/greetd/Cargo.toml
 b/greetd/Cargo.toml
+@@ -14,1 +14,1 @@ repository = "https://git.sr.ht/~kennylevinsen/greetd/;
+-nix = "0.26"
++nix = { version = "0.27", features = ["ioctl", "signal", "user", "fs", 
"mman"] }
+diff --git a/greetd/src/main.rs b/greetd/src/main.rs
+index b88c6dc..92a53d4 100644
+--- a/greetd/src/main.rs
 b/greetd/src/main.rs
+@@ -22,7 +22,7 @@ use crate::{error::Error, session::worker};
+ 
+ async fn session_worker_main(config: config::Config) -> Result<(), Error> {
+ let raw_fd = config.internal.session_worker as RawFd;
+-let mut cur_flags = unsafe { FdFlag::from_bits_unchecked(fcntl(raw_fd, 
FcntlArg::F_GETFD)?) };
++let mut cur_flags = FdFlag::from_bits_retain(fcntl(raw_fd, 
FcntlArg::F_GETFD)?);
+ cur_flags.insert(FdFlag::FD_CLOEXEC);
+ fcntl(raw_fd, FcntlArg::F_SETFD(cur_flags))?;
+ let sock = unsafe { UnixDatagram::from_raw_fd(raw_fd) };
+diff --git a/greetd/src/session/interface.rs b/greetd/src/session/interface.rs
+index f1d3f04..b31f47f 100644
+--- a/greetd/src/session/interface.rs
 b/greetd/src/session/interface.rs
+@@ -99,8 +99,7 @@ impl Session {
+ UnixDatagram::pair().map_err(|e| format!("could not create pipe: 
{}", e))?;
+ 
+ let raw_child = childfd.as_raw_fd();
+-let mut cur_flags =
+-unsafe { FdFlag::from_bits_unchecked(fcntl(raw_child, 
FcntlArg::F_GETFD)?) };
++let mut cur_flags = FdFlag::from_bits_retain(fcntl(raw_child, 
FcntlArg::F_GETFD)?);
+ cur_flags.remove(FdFlag::FD_CLOEXEC);
+ fcntl(raw_child, FcntlArg::F_SETFD(cur_flags))?;
+ 
diff -Nru greetd-0.9.0/debian/patches/relax_deps.patch 
greetd-0.9.0/debian/patches/relax_deps.patch
--- greetd-0.9.0/debian/patches/relax_deps.patch2023-12-21 
14:17:58.0 +
+++ greetd-0.9.0/debian/patches/relax_deps.patch2024-02-22 
22:48:38.0 +
@@ -15,15 +15,4 @@
  getopts = "0.2"
  enquote = "1.1"
 -nix = "0.26"
-+nix = ">=0.26"
 a/greetd/Cargo.toml
-+++ b/greetd/Cargo.toml
-@@ -11,7 +11,7 @@
- debug = []
- 
- [dependencies]
--nix = "0.26"
-+nix = ">=0.26"
- pam-sys = "0.5.6"
- users = "0.11.0"
- serde = { version = "1.0", features = ["derive"] }
++nix = ">= 0.26"
diff -Nru greetd-0.9.0/debian/patches/series greetd-0.9.0/debian/patches/series
--- greetd-0.9.0/debian/patches/series  2023-12-21 14:17:58.0 +
+++ greetd-0.9.0/debian/patches/series  2024-02-22 22:46:06.0 +
@@ -2,3 +2,4 @@
 config_tweaks.patch
 relax_deps.patch
 rpassword_6.0_adaptation.patch
+nix-0.27.patch

Bug#525813: apt-file: Doesn't work very well when multiple package versions are available

[Christoph Anton Mitterer]

On Thu, 2024-02-22 at 08:59 +0100, Niels Thykier wrote:
> One challenge we have here is that a package can have multiple
> versions 
> in a given suite at the same time; notably in unstable.

And multiple arches...


> For people that want better support here, please request the archive 
> maintainers to provide an index with versioning so that apt-file can
> do 
> proper filtering.

Against what would one file such request? ftp.debian.org?


Cheers,
Chris.

Bug#1064479: aardvark-dns - upcoming rust-nix update.

[Peter Green]

Package: aardvark-dns
Version: 1.4.0-5

We are preparing an update of rust-nix to version 0.27, the new version has
been uploaded to experlmental.

To build with this new version of nix, aardvark-dns needs the cargo dependency
on nix relaxing, and needs some features of the nix crate specifying explicitly.
A debdiff is attatched, if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.diff -Nru aardvark-dns-1.4.0/debian/changelog 
aardvark-dns-1.4.0/debian/changelog
--- aardvark-dns-1.4.0/debian/changelog 2023-09-07 00:45:48.0 +
+++ aardvark-dns-1.4.0/debian/changelog 2024-02-22 22:11:17.0 +
@@ -1,3 +1,11 @@
+aardvark-dns (1.4.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax cargo dependency on nix to support 0.27 and explicitly enable
+required features, since nix no longer enables any features by default.
+
+ -- Peter Michael Green   Thu, 22 Feb 2024 22:11:17 +
+
 aardvark-dns (1.4.0-5) unstable; urgency=medium
 
   * Build against clap version 4, Closes: #1040876, #1040877
diff -Nru aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 
aardvark-dns-1.4.0/debian/patches/update-dependencies.patch
--- aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 2023-09-07 
00:45:48.0 +
+++ aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 2024-02-22 
22:10:55.0 +
@@ -25,7 +25,7 @@
 +async-broadcast = ">= 0.4.1"
  resolv-conf = "0.7.0"
 -nix = "0.25.0"
-+nix = "0.26"
++nix = { version = ">= 0.25.0", features = ["fs", "signal"] }
  libc = "0.2"
  
  [build-dependencies]

Bug#1064454: debian-policy: Restrict deb822 field names more

[gregor herrmann]

On Thu, 22 Feb 2024 14:08:38 +0100, Simon Josefsson wrote:

> Would it make sense to change this to use an inclusive list of permitted
> characters instead?  How about checking the field names that is in use
> today, and construct a regexp of permitted symbols out of that?
> Starting point: [A-Za-z][A-Za-z0-9-_]*

Right, also: defining this as a regexp would be helpful for
implementation in all parsers (and I suspect there are many of them
…).


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1064465: chromium: Chromium cannot use webgl without X (should be compiled with swiftshader)

[Charles Samuels]

On Thursday, February 22, 2024 9:52:03 A.M. PST Andres Salomon wrote:
> Swiftshader is manually disabled in Debian's chromium package. It's one 
> of those legacy patches that I've long meant to look at (and remove if 
> conditions allow it), but I haven't gotten to yet: 
> https://salsa.debian.org/chromium-team/chromium/-/commit/84db0501b0d6cb055fe
> 9f22057cd129fdefac710
 
> It wasn't documented *why* swiftshader was disabled. Maybe related to 
> non-DFSG third party libs (see https://bugs.debian.org/909156)? In order 
> to reenable it, I need to poke around and see if I can figure out why it 
> was disabled in the first place.

I looked at all of swiftshader's dependencies' licenses:

SPIRV: Apache
astc-encoder: Apache
benchmark: Apache
boost: Boost license (already part of Debian)
cppdap: Apache
glslang: 3-BSD, 2-BSD, MIT, Apache, GPL3, an NVIDIA license, which seems to be 
similar to the MIT/BSD licenses, Khronos License, already part of debian. 
glslang is already part of Debian
json: MIT
libbacktrace: BSD
llvm: llvm is already part of Debian
llvm-subzero: same license as LLVM
marl: Apache

Let me know if there is any way I can help!

c

Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

[Tobias Frost]

Control: tags -1 moreinfo

Hi Joachim,

review based on the dsc containing:
Checksums-Sha256:
 75aa7ed495b21d360340c84a4def6e16e25ecc36dab91e2481631993b2624bde 5128639 
vzlogger_0.8.3.orig.tar.gz
 c6737877696173e8daa4c9e4d4a1b6663ae5256f669c87554360e665f154e292 6252 
vzlogger_0.8.3-1.debian.tar.xz

It is only a partial review, especially I did not do a d/copyright
review yet.

Please check my remarks and remove the moreinfo tag when ready.

On Tue, Feb 20, 2024 at 12:34:04PM +0100, Joachim Zobel wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "vzlogger":
> 
>  * Package name : vzlogger
>  Version : 3.1-4
>  Upstream contact : Joachim Zobel 
>  * URL : http://wiki.volkszaehler.org/software/controller/vzlogger
>  * License : GPL-3
>  * Vcs : https://github.com/volkszaehler/vzlogger
>  Section : net 
> 
> The source builds the following binary packages:
> 
>  vzlogger - program to read measurements from smart meters and log them
> to Influxdb or forward them via MQTT.
> 
> vzlogger is a tool to read and log measurements of a wide variety of
> smart meters and sensors. It supports various commonly used protocols
> such as s0, d0, sml, oms and others. It can write these data to an
> Influxdb, forward them via MQTT, make them available via HTTP or eport
> them to a volkszaehler.org middleware.
> 
> The package is maintained in the upstream repository. Upstream (which I
> am part of) currently builds native packages. These are patched (a
> switch from native to quilt, a different changelog and a version >= 3.0
> for the dependency on openssl) to make them more suitable for debian.
> The package is therefore availabe in the upstream repo 

Yeah, format 3.0 quilt is the way, it is not a native package.

> https://github.com/volkszaehler/vzlogger.git 
> 
> on branch debian-0.8.3-1.

(There is no such branch on that repo, but a "debian" one.)

Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for 
recommendation how to layout the repository used for packaging, I'd
even recommend to use an extra repository for the packaging.

> Alternatively, you can download thepackage with 'dget' using this
> command:
> 
>  dget -x 
> http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.3-1.dsc
> 
> Regards,
> -- 
>  Joachim Zobel

As you are upstream:
https://wiki.debian.org/UpstreamGuide

d/source/lintian-overrides
 - delete the overrides, seems to be some remnant of earlier packaging.

d/DEBIAN_RELEASE.txt
 - delete this file; the information contained in this files would not
   be a process how to create a package for Debian. (and if you need a
   file describing certain unusal aspects of the Debian packaging, it
   would be README.source (see Debian Policy §4.14)
   I recommend checking out git-buildpackage:
   https://honk.sigxcpu.org/piki/projects/git-buildpackage/ 
   https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/
   - remove Debian_release.patch -- this is not needed, you work with
   your debian/ directory and evolve it, you do not patch it when you
   create a new version. 

d/control
 - specify Rules-Require-Root
 - you manually depend on libsml1. Can you expand why this is needed?
 - Build-Depend: s/pkg-config/pkgconf
 - remove versions from the versioned build dependencies, if the
   debpendency is already fulfilled in oldstable:
   - libjson-c-dev, libcurl4-openssl-dev, 


d/postinst / postrm
 - When you create a user, it should start with "_" - see policy 9.2.1
   - Another option might be using systemd's DynamicUser feature to 
 create the user at runtime. (bonus: some hardening for free.)
   - there's systemd-sysuser (works also without systemd as init system)
 to use sysusers.d 
   - do not delete users/groups on package removal. 

As you are involved with upstream:
The manpage, initfile, systemd service file should probably be included in the
upstream part, it is not only useful for Debian alone.

Linitian emits:
W: vzlogger source: build-depends-on-obsolete-package Build-Depends: pkg-config 
(>= 0.25) => pkgconf
W: vzlogger: groff-message troff::5: warning: cannot select 
font 'CB' [usr/share/man/man8/vzlogger.8.gz:1]
I: vzlogger source: debian-rules-parses-dpkg-parsechangelog [debian/rules:12]
I: vzlogger: file-references-package-build-path [usr/bin/vzlogger]
I: vzlogger: file-references-package-build-path [usr/lib/static/libvz.a]
I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger]
I: vzlogger: hardening-no-fortify-functions [usr/bin/vzlogger]
I: vzlogger: systemd-service-file-missing-documentation-key 
[usr/lib/systemd/system/vzlogger.service]
I: vzlogger source: unused-override odd-historical-debian-changelog-version 
*0.3.4-rc1* [debian/source/lintian-overrides:2]
P: vzlogger source: capitalization-in-override-comment 
odd-historical-debian-changelog-version debian Debian 
[debian/source/lintian-overrides:1]
P: vzlogger source: silent-on-rules-requiring-root 

Bug#1064478: wireless-regdb: install firmware files into /usr

[Michael Biebl]

Source: wireless-regdb
Version: 2022.06.06-1
Severity: normal
Tags: patch trixie sid
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. wireless-regdb installs files into /lib; these should be moved
into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

This should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru wireless-regdb-2022.06.06/debian/changelog 
wireless-regdb-2022.06.06/debian/changelog
--- wireless-regdb-2022.06.06/debian/changelog  2022-07-30 22:10:23.0 
+0200
+++ wireless-regdb-2022.06.06/debian/changelog  2024-02-22 22:52:06.0 
+0100
@@ -1,3 +1,10 @@
+wireless-regdb (2022.06.06-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install firmware files into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Thu, 22 Feb 2024 22:52:06 +0100
+
 wireless-regdb (2022.06.06-1) unstable; urgency=medium
 
   * New upstream version:
diff -Nru wireless-regdb-2022.06.06/debian/rules 
wireless-regdb-2022.06.06/debian/rules
--- wireless-regdb-2022.06.06/debian/rules  2022-07-12 20:40:10.0 
+0200
+++ wireless-regdb-2022.06.06/debian/rules  2024-02-22 22:52:06.0 
+0100
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
-export CRDA_PATH = /lib/crda
+export CRDA_PATH = /usr/lib/crda
+export FIRMWARE_PATH = /usr/lib/firmware
 export REGDB_AUTHOR  = $(shell dpkg-parsechangelog -SMaintainer | sed 
's:.*<\(.*\)>:\1:')
 export V = 1
 # prevent the build system from calling lsb_release
@@ -41,11 +42,11 @@
 install-wireless-regdb:
$(MAKE) -C debian/build DESTDIR=$(CURDIR)/$(DIR) install
for file in regulatory.db regulatory.db.p7s; do \
-   install -m644 $$file $(DIR)/lib/firmware/$$file-upstream \
-   && mv $(DIR)/lib/firmware/$$file 
$(DIR)/lib/firmware/$$file-debian \
+   install -m644 $$file $(DIR)/usr/lib/firmware/$$file-upstream \
+   && mv $(DIR)/usr/lib/firmware/$$file 
$(DIR)/usr/lib/firmware/$$file-debian \
|| exit; \
done
-   rm -r $(DIR)/lib/crda
+   rm -r $(DIR)/usr/lib/crda
 # regulatory.db.5 just includes regulatory.bin.5, so we need to
 # install the latter as regulatory.db.5
mv $(DIR)/usr/share/man/man5/regulatory.bin.5.gz \
@@ -54,7 +55,7 @@
 install-wireless-regdb-udeb: DIR = debian/wireless-regdb-udeb
 install-wireless-regdb-udeb:
$(MAKE) -C debian/build DESTDIR=$(CURDIR)/$(DIR) install
-   rm -r $(DIR)/lib/crda $(DIR)/usr/share/man
+   rm -r $(DIR)/usr/lib/crda $(DIR)/usr/share/man
rmdir --ignore-fail-on-non-empty -p $(DIR)/usr/share
 
 override_dh_auto_clean:

Bug#1064394: release-notes: English language output for the commands into script session

[Franco Martelli]

On 21/02/24 at 23:49, Justin B Rye wrote:


Sorry I missed the sense, what explanation?


If we said "LC_ALL=C.UTF-8 LANGUAGE= script -T ..." it would have all
sorts of disadvantages, including the fact that we'd have to explain
all of it together.  Much easier to explain about script, then suggest
a "script -T..." commandline, *then* deal with locales separately.


Yes, users have to choice if they want to change localization inside the 
"script" session.



The question is, will users realise that they're putting the files in
*root's* home directory, and will they even know where that is?


A minimal assumption of knowledge base of the FHS ¹  and tilde-expansion 
should be take by Release Notes writers. I think we shouldn't worry 
about this.



If we really can't suggest using /var/tmp for this, that seems a pity;
that location *shouldn't* be wiped on reboot, and it's usable whether
you're running "sudo; screen" or "sudo screen" or "screen; sudo".


It's more popular to use a non-privileged home directory. Few people 
strictly adhere to the FHS ¹  specifications. This is why I am in favor 
of using tilde-expansion. No matters if the reader becomes root or runs 
"script" as non-privileged user: the files will always go in the home 
directory, where they will be used by "scriptreplay" command. By doing 
so we won't have to take care of where the files reside.



¹ https://refspecs.linuxfoundation.org/fhs.shtml
--
Franco Martelli

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

[Amin Bandali]

Hi Miguel,

On Thu, Feb 22, 2024 at 09:23:20PM +, Miguel Landaeta wrote:
> On Thu, Feb 22, 2024 at 02:19:21AM +, Amin Bandali wrote:
> > Hi Miguel,
> > 
> > I'm interested in helping with this.  Do you have the current state 
> > of your work available on Salsa or elsewhere that I could pull in
> > and work on?  Otherwise I'll just start with a repo under my own
> > account and we could later transfer it to the 'debian' group or
> > elsewhere.
> 
> Hi Amin, thanks for reaching out.
> 
> I'll push my repo tomorrow or during the weekend to salsa and
> update this thread with the link.
> 
> I started to work on this package a few weeks ago but I decided to
> wait for qbe 1.2 before uploading a package and I just noticed
> it finally happened this week so I was planning to resume my work
> on it.
> 
> I don't have time to work on it this weekend but I'll publish it
> in a few hours to unblock you and other folks interested in
> collaborating.

Sounds great, thanks in advance!

FWIW I was browsing Hare's website again earlier, and saw this bit
on https://harelang.org/installation:

  Step 0: Pre-requisites

[...]
QBE (the latest version on the git master branch, not the latest versioned 
release)

Though I think/hope that that's a remnant from earlier times before
Hare's first versioned release.  Hare's new release policy at
https://git.sr.ht/~sircmpwn/hare/tree/master/item/docs/release.md
is more reassuring:

  The Hare toolchain's chief dependency is qbe. Each Hare version
  is pinned to a specific qbe release, which is documented in the
  release notes corresponding to that Hare version.

So I'm hopeful that at this point and onwards, Hare would depend
on tagged release versions of qbe rather than git trunk commits.

> If you want, I can add you as co-maintainer.
> 
> Cheers,
> Miguel.

Sure, that would be great - many thanks. :-)

Best,
-amin

Bug#1064477: lzo2: install shared library into /usr

[Michael Biebl]

Source: lzo2
Version: 2.10-2
Severity: normal
Tags: patch trixie sid
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. lzo2 installs files into /lib; these should be moved into the
respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

This should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru lzo2-2.10/debian/changelog lzo2-2.10/debian/changelog
--- lzo2-2.10/debian/changelog  2020-01-22 21:35:19.0 +0100
+++ lzo2-2.10/debian/changelog  2024-02-22 22:44:26.0 +0100
@@ -1,3 +1,10 @@
+lzo2 (2.10-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install shared library into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Thu, 22 Feb 2024 22:44:26 +0100
+
 lzo2 (2.10-2) unstable; urgency=medium
 
   * Add missing pkg-config build-dependency.
diff -Nru lzo2-2.10/debian/liblzo2-2.install lzo2-2.10/debian/liblzo2-2.install
--- lzo2-2.10/debian/liblzo2-2.install  2020-01-20 11:42:23.0 +0100
+++ lzo2-2.10/debian/liblzo2-2.install  2024-02-22 22:44:18.0 +0100
@@ -1 +1 @@
-lib/*/*.so.*
+usr/lib/*/*.so.*
diff -Nru lzo2-2.10/debian/liblzo2-2-udeb.install 
lzo2-2.10/debian/liblzo2-2-udeb.install
--- lzo2-2.10/debian/liblzo2-2-udeb.install 2020-01-20 11:42:23.0 
+0100
+++ lzo2-2.10/debian/liblzo2-2-udeb.install 2024-02-22 22:44:21.0 
+0100
@@ -1 +1 @@
-lib/*/*.so.*
+usr/lib/*/*.so.*
diff -Nru lzo2-2.10/debian/rules lzo2-2.10/debian/rules
--- lzo2-2.10/debian/rules  2020-01-22 19:13:05.0 +0100
+++ lzo2-2.10/debian/rules  2024-02-22 22:44:10.0 +0100
@@ -18,9 +18,6 @@
 
 override_dh_auto_install:
dh_auto_install
-   mkdir -p $(DEB_DESTDIR)/lib/$(DEB_HOST_MULTIARCH)
-   mv $(DEB_DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)/*.so.* 
$(DEB_DESTDIR)/lib/$(DEB_HOST_MULTIARCH)
-   ln -sf /lib/$(DEB_HOST_MULTIARCH)/$$(basename $$(readlink 
$(DEB_DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)/*.so)) 
$(DEB_DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)/*.so
mkdir -p $(DEB_DESTDIR)/usr/share/lzo/minilzo
install -D -m 644 minilzo/README.LZO minilzo/minilzo.c 
minilzo/minilzo.h include/lzo/lzoconf.h include/lzo/lzodefs.h 
$(CURDIR)/debian/tmp/usr/share/lzo/minilzo
 

Bug#1064476: dpkg-buildflags: add support for building with frame pointers enabled

[Matthias Klose]

Package: dpkg-dev
Version: 1.22.1
Severity: wishlist
Tags: patch

Please add support to enable to build with frame-pointer turned on. The 
compilers in unstable default to -fomit-framepointer, this turns on 
-fno-omit-framepointer plus an architecture specific option.


To enable it, use

   DEB_BUILD_MAINT_OPTIONS="... qa=+framepointer"

The chosen area might not be ideal, it could also be added to the 
optimize area, however it is a "negative" optimization.


Currently the default is not changed in Debian.diff -Nru dpkg-1.22.1ubuntu3/debian/changelog dpkg-1.22.1ubuntu4/debian/changelog
--- dpkg-1.22.1ubuntu3/debian/changelog	2023-11-23 10:55:44.0 +0100
+++ dpkg-1.22.1ubuntu4/debian/changelog	2023-12-13 09:35:27.0 +0100
@@ -1,3 +1,15 @@
+dpkg (1.22.1ubuntu4) UNRELEASED; urgency=medium
+
+  * dpkg-buildflags: Add a new feature "framepointer" in the "qa" area.
+  * Turn on the use of frame pointers by default on 64bit architectures.
+- Add -fno-omit-frame-pointer.
+- On amd64 and arm64 also add -mno-omit-leaf-frame-pointer.
+- On s390x, also add -mbackchain.
+  * To build without frame pointers, set before setting up buildflags:
+DEB_BUILD_MAINT_OPTIONS="... qa=-framepointer ...".
+
+ -- Matthias Klose   Wed, 13 Dec 2023 09:35:27 +0100
+
 dpkg (1.22.1ubuntu3) noble; urgency=medium
 
   * Disable -fstack-clash-protection on armhf since it causes crashes
diff -Nru dpkg-1.22.1ubuntu3/scripts/Dpkg/Vendor/Debian.pm dpkg-1.22.1ubuntu4/scripts/Dpkg/Vendor/Debian.pm
--- dpkg-1.22.1ubuntu3/scripts/Dpkg/Vendor/Debian.pm	2023-11-23 10:55:44.0 +0100
+++ dpkg-1.22.1ubuntu4/scripts/Dpkg/Vendor/Debian.pm	2023-12-13 09:35:27.0 +0100
@@ -118,6 +118,7 @@
 qa => {
 bug => 0,
 canary => 0,
+framepointer => 0,
 },
 reproducible => {
 timeless => 1,
@@ -463,6 +464,20 @@
 $flags->append('LDFLAGS', "-Wl,-z,deb-canary-${id}");
 }
 
+require Dpkg::Arch;
+my $arch = Dpkg::Arch::get_host_arch();
+
+if ($flags->use_feature('qa', 'framepointer')) {
+$flags->append($_, '-fno-omit-frame-pointer') foreach @compile_flags;
+	if (Dpkg::Arch::debarch_eq($arch, 'amd64')) {
+	$flags->append($_, '-mno-omit-leaf-frame-pointer') foreach @compile_flags;
+	} elsif (Dpkg::Arch::debarch_eq($arch, 'arm64')) {
+	$flags->append($_, '-mno-omit-leaf-frame-pointer') foreach @compile_flags;
+	} elsif (Dpkg::Arch::debarch_eq($arch, 's390x')) {
+	$flags->append($_, '-mbackchain') foreach @compile_flags;
+	}
+}
+
 ## Area: reproducible
 
 # Warn when the __TIME__, __DATE__ and __TIMESTAMP__ macros are used.
diff -Nru dpkg-1.22.1ubuntu3/scripts/Dpkg/Vendor/Ubuntu.pm dpkg-1.22.1ubuntu4/scripts/Dpkg/Vendor/Ubuntu.pm
--- dpkg-1.22.1ubuntu3/scripts/Dpkg/Vendor/Ubuntu.pm	2023-11-23 10:55:44.0 +0100
+++ dpkg-1.22.1ubuntu4/scripts/Dpkg/Vendor/Ubuntu.pm	2023-12-13 09:35:27.0 +0100
@@ -177,6 +177,10 @@
 	$use_feature->{optimize}{lto} = 0;
 	}
 }
+
+if (any { $_ eq $arch } qw(amd64 arm64 ppc64el riscv64 s390x)) {
+$use_feature->{qa}{framepointer} = 1;
+}
 }
 
 sub set_build_features {

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

[Miguel Landaeta]

On Thu, Jan 18, 2024 at 07:50:29PM +0100, Martin Quinson wrote:
> Hello,
> 
> I'm wondering whether you need some help with the packaging of Hare. Is your
> current state available somewhere?

Hi Martin,

I apologize that I somehow missed this message in January.

I prepared a package a few weeks ago but I was waiting for qbe new
upstream release (#1058646) before proceeding with uploads to the
archive. 

Since I'm now noticing there are more folks interested in collaborating,
I'll prioritize this to push my repo to salsa this weekend so other
folks can help to get it ready or just reuse bits from other packaging
efforts if they meet Debian archive expectations.

I don't have my debian laptop handy but tomorrow I'll spend some time
on this and update this bug report with the repo link.

Cheers,
Miguel.

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

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

[Miguel Landaeta]

On Thu, Feb 22, 2024 at 02:19:21AM +, Amin Bandali wrote:
> Hi Miguel,
> 
> I'm interested in helping with this.  Do you have the current state 
> of your work available on Salsa or elsewhere that I could pull in
> and work on?  Otherwise I'll just start with a repo under my own
> account and we could later transfer it to the 'debian' group or
> elsewhere.

Hi Amin, thanks for reaching out.

I'll push my repo tomorrow or during the weekend to salsa and
update this thread with the link.

I started to work on this package a few weeks ago but I decided to
wait for qbe 1.2 before uploading a package and I just noticed
it finally happened this week so I was planning to resume my work
on it.

I don't have time to work on it this weekend but I'll publish it
in a few hours to unblock you and other folks interested in
collaborating.

If you want, I can add you as co-maintainer.

Cheers,
Miguel.

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

Bug#1052939: marked as done (lsp-mode: FTBFS: make: *** [debian/rules:4: binary] Error 25)

[Xiyue Deng]

Control: tags -1 pending

Xiyue Deng  writes:

> Control: reopen -1
> Control: found -1 8.0.0-6
>
> It looks like the attempted fix in 8.0.0-6 is not reliable and still
> fails in ppc64el[1] and s390x[2].  I'm working on a better fix which
> is also forwarded upstream.
>
> [1] https://ci.debian.net/packages/l/lsp-mode/testing/ppc64el/40221847/
> [2] https://ci.debian.net/packages/l/lsp-mode/testing/s390x/40222364/

I have prepared a newer snapshot that has the fix incorporated upstream.
There is a separate RFS[1], and the prepared package has been uploaded
to mentors[2].  Team repo can be found at [3].  Looking for sponsorship
:)

[1] https://bugs.debian.org/1059065
[2] https://mentors.debian.net/package/lsp-mode/
[3] https://salsa.debian.org/emacsen-team/lsp-mode

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#1064475: lists.debian.org: missing recent posts in search indices.

[James Addison]

Package: lists.debian.org
Severity: important

Dear Maintainer,

Some recent discussion from the Debian mailing lists appears to be missing
from the mailing list search engine[1] indices.

For example:

  * Searching for 'Debian'[2] in the debian-devel mailing list, results sorted
by date, currently retrieves a most-recent result dated February of Y2023.

  * A wider search for 'Debian'[3] without specifying an individual mailing
list currently retrieves results up to December of Y2023.

Could you inspect the indexing hosts/processes to check whether posts are being
indexed as expected?

Thank you,
James

[1] - https://lists.debian.org/search.html

[2] - https://lists.debian.org/cgi-bin/search?P=debian=Gdebian-devel=0

[3] - https://lists.debian.org/cgi-bin/search?P=debian=0

Bug#1064474: ITP: rust-rustls-pki-types -- shared types for the rustls PKI ecosystem

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-rustls-pki-types
  Version : 1.3.0
  Upstream Contact: Dirkjan Ochtman 
* URL : https://github.com/rustls/pki-types
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : shared types for the rustls PKI ecosystem

 This crate provides types
 for representing X.509 certificates, keys and other types
 as commonly used in the rustls ecosystem.
 It is intended to be used
 by crates that need to work with such X.509 types,
 such as rustls, rustls-webpki, rustls-pemfile, and others.

This package is needed by recent releases of rust-rustls and others.
It will be maintained in the collaborative Debian section of salsa, at
.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXXsb4ACgkQLHwxRsGg
ASHhSw/+JRLgav5wk3niZQvqMtyKmXTb3DfZlx5DK+GMJL2qFtf3TG3hbrWURe2X
iX/OZqGSk5/IFJamgKbEFQI6JBtXjzCti6oXaPfVRIHBCF6ZPyISNdStKA2KAf5K
q/mh4NpbsSxDhJ00y5dkHSdg5d2p8DFAH+2ZvoW+TdS8eQHORYJ7Tty4G8N60CY7
YnlqefMIFa9i9AU57PlM1sUhTY71jrnwuCeR1dGL1VavBpeQrQihN+j0UdzDaTO7
jjvpmesrdfRMv9wUgvGaZ9GQLeox/rCFp7m5Cktdp5M4pX0itGhIljUd3iFcnvAq
hZoJTGvehWdia8GIJHtGk/Ivf9pajTIb4XFT6VWKeoM74H0zpjQSO4AA+WP/TzBk
vliuf5moOXVjV3UnvIKdPeLlsr1PtZm7dAzHryoxuru8rI4Sfz3zAU1uFbGrJ2jR
DkMSV9ozwPuOXliCaIdQdKzgITz3UN6lcqC9OqNhxJMpI1MOzx1wgNYYcVGOYGMz
FaI1yYakhjfJ4W/Jl+PE2sqjuY5dp/kEa8rL7Dq2346rGFOjzSOVIW6gX98QfiMr
eug0EBwYDO3QjEfQ/ziLmrt3ClPlSWw5hEAiISJjEEQaMQM2+4ABfndtP8cHWq77
9inuoMQmFyZuvB0CquuyO1Lx3BsBCe8uSjIAINo2JtMnk98pLLw=
=oPvz
-END PGP SIGNATURE-

Bug#1064454: debian-policy: Restrict deb822 field names more

[Sam Hartman]

> "Niels" == Niels Thykier  writes:

Niels> Simon Josefsson:
>> Would it make sense to change this to use an inclusive list of
>> permitted characters instead?  How about checking the field names
>> that is in use today, and construct a regexp of permitted symbols
>> out of that?  Starting point: [A-Za-z][A-Za-z0-9-_]*
>> 
>> /Simon

Niels> That is an option and would work for me.

I'd support something along these lines--an inclusive description rather
than an exclusive description.

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

[Ralf Schlatterbeck]

On Thu, Feb 22, 2024 at 07:01:05PM +, Richard Lewis wrote:
> >
> > So I guess that logcheck should be prepared to receive both kinds of
> > timestamps, the 32-byte version and the 25-byte version (without the
> > subseconds timestamp).
> 
> what is the default, and does logcheck cope with that? there's a limit to
> how much to suport out of the box - especially as rsyslog is no longer the
> default.

The current default of Debians rsyslog (after a long time where it was
the 'traditional' format) it is now RFC 3339 timestamps. This comes in
two variants, with or without the sub-seconds part. Logcheck only
supports the variant *with* sub-seconds.

By default, logcheck supports the 'traditional' format and the 32-byte
header, the pattern in most logcheck rules is

^(\w{3} [ :[:digit:]]{11}|[0-9T:.+-]{32})

The first alternative matched by this is something like

Feb 18 00:01:36

while the second is

2024-02-16T20:59:34.218904+01:00

The short form also produced by rsyslog is

2024-02-16T22:06:02+01:00

The third (short) form with no sub-seconds part is currently not matched
by logcheck.

You might want to simply set the match pattern to

^(\w{3} [ :[:digit:]]{11}|[0-9T:.+-]{25,32})

Although rsyslog would probably never produce it, RFC 3339 allows the
sub-seconds part to be short (min 1 digit). There is no maximum in RFC
3339 but RFC 5424 prohibits more than 6 digits:
https://datatracker.ietf.org/doc/html/rfc5424#section-6.2.3.1
For RFC 3339 see p.7 section 5.6 in
https://www.rfc-editor.org/rfc/rfc3339#section-5.6

So it makes sense to match a range of lengths.

> if you configure a logger to produce a certain format it's not unreasonable
> to also have to edit logcheck rules accordingly

I'm talking about the new Debian rsyslog package's default.
And, yes, but that would mean to edit logcheck rules for each installed
package? And the new default of the rsyslog package is the two variants
of RFC 3339. Unfortunately the default for remote logging does *not*
transmit the sub-seconds part. So you end up with two timestamp formats
in the same logfile. Which is fine according to the syslog standard in
RFC 5424.

> But a longer-term solution is perhaps to allow easier customisation of
> rules via "macros"/variables --- a proof-of-concept for this is in
> progress, but not.yet ready for testing

Nice!

Thanks
Ralf
-- 
Dr. Ralf Schlatterbeck  Tel:   +43/2243/26465-16
Open Source Consulting  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling   email: off...@runtux.com

Bug#1063562: dt-schema: Please add version dependency for jsonschema

[Agathe Porte]

Hi,

> This package completly breaks when using python3-jsonschema from
> experimental (4.19.2-1). I had a quick look and upstream is aware
> of the issue. The build script wants a version < 4.18:

Note that the 4.19.2 version was uploaded to unstable [1].

Even if we add this new `Depends: python3-jsonschema (<< 4.18)` the
package will fail to build on unstable thus never migrate to testing.

So I am delaying this for now until upstream decides what to do [2],
or until jsonschema is fixed [3].

[1] 
https://tracker.debian.org/news/1504986/accepted-python-jsonschema-4192-2-source-into-unstable/
[2] https://github.com/devicetree-org/dt-schema/issues/109
[3] https://github.com/python-jsonschema/jsonschema/issues/1085

Bug#1063562: dt-schema: Please add version dependency for jsonschema

[Sebastian Reichel]

Hello Agathe,

On Thu, Feb 22, 2024 at 04:32:11PM +0100, Agathe Porte wrote:
> > This package completly breaks when using python3-jsonschema from
> > experimental (4.19.2-1). I had a quick look and upstream is aware
> > of the issue. The build script wants a version < 4.18:
> 
> Note that the 4.19.2 version was uploaded to unstable [1].

I guess that means the Priority of this bug should be increased
to grave (which should also result in an autoremove from testing).

> Even if we add this new `Depends: python3-jsonschema (<< 4.18)` the
> package will fail to build on unstable thus never migrate to testing.

If you add that dependency for the _binary_ package it should not fail
to build. It cannot migrate to testing, but IMHO that's good. Once
jsonschema migrates to testing it will be broken anyways.

> So I am delaying this for now until upstream decides what to do [2],
> or until jsonschema is fixed [3].
> 
> [1] 
> https://tracker.debian.org/news/1504986/accepted-python-jsonschema-4192-2-source-into-unstable/
> [2] https://github.com/devicetree-org/dt-schema/issues/109
> [3] https://github.com/python-jsonschema/jsonschema/issues/1085

Greetings,

-- Sebastian


signature.asc
Description: PGP signature

Bug#1050220: mutter: autopkgtest regression on s390x: tests time out after 5 minutes

[Simon McVittie]

On Tue, 20 Feb 2024 at 16:08:26 +, Gayathri Berli wrote:
> Please let us know if this bug still needs to be fixed.

I have never seen a s390x machine and probably never will, so you will
know much better than I do whether it's advantageous to our users for
mutter and gnome-shell to be available on that platform, or whether
it would be better to ask for architecture-specific removals of these
packages from s390x and stop spending time on them.

If you would like mutter and gnome-shell to be supportable on s390x,
then yes, we would like their tests to pass reliably there, because
otherwise we have no evidence that they work.

Does it make any sense for gnome-shell to exist on s390x? Or is s390x
only useful as a server platform?

smcv

Bug#1064473: ITP: taskflow -- Parallel and Heterogeneous Task Programming System for C++

[Julian Gilbey]

Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: taskflow
  Version : 3.6.0+git20240218.9616467
  Upstream Contact: Dr. Tsung-Wei Huang 
* URL : https://taskflow.github.io/
* License : Expat
  Programming Lang: C++
  Description : Parallel and Heterogeneous Task Programming System for C++

 Taskflow helps you quickly write parallel and heterogeneous task
 programs with high performance and simultaneous high productivity. It
 is faster, more expressive, with fewer lines of code, and easier for
 drop-in integration than many of existing task programming libraries.
 It is provided as a collecion of C++ header files, using C++17.

This package is a dependency of rapidfuzz, which is a C++ and Python
library for rapid string distance calculations.  In turn, rapidfuzz is
a dependency of newer versions of other Python packages.

It is also a great package in itself, providing a library that can be
used to great effect, as described in several papers and conference
presentations.

I don't think it fits within the Debian Python Team's remit, yet it is
needed by them.  So my proposal is to have myself as maintainer for
now but for the Debian Python Team to be listed as an Uploader.

Bug#1058740: gtk4,librsvg: big-endian support is at risk of being removed

[Simon McVittie]

On Wed, 14 Feb 2024 at 16:47:23 +, Gayathri Berli wrote:
> In the current issue of gtk4 When I tried to reproduce
> the issue on s390x there are 1507 tests that are failing. Can you please
> suggest that version of dependency packages being used/issue reproduce steps/
> logs.

I'm sorry, I don't understand the question. You say you can reproduce 1507
test failures: if that's the case, why do you need steps-to-reproduce?
It seems like you can already reproduce a problem that needs solving?

smcv

Bug#1058740: gtk4,librsvg: big-endian support is at risk of being removed

[Simon McVittie]

On Wed, 14 Feb 2024 at 16:47:23 +, Gayathri Berli wrote:
> In librsvg also we have seen some test failures and regressions. when we
> debugged, we came to know that pixman code changes are triggering the
> regression in librsvg.

That's good to know. I see in
https://gitlab.freedesktop.org/pixman/pixman/-/issues/78 that there is
some confusion over which layer of the stack is the right one to be doing
this byteswapping: the original change was made to fix a bug seen in
gnome-characters, but then that change caused the librsvg bug.

In my experience the only way to solve endianness issues without causing
regressions is to have clear documentation of what endianness each layer
of the stack is aiming to use, so that you can check the behaviour of
each function against that documentation/specification and say "this is
correct" or "this is wrong" with confidence. The majority of computers this
decade are little-endian, so it's mainly the people who are interested in
supporting big-endian computers who need to get this right.

For instance, if a function is returning 32-bit RGBA data, you need
to be able to know whether the correct format is "red first" or "alpha
first" or "red in the least significant byte of the first 32-bit word"
or "alpha in the least significant byte". Otherwise, you can't know
whether a change is actually correct, or whether it's a workaround for
the layer above or below also being wrong.

I think this is what Simon Ser means in their comments on
https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/92.
In your commit message you said "This will write out the pixels as BGRA
on big endian systems but obviously that's wrong", but that isn't obvious
(at least not to me, and probably not immediately obvious to the other
Simon either).

In https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/92
you mentioned that before reverting that change, pixman was failing its
test suite on big-endian, and reverting the change makes its test suite
pass. That's probably relatively good evidence that the revert is the
correct thing to do, but that means it deserves to be mentioned in the
commit message.

This SDL change might be a good example of making sure that an intended
endianness is documented clearly:
https://github.com/libsdl-org/SDL/pull/8318/files

and this one might be a good example of justifying why a change is the
correct change:
https://github.com/libsdl-org/SDL/pull/8819

smcv

Bug#1062770:

[Michael Hudson-Doyle]

> I published an updated consolidated report this morning. As you can see,
> there is an ABI change due to LFS in raft/uv.h
>
>
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-22T10%3A55%3A00/compat_reports/libraft-dev/base_to_lfs/compat_report.html
>
> It is possible some API is not supposed to be exposed or does not appear
> in a shared library or something else, and it would therefore be safe to
> ignore an ABI change that abi-compliance-checker reports. Since I don't
> have specific experience with this package, I can't take such decisions
> and it is ultimately your call.

I think a-c-c is confused here, the symbols it is complaining about are all
from libuv (maybe it got confused by multiple files called "uv.h"?).

So I think this package itself is unaffected, but will require a binNMU
once all the directly affected packages have been rebuilt (like ~5000 other
packages or whatever it is).

Bug#1062928:

[Michael Hudson-Doyle]

FWIW adding a quirk to the analysis confirms that this package is
unaffected by both the lfs and time_t transitions.

Bug#1062744:

[Michael Hudson-Doyle]

Sigh, attached to *this* mail


nmu_libzypp.debdiff
Description: Binary data

Bug#1062744:

[Michael Hudson-Doyle]

I've just reuploaded the package to experimental, new debdiff attached.

Bug#1064472: librust-zerocopy-dev: impossible to install: depends on gone version of librust-zeroize-derive-dev

[Jonas Smedegaard]

Package: librust-zerocopy-dev
Version: 0.6.1-1+b1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: affects -1 rust-ahash

As subject says, the package is impossible to install: depends on gone
version of librust-zeroize-derive-dev

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXXnXMACgkQLHwxRsGg
ASFxoQ/+L0lbPWgl4ZPenJnpFsE7SXe2DcBEN7CLCvkJuLjSNiK87fxMOjJwdEEQ
6MgFMutcvVX78jxjotGuP/ZKFPPuKU+hO7E/vppp9YK0o2HtUsEaxwAMJisTkGyj
D6FXUVhKxh+5JMEP2GcIHnRnNcCET4jxpd3wp2TDoan8E/9P7VqYLOwdbK4JIg3J
L5U2sLZsddqWTO7MToGUMKqaPuUxBKlU4UZm+1vuNAZ2eS92yDKzGMQ1DQXevZx1
Rl7BcMt2+BTZhJ1Hs0uHKK+iZV3nnuXBnMCOZ9gAfMJH5ocBwjivpU2KwXzjKy9m
HqS4QOLbA48qU36nU8VW7xRIABoiCkXZRJEn3+DItXECGYzofH7k6U3XnIRJgyY4
9X3fGy/tZmu5VvZRVOaxvYFvqsAKFuOWQIpEkR81k8mmBfcsvOkcXiCBcg4Z5cBr
HopsSwI0/VVJXkQFZa/4R5zQ3I4Ot1hK+haE0RxV0DbPIZUxfK0HTUkYTD4c+vv+
A2YMOIH9FDwCsp+zgjFec6KeYQizBO1lQ7WCDOz5N3ppzLivdg757IZp12dQ5K7N
6PdjwIP5tFvwSj9AHRSPbEiPn4u7/dMMhOA4EeCJ56IjYkPJDimEcWqZCX2sjiCP
kRrvUDX7jG1HGV2UhWsL+Ib00NmgAkdLl+MfaUwPQ9l/oF49wp8=
=PsHr
-END PGP SIGNATURE-

Bug#1064471: python-pygraphviz: please package v1.12

[Sandro Tosi]

is there a reason you need a newer version of pygraphviz?

On Thu, Feb 22, 2024 at 1:51 PM Alexandre Detiste
 wrote:
>
> Source: python-pygraphviz
> Version: 1.7-3
> Severity: normal
>
> The current watch file does not work
>
> https://pypi.org/project/pygraphviz/
>
> https://github.com/pygraphviz/pygraphviz/releases/tag/pygraphviz-1.12
>
> Greetings



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

[Richard Lewis]

On Thu, 22 Feb 2024, 10:15 Ralf Schlatterbeck,  wrote:

> On Wed, Feb 21, 2024 at 02:52:33PM +0100, Ralf Schlatterbeck wrote:
> >
> > I forgot to mention:
> > There is an upstream (rsyslog) bug-report at
> > https://github.com/rsyslog/rsyslog/issues/5332
>
> Upstream has decided that it is not a bug and that both timestamp
> formats are valid RFC 3339 (I've checked, the grammar explicitly defines
> the sub-seconds part of the timestamp as optional). See link above.
> They also think, logcheck should cope with both formats.
>
> So I guess that logcheck should be prepared to receive both kinds of
> timestamps, the 32-byte version and the 25-byte version (without the
> subseconds timestamp).
>

what is the default, and does logcheck cope with that? there's a limit to
how much to suport out of the box - especially as rsyslog is no longer the
default.

if you configure a logger to produce a certain format it's not unreasonable
to also have to edit logcheck rules accordingly

But a longer-term solution is perhaps to allow easier customisation of
rules via "macros"/variables --- a proof-of-concept for this is in
progress, but not.yet ready for testing

Bug#1064468: Settings schema 'org.gnome.desktop.a11y.interface' does not contain a key named 'show-status-shapes'

[Simon McVittie]

Control: forcemerge 1064438 -1

On Thu, 22 Feb 2024 at 12:25:53 -0500, David Mandelberg wrote:
> Upgrading gsettings-desktop-schemas from 45.0-2 to 46~beta-3 seems to have
> fixed the problem. So I think gnome-settings-daemon's dependency on
> gsettings-desktop-schemas (>= 42~) should be updated to require a newer
> version?

Yes, it's already marked as release-critical and pending upload.

smcv

Bug#1064471: python-pygraphviz: please package v1.12

[Alexandre Detiste]

Source: python-pygraphviz
Version: 1.7-3
Severity: normal

The current watch file does not work

https://pypi.org/project/pygraphviz/

https://github.com/pygraphviz/pygraphviz/releases/tag/pygraphviz-1.12

Greetings

Bug#1064470: barfs on superfluous environment variable

[Zefram]

Package: rakudo
Version: 2020.12+dfsg-1
Severity: normal

Here's an invocation of raku(1) to perform a trivial action:

$ raku -e 'say "hi"'
hi
$

And here's the same invocation with an irrelevant environment variable
added:

$ A=$'\xcc\x81'
$ for p in 0 1 2 3 4 5 6 7 8 9; do A=$A$A; done
$ export A
$ raku -e 'say "hi"'
Unhandled exception: Too many codepoints (1025) in grapheme
   at src/vm/moar/ModuleLoader.nqp:11  
(/usr/share/nqp/lib/ModuleLoader.moarvm:search_path)
 from src/vm/moar/ModuleLoader.nqp:133  
(/usr/share/nqp/lib/ModuleLoader.moarvm:)
 from src/vm/moar/ModuleLoader.nqp:130  
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_setting)
 from :1  
(/usr/lib/perl6/runtime/perl6.moarvm:)
$

raku(1) should not be failing because of an environment variable that
isn't controlling anything and isn't being referenced.

-zefram

Bug#1063703: RFP: swappy -- screenshot editing tool for sway

[Krzysztof Adamski]

retitle 1063703 ITP: swappy -- screenshot editing tool for sway
owner 1063703 !
thanks

I'm using that software daily and I already created a package for myself
so I could happily maintain it in Debian.

Best regards,
Krzysztof Adamski

Bug#1062744:

[Michael Hudson-Doyle]

> There are no mentions of 'time_t' in the public headers of this
> library.

Uh, this is not the case? zypp-core/Date.h contains a class with public
time_t members. Were you grepping the wrong library or something?

The library is also affected by the off_t transition.

> The logs shows that it's a false positive, as the automated
> tool simply wasn't able to build it:
>
>
https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libzypp-dev/base/log.txt

This is 100% not reliable logic as demonstrated above. Adrien added a quirk
to confirm that the library is affected by both transitions but I feel bad
for asking him to do this as the visual inspection turned out to be trivial.

> Closing as not applicable.

Reopening.

Bug#1064419: bookworm-pu: package node-neo-async/2.6.2+~cs3.0.0-2

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Feb 22, 2024 at 02:02:29AM +0530, Praveen Arimbrathodiyil wrote:
> [ Reason ]
> #1064411 some files that are present in npm dist tarball was missing in the
> binary package (it was built but not included in the binary) shipped in
> debian. We noticed this only now since we are trying to integrate
> yarn-plugin-apt (which will use apt installed node modules when available)
> with gitlab in bookworm-fasttrack (fasttrack.debian.net) only now and which
> expects these missing files to be present.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1060214: mirror listing update for repository.su

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2024-01-07 at 17:42 +, repository.su wrote:
> Submission-Type: update
> Site: repository.su
[...]
> Comment: This address is a replacement for the existing mirror
> mirror.surf

The tracefile still contains:

Running on host: mirror.surf

Please fix that and let us know when done. (Likely be changing the
MIRRORNAME variable in your ftpsync config.)

Regards,

Adam

Bug#1063635: mirror listing update for mirror.limda.net

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sat, 2024-02-10 at 08:09 +, Limda Host wrote:
> Submission-Type: update
> Site: mirror.limda.net
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-
> amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Limda Host 
> Country: BD Bangladesh
> Location: Dhaka
> Sponsor: Limda Host https://www.limda.net

Please could you clarify what has changed relative to your current
listing?

Regards,

Adam

Bug#1064289: mirror submission for elmirror.cl

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Mon, 2024-02-19 at 18:57 +, https://elmirror.cl wrote:
> Site: elmirror.cl
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-
> amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x
> Archive-http: /debian/

Our automated checks noticed an issue with your setup:

o The trace file at
  http://elmirror.cl/debian/project/trace/elmirror.cl
  is missing some required information.

  We expect at least the Maintainer and Upstream-mirror values to be filled in,
  and your trace file is missing one or both of them.


Please fix that and let us know once it's done.

Regards,

Adam

Bug#1064371: mirror submission for mirror.xeonbd.com

[Adam D. Barratt]

On Tue, 2024-02-20 at 22:14 +, XeonBD wrote:
> Site: mirror.xeonbd.com
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-
> amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x
> Archive-http: /debian/
> Maintainer: XeonBD 
> Country: BD Bangladesh
> Location: Bangladesh
> Sponsor: XeonBD https://www.xeonbd.com

Our automated checks noticed an issue with your setup:

o We recommend mirrors not sync directly from service aliases such as
  ftp..debian.org (only HTTP is guaranteed to be available at
  ftp. sites).  Maybe change your config to sync from
  the site currently backing the ftp..debian.org service you sync
  from?

Regards,

Adam

Bug#1063821: python-dnslib 0.9.14-1+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1063821 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: python-dnslib
Version: 0.9.14-1+deb11u1

Explanation: validate transaction ID in client.py

Bug#866340: aa-genprof: ERROR: Can't find system log "/var/log/syslog" (journald-only setup)

[3a58f101-de75-4b85-b8fe-127896854a50]

This bug is now 7 years old and has not been fixed yet? Jesus!

Bug#1064431: mirror submission for mirror.fra.macarne.com

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2024-02-21 at 23:45 +, Macarne LLC wrote:
> Submission-Type: new
> Site: mirror.fra.macarne.com

Our automated checks found an issue with your mirror:

o The trace file at
  http://mirror.fra.macarne.com/debian/project/trace/mirror.fra.macarne.com
  is missing some required information.

  We expect at least the Maintainer and Upstream-mirror values to be filled in,
  and your trace file is missing one or both of them.


Please fix that and let us know once it's done.

Regards,

Adam

Bug#1064469: debgpt: does not handle errors

[Vincent Lefevre]

Package: debgpt
Version: 0.4.94
Severity: minor

debgpt does not handle errors:

qaa:~> debgpt -Q -A "who are you?"
[19:06:24] OpenAIFrontend> Starting conversation  frontend.py:66
[...]
LLM[2]> Traceback (most recent call last):
  File "/bin/debgpt", line 8, in 
sys.exit(main())
 ^^
  File "/usr/lib/python3/dist-packages/debgpt/cli.py", line 455, in main
frontend.query_once(f, msg)
  File "/usr/lib/python3/dist-packages/debgpt/frontend.py", line 218, in 
query_once
reply = f(text)
^^^
  File "/usr/lib/python3/dist-packages/debgpt/frontend.py", line 96, in __call__
return self.query(*args, **kwargs)
   ^^^
  File "/usr/lib/python3/dist-packages/debgpt/frontend.py", line 131, in query
completion = self.client.chat.completions.create(
 
  File "/usr/lib/python3/dist-packages/openai/_utils/_utils.py", line 275, in 
wrapper
return func(*args, **kwargs)
   ^
  File "/usr/lib/python3/dist-packages/openai/resources/chat/completions.py", 
line 663, in create
return self._post(
   ^^^
  File "/usr/lib/python3/dist-packages/openai/_base_client.py", line 1200, in 
post
return cast(ResponseT, self.request(cast_to, opts, stream=stream, 
stream_cls=stream_cls))
   
^
  File "/usr/lib/python3/dist-packages/openai/_base_client.py", line 889, in 
request
return self._request(
   ^^
  File "/usr/lib/python3/dist-packages/openai/_base_client.py", line 980, in 
_request
raise self._make_status_error_from_response(err.response) from None
openai.AuthenticationError: Error code: 401 - {'error': {'message': 'Incorrect 
API key provided: empty. You can find your API key at 
https://platform.openai.com/account/api-keys.', 'type': 
'invalid_request_error', 'param': None, 'code': 'invalid_api_key'}}

I would expect just a clear error message.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
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

Versions of packages debgpt depends on:
ii  python3 3.11.6-1
ii  python3-bs4 4.12.3-1
ii  python3-openai  1.12.0-1
ii  python3-prompt-toolkit  3.0.43-1
ii  python3-requests2.31.0+dfsg-1
ii  python3-rich13.3.1-2
ii  python3-tomli   2.0.1-2

Versions of packages debgpt recommends:
ii  git  1:2.43.0-1
ii  man-db   2.12.0-3
ii  python3-zmq  24.0.1-5+b1
ii  tldr 0.9.2-5

Versions of packages debgpt suggests:
pn  python3-torch | python3-torch-cuda | python3-torch-rocm  
pn  python3-transformers 

-- no debconf information

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

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Sam Hartman]

> "Sean" == Sean Whitton  writes:
Sean> In general, I agree with Santiago.  I find Policy's current
Sean> scope and working process effective, and not especially
Sean> ambiguous.  I think everyone should read it during the NM
Sean> process, if not sooner.

Sean> Russ has concretely considered these issues much more than me,
Sean> and Niels has worked extensively on an implementation, and I
Sean> have not.  These things count, so my sense that things are
Sean> broadly okay as they are only goes so far.

I agree with the above.
When Russ brought up concerns I didn't want to add stop energy to making
things better.
But I also am generally happy with policy today.  I find it useful and
refer to it often.  I find that with almost all of my NM applicants I
end up asking them to look at policy at various points in the process
and they do not run into trouble using the document.
The only reason they did not before is they were not in the practice of
doing so.

Bug#1064465: chromium: Chromium cannot use webgl without X (should be compiled with swiftshader)

[Andres Salomon]

Swiftshader is manually disabled in Debian's chromium package. It's one 
of those legacy patches that I've long meant to look at (and remove if 
conditions allow it), but I haven't gotten to yet: 
https://salsa.debian.org/chromium-team/chromium/-/commit/84db0501b0d6cb055fe9f22057cd129fdefac710


It wasn't documented *why* swiftshader was disabled. Maybe related to 
non-DFSG third party libs (see https://bugs.debian.org/909156)? In order 
to reenable it, I need to poke around and see if I can figure out why it 
was disabled in the first place.



On 2/22/24 10:32, Charles Samuels wrote:

Package: chromium
Version: 121.0.6167.160-1~deb12u1
Severity: normal
X-Debbugs-Cc: char...@derkarl.org

Dear Maintainer,

I'd like to use Chromium's webgl support in headless mode. However, If I don't
have an X-server running, and I try to access a website that uses webgl, the
browser simply doesn't support webgl, which forces me to use a non-Debian
Chromium.

I can reproduce this problem with:
$ unset DISPLAY
$ chromium --headless=new --enable-webgl --screenshot https://get.webgl.org

Then Chromium outputs messages like:

[843245:843245:0222/035252.118199:ERROR:gl_display.cc(520)] EGL Driver message
(Critical) eglInitialize: Could not open the default X display.

In theory, I should be able to run Chromium, per their documentation:

$ chromium --headless=new --use-gl=swiftshader --enable-webgl --screenshot
https://get.webgl.org

But it indicates that that is not supported.

In order to support swiftshader, a clone of
 must be present in third_party/
and the debian/rules should set the features: enable_swiftshader=true
dawn_use_swiftshader=true . It might also make sense to use
enable_swiftshader_vulkan=true as well

Thank you for your attention and the efforts you put into Debian.

cs


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

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

Versions of packages chromium depends on:
pn  chromium-common 
ii  libasound2  1.2.8-1+b1
ii  libatk-bridge2.0-0  2.46.0-5
ii  libatk1.0-0 2.46.0-5
ii  libatomic1  12.2.0-14
ii  libatspi2.0-0   2.46.0-5
ii  libbrotli1  1.0.9-2+b6
ii  libc6   2.36-9+deb12u3
ii  libcairo2   1.16.0-7
ii  libcups22.4.2-3+deb12u5
ii  libdbus-1-3 1.14.10-1~deb12u1
ii  libdouble-conversion3   3.2.1-1
ii  libdrm2 2.4.114-1+b1
ii  libevent-2.1-7  2.1.12-stable-8
ii  libexpat1   2.5.0-1
ii  libflac12   1.4.2+ds-2
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-5
ii  libgbm1 22.3.6-1+deb12u1
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgtk-3-0  3.24.38-2~deb12u1
ii  libjpeg62-turbo 1:2.1.5-2
ii  libjsoncpp251.9.5-4
ii  liblcms2-2  2.14-2
ii  libminizip1 1.1-8+deb12u1
ii  libnspr42:4.35-1
ii  libnss3 2:3.87.1-1
ii  libopenh264-7   1:2.3.1-dmo1
ii  libopenjp2-72.5.0-2
ii  libopus01.3.1-3
ii  libpango-1.0-0  1.50.12+ds-1
ii  libpng16-16 1.6.39-2
ii  libpulse0   16.1+dfsg1-2+b1
ii  libsnappy1v51.1.9-3
ii  libstdc++6  12.2.0-14
ii  libwebp71.2.4-0.2+deb12u1
ii  libwebpdemux2   1.2.4-0.2+deb12u1
ii  libwebpmux3 1.2.4-0.2+deb12u1
ii  libwoff1   

Bug#1064031: chromium and rustc in bookworm

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2024-02-15 at 19:25 -0500, Andres Salomon wrote:
> Chromium now requires a Rust compiler to build, and it specifically 
> needs a rustc with profiler support built into it. This package can 
> hopefully be shared with firefox and other browser/web engines that
> end  up needing a newer rustc.

Please go ahead.

Regards,

Adam

Bug#1064343: tput sgr0 adds uncalled-for codes

[Sven Joachim]

I would like to add a few more points here, not to prolong the
discussion but rather for future reference and for myself.

On 2024-02-21 07:06 +0100, Adam Borowski wrote:

> On Tue, Feb 20, 2024 at 07:41:42PM +0100, Sven Joachim wrote:
>> The reason for including \E(B here is that sgr0 should cancel the
>> effects of a previous smacs (start alternate character set) sequence and
>> thus includes the rmacs (end alternate character set) escape sequence.

This has been the case from the early days of ncurses when ESR started
to maintain the terminfo collection.  On archive.debian.org I found a
version on ncurses 1.9.4 with the terminfo.src file version 9.8[1].

The ncurses manpages do not seem to explicitly mention this detail, but
implicitly it appears a few times, for instance in termcap(3ncurses):

,
| termcap has nothing analogous to terminfo's set_attributes (sgr)
| capability.  One consequence is that termcap applications assume that
| “me” (equivalent to terminfo's exit_attribute_mode (sgr0) capability)
| does not reset the alternate character set.  ncurses checks for, and
| modifies the data shared with, the termcap interface to accommodate the
| latter's limitation in this respect.
`

> Then it combines two completely different concepts in one label.  SGR is
> for character attributes, G0/G1 are for encoding.

You might think of it that way, but in (n)curses A_ALTCHARSET is just
another video attribute, the concepts are not that different.

>> Closing the bug, because everything works as intended.
>
> Well, I'm not going to fight a BTS war, but I don't agree with your
> decision.

If you want to see changes, please propose them upstream.  If Thomas
follows your reasoning, great for you.  Otherwise nothing is ever going
to happen anyway, because there is no way I am going to deviate from
upstream here (and patch sgr0 in a gazillion terminfo entries).

Cheers,
   Sven


1. 
https://archive.debian.org/debian/dists/Debian-0.93R6/source/devel/ncurses-1.9.4-0.tar.gz

Bug#1064468: Settings schema 'org.gnome.desktop.a11y.interface' does not contain a key named 'show-status-shapes'

[David Mandelberg]

Package: gnome-settings-daemon
Version: 46~beta-1

After a recent upgrade, many applications running under gnome X11 
stopped using gnome's settings. (Like large text, cursor theme, etc.) 
Digging into it, I found that org.gnome.SettingsDaemon.XSettings.service 
had failed to start with this error message:


feb 21 23:54:27 solaria gsd-xsettings[2760]: Settings schema 
'org.gnome.desktop.a11y.interface' does not contain a key named 
'show-status-shapes'


Upgrading gsettings-desktop-schemas from 45.0-2 to 46~beta-3 seems to 
have fixed the problem. So I think gnome-settings-daemon's dependency on 
gsettings-desktop-schemas (>= 42~) should be updated to require a newer 
version?

Bug#1063898: pipewire-bin: customization file in ALSA profile-sets wrongly packaged

[Dylan Aïssi]

Le jeu. 15 févr. 2024 à 16:03, Sander van Grieken
 a écrit :
>
> Using dpkg-divert is fine. Maybe adding a single comment line mentioning 
> dpkg-divert in /usr/share/alsa-card-profile/mixer/profile-sets/default.conf, 
> just above the include of -custom.conf would be helpful.
>

Patching files always has a maintenance cost that I would like to avoid and
since dpkg-divert is something specific to Debian, I am not sure upstream is
interested by adding such comment. But, we can install a -custom.conf.README
explaining how to use dpkg-divert on it. What do you think?

Best,
Dylan

Bug#1064467: ITP: fonts-sn-pro -- friendly new typeface based on Nunito

[Agathe Porte]

Package: wnpp
Severity: wishlist
Owner: Agathe Porte 
X-Debbugs-Cc: debian-de...@lists.debian.org, gag...@debian.org

* Package name: fonts-sn-pro
  Version : 1.0.0
  Upstream Contact: Tobias https://tobias.so/
* URL : https://supernotes.app/open-source/sn-pro/
* License : OFL-1.1
  Programming Lang: N/A
  Description : friendly new typeface based on Nunito

A friendly new typeface that's open source and free for both personal and
commercial use. We've carefully re-designed each character, improving support
for Markdown and ligatures. This font family is continually being updated and
improved.
.
Designed at Supernotes. Based on Nunito by Vernon Adams.

Will be maintained in the debian-fonts team.

Bug#1064459: base-files: install aliasing symlinks for merged-/usr DEP17

[Helmut Grohne]

block 1064459 by 1053111 1055959 1059533 1059919 1059981 106 1060089 
1060139 1060160 1060270 1061274
user helm...@debian.org
usertags 1064459 dep17m2
thanks

Hi Santiago,

Thanks for the quick feedback.

On Thu, Feb 22, 2024 at 03:27:20PM +0100, Santiago Vila wrote:
> Hi> Please respect any already existing coding style that
> you can notice in other parts of base-files.
> 
> Some examples:
> 
> Indent in shell script using 2 spaces.
> Quotes around "triggered" and similar places.

I'm sorry. I've attached an updated patch correcting this in all places.

> (Also, I wonder if it would be possible to create debian/triggers
> using some sort of dh-exec-like template instead of having
> extra variables and a for loop in debian/rules).

Difficult. The problem is that we need a looping construct here or
duplicate the logic from debian/rules. I value don't-repeat-yourself
higher than being able to use dh-exec and hence interpolated the
triggers from debian/rules.

I somewhat simplified the logic using make's filter-out now. Hope that
makes things more clear.

> While we are at it: Is there an estimated date when you will want
> to upload this?

We can only move forward once all of the bugs marked as blockers have
been fixed (ideally in trixie). I'll have to look into NMUing them soon.
If all goes well and time64 settles, I can do the synced NMU around the
end of March. Does that work for you?

An unsolved problem at this time is how to ensure that all of the
relevant packages migrate to trixie at the same time. Possibly we'll
have to add mutual versioned Breaks to the mix.

Helmut
diff --minimal -Nru base-files-13/debian/base-files.dirs 
base-files-13+nmu1/debian/base-files.dirs
--- base-files-13/debian/base-files.dirs2023-03-02 14:00:00.0 
+0100
+++ base-files-13+nmu1/debian/base-files.dirs   2024-01-24 08:10:53.0 
+0100
@@ -1,4 +1,3 @@
-bin
 boot
 dev
 etc
@@ -8,19 +7,14 @@
 etc/skel
 etc/update-motd.d
 home
-lib
 proc
 root
 run
-sbin
 sys
 tmp
 usr
-usr/bin
 usr/games
 usr/include
-usr/lib
-usr/sbin
 usr/share
 usr/share/base-files
 usr/share/common-licenses
diff --minimal -Nru base-files-13/debian/base-files.lintian-overrides 
base-files-13+nmu1/debian/base-files.lintian-overrides
--- base-files-13/debian/base-files.lintian-overrides   2023-03-02 
14:00:00.0 +0100
+++ base-files-13+nmu1/debian/base-files.lintian-overrides  2024-02-22 
17:16:54.0 +0100
@@ -20,3 +20,14 @@
 base-files: extra-license-file [usr/share/common-licenses/LGPL-2]
 base-files: extra-license-file [usr/share/common-licenses/LGPL-2.1]
 base-files: extra-license-file [usr/share/common-licenses/LGPL-3]
+
+# Yes, these links really should be relative
+base-files: relative-symlink usr/bin [bin]
+base-files: relative-symlink usr/lib [lib]
+base-files: relative-symlink usr/lib64 [lib64]
+base-files: relative-symlink usr/libx32 [libx32]
+base-files: relative-symlink usr/sbin [sbin]
+
+# Yes, we need these for the relevant architectures
+base-files: non-multi-arch-lib-dir [usr/lib64/]
+base-files: non-multi-arch-lib-dir [usr/libx32/]
diff --minimal -Nru base-files-13/debian/changelog 
base-files-13+nmu1/debian/changelog
--- base-files-13/debian/changelog  2023-06-11 17:00:00.0 +0200
+++ base-files-13+nmu1/debian/changelog 2024-02-22 17:16:54.0 +0100
@@ -1,3 +1,10 @@
+base-files (13+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * DEP17: Install /usr-merge aliasing symlinks. Closes: #-1.
+
+ -- Helmut Grohne   Thu, 22 Feb 2024 17:16:54 +0100
+
 base-files (13) unstable; urgency=medium
 
   * Change issue, issue.net, debian_version and os-release
diff --minimal -Nru base-files-13/debian/clean base-files-13+nmu1/debian/clean
--- base-files-13/debian/clean  2023-03-02 14:00:00.0 +0100
+++ base-files-13+nmu1/debian/clean 2024-01-24 08:30:30.0 +0100
@@ -1 +1,2 @@
 debian/postinst
+debian/triggers
diff --minimal -Nru base-files-13/debian/control 
base-files-13+nmu1/debian/control
--- base-files-13/debian/control2023-03-02 14:00:00.0 +0100
+++ base-files-13+nmu1/debian/control   2024-01-24 08:25:17.0 +0100
@@ -7,7 +7,7 @@
 Rules-Requires-Root: binary-targets
 
 Package: base-files
-Provides: base
+Provides: base, usr-is-merged
 Architecture: any
 Pre-Depends: awk
 Depends: ${misc:Depends}
diff --minimal -Nru base-files-13/debian/postinst.in 
base-files-13+nmu1/debian/postinst.in
--- base-files-13/debian/postinst.in2023-03-02 14:00:00.0 +0100
+++ base-files-13+nmu1/debian/postinst.in   2024-02-22 17:15:11.0 
+0100
@@ -106,3 +106,15 @@
 install_directory mnt 755 root
   fi
 fi
+
+if [ "$1" = "triggered" ]; then
+  for d in #USR_MERGE_MULTILIB#; do
+if test -d "$DPKG_ROOT/usr/$d"; then
+  test -h "$DPKG_ROOT/$d" && continue
+  ln -s "usr/$d" "$DPKG_ROOT/$d"
+else
+  test -h "$DPKG_ROOT/$d" || continue
+  rm "$DPKG_ROOT/$d"
+fi
+  done
+fi
diff --minimal -Nru 

Bug#1064451: the problem with sending an error message via the reportbug package

[Николай Сабельников]

so we'll write it. can you tell me how to close the bug?

22 февраля 2024 г. 19:45:19 GMT+03:00, Sandro Tosi  
пишет:
>it's a wiki, you can write it yourself if you want
>
>On Thu, Feb 22, 2024 at 11:43 AM Николай Сабельников
><79625490...@yandex.ru> wrote:
>>
>> thanks for the information. but why is there no such information in the 
>> Debian wiki? I think it's worth writing it in the wiki.
>>
>> 22 февраля 2024 г. 19:34:52 GMT+03:00, Sandro Tosi  
>> пишет:
>> >please read the doc and configure programs according to your needs:
>> >https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/conf/reportbug.conf?ref_type=heads#L64-72
>> >
>> >On Thu, Feb 22, 2024 at 6:03 AM Nikolay Sabelnikov
>> ><79625490...@yandex.ru> wrote:
>> >>
>> >> Package: reportbug
>> >> Version: 12.0.0
>> >>
>> >> hello. There is a problem with sending error information via reportbug. I 
>> >> use Yandex mail. And I have two-factor protection set up there. And when 
>> >> setting up, you need to add the ability to add a username and password 
>> >> that I can generate in my mail account.
>> >>
>> >>
>> >
>> >
>
>
>

Bug#1064428: [Britney] does not migrate new arch:all packages after initial migration of same source

[Dalton Durst]

Hi Paul,

Thanks very much for your reply.

For what it's worth, I don't necessarily need britney2 to handle these
migrations "correctly", and I don't think Debian does either. However,
there is some behavior instability when arch-indep and arch-dep packages
are proposed in different ways in the same source. It would be okay if
britney2 simply threw the migration out with the message "this is too
complicated, some human should tell the archive what to do." Instead, it
either passes the arch-indep package through as a rider on another
change or seems to ignore the package entirely.

On Wed, Feb 21, 2024, at 11:59 PM, Paul Gevers wrote:
> On 21-02-2024 23:50, Dalton Durst wrote:
>
> > If the
> > package were binNMU'd, though, britney would migrate everything
> > including the arch:all package if it passed checks.
>
> In Debian, binNMU-ing a arch:all package is known to not work. I don't
> know if this bug is the reason why it doesn't work, but I've been taught
> this when I joined the Release Team. I think I tried once by accident
> (or ignorance) and the binNMU didn't work.

Sorry, I might not have been as clear as possible here. The problem is
that the arch:all packages won't migrate unless there's another valid
migration item in the source. So an arch:all package could be stuck in
unstable for a while without moving. As soon as a valid binNMU appears
(without replacing the arch:all package, as is policy), the arch:all
package might migrate too.

> > This behavior
> > instability might be undesirable.
>
> But there _might_ be more infrastructure problems than britney2.

Agreed. In fact, I found even spookier behavior in britney2 while adding
more tests.

To explain: when this odd situation occurs, the arch:all package seems
to be checked for validity, at least a little. If it is installable, it
migrates with the binNMU. If it is not installable, it does not migrate
with the binNMU. This seems like a good thing, britney2 is somehow
avoiding a non-installable package in testing. However, in all cases,
the excuses output does not accurately reflect the decisions that were
made during britney's run.

Depending on how the downstream software actually performs migration,
you could still get different results from the same britney run. When
the arch:all package is "accepted" (scare quotes because britney2 says
the package is ignored in excuses), it appears in HeidiResult but not
HeidiResultDelta.

This is a little hard to explain, so I've attached another three tests
which demonstrate the situation. "arch-all-migrates-with-broken"
demonstrates what happens when the arch:all package itself is not
installable, but the binNMU is. "arch-all-migrates-with-others" shows
an OK arch:all and arch:any migration (with the :all package appearing
in HeidiResult but not the delta). "arch-all-migrates-without-others"
shows what happens "at rest," when all arch-dep binaries for the source
are already in testing. "...without-others" should be a repeat of the
test attached in my first message, but they can all be run with
"bin/runtests ../britney2/britney.py t test-out /arch-all-migrates.*/"
which is nice.

>
> > The code which skips arch:all packages dates all the way back to
> > britney2's original import[1], so it's not clear if it's still
> > load-bearing.
>
> In the old days, an arch:all package was never build on a buildd, but
> uploaded by the uploader (together with the source). It's very possible
> that that fact is related to the original intent.

Makes sense.

> I am currently working an a change to britney2 that (based on
> Package-List entries in the Sources) will prevent migration of sources
> which build arch:all binaries. That will also work around bug #915948
> (in dak) and fix bug #887060 (in britney2 for Sources build from
> source.changes files). From our conversation on IRC I take it that that
> wouldn't solve *your* case as you're using aptly and apparently that
> builds the Sources (with or without a Package-List) from what's in the
> archive so it would still run into this issue.

That sounds like a really good addition. I suppose it would mark a
change in my situation because the unstable source package's
Package-List would be different from the testing package. Maybe that
change would be enough to get some output from britney2 when this odd
situation is hit?

Thanks again,
Dalton

0001-WIP-Add-tests-for-new-arch-all-binaries.patch
Description: Binary data

Bug#1064451:

[Николай Сабельников]

done

Bug#1064451: the problem with sending an error message via the reportbug package

[Николай Сабельников]

thanks for the information. but why is there no such information in the Debian 
wiki? I think it's worth writing it in the wiki.

22 февраля 2024 г. 19:34:52 GMT+03:00, Sandro Tosi  
пишет:
>please read the doc and configure programs according to your needs:
>https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/conf/reportbug.conf?ref_type=heads#L64-72
>
>On Thu, Feb 22, 2024 at 6:03 AM Nikolay Sabelnikov
><79625490...@yandex.ru> wrote:
>>
>> Package: reportbug
>> Version: 12.0.0
>>
>> hello. There is a problem with sending error information via reportbug. I 
>> use Yandex mail. And I have two-factor protection set up there. And when 
>> setting up, you need to add the ability to add a username and password that 
>> I can generate in my mail account.
>>
>>
>
>

Bug#1064451: the problem with sending an error message via the reportbug package

[Sandro Tosi]

it's a wiki, you can write it yourself if you want

On Thu, Feb 22, 2024 at 11:43 AM Николай Сабельников
<79625490...@yandex.ru> wrote:
>
> thanks for the information. but why is there no such information in the 
> Debian wiki? I think it's worth writing it in the wiki.
>
> 22 февраля 2024 г. 19:34:52 GMT+03:00, Sandro Tosi  
> пишет:
> >please read the doc and configure programs according to your needs:
> >https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/conf/reportbug.conf?ref_type=heads#L64-72
> >
> >On Thu, Feb 22, 2024 at 6:03 AM Nikolay Sabelnikov
> ><79625490...@yandex.ru> wrote:
> >>
> >> Package: reportbug
> >> Version: 12.0.0
> >>
> >> hello. There is a problem with sending error information via reportbug. I 
> >> use Yandex mail. And I have two-factor protection set up there. And when 
> >> setting up, you need to add the ability to add a username and password 
> >> that I can generate in my mail account.
> >>
> >>
> >
> >



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Jonas Smedegaard]

Quoting Facundo Gaich (2024-02-22 17:12:22)
> I can work on packaging this if you're still interested, I'd need a sponsor.
> 
> I've already done some preliminary work on this, in particular I renamed
> the bin to "rust-toml2json" but maybe you've got a better idea?

If the command-line tool does somewhat the same as the existing one, I
suggest to rename it with the deviating part as the end instead, so that
users TAB-completing would easier notice the alternative:
toml2json-rust.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Bug#1064451: the problem with sending an error message via the reportbug package

[Sandro Tosi]

please read the doc and configure programs according to your needs:
https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/conf/reportbug.conf?ref_type=heads#L64-72

On Thu, Feb 22, 2024 at 6:03 AM Nikolay Sabelnikov
<79625490...@yandex.ru> wrote:
>
> Package: reportbug
> Version: 12.0.0
>
> hello. There is a problem with sending error information via reportbug. I use 
> Yandex mail. And I have two-factor protection set up there. And when setting 
> up, you need to add the ability to add a username and password that I can 
> generate in my mail account.
>
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1064466: RFP: xsqlite -- forensic analysis of SQLite database files

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: vil...@debian.org

* Package name: xsqlite
  Version : 2.0.6
  Upstream Contact: Netherlands Forensic Institute
* URL : https://github.com/NetherlandsForensicInstitute/xsqlite
* License : Expat
  Programming Lang: Python
  Description : forensic analysis of SQLite database files

 Xsqlite is a Python 3 package that can be used for forensic analysis of
 SQLite database files. It's main purpose is to recover deleted records,
 but it can also be used to analyse the low-level file structure for
 forensic purposes. The package includes a simple command-line tool for
 basic record recovery, but for more advanced usage it can be used as
 Python module or in the interactive Python shell.

Bug#1064447: debuerreotype: ineffective diversions (due to /usr-merge DEP17) for obsolete upstart files

[Tianon Gravi]

On Thu, 22 Feb 2024 at 01:48, Helmut Grohne  wrote:
> debuerreotype diverts /sbin/initctl. This file is part of upstart, which
> has been deleted from Debian since at least bullseye. If it still were
> part of Debian, we'd have to move the file and hence this diversion
> would become ineffective. Rather than fix it, I propose deleting the
> dead code.

It is precisely those older versions that the code still exists for --
I use debuerreotype for creating reproducible rootfs builds all the
way back to slink. 

You can see in [1] that it only runs that diversion iff "upstart"
exists in the repos we're pointed at.

[1]: 
https://github.com/debuerreotype/debuerreotype/blob/60b625d1ce31bd81525bb67fc3a33f9686bc3433/scripts/debuerreotype-minimizing-config#L40

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#1062756: reported upstream

[Patrick Schleizer]

https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2053153/

Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Facundo Gaich]

Hi,

I can work on packaging this if you're still interested, I'd need a sponsor.

I've already done some preliminary work on this, in particular I renamed
the bin to "rust-toml2json" but maybe you've got a better idea?

Best,
Facundo

Bug#1064461: gnome-settings-daemon: Xft.dpi not set correctly for 4K monitor at 200% scale

[Simon McVittie]

On Thu, 22 Feb 2024 at 14:21:38 +, Daniel Thompson wrote:
> I assume this is a version skew problem caused by gnome-settings-daemon
> updating to GNOME 46 before other components

If you upgrade both gnome-settings-daemon and gsettings-desktop-schemas
to their versions from unstable, does that resolve this?

(Possibly the same bug as #1064438)

smcv

Bug#1061290: RFS: rgbds/0.7.0-3 [ITP] -- Game Boy ASM programming tools

[P. J. McDermott]

I'm not a DD so I can't upload this, but I took a look.  I see you've
addressed most of the comments on Mentors in the repository on GitHub,
so I'm reviewing that rather than the older upload on Mentors.

Build-Depends lists pkg-config, which is a transitional package since
bookworm that should be replaced with the newer pkgconf.  lintian warns
about this:

W: rgbds source: build-depends-on-obsolete-package Build-Depends: 
pkg-config => pkgconf

This is just a suggestion/tip and not at all required, but it's popular
to use `wrap-and-sort -ast` to put each dependency on its own line (with
a trailing comma).  This would make the diff clearer in commits like
d1842536 and 22baba8b.

The years in the Copyright field of the "Files: *" stanza of d/copyright
look outdated: "1997-2020" when LICENSE says "1997-2023" since commit
f8af5696.

Not required by all sponsors, but Emmanuel on Mentors and Tobias here
suggested maintaining the packaging Git repository on Salsa (and
updating the Vcs- fields):

https://salsa.debian.org/
https://salsa.debian.org/games-team
https://salsa.debian.org/debian

You may also want to look into git-buildpackage with pristine-tar and a
DEP-14 branch layout:

https://honk.sigxcpu.org/piki/projects/git-buildpackage/
https://www.eyrie.org/~eagle/notes/debian/git.html
https://dep-team.pages.debian.net/deps/dep14/

Looks OK otherwise to me, and the package builds fine under sbuild with
no lintian tags (even informational or pedantic) other than the obsolete
package warning above; nice work!  So, once the pkg-config -> pkgconf
switch and copyright years update are done, I think it's good enough for
someone to upload.

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1038434: Update on bug 1038434

[陈 晟祺]

Control: notfound -1 2.1.11-1
Control: tags -1 + wontfix

> There is a zfs-load-key service that is masked, and as such never
> starts, and the script in init.d doesn't do anything either because of
> that.

This service is intentionally masked. This functionality is now provided by
zfs-mount-generator(8). Please refer to its man pages for usage.

Thanks,
Shengqi Chen

Bug#1064465: chromium: Chromium cannot use webgl without X (should be compiled with swiftshader)

[Charles Samuels]

Package: chromium
Version: 121.0.6167.160-1~deb12u1
Severity: normal
X-Debbugs-Cc: char...@derkarl.org

Dear Maintainer,

I'd like to use Chromium's webgl support in headless mode. However, If I don't 
have an X-server running, and I try to access a website that uses webgl, the 
browser simply doesn't support webgl, which forces me to use a non-Debian 
Chromium.

I can reproduce this problem with:
$ unset DISPLAY
$ chromium --headless=new --enable-webgl --screenshot https://get.webgl.org

Then Chromium outputs messages like:

[843245:843245:0222/035252.118199:ERROR:gl_display.cc(520)] EGL Driver message
(Critical) eglInitialize: Could not open the default X display.

In theory, I should be able to run Chromium, per their documentation:

$ chromium --headless=new --use-gl=swiftshader --enable-webgl --screenshot
https://get.webgl.org

But it indicates that that is not supported.

In order to support swiftshader, a clone of
 must be present in third_party/ 
and the debian/rules should set the features: enable_swiftshader=true
dawn_use_swiftshader=true . It might also make sense to use 
enable_swiftshader_vulkan=true as well

Thank you for your attention and the efforts you put into Debian.

cs


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

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

Versions of packages chromium depends on:
pn  chromium-common 
ii  libasound2  1.2.8-1+b1
ii  libatk-bridge2.0-0  2.46.0-5
ii  libatk1.0-0 2.46.0-5
ii  libatomic1  12.2.0-14
ii  libatspi2.0-0   2.46.0-5
ii  libbrotli1  1.0.9-2+b6
ii  libc6   2.36-9+deb12u3
ii  libcairo2   1.16.0-7
ii  libcups22.4.2-3+deb12u5
ii  libdbus-1-3 1.14.10-1~deb12u1
ii  libdouble-conversion3   3.2.1-1
ii  libdrm2 2.4.114-1+b1
ii  libevent-2.1-7  2.1.12-stable-8
ii  libexpat1   2.5.0-1
ii  libflac12   1.4.2+ds-2
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-5
ii  libgbm1 22.3.6-1+deb12u1
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgtk-3-0  3.24.38-2~deb12u1
ii  libjpeg62-turbo 1:2.1.5-2
ii  libjsoncpp251.9.5-4
ii  liblcms2-2  2.14-2
ii  libminizip1 1.1-8+deb12u1
ii  libnspr42:4.35-1
ii  libnss3 2:3.87.1-1
ii  libopenh264-7   1:2.3.1-dmo1
ii  libopenjp2-72.5.0-2
ii  libopus01.3.1-3
ii  libpango-1.0-0  1.50.12+ds-1
ii  libpng16-16 1.6.39-2
ii  libpulse0   16.1+dfsg1-2+b1
ii  libsnappy1v51.1.9-3
ii  libstdc++6  12.2.0-14
ii  libwebp71.2.4-0.2+deb12u1
ii  libwebpdemux2   1.2.4-0.2+deb12u1
ii  libwebpmux3 1.2.4-0.2+deb12u1
ii  libwoff11.0.2-2
ii  libx11-62:1.8.4-2+deb12u2
ii  libxcb1 1.15-1
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.6-1
ii  libxext62:1.3.4-1+b1
ii  libxfixes3  1:6.0.0-2
ii  libxkbcommon0   1.5.0-1
ii  libxml2 
2.9.14+dfsg-1.3~deb12u1
ii  

Bug#1001802: Update on bug 1001802

[陈 晟祺]

control: forwarded -1 https://github.com/openzfs/openzfs-docs/issues/237
control: notfound -1 2.0.3-9

> - while the script indeed waits for user input, snapshots list and 
prompt are not displayed to the user

Please disable "quiet" in your kernel cmdline, or you won't get stderr from 
initramfs.

> - the script does not check that the value given by the user is valid

Yes. You can submit an PR to openzfs/zfs, it is located at 
contrib/initramfs-tools.

Thanks,
Shengqi Chen

Bug#1061248: glibc: DEP17: move most files but rtld to /usr

[Julian Andres Klode]

On Sun, Feb 04, 2024 at 09:20:09PM +0100, Helmut Grohne wrote:
> Hi Aurelien and Sven,
> 
> On Wed, Jan 24, 2024 at 09:19:12PM +0100, Aurelien Jarno wrote:
> > On 2024-01-23 17:40, Helmut Grohne wrote:
> > > Conflicting runtime dynamic linkers between multiarch packages
> > > ==
> > > 
> > > Some architecture combinations such as s390, powerpc, hppa, m68k,
> > > mipsn32, and hurd-i386 or alpha, i386, sh4, and sparc have conflicting
> > > runtime dynamic loaders. In theory this violates Multi-Arch: same, but
> > > there is basically nothing we can do about this and dropping Multi-Arch:
> > > same from the packages would completely break any kind of multiarch
> > > setup. There is little we can do here and this is also unrelated to
> > > DEP17.
> > 
> > We tried to add conflicts for those, like it's done for the multilib
> > packages, but at the time the infrastructure exploded (see #745552). I
> > don't remember the details, but I guess it was either dak or
> > dose-builddebcheck.
> 
> Yeah, I also remember something like that. It's not the first time I
> trip into this. "There is little we can do here" still counts.
> 
> > I guess the symlink in the maintainer script could indeed work. I am not
> > sure why it has been done like that, it was part of the multiarch
> > patchset from Steve Langasek more than 10 years ago.
> 
> Practically speaking, it appears to work rather well. On the flip side,
> I also thought that way of my first patch. ;)
> 
> > Note however that the those packages are used by cross-toolchain-base
> > (which builds them from glibc-source) and mangled to install them in the
> > cross path. See for instance libc6-amd64-x32-cross. For such cases, we
> > probably do want to keep the dynamic linker symlink, as those packages
> > do not have maintainer scripts.
> 
> I don't think those -$arch-cross packages need the runtime dynamic
> linker at all. Unlike the libc6-$multilib packages, we don't use
> -$arch-cross packages to actaully run any binary. Simply not installing
> it might just work in practice.
> 
> So here is an updated patch with a few notes:
>  * This patch moves all the files including the runtime dynamic linker
>in the main multiarch library. Therefore, this patch needs to be
>synced with the corresponding base-files change to add the aliasing
>symlinks or debootstrap breaks. In other words: Don't upload this
>yet.
>  * As mentioned earlier, only the multiarch packages install the runtime
>dynamic linker via data.tar. All the multilib packages install it via
>maintainer scripts now.
>  * When installing libc6-x32, /libx32 will be created because partial
>upgrades might otherwise be broken. Removing libc6-x32 will not
>remove /libx32 though. I suggest fixing this in base-files by
>installing a trigger interest in /usr/libx32 and having
>base-files.postinst create/remove /libx32 as needed. This way, we
>centralize the management of aliasing links into base-files. libx32
>only serves as an example here and it works the same way for any
>other non-essential multilib directory. Do you agree with the
>approach?
>  * The multilib packages install a trigger interest on the runtime
>dynamic linker such that they notice when a multiarch package deletes
>it and can then recreate it as needed. Thus the multiarch packages do
>not have to pay attention to a possibly installed multilib package
>when they are removed.
>  * I've tried quite a few multiarch upgrades involving amd64 and i386
>using dpkg --auto-deconfigure --unpack with various packages and even
>cross grading libc6-x32 from :i386 to :amd64 during the upgrade.
>While dpkg --verify was occasionally unhappy during a partial upgrade
>(where half-unpacked packages were around), once no package was
>half-installed, dpkg --verify was also happy again in all attempts. I
>did not come up with a systematic enumeration of possible upgrade
>scenarios though.
>  * The patch works will deboostrap/cdebootstrap/mmdebstrap (in
>combination with more patches including base-files, bash, dash and
>util-linux).
>  * The change to install ldconfig to /usr/sbin can be uploaded right
>away. It's limited to debian/debhelper.in/libc-bin.install and
>debian/debhelper.in/libc-bin.lintian-overrides and doesn't contribute
>much diff, so doing it later is fine as well.
> 
> I hope you don't manage to punch holes into my theory this time around.

Ubuntu testing revealed that due to /lib64 going away in the package we
also are going to need Depends or PreDepends on base-files, such that
base-files trigger can then create the symlink.

Or we temporarily handle the trigger ourselves or so.

I am not sure if Depends are enough, I guess if you do a release
upgrade we could end up with

unpack base-files
unpack libc6 
preinst for something we want to unpack -> poof, no /lib64 here, can't 

Bug#1064464: mariadb 10.3.39 crash at startup and can't be recovered

[Brice Waegeneire]

Package: mariadb-server
Version: 1:10.3.39-0+deb10u2

Hello there,

We had a crash with MariaDB server 10.3.39 on a Debian 10 server, which 
we weren't able to recover from. We know this is an old version of 
MariaDB, so we don't expect this bug to be fixed, but we want to 
document it in case other person are impacted.


What happened was: the instance crashed, and we weren't able to start it 
up again (see the attached partial-backtrace.txt), then we managed to 
have it start with the additional options "innodb_force_recovery = 3" 
and "innodb_purge_threads = 0". However, when we remove these options, 
the server crash during startup again. So the bug is reproducible on our 
hand,


The following is the environment of the crashed instance:

# cat /etc/debian_version
10.13
# dpkg -l mariadb-server-10.3
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion Architecture Description
+++-===-===--=
ii  mariadb-server-10.3 1:10.3.34-0+deb10u1 amd64MariaDB 
database server binaries

# mariadb --version
mariadb  Ver 15.1 Distrib 10.3.39-MariaDB, for debian-linux-gnu (x86_64) 
using readline 5.2

# mysqld --print-defaults or SHOW VARIABLES
mysqld would have been started with the following arguments:
--user=mysql --pid-file=/run/mysqld/mysqld.pid 
--socket=/run/mysqld/mysqld.sock --basedir=/usr --datadir=/var/lib/mysql 
--tmpdir=/tmp --lc-messages-dir=/usr/share/mysql 
--bind-address=127.0.0.1 --query_cache_size=16M 
--log_error=/var/log/mysql/error.log --expire_logs_days=10 
--character-set-server=utf8mb4 --collation-server=utf8mb4_general_ci 
--max_connections=250 --back_log=100 --max_connect_errors=10 
--slow_query_log=1 --slow_query_log_file=/var/log/mysql/mysql-slow.log 
--long_query_time=10 --key_buffer_size=512M --max_allowed_packet=64M 
--thread_stack=192K --thread_cache_size=1 --max_heap_table_size=64M 
--table_open_cache=4096 --table_definition_cache=4096 
--query_cache_limit=8M --query_cache_size=256M --query_cache_type=1 
--max_heap_table_size=128M --tmp_table_size=128M --innodb_file_per_table 
--innodb_buffer_pool_size=512M --innodb_thread_concurrency=16 
--character-set-server=utf8 --collation-server=utf8_general_ci 
--secure-file-priv= --bind-address=0.0.0.0 --thread_cache_size=1 
--innodb_buffer_pool_size=4815M --tmpdir=/home/mysqltmp 
--innodb_log_file_size=256M --log_bin=/srv/mysql_binlogs/mysql-bin.log 
--expire_logs_days=5 --max_binlog_size=100M --binlog_format=mixed 
--sync_binlog=1 --gtid_domain_id=1 --server-id=1 
--auto-increment-increment=10 --auto-increment-offset=2 
--gtid_strict_mode=On --report-host=10.0.14.154 --report-port=3306 or 
SHOW VARIABLES


Note, the exact version of the mariadb-server package may not be 
consistent in the different logs (10.3.34-0+deb10u1 and 
10.3.39-MariaDB-0+deb10u2) because I wasn't able to get the debug 
symbols for the initial version (10.3.39-MariaDB-0+deb10u2) and ended up 
downgrading the package to get a full back trace. The crash occurred 
with both package version.


Note the attached innodb-status.txt if from the instance with 
innodb_force_recovery set.


I have already reported this bug to upstream: 
https://jira.mariadb.org/browse/MDEV-33528


If I've forgotten to share some information, I'll be happy to provide it.

Cheers,
- Brice Waegeneire
--
Brice WAEGENEIRE  - SysAdmin support Evolix
Evolix - Hébergement et Infogérance Open Source
Marseille (37 rue Guibal, Pôle Média, 13003) / Paris / Montréal
http://evolix.com | Twitter: @Evolix @EvolixNOC | http://blog.evolix.com

Bug#985299: Update on bug 985299

[陈 晟祺]

control: -1 notfound 2.0.3-1
control: -1 tags + wontfix

Hi,

> After an upgrade, some kind of system services appeared to automatically mount
> some FreeBSD partitions on my Debian system directories.

As zfs cannot tell which pools / datasets are from FreeBSD, zfs-mount.service 
will try to mount everything.

> Disabling zfs-mount.service and zfs-share.service made my machine work 
> normally
> again, possibly with the modification of /etc/defaults/zfs below:

This would work on your case, but might cause trouble when somebody has their 
root / home on zfs.
You can do "zfs set canmount=noauto bsdpool" to prevent auto-mounting of 
foreign datasets.

Thanks,
Shengqi Chen

Bug#1012805: Update on bug 1012805

[陈 晟祺]

control: tag -1 + moreinfo unreproducible

> At first vdev_id is not in the search path but in /lib/udev/vdev_id. 
> Next, it doesn't find the config file /etc/zfs/vdev_id.conf when started 
> without options. It does find it however when this very path is given 
> explicitly like so:
> # /lib/udev/vdev_id -c /etc/zfs/vdev_id.conf

This is expected. This script should only be used by udev, not users.

> The instructions in the FAQ section of the openzfs docs state that the 
> command
> # udevadm trigger
> should create the /dev/disk/by-vdev directory and some symlinks in it.

I tried some config with zfs 2.1.4 on bullseye. It worked as expected.

Run 'udevadm monitor' when you trigger the udevadm update might help.

Thanks,
Shengqi Chen

Bug#1060898: apfs-dkms: fails to build module: super.c:17:10: fatal error: version.h: No such file or directory

[Andreas Beckmann]

On 19/02/2024 19.34, Gürkan Myczko wrote:
So sorry, moved to bananas team, but never filled it, now it's there and 
ready.

Feel free to go ahead with a team upload...


Done ;-)

I've added two more changes to fix/skip building the module for older 
kernels, maybe these patches should be sent upstream.


  * Fix module build for Linux 4.18.13..4.19~ since discard_new_inode() 
was backported.

  * Set BUILD_EXCLUSIVE_KERNEL_MIN="4.13" for kmemdup_nul() usage.

You can find the updated master branch and a signed tag in
https://salsa.debian.org/anbe/linux-apfs-rw.git

(Not creating a merge request since AFAIK that cannot transfer the tag.)

I'd recommend enabling the salsa pipeline for the package.
In case you aren't used to that:
In the project page in salsa
under Settings -> CI/CD -> General pipelines
set "CI/CD configuration file" to
recipes/debian.yml@salsa-ci-team/pipeline
(i.e. it fetches the pipeline definitions from another repository)
and salsa will automatically build and test the package the next time 
you push the repository with results similar to

https://salsa.debian.org/anbe/linux-apfs-rw/-/pipelines/642925

Andreas

PS: I do have an amd64 chroot with most Debian kernel header packages 
going back to 2.6.32 installed that I use for testing dkms and dkms 
modules to the extreme ;-)

Bug#1064463: reptyr: New upstream version 0.10.0 available

[Michael Prokop]

Package: reptyr
Version: 0.9.0-1+b1
Severity: wishlist

Hi,

since 2023-06-04 version 0.10.0 is available, see
https://github.com/nelhage/reptyr/tags

According to the changelog, it's only about
"Add arm7 and aarch64 support for FreeBSD", not sure it's relevant
for Debian context though? :)

Thanks for packaging + maintaining reptyr in Debian! :)

regards
-mika-

Bug#977322: Following advice of cute-field tag for X-DhRuby-Root breaks build

[Niels Thykier]

Control: clone -1 -2
Control: retitle -2 gem2deb: Case sensitive handling of d/control
Control: reassign -2 gem2deb

On Sun, 13 Dec 2020 15:27:20 -0800 Russ Allbery  wrote:

Package: lintian
Version: 2.104.0
Severity: normal

Lintian now emits the following pedantic tag for packages using
X-DhRuby-Root:

P: remctl source: cute-field debian/control@ruby-remctl X-DhRuby-Root vs 
X-Dhruby-Root
N:
P: cute-field
N:
N:   The named field uses a free-style form of capitalization, which is
N:   permitted by policy. The alternative offered is probably a more common
N:   variant in the archive.
N:   
N:   Refer to Debian Policy Manual section 5.1 (Syntax of control files)

N:   for details.
N:   
N:   Severity: pedantic
N:   
N:   Check: fields/style


However, following this advice breaks the Ruby package tooling.  The
build products are not copied into the package correctly and the resulting
package is empty.  Apparently the Ruby package tooling requires that
specific capitalization.

This is with gem2deb 1.4.

[...]


Hi

On one end, I do not think `lintian` decides the canonical case / 
spelling of a field. In that sense, I feel this bug is valid.


On the flip side, gem2deb does not follow the deb822 if field name case 
matters. The format is defined as case-insensitive.


"""
Field names are not case-sensitive, but it is usual to capitalize the 
field names using mixed case as shown below. Field values are 
case-sensitive unless the description of the field says otherwise.

"""

Cloned and reassigned accordingly.

Best regards,
Niels

Bug#1064459: base-files: install aliasing symlinks for merged-/usr DEP17

[Santiago Vila]

Hi.

Please respect any already existing coding style that
you can notice in other parts of base-files.

Some examples:

Indent in shell script using 2 spaces.
Quotes around "triggered" and similar places.

(Also, I wonder if it would be possible to create debian/triggers
using some sort of dh-exec-like template instead of having
extra variables and a for loop in debian/rules).

While we are at it: Is there an estimated date when you will want
to upload this?

Thanks.